Why your auditor wants security work tracked to a committed timeline
Your auditor isn't checking that you fix things. Your auditor is checking that security work is visible, owned, and closed on a timeline you committed to in advance — access changes, system changes, vulnerabilities and incidents. A ticket is how you prove all three at once.
The commitment is the part people miss. Fixing a critical vulnerability in three days is good work. Fixing it in three days after publishing a policy that says two is a finding.
Two separate assertions
Every one of these controls is really two claims, and a ticket has to carry both:
- It was tracked. The work existed as a record before it was done — requested, assigned, owned. Work that only exists after the fact can't be sampled, and can't show anyone was accountable for it.
- It was closed on time. Against a deadline you set beforehand, not one you decided was reasonable afterwards.
You can fail either assertion independently. A team that fixes everything fast but works from a chat channel fails the first. A team with beautiful tickets that all sit open for months fails the second.
How an auditor tests this control
An auditor doesn't read everything. They take your population — every access ticket in the period, say — and pull a sample from across it, usually including something from the middle rather than only the recent ones. For each sampled item they trace it end to end: who asked, who approved, what was done, what proves it, and how long it took.
Then they compare how long it actually took against the timeline in your own policy — not against an industry norm.
This is why a small, honest, complete population beats a large sloppy one.
Why a deadline chosen to pass the test is the worst outcome
It's tempting to set generous deadlines so the tests stay green. It backfires in a specific way: your policies, your customer commitments and your configured timelines all end up saying different things, and the auditor reads the gap between them rather than the green tick. That gap is easier to find than a missed deadline and harder to explain.
Set the timeline you can genuinely meet, write it in your policy, commit the same number everywhere you state it, and then meet it. If the number is wrong, change it deliberately and re-approve the policy. A missed deadline you can explain is a normal finding. A contradiction between your own documents is a credibility problem.
What this looks like in practice
Each kind of work has its own population and its own bar, but the shape is identical every time: make the work visible before it's done, give it a deadline you set in advance, record enough that someone can trace it a year later, and close it honestly.