ISO 27001 without the screenshot scramble: running an ISMS that can prove itself

ISO 27001 certification does not end when the certificate is issued. The standard operates on a three-year certification cycle, with surveillance audits typically in year one and year two and a full recertification audit at year three. The ISMS a company builds to earn the certificate has to keep running — not as a documented structure, but as an operating system with evidence to show for it. Clause 9 of ISO 27001 requires performance evaluation: measurement, analysis, and internal audit. The question the standard keeps asking is not "did you design this correctly" but "can you prove it is working."

The honest answer, for most organizations that have passed their initial certification, is that they cannot answer that question at any given moment. Evidence exists in scattered forms — last year's internal audit report, a folder of screenshots from the most recent surveillance visit, a spreadsheet that someone updated before the auditor arrived. Between visits, the ISMS runs largely on good faith. Controls are assumed to be operating until the next audit requires proof.

This article covers the specific ways that evidence decays between surveillance visits, where the proof of Annex A control operation actually lives, and what changes when an organization maintains a continuous, independently held record across the systems its ISMS governs.

01 / The surveillance cycle and why evidence decays

A typical certification timeline looks like this: year zero is the Stage 1 and Stage 2 certification audit, which results in the certificate. Year one is a surveillance audit, usually a partial scope review covering selected controls and any nonconformities flagged at certification. Year two is a second surveillance audit with a similar scope. Year three is recertification — a full audit against the current standard.

The gap between audits creates a decay problem. Controls that were documented and demonstrably operating at certification are not static. People leave and their access is not always revoked promptly. Supplier agreements expire or are renegotiated without a formal information security review. Device management policies are updated by an IT team that does not coordinate with the compliance function. Configuration changes in AWS or Google Workspace are made to solve operational problems without a corresponding update to the ISMS risk register.

None of this represents bad faith. Organizations change. Technology stacks change. The people who ran the ISMS at certification are not always the ones running it at the year-two surveillance visit. What was true at Stage 2 drifts. The evidence that the auditor reviewed during certification does not describe the ISMS that exists eighteen months later.

The surveillance audit reveals this drift through spot checks. An auditor asks for evidence of a specific Annex A control and the team must retrieve it from wherever it currently lives — if it can be retrieved at all. Log retention policies may have deleted the relevant records. The person who owned the process may have left. The answer to "can you show me evidence of this control operating over the past twelve months" becomes a weekend project rather than a pull of the existing record.

02 / Mapping Annex A controls to where they actually operate

Annex A of ISO 27001 (aligned to ISO 27002 as a reference set of controls) covers access control, cryptography, physical security, operations security, supplier relationships, and information security incident management, among other domains. Many of these controls are documented in policy. The policy is not the evidence of operation. The evidence of operation lives in the systems where the controls actually run.

Access control (Annex A 5.15 through 5.18 in the 2022 edition) is administered in the identity provider. Okta, Azure Active Directory, Google Workspace — these are the systems where user provisioning, access rights management, and authentication requirements are enforced. The access control policy says what should happen. The identity provider log shows what did happen. Any assessment of whether access was reviewed, whether privileged access was controlled, whether user registration and deregistration processes ran correctly, requires reading the identity provider record.

Asset management controls require knowing what devices exist, what software is installed, and what configuration baselines are maintained. That record lives in device management tools — Microsoft Intune, Jamf, or similar. It is not a spreadsheet maintained by the IT manager. It is a system of record that logs enrollment, policy application, and configuration state continuously. Supplier security controls (Annex A 5.19 through 5.22) exist in the contract and vendor management workflows a company actually uses — not in a separate GRC module but in the procurement process, the legal repository, and the ticketing system that tracks vendor reviews.

The ISMS is not the binder. The ISMS is the set of systems, people, and processes governing information security — and the evidence that they operated is generated by those systems, not assembled after the fact.

Operations security — patch management, malware controls, backup verification — lives in vulnerability management platforms, endpoint protection tools, and infrastructure logs. Cloud infrastructure logs in AWS CloudTrail or Google Cloud Audit Logs record every administrative action taken against the environment. These are not supplementary evidence sources. They are the primary record of whether the controls ran.

03 / The internal audit burden on small compliance teams

Clause 9.2 of ISO 27001 requires internal audits at planned intervals. The standard does not specify frequency, but certification bodies typically expect at least an annual internal audit. For a small or mid-market compliance team — often one or two people with ISMS ownership on top of other responsibilities — the internal audit is a significant time commitment.

The problem is that internal auditors must gather evidence to assess the same controls the external auditor will review. If evidence collection requires pulling logs manually from each system, scheduling interviews with system owners, and assembling documentation across ten or fifteen platforms, the internal audit consumes weeks of effort. The effort is especially painful because it is largely repetitive: the same systems, the same controls, the same retrieval process, every year.

Small compliance teams face a further constraint. The people best positioned to audit a control are often the same people who operate it, which creates an independence problem. Using Bylaw's independently held record addresses both constraints. The internal auditor queries the record rather than the source systems. The record is held outside the team that operates the controls, so it provides a degree of independence that self-assembled documentation cannot. The internal audit becomes a structured review of what the record shows, not a project to build the record before reviewing it.

04 / Continuous collection and what surveillance audits become

When a company maintains a continuous evidence record across the systems its ISMS governs, the surveillance audit changes in character. The auditor arrives with questions. The company answers with a pull of the record for the relevant period. The question "can you show me evidence that privileged access was reviewed over the past twelve months" is answered with the full-year log from the identity provider, structured and retained independently, not with a spreadsheet prepared for the visit.

The auditor can examine a complete record rather than a curated sample. Gaps in control operation are visible rather than hidden by the selection of evidence. A company that finds gaps in its own continuous record before the surveillance audit has the opportunity to address them — not to hide them, but to document remediation and show that the ISMS responded. That is exactly what the standard expects: a management system that detects and corrects nonconformities, not one that presents only favorable evidence.

The recertification audit at year three follows the same logic. Three years of continuous evidence means three years of demonstrable ISMS operation. The auditor is not relying on snapshots taken in the weeks before the visit. The record covers the full certification cycle. Clause 9 performance evaluation requirements are answered by the record, not constructed to answer them.

05 / The data-possession question

One concern that surfaces when organizations consider continuous evidence collection is what data moves. The worry is that a system monitoring Okta, Microsoft 365, Salesforce, and AWS must be ingesting and storing sensitive business data to do its work. That concern is worth examining directly.

Proving that an access control operated does not require possessing the data that access control protects. Proving that Salesforce permission sets were reviewed quarterly does not require exporting customer records. Proving that Microsoft 365 conditional access policies enforced MFA does not require reading email contents. The evidence of control operation is administrative and structural: log entries recording what actions were taken, configuration states recording what policies were in force, approval records documenting who reviewed what and when.

This is the governance layer. It is distinct from the data layer — the customer records, employee files, and transaction histories that the controls protect. A correctly scoped evidence system collects from the governance layer only. It governs the systems a company runs without touching the information those systems handle.

Bylaw governs the systems companies already run — Salesforce, Microsoft 365, Google Workspace, AWS, Okta — and collects the evidence those systems generate at the governance layer. The underlying business data never moves. The scope is the record of how controls operated, not the data that controls protected. That boundary is not incidental. It is the correct scope of what ISMS evidence requires.

06 / What the ISMS looks like when it can prove itself

An ISMS that can prove itself is not one that performs well on audit day. It is one that operates demonstrably, continuously, across the systems it governs — and whose operation is recorded in a form the organization can rely on at any point in the certification cycle. Clause 9 requires this. Surveillance audits test for it. Recertification assumes three years of it.

The practical shape of that ISMS is one where evidence collection is not a project that precedes audits but a continuous function that runs alongside operations. The identity provider logs are retained and structured. The device management records are held independently. The supplier review workflow creates a durable record as it runs. When the internal audit is scheduled, the auditor queries the record. When the surveillance visit arrives, the company answers with the record. When the enterprise prospect sends a security questionnaire, the compliance team answers from documented evidence rather than constructing a response from memory.

ISO 27001 describes an information security management system — a system, not a document set, not an annual audit exercise, not a folder of screenshots. The organizations that treat it as a system, and keep the evidence that proves the system ran, are the ones that find surveillance audits straightforward and recertification credible. The ones that treat it as a documentation exercise rediscover the same decay problem at every audit visit, and spend the weeks before each one reconstructing what should already be there.