Statement of Applicability: [Organisation name] AI management system
Statement of Applicability (SoA) for an AI management system (AIMS),
structured on clause 6.1.3 of ISO/IEC 42001:2023 (Information
technology, Artificial intelligence, Management system). It records
every Annex A control (A.2 to A.10), whether it is included or
excluded, why, how far it is implemented, who owns it and what evidence
shows it works, together with additional controls taken from other
sources such as the NIST AI RMF and ISO/IEC 27001. Replace every
[bracketed] value and every row or cell marked Example. Control
numbers are cited for reference; the short descriptions are original
paraphrases, so read the standard for the normative control text.
Document control
| Field | Value |
|---|
| Document ID | [SOA-AIMS-001] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@aims-manager] |
| Approvers / reviewers | [@ai-governance-board], [@ciso], [@dpo], [@legal] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |
| AIMS scope statement | [SCOPE-AIMS-001, version] |
| AI risk assessment | [AIRA-REG-001, version, date] |
| AI risk treatment plan | [AIRTP-001, version, date] |
| Standard edition | ISO/IEC 42001:2023 [plus amendments, if any] |
| Certification body (if any) | [Name, accreditation] |
| Next scheduled review | YYYY-MM-DD |
Approvals
| Role | Name | Decision | Date |
|---|
| AIMS manager | [@name] | [Prepared] | YYYY-MM-DD |
| AI governance board chair | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Top management representative | [@name] | [Approve residual risk and treatment plan] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft from the initial risk treatment plan |
| 1.0 | YYYY-MM-DD | [@name] | Example: Approved for stage 1 certification audit |
| 1.1 | YYYY-MM-DD | [@name] | Example: A.7.5 status changed to Implemented after data lineage tool rollout; added AC-004 |
Contents
1. Purpose and scope
This Statement of Applicability records the controls [Organisation name]
has determined to be necessary to treat its AI risks within the AIMS
scope defined in [SCOPE-AIMS-001]. It is the reference that internal
auditors, the certification body and the AI governance board use to
check that each Annex A control was considered, that inclusions and
exclusions are justified, and that implementation is evidenced.
1.1 AIMS scope summary
| Item | Value |
|---|
| Organisational units | [Example: Product engineering, data science, customer operations] |
| Locations | [Example: Berlin (HQ), remote staff in the EU] |
| AI roles of the organisation | [AI provider / AI producer / AI customer / AI partner / AI subject] (role terms as described in ISO/IEC 22989) |
| Out of scope | [Example: HR recruitment tools bought as SaaS and covered by the procurement process only] |
1.2 AI systems in scope
| System ID | AI system | Role of the organisation | Life cycle stage | Impact assessment |
|---|
| AIS-001 (Example) | Customer support assistant (LLM with retrieval) | Provider and deployer | Operation | AIIA-001 |
| AIS-002 (Example) | Invoice anomaly detection model | Developer and deployer | Verification and validation | AIIA-002 |
| AIS-003 (Example) | Third-party code assistant used by engineers | Customer (user) | Operation | Not required (internal, low impact) |
2. Link to risk assessment and treatment
The SoA was produced from the AI risk treatment process in the following
sequence. Controls may come from Annex A or from any other source; Annex
A is used as a completeness check rather than as the only menu.
| Input | Reference | Date | How it was used |
|---|
| AI risk register | [AIRA-REG-001] | YYYY-MM-DD | Example: 27 risks rated, 9 above tolerance; each above-tolerance risk maps to at least one control in sections 4 and 6 |
| AI system impact assessments | [AIIA-001], [AIIA-002] | YYYY-MM-DD | Example: Impacts on applicants and customers drove inclusion of A.5.4, A.8.2 and A.8.3 |
| Legal and regulatory register | [AI regulatory applicability register] | YYYY-MM-DD | Example: EU AI Act provider and deployer duties drove A.6.2.8 and A.8.5 |
| Contractual requirements | [Customer contracts register] | YYYY-MM-DD | Example: Two enterprise contracts require incident notice within 72 hours |
| Risk criteria | [Risk methodology, section x] | YYYY-MM-DD | Likelihood and impact scales and tolerance |
3. How to read the applicability tables
Included is Yes when the control is necessary to treat at least one
risk or to meet a requirement, and No when it is excluded (see section 5).
Basis codes explain why a control is included:
| Code | Meaning |
|---|
| RA | Needed to treat a risk in the AI risk register |
| IA | Needed because of a finding in an AI system impact assessment |
| LR | Needed to meet a legal or regulatory requirement |
| CO | Needed to meet a contractual or customer requirement |
| BP | Adopted as good practice or an internal objective without a specific risk |
| Status | Meaning |
|---|
| Planned | Approved in the treatment plan; work not started |
| In progress | Partly in place; gaps tracked in the treatment plan |
| Implemented | In place and operating; evidence available |
| Effective | Implemented and verified by internal audit or monitoring results |
| Not applicable | Excluded; justification in section 5 |
Guidance gives the matching Annex B clause, which carries the
standard's implementation guidance for each Annex A control (for example
B.2.2 for A.2.2). Annex C (potential AI-related objectives and risk
sources) and Annex D (use across domains and sectors) are informative and
can support justifications.
4. Annex A control applicability
Annex A of ISO/IEC 42001:2023 groups its controls into nine control
areas, A.2 to A.10 (A.6 has two objectives, A.6.1 and A.6.2). Public summaries consistently count 38 controls;
confirm the count against the edition you hold. The descriptions below
are short original paraphrases of each control's subject.
4.1 A.2 Policies related to AI
| Control | Subject (paraphrase) | Included | Basis | Justification | Status | Owner | Evidence | Guidance |
|---|
| A.2.2 | Documented policy for developing or using AI systems | Yes | LR, BP | Example: Required to set direction for all AIS in scope and to anchor AI objectives | Implemented | [@ciso] | POL-AI-001 v1.0 | B.2.2 |
| A.2.3 | Alignment of other organisational policies with AI objectives | Yes | RA | Example: Security, privacy and procurement policies affect AI risk R-07 | In progress | [@aims-manager] | Policy alignment log | B.2.3 |
| A.2.4 | Planned and event-driven review of the AI policy | Yes | BP | Example: AI law and technology change faster than the annual policy cycle | Implemented | [@aims-manager] | Board minutes YYYY-MM-DD | B.2.4 |
4.2 A.3 Internal organization
| Control | Subject (paraphrase) | Included | Basis | Justification | Status | Owner | Evidence | Guidance |
|---|
| A.3.2 | Defined and assigned AI roles and responsibilities | Yes | RA, LR | Example: Unclear ownership was the root cause of risk R-02 | Implemented | [@coo] | AI RACI v2 | B.3.2 |
| A.3.3 | Process for raising concerns about AI systems | Yes | IA, LR | Example: Impact assessment AIIA-001 found no channel for staff concerns | In progress | [@ethics-officer] | Speak-up procedure update | B.3.3 |
4.3 A.4 Resources for AI systems
| Control | Subject (paraphrase) | Included | Basis | Justification | Status | Owner | Evidence | Guidance |
|---|
| A.4.2 | Identification and documentation of resources per life cycle stage | Yes | RA | Example: Needed to plan capacity and dependencies for AIS-001 | Implemented | [@ml-platform-lead] | AI system inventory | B.4.2 |
| A.4.3 | Documentation of data resources used | Yes | RA, LR | Example: Data origin gaps rated high in R-05 | In progress | [@data-governance-lead] | Dataset register | B.4.3 |
| A.4.4 | Documentation of tooling resources | Yes | RA | Example: Unreviewed training and evaluation libraries (R-11) | Implemented | [@ml-platform-lead] | Tooling register, AI-BOM | B.4.4 |
| A.4.5 | Documentation of system and computing resources | Yes | BP | Example: Needed for cost, resilience and environmental reporting | Implemented | [@infra-lead] | Capacity plan | B.4.5 |
| A.4.6 | Documentation of human resources and competences | Yes | RA, LR | Example: Skills gaps in model validation (R-08); AI literacy measures | In progress | [@hr-lead] | Competence matrix, AI literacy plan | B.4.6 |
4.4 A.5 Assessing impacts of AI systems
| Control | Subject (paraphrase) | Included | Basis | Justification | Status | Owner | Evidence | Guidance |
|---|
| A.5.2 | Process for assessing potential consequences of AI systems | Yes | LR, RA | Example: Clause 6.1.4 requirement; AI Act fundamental rights duties for some deployments | Implemented | [@ai-governance-lead] | Impact assessment procedure | B.5.2 |
| A.5.3 | Documentation and retention of impact assessment results | Yes | LR | Example: Results must be available to auditors and regulators | Implemented | [@ai-governance-lead] | AIIA records | B.5.3 |
| A.5.4 | Assessment of impacts on individuals or groups | Yes | IA | Example: AIS-001 interacts with consumers, including vulnerable users | Implemented | [@product-owner] | AIIA-001 section 5 | B.5.4 |
| A.5.5 | Assessment of societal impacts | Yes | IA | Example: Scale of AIS-001 and environmental footprint of hosting | In progress | [@sustainability-lead] | AIIA-001 section 5.3 | B.5.5 |
4.5 A.6 AI system life cycle
| Control | Subject (paraphrase) | Included | Basis | Justification | Status | Owner | Evidence | Guidance |
|---|
| A.6.1.2 | Objectives that guide responsible development | Yes | BP | Example: Translates AI policy principles into engineering targets | Implemented | [@head-of-ml] | Responsible development objectives | B.6.1.2 |
| A.6.1.3 | Defined processes for responsible design and development | Yes | RA | Example: Ad hoc development caused R-03 (untested prompts in production) | In progress | [@head-of-ml] | ML development standard | B.6.1.3 |
| A.6.2.2 | Requirements and specification for new or enhanced AI systems | Yes | RA | Example: Missing acceptance criteria in R-03 | Implemented | [@product-owner] | Requirement specs, prompt specifications | B.6.2.2 |
| A.6.2.3 | Documentation of design and development | Yes | LR | Example: Technical documentation duties for provider role | In progress | [@tech-lead] | Design records | B.6.2.3 |
| A.6.2.4 | Verification and validation measures and criteria | Yes | RA, CO | Example: Hallucination and safety risks R-04, R-09; customer acceptance tests | Implemented | [@qa-lead] | Evaluation plans and reports | B.6.2.4 |
| A.6.2.5 | Deployment planning and release criteria | Yes | RA | Example: Releases without gates caused incident INC-14 | Implemented | [@release-manager] | Launch review records | B.6.2.5 |
| A.6.2.6 | Running and watching the system in production, with upkeep | Yes | RA | Example: Drift and degradation risk R-10 | In progress | [@sre-lead] | Monitoring plan, dashboards | B.6.2.6 |
| A.6.2.7 | Technical documentation for each relevant interested party | Yes | LR, CO | Example: Deployer customers need instructions for use | Planned | [@tech-writer] | Documentation set | B.6.2.7 |
| A.6.2.8 | Deciding when event logs are kept, always including live use | Yes | LR, RA | Example: Traceability and incident investigation needs; AI Act logging duties for high-risk systems | Implemented | [@sre-lead] | Logging standard, log retention settings | B.6.2.8 |
4.6 A.7 Data for AI systems
| Control | Subject (paraphrase) | Included | Basis | Justification | Status | Owner | Evidence | Guidance |
|---|
| A.7.2 | Data management processes for development and enhancement | Yes | RA | Example: Uncontrolled reuse of support tickets for fine-tuning (R-05) | In progress | [@data-governance-lead] | Data management procedure | B.7.2 |
| A.7.3 | Acquisition and selection of data | Yes | RA, LR | Example: Licensing and lawful basis of acquired datasets (R-06) | Implemented | [@legal] | Data acquisition records | B.7.3 |
| A.7.4 | Data quality requirements and checks | Yes | RA | Example: Label noise affecting AIS-002 recall (R-12) | Implemented | [@data-science-lead] | Data quality rules, validation reports | B.7.4 |
| A.7.5 | Recording of data provenance | Yes | LR, RA | Example: Needed to answer data subject and copyright queries | In progress | [@data-governance-lead] | Lineage tool, datasheets | B.7.5 |
| A.7.6 | Criteria and methods for data preparation | Yes | RA | Example: Inconsistent PII redaction before training (R-05) | Implemented | [@data-engineering-lead] | Pipeline specification | B.7.6 |
4.7 A.8 Information for interested parties of AI systems
| Control | Subject (paraphrase) | Included | Basis | Justification | Status | Owner | Evidence | Guidance |
|---|
| A.8.2 | System documentation and information for users | Yes | LR, IA | Example: Users must know they interact with AI and understand limits | Implemented | [@product-owner] | In-product notices, help centre article | B.8.2 |
| A.8.3 | Means for interested parties to report adverse impacts | Yes | IA | Example: AIIA-001 required an external reporting route | In progress | [@support-lead] | Feedback form, triage procedure | B.8.3 |
| A.8.4 | Plan for communicating incidents to users | Yes | LR, CO | Example: Contractual 72-hour notice; serious incident reporting duties | Implemented | [@incident-manager] | AI incident response plan | B.8.4 |
| A.8.5 | Determination of information to report to interested parties | Yes | LR | Example: Regulator and customer reporting obligations identified in the legal register | Planned | [@legal] | Reporting obligations register | B.8.5 |
4.8 A.9 Use of AI systems
| Control | Subject (paraphrase) | Included | Basis | Justification | Status | Owner | Evidence | Guidance |
|---|
| A.9.2 | Processes for responsible use of AI systems | Yes | RA | Example: Staff use of third-party assistants (AIS-003, R-13) | Implemented | [@ciso] | AI acceptable use policy | B.9.2 |
| A.9.3 | Objectives that guide responsible use | Yes | BP | Example: Sets measurable targets for review of AI-assisted output | In progress | [@ai-governance-lead] | AI objectives register | B.9.3 |
| A.9.4 | Use according to intended use and accompanying documentation | Yes | LR, RA | Example: Deployer duty to follow provider instructions; off-label use risk R-14 | Implemented | [@business-owner] | Use case intake records | B.9.4 |
4.9 A.10 Third-party and customer relationships
| Control | Subject (paraphrase) | Included | Basis | Justification | Status | Owner | Evidence | Guidance |
|---|
| A.10.2 | Splitting life cycle duties across the value chain | Yes | LR, CO | Example: AI Act value chain roles and Article 25 written agreements | In progress | [@legal] | Responsibility matrix in contracts | B.10.2 |
| A.10.3 | Checking that supplied AI inputs fit the organisation's responsible AI approach | Yes | RA | Example: Dependence on an external foundation model provider (R-15) | Implemented | [@procurement-lead] | AI vendor risk questionnaires | B.10.3 |
| A.10.4 | Consideration of customer expectations and needs | Yes | CO | Example: Enterprise customers require transparency reports and opt-outs | Implemented | [@account-director] | Customer requirements log | B.10.4 |
5. Excluded controls
Exclusions are rare in an AIMS because most controls apply to any
organisation that develops or uses AI. Record each one with the
condition that would bring it back into scope.
| Control | Reason for exclusion | Evidence for the reason | Condition to re-include | Approved by | Review date |
|---|
| A.7.3 (Example) | The organisation acts only as an AI customer for AIS-003 and acquires no data for AI development in that scope | Scope statement section 2; AI system inventory | Any plan to fine-tune or train a model on acquired data | [@ai-governance-board] | YYYY-MM-DD |
| A.6.2.7 (Example) | No external interested parties receive the internal-only system, so only internal documentation is required (covered by A.6.2.3) | System inventory shows internal users only | System offered to customers or partners | [@ai-governance-board] | YYYY-MM-DD |
The two rows above illustrate a narrower scope than section 4. If you
keep them, change the matching rows in section 4 to Included: No and
Status: Not applicable so the document stays consistent.
6. Additional controls from other sources
| ID | Control (original wording) | Source | Basis | Treats | Status | Owner | Evidence |
|---|
| AC-001 (Example) | Run adversarial testing against prompt injection, data leakage and excessive agency before each major release of an LLM application | NIST AI 600-1, MEASURE 2.7 suggested actions; OWASP Top 10 for LLM Applications | RA | R-09 | Implemented | [@security-lead] | Red team reports |
| AC-002 (Example) | Keep a generative AI risk profile per system covering the 12 GAI risk categories | NIST AI 600-1 section 2 | RA | R-04, R-09, R-16 | In progress | [@ai-risk-lead] | GenAI risk profiles |
| AC-003 (Example) | Manage access rights to models, prompts, vector stores and evaluation data on least privilege | ISO/IEC 27001:2022 Annex A 5.15 and 8.2 | RA | R-17 | Implemented | [@iam-lead] | Access review records |
| AC-004 (Example) | Record model, dataset and component inventory in a machine-readable AI bill of materials | CycloneDX ML-BOM; NIST AI 600-1 GOVERN 6.1 actions | RA, CO | R-11, R-15 | Planned | [@ml-platform-lead] | AI-BOM files |
| AC-005 (Example) | Process personal data in prompts and training sets under documented privacy controls and DPIA | ISO/IEC 27701:2025; GDPR Article 35 | LR | R-05 | Implemented | [@dpo] | DPIA records |
| AC-006 (Example) | Label or mark AI-generated content where transparency obligations apply | EU AI Act Article 50 | LR | R-18 | In progress | [@product-owner] | Content transparency plan |
| AC-007 (Example) | Map each AI system to NIST AI RMF GOVERN, MAP, MEASURE and MANAGE outcomes for customers who require that framework | NIST AI RMF 1.0 (AI 100-1) | CO | R-19 | Implemented | [@ai-governance-lead] | AI risk assessment |
7. Implementation summary
| Objective | Controls | Included | Excluded | Implemented or Effective | In progress | Planned |
|---|
| A.2 Policies related to AI | 3 | Example: 3 | 0 | 2 | 1 | 0 |
| A.3 Internal organization | 2 | 2 | 0 | 1 | 1 | 0 |
| A.4 Resources for AI systems | 5 | 5 | 0 | 3 | 2 | 0 |
| A.5 Assessing impacts of AI systems | 4 | 4 | 0 | 3 | 1 | 0 |
| A.6 AI system life cycle | 9 | 9 | 0 | 5 | 3 | 1 |
| A.7 Data for AI systems | 5 | 5 | 0 | 3 | 2 | 0 |
| A.8 Information for interested parties | 4 | 4 | 0 | 2 | 1 | 1 |
| A.9 Use of AI systems | 3 | 3 | 0 | 2 | 1 | 0 |
| A.10 Third-party and customer relationships | 3 | 3 | 0 | 2 | 1 | 0 |
| Additional controls (section 6) | 7 | 7 | 0 | 4 | 2 | 1 |
Figures in the Included to Planned columns are Example values that
match the sample rows in sections 4 and 6. The "Controls" column for A.2
to A.10 follows the public count of 38; check it against your copy of
the standard.
Open gaps are tracked in the AI risk treatment plan [AIRTP-001] with a
target date and owner. Management reviews the gap list at each
management review (clause 9.3).
8. Traceability matrix
| Risk or requirement | Description | Controls | Treatment plan item | Evidence | Residual rating |
|---|
| R-03 (Example) | Untested prompt changes reach production | A.6.1.3, A.6.2.2, A.6.2.5 | TP-04 | Change records with evaluation results | Medium |
| R-05 (Example) | Personal data in support tickets used for fine-tuning | A.7.2, A.7.6, AC-005 | TP-02 | Redaction test report, DPIA | Low |
| R-09 (Example) | Prompt injection leads to data exposure | A.6.2.4, AC-001, AC-003 | TP-07 | Red team report RT-2026-03 | Medium |
| R-15 (Example) | Foundation model provider changes behaviour without notice | A.10.2, A.10.3, AC-004 | TP-09 | Vendor questionnaire, contract clause 12 | Medium |
| LR-01 (Example) | EU AI Act transparency for chatbots and generated content | A.8.2, AC-006 | TP-11 | Notice screenshots, marking test | Low |
| CO-02 (Example) | Customer contract requires incident notice within 72 hours | A.8.4, A.10.4 | TP-12 | Incident plan, notification template | Low |
9. Maintenance and review
The SoA is a controlled document under clause 7.5. Update it and record
a new version in the revision history when any of these occur:
| Trigger | Action | Owner |
|---|
| New AI system enters scope or an existing one changes role | Re-run risk and impact assessment; review all rows | [@aims-manager] |
| Risk register changes a rating above or below tolerance | Review controls linked to that risk | [@ai-risk-lead] |
| New or amended law, standard or contract term | Review Basis LR and CO rows | [@legal] |
| Internal audit or certification audit finding | Correct status, justification or evidence | [@aims-manager] |
| Incident or near miss involving an AI system | Review controls that should have prevented or detected it | [@incident-manager] |
| Scheduled review | Full review at least [annually] and before each management review | [@ai-governance-board] |
10. Audit readiness
Before an audit, confirm that:
- Every Annex A control has a row, a decision and a justification, and
the count matches the standard you hold.
- Each Implemented or Effective status has at least one evidence item
that is dated, controlled and retrievable within a working day.
- Exclusions reference scope or role facts that the auditor can verify
in the scope statement or AI system inventory.
- The SoA version matches the risk treatment plan version approved by
management, and the approval record shows acceptance of residual risk.
- Additional controls in section 6 have owners and are covered by the
internal audit programme.
| Check | Result | Checked by | Date |
|---|
| Row count against standard | [Pass / Fail] | [@internal-auditor] | YYYY-MM-DD |
| Evidence sample (10 controls) | [Pass / Fail, findings] | [@internal-auditor] | YYYY-MM-DD |
| Approval and version alignment | [Pass / Fail] | [@aims-manager] | YYYY-MM-DD |
11. Glossary and references
| Term | Meaning |
|---|
| AIMS | AI management system: the policies, objectives, processes and controls an organisation uses to manage AI responsibly |
| Statement of Applicability | Record of the necessary controls, why they are included or excluded and their implementation status |
| Control objective | Grouping heading in Annex A that states what a set of controls is meant to achieve |
| Risk treatment plan | Plan that assigns actions, owners and dates to implement the selected controls |
| AI system impact assessment | Assessment of potential consequences of an AI system for individuals, groups and society |
| Residual risk | Risk remaining after treatment, accepted by management |
- ISO/IEC 42001:2023, clauses 4 to 10, Annex A (controls), Annex B
(implementation guidance), Annex C and Annex D (informative);
catalogue page https://www.iso.org/standard/81230.html
- ISO/IEC 42005:2025 (AI system impact assessment guidance) and
ISO/IEC 42006:2025 (requirements for AIMS audit and certification
bodies)
- ISO/IEC 23894:2023 (AI risk management guidance)
- ISO/IEC 27001:2022 and ISO/IEC 27701:2025 for additional controls
- NIST AI RMF 1.0 (NIST AI 100-1) and NIST AI 600-1, Generative AI
Profile (July 2024), https://www.nist.gov/itl/ai-risk-management-framework
- Regulation (EU) 2024/1689 (AI Act) as amended by Regulation (EU)
2026/1744, consolidated text on EUR-Lex
- Related templates: AI policy (ISO/IEC 42001),
AI management system policy and impact assessment,
ISO/IEC 27001 Statement of Applicability,
AI vendor risk questionnaire,
AI risk assessment (
ai-data/ai-risk-assessment),
AI system impact assessment (ai-data/ai-impact-assessment-42005),
Generative AI risk profile (ai-data/genai-risk-profile),
Risk methodology
Standard and licence note
Structure aligned with ISO/IEC 42001:2023, clause 6.1.3 and Annex A.
ISO/IEC standards are copyrighted: this template cites clause and control
numbers only, and all descriptions, justifications and examples are
original text. No control text, table or definition from the standard is
reproduced. The count of 38 controls in nine control areas follows
reputable public summaries; obtain the standard from ISO or your national
standards body for the normative requirements and check the current
edition and any amendment before use. References to NIST publications
(public domain) and the EU AI Act (EU legislative text, free to reuse)
are summarised in original wording. This is a documentation format, not
legal or certification advice. Template licence: MIT.