ISO 27001: the ISMS, Annex A, and the certification cycle

What an ISMS actually is

ISO/IEC 27001 is a management-system standard, not a control checklist. The certifiable requirements live in clauses 4 through 10: understand the organization's context, secure leadership commitment, plan around a risk assessment, resource and document the system, operate it, measure it, and improve it. An organization certifies its information security management system — the ongoing machinery of risk decisions, controls, internal audits, and management reviews — not a point-in-time configuration.

Annex A is a reference set of controls, not a mandate. Clause 6.1.3 requires you to determine the controls your risk treatment actually needs, then compare that list against Annex A to check nothing necessary was missed. The output is the Statement of Applicability. This is the part teams most often get backwards: the risk assessment drives the controls, and Annex A is the completeness check — not the other way around.

Two clause-level obligations shape day-to-day operation more than any single control: internal audits of the ISMS at planned intervals, and management review of its continuing suitability and effectiveness. A certification body will test both, because they are what make the system self-correcting.

The 2022 revision and the four Annex A themes

ISO/IEC 27001:2022 replaced the 2013 edition and restructured Annex A. The 2013 catalog of 114 controls across 14 domains was consolidated into 93 controls organized under four themes, with 11 controls that are new rather than merged — including threat intelligence, information security for use of cloud services, ICT readiness for business continuity, configuration management, data leakage prevention, and secure coding. Under the IAF transition arrangements, accredited certificates against the 2013 edition expired by 31 October 2025, so new and continuing certifications now run against the 2022 edition.

The themes matter operationally because they change who owns evidence. Technological controls pull from your cloud and code platforms; organizational controls pull from policies, registers, and supplier records; people and physical controls pull from HR and facilities processes. A program that treats Annex A as one undifferentiated list ends up with one overloaded owner.

• Organizational (37 controls): policies, asset management, supplier relationships, incident management, legal and contractual requirements.
• People (8 controls): screening, terms of employment, awareness and training, disciplinary process, remote working.
• Physical (14 controls): secure areas, equipment, media, physical entry, and physical security monitoring.
• Technological (34 controls): access control mechanics, cryptography, logging and monitoring, configuration, development security, and network controls.

Certification, surveillance, and the Statement of Applicability

Certification runs on a three-year cycle. The initial audit comes in two stages: stage 1 reviews your documentation and readiness — scope, risk methodology, SoA, mandatory clause records — and stage 2 tests whether the ISMS actually operates as documented. Pass both and the certificate is issued for three years, with surveillance audits in years one and two that sample parts of the system, and a full recertification audit in year three.

The Statement of Applicability is the document auditors read first. Clause 6.1.3 requires it to list the necessary controls, justify their inclusion, justify the exclusion of any Annex A control, and state implementation status. It is meant to be a living reconciliation between your risk register and your control set — and it decays fastest of any ISMS artifact, because every new system, vendor, or architectural change shifts which controls are necessary and whether they are implemented.

The practical failure mode is an SoA maintained as a spreadsheet, updated in the weeks before each audit, asserting implementation statuses nobody has verified since the last one. When the auditor samples a control marked implemented and finds it drifted, the finding is not just about that control — it undermines confidence in the whole statement.

Continuous monitoring between audits

An ISMS is required to operate continuously; the audit only samples it annually. Clause 9 obliges you to monitor and measure the system regardless of when the certification body shows up. The gap between those two facts is where programs quietly fail: controls that operated at stage 2 drift for months, and the drift surfaces either at surveillance or — worse — in an incident.

Closing that gap is what continuous control monitoring is for. Rather than re-collecting screenshots before each audit, mature programs pull evidence directly and read-only from the systems that already hold it — source control, cloud providers, identity, and observability tooling — so the state behind a technological control reflects reality rather than a moment months ago. Good practice anchors each artifact with a timestamp and an integrity hash, re-checks it on a schedule, and records that a named person reviewed and accepted it on an append-only trail. The discipline that matters most: a passing automated test should inform a control's status, never silently satisfy it — a human still owns the judgment that the control operates.

What good looks like, and how to evaluate any tool

Many compliance dashboards will show a readiness percentage even when the underlying data is missing — an estimated number that fails exactly when an auditor tests it. A more defensible model treats a control as met only when current evidence supports it and a named person has accepted that evidence; anything unevidenced stays a visible gap, and anything the tooling genuinely cannot measure is reported as unmeasured rather than guessed. A Statement of Applicability built on that discipline states implementation statuses you can defend in a stage 2 audit.

One boundary is worth stating plainly: no tool certifies you. Only an accredited certification body can issue an ISO 27001 certificate, and the audit opinion is theirs to give. Software's role is to make that opinion cheaper to reach and easier to keep. Whatever platform you evaluate, hold it to the failure modes that actually cost ISO programs:

• Can it show where each piece of evidence came from, when, and who accepted it — or is provenance just a filename convention?
• Does it distinguish a control that exists on paper from one that demonstrably operates?
• Are implementation statuses backed by current evidence, or asserted once a year before the audit?
• Does risk acceptance record who accepted the risk and when, in a form that survives personnel change?
• Can your certification body independently verify an evidence export, or must they trust the tool?
• Does it tell you what it cannot measure — or does every dashboard read green?

Frequently asked questions