ISO 27001:2022 New Controls: Implementing All 11

The 2022 edition of ISO/IEC 27001 added 11 controls to Annex A, and many ISMSs that moved to the new edition simply marked them "applicable" in the Statement of Applicability without building anything behind them. Every certificate now references the 2022 edition, so surveillance audits test whether these controls actually operate. This guide takes the 11 additions one at a time: what the control asks, a practical minimum implementation, the evidence an auditor can sample, and how to scale it for small and large organisations. It is for ISMS managers, internal auditors and the control owners in security, IT and development who have to make the controls real. For the ISMS clauses, certification steps and transition dates, see the ISO 27001 Certification Guide; for the full Annex A catalogue and attributes, see the ISO 27002 Controls Guide.

Key takeaways

Eleven controls, four themes. The new controls are 5.7, 5.23 and 5.30 (organisational), 7.4 (physical) and 8.9, 8.10, 8.11, 8.12, 8.16, 8.23 and 8.28 (technological). People controls had no additions. Amendment 1 of February 2024 (climate action changes) amended the 2022 edition but did not add Annex A controls.
Most are existing practice made explicit. Few organisations start from zero: the gap is usually a missing owner, an undocumented process or no evidence trail, not missing technology.
Some controls expect documentation, others expect operation. ISACA's guide notes that 27002 expects configuration management to be documented with changes logged, while threat intelligence and physical monitoring need no mandatory document. Auditors still sample outputs for all of them.
Justify exclusions properly. Data masking or web filtering can be excluded only with a risk-based reason in the SoA; "not needed" is not a justification.
Link the controls together. Threat intelligence should feed monitoring, monitoring should cover cloud services, and configuration baselines should include DLP and web filtering settings. Auditors follow those threads.

The 11 additions at a glance

ISO/IEC 27002:2022 (edition 3, published February 2022) reduced the control set from 114 to 93 by merging related controls and adding 11. The control numbers below appear identically in independent summaries from ISACA (parts 1 and 2), NQA and SGS, which is why we keep them; the purposes are paraphrased from the ISACA and NQA summaries; the standard itself is the authority, so read your purchased copy for exact wording.

Control	What it asks for (paraphrased)	Typical owner	Evidence an auditor can sample
5.7 Threat intelligence	Collect and analyse information about threats to produce intelligence that drives mitigation	Security operations or risk	Intelligence sources list, periodic threat summaries, a record of actions taken from intelligence
5.23 Information security for use of cloud services	Processes for acquiring, using, managing and exiting cloud services, in line with security requirements	Cloud or procurement lead	Cloud register, shared responsibility matrices, exit plans
5.30 ICT readiness for business continuity	Plan, implement, maintain and test ICT readiness based on continuity objectives	IT operations	RTO and RPO per service, recovery test reports, lessons learned
7.4 Physical security monitoring	Continuously monitor premises for unauthorised physical access	Facilities	Alarm and CCTV coverage map, alarm response records, retention settings
8.9 Configuration management	Establish, document, implement, monitor and review configurations, including security settings	IT and platform teams	Baselines, drift reports, change records
8.10 Information deletion	Delete information when it is no longer required	Data owners and IT	Retention schedule, deletion jobs and logs, sanitisation certificates
8.11 Data masking	Mask data in line with access control policy, business needs and law	Data and application owners	Masking rules, test data procedure, sample masked records
8.12 Data leakage prevention	Apply leakage prevention to systems, networks and devices handling sensitive information	Security	DLP policy set, alert and case records, tuning history
8.16 Monitoring activities	Monitor networks, systems and applications for anomalous behaviour and evaluate potential incidents	SOC	Log source coverage, use case list, triage records
8.23 Web filtering	Manage access to external websites to reduce exposure to malicious content	IT or network security	Filtering policy and categories, block logs, exception approvals
8.28 Secure coding	Apply secure coding principles to software development	Engineering	Coding standard, review and scan results, training records

Organisational controls: 5.7, 5.23 and 5.30

5.7 Threat intelligence

ISACA's summary of 27002 describes collecting and analysing information on existing and emerging threats and sharing intelligence with external organisations on a mutual basis. A minimum viable implementation is a short list of sources (national CERT advisories, sector ISAC, vendor advisories for your estate), a named analyst, a monthly or quarterly threat summary, and a log of decisions it triggered, such as a patch priority change or a new detection rule. The output that convinces an auditor is the decision log, not the subscription list. Large organisations split strategic, operational and tactical outputs and measure how many detections came from intelligence. See the Threat Intelligence Guide and, for identity-specific feeds, the Threat Intelligence for Identity and NHI Guide.

5.23 Information security for use of cloud services

The control covers the whole life cycle: acquisition, use, management and exit. ISACA's summary points to a topic-specific cloud policy, a defined way of managing cloud risk, documented responsibilities of provider and customer, and cross-references to ISO/IEC 27017 and ISO/IEC 27018. Build a cloud service register (owner, data classification, region, authentication method, logging status), attach the provider's shared responsibility model to each entry, and write an exit plan for any service holding critical data. The common audit gap is shadow SaaS bought on expenses and never registered. Customer-side configuration errors are the usual cause of cloud exposure: the Firebase misconfigurations of 2024 exposed more than 125 million records because backends had missing or incorrect security rules.

5.30 ICT readiness for business continuity

This control connects the continuity programme to IT. ICT strategies should come from the business impact analysis and ICT risk assessment and cover before, during and after disruption; ISACA points to ISO 22301, ISO 22313 and ISO/TS 22317. The test is simple: for each critical service, is there an agreed recovery time objective and recovery point objective, and has a restore been tested against them in the last year? Include identity infrastructure, because recovery fails if the directory, privileged access tooling or the secrets store cannot be restored first. See the Business Continuity and Disaster Recovery Guide and the ISO 22301 Business Continuity Guide.

Physical control: 7.4 physical security monitoring

Premises should be continuously monitored for unauthorised physical access, using surveillance, intruder alarms or video monitoring as the risk requires. ISACA's summary adds three points auditors check: monitoring system design is kept confidential, the systems are protected from unauthorised access and remote disabling, and local law on personal data and staff monitoring shapes coverage and video retention. In a shared office or a co-location facility, evidence may come from the landlord or provider: obtain it in writing. Treat CCTV and alarm systems as networked assets in your inventory, with patched firmware and no default passwords. See the Physical Security Guide for Security Teams and the Physical Access Control Systems Security Guide.

Technological controls: 8.9 to 8.12

8.9 Configuration management

The control expects processes and tools to enforce configurations on new and operational systems, including cloud services, defined roles for configuration change, standard secure templates, recorded configurations with logged changes, and regular review. ISACA notes that 27002 expects this to be documented, as a procedure or a separate configuration process. A practical baseline uses published benchmarks (for example CIS Benchmarks) as templates, a configuration management or policy-as-code tool to detect drift, and a weekly drift report with exceptions tied to change tickets. See the NIST SP 800-128 Security-Focused Configuration Management Guide.

8.10 Information deletion

Information stored in systems, devices or media should be deleted when no longer required. This needs three things: a retention schedule that says when "no longer required" arrives for each record type, a mechanism that deletes on schedule (lifecycle policies in storage, automated jobs in applications), and a sanitisation method for media leaving your control. NIST SP 800-88 Revision 2, Guidelines for Media Sanitization (final, September 2025), is the common reference for choosing sanitisation techniques, including cryptographic erase. Keep certificates of destruction from disposal suppliers. Remember backups and logs: a record deleted from production but kept in a seven-year backup is not deleted.

8.11 Data masking

Masking should follow the access control policy, business requirements and applicable law, with the purpose of limiting exposure of sensitive data including personal data. The two places auditors look are production screens (do support staff see full card numbers or national identifiers?) and non-production environments (is test data copied from production?). Implement static masking for test data, dynamic masking or field-level permissions in applications, and pseudonymisation where analytics needs linkable records. See the Tokenisation and Data Masking Guide.

8.12 Data leakage prevention

Leakage prevention measures apply to systems, networks and devices that process, store or transmit sensitive information, with the aim of detecting and preventing unauthorised disclosure by people or systems. The measure need not be a single DLP product: email rules, cloud sharing restrictions, removable media control and egress filtering all count if they cover your sensitive data channels. Start in monitor mode, tune on real alerts, then block on the highest-confidence rules. Evidence is the policy set mapped to data classes and a sample of handled alerts. See the Data Loss Prevention (DLP) Guide.

Technological controls: 8.16, 8.23 and 8.28

8.16 Monitoring activities

Networks, systems and applications should be monitored for anomalous behaviour, with action taken to evaluate potential incidents. 8.15 Logging (a merged control) produces the records; 8.16 is about watching them. Define a baseline of normal behaviour for key systems, a list of detection use cases, and a triage process with records. Include non-human identities: a service account authenticating from a new location or an API key used outside its normal pattern is exactly the anomaly this control targets. Evidence is the use case list, log source coverage against the asset inventory, and closed triage tickets.

8.23 Web filtering

Access to external websites should be managed to reduce exposure to malicious content. In practice that means blocking known-malicious and newly registered domains, categories your policy prohibits, and file types you cannot inspect, applied on and off the corporate network. Remote and roaming users are the common gap: filtering that only works on the office proxy does not meet the control for a hybrid workforce. See the Secure Web Gateway and Web Filtering Guide.

8.28 Secure coding

Secure coding principles should be applied to software development, to reduce vulnerabilities. The control covers planning, during coding and review, and applies to code you write, including scripts and infrastructure as code, and to how you handle third-party and open source components. Evidence is a coding standard, pre-merge review and automated scanning (static analysis, dependency and secret scanning), developer training records and a vulnerability remediation record. Hard-coded credentials are a frequent finding, so include secret scanning in the pipeline. See the Secure Coding Guide.

Rolling out the controls

Re-read your SoA. For each of the 11 controls, record the owner, implementation status, justification and evidence location. Rewrite any exclusion that lacks a risk-based reason.
Gap check in a day. Run a one-hour session with each owner to answer: what exists, what is documented, what evidence can we show from the last three months?
Fix documentation first where 27002 expects it. Configuration management (8.9) and information deletion (8.10) usually need a procedure and a retention schedule before the technology changes.
Pilot the operational controls. Run DLP and web filtering in monitor mode on one business unit; prove recovery for one critical service under 5.30.
Connect the controls. Feed threat intelligence into monitoring rules, add cloud services to log sources, include DLP and filtering settings in configuration baselines.
Internal audit before surveillance. Sample each control as the certification body would, record nonconformities and corrective actions. See the ISO 27001 Internal Audit Programme Template.

Rollback is straightforward for operational controls in monitor mode: they can be switched off without business impact. Blocking rules should go live with an exception route and a named approver. A small organisation with one office and mostly SaaS can meet several controls through provider features and contracts (web filtering in the endpoint agent, DLP in the email and collaboration suite, monitoring through a managed service), but still needs its own owner and evidence. A large organisation should assign each control to a single accountable owner even when delivery is spread across teams.

Detection and measurement

Intelligence-driven actions: number of patches reprioritised or detections added from threat intelligence each quarter (5.7).
Cloud register coverage: percentage of cloud services found in expense, SSO or network data that appear in the register with an owner (5.23).
Recovery tested: percentage of critical services with a successful restore test against RTO and RPO in the last 12 months (5.30).
Configuration drift: open drift items older than 30 days (8.9).
Deletion on schedule: percentage of record types with an automated deletion mechanism (8.10).
Monitoring coverage: percentage of in-scope assets sending logs to monitoring, and median triage time (8.16).

Common failure patterns

Applicable on paper only. The SoA says "implemented" but no owner can show output from the last quarter.
Threat intelligence as a newsletter. Feeds arrive in a mailbox and nobody records a decision made from them.
Cloud register missing SaaS. Infrastructure accounts are registered; collaboration and AI tools bought by departments are not.
Deletion ignores backups and logs. Retention rules apply to the database but not to its copies.
Masking stops at production. Test environments hold full copies of live personal data.
Filtering only on the office network. Remote users browse unfiltered.

Framework mapping

ISO/IEC 27001:2022 Annex A	NIST SP 800-53 Rev. 5 (closest)	NIST CSF 2.0 (closest)
5.7 Threat intelligence	PM-16 Threat Awareness Program	ID.RA-02
5.23 Cloud services	SA-9 External System Services	GV.SC-05
5.30 ICT readiness	CP-2 Contingency Plan, CP-4 Contingency Plan Testing	PR.IR-03
7.4 Physical security monitoring	PE-6 Monitoring Physical Access	DE.CM-02
8.9 Configuration management	CM-2 Baseline Configuration, CM-6 Configuration Settings	PR.PS-01
8.10 Information deletion	MP-6 Media Sanitization, SI-12 Information Management and Retention	PR.DS-01
8.12 Data leakage prevention	SC-7 Boundary Protection	PR.DS-02
8.16 Monitoring activities	SI-4 System Monitoring	DE.CM-01
8.28 Secure coding	SA-11 Developer Testing and Evaluation, SA-15 Development Process, Standards, and Tools	PR.PS-06

These mappings are NHI Mgmt Group's closest-fit judgements, not an official crosswalk. For full mappings, see the NIST SP 800-53 to ISO 27001 Mapping Guide and the NIST CSF to ISO 27001 Mapping Guide.

Practitioner checklist

Name one accountable owner for each of the 11 controls and record it in the SoA.
Replace any exclusion of 8.11 or 8.23 that lacks a risk-based justification.
Keep a threat intelligence decision log and review it quarterly.
Build a cloud service register with owner, data class, shared responsibility model and exit plan.
Test restore of every critical service, including identity infrastructure, against agreed RTO and RPO.
Publish secure configuration baselines and report drift weekly.
Extend the retention schedule to backups and logs, and keep sanitisation certificates.
Stop copying unmasked production personal data into test environments.
Apply web filtering to remote and roaming devices, not only the office network.
Add secret scanning and dependency scanning to the development pipeline.

ISO 27001:2022 New Controls: Implementing the 11 Additions Auditors Focus On