ISO 27001 Guide: Certification Step by Step

Most organisations that fail or stall on ISO/IEC 27001 do so because they treat it as a list of 93 controls to implement, when the standard certifies a risk-based management system and the controls are an output of it. ISO/IEC 27001:2022 sets requirements for an information security management system (ISMS) in clauses 4 to 10, and Annex A lists the reference controls a risk treatment must be compared against. This guide walks through scoping, risk assessment and treatment, the Statement of Applicability, Annex A and the ISO/IEC 27002 attributes, internal audit and management review, and the stage 1 and stage 2 certification audits, surveillance and recertification. It is written for the information security manager or lead implementer running a first certification, and for teams maintaining a certificate after the 2022 transition.

Key takeaways

• Clauses 4 to 10 are what you are certified against. Annex A controls are selected through risk treatment and justified in the Statement of Applicability; an auditor will raise a nonconformity for a missing management review long before a missing control.
• The 2022 edition has 93 controls in four themes. Organizational (37), People (8), Physical (14) and Technological (34), aligned to ISO/IEC 27002:2022, with 11 new controls such as threat intelligence, configuration management and secure coding.
• The transition is over. Certification bodies had to move all clients to ISO/IEC 27001:2022 by 31 October 2025, and Amendment 1:2024 adds a climate change consideration to clauses 4.1 and 4.2.
• Certification is a three-year cycle. Stage 1 (readiness and documentation), stage 2 (implementation and effectiveness), then surveillance audits each year and a recertification audit before the certificate expires.
• Identity controls carry much of the evidence load. A.5.15 to A.5.18, A.8.2 and A.8.5 cover access control, identity lifecycle, authentication information, privileged access and secure authentication, and they apply to service accounts and API keys as much as to people.

What ISO/IEC 27001:2022 requires

ISO/IEC 27001:2022 (edition 3, published 25 October 2022) is short: 19 pages. It follows the harmonised structure shared with other ISO management system standards, so clauses 4 to 10 read much like ISO 9001 or ISO/IEC 42001. Every "shall" in these clauses is auditable.

Amendment 1:2024: published on 23 February 2024 as part of a joint ISO and IAF change to 31 management system standards. Clause 4.1 adds "The organization shall determine whether climate change is a relevant issue." and clause 4.2 adds "NOTE: Relevant interested parties can have requirements related to climate change." For most ISMSs the answer is a recorded decision in the context analysis, for example data centre resilience to heat or flooding, rather than new controls.

Annex A and ISO/IEC 27002:2022

Annex A lists 93 controls, each a one-line statement. ISO/IEC 27002:2022 gives the implementation guidance for each one. You cannot be certified to 27002; it is guidance used inside a 27001 ISMS. The 2022 revision merged 24 controls, updated 58 and added 11, and reorganised them from 14 domains into four themes.

Attributes: ISO/IEC 27002:2022 tags every control with five attributes so you can filter and map the set: control type (#Preventive, #Detective, #Corrective), information security properties (#Confidentiality, #Integrity, #Availability), cybersecurity concepts (#Identify, #Protect, #Detect, #Respond, #Recover, matching the NIST CSF functions), operational capabilities (15 values, including #Identity_and_access_management and #Supplier_relationships_security) and security domains (#Governance_and_Ecosystem, #Protection, #Defence, #Resilience). Filtering on #Identity_and_access_management gives the identity team its own control list; filtering on #Detective shows whether the set can actually catch failure.

Scoping the ISMS

Clause 4.3 requires a documented scope that considers the issues in 4.1, the requirements in 4.2 and the interfaces and dependencies with activities performed by other organisations. The certificate states the scope, and customers read it.

• Small organisations (under about 100 staff): scope the whole organisation. Carving out parts of a small company adds boundary controls and explanations that cost more than including them.
• Large organisations: start with the business unit, product or service that customers or regulators ask about, then extend. Name locations, products, teams and the cloud platforms in scope.
• Interfaces: list what sits outside but connects in: the group identity provider, shared IT, outsourced SOC, cloud providers. Out of scope does not mean uncontrolled; supplier controls A.5.19 to A.5.22 cover the dependency.
• Scope wording to avoid: statements so narrow that the certificate does not cover the service the customer buys. Buyers check this first.

Risk assessment and risk treatment

Clause 6.1.2 requires a defined and repeatable information security risk assessment process: risk acceptance criteria, criteria for performing assessments, identification of risks to confidentiality, integrity and availability within scope, named risk owners, analysis of consequence and likelihood, and evaluation against the criteria. ISO/IEC 27005:2022 gives guidance on doing this; it is optional and not certifiable.

1. Set criteria first: a likelihood and impact scale with defined anchors (for example financial loss bands, customer records affected, regulatory notification) and a risk acceptance threshold approved by management.
2. Choose an approach: asset-based (assets, threats, vulnerabilities) or event-based (scenarios such as "attacker uses a leaked CI/CD token to reach production"). ISO/IEC 27005 describes both. Event-based is usually faster for a first cycle and easier for executives to read.
3. Assign risk owners: people with authority to accept or fund treatment, not the security team by default.
4. Treat: modify (apply controls), retain (accept), avoid or share. For each treated risk, determine the necessary controls from any source, then compare them with Annex A to check nothing necessary has been omitted (6.1.3 c).
5. Produce the risk treatment plan with actions, owners, dates and resources, and obtain risk owners' approval of the plan and acceptance of residual risk (6.1.3 f).
6. Repeat at planned intervals and when significant changes occur (8.2), such as a new cloud platform, an acquisition or deploying AI agents with production access.

Quantified methods are compatible with the standard as long as the criteria are defined. See the Cyber Risk Quantification Guide.

The Statement of Applicability

The SoA required by 6.1.3 d) lists the necessary controls, the justification for including them, whether they are implemented, and the justification for excluding any Annex A control. It is the single most read ISMS document: auditors use it to plan sampling and customers often request it with the certificate.

• Exclusions need a reason tied to risk or scope, not "not relevant". "No premises in scope" is acceptable; "not a priority" is not.
• Additional controls: the 2022 text makes clear Annex A is not exhaustive. Add controls you need, for example for AI systems or non-human identity governance, and mark their source.
• Version the SoA and record why each change was made; auditors compare versions between surveillance visits.

Where identity fits

Identity controls generate a large share of audit sampling, and nothing in them limits them to employees: service accounts, workloads, API keys and AI agents are identities and authentication information too.

• Service accounts and API keys: include them in the asset inventory (A.5.9), assign owners under A.5.16 and treat their keys as authentication information under A.5.17. See the Service Account Security Guide and the Secrets Management Guide.
• Lifecycle: leaver processes that disable the person but leave their tokens and keys active fail A.5.18. See the Joiner-Mover-Leaver Guide.
• Privileged access: see the Privileged Access Management Guide.

Certification step by step

1. Gap analysis (weeks 1 to 4): assess clauses 4 to 10 and Annex A against current practice. Decide scope and sponsor.
2. Build the management system (months 1 to 4): policy, roles, risk method, risk assessment, risk treatment plan, SoA, objectives and metrics, document control, competence and awareness.
3. Implement and operate controls (months 2 to 8): prioritise treatment of the highest risks; an ISMS needs records of operation, so start operating early.
4. Internal audit (9.2): cover all clauses and the applicable controls over the audit programme, by auditors who are objective and impartial (they must not audit their own work). Many organisations use a contracted auditor for the first cycle.
5. Management review (9.3): top management reviews audit results, risk status, metrics, nonconformities and changes, and records decisions.
6. Select an accredited certification body: check accreditation by a national body that is an IAF member (for example UKAS or INAB) and that the scope of accreditation covers ISO/IEC 27001. Certification bodies audit to ISO/IEC 17021-1 and ISO/IEC 27006.
7. Stage 1 audit: documentation review and readiness: scope, risk method, SoA, internal audit and management review completed. Issues are recorded as areas of concern to fix before stage 2.
8. Stage 2 audit: on-site or remote evaluation of implementation and effectiveness, interviewing control owners and sampling records. Major nonconformities must be corrected before a certificate is issued; minor ones need an accepted corrective action plan.
9. Certification decision and certificate: valid for three years, subject to surveillance. Refer to it as "certified to ISO/IEC 27001:2022", as ISO advises.
10. Surveillance and recertification: surveillance audits each year sample parts of the ISMS; a recertification audit before expiry reviews the whole system.

Test before the auditor does: run a mock stage 2 two to four weeks ahead, using someone outside the implementation team, sampling the same records an auditor would: five leavers, five changes, one supplier review, the latest access review and the last two incidents. Fix what it finds and log the fixes as corrective actions under 10.2; a working corrective action process is itself evidence the ISMS operates.

Decision guidance: a focused SaaS company of 50 people with cloud-native tooling can typically reach stage 2 in six to nine months; a multi-site enterprise usually needs 12 to 18 months or a phased scope. Lead implementer and lead auditor training courses help the core team, but certificates held by individuals do not certify the organisation. If a stage 2 audit raises a major nonconformity, you do not restart: you correct it, provide evidence and the certification body verifies before deciding.

Transition from 2013 and related standards

Under IAF MD 26:2023, initial and recertification audits had to use the 2022 edition no later than 30 April 2024, and certification bodies had to complete client transitions by 31 October 2025. A certificate still referencing ISO/IEC 27001:2013 should now be queried with the issuing body. Transitions required updating the SoA to the new control numbering, reviewing risk treatment against the new controls, and adding clause 6.3 planning of changes.

Legacy documents: SoAs, policies and audit checklists written for the 2013 edition still circulate. Old references such as A.9 (access control) or A.12.4 no longer exist: the 2022 numbering merged related controls, so A.8.15 Logging replaces the three 2013 logging controls 12.4.1 to 12.4.3. Keep a one-off cross-reference from old to new numbers for evidence filed before the transition, then retire the old numbering from every live document so internal audit and supplier questionnaires use one scheme.

For AI programmes, see the AI Governance Guide. Integrated audits of 27001 with 27701 or 42001 save time when the certification body can audit both in one visit.

Measuring the ISMS and framework mapping

• Risk treatment plan progress: percentage of treatment actions closed by due date, with overdue high risks reported to management review.
• Nonconformity closure: mean days to close internal and external audit findings; target zero repeat findings at surveillance.
• Control operation: percentage of scheduled control activities (access reviews, vulnerability scans, supplier reviews) completed on time.
• Identity hygiene: share of identities, including non-human ones, with a named owner; leaver disablement time; percentage of secrets rotated within policy.
• Incident learning: incidents with completed lessons learned that resulted in a risk register update.

Common failure patterns

• Controls on paper, gaps in practice: an SoA can mark A.8.5 implemented while one remote access path lacks MFA. In the Change Healthcare breach, a single Citrix login without MFA was enough.
• Risk assessment done once: the register is built for stage 1 and not revisited after major change, so surveillance auditors find new platforms with no assessed risks.
• Incident response that skips credential rotation: A.5.17 needs rotation after exposure. The Cloudflare breach followed four credentials left unrotated after a supplier incident, and the Internet Archive breach followed an exposed GitLab token and unrotated Zendesk keys.
• Non-human identities outside the inventory: service accounts and keys without owners are invisible to A.5.16 and A.5.18 reviews. See the Okta support system breach, where a service account credential ended up in a personal Google profile.
• Internal audit as a checkbox: a two-day audit by the person who wrote the policies fails the impartiality requirement and finds nothing useful.
• Scope that misses the product: certifying head office while the customer-facing platform sits outside the scope statement.

Practitioner checklist

• Write the scope so it covers the service customers buy, and list interfaces and dependencies.
• Agree risk acceptance criteria with management before the first risk assessment.
• Name risk owners with authority to accept residual risk and approve the treatment plan.
• Build the SoA from risk treatment, with real justifications for every exclusion.
• Inventory service accounts, API keys and AI agents with owners under A.5.9 and A.5.16.
• Operate controls for at least one cycle and complete an impartial internal audit and a management review before stage 1.
• Choose a certification body accredited by an IAF member for ISO/IEC 27001:2022.
• Record the climate change decision from Amendment 1:2024 in the context analysis.
• Re-run the risk assessment on significant change and before each surveillance audit.

Standards and references

• ISO: ISO/IEC 27001:2022 Information security management systems, Requirements
• ISO: ISO/IEC 27002:2022 Information security controls
• ISO: ISO/IEC 27005:2022 Guidance on managing information security risks
• ISO and IAF: Joint Communiqué on the addition of climate change considerations to management system standards
• INAB: Transition requirements for ISO/IEC 27001:2022
• UKAS: Transition arrangements for ISO/IEC 27001:2022
• ISO: ISO/IEC 27701:2025 Privacy information management systems
• BSI: New ISO/IEC 27002 version with changes to ISO/IEC 27001

Related NHI Mgmt Group resources: Access Reviews Guide · Service Account Security Guide · Cyber Risk Quantification Guide · GDPR Compliance Guide for Security Teams · Third-Party Access Guide