The 11 new controls in ISO/IEC 27001:2022, explained

ISO/IEC 27001:2022 replaced the 2013 edition, and the transition deadline of 31 October 2025 has passed. Every certificate issued today is against the 2022 edition. If you are building an ISMS now, this is the version you are working to, and it is worth understanding what changed and why.

The headline changes

The management system clauses 4 to 10 changed only modestly: clearer wording on planning changes, on defining processes, and on communication. The substantial change is Annex A, which was rebuilt to match ISO/IEC 27002:2022.

• 114 controls became 93. Many 2013 controls were merged. Nothing of substance was removed.
• 14 domains became 4 themes: organizational (37 controls), people (8), physical (14), and technological (34).
• 11 controls are new. They reflect how organizations have actually operated since 2013: in the cloud, with remote workers, against a threat landscape that changes weekly.
• Attributes were introduced in ISO 27002 to let you filter controls by type, security property, cybersecurity concept, operational capability, and security domain. They are optional but useful for mapping to other frameworks.

The 11 new controls and what auditors look for

A.5.7 Threat intelligence

Collect and analyze information about threats and use it to inform your controls. The auditor does not expect a threat intelligence team. They expect evidence that you receive relevant information, from vendor advisories, industry groups, or government sources, and that it changes something: a patch prioritized, a rule added, a risk reassessed.

A.5.23 Information security for use of cloud services

Define how you acquire, use, manage, and exit cloud services. Expect questions about your process for approving new cloud services, how shared responsibility is understood for each major provider, what the contracts say about security and data return, and how you would leave.

A.5.30 ICT readiness for business continuity

Plan, implement, and test ICT continuity to meet business continuity objectives. The auditor looks for defined recovery objectives, technical arrangements that could meet them, and evidence of testing. A backup that has never been restored is a finding waiting to happen.

A.7.4 Physical security monitoring

Monitor premises for unauthorised physical access. For an office, this may be alarm systems, CCTV, or access logs that someone reviews. For a fully remote company with no premises in scope, this control may be justifiably not applicable, but the Statement of Applicability must say so and why.

A.8.9 Configuration management

Establish, document, implement, monitor, and review configurations of hardware, software, services, and networks. In cloud environments this is infrastructure as code, baseline images, and drift detection. The auditor wants to see standard configurations, a process for changing them, and a way of detecting when reality diverges.

A.8.10 Information deletion

Delete information when it is no longer required. Expect questions about retention periods, how deletion is actually carried out in production systems, backups, and with suppliers, and how you would satisfy a deletion request from a customer or data subject.

A.8.11 Data masking

Use masking, pseudonymization, or anonymization to limit exposure of sensitive data. The typical evidence is how production data is handled in test and analytics environments, and what fields are masked in logs and support tooling.

A.8.12 Data leakage prevention

Apply measures to detect and prevent unauthorised disclosure. This does not mandate a DLP product. It asks what you do to stop sensitive data leaving: email controls, endpoint restrictions, cloud storage sharing settings, and monitoring for unusual exports.

A.8.16 Monitoring activities

Monitor networks, systems, and applications for anomalous behavior and act on it. The auditor will ask what is monitored, how alerts are triaged, and for examples of alerts that led to investigation. Dashboards nobody looks at do not count.

A.8.23 Web filtering

Manage access to external websites to reduce exposure to malicious content. This can be DNS filtering, a secure web gateway, or browser policies. The auditor wants to see the policy and evidence that it is applied to endpoints.

A.8.28 Secure coding

Apply secure coding principles to software development. Expect questions about coding standards, developer training, code review, static analysis, dependency management, and how vulnerabilities found in code are tracked to closure.

How the merged controls affect you

Because many 2013 controls were combined, a single 2022 control can be broad. A.5.15 access control, for example, absorbed several 2013 controls. When you write your Statement of Applicability, describe how you meet the whole control, not just the part that maps to what you did before.

Practical advice

• Base your Statement of Applicability on ISO 27002:2022 guidance so your control descriptions match what auditors are reading.
• For each new control, decide early whether it is applicable. Not applicable is acceptable with a justification; silent omission is not.
• Use the attributes to map to SOC 2, NIST CSF, or CIS Controls if you maintain several frameworks. It saves rework.
• Expect auditors to spend more time on the technological theme than they did under 2013, because that is where the new controls concentrate.

• ISO 27001:2022
• Annex A
• controls