What are the 11 new controls in ISO 27001:2022 Annex A?
A customer, contract or regulator now asks for ISO 27001:2022, so the first question is what changed in Annex A. IAF MD 26:2023 counts 11 new controls in the 93-control Annex A: A.5.7 (threat intelligence), A.5.23 (information security for cloud services), A.5.30 (ICT readiness for business continuity), A.7.4 (physical security monitoring), A.8.9 (configuration management), A.8.10 (information deletion), A.8.11 (data masking), A.8.12 (data leakage prevention), A.8.16 (monitoring activities), A.8.23 (web filtering) and A.8.28 (secure coding). Three of them sit in the organizational theme (A.5.7, A.5.23 and A.5.30), one in physical controls and seven in technological controls.
The controls are the same for every organization, but the work to meet each one depends on the systems in scope. A cloud-hosted SaaS vendor will spend most of its effort on A.5.23 and A.8.12, while a company with on-premises databases may focus on A.8.10 and A.8.11. Start by mapping each new control to the assets, suppliers and environments in your ISMS scope, then record which existing procedure, tool or log already covers it and where a gap remains. Confirm the exact wording and attributes of each control in ISO/IEC 27002:2022 before you write your Statement of Applectability entries.
Your organization owns its controls and the evidence that they operate. An implementation partner can help configure systems, write procedures and collect records, but only an independent certification body issues an ISO 27001 certificate, and it does so after an audit against the standard. Ask any partner to state in writing which tasks it performs and which remain with your staff, and check the certification body's accreditation through the IAF CertSearch database before you commit to a timeline.
Which new organizational controls (A.5.7, A.5.23, A.5.30) ask for
ISO 27001:2022 added three controls to the organizational theme that did not exist in the 2013 edition: threat intelligence, cloud services and ICT readiness. Each one asks the organization to make a standing capability visible, documented and reviewed, so the assessor can see it working rather than only described in a policy.
Threat intelligence (A.5.7)
A.5.7 asks the organization to collect and analyze information about threats to its information security, and to use that analysis to reduce risk. The assessor typically looks for a defined set of sources, such as a national computer emergency response team, sector information sharing groups or vendor advisories, and for evidence that someone reviews them on a schedule. Check that each intelligence item leads to a recorded decision, such as a patch, a detection rule or a risk register update. A common gap is a subscription to feeds with no record of what was done with them.
Cloud services security (A.5.23)
A.5.23 asks the organization to set and manage how it acquires, uses, manages and exits cloud services, with security requirements that match its risk assessment. For a self-hosted platform running in the client's own cloud account, the organization still owns the shared responsibility split with the provider. Evidence usually includes a cloud service inventory, the security terms in each contract, configuration baselines and exit plans. A common gap is an inventory that omits services adopted informally by teams, such as software-as-a-service tools bought on a corporate card.
ICT readiness for continuity (A.5.30)
A.5.30 asks the organization to plan, implement, maintain and test ICT readiness so that information security and availability objectives survive a disruption. In practice, the assessor looks for recovery objectives agreed with the business, documented recovery procedures for the systems in scope and test records showing that restores or failovers worked. This control links directly to business continuity management, which is covered in the integration topic for ISO 9001 and ISO 22301. A common gap is recovery targets set by the IT team that the business owners never approved.
How the new technological controls work in practice
A.7.4 Physical security monitoring asks the organization to watch its premises for unauthorized physical access, using measures such as cameras, intrusion sensors and access logs. An assessor first checks that monitoring covers the secure areas in the scope, such as server rooms, storage and equipment cages, and that the method matches the risk assessment. The assessor then samples alerts and reviews to see whether anyone acted on them.
- Coverage map: a current floor plan that shows cameras, sensors and access points against each secure area in the scope.
- Retention and access: the settings for how long footage and logs are kept, who can view them, and how each viewing is recorded.
- Alert handling: a trail showing that alarms were triaged, escalated and closed, linked to the incident management process.
- Provider responsibilities: where a data center or colocation provider runs the monitoring, the contract clauses and the provider's own assurance evidence.
- Platform integration: where camera and access logs feed a central log platform, the retention and integrity settings for those feeds.
Ask facilities whether monitoring is continuous or periodic for each area, and ask the platform team which physical log sources reach the central log store.
A.8.9 Configuration management asks the organization to define, document, apply and monitor security-relevant configurations for hardware, software, services and networks. A.8.10 Information deletion asks it to remove information from systems, devices and storage when that information is no longer needed, while respecting legal and contractual retention duties. An assessor compares documented baselines with running systems, samples drift findings and change records, and traces deletion from the retention schedule to the job logs that show it happened.
- Baseline standards: hardened build standards for each platform type, version controlled, with an owner and a review date.
- Drift detection: scheduled comparisons between running settings and the baseline, with each finding tracked to closure.
- Retention schedule: the data classes to be deleted, the period for each, and the legal holds that override deletion.
- Deletion evidence: job logs, vendor erasure records or cryptographic erasure records, and confirmation of deletion from storage.
- Backup handling: a documented position on how deleted data expires from backup copies, since this is a common assessor question.
Request the baseline repository and one complete deletion job log, and confirm with the platform vendor which deletion steps are native and which depend on custom scripts.
A.8.11 Data masking asks the organization to limit exposure of sensitive data through masking, pseudonymization or anonymization, in line with its access control policy and business needs, including in test and analytics environments. A.8.12 Data leakage prevention asks for measures that detect and prevent unauthorized disclosure or extraction of sensitive information through channels such as email, endpoints and uploads. An assessor checks the classification scheme that drives both controls, the masking rules applied outside production, and the rule sets and alert history for leakage prevention.
- Classification input: the data classes that masking and leakage rules depend on, traced back to the information classification scheme.
- Non-production data: masked or synthetic copies used for testing and analytics, with a record of the method used and who approved it.
- Leakage rules and tuning: documented policies for each channel in scope, with a regular review of false positives and missed events.
- Exception handling: approvals for disclosures the business needs, each with an owner and a review date.
- Open-source coverage: self-hosted options exist for parts of masking and outbound inspection, but depth varies, so confirm each tool's capabilities against the channels in your risk assessment.
Ask for a sample of masked test data and the leakage alert history for the last review period, and confirm which channels the chosen tools inspect in practice.
A.8.16 Monitoring activities asks the organization to monitor networks, systems and applications for anomalous behavior and to evaluate possible incidents. A.8.23 Web filtering asks it to manage access to external websites to reduce exposure to malicious content. A.8.28 Secure coding asks it to apply secure coding principles to software development. Guidance on these controls appears in ISO/IEC 27002:2022. An assessor reviews detection use cases, alert triage records, filtering policies and blocked-request logs, then samples development evidence such as code review records and static analysis findings.
- Monitoring scope: a list of log sources and detection use cases, each with an owner and a review cycle.
- Web filter policy: the categories blocked, the exception process, and logs of blocked and allowed requests.
- Secure coding standard: written guidance, peer review gates, and static analysis findings tracked to closure.
- Build pipeline checks: dependency and build checks recorded as part of the development evidence for each release.
- Partner role: an implementer can configure log pipelines, filtering rules and pipeline gates, but the organization must own detection tuning, triage decisions and secure coding approval.
Request a month of alert triage records and the pipeline definition, and confirm which scanners and filtering categories your chosen platform supports.
How an assessor tests a new control during the audit
The sequence confirms that each of the 11 new Annex A controls is recorded, designed, operating and owned by people who can explain it. Each step produces a finding or a piece of evidence the certification body can cite in its report.
Check the Statement of Applicability entry
The assessor starts with the Statement of Applicability and looks for each new control, such as A.5.7 threat intelligence or A.8.28 secure coding, to confirm it is marked as applicable or excluded. For an applicable control, the entry should state how it is implemented and why it was selected, tied to the risk treatment plan. For an exclusion, the justification must hold up against the risk assessment. The step closes with a recorded finding for each control that is complete, missing or inconsistent with the risk treatment.
Review the documented process and its design
Next the assessor reads the documented procedure, standard or configuration baseline that the organization uses for the control, such as a configuration management procedure for A.8.9 or a data masking rule set for A.8.11. The question is whether the document says who does what, with which tools, and how exceptions are handled. The assessor also checks that the document is approved, version-controlled and aligned with the policies under the top-level information security policy. The output is a design observation for each control, which may be accepted or raised as a gap before operating testing begins.
Confirm the control is in operation
The assessor then checks whether the process runs in practice, using the tool or record that the procedure names. For A.7.4 physical security monitoring, this may mean reviewing monitoring alarm logs and their follow-up. For A.8.23 web filtering, it may mean reviewing blocked-category logs and policy change records. The assessor does not rely on a single screenshot taken for the audit. The output is a note on whether the control operated as designed during the period under review.
Sample operating evidence over the audit period
The assessor selects a sample of records spread across the audit period and traces each one back to its source. Typical samples include change tickets for configuration management, deletion certificates or logs for information deletion under A.8.10, and alerts with triage notes for A.8.16 monitoring activities. The sample size and selection method follow the certification body's procedures. Gaps in the sample, missing records or records that do not match the documented process are recorded as nonconformities or observations. The step closes when each sampled item has a recorded result.
Interview the control owners
The assessor interviews the people who run each control, such as the threat intelligence analyst, the cloud service owner or the engineer responsible for secure coding standards. The interview tests whether the owner can explain the purpose, the steps, the tools and the escalation path, and whether their explanation matches the documents and records. Inconsistent answers lead the assessor to sample more evidence. The output is a set of interview notes linked to each control, which the assessor uses to finalize the findings.
Record findings and agree corrective actions
The assessor consolidates the statement, design, operating and interview results into findings for each control and classifies any gaps as nonconformities or observations. The organization reviews the draft findings, confirms facts it can support with evidence, and proposes corrective actions with owners and target dates. The assessor reviews those actions before the audit closes. The output is the audit report section for each new control, which only the certification body issues.
What changes for an organization already certified to ISO 27001:2013
If your organization still holds an ISO/IEC 27001:2013 certificate, the 2022 controls already apply to you. Under IAF MD 26:2023, all 2013 certifications had to expire or be withdrawn by 31 October 2025, the end of the 36-month transition period. Any certificate you hold today is therefore issued against the 2022 text, and the 11 new Annex A controls are part of what an assessor will test at your next audit. The first decision is to confirm with your certification body which edition your certificate and audit plan reference, so that no one plans work against the wrong control set.
The 11 new controls are not a relabeling of older ones. Several, including A.7.4 Physical security monitoring, A.8.9 Configuration management, A.8.10 Information deletion and A.8.23 Web filtering, have no counterpart in the 2013 edition, so your existing Statement of Applicability cannot simply be carried forward. Run a gap assessment against the 2022 text: for each new control, record whether a process, technical setting or record already exists, who owns it, and where its evidence is kept. Expect the gaps to be concentrated in technical controls where no tooling or log has ever been collected.
The new controls are only part of the change. IAF MD 26:2023 also records 24 merged controls and 58 updated controls, and an updated control can fail an audit even when its control ID looks familiar. Review each updated control against its new attributes and purpose, and check whether any merged control now covers responsibilities that were previously split across two owners. Ask your certification body how it will sample these changes at the next visit, and document the outcome of your review so the auditor can trace it.
What evidence shows each new control is operating
The eleven new Annex A controls rarely rely on a single artifact. Each one is shown to work through a mix of written decisions, system records and recurring outputs that an auditor can trace back to the control. Confirm with your certification body which of these forms it accepts and how far back it will look.
Documented procedures and approvals
Each new control needs a written procedure that says who performs the activity, how often, and where the output is stored. For A.5.7 threat intelligence, that means a defined process for collecting, analyzing and acting on threat information. For A.8.10 information deletion, it means a documented method for removing data no longer needed. Ask your auditor whether it expects version history, owner sign-off and a review date on each procedure.
Risk decisions in the Statement of Applicability
The Statement of Applicability records whether each Annex A control applies and why. For the new controls, auditors look for a justification that matches the risk assessment, especially where a control is excluded or handled through another control. A.7.4 physical security monitoring, for example, should be justified by the sites and assets actually in scope. Confirm with your certification body how it expects exclusions to be reasoned and approved.
Configuration baselines and change records
A.8.9 configuration management is shown by approved baseline configurations for servers, containers, cloud accounts and network devices, plus records of changes made against them. Infrastructure as code repositories with reviewed commits can serve as this evidence when deployments are traceable. Check whether your auditor will accept pipeline logs and pull request approvals as the change record, and how it wants drift between baseline and running systems reported.
Access and data handling logs
Data masking under A.8.11 and data leakage prevention under A.8.12 leave traces in access logs, masking rule sets and policy alerts. A masking record should show which fields were masked, for which environments, and who approved any exception. Ask your auditor which log retention period it expects and whether it will sample logs or require a continuous export.
Deletion certificates and masking records
A.8.10 information deletion needs proof that data was removed when retention ended, not only a retention schedule. Deletion job logs, storage lifecycle reports and, where data went to a third party, written confirmation from that party are the usual artifacts. Confirm with your auditor how it will verify backups and replicas that are scheduled for later expiry.
Monitoring and filtering outputs
A.8.16 monitoring activities and A.8.23 web filtering produce recurring outputs: alert queues, blocked-category reports and tickets showing how anomalies were investigated. Auditors generally look for evidence that someone reviewed these outputs and acted, not only that the tool was switched on. Ask your certification body how it expects review frequency and follow-up to be recorded.
Which parts the organization owns and which an implementation partner can prepare
The organization owns the decisions that make its ISMS its own. Scope, risk treatment and control ownership cannot be handed to a partner. For the new controls, that means deciding whether A.5.7 threat intelligence, A.8.9 configuration management or A.8.12 data leakage prevention applies at all, what the risk assessment says about them, and which named role answers for each one. The Statement of Applicability records those choices, and the people who sign it must be inside the organization. An implementation partner can draft options and explain the trade-offs, but the accountable decisions and their justification stay with leadership and the control owners.
An implementation partner such as DeployOpen works on the other side of that line. In the client's own cloud accounts, data centers or air-gapped networks, a partner can prepare the systems the controls depend on: configuration baselines, logging and alerting for monitoring activities, data masking and deletion routines, web filtering and secure coding checks in the delivery pipeline, and the collection of evidence such as exports, change records and access reviews. Ask any partner to put in writing which systems, configurations and evidence sets are in scope, who maintains them after handover, and where the evidence is stored. Because DeployOpen does not issue reports or certificates, the partner's output is inputs to the audit, not the audit itself.
The independent certification body or auditor assesses the controls against the standard and decides whether the organization is certified. That assessment cannot be bought in advance. Hiring a partner does not guarantee a certification result. A well-prepared system can still produce nonconformities if the risk assessment is weak, the owners do not know their duties, or the evidence does not show the control operating over time. Confirm with any certification body how it plans its audit and which of its auditors will review the new controls, and keep the partner and the auditor independent of each other so that the organization can rely on the result.
Questions about the 2022 Annex A changes
Do we have to implement all 11 new Annex A controls?
No. Annex A controls are not automatically mandatory. Each organization decides which controls apply through its risk assessment and risk treatment, and records the result in the Statement of Applicability. A control can be excluded, but the exclusion must be justified in the Statement of Applicability, and the reason must be consistent with the risk assessment. In practice, most of the 11 new controls, such as configuration management (A.8.9), data leakage prevention (A.8.12) and secure coding (A.8.28), will apply to organizations that build software, store personal data or run technical infrastructure. A business with no development activity may have a different answer for A.8.28. Ask your certification body how it expects exclusions to be documented before you finalize the Statement of Applicability.
Can our own team implement the 11 new controls without a consultant?
Often yes, if the team has the time and the right technical skills. The organization owns its controls, so internal staff can design the policies, configure the systems and collect the evidence. An outside implementation partner can prepare systems, controls and evidence, but it cannot issue a certificate, and the certification body must remain independent of whoever helped you build the ISMS. The areas that usually need the most specialist input are the technical controls, such as data masking (A.8.11), web filtering (A.8.23) and monitoring (A.8.16), because they depend on how your environment is built. Decide early which parts your staff will own, and whether any part needs a scoped engagement agreed in writing before work starts.
How long does it take to implement the 2022 control changes?
The time depends on the scope of the ISMS, the number of systems and sites involved, how much of the environment already has documented processes, and how many teams must change how they work. No duration is given here because the work varies widely between organizations. The 11 new controls are not separate projects: several, such as threat intelligence (A.5.7), ICT readiness for business continuity (A.5.30) and information deletion (A.8.10), touch existing processes that may already exist in part. Ask any consultant or implementation partner for a written plan that lists the systems in scope, the deliverables and the dependencies, and treat any timeline that is not tied to that scope with caution.
What do the new controls require from our staff?
Most of the 11 new controls need participation from more than the security team. Engineering staff are involved in configuration management (A.8.9), secure coding (A.8.28) and information deletion (A.8.10). Infrastructure and cloud teams own data leakage prevention (A.8.12), web filtering (A.8.23) and monitoring. Facilities or site managers handle physical security monitoring (A.7.4). Procurement or legal staff are often needed for cloud services (A.5.23) and supplier terms. Plan for recurring effort, not only one-time setup: reviews, access checks, log reviews and records of changes all continue after the first assessment. Name an owner for each control and make sure the owner understands what evidence they must keep.
What does the 2022 edition mean for an existing ISO 27001:2013 certificate?
Under IAF MD 26:2023, all certifications to ISO/IEC 27001:2013 had to expire or be withdrawn by 31 October 2025, the end of the 36-month transition period. A 2013 certificate is therefore no longer valid. An organization that still holds the 2013 certificate must work with its certification body to move to the 2022 edition, which means mapping the 2013 controls to the 2022 Annex A, updating the Statement of Applicability and covering the new and updated controls in its audit. Confirm the current status of your certificate directly with your certification body and check it in the IAF CertSearch database, since ISO still points to that database for checking accredited certificates.
Are the mappings between ISO 27001:2022 and other frameworks authoritative?
Not by themselves. Mappings between ISO 27001:2022 and frameworks such as NIST SP 800-53, NIST CSF 2.0 or ENISA's NIS2 guidance are published as crosswalks by other organizations, and they reflect those authors' judgments about how controls relate. They can help you find overlapping evidence, but a control that appears mapped may still not meet the requirement in your own environment. Before relying on any mapping, open the source document, read the control text and confirm the relationship with the publisher or your certification body. Do not treat a crosswalk as proof that a single piece of evidence satisfies two frameworks.
Where to read the official text and transition rules
This sequence points you to the three official sources that define the 11 new Annex A controls, the transition rules that apply to them, and how to confirm you are working from the current text before you write any control documentation.
Get the ISO/IEC 27001:2022 text from ISO
Start with the standard itself, published by ISO and available from its catalogue page for ISO/IEC 27001. Read the clauses on context, leadership, planning and support first, then Annex A, which is normative and lists the 93 controls in four themes. Find the 11 new controls by their IDs in the organizational, physical and technological sections, and note their titles exactly as printed. The step is complete when you can list the new control IDs from memory without relying on a secondary summary. Buy the official copy from ISO or a national member body, since the text is copyrighted and should not be copied into internal documents.
Read the control guidance in ISO/IEC 27002:2022
Next, open ISO/IEC 27002:2022, which gives guidance on each Annex A control. For every new control, read the attributes, purpose and guidance sections and write down what the control asks an organization to decide, document and operate. ISO/IEC 27002 is guidance, not a certifiable standard, so use it to design your implementation rather than as a checklist an auditor will score. The step is complete when each new control has a short working note in your own words that names the owner, the decision it requires and the evidence you expect to keep.
Confirm transition rules in IAF MD 26:2023
Read the IAF mandatory document MD 26:2023, which sets the transition requirements for moving from ISO/IEC 27001:2013 to the 2022 edition. It summarizes the change as 11 new controls, 24 merged controls and 58 updated controls, and it records the date by which 2013 certificates had to expire or be withdrawn. Note the transition obligations that apply to your certification body and to your own certificate. The step is complete when you can state, in writing, which edition your certificate and your Statement of Applicability reference and whether any transition action is still open for your organization.
Check the current edition with your certification body
Ask your certification body, or the body you plan to engage, which edition of ISO/IEC 27001 its audit plan will use and whether any amendment affects your scope. Confirm that the Amd 1:2024 climate action changes are reflected in your clause 4 context work if the body expects it. Request the body's written audit plan reference for the edition. The step is complete when you hold a written reply from the certification body that names the edition and any amendment it will assess, and you have filed that reply with your ISMS documentation.
Verify accredited certificates in the IAF database
If you rely on another organization's certificate as evidence, or you need to check a certification body's accreditation, use the IAF CertSearch database that ISO points to for accredited certificates. Search by certificate holder or certification body, confirm the standard and edition shown, and record the date you checked. Since 1 January 2026, Global ACI has taken over the IAF and ILAC roles, so confirm the database entry rather than relying on older guidance. The step is complete when you have a dated screenshot or record of each verified certificate in your supplier or customer file.
Record the source version in your control register
Add a source reference to your control register and Statement of Applicability for each of the 11 new controls. Name the edition of ISO/IEC 27001 you used, the ISO/IEC 27002 edition and the IAF document that governed the transition. Assign an owner to review the references when the standards are amended. The step is complete when the register shows, for each new control, the source documents and the review owner, and a second person has checked the entries against the official copies.
How DeployOpen prepares the systems and evidence for the new controls
DeployOpen's role in the new controls is to prepare the systems and evidence, not to decide whether the organization meets them. The work starts with a written scope that names which of the 11 new controls are in play, such as A.8.9 configuration management, A.8.10 information deletion and A.8.12 data leakage prevention, and which platforms, cloud accounts or network segments they touch. Scope, deliverables and timelines are agreed in writing before any work begins, and DeployOpen provides a written quote based on that scope. The organization keeps ownership of its controls, its risk decisions and its Statement of Applicability.
Once the scope is agreed, DeployOpen implements and hardens the self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. Typical technical work includes baseline configuration under version control, controls for data masking and deletion in the systems that hold personal or confidential data, web filtering and monitoring settings, and centralized logging and alerting so that events from the new monitoring and physical security monitoring controls are retained and reviewed. Each setting is documented so the client can show what was configured, when and by whom. Confirm with your own engineers which logs must be retained and for how long, since that decision belongs to the organization.
The output is an evidence pack for each in-scope control: configuration records, change history, log samples, test results and the runbooks that show how the control operates. The client and its independent auditor review that pack. DeployOpen does not issue audit reports, attestations or certifications; only the certification body can do that, and its audit approach determines what evidence it wants. Before engaging, ask the implementation partner to show how it maps each artifact to a control and to state which parts of the evidence the client must still produce itself.
