The 11 New ISO 27001 Annex A Controls Explained
ISO/IEC 27001:2022 added 11 new Annex A controls. Here is what each one means in plain English, with a sensible first step for a growing company.
In this article
ISO/IEC 27001:2022 reorganised Annex A into 93 controls in four themes. Most of those controls existed in some form before. Eleven were new. They are the ones teams most often ask about, because they reflect how technology and threats have changed.
This guide explains each new control in plain English and suggests a first step. It is not a full implementation plan. Use it to decide where you stand and which controls need attention first, based on your own risk assessment.
1. Why the new controls matter
The new controls are not a random list. They cover areas where many organisations already had risks but no clear control: cloud services, data leaking out of approved channels, configuration drift, insecure code and the gap between collecting logs and actually watching them.
Because they are new, they are also where audits often find the biggest gap between policy and practice. A policy written during the transition is a start. An auditor will want to see that the control runs, with records over time. If you select a control in your Statement of Applicability, plan the evidence as well as the document.
It also helps to remember what did not change. The core of the standard is still the management system: context, leadership, risk assessment, internal audit and improvement. The new controls sit inside that system. They are chosen because of your risks, and they are reviewed in the same cycle as everything else.
2. The 11 new controls at a glance
The table below gives a plain meaning and a practical first step for each new control. The first step is a starting point for a growing company, not the full requirement.
| Control | Plain meaning | A first step |
|---|---|---|
| Threat intelligence | Know which threats are relevant to you. | Subscribe to a few trusted sources and review them monthly. |
| Information security for use of cloud services | Choose, use and leave cloud services securely. | List your cloud services and who owns each one. |
| ICT readiness for business continuity | Make sure IT can support recovery after disruption. | Test a restore of one critical system. |
| Physical security monitoring | Watch sensitive areas for unauthorised access. | Review who can see camera or access logs. |
| Configuration management | Keep systems in a known, approved state. | Define a baseline for your main server or cloud setup. |
| Information deletion | Delete data when it is no longer needed. | Set a retention period for one large dataset. |
| Data masking | Hide sensitive data where full values are not needed. | Mask personal data in test environments. |
| Data leakage prevention | Stop data leaving through unapproved channels. | Identify your most sensitive data and where it flows. |
| Monitoring activities | Watch for unusual behaviour, not just store logs. | Agree a few alerts that someone reviews every day. |
| Web filtering | Reduce access to harmful websites. | Turn on filtering for known malicious sites. |
| Secure coding | Write and review code with security in mind. | Add a security check to code review. |
Notice that several first steps are about ownership and visibility. You often cannot improve a control until you know what you have and who looks after it.
3. Turning the list into a plan
Start with your risk assessment. For each new control, ask whether the risk it addresses is real for your business. A fully remote company may have little physical space to monitor. A software company with customer data in test systems has a strong case for data masking and secure coding.
Then group the selected controls by owner. Engineering usually owns configuration management, secure coding and data masking. IT or security operations usually owns monitoring activities, web filtering and data leakage prevention. The leadership team and IT share ICT readiness for business continuity. Grouping by owner keeps the work practical.
Be careful not to overbuild. A growing company does not need an enterprise data leakage prevention platform on day one. It needs to know where its sensitive data lives and to block the most obvious ways it could leak. Start small, measure, and grow the control as the business grows.
Set a simple target for each control: what "operating" will look like, what evidence it produces and how often. For example, monitoring activities might mean a short daily review of agreed alerts, with a log of what was checked and what was escalated.
Finally, review progress in your management review and internal audit. These controls mature over months, not days. Treat early gaps as normal and keep improving.
If you are preparing for a surveillance audit, plan the evidence for each selected control as carefully as the policy. Our ISO 27001 consulting team and GRC tool automation service can help you plan the work, if you would like a hand.