THE POINT The annual fire drill happens because evidence is built for the auditor instead of being produced by the control. Fix that, and audit readiness becomes a by-product of normal operations.
What the drill looks like
The audit window opens. Engineers pull screenshots. Someone rebuilds a spreadsheet of joiners and leavers. Control owners are chased for proof of reviews that may or may not have happened. The audit closes, the team exhales, and nothing changes until next cycle.
The effort is not the problem. The design is. Evidence that depends on a person remembering to capture it will always arrive late and incomplete.
Where it starts
-
Evidence is collected, not generated. A control may run correctly inside a tool, yet the proof is a manual screenshot taken weeks later. The control worked. The evidence says nothing about when.
-
Nobody owns the population. Auditors test samples drawn from a complete list: every leaver, every privileged account, every production change. If the team cannot produce that list and show it is complete, the sample has no value. This is a common point where requests stall.
-
The control statement drifts from practice. The document says quarterly access reviews. In practice, reviews happen when someone remembers. The auditor tests what the document says.
-
Ownership is vague. A control with a team name in the owner column has no owner.
What to change
-
Build one control-to-evidence map. For every in-scope control, record the owner, the system of record, the evidence produced, how often, where it is stored, and which frameworks and contracts it satisfies. One control often serves several requirements. Map it once.
-
Produce evidence at the point of operation. Ticket closures, configuration exports, scheduled reports and log queries should create evidence as the control runs. Screenshots are the fallback, not the method.
-
Define each population once. Write down the report or query that lists it, who runs it, and how completeness is checked, for example by reconciling the HR leaver list against directory disablements.
-
Check evidence monthly, not annually. Ask one question per control: did it produce its evidence this period? Log exceptions when they occur and set a fix date. An exception you logged and fixed shows the control is monitored. The same exception found by an auditor shows it is not.
-
Rehearse before the window opens. Pick a sample of controls. Request evidence the way an auditor would. Time how long it takes and who gets pulled in.
-
Agree the rules early. Confirm with the auditor the sampling approach, the period covered, and which evidence formats they accept. Surprises here cost the most time.
What good evidence looks like by control
| Control | Population | Evidence worth keeping | Common gap |
|---|---|---|---|
| Access review | All accounts in scope for the system | Dated review record showing reviewer, decision per account, and completed removals | Reviews recorded, removals never evidenced |
| Change management | All changes in the period, from the change system | Approval, test result and deployment record linked to one change | Emergency changes approved after the fact with no record |
| Vulnerability remediation | All findings by severity from the scanner | Remediation against stated timelines; exceptions with approver and expiry | Exceptions with no owner or end date |
| Joiner, mover, leaver | HR list reconciled with directory | Ticket timestamps against HR effective dates | HR and IT lists never reconciled |
| Backup and restore | All in-scope systems | Job logs plus completed restore test results | Backups proven, restores never tested |
Why the cycle repeats
Certification and assurance schemes are built on repetition. Organizations certified to ISO/IEC 27001 are audited on a recurring cycle, with surveillance audits between full certification audits. A SOC 2 Type 2 report covers an observation period, so a control has to operate and be evidenced throughout that period, not just in the final weeks. A team that prepares only at the end of the period will always be short of evidence for the beginning of it.
How to tell it is working
-
Most of the auditor’s request list is answered from the evidence repository, not by asking people.
-
Exceptions are found by your own monthly check before the auditor finds them.
-
Every control has a named person as owner, and that person knows it.
-
Time from request to evidence drops across audits. Track it.
Limits
Automating evidence does not fix a weak control. It produces clean proof that a weak control ran. Review control design first, then automate its evidence. Auditors also differ in what they accept, so treat the points above as a method to adapt, not a standard to quote.
Sources
-
International Organization for Standardization. ISO/IEC 27001, Information security management systems — Requirements. iso.org
-
International Organization for Standardization. ISO/IEC 17021-1, Conformity assessment — Requirements for bodies providing audit and certification of management systems. iso.org
-
American Institute of Certified Public Accountants. SOC 2 examinations and the Trust Services Criteria. aicpa-cima.com
-
National Institute of Standards and Technology. Cybersecurity Framework 2.0. csrc.nist.gov
How we label evidence
Facts carry a source. Analysis and recommendations are marked as ours. Examples that are hypothetical are labeled as hypothetical.
Part of the solutionSecure & ComplyTurn regulatory duties into controls that hold up.See how we work →Related service
Audit Readiness
Use this to build defensible audit evidence.