ISO/IEC 42001 Statement of Applicability Template (AIMS Annex A)

AIMS SoA: scope, risk treatment link, all 38 Annex A controls with basis, justification, status, owner, evidence, Annex B ref, extra controls, traceability

ISO & KonformitätVollständigISO/IEC 42001:2023 clause 6.1.3, Annex Aiso 42001 statement applicabilityAktualisiert 21.10.2026

Im Editor öffnen.md herunterladen

Anleitung: Use it after the AI risk assessment and impact assessment to record which ISO/IEC 42001 Annex A controls are needed and why. Fill the scope, the risk treatment inputs and the basis codes first, then one row per control. The main pitfall is marking controls Implemented when no dated evidence shows them operating. Honest current-state scores matter more than target ambitions.

Vorschau

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

Purpose and scope
Link to risk assessment and treatment
How to read the applicability tables
Annex A control applicability
Excluded controls
Additional controls from other sources
Implementation summary
Traceability matrix
Maintenance and review
Audit readiness
Glossary and references

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 scale:

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	Implemented or Effective	In progress	Planned
A.2 Policies related to AI	3	Example: 3	2	1	0
A.3 Internal organization	2	2	1	1	0
A.4 Resources for AI systems	5	5	3	2	0
A.5 Assessing impacts of AI systems	4	4	3	1	0
A.6 AI system life cycle	9	9	5	3	1
A.7 Data for AI systems	5	5	3	2	0
A.8 Information for interested parties	4	4	2	1	1
A.9 Use of AI systems	3	3	2	1	0
A.10 Third-party and customer relationships	3	3	2	1	0
Additional controls (section 6)	7	7	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

References:

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.