The common failure is a mismatch between the risk register and the control set. If a risk is identified but no corresponding Annex A control is selected, or if the exclusion has no documented reason, auditors can treat that as a finding. The SoA must connect the risk, the control decision, and the justification.
How ISO 42001 Exclusions Fail When They Are Treated as Free Passes
An exclusion is only defensible when it is part of a risk-based decision, not a shortcut around the standard. If a control is excluded without being tied to the underlying risk and impact assessment, the management system loses traceability: reviewers cannot tell whether the omission was deliberate, justified, and bounded, or simply undocumented.
That matters because ISO 42001 expects exclusions to sit inside the same governance logic as the rest of the AI management system. The exclusion should answer why the control is unnecessary, what residual risk remains, and what compensating measures, if any, preserve acceptable treatment of that risk.
When exclusions are detached from assessment, the common breakdown is that the statement of applicability becomes a list of selections rather than a decision record. At that point, the document may still look complete, but it no longer shows how the organisation moved from identified risk to control choice.
Why the SoA Stops Being Defensible
The statement of applicability is meant to connect identified risks to the controls selected, omitted, or replaced. If an exclusion is not linked to impact and risk reasoning, the SoA can no longer explain why the control set is the right one for the actual AI environment.
In practice, that creates a gap between governance intent and evidence. Auditors and assessors are not only checking whether a control appears in the catalog, they are checking whether the organisation can justify the control decision with a documented rationale that matches the risk profile.
That is especially important where the exclusion affects a material control area such as accountability, monitoring, data handling, or change oversight. A weak exclusion can make the whole control set look uncalibrated, because the absence of one control may imply that nearby controls were also chosen without sufficient analysis.
What Auditors and Practitioners Usually Find Missing
When exclusions are not tied to assessments, the missing pieces are usually predictable: no documented rationale, no reference to the risk owner’s decision, no evidence that impact was considered, or no sign that residual risk was accepted by the right authority. Those omissions are what turn a reasonable exclusion into a finding.
Another common failure is inconsistency. A team may identify a real risk in the register, but the SoA does not show any corresponding control decision, or it marks the control as excluded without explaining why the risk can still be managed. That mismatch is easy for reviewers to spot and hard to defend later.
Where exclusions are repeated across multiple controls, the problem becomes structural. The organisation may appear to have an AI management system, but the system is not actually driving control selection. In that case, the SoA becomes a compliance artifact instead of an operational governance tool.
Risk and Threat Considerations
Detached exclusions create governance exposure because they weaken the chain from risk identification to control treatment. In an AI management system, that means latent risks can remain unmanaged even though the document set suggests they were reviewed.
Failure mechanism: A risk is identified, but the exclusion is written as a convenience statement rather than as a risk treatment decision, so the control set no longer reflects the assessed impact or the accepted residual exposure.
Impact: The organisation can lose audit defensibility, miss compensating controls, and leave material AI-related risks without a clearly owned treatment decision.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
ISO/IEC 27001:2022 and SOC 2 (AICPA) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.1 — Policies for information security | ISO 42001 exclusions need policy-backed governance and documented control decisions. |
| A.5.36 — Compliance with policies, rules and standards for information security | Exclusions must remain consistent with the organisation's stated governance rules and review evidence. | |
| Recommendation — Require documented control decisions and rationale for any exclusion. Check exclusions against the approved governance and review process. | ||
| SOC 2 (AICPA) | CC4.1 — Monitor and Evaluate | Control exclusions should be observable, reviewed, and supported by evidence over time. |
| Recommendation — Monitor excluded controls for evidence that the risk decision remains valid. | ||
Practitioner Guidance
What to verify: For every excluded control, verify that the SoA points back to a specific risk assessment entry, an impact rationale, and a named decision owner. If those three elements are not aligned, treat the exclusion as incomplete rather than merely undocumented.
Decision rule: If the risk exists but the control is excluded, require a clear explanation of why the residual risk is still acceptable and what alternative control or monitoring arrangement covers the gap. If no such explanation exists, the exclusion should not be accepted as final.
Practitioner takeaway: The real test is not whether a control can be excluded, but whether the exclusion still leaves a visible, reviewable path from risk, to impact, to control decision, to residual risk acceptance.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
