The 11 New ISO 27001:2022 Controls: Evidence by Control Outcome

ISO/IEC 27001:2022 reorganised Annex A into 93 controls across organisational, people, physical and technological themes. Eleven controls were identified as new relative to the 2013 set. “New” does not mean universally mandatory, and it does not mean organisations had never performed the underlying activities.

Control selection remains risk-based. The organisation must determine necessary controls through risk treatment, compare them with Annex A so none are inadvertently omitted, and explain applicability. Legal, regulatory and contractual requirements can also make a control necessary.

ISO/IEC 27002:2022 provides implementation guidance for information-security controls. It is guidance, not a separately certifiable management-system requirements standard.

The 11 controls at a glance

The publicly identified control names are:

1. A.5.7 Threat intelligence
2. A.5.23 Information security for use of cloud services
3. A.5.30 ICT readiness for business continuity
4. A.7.4 Physical security monitoring
5. A.8.9 Configuration management
6. A.8.10 Information deletion
7. A.8.11 Data masking
8. A.8.12 Data leakage prevention
9. A.8.16 Monitoring activities
10. A.8.23 Web filtering
11. A.8.28 Secure coding

This article does not reproduce standard text. It explains practical outcomes and evidence questions. Use the licensed standards for the authoritative wording.

Read them as outcomes, not purchases

The controls do not automatically require eleven new products or eleven separate policies. An organisation may already address several outcomes through existing processes. The task is to test whether those processes match current risks, scope and obligations.

For each control, record:

• relevant risk or requirement;
• intended outcome;
• owner;
• people, process and technology used;
• implementation boundary;
• operating record;
• effectiveness measure;
• exception handling; and
• Statement of Applicability rationale.

The Annex A selection guide explains how to keep the decision traceable.

Organisational control outcomes

Threat intelligence

The outcome is usable understanding of threats relevant to the organisation, not a feed subscription. Define sources, assessment, distribution and action. Evidence can include intelligence requirements, source evaluation, analysed reports, decisions, changed detection or risk treatment, and review of usefulness.

Weak evidence is a collection of alerts with no relevance assessment. Strong evidence shows that intelligence changed a control, priority or response.

Information security for cloud services

Govern acquisition, use, management and exit of cloud services. Define customer-provider responsibility, service scope, approved configuration, assurance, monitoring, change and termination.

Evidence may include cloud governance rules, service inventory, responsibility records, risk assessments, provider assurance reviews, configuration evidence, incident coordination and exit tests. The ISO 27001 and ISO 27017 comparison provides a deeper cloud-control model.

ICT readiness for business continuity

Connect technology recovery capabilities to business continuity needs. Evidence should reconcile approved recovery objectives with architecture, backup, redundancy, dependencies, procedures, exercises, results and corrective action.

A disaster-recovery document alone is weak if no test demonstrates that the required service and data can be restored within agreed tolerances.

Physical control outcome

Physical security monitoring

Monitor relevant physical areas and events according to risk. The organisation should determine protected zones, methods, legal and privacy constraints, alert ownership, retention and response.

Evidence may include coverage design, access or alarm integration, device health, event samples, response cases, maintenance and periodic coverage review. Camera installation does not prove effective monitoring if blind spots, failed recording or unreviewed alerts persist.

Technological control outcomes

Configuration management

Define secure configurations, approve changes, detect drift and restore intended state. Scope should include infrastructure, cloud, applications, network, endpoints and relevant security services.

Evidence may include approved baselines, configuration repositories, automated policy results, change records, drift cases, exceptions and remediation. A baseline document without comparison to live systems is only design evidence.

Information deletion

Delete information when retention and business needs no longer justify it, subject to legal holds and other obligations. Cover live systems, copies, backups, devices and suppliers according to feasibility and risk.

Evidence can include retention decisions, deletion rules, system jobs, sampled records, supplier confirmations, disposal records, exception handling and validation. “Deleted from the application” may not mean removed from every storage layer.

Data masking

Reduce exposure by substituting, obscuring or otherwise limiting the visibility of sensitive data where full values are unnecessary. Define use cases such as development, support, analytics or demonstrations.

Evidence may include data classification, masking design, access restrictions, transformation tests, re-identification risk evaluation, exception approval and monitoring. Verify the result with representative data; a configured function can still leave sensitive fields exposed.

Data leakage prevention

Identify and reduce unauthorised disclosure across relevant channels. The outcome may combine data governance, endpoint and network controls, access, user behaviour and incident response.

Evidence may include channel risk assessment, detection rules, tuning, alerts, investigations, approved transfers, false-positive handling and lessons. A product licence is not evidence that high-risk channels are covered or alerts are acted upon.

Monitoring activities

Observe systems, networks and applications for abnormal behaviour and security events. Define coverage, use cases, ownership, escalation, retention, time quality and health monitoring.

Evidence can include data-source inventory, ingestion status, detection logic, alert samples, investigation timelines, missed-event analysis and tuning. The incident evidence guide shows how monitored events enter a controlled response process.

Web filtering

Manage access to external web resources according to risk and business need. Consider malicious destinations, inappropriate categories, encrypted traffic, remote users, exceptions and privacy.

Evidence may include policy, category settings, threat intelligence integration, exception approvals, blocked-event samples, alert response and coverage tests. Do not infer effectiveness from a gateway setting if roaming devices bypass it.

Secure coding

Integrate security practices into software development. Tailor coding rules, review, testing, dependency handling, secrets protection and remediation to technologies and risk.

Evidence may include engineering standards, training, repository protections, review records, automated and manual test results, vulnerability remediation, exception decisions and release gates. A training certificate alone does not show that insecure changes are prevented or corrected.

Build evidence across the control lifecycle

For every applicable control, distinguish:

Design: What outcome, scope, ownership and method were approved?

Implementation: What settings, integrations, workflows or safeguards were deployed?

Operation: Which records show performance across the audit period?

Evaluation: How did owners judge effectiveness, handle exceptions and improve the control?

This structure prevents an evidence file from becoming a pile of screenshots. Use the evidence register guide to index proof by control, owner, period and source.

Audit sampling

Do not sample all eleven controls identically. Select populations and records suited to the activity:

• intelligence reports and resulting decisions;
• cloud services and material changes;
• recovery tests and unresolved actions;
• physical alerts and maintenance events;
• configuration drift and exceptions;
• deletion jobs and sampled records;
• masked data flows;
• leakage alerts and investigations;
• monitoring use cases and cases;
• filtering exceptions; and
• code changes and security findings.

Prioritise high-risk systems, recent changes, failed events and exceptions. For each sample, trace risk, approval, implementation, operation and evaluation.

Use the Statement of Applicability builder to structure control rationales, then validate every decision against actual risk treatment and evidence.

Pass, partial and fail examples

Pass: Each applicable control has a risk rationale, defined owner and boundary, implemented safeguards, operating records and effectiveness review. Exclusions are justified and consistent with requirements.

Partial: The controls appear in the Statement of Applicability and technologies are deployed, but evidence is mostly current-state configuration. Exceptions and effectiveness measures are incomplete.

Fail: All eleven controls were declared applicable only because they were new. Owners cannot connect them to risk, several product claims are unsupported, and no period evidence exists.

These examples illustrate evidence maturity, not mandatory audit classifications.

Common mistakes

Avoid:

• treating every new control as compulsory;
• excluding a control without considering obligations;
• buying technology before defining the outcome;
• creating eleven isolated documents;
• reproducing standard language as an implementation plan;
• using one screenshot as proof of operation;
• ignoring supplier and shared responsibilities;
• failing to sample exceptions; and
• updating the Statement of Applicability without updating risk treatment.

The Annex A control lookup provides a quick route to related control themes without replacing the licensed standards.

Practical conclusion

The 2022 additions highlight modern risk areas, but conformity still depends on disciplined selection and effective operation. Treat each control as an outcome connected to risk, assign ownership, implement proportionate measures and retain evidence across time.

The important audit question is not whether an organisation has eleven new artefacts. It is whether applicable risks are addressed through controls that are designed, operating and evaluated.