Most companies that call us about ISO 27001 have already read the marketing copy on a dozen certification body websites. What they haven't seen is what the standard actually obligates them to do, clause by clause, before an auditor will sign anything. That gap between "we want the certificate" and "we understand the ten management clauses and ninety-three Annex A controls we have to operationalize" is where most implementations stall.
This guide walks through what ISO/IEC 27001:2022 requires in the order you'll actually encounter it: scoping, risk assessment, control selection, internal audit, and the two-stage certification audit. I've included the clause numbers because a consultant, or an auditor, will use them, and you should be able to follow the conversation without translating.
What ISO/IEC 27001:2022 Actually Is
ISO/IEC 27001:2022 was published on October 25, 2022, replacing the 2013 edition. It's a management systems standard, not a technical control checklist. The requirements that get you certified live in clauses 4 through 10 — context of the organization, leadership, planning, support, operation, performance evaluation, and improvement. Annex A is the reference list of security controls you draw from when you build your risk treatment plan; it isn't a separate certifiable document, but you'll spend more implementation hours on it than on any single clause.
The 2022 revision cut Annex A from 114 controls across 14 domains down to 93 controls organized into four themes: Organizational (37 controls), People (8 controls), Physical (14 controls), and Technological (34 controls). Eleven of those are entirely new — things like threat intelligence (5.7), data masking (8.11), and web filtering (8.23) — reflecting a decade of change in how organizations actually get breached.
If your organization is still certified against ISO/IEC 27001:2013, the transition deadline has already passed: certification bodies were required to have all existing clients transitioned to the 2022 version by October 31, 2025, per IAF MD 26 transition arrangements. A 2013-version certificate issued or renewed after that date is not valid. If you're not sure which version your current ISMS documentation references, that's the first thing to check, not the last.
The Implementation Sequence, Step by Step
Step 1: Define the Scope (Clause 4.3)
Everything downstream depends on this. Clause 4.3 requires you to determine the boundaries and applicability of the ISMS, considering internal and external issues (clause 4.1), the needs of interested parties (clause 4.2), and interfaces with other organizations. In practice, this means deciding — in writing, as a controlled document — which business units, locations, systems, and data flows are inside the ISMS and which are excluded.
I've seen more implementations go sideways here than anywhere else. Scope too broad and you're trying to document controls for systems nobody uses; scope too narrow and a customer's security questionnaire calls your certificate meaningless because it excludes the product they actually buy from you. A gap analysis against the current state of your policies, technical controls, and vendor contracts should happen before scope is finalized, not after.
Step 2: Risk Assessment and Risk Treatment (Clauses 6.1.2 and 6.1.3)
Clause 6.1.2 requires a documented, repeatable risk assessment methodology — most organizations base theirs on ISO/IEC 27005, though the standard doesn't mandate that specific framework. You need to identify risks to the confidentiality, integrity, and availability of information within scope, assign risk owners, and evaluate likelihood and consequence against criteria you've defined in advance.
Clause 6.1.3 is where risk treatment happens, and it has four sub-requirements auditors check line by line: (a) select risk treatment options, (b) determine the necessary controls, (c) compare those controls against Annex A to verify nothing has been overlooked, and (d) produce a Statement of Applicability. The Statement of Applicability — the SoA — is the single document auditors ask for most often, because it's the bridge between your risk assessment and your control implementation. It lists all 93 Annex A controls, states whether each is applicable, and if excluded, states why.
Step 3: Implement and Document Controls
This is the longest phase by hours, though usually not by calendar time if the work is running in parallel with steps 1 and 2. You're not implementing all 93 controls from scratch — you're implementing whichever ones your SoA marked applicable, and for most organizations that's the majority of them, with justified exclusions for things like Annex A controls covering physical data centers when everything runs in a cloud provider's environment.
Each control needs evidence, not just a policy statement. Access control policy (control 5.15) needs to be paired with actual access review records. Logging and monitoring (control 8.15) needs log retention configured and evidence someone reviews it. This is the stage where "we wrote a policy" and "we operate a control" diverge, and it's also where auditors spend most of their Stage 2 time — sampling records, not reading policy documents.
Step 4: Internal Audit (Clause 9.2)
Before a certification body ever shows up, you're required to audit yourself. Clause 9.2 requires a planned internal audit program covering the entire ISMS at planned intervals, conducted by people who did not perform the work being audited — internal independence, not necessarily an outside firm. Findings go into a documented report, and any nonconformities feed clause 10.1.
Step 5: Management Review (Clause 9.3)
Top management has to formally review the ISMS at planned intervals, with a defined set of inputs specified in clause 9.3: status of actions from previous reviews, changes in external and internal issues, performance trends, audit results, and opportunities for improvement. This isn't a rubber-stamp meeting — auditors ask for the minutes and the inputs discussed, and a management review that looks like it happened in five minutes with no substantive inputs is a common finding.
Step 6: Correct Nonconformities (Clause 10.1)
The 2022 revision merged what was clauses 10.1 and 10.2 in the 2013 version into a single clause 10.1 covering nonconformity and corrective action. Whatever your internal audit and management review turned up needs a documented root cause analysis and correction before you're ready for external audit — auditors will ask to see this trail, and an ISMS with zero internal findings after its first internal audit usually reads as a red flag, not a clean bill of health.
Step 7: Stage 1 and Stage 2 Certification Audits
Certification bodies operating under ISO/IEC 17021-1 conduct two distinct audit stages. Stage 1 is a documentation review — the auditor checks that your scope, risk assessment, SoA, and policies exist and are coherent, and identifies readiness for Stage 2. It often happens on-site or remotely and typically takes one to two days depending on scope size.
Stage 2 is the operational audit: the auditor samples evidence that controls are actually functioning, interviews staff, and reviews records against the SoA. This is where an ISMS that exists only on paper gets found out. Major nonconformities found in Stage 2 require correction and a follow-up audit before certification is issued; minor nonconformities can usually be addressed with a corrective action plan reviewed at the next surveillance audit.
How Long Implementation Actually Takes
| Organization profile | Typical timeline to certification readiness | Primary bottleneck |
|---|---|---|
| Single-location SaaS company, <50 employees, cloud-native infrastructure | 4–6 months | Evidence collection for technical controls |
| Multi-location company with legacy on-prem systems | 8–12 months | Physical and legacy system control gaps |
| Organization with prior SOC 2 or similar framework in place | 3–5 months | Mapping existing controls to Annex A, not building new ones |
| Highly regulated environment (healthcare, financial services) with overlapping frameworks | 9–14 months | Reconciling ISO 27001 scope against existing regulatory controls |
These ranges assume a dedicated internal owner and consistent leadership attention. The single biggest accelerant I see is an organization that already runs a mature SOC 2 Type II program — the risk assessment discipline and evidence habits transfer directly, and the gap is mostly mapping exercises, not new control-building. The single biggest drag is an organization trying to run implementation as a side project for someone who also owns three other initiatives. Clause 5.1 requires top management commitment for a reason: ISMS programs that stall almost always stall because nobody with authority is protecting the time it takes.
The Four Annex A Themes
| Theme | Control count | Representative controls |
|---|---|---|
| Organizational | 37 | Policies for information security (5.1), threat intelligence (5.7), supplier relationships (5.19–5.23) |
| People | 8 | Screening (6.1), terms and conditions of employment (6.2), disciplinary process (6.4) |
| Physical | 14 | Physical security perimeters (7.1), equipment maintenance (7.13), clear desk and clear screen (7.7) |
| Technological | 34 | Access rights (8.2), data masking (8.11), secure coding (8.28), web filtering (8.23) |
A practical note on this table: the theme count tells you where the standard puts its weight, but it doesn't tell you where your gaps are. A software company usually has strong Technological-theme controls already in place through normal engineering practice and weak Organizational-theme controls — supplier risk assessments, documented policy review cycles — because nobody was assigned to own paperwork discipline. A gap analysis against your specific scope, not the theme totals, is what should drive your implementation plan.
What a Consultant Actually Does in This Process
The value of bringing in outside help isn't writing your policies for you — a template library gets you policy documents in an afternoon, and any experienced compliance hire can adapt them. The value is in three places auditors consistently flag when they're missing: a risk assessment methodology that's actually followed consistently rather than performed once for the audit, a Statement of Applicability where the exclusions are defensible rather than convenient, and an internal audit program with enough independence and rigor that Stage 2 doesn't turn up surprises. If you're evaluating whether to bring in outside support, ask a candidate consultant to walk you through how they'd structure your SoA exclusions — the answer tells you quickly whether they understand the standard or are selling a template.
If you're scoping this project and want a second opinion on your gap analysis before you commit to a timeline, my team at Certify Consulting reviews ISO 27001 readiness for organizations at every stage of the process — you can reach us through the contact page or read more about our ISO 27001 services directly.
FAQ
How many controls are in ISO/IEC 27001:2022? Annex A contains 93 controls organized into four themes: Organizational (37), People (8), Physical (14), and Technological (34). This replaced the 114 controls across 14 domains in the 2013 version.
Do I need to implement all 93 Annex A controls? No. Clause 6.1.3 requires you to determine which controls are necessary based on your risk assessment, and to document any exclusions with justification in your Statement of Applicability. Most organizations exclude a handful of controls that don't apply to their infrastructure or business model.
What's the difference between Stage 1 and Stage 2 audits? Stage 1 is a documentation review confirming your ISMS scope, policies, risk assessment, and Statement of Applicability exist and are coherent. Stage 2 is an operational audit where the auditor samples evidence that controls are actually functioning day to day.
Is the ISO/IEC 27001:2013 certificate still valid? No. Certification bodies were required under IAF MD 26 transition arrangements to have all clients transitioned to the 2022 version by October 31, 2025. Certificates against the 2013 version are no longer valid.
How long does ISO 27001 certification take from start to finish? Most organizations move from gap analysis to certification readiness in 4 to 14 months depending on infrastructure complexity, existing framework overlap (such as SOC 2), and how much dedicated time leadership assigns to the project. The audit itself, once you're ready, typically adds 4 to 8 weeks between Stage 1 and Stage 2.
Last updated: 2026-08-11
Jared Clark
Principal Consultant, Certify Consulting
Jared Clark is the founder of Certify Consulting, helping organizations achieve and maintain compliance with international standards and regulatory requirements.