The expensive part of ISO 27001 is not the certification. It is year two.
The project has a budget, a deadline and attention. Then the certificate arrives, the project team disperses, and twelve months later someone realises the surveillance audit is in six weeks and nobody has collected anything since the last one. What follows is a scramble: screenshots, exported spreadsheets, chased approvals, and a week of senior time spent proving that things which were true all year were in fact true.
That scramble is not a discipline problem. It is a design problem. The system was built to be audited once.
The pattern that causes it
Most ISMS documentation describes controls in terms of human behaviour. "Access rights are reviewed quarterly." "Changes are approved before deployment." "Backups are tested annually."
Each of those is a promise that someone will do something and then find a way to prove it afterwards. The proof is manufactured at audit time from systems that were never asked to keep it: a screenshot of a ticket, a CSV export, an email thread. It is genuine, and it is enormously expensive per control.
The alternative is to state the control in terms of a check that a machine performs and records.
Restating controls as checks
Take three common ones.
Access review. Instead of "access rights are reviewed quarterly", run a scheduled job that exports group membership and privileged role assignments, opens a ticket per owner, and records the response. The evidence is the job's output and the closed tickets, timestamped, generated whether or not anyone remembers the audit.
Change approval. Instead of a change advisory board and its minutes, require approval in the pull request, protect the branch so it cannot be merged without one, and generate a deployment record from the pipeline linking commit, approver, test result and deployment time. The auditor's sample of ten changes is a query, not a search.
Backup testing. Instead of an annual exercise written up in a document, schedule an automated restore into an isolated environment, assert on the restored data, and publish the measured recovery time. Your RTO becomes a number you observed rather than one you hope for.
In each case the control did not get weaker. It got continuous, and it started producing its own record.
What this looks like in practice
The implementation is less exotic than the name suggests.
A control-to-check mapping. One table: control reference, what proves it, where that proof comes from, how often, who owns it. Building this honestly is the real work, and it usually reveals that a third of your controls are already evidenced automatically and nobody had noticed.
Policy as code in the pipeline. Infrastructure that violates a rule fails the pull request. Encryption at rest, network exposure, logging enabled, tagging for ownership — these are decidable, and deciding them before deployment is both cheaper and better evidence than detecting them afterwards.
Continuous posture monitoring. Cloud posture tooling reporting against your control framework rather than against the vendor's default benchmark. The output is not "142 findings"; it is "control A.8.9 is satisfied across 47 of 48 accounts, with the exception documented and dated".
An evidence store with retention. Somewhere the artefacts land automatically, with a timestamp, kept for the retention period the standard requires. Object storage with versioning is enough; it does not need to be a product.
Exception handling that is part of the system. Every real environment has exceptions. A control framework with no exception process produces either dishonest evidence or paralysis. Make exceptions explicit: who approved, why, until when, and what compensates.
What it does not cover
Being honest about the limits matters, because oversold automation is how this becomes a disappointment.
Roughly sixty to seventy per cent of Annex A controls in a cloud-native organisation can be evidenced automatically. The rest are human and will stay human: supplier due diligence, management review, awareness training, physical security, HR screening, incident lessons learned. Those need a calendar, an owner and a document.
The aim is not to eliminate manual evidence. It is to stop spending your scarce manual effort on the sixty per cent that a machine could have recorded, so that there is time left for the forty per cent that genuinely requires judgement.
The second benefit: every other framework
The reason we push this harder than ISO 27001 alone would justify is reuse.
A firm with an ISO 27001 certificate, a SOC 2 report, NIS2 obligations and a GDPR register is answering four sets of questions that overlap by roughly seventy per cent. Access control, change management, logging, backup, supplier management and incident response appear in all four, in different words.
If the evidence is produced by a check rather than by a person, adding the second framework costs the mapping and almost nothing else. The same restore test evidences ISO 27001 Annex A.8.13, SOC 2 availability criteria, the NIS2 continuity measure and your DORA resilience testing obligation. Produced once, filed once, cited four times.
That is where the compounding is, and it is why we treat the control framework as an engineering artefact rather than a document.
Where to start, if you already have the certificate
Do not attempt the whole framework. Take the ten controls that cost you the most evidence-gathering time last audit — your team will name them without hesitation — and convert those. Measure the time saved. Use the measurement to fund the next ten.
A first pass of two to three weeks typically converts the worst offenders and cuts audit preparation from weeks to days. That is a small enough piece of work to do between audits, which is precisely when it has to happen: nobody rebuilds their evidence pipeline six weeks before a surveillance audit.
The certificate on the wall is a claim about how you operate. Compliance as code is what makes the claim continuously true, at a cost you can keep paying.