Who should read this: anyone who has spent the four weeks before an audit chasing screenshots, and would prefer not to do it again next year.
Every framework worth the name asks the same thing in the end. Not “do you have a policy”, but “show me this ran”. ISO 27001 calls it documented information. NIS2 calls it demonstrating the measures. A customer questionnaire calls it attach your evidence. Same question, three vocabularies.
There are two ways to answer it, and the gap between them is the difference between a working management system and an annual archaeology project.
The month before, and why it recurs
The pattern is familiar enough to describe without knowing your company.
Four to six weeks before the audit, someone opens the control list and starts collecting. A screenshot of the MFA settings. A copy of the joiner checklist. An export of the patch status. A list of suppliers pulled together from three people’s memories. A backup report for the current month, because nobody kept the earlier ones.
It works. The audit passes. Then it happens again next year, because nothing about the way work is recorded has changed, only the deadline.
Three things make this expensive beyond the obvious hours.
It samples the wrong period. Auditors ask for evidence across a window, not a snapshot. Assembled evidence is almost always current-state, which is exactly the shape that prompts the follow-up question about the other eleven months.
It puts the burden on the people least able to carry it. The engineer who can produce the screenshot is the engineer who was doing something else.
It creates a file, not a record. A folder of screenshots assembled in March describes March. It answers this audit and contributes nothing to the next one, so the cost repeats in full.
What auditors actually accept
Useful to be precise here, because the belief that evidence must be pretty causes a lot of unnecessary work.
Auditors accept records that were created as a by-product of the work. A ticket with a date. A log entry. An approval in the tool where approvals happen. A signed-off review with the reviewer’s name and the date they did it.
They are trained to notice evidence that was manufactured for them. Not because they are suspicious by nature, but because it is easy to see: a set of documents with adjacent timestamps, a tidiness that real operations do not have, a screenshot of a setting rather than a record of the change that set it.
And they accept gaps that are explained. A patch record with a hole and a note saying why is a working system with a known issue. A patch record with no hole at all, for a company of forty people, is a claim nobody believes.
The bar is not perfection. It is contemporaneity. Was this recorded when it happened.
The four evidence types, and which of them can generate itself
Sorting your control evidence by type tells you where the work actually is.
1. Configuration state. MFA enforcement, encryption settings, access policies, cloud posture. This can be read from the systems themselves, continuously, without anyone taking a screenshot. If you are still screenshotting settings, this is the first thing to fix.
2. Event records. Logins, changes, patches, incidents, alerts. Generated by systems as a matter of course. The work is not creating them, it is retaining them for the audit window and being able to answer a question with them.
3. Human decisions. Risk acceptances, approvals, exceptions, management review minutes, supplier assessments. These cannot generate themselves, because the evidence is the decision. What they need is a place to live with a date and an owner attached, so they can be found a year later.
4. Periodic activities. Access reviews, training, backup restore tests, BCP exercises, internal audits. These need a schedule that produces a dated record whether or not anyone remembers the audit is coming.
Types 1 and 2 should be automatic. Type 3 needs a system of record. Type 4 needs a calendar with teeth. Almost all audit-preparation pain comes from treating all four as though they were type 3, and doing them by hand.
Start the clock before the documents are finished
This is the scheduling consequence, and it is the one that costs whole quarters.
Your management system has to have been operating for a period before Stage 2, typically around three months, because sampling requires history. That is calendar time. It cannot be compressed with money or effort, which is the constraint at the centre of how long ISO 27001 really takes.
Which means the recurring things should start in week one, imperfect. Access reviews, patch records, log retention, the first supplier assessments. Most projects perfect the documentation first and start the evidence clock in month four, pushing certification out by a full quarter for no gain whatsoever.
An imperfect access review with a date beats a perfect one that has not happened yet. Every time.
What this looks like when it works
A control carries four things: an owner, a status, its evidence, and a date. The evidence arrives because the work happened, not because someone went looking for it.
When a questionnaire, an auditor or a regulator asks, the answer is already there. The reason internal audit and management review get raised as findings so often is that both depend on evidence being in place beforehand, and both are usually scheduled after the evidence work has been deferred.
It also changes the economics. The largest line in an ISO 27001 budget is internal staff time, and audit preparation is where most of it goes. Cutting that is a bigger saving than any negotiation with a certification body, as the arithmetic in what ISO 27001 actually costs an SME shows.
This is also the point of holding the control set, the gap list and the evidence in one place rather than three. Not because a tool is inherently better than a folder, but because a control record with an owner and a date is the thing that answers the next framework as well as this one.
The technical reality: generated evidence proves timing, not effectiveness
The honest limit of everything above.
Evidence that assembles itself proves a control operated. It does not prove the control worked. Those are different claims, and the second one is not on the certificate.
A vulnerability scanner running monthly and filing its report automatically produces excellent evidence for A.8.8. It produces exactly the same excellent evidence whether the critical findings were remediated in three days or ignored for nine months. Log retention that runs continuously satisfies A.8.15 regardless of whether anyone has ever queried those logs. Automated backup reports satisfy the record-keeping expectation whether or not a restore has ever been tested.
Automating evidence collection removes the archaeology. It does not close the gap between a control that exists and a control that protects you. Closing that gap means the finding has to go somewhere with an owner and a deadline, and the deadline has to be enforced by something other than the audit calendar. The controls where this matters most, and the ones where recording is genuinely enough, are separated in the Annex A controls grouped for real work.
