Updates in ISO 27000:2026 I did not expect
I really did not expect those...
In July 2026, ISO and IEC published the sixth edition of ISO/IEC 27000, replacing the 2018 edition. This is a substantial revision — new title, new structure, new purpose.
Most people won’t read it. It’s “just the overview document,” after all.
That’s a mistake. Buried in the new text are two passages that address concepts the large majority of ISO 27001 users get wrong: the role of Annex A, and what a risk treatment plan actually is.
What changed between 2018 and 2026
The most visible change is in the title. Overview and vocabulary became simply Overview. ISO/IEC 27000 is no longer the terminology document of the ISMS family. Clause 3 shrank from 77 defined terms to 12 — only what’s needed to explain the concepts in the document itself. For everything else, the ISO Online Browsing Platform is now your reference.
Beyond that:
The document now has two jobs: explain the concepts and principles behind information security and ISMS (Clause 4), and map the relationships between all documents related to ISMS including ISO/IEC 27001 (Clause 5).
The categorization of standards changed too. The 2018 edition sorted them into requirement standards, general guidelines and sector-specific guidelines. The 2026 edition categorizes by function: ISMS specification (27001), candidate necessary information security controls (27002, 27010, 27011, 27017, 27019), fulfilment of ISMS requirements (27003, 27004, 27005, 27007), use of ISMS (27013, 27014, TR 27016), control assessment, attributes, processes and competence (TS 27008, 27021, TS 27022, 27028), and conformity assessment (27006-1).
ISO/IEC 27009, 27018 and 27799 no longer appear in the family. ISO/IEC 27028 on control attributes joins it.
Housekeeping, mostly. But two sections deserve a closer look.
Annex A is not a list of Controls!
Notice the wording in the new categorization above: ISO/IEC 27002 and the sector standards are called candidate necessary information security controls. That word choice is deliberate, and Clause 5.2 spells out why.
Here’s the process as the new edition describes it: the organization determines the controls it regards as necessary to implement its risk treatment plan. These controls can be designed by the organization or identified from any source — ISO/IEC 27002, sector standards like ISO/IEC 27017, vendor frameworks, your own engineering. They are then compared with the reference controls in Annex A “to verify that no necessary controls have been omitted.”
Read that sequence again.
Your risks come first.
Your controls come second.
Annex A comes last.
Annex A is not a catalogue you shop from. It’s a checklist you verify against. It doesn’t ask “have you implemented A.8.5?” — you can’t implement A.8.5, it’s a one-sentence description of a desired state. It asks “have you thought about authentication?” If your risk treatment produced nothing that maps to a reference control, that’s your prompt to check whether you missed a risk — or to document why the control genuinely doesn’t apply. That’s the entire verification step. A safety net, not a control catalog.
Was this in the old version? No — and the contrast is telling. The 2018 edition, still written against ISO/IEC 27001:2013, said control objectives and controls shall be selected from Annex A to cover identified requirements. Annex A was the menu. ISO/IEC 27001:2022 dropped the control objectives entirely and reframed Annex A as reference controls, and the 2026 overview now states that logic plainly. If your SoA is still a copy-paste of Annex A with a yes/no column, this clause is written for you.
The risk treatment plan: more than a project plan
Clause 4.1.5 contains something the 2018 edition never addressed. Controls are categorized as organizational, people, physical and technological — mirroring ISO/IEC 27002:2022 — and classified as preventive, detective and corrective. Then comes the sentence worth underlining: controls work together in accordance with the organization’s risk treatment plan. A suitable mix of preventive, detective and corrective controls makes the risk treatment plan resilient to control failures.
Think about how risk treatment plans are actually written. In almost every ISMS I audit, the RTP is a project plan: which controls to implement, by whom, by when. For a first-time certification, that’s exactly right. The plan describes the path from current state to target state.
But what happens after the controls are implemented? In most organizations, the RTP quietly dies. There’s nothing left to plan.
Clause 4.1.5 suggests a second reading: the risk treatment plan as a description of how your controls work together. Which preventive controls reduce likelihood? Which detective controls catch what the preventive layer misses? Which corrective controls limit the consequences when both fail?
A plan structured this way exposes single points of failure in your control architecture. One preventive control with no detective backup is a fragile treatment — no matter how well that control is implemented.
Neither reading excludes the other. A mature ISMS arguably needs both: a forward-looking plan for changes and improvements, and a systemic view of how the implemented control mix holds together under failure conditions.
Your Free Guide to ISO 27001
Stop guessing your way through ISO 27001. My free guide walks you through the full implementation project in 12 clear steps. Verified by an active Lead Auditor with many years of experience in both auditing and implementing ISMS.
Thanks Aron for a clear description of the risk treatment plan