SimDeskMost first-time ISO 27001 projects produce a folder of policies, a risk spreadsheet and a fortnight of panic before the audit. The policies are usually fine. What the auditor asks for is the boring part: show me that this control ran, on these dates, and who checked it.
What an auditor actually samples
- Access reviews — who had privileged access last quarter, who approved it, what was removed.
- Backups — that a restore was tested, not just that a job succeeded.
- Incidents — the ones you recorded, how severity was decided, and what changed afterwards.
- Risk treatment — a risk with an owner, a decision and a date, not a colour on a chart.
- Training — who took it, when, and what happens to the person who did not.
- Supplier reviews — what the vendor can access and what was checked before they got it.
- Management review and internal audit minutes, with the actions closed out.
Why the spreadsheet fails
A spreadsheet records that something happened; it cannot prove when it was written. A row added the night before the audit looks exactly like a row added in March. Auditors know this, which is why a system with timestamps, an audit log and a signature carries more weight than a tidier workbook.
Make the evidence a by-product of the work
The way out is to stop producing evidence and start recording work in the place that keeps it. An incident logged in the system is the incident record. An asset issued to an engineer is the asset evidence. A document signed in the library is the document control evidence. Nobody assembles anything at the end of the quarter, because it was assembled as it happened.
Value the assets in a way you can defend
Ratings that were guessed will be picked apart. Rate each asset for Confidentiality, Integrity and Availability against written criteria, and — this is the part most registers miss — for the Expectations placed on it: what a customer contract, a regulator or the law requires of it. A system with no sensitive data can still be your most critical one because you promised its uptime in writing.
Close the loop on every incident
Clause A.5.27 asks you to learn from incidents. In practice that means every closed incident leaves behind two things: what it taught you, and how a repeat is prevented. Keep them on the incident itself, and write the recurring ones up as a knowledge base article so the next person settles it in minutes rather than rediscovering it.
We run our own ISO 27001 and ISO 27701 certification on exactly this: the compliance module of our platform, used every day rather than demonstrated once a year. The audit week stops being a project and becomes a read-only visit.