Manzill Surolia

Analysis · 14 Jul 2026

ISO 27001:2013 → 2022, Quantified

114 controls in 14 domains became 93 in 4 themes — not by deleting the work, but by consolidating it. Here is exactly what moved.

114→93Annex A controls (net −21)
14→4domains became themes
11brand-new controls
57→24controls merged down
0controls actually deleted

The 2022 revision reads like a cut, but nothing was thrown away. ISO/IEC 27001:2022 (with its control text in ISO/IEC 27002:2022) took the 2013 catalogue of 114 controls across 14 domains and re-indexed it into 93 controls across 4 themes. The shrinkage is almost entirely consolidation — 57 overlapping controls were merged into 24, one control was split into two, and 11 genuinely new controls were added for the threats the 2013 edition never anticipated: cloud, data leakage, threat intelligence, secure coding. Count fell; coverage grew.

How the 114 old controls map forward
Merged57 controls → 2457
Carried overunchanged or renamed56
Split1 control → 21
New in 2022added controls11

57 merged + 56 carried + 1 split = the 114 old controls; 24 + 56 + 2 + 11 = the 93 new ones.

1 · The Structure: 14 Domains Became 4 Themes

The 2013 Annex A grouped controls into fourteen numbered domains (A.5–A.18). The 2022 edition flattens them into four themes, each a single clause. Every old domain still lives inside one of the four — the syllabus did not change, its filing system did.

2022 themeClauseControlsAbsorbs (from the 2013 domains)
OrganizationalA.537Policies, org of infosec, asset mgmt, supplier relationships, incident mgmt, compliance, business continuity
PeopleA.68Human-resource security, awareness, remote working, screening
PhysicalA.714Physical & environmental security, secure areas, equipment
TechnologicalA.834Access control, cryptography, operations, comms, secure development

37 + 8 + 14 + 34 = 93. Organizational and Technological carry three-quarters of the catalogue between them.

▸ Re-theming is why a control’s number changed even when its meaning did not. A.9.2.3 “Privileged access rights” (2013) is now A.8.2 — same requirement, new address. Your Statement of Applicability needs re-numbering, not re-thinking.

2 · The 11 New Controls

These are the only controls with no ancestor in 2013. Read as a list, they are a decade of threat evolution written into the standard: the cloud became default, data started leaving in bulk, and development moved left.

Ref.New controlThemeWhy it was added
5.7Threat intelligenceOrganizationalCollect and act on information about threats, not just react to incidents
5.23Information security for use of cloud servicesOrganizationalAcquire, use and exit cloud services securely — the shared-responsibility gap
5.30ICT readiness for business continuityOrganizationalPlan and test IT recovery to meet continuity objectives (RTO/RPO)
7.4Physical security monitoringPhysicalContinuously monitor premises for unauthorised physical access
8.9Configuration managementTechnologicalDefine, enforce and monitor secure configurations across assets
8.10Information deletionTechnologicalDelete data no longer required — a direct nod to privacy law
8.11Data maskingTechnologicalMask, pseudonymise or anonymise data to limit exposure
8.12Data leakage preventionTechnologicalDetect and stop unauthorised data exfiltration (DLP)
8.16Monitoring activitiesTechnologicalMonitor networks, systems and apps for anomalous behaviour
8.23Web filteringTechnologicalControl access to external websites to reduce malicious exposure
8.28Secure codingTechnologicalApply secure-coding principles across the development lifecycle

▸ Eight of the eleven are Technological, and four of those (deletion, masking, DLP, monitoring) are data-centric. If you built an ISMS in the 2010s, this table is your gap list.

3 · The Attribute Lens: Controls Became a Database

The quiet structural upgrade in 2022 is that every control in ISO/IEC 27002:2022 now carries five attributes. A catalogue you used to read top-to-bottom became a table you can filter — “show me every detective control that supports Recover” is now a query, and it maps cleanly onto other frameworks.

AttributeValuesWhat it lets you do
Control typePreventive · Detective · CorrectiveBalance the portfolio across the incident timeline
Information security propertiesConfidentiality · Integrity · AvailabilityTrace coverage back to the CIA triad
Cybersecurity conceptsIdentify · Protect · Detect · Respond · RecoverMap 1:1 onto the NIST Cybersecurity Framework
Operational capabilitiesGovernance, Asset mgmt, Identity & access, … (15 in total)Assign controls to the teams that actually run them
Security domainsGovernance & ecosystem · Protection · Defence · ResilienceReport posture in board-level language

The Cybersecurity concepts attribute is the bridge: it is the reason a 2022 ISMS crosswalks to NIST CSF far more cleanly than a 2013 one did.

4 · What Changed Outside Annex A

The management-system clauses (4–10) are largely stable, but the revision is not only about controls. A handful of requirement-level edits are easy to miss and are exactly what auditors check first on a transition.

ClauseChange
TitleRenamed to “Information security, cybersecurity and privacy protection” — scope now names privacy explicitly
4.2Added: determine which interested-party requirements will be addressed through the ISMS
6.2Information security objectives must now be monitored and documented
6.3New: “Planning of changes” — changes to the ISMS must be done in a planned manner
8.1Reworded: establish criteria for processes and control externally provided processes/products/services
9.3Management review must consider changes in interested-party needs and expectations
10Order swapped: 10.1 Continual improvement now precedes 10.2 Nonconformity & corrective action
Amd 1:2024Climate action: 4.1 must consider whether climate change is relevant; 4.2 notes interested parties may have climate-related requirements

5 · Migration — and Why the Clock Already Ran Out

ISO/IEC 27001:2022 was published on 25 October 2022. The accreditation bodies set a three-year transition, so certificates issued against the 2013 edition ceased to be valid after 31 October 2025. As of this writing that window is closed: a “current” ISO 27001 certificate now means the 2022 edition, full stop. If any part of your programme still references the 2013 Annex A, it is not a future task — it is a live nonconformity.

  • Re-baseline the Statement of Applicability — restate it against the 93 controls, preserving justification and mapping old numbers forward.
  • Gap-assess the 11 new controls — threat intelligence, cloud, ICT continuity, config mgmt, deletion, masking, DLP, monitoring, web filtering, physical monitoring, secure coding.
  • Close the clause edits — add “planning of changes” (6.3), monitor objectives (6.2), and fold climate into context (Amd 1:2024).
  • Re-run the risk treatment so each residual risk points at a 2022 control reference.
  • Update audit & review evidence — internal audit programme, management review inputs, and training material all cite the new structure.

Bottom line

  • Fewer controls, not less work — the drop from 114 to 93 is 57→24 consolidation, not deletion.
  • The 11 new controls are the real delta — and eight are data- and cloud-centric, tracking where the last decade’s breaches happened.
  • Attributes turn the catalogue into a queryable database — and align it, control-by-control, to NIST CSF.
  • The clauses moved too — “planning of changes” and the 2024 climate amendment are quiet audit traps.
  • The transition is over — since 31 Oct 2025, only the 2022 edition counts; a 2013 reference is a finding, not a plan.

Sources & method. Figures are drawn from the published standards — ISO/IEC 27001:2022, its Annex A, ISO/IEC 27002:2022 (which carries the control text and attributes), and ISO/IEC 27001:2022/Amd 1:2024 — together with the IAF/accreditation-body transition timeline. Control counts and the 57→24 merge / 1-split / 11-new arithmetic are taken directly from the 2022 texts. This is original analysis; no third-party material is reproduced.