ISO/IEC 27001 is the international standard specifying the requirements for an ISMS — an Information Security Management System. It is the only standard in the 27000 family you can be certified against, which is why its name shows up in contracts, tenders and vendor due diligence.
The most common confusion starts right here. People come to ISO 27001 expecting firewall configurations, password rules and encryption requirements. That is not what it is. The standard is about management: how the organisation decides what to protect, on what basis, who is accountable, and how it demonstrates that the system keeps working over time.
What the standard actually requires
The mandatory body of ISO 27001 lives in clauses 4 to 10. These are what the auditor checks, and none of them can be waived:
- 4 — Context of the organisation. Define the ISMS scope and identify interested parties and their requirements.
- 5 — Leadership. Top management must own the security policy and assign roles formally. This is not delegable to IT.
- 6 — Planning. Risk assessment and treatment, plus measurable security objectives.
- 7 — Support. Competence, awareness, communication and control of documented information.
- 8 — Operation. Execute what was planned, and keep records of it.
- 9 — Performance evaluation. Monitoring, internal audit and management review.
- 10 — Improvement. Handling non-conformities and continual improvement.
Annex A, where the security controls themselves live, works as a reference checklist: you must justify, in the Statement of Applicability, why each control does or does not apply to your scope.
What changed in the 2022 revision
The 2022 revision completely reorganised Annex A. The 114 controls spread across 14 sections in the 2013 version became 93 controls grouped into four themes: organisational, people, physical and technological.
The reduction does not mean the standard got lighter. Much of it came from merging overlapping controls, and eleven controls are entirely new — among them threat intelligence, information security for cloud services, data masking, data leakage prevention and secure coding. These are topics that barely existed in the 2013 vocabulary.
Mind the deadline. The transition period for organisations certified against the 2013 version ended on 31 October 2025. Certificates issued under the old version are no longer valid. If your organisation did not complete the migration, the certificate has to be earned again against the 2022 version.
What it is for, in practice
It is worth separating the real reasons from the stated ones. In most projects that reach us, the trigger is one of these:
- A commercial requirement. A large customer — or an international procurement process — made certification a condition. This is by far the most frequent driver.
- An indirect regulatory requirement. The regulator does not name ISO 27001, but asks for a set of practices the standard organises well.
- Actual risk reduction. The organisation had an incident, or realised it cannot answer the question "what exactly are we protecting?".
All three are legitimate. But they lead to different projects: the first tends to produce a narrow, fast scope; the third demands a broader scope and a longer timeline. Deciding which one is yours before you start avoids the frustration of a project that delivers the certificate without reducing exposure — or one that reduces exposure but delays the contract.
How long it takes
For a mid-sized organisation with no prior ISMS, the typical gap between project kick-off and the certification audit is 6 to 12 months. What stretches that timeline is almost never the technical work — it is the need to accumulate evidence. The stage 2 audit requires the system to be operating, with monitoring records, at least one internal audit cycle completed and a management review already held.
The mistake that costs the most
Treating ISO 27001 as an IT project. When the ISMS sits solely with infrastructure, three things tend to happen: scope gets defined by system instead of by business process, the risk assessment becomes an inventory of technical vulnerabilities, and clause 5 — leadership — cannot be evidenced at all, because management was never involved.
Auditors do not ask for console screenshots. They ask for meeting minutes, recorded decisions, and risk acceptance criteria signed by someone with the authority to accept risk.
Where to start
Before hiring consultants or buying tooling, run a gap assessment: which of the clause 4–10 requirements do you already meet in some form, even informally, and which simply do not exist? Organisations that already have change management, documented access control and some incident response process are usually closer than they think — what is missing is formalisation and evidence, not capability.