Organisations usually fail their first ISO 27001 audit for a reason that surprises them. The controls were genuinely in place. Access was genuinely restricted. Backups genuinely ran.
What was missing was proof that any of it happened.
ISO 27001 is an evidence standard as much as a control standard. The auditor’s job is not to admire your architecture; it is to sample records and see whether your described controls actually operated over a period. A control with no record is, from an audit standpoint, indistinguishable from a control that does not exist.
This changes what you should build. The goal is not to be secure on audit day. It is to run infrastructure that emits evidence continuously as a by-product of normal operation.
The seven things auditors reliably sample
1. An asset inventory that matches reality
The auditor will take your inventory and check it against what is actually running, and they will look for the gap in both directions.
The failure mode is not usually a missing spreadsheet. It is an inventory that was accurate when it was written and has since diverged: decommissioned servers still listed, and more damagingly, systems in production that appear nowhere.
Make it automatic. An inventory maintained by hand will drift, always. One generated from discovery, from your configuration management database, or from infrastructure-as-code state will not.
2. Joiner, mover and leaver records
The auditor picks a few people who joined, changed role, or left during the audit period, and traces what happened to their access.
Leavers are where this breaks. The specific question is: how long between the person leaving and their access being removed? If the answer is “we do it when HR tells us” and HR tells you weekly, you have a finding.
What you need is a record per identity showing what was granted, when, by whom, on what authority, and when it was removed.
3. Evidence of periodic access review
Not the policy saying reviews happen. The output of reviews that happened.
A defensible review record shows the date, who performed it, the scope, what was found, and what was changed as a result. A review that never removes any access is treated with suspicion. It suggests the review was a formality.
4. Change records for production systems
For a sample of production changes, the auditor wants to see what changed, who approved it, when, and what the rollback plan was.
This is where infrastructure-as-code and CI/CD pipelines pay for themselves at audit time. If production changes go through version control and a pipeline, your change record already exists: the commit, the reviewer, the approval, the deployment record and the diff. You are not producing evidence for the audit; you are exporting evidence you already had.
Organisations making changes by hand on servers have to reconstruct this from memory and ticket systems, which is expensive and frequently incomplete.
5. Vulnerability scan results with remediation tracking
Scanning is the easy half. The auditor’s real interest is what happened after the scan.
They will look for: scans running on a defined schedule; findings triaged by severity against a documented timeline; evidence that high-severity findings were remediated within it; and a documented, approved justification for anything accepted rather than fixed.
A scan history showing the same critical finding open for eight months is worse than not scanning, because it demonstrates you knew.
6. Backup restore test results
Backups running is not evidence that data can be recovered. Only a restore proves that.
The auditor wants dated restore test records showing what was restored, how long it took, whether it was complete, and what was done about anything that failed. NIST SP 800-34 makes the same point about contingency planning: an untested plan is an assumption.
This is also the control most likely to produce a genuine surprise the first time it is tested properly.
7. Log retention proof
You will be asked whether logs are retained for your stated period, and whether they are protected from tampering by the people they record.
The awkward follow-up: can an administrator delete the logs of their own activity? If yes, the logs are not evidence about administrators. Forwarding to write-once or append-only storage outside the administrator’s control is the usual answer.
The instrumentation that produces all seven
Almost everything above falls out of the same set of infrastructure decisions:
- None of these
- is a compliance tool
- The evidence
- is a side effect of running the estate well
- Which is why
- it does not stop the moment the audit ends
This diagram as text
- Ordinary infrastructure practice
- Infrastructure as code, with pipelines
- Centralised identity with provisioning
- Append-only log aggregation
- Scheduled scanning, tickets integrated
- Automated restore testing
- Automated discovery
- What an auditor samples
- Change records, approvals, rollback plans
- Joiner, mover and leaver records
- Retention proof and incident timelines
- Scan history with remediation in one trail
- Dated restore results, with a duration
- An inventory that cannot drift silently
Relationships
- Infrastructure as code, with pipelines → Change records, approvals, rollback plans
- Centralised identity with provisioning → Joiner, mover and leaver records
- Append-only log aggregation → Retention proof and incident timelines
- Scheduled scanning, tickets integrated → Scan history with remediation in one trail
- Automated restore testing → Dated restore results, with a duration
- Automated discovery → An inventory that cannot drift silently
Notice that none of these are compliance tools. They are ordinary good infrastructure practice. The evidence is a side effect, which is exactly the position you want to be in, because evidence produced specifically for an auditor is expensive, resented, and stops the moment the audit ends.
Two things that are not about technology
Scope. Getting scope wrong is the most expensive early mistake. Too broad and you are securing and evidencing systems that did not need to be in scope. Too narrow and the certificate does not cover what your customers are asking about, which defeats the purpose. Decide scope against what your customers and regulators actually need to see.
Time. Most first certifications are not limited by remediation speed. They are limited by the requirement for controls to have operated long enough to be sampled. You cannot compress that by working harder, only by starting earlier. Anyone promising certification in a few weeks from a cold start is describing something other than a real audit.
A realistic sequence
- Gap assessment: establish honestly what exists against the standard
- Scope decision: what the certificate needs to cover, and why
- Remediation, ordered by audit risk rather than by ease
- Instrumentation: make evidence a by-product, per the table above
- Operating period: let controls run and accumulate records
- Internal audit: find your own findings before an auditor does
- Certification audit: Stage 1 documentation review, then Stage 2 evidence sampling
Step 6 is the one most often skipped and the one with the best return. An internal audit that finds five issues is five findings you get to fix quietly.
Where STP fits
We are explicit about this: STP is not ISO 27001 certified. We implement, audit and document infrastructure so that our clients can achieve and maintain certification, and our own internal practice is aligned with the standard. We will never display a badge we have not earned. See our trust centre for our exact position.
What we do is the infrastructure side of the list above: gap assessment, remediation prioritised by audit risk, evidence automation, and sitting with your auditor during the control walkthrough.
More on audit and compliance enablement, or start a conversation.