What a ticket has to contain to stand up in an audit
A compliance ticket needs five things in it: who asked, who approved, what specifically changed, what proves it's done, and when. The test only reads the label, the priority, and the open and close dates — your auditor reads the whole ticket, so passing the test is the floor, not the goal.
This is the gap that costs people their audit. A ticket that says "offboard Sam" and closes in a day passes every automated check and tells an auditor nothing. They can't tell what access Sam had, who authorized removing it, or whether it actually happened.
The five things
- Who asked. The requester, by name — a person, a form submission, an alert, or a scanner. "Someone in the team channel" isn't a requester.
- Who approved, and when. Approval is the item an auditor presses hardest on and the one most often missing. Approval has to come from someone with the authority to give it, and it has to be visible on the ticket — a comment, an approval field, a linked request. A ticket the assignee both raised and approved is a finding.
- What specifically changed. Not "access updated" — which systems, which permissions, which servers, which version. Specific enough that someone who wasn't there could verify it a year later.
- What closed it. Link the proof: the pull request, the scanner rescan, the deprovisioning log, the incident write-up. A link is worth more than a paragraph, because the auditor can follow it.
- When. Your tracker records open and close dates for you. Add the real-world date if it differs — a termination date, a change window, the time an incident was detected.
Put these five things into a ticket template so nobody has to remember them — Make the compliant ticket the default with templates and automation shows how.
What good looks like — an access ticket
An access ticket is the fullest example, because access tickets are the highest-volume family and the first one auditors sample:
- What kind — onboarding, offboarding, or an access change
- Who — the person's name and role, and their start, termination, or role-change date
- What access — every system and the permission level on each, plus equipment and physical access to issue or take back
- Who approved it — a named approver confirming the work on the ticket, with a date
- Who did it, and what state it's in — assignee and status
- Proof of completion — the deprovisioning output, the confirmation from each system owner
For the access list, you can keep role-based permission documents outside the ticket and link the right one. If someone gets access beyond their standard role, that goes on the ticket itself — the exception is the part an auditor wants to see justified.
The same five things, per kind of work
- System change — what was changed and where, why now, who approved it, what backed it out if it went wrong, and the release or pull request that proves it shipped.
- Vulnerability — the finding and its severity, the affected asset, the fix or the accepted risk, and the rescan or patch record that closed it.
- Incident — everything above, plus when it was detected, which is usually earlier than when the ticket was raised, and whether personal data was affected.
Why your auditor cares
Auditors don't read every ticket. They pick a handful from across the period and trace each one end to end — request, approval, action, proof. One sampled ticket that can't be traced does more damage than ten on-time tickets do good, because it tells the auditor the process is informal. That's why the fields matter more than the count.
Closing a ticket you haven't finished is the worst available option. It is the one move that makes your evidence worse rather than better: the work isn't done, and now the record says it is.
Common mistakes
- Approval by silence. Nobody objected in a channel, so it went ahead. That's not approval and it can't be sampled.
- "Done" as the closing comment. Link what proves it.
- One ticket for a whole quarter of work. A batch ticket can't be traced to any single request or approval.
- Secrets in the ticket. Never paste credentials, keys or personal data into a ticket to "show your work" — link to where they live instead.