The evidence an ISO 27001 auditor will actually accept
"Show me the last one."
An auditor says it at Stage 2 about the quarterly access review, the annual restore test, the security training your policy says every joiner completes in their first week. The control is real. The team does the work. Then somebody starts scrolling a Slack thread looking for the screenshot they posted in March, and the room gets quiet.
That gap accounts for more first-audit trouble than missing controls do. Nothing was insecure. What was missing was an artefact that lets an independent third party confirm the control operated, on a date, across a known set of things, without taking anyone's word for it. This piece is about what "evidence" means to an auditor as distinct from what it means to an engineer. If you're earlier in the process, the complete certification guide covers the whole path first.
The standard asks for two different kinds of document
Clause 7.5 of ISO 27001:2022 governs documented information, and it draws a line most teams never notice. Some documents are maintained: policies, procedures, methodologies, your scope statement, the risk assessment method. They set out how the organisation intends to operate. Others are retained: logs, registers, minutes, review records, attestations, completed forms, reports. They capture what the organisation actually did.
Both are required. First audits reliably over-produce the first kind, because writing a policy is a bounded task with an obvious finish line, while producing records is a habit that has to have been running for a while before anyone asks to see it.
The two are also load-bearing on each other. A maintained document is what makes a retained one legible: your access control policy says recertification runs quarterly, so the auditor knows to expect four records for the year and can tell immediately that you have produced two. Write "periodically" instead and you have not escaped the requirement, you have just made your own evidence impossible to score, which an auditor reads as its own answer.
Clause 7.5 is a requirement of the management system itself, not an Annex A control. So are the internal audit and management review obligations in clauses 9.2 and 9.3. Annex A controls are the security measures your risk treatment selects; the numbered clauses are the machinery that has to run regardless of which controls you selected. Auditors check both, and the clause requirements are not something your Statement of Applicability can exclude.
The retained-record test
When an auditor picks up a record, they are asking four questions of it. A record that answers all four survives sampling. A record that misses one is weaker than the team producing it believes, and the team usually finds out in the room.
When, and who? A record needs a date and an accountable person. An undated screenshot establishes a state at the moment somebody took it and nothing about when that was or who checked it. A PDF export with a generated-on date, a ticket with a closure timestamp, minutes with an attendee list: these carry the same information and can be handed over without narration.
Out of what? Sampling requires a population. "We reviewed access" invites the next question, which is access to what, covering which accounts, and how you know the list was complete. A review record that names its source (all accounts in the identity provider as at a given date, all repositories in the production organisation) is testable. One that names no population cannot be tested, only believed.
Where does it live, and can you produce it again? Clause 7.5.3 covers control of documented information: it has to be available where it is needed, and it has to be protected, which includes storage, retention and version control. This is where the quarterly access review kept in one spreadsheet, overwritten each quarter, quietly fails. The review happened four times. The record exists once, in its current state, and the three earlier ones were destroyed by the process that created the fourth.
What happened to what it found? A review that found nothing, every quarter, for a year, reads as a review nobody performed. Real reviews turn up dormant accounts, an over-provisioned contractor, a service principal nobody can place. The record should show those exceptions and where they went: removed on a date, accepted with a reason, raised as a ticket that closed. The exception trail is often stronger evidence that the control operates than the review itself, because it is the part nobody would bother to fabricate.
Four questions, one record. It is worth running them over your evidence before an auditor does, particularly on controls you are confident about, because confidence is exactly where teams stop checking.
Three controls where the record is the hard part
A.5.18 (Access rights). The control requires that access is granted, reviewed, modified and removed in line with your access control policy, with periodic recertification and prompt revocation when someone changes role or leaves. Most teams do revoke promptly. Far fewer can produce a recertification record with a named population and a documented outcome, and fewer still can produce last year's. Leaver evidence is usually the easier half: an offboarding checklist per departure, with dates, does most of the work.
A.8.13 (Information backup). Backups are maintained and regularly tested in accordance with an agreed backup policy, with restoration validated against defined recovery objectives. Almost every SaaS team backs up. The evidence gap is the word "tested". A restore that has never been performed on the record is a backup with an untested assumption attached, and the auditor is not asking whether it would work, they are asking for the record of the time you checked. A restore test note with the date, the system, who ran it, how long it took and whether the result met the objective is a short document that closes the control.
A.6.3 (Information security awareness, education and training). This one fails on population rather than on existence. The training platform shows a completion rate. The auditor wants to know the denominator: everyone in scope, including the three people who joined in the last quarter and the contractor with production access. Reconciling the training roster against the current staff list, on a date, and keeping that reconciliation is the record. The completion certificate on its own is not.
Some records can only be made by time passing
There is a category of evidence you cannot assemble in the last fortnight before Stage 2, and it is worth identifying early because it sets your real timeline more than the policy writing does.
Anything with a cadence is in this category. If your policy commits to quarterly access recertification, a year of evidence takes a year. A.8.8 (Management of technical vulnerabilities) is assessed against the cadence you defined, so the evidence is a run of dated scan reports with the remediation each one triggered, and a single report produced the week before the audit covers one week of it. The internal audit required by clause 9.2 and the management review required by clause 9.3 both have to have happened, with their own records, before an external auditor can confirm the system reviews itself.
The practical consequence is an ordering one. The recurring records should be the first thing you start and the last thing you finish, because every week you delay is a week of history you will not have. Policies can be written in parallel and revised late. A quarter cannot be compressed.
This is also the honest answer to teams asking how far back evidence has to go. For a first certification, an auditor is generally looking for enough operating history to believe the system runs, and the length they expect is anchored to the cadences you set yourself, not to a fixed number of years. Commit to monthly and you owe more records than a team that committed to quarterly and can defend the choice.
How scoper.io reads your evidence
scoper.io works on the documents you already have. You upload your policies, procedures, configurations and records into the evidence vault, and the platform interrogates them against the Annex A controls, producing a verdict per control: covered, partial, gap, or not applicable. Every verdict cites the specific documents it rests on, so the reasoning is visible and checkable, and a verdict you disagree with can be attested or disputed by a practitioner, re-run for that single control, or answered by attaching the document the assessment did not have.
The output that matters most for the subject of this article is the evidence index in the assessor dossier. It lists the documents in your vault with a reference label each, the controls that cite them, and the extracts the assessment actually relied on. When an auditor asks which document supports a claim, the answer is a page you can turn to. Alongside it, the gap analysis names the controls where the evidence does not carry the claim yet, which is the same list you would otherwise assemble by hand, later, under more pressure.
What the platform cannot do is create a record that does not exist. If nobody minuted the review, no assessment can find the minutes; it will tell you the evidence is absent, which is useful, and is still a record you have to go and make. It also does not certify anyone. An accredited Certification Body does that, from what they find in your evidence. There is more on the assessment flow on the ISO 27001 product page, and the Statement of Applicability piece covers the document all of this evidence eventually has to agree with.
Common questions
Is a screenshot acceptable evidence? Sometimes, and it is usually the weakest option available. A screenshot with no date, no source and no context answers one of the four questions above. If a screenshot is genuinely the only artefact a system produces, pair it with something that carries the date and the reviewer, such as a ticket or a signed note recording when it was captured and by whom.
Can we write the record after the event? You can document something that happened, and doing so honestly is normal practice: a note written in August recording an April review, dated as written and describing what was done, is a weak record but not a dishonest one. Backdating it is a different act entirely, and it converts a minor evidence gap into a finding about the integrity of your management system. Auditors are practised at spotting documents that all appeared in the same fortnight.
Does the auditor want every record, or a sample? A sample. At Stage 2 they select controls, ask for representative evidence, and follow whatever they find. That is why population matters so much: a sample is only meaningful if you can show what it was drawn from, and a request you cannot answer completely tends to widen the next request.
We have the control but no record for last year. What now? Say so, and treat it as a gap with a plan rather than something to paper over. A control operating now, with a dated record from this quarter and a documented start date, is a defensible position. A control claimed as long-standing with no history behind it is the one that goes badly.
The short version
ISO 27001 distinguishes documents that are maintained, which describe intent, from records that are retained, which prove occurrence. Teams heading into a first audit almost always have the controls and the policies; what they lack are the retained records. Every record an auditor accepts answers four questions: when and by whom, out of what population, held where and reproducible, and what happened to the exceptions it found. Records governed by a cadence cannot be assembled late, so start those first and let the policy drafting run alongside them.
If you want to see which of your controls your current documents actually support, book a demo. We run the assessment against your own evidence and show you the citations behind every verdict.
See it run on your own evidence.