An Audit Sample, a Documentation Gap, and a Proposal to Reclassify
Internal audit sampled 200 of the 1,840 production changes made last year and found 14 without documented approval. Nine were emergency changes where approval was recorded retroactively inside the policy's 48-hour window, but the ticket template never captured an incident ID, so the link cannot be proven from the record. The other five have no approval at all; two of those touched a system in scope for financial reporting. The audit committee meets in six weeks. The change manager proposes reclassifying the nine as compliant and closing the finding, arguing the work was in fact approved. Your team's emergency-change documentation error rate is 22% by the same sampling method.
1. Do you support the reclassification? Justify your answer.
Read the worked answer
No - not as a closure of the finding, though the underlying claim may be true.
The change manager's argument is about what happened; the audit finding is about what can be evidenced. Those are different claims and the audit committee is entitled to the second one. Reclassifying nine items as compliant converts an evidenced control gap into an unevidenced assertion, and it does so in a sample where you already know 22% of emergency changes have the same documentation defect. If you reclassify, you are asserting a fact about the other ~1,600 changes that a 22% error rate directly contradicts.
The honest framing: the control design permitted approval without capturing the link, so the nine are not misconduct - they are a design defect. Say that. The finding stands, but its character changes from "people bypassed approval" to "the system could not prove approval happened." That is a better and more defensible statement, and it points at a fix that actually works.
The five with no approval at all are a different matter and must not be bundled with the nine. Two touched a financially relevant system; that is the item the committee will ask about, and it needs its own analysis.
2. What root cause do you present, and what do you commit to fixing in six weeks?
Read the worked answer
Root cause, stated in one line: the emergency-change ticket template has no required field for the incident reference, so approval could be recorded without a link to the event that justified it - a design defect, not a discipline problem.
Note the arithmetic that supports this: a 22% documentation error rate is far too high to be individual carelessness. At that rate you are describing the template, not the team.
What you can credibly commit to in six weeks - only what is real:
- Template change, incident ID mandatory for emergency changes, with the field validated at submission. Live within two weeks.
- Backfill the nine sampled items with corroborating evidence where it exists (chat logs, incident records, deployment logs), and record what can and cannot be reconstructed. Report the reconstruction rate honestly - if it's 7 of 9, say 7 of 9.
- Re-perform the sample on the current quarter to show whether the template change moved the rate. This is the only thing that demonstrates the fix works.
Do not commit to "retraining" as the primary fix. When the error rate is 22%, training is the answer to a question nobody asked.
3. The five unapproved changes include two in a financially relevant system. How do you handle that separately?
Read the worked answer
Separate it explicitly, in writing, and do not let it be absorbed into the documentation discussion.
For each of the five, establish: what the change did, when it went to production, who made it, whether it was tested, and whether it altered anything that feeds financial reporting. If any of the two in-scope changes affected a control the auditors rely on, that is a potential control deficiency that Legal and the CFO need to see before the audit committee does - not at the meeting.
Assess materiality honestly rather than defensively. Most such changes turn out to be minor and the story ends at "a process lapse with no financial effect" - which is a fine outcome, but only if you establish it with evidence rather than assume it because it is convenient.
Report the five separately from the nine, with their own root cause. If it emerges that all five were genuine process bypasses, the finding is about enforcement of the emergency path, and the template fix does nothing for it - you would need a monitoring control, such as a monthly reconciliation of emergency changes against incident records. Say which of the two causes you believe, and what would change your mind.