An auditor opens an ISMS documentation package. Within ninety seconds — frequently less — they have made a determination about the maturity of the organisation in front of them. They are not making this determination because they have read every policy, walked every control, or assessed every piece of evidence. They are making it because they have learned, over hundreds of audits, what mature ISMS documentation looks like. The packages that produce evidence look one way. The packages that produce frameworks look another. The distinction is consequential, and it is visible immediately.
This is the central problem with how most organisations approach ISO 27001 implementation. They invest substantial effort, often over many months, in producing documentation that satisfies the literal requirements of the standard. They draft policies. They populate Statements of Applicability. They author control narratives. They assemble evidence packages. They achieve certification. And then, when the next surveillance audit arrives, they discover that the work they did was never going to be sustainable, because they built a framework rather than an evidence-producing system.
The distinction matters because ISO 27001 is not, fundamentally, a documentation standard. It is a management system standard. The documentation is the visible artefact of an underlying operational reality — and auditors, increasingly, are trained to assess that reality through the documentation rather than the other way around.
Frameworks versus evidence systems
A framework is a static description of what the organisation intends to do. It says: we will manage access. We will assess risk. We will respond to incidents. It is written in the future tense or the timeless present, and it is structurally indistinguishable from the framework that any other organisation in the same sector might produce. Frameworks are necessary. ISO 27001 requires them. But frameworks are not evidence.
An evidence system, by contrast, is a living arrangement that produces a continuous record of what the organisation actually does. It says: here is what happened. Here is who did it. Here is when. Here is what they decided. Here is the artefact they generated. Evidence systems are dynamic. They are populated by operational activity, not by documentation exercises. And — critically — they are what auditors actually want to see.
The shift from framework to evidence system is the single most important architectural decision in any ISMS implementation. Organisations that make it explicitly tend to succeed. Organisations that do not make it — that drift between the two postures, or that assume the framework will somehow generate evidence on its own — produce ISMS implementations that pass initial certification, struggle with surveillance audits, and collapse under the first material incident or scope expansion.
What auditors actually look for
To understand why frameworks fail and evidence systems succeed, it helps to understand what experienced auditors actually do when they assess an ISMS. They are not, despite the impression sometimes given, working through a checklist of requirements. They are looking for three things, in roughly this order.
The traceability test
The first thing an auditor tests is whether the documentation traces from policy to control to evidence in a coherent way. Given a control listed as applicable in the SoA, can they find the policy that establishes it, the procedure that operationalises it, the records that demonstrate it has been performed, and the metrics that demonstrate it is effective? If the trace breaks — and in immature implementations, it almost always breaks — the auditor's confidence in the entire system drops sharply.
This test reveals whether the organisation has built an integrated documentation architecture or merely assembled a collection of documents. The difference is structural. Integrated architectures use consistent identifiers, version control, and explicit cross-references. Collections of documents use whatever conventions each author preferred at the time of writing. Auditors can tell the difference at a glance, and they make inferences about the rest of the system on the basis of that signal.
The recency test
The second thing auditors test is whether the documentation reflects the current state of the organisation. They will pick a recent change — a new system, a recent incident, a known organisational restructuring — and look for the documentation that should have been generated by it. If the documentation is missing, or is dated before the change, or contains inconsistencies that reveal it has not been updated, the auditor concludes that the ISMS is not functioning as a management system.
This test is brutal because it is unfakeable. An organisation can spend months preparing for a certification audit, polishing every artefact into pristine condition. But the surveillance audit comes a year later, and by then the organisation has either continued to maintain the documentation as part of its operational rhythm — in which case the recency test passes — or it has not, in which case the test fails and the auditor's findings escalate accordingly.
"Most ISMS implementations produce frameworks. Few produce evidence. The distinction matters — and auditors know it the moment they open your documentation package."
The consistency test
The third thing auditors test is whether the documentation is internally consistent. If the access control policy says one thing and the access control procedure says something different, that is a finding. If the SoA marks a control as applicable but the risk treatment plan does not address it, that is a finding. If incident response records show one classification scheme and the incident response policy uses another, that is a finding.
The consistency test reveals whether the organisation maintains its documentation as a coherent system or as a collection of artefacts owned by different people who do not coordinate. Mature organisations have governance structures that prevent inconsistency — content review processes, change-control workflows, central editorial ownership. Immature organisations do not, and the inconsistencies accumulate over time until the documentation no longer represents anything coherent.
The architectural choice
What separates evidence-producing ISMS implementations from framework-producing ones is, primarily, an architectural choice made early in the implementation. Mature organisations make this choice deliberately. Immature organisations drift into a default architecture that almost guarantees failure.
The default architecture, which produces frameworks, has these characteristics:
- Policies, procedures, and records are stored in different systems, often with different access controls and different ownership.
- The Statement of Applicability is maintained as a spreadsheet or a Word document, separately from the policies it references.
- Risk assessments are produced as point-in-time exercises, with limited automated linkage to changes in the operational environment.
- Evidence is collected reactively, when an audit is scheduled, rather than continuously as a by-product of operations.
- Control implementation is described in narrative form, with limited use of structured data or automated testing.
The mature architecture, which produces evidence systems, has these characteristics instead:
- Single-source structured authoring. Policies, procedures, the SoA, and supporting records share a common authoring environment with explicit cross-referencing, version control, and consistent metadata.
- Living risk registers. Risks are tied to assets, controls, and treatments through structured links that update as the operational environment changes.
- Continuous evidence capture. Evidence is generated as a by-product of normal operations, captured in tamper-evident storage, and indexed for retrieval at audit time.
- Automated control testing. Where controls can be tested automatically — and an increasing proportion can be — automated testing produces evidence on a schedule rather than on demand.
- Editorial governance. A central function is responsible for the consistency and quality of the documentation as a whole, not just the individual contributions.
Why most implementations default to frameworks
Given that the architectural difference is consequential, and given that the mature architecture is well-understood, why do most ISMS implementations default to producing frameworks? The answer is partly cultural, partly economic, and partly tactical.
Culturally, most organisations approach ISO 27001 as a certification exercise rather than a management system implementation. The goal is to get certified. The certification body is the audience. Once the certificate is in hand, attention drifts to the next priority. This cultural framing produces frameworks because frameworks are sufficient to achieve certification.
Economically, the mature architecture is more expensive to build initially. Single-source structured authoring requires tooling. Continuous evidence capture requires integration. Editorial governance requires headcount. Organisations operating under cost pressure rationally choose the cheaper option — until they discover, in the second or third year, that the cheaper option requires the same expensive rebuild every time the surveillance audit reveals a gap.
Tactically, the framework approach is faster to implement. An organisation that needs certification within six months for a customer contract will produce a framework, because that is what can be produced in six months. The mature architecture takes longer, sometimes substantially longer. The trade-off is real, but it is rarely made deliberately. Organisations that make it deliberately can plan for the post-certification rebuild. Organisations that drift into the framework approach typically do not.
The path forward
For organisations facing initial ISO 27001 implementation, the recommendation is straightforward: invest in the architecture early. The marginal cost of building the right architecture during initial implementation is far lower than the cost of rebuilding it after certification. Use structured authoring tools. Establish editorial governance. Build evidence capture into operational systems. Treat the SoA as a live document, not a one-time artefact.
For organisations that have already certified under a framework approach, the recommendation is more nuanced. Wholesale rebuilds are rarely the right answer — the disruption cost is too high, and the surveillance audit cycle does not always permit it. The right approach is generally to identify the highest-leverage transition points (a major surveillance audit, a scope expansion, a re-certification cycle) and use those as opportunities to migrate progressively from framework to evidence system.
What does not work is continuing to maintain a framework-architecture ISMS while pretending it is an evidence system. The auditors will see through it. They always do. And the consequences — major findings, certification at risk, customer audits that escalate to contract risk — are not theoretical. They are documented in the case histories of every certification body operating in this space.
ISO 27001 is, in the end, a useful standard. It compresses decades of information security practice into a coherent management framework. It is internationally recognised. It is reasonable in its expectations. It is achievable. But achieving it in a way that produces durable value — rather than a certificate that hangs on the wall while the underlying reality decays — requires a deliberate architectural choice, made early and resourced appropriately. That choice, more than any other, determines whether the organisation has built a framework or an evidence system. And that distinction, more than any other, is what the auditor sees.