3.8 Statement of Applicability (SoA) Development & Justification

3.8 Statement of Applicability (SoA) Development & Justification

The Statement of Applicability (SoA) is arguably the single most important document produced during an ISO/IEC 42001 implementation. Required under Clause 6.1.3 (d), the SoA serves as the primary bridge between the organization's risk assessment results and the normative control framework of Annex A. Certification auditors utilize the SoA as their primary roadmap to evaluate which controls apply, how they are implemented, and whether any excluded controls are legitimately justified.

---

Mandatory Elements of the Statement of Applicability

Under Clause 6.1.3 (d), the SoA must cover all 38 controls defined across Annex A.2 through A.10. For every single control, the document must explicitly state:

1. Control Reference & Title: The precise Annex A control reference number and name (e.g., A.6.2 Data Quality for AI Systems).
2. Applicability Designation: Clear designation of whether the control is Applicable or Excluded.
3. Justification for Inclusion: Summary of the risk assessment findings, impact assessments, legal mandates, or business requirements that necessitate the control.
4. Justification for Exclusion: Detailed technical, legal, operational, or role-based rationale explaining why a control is not applicable (required for every excluded control).
5. Implementation Status: Current operational state (e.g., Implemented, In Progress, or Planned).
6. Supporting Document References: Direct cross-references to supporting policies, SOPs, architectural diagrams, or audit logs.

---

Sample Auditable Statement of Applicability Structure

The following table illustrates the required format for an auditable ISO/IEC 42001 SoA:

---

Rules & Principles for Control Exclusions

Excluding an Annex A control is permissible, but subject to strict audit scrutiny:

• Role-Based Exclusion Rules: An organization operating strictly as an AI Deployer (using external LLM APIs) may legitimately exclude custom pre-training controls under Annex A.5, provided it justifies how third-party risks are managed under Annex A.9.
• No Arbitrary Exclusions: Stating "not required" or "not feasible" is an automatic audit non-conformity. Exclusions must reference specific operational boundaries or technical facts.
• Interdependency Rules: An organization cannot exclude data quality controls (Annex A.6) while claiming to train custom machine learning models in-house.

---

Common SoA Audit Non-Conformities & How to Avoid Them

During Stage 1 and Stage 2 certification audits, external auditors subject the SoA to intense scrutiny. Implementers must avoid these common failure modes:

• Unjustified Exclusions: Marking controls as "Excluded" without documenting a valid, technical, or risk-backed rationale.
• Role Misalignment: An organization declaring itself an AI Producer while attempting to exclude Annex A.5 development controls, or an AI Deployer excluding Annex A.9 third-party controls.
• Disconnect from Risk Register: Selecting controls in the SoA that do not correspond to any identified risks in the Clause 6.1.2 Risk Register, or leaving high-severity risks unmitigated by selected controls.
• Static Document Management: Treating the SoA as a one-time project artifact rather than maintaining it as a living document.

---

SoA Maintenance & Lifecycle Change Management

The Statement of Applicability must be reviewed and updated continuously throughout the AIMS lifecycle. Mandatory update triggers include:

• New AI System Deployment: Onboarding a new generative AI tool or custom ML algorithm into the enterprise inventory.
• Risk Profile Shift: Re-evaluating risks following an AI security incident, model drift event, or bias discovery.
• Regulatory Changes: Enactment of new statutory mandates or binding industry standards.
• Management Reviews: Annual Clause 9.3 performance evaluations and internal audit findings.

---

Worked Implementation Scenario: Enterprise SaaS Provider SoA Development

Context: A SaaS company providing AI-driven HR analytics prepares its SoA for an ISO/IEC 42001 certification audit.

Execution Steps:

1. Control Mapping: The Lead Implementer reviews all 38 Annex A controls against the Clause 6.1.2 Risk Register and Clause 6.1.4 AISIA.
2. Documenting Inclusions: 35 controls are designated as Applicable, including A.6.3 (Data Quality) and A.8.2 (Human Oversight).
3. Justifying Exclusions: 3 controls related to hardware data center thermal management are designated as Excluded, with documented justification stating that all infrastructure is hosted in ISO 27001-certified AWS cloud data centers.
4. Audit Verification: The Stage 1 auditor verifies that all exclusions are supported by cloud SLA artifacts, issuing zero non-conformities.

---

Lead Implementer Exam Tips

• Clause 6.1.3 (d) Requirement: Memorize that the SoA is explicitly mandated under Clause 6.1.3 (d).
• All 38 Controls: Remember that the SoA must cover all 38 Annex A controls—omitting a control from the document is an automatic non-conformity.
• Justification Requirement: Every single control entry in the SoA requires a documented justification, regardless of whether it is designated as Included or Excluded.