Which ISO 27001 version applies in 2026?<\/strong><\/h2>ISO\/IEC 27001:2022, with Amendment 1:2024, is the current published edition. There is no separate ISO\/IEC 27001:2026 edition.<\/strong><\/p>The transition deadline for accredited ISO\/IEC 27001:2013 certifications was 31 October 2025<\/strong>. Organizations maintaining certification should confirm their certificate’s current edition, validity, and scope with the issuing certification body. The 2022 revision aligned Annex A with ISO\/IEC 27002:2022 and introduced clause 6.3 on planning changes to the ISMS. Its reference set contains 93 controls across four groups<\/strong>:<\/p>Annex A group<\/strong><\/th>Controls<\/strong><\/th>Examples of areas covered<\/strong><\/th><\/tr><\/thead>Organizational<\/td> 37<\/td> Governance, suppliers, incident management, and continuity<\/td><\/tr> People<\/td> 8<\/td> Employment responsibilities, awareness, and reporting<\/td><\/tr> Physical<\/td> 14<\/td> Facilities, physical access, and equipment<\/td><\/tr> Technological<\/td> 34<\/td> Access, configuration, monitoring, development, and data protection<\/td><\/tr><\/tbody><\/table><\/figure>The reduction from 114 controls does not represent 21 security practices that organizations can discard. Controls were reorganized, merged, and updated. The 2024 amendment adds a requirement to determine whether climate change is relevant to organizational context and a note about related interested-party requirements. It does not add Annex A controls. These facts establish the baseline. The more consequential question is whether your implementation remains accurate as the business changes.<\/p>
1. Keep control scope current<\/strong><\/h2>A control can continue working on its original population while new assets remain outside it. Control scope means the assets, accounts, services or activities that a particular control should cover within the ISMS. Review this population as the environment changes. <\/p>
Endpoint protection may be healthy on enrolled devices, but recently acquired devices may never have enrolled. A privileged access workflow may operate correctly for known administrators while new cloud roles bypass it. Backup jobs may succeed for configured systems while a new critical service remains unprotected.<\/p>
This is why coverage needs a reliable denominator: which assets, accounts, services, or activities should the control cover?<\/strong> For each priority control, establish:<\/p>\n- The service and risk it supports.<\/li>\n\n\n\n
- The population that should be covered.<\/li>\n\n\n\n
- The source used to identify that population.<\/li>\n\n\n\n
- The expected control state.<\/li>\n\n\n\n
- The owner responsible for investigating differences.<\/li>\n<\/ul>
Then define events that trigger review. Examples include a new cloud account, SaaS service, supplier, acquisition, privileged role, or material system change. This does not mean rewriting the SoA whenever an account is created. Keep detailed operational inventories linked to the control implementation. Review the SoA when the change affects applicability, implementation status, or the rationale recorded there.<\/p>
2. Keep the SoA aligned with current control implementation <\/strong><\/h2>The Statement of Applicability (SoA) records necessary controls, their inclusion rationale, implementation status and justified Annex A exclusions. Review these entries when business or technical changes affect the decisions they describe.<\/p>
Keep detailed asset and account inventories linked to the relevant implementation records. A new account may require an inventory update without changing the SoA. A change in control applicability, implementation status or rationale may also require a SoA update.<\/p>
For each applicable control, maintain a clear connection between the SoA entry, its owner, implementation and supporting evidence. This helps keep the documented decisions aligned with how controls operate today.<\/p>![\"\"](\"https:\/\/spog.ai\/blog\/wp-content\/uploads\/2026\/10\/iso-27001_02.png\")
<\/figure>3. Distinguish coverage, health, and effectiveness<\/strong><\/h2>Coverage, health, and effectiveness are practical assessment dimensions, not three formal categories prescribed by ISO 27001. They reveal different weaknesses:<\/p>Question<\/strong><\/th>What it establishes<\/strong><\/th>Example<\/strong><\/th><\/tr><\/thead>Coverage<\/td> Does the control reach the intended population?<\/td> Are all in-scope privileged accounts included?<\/td><\/tr> Health<\/td> Are the mechanisms supporting the control operating?<\/td> Are required password rotation jobs completing?<\/td><\/tr> Effectiveness<\/td> Does the control achieve its defined objective under the conditions tested?<\/td> Can unauthorized privileged access still occur?<\/td><\/tr><\/tbody><\/table><\/figure>A deployed tool does not answer all three. For example, a PAM inventory can show which accounts are onboarded. Job records can show whether rotation is succeeding. Testing access outside the approved route can reveal whether the intended restriction actually holds.<\/p>
The test should match the objective. A successful backup job establishes something different from a successful restore. Enabled logging establishes something different from a tested detection and response path. Also distinguish failed<\/strong> from unknown<\/strong>. If an evidence feed is stale or a critical population cannot be reconciled, the result lacks sufficient support. It should not silently remain green.<\/p>4. Treat exceptions as governed decisions<\/strong><\/h2>An exception is an ongoing risk decision with defined boundaries. Record its scope, rationale, accountable risk owner, approver, alternative measures where relevant, and review or expiry date. Keep approved deviations distinguishable from unexplained gaps.<\/p>
Review which exceptions remain valid, which have expired and which depend on assumptions that have changed. Where protection depends on an alternative measure, retain evidence that it operates as intended.<\/p>
Repeated exceptions affecting the same control should inform risk assessment and management review. Leadership may need to address a recurring dependency, ownership gap or resource constraint.<\/p>
Example following a new cloud account through to closure<\/strong><\/h3>Consider a new production cloud account supporting a customer-facing application. This is an illustrative scenario, not a reported customer result.<\/p>
The account appears in the cloud inventory but is missing from the population used to assess privileged access. The team confirms that it falls within the existing ISMS scope and that the selected access controls apply. It updates the operational inventory and checks whether the SoA still accurately describes the implementation.<\/p>
Validation finds a direct administrator access path outside the approved privileged access workflow. The security team records the finding, links it to the application and affected identities, and assesses the consequence of unauthorized access. The application owner and risk owner agree on remediation, ownership, and a due date under the organization’s procedure.<\/p>
Where immediate correction could disrupt the service, the authorized risk owner decides whether temporary alternative measures are acceptable. Any exception records its scope, approver, measures, and review date. It remains visible as a deviation from the intended state.<\/p>
After the access path is corrected, the team tests authorized access through the intended workflow and verifies that access outside it is blocked. It retains the account scope, test time, and results before closing the finding. The next assessment includes the new account, preventing the same population gap from recurring.<\/p>![\"\"](\"https:\/\/spog.ai\/blog\/wp-content\/uploads\/2026\/10\/iso-27001_03.png\")
<\/figure>5. Give management review decisions, not just percentages<\/strong><\/h2>A dashboard showing “controls implemented” is an incomplete basis for leadership oversight.<\/p>
For critical services, management needs to understand:<\/p>
\n- Which material control gaps remain.<\/li>\n\n\n\n
- Which results are unknown because evidence is incomplete.<\/li>\n\n\n\n
- Which exceptions are approaching or exceeding their review dates.<\/li>\n\n\n\n
- Which remediation efforts require resources or escalation.<\/li>\n\n\n\n
- Whether repeated failures indicate a weakness in the process itself.<\/li>\n<\/ul>
A coverage percentage should identify its population and measurement time. Trends should use consistent definitions or explain changes in scope. If a service expands, coverage can fall even when every previously protected asset remains protected. That is valuable information: the organization has grown faster than the control’s reach.<\/p>
For example, if the same onboarding gap affects several critical services, management may need to fund an automated enrollment check, assign responsibility for reconciling inventories, or escalate overdue remediation.<\/p>
What do the 11 new controls mean for ongoing operations?<\/strong><\/h2>The controls introduced in the 2022 revision remain relevant, but “new” describes their relationship to the earlier reference set. It does not mean the practices were invented in 2022.<\/p>
They cover:<\/p>Area<\/strong><\/th>Controls introduced in the 2022 revision<\/strong><\/th><\/tr><\/thead>Intelligence, cloud, and continuity<\/td> Threat intelligence; information security for use of cloud services; ICT readiness for business continuity<\/td><\/tr> Physical protection<\/td> Physical security monitoring<\/td><\/tr> Configuration and data protection<\/td> Configuration management; information deletion; data masking; data leakage prevention<\/td><\/tr> Monitoring and engineering<\/td> Monitoring activities; web filtering; secure coding<\/td><\/tr><\/tbody><\/table><\/figure>For applicable areas, examine the implementation rather than just the mapping. For cloud services, consider how security responsibilities and controls operate through acquisition, use, change, and exit. For configuration management, compare actual states with approved baselines. For monitoring, examine critical-system coverage, feed health, and whether alerts reach an accountable response process.<\/p>
A mapped control is a reference. Evidence and review establish whether its implementation remains appropriate.<\/p>
Where continuous control monitoring helps<\/strong><\/h2>Continuous control monitoring can help teams assess selected controls as operational evidence changes. It is particularly useful where assets, identities, configurations, and technical states change between scheduled reviews. It still depends on:<\/p>
\n- Defined objectives and acceptable states.<\/li>\n\n\n\n
- Accurate scope and asset relationships.<\/li>\n\n\n\n
- Reliable evidence sources.<\/li>\n\n\n\n
- Appropriate assessment frequency.<\/li>\n\n\n\n
- Owners who act on findings.<\/li>\n<\/ul>
ISO 27001 does not require a particular continuous monitoring platform or real-time testing of every control. Select a monitoring and testing approach proportionate to the risk and the nature of the control.<\/p>
SPOG.AI connects operational evidence with controls, affected assets, risk context, ownership, exceptions and remediation. This helps security and GRC teams maintain visibility into control coverage, evidence freshness, unresolved gaps and accountable actions as the environment changes. Available coverage depends on connected systems, evidence sources and configured assessments. <\/p>
What to review next<\/h2>
Start with one critical service. Confirm which assets, identities and activities each priority control should cover, whether its evidence is sufficiently current and who owns any gaps or unknown results. Revisit the Statement of Applicability when changes affect control applicability, implementation status or the rationale recorded there.<\/p>
SPOG.AI’s GRC solution<\/a> connects requirements, controls, ownership and exceptions to support this oversight. Its Continuous Control Monitoring solution<\/a> helps teams assess selected controls against operational evidence as the environment changes. Available coverage depends on connected systems, evidence sources and configured assessments; the organization remains responsible for evaluating and improving its ISMS.<\/p>Bring material gaps, unsupported conclusions and overdue exceptions into management review, with clear decisions and follow-up dates. Expand this approach when owners can explain what each result establishes, what remains uncertain and whether corrective action restored the intended control outcome.<\/p>
Frequently asked questions<\/strong><\/h6>\n\n \n \n \n\n
The transition deadline for accredited ISO\/IEC 27001:2013 certifications was 31 October 2025<\/strong>. Organizations maintaining certification should confirm their certificate’s current edition, validity, and scope with the issuing certification body. The 2022 revision aligned Annex A with ISO\/IEC 27002:2022 and introduced clause 6.3 on planning changes to the ISMS. Its reference set contains 93 controls across four groups<\/strong>:<\/p> The reduction from 114 controls does not represent 21 security practices that organizations can discard. Controls were reorganized, merged, and updated. The 2024 amendment adds a requirement to determine whether climate change is relevant to organizational context and a note about related interested-party requirements. It does not add Annex A controls. These facts establish the baseline. The more consequential question is whether your implementation remains accurate as the business changes.<\/p> A control can continue working on its original population while new assets remain outside it. Control scope means the assets, accounts, services or activities that a particular control should cover within the ISMS. Review this population as the environment changes. <\/p> Endpoint protection may be healthy on enrolled devices, but recently acquired devices may never have enrolled. A privileged access workflow may operate correctly for known administrators while new cloud roles bypass it. Backup jobs may succeed for configured systems while a new critical service remains unprotected.<\/p> This is why coverage needs a reliable denominator: which assets, accounts, services, or activities should the control cover?<\/strong> For each priority control, establish:<\/p> Then define events that trigger review. Examples include a new cloud account, SaaS service, supplier, acquisition, privileged role, or material system change. This does not mean rewriting the SoA whenever an account is created. Keep detailed operational inventories linked to the control implementation. Review the SoA when the change affects applicability, implementation status, or the rationale recorded there.<\/p> The Statement of Applicability (SoA) records necessary controls, their inclusion rationale, implementation status and justified Annex A exclusions. Review these entries when business or technical changes affect the decisions they describe.<\/p> Keep detailed asset and account inventories linked to the relevant implementation records. A new account may require an inventory update without changing the SoA. A change in control applicability, implementation status or rationale may also require a SoA update.<\/p> For each applicable control, maintain a clear connection between the SoA entry, its owner, implementation and supporting evidence. This helps keep the documented decisions aligned with how controls operate today.<\/p> Coverage, health, and effectiveness are practical assessment dimensions, not three formal categories prescribed by ISO 27001. They reveal different weaknesses:<\/p> A deployed tool does not answer all three. For example, a PAM inventory can show which accounts are onboarded. Job records can show whether rotation is succeeding. Testing access outside the approved route can reveal whether the intended restriction actually holds.<\/p> The test should match the objective. A successful backup job establishes something different from a successful restore. Enabled logging establishes something different from a tested detection and response path. Also distinguish failed<\/strong> from unknown<\/strong>. If an evidence feed is stale or a critical population cannot be reconciled, the result lacks sufficient support. It should not silently remain green.<\/p> An exception is an ongoing risk decision with defined boundaries. Record its scope, rationale, accountable risk owner, approver, alternative measures where relevant, and review or expiry date. Keep approved deviations distinguishable from unexplained gaps.<\/p> Review which exceptions remain valid, which have expired and which depend on assumptions that have changed. Where protection depends on an alternative measure, retain evidence that it operates as intended.<\/p> Repeated exceptions affecting the same control should inform risk assessment and management review. Leadership may need to address a recurring dependency, ownership gap or resource constraint.<\/p> Consider a new production cloud account supporting a customer-facing application. This is an illustrative scenario, not a reported customer result.<\/p> The account appears in the cloud inventory but is missing from the population used to assess privileged access. The team confirms that it falls within the existing ISMS scope and that the selected access controls apply. It updates the operational inventory and checks whether the SoA still accurately describes the implementation.<\/p> Validation finds a direct administrator access path outside the approved privileged access workflow. The security team records the finding, links it to the application and affected identities, and assesses the consequence of unauthorized access. The application owner and risk owner agree on remediation, ownership, and a due date under the organization’s procedure.<\/p> Where immediate correction could disrupt the service, the authorized risk owner decides whether temporary alternative measures are acceptable. Any exception records its scope, approver, measures, and review date. It remains visible as a deviation from the intended state.<\/p> After the access path is corrected, the team tests authorized access through the intended workflow and verifies that access outside it is blocked. It retains the account scope, test time, and results before closing the finding. The next assessment includes the new account, preventing the same population gap from recurring.<\/p> A dashboard showing “controls implemented” is an incomplete basis for leadership oversight.<\/p> For critical services, management needs to understand:<\/p> A coverage percentage should identify its population and measurement time. Trends should use consistent definitions or explain changes in scope. If a service expands, coverage can fall even when every previously protected asset remains protected. That is valuable information: the organization has grown faster than the control’s reach.<\/p> For example, if the same onboarding gap affects several critical services, management may need to fund an automated enrollment check, assign responsibility for reconciling inventories, or escalate overdue remediation.<\/p> The controls introduced in the 2022 revision remain relevant, but “new” describes their relationship to the earlier reference set. It does not mean the practices were invented in 2022.<\/p> They cover:<\/p> For applicable areas, examine the implementation rather than just the mapping. For cloud services, consider how security responsibilities and controls operate through acquisition, use, change, and exit. For configuration management, compare actual states with approved baselines. For monitoring, examine critical-system coverage, feed health, and whether alerts reach an accountable response process.<\/p> A mapped control is a reference. Evidence and review establish whether its implementation remains appropriate.<\/p> Continuous control monitoring can help teams assess selected controls as operational evidence changes. It is particularly useful where assets, identities, configurations, and technical states change between scheduled reviews. It still depends on:<\/p> ISO 27001 does not require a particular continuous monitoring platform or real-time testing of every control. Select a monitoring and testing approach proportionate to the risk and the nature of the control.<\/p> SPOG.AI connects operational evidence with controls, affected assets, risk context, ownership, exceptions and remediation. This helps security and GRC teams maintain visibility into control coverage, evidence freshness, unresolved gaps and accountable actions as the environment changes. Available coverage depends on connected systems, evidence sources and configured assessments. <\/p> Start with one critical service. Confirm which assets, identities and activities each priority control should cover, whether its evidence is sufficiently current and who owns any gaps or unknown results. Revisit the Statement of Applicability when changes affect control applicability, implementation status or the rationale recorded there.<\/p> SPOG.AI’s GRC solution<\/a> connects requirements, controls, ownership and exceptions to support this oversight. Its Continuous Control Monitoring solution<\/a> helps teams assess selected controls against operational evidence as the environment changes. Available coverage depends on connected systems, evidence sources and configured assessments; the organization remains responsible for evaluating and improving its ISMS.<\/p> Bring material gaps, unsupported conclusions and overdue exceptions into management review, with clear decisions and follow-up dates. Expand this approach when owners can explain what each result establishes, what remains uncertain and whether corrective action restored the intended control outcome.<\/p>Annex A group<\/strong><\/th> Controls<\/strong><\/th> Examples of areas covered<\/strong><\/th><\/tr><\/thead> Organizational<\/td> 37<\/td> Governance, suppliers, incident management, and continuity<\/td><\/tr> People<\/td> 8<\/td> Employment responsibilities, awareness, and reporting<\/td><\/tr> Physical<\/td> 14<\/td> Facilities, physical access, and equipment<\/td><\/tr> Technological<\/td> 34<\/td> Access, configuration, monitoring, development, and data protection<\/td><\/tr><\/tbody><\/table><\/figure> 1. Keep control scope current<\/strong><\/h2>
\n
2. Keep the SoA aligned with current control implementation <\/strong><\/h2>
<\/figure>3. Distinguish coverage, health, and effectiveness<\/strong><\/h2>
Question<\/strong><\/th> What it establishes<\/strong><\/th> Example<\/strong><\/th><\/tr><\/thead> Coverage<\/td> Does the control reach the intended population?<\/td> Are all in-scope privileged accounts included?<\/td><\/tr> Health<\/td> Are the mechanisms supporting the control operating?<\/td> Are required password rotation jobs completing?<\/td><\/tr> Effectiveness<\/td> Does the control achieve its defined objective under the conditions tested?<\/td> Can unauthorized privileged access still occur?<\/td><\/tr><\/tbody><\/table><\/figure> 4. Treat exceptions as governed decisions<\/strong><\/h2>
Example following a new cloud account through to closure<\/strong><\/h3>
<\/figure>5. Give management review decisions, not just percentages<\/strong><\/h2>
\n
What do the 11 new controls mean for ongoing operations?<\/strong><\/h2>
Area<\/strong><\/th> Controls introduced in the 2022 revision<\/strong><\/th><\/tr><\/thead> Intelligence, cloud, and continuity<\/td> Threat intelligence; information security for use of cloud services; ICT readiness for business continuity<\/td><\/tr> Physical protection<\/td> Physical security monitoring<\/td><\/tr> Configuration and data protection<\/td> Configuration management; information deletion; data masking; data leakage prevention<\/td><\/tr> Monitoring and engineering<\/td> Monitoring activities; web filtering; secure coding<\/td><\/tr><\/tbody><\/table><\/figure> Where continuous control monitoring helps<\/strong><\/h2>
\n
What to review next<\/h2>
Frequently asked questions<\/strong><\/h6>