The Information Security
Management System, Run

01What it is

ISO/IEC 27001 is the requirements standard for an information security management system — an ISMS. It is the document an accredited body certifies you against, and the one procurement teams mean when they ask whether you are “ISO certified” for security.

It does not tell you which firewall to buy. It tells you how to run an organisation that decides, deliberately and repeatably, what information it holds, what could go wrong with its confidentiality, integrity and availability, which of those risks it will treat and how, and how it checks that the treatment is working. The controls are an output of that reasoning, not its starting point.

The standard has two halves that behave very differently:

• Clauses 4 to 10 are the management system. Every one of them applies; none can be excluded. They use the harmonized structure — the common skeleton shared with ISO 9001, ISO 14001, ISO/IEC 42001 and the rest — so the clause numbers and titles will be familiar to anyone who has run another management system.
• Annex A is a reference list of 93 information security controls in four themes. It is normative, but you do not “implement Annex A”. You determine the controls your risk treatment needs, then compare that set against Annex A to check nothing has been overlooked, and record the outcome in the Statement of Applicability.

What it is not

The real test is the same as in any management system: when a control fails or a risk changes, does anything happen? A certificate does not say your organisation is secure. It says that, within a stated scope, a system for managing information security risk was operating and being improved when the auditor looked.

02The 2022 edition and Amendment 1:2024

The third edition was published in October 2022. The clauses moved a short distance; Annex A was rebuilt. Sixteen months later an amendment added climate change to the context clauses.

What Amendment 1 actually asks

In 4.1 the organisation must now decide whether climate change is a relevant issue for it. In 4.2 a note points out that interested parties can have requirements related to climate change. That is the whole amendment.

It is small, and it is routinely mishandled in both directions. It does not require a climate strategy, a carbon figure or an environmental management system. It does require a determination — a recorded decision, with reasoning, that climate change is or is not relevant to the ISMS's intended outcomes. For most organisations the honest answer is “relevant, at the edges”: physical risks to sites and data centres (flood, heat, power), supply chain disruption, and customers or regulators asking for climate disclosures that touch the information you hold.

03From 2013 to 2022

The transition period ended on 31 October 2025. Certificates to ISO/IEC 27001:2013 are no longer valid; anyone still holding one is uncertified.

The accreditation rules gave three years from publication. New certifications to the 2013 edition stopped in 2023, and every remaining 2013 certificate had to be transitioned — usually at a surveillance or recertification audit with extra time added — before the deadline. If you are reading this after a lapse, you are not transitioning; you are certifying from scratch against the 2022 edition, Stage 1 and all.

What changed in the clauses

What changed in Annex A

• 93 controls in 4 themes — organizational (37), people (8), physical (14), technological (34) — replacing 114 controls in 14 domains. Annex A no longer carries control objectives; the purpose of each control lives in 27002.
• Eleven new controls: threat intelligence (A.5.7), information security for use of cloud services (A.5.23), ICT readiness for business continuity (A.5.30), physical security monitoring (A.7.4), configuration management (A.8.9), information deletion (A.8.10), data masking (A.8.11), data leakage prevention (A.8.12), monitoring activities (A.8.16), web filtering (A.8.23) and secure coding (A.8.28). They are flagged New 2022 in the tables below.
• Consolidation, not deletion. The commonly cited tally is that 57 of the 2013 controls were merged into 24; the rest carried across, many renamed. Almost nothing of substance disappeared, but the SoA had to be rebuilt row by row because the references all changed.
• Attributes. 27002:2022 tags each control with control type (preventive, detective, corrective), information security properties (confidentiality, integrity, availability), cybersecurity concepts (identify, protect, detect, respond, recover), operational capabilities and security domains. None of this is required by 27001, but it makes filtering the catalogue — and explaining coverage to a board — much easier.

04Document map

Ten clauses and one annex. Clauses 4 to 10 are what you are certified against. Annex A is the control reference list. The bibliography points at 27002 for how to implement each control.

Three neighbouring documents are worth having to hand. ISO/IEC 27000 holds the vocabulary — “risk owner”, “information security event” and the rest are defined there. ISO/IEC 27002:2022 gives the purpose and implementation guidance for every Annex A control. ISO/IEC 27005:2022 is guidance on information security risk management and is the most useful thing to read before designing a 6.1.2 method.

05How certification works

Two audits to get the certificate, then a surveillance audit every year and a recertification every three. Stage 1 asks whether the ISMS is documented and coherent. Stage 2 asks whether it is actually being run. They fail for different reasons, which is why it pays to measure readiness for each separately.

Scope comes first

The certificate states a scope, and every audit is planned against it: organisational units, locations, services, and the information and systems behind them. The certification body uses it — along with headcount and complexity, under the rules in ISO/IEC 27006-1 — to set the number of audit days. A scope that is vague (“the IT department”) or cosmetic (one product line of many) costs you twice: at the audit, when the auditor cannot tell what is in, and with customers, who read the certificate as a claim.

1. Choose an accredited certification body

   Check that the body is accredited for ISO/IEC 27001 by a recognised national accreditation body, and that the certificate will carry the accreditation mark. Unaccredited certificates exist and are widely rejected in procurement.

2. Stage 1 — documentation and readiness

   Often partly remote. The auditor reads the scope, the context analysis, the policy, the risk assessment and treatment methods and their results, the SoA, the objectives, and evidence that an internal audit and a management review have taken place. The question is whether the system is designed to conform and whether you are ready for Stage 2. The output is a report listing areas of concern, any of which could become a nonconformity at Stage 2.

3. Close the Stage 1 concerns

   Usually a few weeks. The gap between the stages is set by the certification body; leave enough to fix what was raised and to accumulate a little more operating evidence.

4. Stage 2 — implementation and effectiveness

   On site or hybrid, and the bulk of the audit days. The auditor samples controls from the SoA, follows a risk from the register to its control to the evidence that the control operates, interviews people outside the security team, and tests the loop: monitoring results, internal audit findings, management review decisions, corrective actions closed with root cause. Findings are graded.

5. Certification decision

   Made by the certification body, not by the auditor in the room, after any major nonconformities have been corrected and the corrective action plans for minors accepted. The certificate runs for three years.

6. Surveillance, then recertification

   At least one surveillance audit a year — the first within twelve months of the certification decision — each covering a portion of the controls plus the core loop: internal audit, management review, corrective action, changes. A recertification audit before the third anniversary re-examines the whole system.

How findings are graded

Grading terms vary a little between certification bodies, but the shape is consistent and set by the accreditation rules they work to (ISO/IEC 17021-1).

06Clause 4 — Context of the organization

Each clause below gives a paraphrase of what it requires, what an auditor will ask to see, and what thin evidence looks like — the version that gets a finding.

07Clause 5 — Leadership

08Clause 6 — Planning

The engine room. Most Stage 1 findings, and most of the expensive Stage 2 ones, trace back to here. The risk clauses get a fuller treatment in Risk assessment in depth and Risk treatment and acceptance.

09Clause 7 — Support

10Clause 8 — Operation

Clause 6 plans; clause 8 does. The pairing is deliberate — 8.2 and 8.3 are the evidence that 6.1.2 and 6.1.3 are not just designs.

11Clause 9 — Performance evaluation

12Clause 10 — Improvement

13Risk assessment in depth

Clause 6.1.2 fixes the properties a method must have, not the method. That freedom is why risk assessments vary so much in quality — and why auditors test the properties rather than the format.

Set the criteria before you score anything

The criteria are the part of the method most often missing and the part an auditor reads first. They are what makes results consistent, valid and comparable: two people scoring two similar risks should land in similar places, and this year's scores should mean the same as last year's.

Identify: asset-based or scenario-based

The 2013 edition dropped the requirement to identify risks by asset, threat and vulnerability. The requirement now is to identify risks to the confidentiality, integrity and availability of information within the scope. ISO/IEC 27005:2022 describes two ways to get there, and both are acceptable.

Many mature registers use scenarios for the main register and the asset inventory as the completeness check. Whichever you use, say so in the method — the auditor will test you against the method you wrote, not the one they prefer.

Risk owners are not asset owners

Each risk needs a risk owner: someone with the accountability and authority to manage it, including the authority to accept what remains. That is usually a business manager, not the security team. The asset owner (A.5.9) is responsible for an asset's day-to-day protection; the two can be the same person but often are not. A register where every risk is owned by the CISO tells the auditor that nobody with budget has accepted anything.

Analyse and evaluate

Analysis applies the scales: consequence if it happens, likelihood of it happening, resulting level — stating whether existing controls are taken into account, and doing that consistently. Evaluation compares the level against the acceptance criteria and sets the order in which risks get treated. Keep the reasoning short but present: one sentence per score explaining why is what makes a result reproducible.

14Risk treatment and acceptance

Clause 6.1.3 turns the evaluated register into decisions: what you will do about each risk, which controls that needs, and who accepts what is left.

Treatment options

Determine controls, then compare with Annex A

The order matters and is often reversed. You first determine all the controls needed to implement the chosen treatment — they can come from anywhere: Annex A, 27002, an industry framework, or your own design. Then you compare that set against Annex A to check that nothing necessary has been missed. Annex A is a cross-check, not a menu; the standard is explicit that it is not exhaustive and that you may need controls beyond it.

In practice the comparison is a pass down the 93 controls asking, for each one not already in your set: does any risk in the register need this? If yes, you missed it — add it. If no, record why it is not needed. That pass is what produces the exclusion justifications in the SoA.

The risk treatment plan

The plan says how the selected controls that are not yet in place will get there. Treat it like an objective plan under 6.2: for each action, what will be done, the resources, the owner, the due date and how completion will be checked. A plan with no dates is a wish list; a plan whose dates have all passed unrevised is a Stage 2 finding under 8.3.

Approval and acceptance by risk owners

Risk owners approve the treatment plan and accept the residual risk — the level expected once the planned controls are in place. Make the record explicit: which risk, what residual level, accepted by whom, on what date, with what authority, until when. Where a residual risk sits above the acceptance criteria and the business still chooses to carry it, that acceptance needs to come from whoever your criteria say can accept that level — usually top management — and should be revisited at management review.

15The Statement of Applicability

The document an auditor spends longest on, and the one that appears by version number on many certificates. It is where risk assessment, control selection and reality have to reconcile.

Clause 6.1.3 sets the required content. Paraphrased, the SoA must contain the necessary controls, the justification for including them, whether each is implemented, and the justification for excluding any Annex A control. Every one of the 93 Annex A controls therefore appears as a row, plus any control you added from another source.

Excluding a control properly

Exclusions are justified by the absence of a risk or requirement, not by inconvenience. “A.8.30 Outsourced development — excluded: no software development is outsourced; all development is in-house under A.8.25–A.8.29; re-evaluated if a development contractor is engaged” is a justification. “A.7.4 not applicable” is not, particularly when the organisation has an office. Excluding a control does not exclude the risk: if you rely on a cloud provider's data-centre security instead of running your own physical controls, the justification should point to how that reliance is managed (A.5.19–A.5.23).

16Annex A — the 93 controls

Four themes, numbered to match ISO/IEC 27002:2022. The control references and short names below are the published ones; the notes and evidence lists are an implementation reading, not the control text.

The themes are a filing system, not an ownership model. A.5.15 access control is “organizational” because it is a rule; A.8.2–A.8.5 are “technological” because they implement it. Expect one process — joiners, movers and leavers, say — to evidence controls in three themes at once.

17A.5 — Organizational controls

Thirty-seven controls: the policies, rules, relationships and processes that frame everything else. The largest theme, and the one where suppliers, incidents, continuity and legal obligations live.

18A.6 — People controls

Eight controls covering the employment life cycle — before, during and after — plus remote working and the duty to report.

19A.7 — Physical controls

Fourteen controls for premises and equipment. Organisations that are fully remote or entirely cloud-hosted often exclude some of these; the justification has to say where physical protection is provided instead.

20A.8 — Technological controls

Thirty-four controls implemented largely in technology: endpoints, access, vulnerabilities, logging and monitoring, networks, cryptography and the secure development life cycle. Seven of the eleven new controls are here.

21What you actually have to write

The documented information an ISMS needs, grouped by clause. Items in bold are explicitly required by clauses 4–10; the rest are what the applicable controls and an auditor will reasonably expect. Proportion matters — a small organisation's version of most of these is a page.

22Running 27001 alongside ISO/IEC 42001

Both use the harmonized structure, so clauses 4, 5, 7, 9 and 10 line up almost word for word in their titles. An organisation with a working ISMS has most of an AI management system's skeleton already. What it does not have is the AI-specific substance.

Where one artefact serves both

• Context and interested parties (4.1, 4.2): one analysis and one register, with AI-specific issues and parties — including the people AI systems make decisions about — added alongside the security ones.
• Competence, awareness, communication, documented information control (7.2–7.5): one competence matrix with AI roles added, one document control procedure, one communication plan.
• Internal audit and management review (9.2, 9.3): one programme and one review, provided both standards' inputs are covered explicitly and the auditors are competent in both disciplines.
• Nonconformity and corrective action (10.2): one log, tagged by standard.
• Evidence: an access review, a supplier assessment or an incident record frequently evidences a control in each standard. File it once and link it twice.

Where they must stay separate

• Scope. The ISMS scope and the AIMS scope can differ, and usually do. Each certificate states its own.
• Policy. 42001 needs an AI policy; it can sit under the same governance as the security policy, and 42001 A.2.3 asks you to align the two, but an information security policy does not discharge it.
• Risk. The method and criteria can share a shape. The registers cannot be merged: 27001 assesses risk to confidentiality, integrity and availability of information; 42001 assesses AI risk to the organisation's objectives, and adds an AI system impact assessment (6.1.4, 8.4) for harm to individuals and society that has no 27001 counterpart at all.
• Statement of Applicability. Two SoAs against two different Annex As. The 42001 Annex A (38 controls) is not a subset or superset of 27001's 93.

Crosswalk — the most useful overlaps

The pairs below match the crosswalk carried in the ClairAIMS control catalogue. “Overlap” means one process or record can usually evidence both; it never means one control satisfies the other's wording automatically. See the 42001 guide for the AI controls themselves.

23Common Stage 1 and Stage 2 findings

The same few findings recur across organisations and certification bodies. Most are cheap to prevent and expensive to fix under a deadline.

At Stage 1 — the documentation does not hold together

At Stage 2 — the system is not running as written

24Pre-audit checklist

Work through this before booking each stage. The ticks are saved in this browser only.

Before Stage 1

• Scope written and approved, naming units, sites, services, interfaces and dependencies.Clause 4.3. Check it matches what the certification body quoted for.
• Context analysis current, with the climate change determination recorded.
• Interested parties register marks which requirements the ISMS addresses.
• Policy approved and communicated, containing both required commitments.
• Risk method documented with scales, acceptance criteria and triggers for reassessment.
• Risk register complete, every risk with an owner who has authority.
• SoA covers all 93 controls with justification and status, versioned and approved.Run the trace test on ten random rows.
• Treatment plan approved and residual risk accepted by the risk owners, on record.
• Objectives measurable, with owners and a first reading.
• One full internal audit and one management review completed, with records.

Before Stage 2

• Stage 1 concerns closed, with evidence for each.
• Every implemented SoA row has evidence linked — a record, not just a policy.
• At least one cycle of each recurring control has run: access review, supplier review, vulnerability reporting, backup restore test.
• Monitoring results exist over several periods, analysed, with at least one decision taken from them.
• Nonconformity log shows real entries with root cause and effectiveness review.An empty log after months of operation is itself a finding waiting to happen.
• Treatment plan up to date: done items evidenced, slipped items re-dated with a reason.
• Incident log and procedure agree — including events judged not to be incidents.
• Staff outside the security team briefed — not coached — and able to describe reporting and their own responsibilities.
• Top management ready to be interviewed on risks, objectives and review decisions.
• Licensed copy of ISO/IEC 27001:2022 with Amd 1:2024 held, and the controls read against it, not against a summary.

25Using this with ClairAIMS

ClairAIMS keeps a 27001 programme beside a 42001 one, and it is built around the same distinctions this guide draws.

• Readiness, two numbers. Stage 1 readiness measures whether the ISMS is documented and coherent — scope, policy, risk method, SoA justifications, objectives. Stage 2 readiness measures whether it is running — evidence linked, monitoring readings, internal audit, management review, corrective actions with effectiveness checks. They are reported separately on purpose: a high Stage 1 figure with a low Stage 2 one means the documents are ready and the system is not, so book Stage 1 and keep operating.
• The Statement of Applicability. All 93 controls as rows, each with applicability, justification and status. A row the app proposed counts only once a person has confirmed it — the auditor will ask who decided.
• The evidence vault. Upload a file once and link it to every reference it proves. An access review can evidence 27001 A.5.18 and a 42001 control in the same company without a second copy. A link is a person saying “this file proves that”, and it is what moves a row towards Stage 2.

26What it will not do

• It does not make you secure. It makes your management of security risk systematic and visible. A well-run ISMS around a poorly judged risk appetite produces excellent records of risks you chose to carry.
• It does not set a technical baseline. Annex A says what kind of control is expected, not how strong. The strength comes from your risk assessment and from 27002, sector rules and your customers.
• It does not make you compliant with a law. Not with data protection law, NIS2, DORA or any sectoral regime — though it builds the apparatus most of them assume, and A.5.31 makes you track them.
• It does not cover AI-specific risk or harm. That is ISO/IEC 42001's territory, and its impact assessment has no counterpart here.
• A certificate is not a rating. It says an ISMS meeting the requirements was operating within a stated scope at a point in time. Read the scope, and ask for the SoA.

27Sources

• ISO catalogue entry — ISO/IEC 27001:2022, and the ISO Online Browsing Platform preview: foreword, introduction, scope and clause titles are publicly viewable. Clauses 4–10 and Annex A text are not.
• ISO/IEC 27001:2022/Amd 1:2024 — Climate action changes, as announced by ISO with the parallel amendments to its other management system standards.
• ISO/IEC 27002:2022 — control names, numbering, themes and attributes, as shown in its public preview.
• ISO/IEC 27005:2022 (information security risk management guidance) and ISO/IEC 27006-1 (requirements for certification bodies), for the risk identification approaches and certification process described here.
• IAF Mandatory Document MD 26 — the transition arrangements for ISO/IEC 27001:2022, ending 31 October 2025.
• Companion guides in this series: ISO/IEC 42001 — the AI management system, ISO 19011 — auditing management systems.