· Yair Knijn
Collecting ISO 27001 Annex A evidence: what auditors sample and what actually counts
ISO/IEC 27001:2022 restructured Annex A into 93 controls across four themes — organisational, people, physical, and technological. The Statement of Applicability says which of those controls you claim; evidence is what proves each claimed control actually operates. That distinction is where most first audits wobble: teams arrive with a binder of policies and discover that a policy is evidence of intent, not of operation.
An auditor does not read everything. They sample: pick a leaver from the HR list and ask for the access-revocation record, pick a change from the release log and ask for its approval, pick a supplier and ask for the last review. Evidence collection is therefore not about volume. It is about being able to produce the specific record for the specific instance the auditor picked, quickly, with a date on it.
What evidence looks like, per theme
For the organisational controls (the largest theme), the load-bearing records are registers and reviews: the asset inventory with owners, the supplier register with review dates, access review results with who approved what, incident records with timelines, and the policy set with review history. A supplier register that was demonstrably updated in March, June, and September tells a different story from one with a single creation date.
For people controls, evidence lives at the joins: screening confirmation before access was granted, awareness training completion records per person, signed confidentiality terms, and disciplinary process records if invoked. The joiner-mover-leaver chain produces most of it — and most of the gaps. We wrote about that failure mode in the leaver who still has access to three SaaS apps.
For physical controls, cloud-first organisations mostly inherit evidence from providers — data centre certifications and attestation reports — plus their own records for offices and equipment: visitor logs, asset disposal certificates, clear desk spot checks.
For technological controls, the evidence is system-generated or it is fiction: authentication logs showing MFA enforcement, configuration baselines and drift reports, backup completion and restore-test records, vulnerability scan results with remediation dates, change logs, and audit trails that the vendor cannot edit — a property we covered in the audit trail the vendor could edit.
Point-in-time collection is the anti-pattern
The night-before-the-audit screenshot sprint fails for a structural reason: a surveillance audit looks at the period, not the day. A screenshot of MFA settings taken in October proves nothing about February. Records need timestamps spread across the year, which means collection has to be an operating habit — ideally a by-product of systems that log continuously — rather than a project. We described the sprint version of this failure in the ISO 27001 evidence assembled the night before.
The practical setup: map each Statement of Applicability control to the system that produces its record, note the cadence (continuous log, monthly review, annual test), and give each mapping an owner. Where the record is a periodic human action — an access review, a restore test — put it on a calendar with the evidence artefact named in advance. The audit then becomes an export exercise. If you are still on the 2013 control set, the transition deadline has passed; we covered what changes in ISO 27001:2022 after the transition.
One caution from the other side of the table: never describe yourself as "ISO 27001 certified" before the certificate exists. Buyers check, and the claim is more damaging than the gap. Building the operating record first — controls running, evidence accumulating — makes the eventual audit an inspection of something real.
The Spot Suite modules are built to leave this kind of operating record behind: per-action audit trails, exportable evidence, and registers that update because the system did the work, not because someone remembered to.