The eleven new ISO 27001:2022 controls that catch first-time implementers

ISO/IEC 27001:2022 restructured Annex A into 93 controls across four themes and introduced eleven that did not exist in the 2013 edition. Organisations transitioning from 2013 generally handle nine of them comfortably. Four reliably cost weeks.

The new controls are:

• 5.7 Threat intelligence
• 5.23 Information security for use of cloud services
• 5.30 ICT readiness for business continuity
• 7.4 Physical security monitoring
• 8.9 Configuration management
• 8.10 Information deletion
• 8.11 Data masking
• 8.12 Data leakage prevention
• 8.16 Monitoring activities
• 8.23 Web filtering
• 8.28 Secure coding

Below, the four that consistently cause difficulty, and what a competent auditor actually looks for.

8.10 Information deletion#

This is the hardest of the eleven for most organisations, and the reason is architectural rather than procedural.

The control requires that information stored in information systems, devices or other storage media is deleted when no longer required. Writing the policy takes an afternoon. Demonstrating deletion is a different matter.

The questions an auditor will ask:

• Where does this data class exist? All the places, including replicas, analytics copies, caches, message queues and object storage lifecycle-transitioned to cold tiers.
• What triggers deletion, and is that trigger automated or dependent on someone remembering?
• What happens in backups? A record deleted from production and present in a backup taken yesterday is retained for the backup's retention period.
• How do you evidence that deletion occurred rather than that it was scheduled?

The DPDPA erasure obligation and GDPR's right to erasure both land on the same underlying capability, so this control is worth doing properly rather than minimally.

8.9 Configuration management#

The control requires that configurations of hardware, software, services and networks are established, documented, implemented, monitored and reviewed.

Two failure modes:

No baseline. The organisation has hardened systems but no documented target configuration, so "monitored and reviewed" has nothing to compare against. The fix is a defined baseline per system class — CIS benchmarks are an acceptable and defensible starting point — with documented deviations.

Drift undetected. A baseline exists and was applied at build time. Nobody checks whether it still holds. An auditor asks to see the current configuration of a sampled system against the baseline and finds three deviations nobody knew about.

For cloud-native organisations this control is comparatively easy, because infrastructure-as-code is the documented baseline and drift detection is a standard capability. For organisations with long-lived servers and manual builds it is real work, and the honest sequencing is to establish the baseline first and add monitoring second rather than trying to do both at once.

8.16 Monitoring activities#

Networks, systems and applications must be monitored for anomalous behaviour, with appropriate action taken to evaluate potential incidents.

The gap here is rarely tooling. Most organisations have a SIEM or equivalent. The gap is coverage justification.

The auditor's question is not "do you have monitoring" but "how did you decide what to monitor". Without an answer, you have log collection rather than a monitoring control.

What works is a documented coverage rationale: threat scenarios relevant to your organisation, the detection use case that addresses each, the log source it depends on, and the gaps you have accepted with reasoning. Mapping use cases to MITRE ATT&CK techniques makes this concrete and gives you a maturity measure over time.

Certification delays of a month or more are common when an organisation with an expensive, well-tuned SIEM cannot explain how its rule set was chosen.

5.7 Threat intelligence#

Information relating to information security threats must be collected and analysed to produce threat intelligence.

The trap is scale. Organisations read this and conclude they need a threat intelligence platform and a subscription. For most, that is disproportionate and the auditor will not require it.

What is required is that intelligence is collected, analysed and used. A defensible minimal implementation:

• Named sources — CERT-In advisories, sector CERT feeds, vendor security bulletins, your cloud provider's security notifications.
• A defined cadence for review, with an owner.
• A record of decisions taken as a result: patches prioritised, detection rules added, an assessment that a given advisory did not apply and why.

The third item is what makes it a control rather than a subscription. An auditor asked to see evidence will accept a monthly review record showing three advisories assessed and one acted upon. They will not accept a login to a threat feed.

The transition deadline and what it means#

Organisations certified to ISO 27001:2013 must complete transition to the 2022 revision at their next recertification. In practice that means the work needs to be done a full audit cycle before the certificate expires, because a surveillance audit is not the place to discover a gap in four new controls.

A note on control exclusion#

Annex A is a reference set, not a mandatory checklist. The Statement of Applicability is where you justify inclusions and exclusions against your risk assessment, and excluding a control with documented reasoning is entirely legitimate.

A fully remote organisation with no premises does not implement physical security monitoring. An organisation that stores no data requiring obfuscation may reasonably exclude data masking.

What auditors challenge is exclusion without reasoning, or reasoning that contradicts the risk assessment. "Not applicable" is not a justification; "we hold no personal data in non-production environments, enforced by control 8.33, therefore masking is not required" is.

The other seven, briefly#

The remaining new controls are less troublesome, but each has one detail that decides whether an auditor is satisfied.

5.23 Information security for use of cloud services. The detail is the lifecycle: acquisition, use, management and exit. Exit is what gets asked about and what nobody has documented. Have a tested export path for each material cloud service.

5.30 ICT readiness for business continuity. The detail is that recovery objectives must derive from a business impact analysis, not from what your infrastructure happens to achieve. An RTO chosen because it was attainable will be challenged.

7.4 Physical security monitoring. The detail is retention and review. Cameras that record but are never reviewed, with no defined retention, do not satisfy a monitoring control.

8.11 Data masking. The detail is non-production environments. This is where auditors look, and where copies of production data most often sit unmasked.

8.12 Data leakage prevention. The detail is proportionality. Full DLP tooling is not required for every organisation; a documented risk-based decision about channels and data classes is.

8.23 Web filtering. The detail is the exception process. A blocklist with no documented route for legitimate business need generates workarounds, and the auditor will find them.

8.28 Secure coding. The detail is evidence rather than policy. A secure coding standard nobody references satisfies nothing; a pipeline check plus a code review record satisfies it plainly.

Scope is the decision that sets the cost#

More certification budget is lost to scope than to any control on the list, and the decision is made in week one when the team knows least.

Two failure modes, opposite in shape:

Too broad. Every entity, every location, every system, because it felt safer. The result is a risk assessment spanning environments nobody in the room understands, an internal audit that cannot finish, and a Stage 2 that surfaces gaps in a subsidiary the core team has never visited.

Too narrow. Scoped so tightly that the certificate excludes the service the buyer is actually purchasing. The scope statement appears on the certificate, so the buyer will read it. A certificate covering "corporate IT" when the customer buys your SaaS platform is worse than none — it reads as an attempt to mislead.

The workable rule: scope to the product and the teams that build and run it, plus the shared services they genuinely depend on. Then write the scope statement and read it as a sceptical procurement analyst would. If it does not obviously cover what you sell, widen it before you start rather than during Stage 2.

Our ISO 27001:2022 Implementation Guide sets out a twenty-week plan including implementation notes for all eleven new controls and the eight mistakes that most reliably add time to a certification.