AIMS Status
301 Controls across 80 Objectives in 10 Domains. Click any Domain row to drill in.
Healthy (Gap ≤ 0.49)Watch (Gap 0.50–1.25)Attention (Gap > 1.25)
Target
6.34
Current
5.98
Gap
0.36
Total Controls
301
At Target
195
Below Target
106
Per-Domain Detail
Domain
Target
Current
Gap
Controls
At Target
Below Target
Govern Domain
50 Controls across 12 Objectives.
Healthy (Gap ≤ 0.49)Watch (Gap 0.50–1.25)Attention (Gap > 1.25)
Target
6.40
Current
6.30
Gap
0.10
Total Controls
50
At Target
45
Below Target
5
Per-Objective Detail
ID
Objective
Target
Current
Gap
Controls
At Target
Below Target
GOV.PO
AI Policy
6.00
6.00
0.00
4
4
0
GOV.ST
AI Strategy
6.80
6.00
0.80
5
1
4
GOV.LD
AI Leadership and Commitment
6.00
6.00
0.00
4
4
0
GOV.RR
AI Roles, Responsibilities, and Authorities
6.67
6.67
0.00
6
6
0
GOV.GF
AI Governance Forums and Independent Review
6.50
6.50
0.00
4
4
0
GOV.ET
AI Ethics Commitments
6.00
6.00
0.00
4
4
0
GOV.AU
AI Acceptable Use
6.67
6.33
0.33
3
2
1
GOV.RA
AI Risk Appetite and Tolerance
6.25
6.25
0.00
4
4
0
GOV.OB
AI Objectives and Planning
6.33
6.33
0.00
3
3
0
GOV.CO
AI Competence and Literacy
6.25
6.25
0.00
4
4
0
GOV.DI
Documented Information and Communication
6.50
6.50
0.00
2
2
0
GOV.OV
AIMS Performance Evaluation and Improvement
6.57
6.57
0.00
7
7
0
Controls Below Target 5
Every Control in this Domain where Current < Target. Sorted by Gap (largest first).
ID
Control
Target
Current
Gap
Forecast
Growth
F Gap
GOV.ST-01
The AI strategy framework is documented, approved at appropriate authority level, and version-controlled, integrating AI product strategy, AI consumption strategy, and AI internal development strategy
7.00
6.00
1.00
6.00
0.00
1.00
GOV.ST-02
AI product and service strategy — the provider-mode strategy for AI products and services placed on the market — is documented, approved, and aligned with corporate strategy and target customer needs
7.00
6.00
1.00
6.00
0.00
1.00
GOV.ST-03
AI consumption strategy — the deployer-mode strategy for adopting third-party AI products and foundation model APIs — is documented, approved, and aligned with corporate strategy
7.00
6.00
1.00
6.00
0.00
1.00
GOV.ST-04
AI internal development strategy — the internal-developer strategy for AI capabilities built in-house for internal use — is documented, approved, and aligned with corporate strategy
7.00
6.00
1.00
6.00
0.00
1.00
GOV.AU-02
Shadow AI prevention — covering technical controls to block unsanctioned AI service access, data leakage prevention to sanctioned and unsanctioned AI, identity-controlled SaaS access, and provision of sanctioned alternatives — are established and maintained
7.00
6.00
1.00
6.00
0.00
1.00
Context Domain
20 Controls across 5 Objectives.
Healthy (Gap ≤ 0.49)Watch (Gap 0.50–1.25)Attention (Gap > 1.25)
Target
6.60
Current
6.40
Gap
0.20
Total Controls
20
At Target
16
Below Target
4
Per-Objective Detail
ID
Objective
Target
Current
Gap
Controls
At Target
Below Target
CON.OC
Organisational Context
7.00
6.00
1.00
3
0
3
CON.IP
Interested Parties
6.50
6.25
0.25
4
3
1
CON.SC
AIMS Scope
6.67
6.67
0.00
3
3
0
CON.JU
Jurisdictional Applicability
6.33
6.33
0.00
6
6
0
CON.IN
AI Inventory and Portfolio
6.75
6.75
0.00
4
4
0
Controls Below Target 4
Every Control in this Domain where Current < Target. Sorted by Gap (largest first).
ID
Control
Target
Current
Gap
Forecast
Growth
F Gap
CON.OC-01
External AI context — regulatory and policy environment, AI threat and opportunity landscape, AI technology trends, market and competitive landscape, and geopolitical factors — is identified, documented, and reviewed at defined cadence and on material change
7.00
6.00
1.00
6.00
0.00
1.00
CON.OC-02
Internal AI context — organisational structure, culture, AI capabilities and constraints, and AI strategy implementation context — is identified, documented, and reviewed at defined cadence and on material change
7.00
6.00
1.00
6.00
0.00
1.00
CON.OC-03
Context review — covering combined external and internal AI context — is performed at defined cadence and on material change, with findings driving AIMS adjustments
7.00
6.00
1.00
6.00
0.00
1.00
CON.IP-02
Affected parties — individuals or groups potentially impacted by AI outputs, decisions, or operations — are identified per AI system and maintained for use in impact assessment
7.00
6.00
1.00
6.00
0.00
1.00
Risk Domain
23 Controls across 7 Objectives.
Healthy (Gap ≤ 0.49)Watch (Gap 0.50–1.25)Attention (Gap > 1.25)
Target
6.30
Current
5.87
Gap
0.43
Total Controls
23
At Target
12
Below Target
11
Per-Objective Detail
ID
Objective
Target
Current
Gap
Controls
At Target
Below Target
RSK.ME
AI Risk Management Methodology
6.25
6.00
0.25
4
2
2
RSK.ID
AI Risk Identification
6.33
6.00
0.33
3
2
1
RSK.AS
AI Risk Assessment
6.33
5.67
0.67
3
2
1
RSK.TR
AI Risk Treatment and Acceptance
6.00
5.33
0.67
3
1
2
RSK.RG
AI Risk Register and Reporting
6.00
5.67
0.33
3
2
1
RSK.AR
Adversarial AI Risk Management
6.75
6.00
0.75
4
1
3
RSK.MO
AI Risk Monitoring and Reassessment
6.33
6.33
0.00
3
2
1
Controls Below Target 11
Every Control in this Domain where Current < Target. Sorted by Gap (largest first).
ID
Control
Target
Current
Gap
Forecast
Growth
F Gap
RSK.AS-02
Portfolio-level AI risk assessment — aggregating per-AI risks across the AI inventory to identify concentration, systemic, and cross-cutting risks — is performed and reported
7.00
5.00
2.00
6.00
1.00
1.00
RSK.AR-03
Prompt-layer and agentic adversarial risks — covering prompt injection (direct and indirect), tool misuse, goal hijack, and multi-agent collusion — are identified, assessed, and treated
7.00
5.00
2.00
6.00
1.00
1.00
RSK.ME-01
The AI risk management methodology — covering assessment criteria, scoring approach, and treatment options — is documented, communicated, and maintained
6.00
5.00
1.00
6.00
1.00
0.00
RSK.ME-02
AI risk classes — covering functional, legal, ethical, societal, and commercial risk — are defined and applied to AI risk identification and assessment
7.00
6.00
1.00
6.00
0.00
1.00
RSK.ID-01
AI risk identification process — covering techniques (threat modelling, risk workshops, incident review, horizon scanning) and risk sources — is documented and performed
7.00
6.00
1.00
6.00
0.00
1.00
RSK.TR-02
Residual risk acceptance — covering acceptance authority per risk level, documentation requirements, time-bound acceptance, and Statement of Applicability approval — is established and applied
6.00
5.00
1.00
6.00
1.00
0.00
RSK.TR-03
Treatment effectiveness verification — confirming that implemented treatments deliver the intended residual risk reduction, and updating the Statement of Applicability where verification findings warrant — is performed and documented
6.00
5.00
1.00
6.00
1.00
0.00
RSK.RG-02
AI risk reporting — covering risk posture reporting to AI governance forums and board with defined cadence and content — is established and performed
6.00
5.00
1.00
6.00
1.00
0.00
RSK.AR-01
Adversarial AI threat modelling — performed per AI system using established taxonomies — is performed at design and updated on material change
7.00
6.00
1.00
6.00
0.00
1.00
RSK.AR-04
AI red teaming and adversarial testing programme — covering scope, frequency, methodology, and findings management — is established and operated
7.00
6.00
1.00
6.00
0.00
1.00
RSK.MO-01
AI key risk indicators — defined to detect emerging risk and indicate risk posture trends — are monitored on defined cadence
7.00
6.00
1.00
6.00
0.00
1.00
Impact Domain
23 Controls across 6 Objectives.
Healthy (Gap ≤ 0.49)Watch (Gap 0.50–1.25)Attention (Gap > 1.25)
Target
6.26
Current
5.61
Gap
0.65
Total Controls
23
At Target
11
Below Target
12
Per-Objective Detail
ID
Objective
Target
Current
Gap
Controls
At Target
Below Target
IMP.ME
AI Impact Assessment Methodology
6.00
5.67
0.33
3
2
1
IMP.IA
AI System Impact Assessment
6.00
5.50
0.50
6
3
3
IMP.DA
Data Protection Impact Assessment for AI
6.00
5.67
0.33
3
2
1
IMP.GP
GPAI Compliance and Conformity
7.00
5.40
1.60
5
0
5
IMP.MO
Pre-deployment and Post-deployment Impact Monitoring
6.00
6.00
0.00
3
3
0
IMP.IR
Independent Impact Review
6.33
5.67
0.67
3
1
2
Controls Below Target 12
Every Control in this Domain where Current < Target. Sorted by Gap (largest first).
ID
Control
Target
Current
Gap
Forecast
Growth
F Gap
IMP.GP-02
GPAI provider obligations per Art. 53 — technical documentation, copyright policy, and training data summary — are produced and maintained for each GPAI model
7.00
4.00
3.00
6.00
2.00
1.00
IMP.GP-01
GPAI classification and systemic-risk threshold assessment — performed per AI model per EU AI Act Art. 51 — is documented
7.00
5.00
2.00
6.00
1.00
1.00
IMP.ME-02
Role-specific methodology application — covering how the impact assessment methodology is applied for provider, deployer, and internal-developer contexts — is documented and maintained
6.00
5.00
1.00
6.00
1.00
0.00
IMP.IA-04
Impact assessment triggers — new AI system, material change, post-incident, regulatory change — are defined and applied
6.00
5.00
1.00
6.00
1.00
0.00
IMP.IA-05
AI benefits and cost-of-errors analysis per AI system — covering intended benefits per affected-party category, expected and realised costs of errors, non-monetary costs, and benefit-cost trade-off documentation — is performed and documented
6.00
5.00
1.00
6.00
1.00
0.00
IMP.IA-06
Environmental impact assessment per AI system — covering compute energy consumption, water use, carbon footprint, hardware lifecycle, and sustainability mitigation — is performed and documented
6.00
5.00
1.00
6.00
1.00
0.00
IMP.DA-01
DPIA scope determination for AI processing — assessing Art. 35 triggers per AI processing activity — is performed and documented
6.00
5.00
1.00
6.00
1.00
0.00
IMP.GP-03
GPAI procedural rights and challenge process — per Art. 52 — are established to respond to Commission designation processes and corrections
7.00
6.00
1.00
6.00
0.00
1.00
IMP.GP-04
Systemic-risk GPAI obligations per Art. 55 — model evaluation, adversarial testing, serious incident reporting, and cybersecurity — are established and maintained for models meeting systemic-risk thresholds
7.00
6.00
1.00
6.00
0.00
1.00
IMP.GP-05
Authorised representative arrangement per Art. 54 — where the provider is established outside the EU — is established with documented mandate and oversight
7.00
6.00
1.00
6.00
0.00
1.00
IMP.IR-02
Independent review of AI impact assessments per defined scope — covering review of methodology application, completeness, and conclusions — is performed and documented
7.00
6.00
1.00
6.00
0.00
1.00
IMP.IR-03
Independent review findings, escalation, and action tracking — covering documentation, escalation pathway, and closure verification — are maintained
6.00
5.00
1.00
6.00
1.00
0.00
Data Domain
35 Controls across 10 Objectives.
Healthy (Gap ≤ 0.49)Watch (Gap 0.50–1.25)Attention (Gap > 1.25)
Target
6.14
Current
5.63
Gap
0.51
Total Controls
35
At Target
17
Below Target
18
Per-Objective Detail
ID
Objective
Target
Current
Gap
Controls
At Target
Below Target
DAT.PO
AI Data Governance Policy and Methodology
6.00
6.00
0.00
3
3
0
DAT.IN
AI Data Inventory and Classification
6.50
6.50
0.00
4
4
0
DAT.PR
Data Provenance and Lineage
6.33
5.67
0.67
3
1
2
DAT.QU
Data Quality
6.00
5.00
1.00
4
0
4
DAT.BI
Bias-in-Data Measurement and Mitigation
6.00
5.25
0.75
4
1
3
DAT.LB
Lawful Basis and Data Subject Rights for AI
6.00
5.40
0.60
5
2
3
DAT.RE
Data Minimisation and Retention for AI
6.00
5.33
0.67
3
1
2
DAT.SY
Synthetic Data Governance
6.00
6.00
0.00
3
3
0
DAT.LA
Data Labelling and Annotation Governance
6.00
5.33
0.67
3
1
2
DAT.LK
AI Data Leakage Prevention
6.67
6.00
0.67
3
1
2
Controls Below Target 18
Every Control in this Domain where Current < Target. Sorted by Gap (largest first).
ID
Control
Target
Current
Gap
Forecast
Growth
F Gap
DAT.PR-02
Lineage tracking across the AI data lifecycle — from source through training, fine-tuning, evaluation, and inference — is established and maintained
6.00
5.00
1.00
6.00
1.00
0.00
DAT.PR-03
Third-party data provenance verification — covering supplier-provided datasets and third-party model training data — is performed and documented
7.00
6.00
1.00
6.00
0.00
1.00
DAT.QU-01
AI data quality criteria — covering representativeness, completeness, accuracy, consistency, and timeliness — are defined per lifecycle stage and applied
6.00
5.00
1.00
6.00
1.00
0.00
DAT.QU-02
AI data quality measurement and monitoring — covering ingestion-time assessment and ongoing monitoring — is performed and reported
6.00
5.00
1.00
6.00
1.00
0.00
DAT.QU-03
AI data quality treatment and remediation — covering cleaning, augmentation, rebalancing, and rejection — are applied where quality issues are identified
6.00
5.00
1.00
6.00
1.00
0.00
DAT.QU-04
AI data quality assurance review is performed at defined cadence with findings driving methodology and treatment improvements
6.00
5.00
1.00
6.00
1.00
0.00
DAT.BI-01
Bias identification methodology for AI datasets — covering bias sources, identification techniques, and documentation — is established and applied
6.00
5.00
1.00
6.00
1.00
0.00
DAT.BI-02
Bias measurement in AI datasets — covering representativeness, demographic balance, label bias, and outcome bias — is performed and documented
6.00
5.00
1.00
6.00
1.00
0.00
DAT.BI-03
Bias mitigation at dataset level — covering sampling, augmentation, reweighting, and debiasing techniques — is applied where bias is identified
6.00
5.00
1.00
6.00
1.00
0.00
DAT.LB-01
Lawful basis determination per AI processing activity — covering GDPR Art. 6 grounds and Art. 9 special category restrictions — is performed and documented
6.00
5.00
1.00
6.00
1.00
0.00
DAT.LB-04
Consent management where AI processing relies on consent — covering valid consent collection, withdrawal handling, and record-keeping — is operated
6.00
5.00
1.00
6.00
1.00
0.00
DAT.LB-05
International data transfers for AI processing per GDPR Art. 44–49 — covering transfer mechanism selection, Transfer Impact Assessment, supplementary measures, and per-transfer record-keeping — are established and maintained
6.00
5.00
1.00
6.00
1.00
0.00
DAT.RE-01
Data minimisation in collection and processing — covering necessity assessment, purpose limitation, and use restriction — is applied across the AI data lifecycle
6.00
5.00
1.00
6.00
1.00
0.00
DAT.RE-03
Lawful disposal at end of retention — covering deletion, anonymisation, and verification — is performed for AI data classes
6.00
5.00
1.00
6.00
1.00
0.00
DAT.LA-02
Annotator competence and training — covering competence requirements, training, and ongoing capability assessment — are established
6.00
5.00
1.00
6.00
1.00
0.00
DAT.LA-03
Ethical and labour considerations for the annotation workforce — covering working conditions, exposure to harmful content, and fair labour practices — are established
6.00
5.00
1.00
6.00
1.00
0.00
DAT.LK-01
Training-time data exposure prevention — covering Restricted data exclusion, memorisation reduction, and access governance — is established
7.00
6.00
1.00
6.00
0.00
1.00
DAT.LK-02
Output-side leakage prevention — covering model regurgitation, membership inference resistance, and output filtering — is established
7.00
6.00
1.00
6.00
0.00
1.00
Lifecycle Domain
49 Controls across 11 Objectives.
Healthy (Gap ≤ 0.49)Watch (Gap 0.50–1.25)Attention (Gap > 1.25)
Target
6.41
Current
5.80
Gap
0.61
Total Controls
49
At Target
19
Below Target
30
Per-Objective Detail
ID
Objective
Target
Current
Gap
Controls
At Target
Below Target
LIF.PO
AI Lifecycle Policy and Process
6.00
5.67
0.33
3
2
1
LIF.DE
AI Design and Requirements Engineering
6.60
6.00
0.60
5
2
3
LIF.DV
Secure AI Development
6.00
5.60
0.40
5
3
2
LIF.TR
AI Training Process Governance
6.75
6.00
0.75
4
1
3
LIF.VA
AI Validation and Evaluation
6.17
5.67
0.50
6
3
3
LIF.DP
AI Deployment and Release Management
6.25
5.75
0.50
4
2
2
LIF.OP
AI Operational Monitoring
6.60
5.60
1.00
5
0
5
LIF.VR
AI Versioning and Registry
6.25
6.00
0.25
4
3
1
LIF.IR
AI Incident Response
7.00
6.00
1.00
5
0
5
LIF.DC
AI Decommissioning and Retirement
6.00
5.33
0.67
3
1
2
LIF.AG
Agentic System Design and Authorisation
6.60
6.00
0.60
5
2
3
Controls Below Target 30
Every Control in this Domain where Current < Target. Sorted by Gap (largest first).
ID
Control
Target
Current
Gap
Forecast
Growth
F Gap
LIF.PO-02
Stage-gate criteria and approval authorities — covering go / no-go criteria, approval authority per stage, and evidence required at each gate — are defined and applied
6.00
5.00
1.00
6.00
1.00
0.00
LIF.DE-02
AI architecture and design decisions — covering model selection, data flow, integration topology, and trade-off documentation — are performed and documented
7.00
6.00
1.00
6.00
0.00
1.00
LIF.DE-03
Safety-by-design and ethics-by-design principles — covering safety constraints, ethical safeguards, and design-time consideration of harm scenarios — are applied per AI system
7.00
6.00
1.00
6.00
0.00
1.00
LIF.DE-04
Design review and approval — covering review scope, participants, evidence required, and approval authority — are performed before progression to development
7.00
6.00
1.00
6.00
0.00
1.00
LIF.DV-04
Secure coding practices for AI components — covering AI-specific secure coding, code review, and testing integration — are established
6.00
5.00
1.00
6.00
1.00
0.00
LIF.DV-05
Model artefact integrity controls — covering model storage, signing, verification, and safe loading — are established and maintained
6.00
5.00
1.00
6.00
1.00
0.00
LIF.TR-01
Training data preparation and integrity — covering dataset selection, pre-processing, integrity verification, and split discipline — is established per training run
7.00
6.00
1.00
6.00
0.00
1.00
LIF.TR-03
Training run documentation and reproducibility — covering hyperparameter capture, run metadata, and reproducibility artefacts — are established per training run
7.00
6.00
1.00
6.00
0.00
1.00
LIF.TR-04
Foundation model training process governance — covering pretraining decisions, fine-tuning workflows, and safety alignment — is established
7.00
6.00
1.00
6.00
0.00
1.00
LIF.VA-01
Performance evaluation against defined metrics — covering metric selection, evaluation execution, and performance thresholds — is performed per AI system before deployment
6.00
5.00
1.00
6.00
1.00
0.00
LIF.VA-02
Robustness and stress testing — covering perturbation testing, distribution shift testing, and resource stress testing — is performed pre-deployment
6.00
5.00
1.00
6.00
1.00
0.00
LIF.VA-04
Adversarial testing pre-deployment — covering attack-surface testing, red teaming, and capability elicitation — is performed and findings remediated
7.00
6.00
1.00
6.00
0.00
1.00
LIF.DP-03
Provider release documentation and instructions for use — produced per EU AI Act Art. 13 expectations and TRA.IU — accompany every provider release
7.00
6.00
1.00
6.00
0.00
1.00
LIF.DP-04
Deployer acceptance testing of consumed AI — covering pre-adoption evaluation, contractual conformance verification, and integration validation — is performed
6.00
5.00
1.00
6.00
1.00
0.00
LIF.OP-01
Runtime performance monitoring against expected baselines — covering metric collection, baseline comparison, and divergence alerting — is established per AI system
6.00
5.00
1.00
6.00
1.00
0.00
LIF.OP-02
Data and concept drift detection — covering input distribution monitoring, output drift monitoring, and ground-truth drift — is established
6.00
5.00
1.00
6.00
1.00
0.00
LIF.OP-03
Abuse pattern and adversarial behaviour detection — covering anomalous input detection, jailbreak attempt detection, and rate / pattern analysis — is established
7.00
6.00
1.00
6.00
0.00
1.00
LIF.OP-04
Output safety monitoring — covering harmful output detection, hallucination monitoring, refusal-failure tracking, and PII leakage detection — is established
7.00
6.00
1.00
6.00
0.00
1.00
LIF.OP-05
Retraining triggers and operational reporting — covering automated triggers, manual triggers, decision authority, and operational reporting cadence — are established
7.00
6.00
1.00
6.00
0.00
1.00
LIF.VR-03
Dataset versioning linked to model versions — covering dataset version identifiers, dataset registry, and model-to-dataset linkage — is established
7.00
6.00
1.00
6.00
0.00
1.00
LIF.IR-01
AI incident classes and declaration criteria — covering AI-specific incident taxonomy, declaration thresholds, and triage process — are defined
7.00
6.00
1.00
6.00
0.00
1.00
LIF.IR-02
AI incident response and containment process — covering response activation, containment actions, evidence preservation, and stakeholder notification — is established
7.00
6.00
1.00
6.00
0.00
1.00
LIF.IR-03
Root cause analysis and post-incident learning — covering systematic investigation, lessons captured, and improvement actions — are established
7.00
6.00
1.00
6.00
0.00
1.00
LIF.IR-04
Serious incident reporting for GPAI per EU AI Act Art. 55 — covering reporting criteria, timelines, content, and follow-up — is established
7.00
6.00
1.00
6.00
0.00
1.00
LIF.IR-05
Provider corrective actions and duty of information per EU AI Act Art. 20 — covering non-conformity triggers, corrective actions, downstream notification, and authority cooperation — are established
7.00
6.00
1.00
6.00
0.00
1.00
LIF.DC-01
AI decommissioning process and triggers — covering retirement criteria, decommissioning workflow, and decision authority — are established
6.00
5.00
1.00
6.00
1.00
0.00
LIF.DC-02
Provider end-of-life customer notification and migration support — covering notification timelines, migration assistance, and contractual obligation handling — are established
6.00
5.00
1.00
6.00
1.00
0.00
LIF.AG-01
Agent authorisation scope — covering tools, actions, data access, autonomy level, and per-agent scope documentation — is defined and enforced
7.00
6.00
1.00
6.00
0.00
1.00
LIF.AG-03
Multi-agent orchestration design and inter-agent communication — covering communication protocols, authority boundaries, and conflict resolution — are established
7.00
6.00
1.00
6.00
0.00
1.00
LIF.AG-05
Emergency suspension and revocation capability for agentic systems — covering kill switches, capability revocation, and tested exercise — is established
7.00
6.00
1.00
6.00
0.00
1.00
Trust Domain
35 Controls across 9 Objectives.
Healthy (Gap ≤ 0.49)Watch (Gap 0.50–1.25)Attention (Gap > 1.25)
Target
6.63
Current
6.20
Gap
0.43
Total Controls
35
At Target
20
Below Target
15
Per-Objective Detail
ID
Objective
Target
Current
Gap
Controls
At Target
Below Target
TRU.PO
Trustworthy AI Policy and Criteria
6.33
6.33
0.00
3
3
0
TRU.AC
AI Accuracy and Performance
6.25
6.25
0.00
4
4
0
TRU.FA
AI Fairness and Non-Discrimination
7.00
7.00
0.00
5
5
0
TRU.RB
AI Robustness
6.75
6.50
0.25
4
3
1
TRU.SA
AI Safety
7.00
6.00
1.00
5
0
5
TRU.EX
AI Explainability and Interpretability
6.25
6.00
0.25
4
3
1
TRU.PE
Privacy-Enhancing Technologies for AI
6.33
5.33
1.00
3
0
3
TRU.OI
AI Output Integrity and Provenance
7.00
6.00
1.00
4
0
4
TRU.RE
AI Resilience and Graceful Degradation
6.33
6.00
0.33
3
2
1
Controls Below Target 15
Every Control in this Domain where Current < Target. Sorted by Gap (largest first).
ID
Control
Target
Current
Gap
Forecast
Growth
F Gap
TRU.RB-04
Robustness monitoring in production — covering ongoing robustness measurement, signal detection, and response — is established
7.00
6.00
1.00
6.00
0.00
1.00
TRU.SA-01
AI safety boundaries — covering harmful output prevention, refusal training, content filters, and policy enforcement — are established per AI system
7.00
6.00
1.00
6.00
0.00
1.00
TRU.SA-02
Agent behaviour safety — covering action limits, goal alignment, multi-agent containment, and behaviour boundaries — is established per agent system
7.00
6.00
1.00
6.00
0.00
1.00
TRU.SA-03
AI safety testing methodology — covering safety test design, evaluation criteria, and methodology documentation — is established
7.00
6.00
1.00
6.00
0.00
1.00
TRU.SA-04
Dangerous-capability assessment for foundation models — covering capability elicitation, risk thresholds, and Art. 55 alignment — is performed per GPAI per IMP.GP-01
7.00
6.00
1.00
6.00
0.00
1.00
TRU.SA-05
AI safety monitoring in production — covering refusal-failure tracking, safety boundary breach detection, and reporting — is established
7.00
6.00
1.00
6.00
0.00
1.00
TRU.EX-04
User-facing explanation delivery — covering presentation, accessibility, and linkage with right-to-explanation processes — is established
7.00
6.00
1.00
6.00
0.00
1.00
TRU.PE-01
PET selection and application per AI use case — covering PET options, selection criteria, and application — are established
7.00
6.00
1.00
6.00
0.00
1.00
TRU.PE-02
Privacy-preserving training — covering differential privacy, federated learning, and secure multi-party computation where applied — is established
6.00
5.00
1.00
6.00
1.00
0.00
TRU.PE-03
PET effectiveness measurement — covering privacy guarantee verification, residual privacy risk assessment, and reporting — is performed
6.00
5.00
1.00
6.00
1.00
0.00
TRU.OI-01
AI-generated content marking and watermarking per EU AI Act Art. 50 — covering provider obligations and technical implementation — is applied
7.00
6.00
1.00
6.00
0.00
1.00
TRU.OI-02
Output provenance traceability — covering output-to-model linkage, output-to-input lineage, and audit traceability — is established
7.00
6.00
1.00
6.00
0.00
1.00
TRU.OI-03
Synthetic content identification (deepfake, AI-generated media) — covering deepfake detection, attribution, and reporting — is established for deployers and providers
7.00
6.00
1.00
6.00
0.00
1.00
TRU.OI-04
Downstream attribution and output integrity verification — covering downstream-of-AI content tracking and integrity verification — is established
7.00
6.00
1.00
6.00
0.00
1.00
TRU.RE-02
Fault tolerance, failover, and graceful degradation design — covering redundancy, failover mechanisms, and degraded-mode behaviour — is established
7.00
6.00
1.00
6.00
0.00
1.00
Human Domain
21 Controls across 6 Objectives.
Healthy (Gap ≤ 0.49)Watch (Gap 0.50–1.25)Attention (Gap > 1.25)
Target
6.00
Current
5.90
Gap
0.10
Total Controls
21
At Target
18
Below Target
3
Per-Objective Detail
ID
Objective
Target
Current
Gap
Controls
At Target
Below Target
HUM.PO
Human Oversight Policy and Methodology
6.00
6.00
0.00
3
3
0
HUM.CO
Human-AI Configuration
6.00
6.00
0.00
4
4
0
HUM.IN
Override and Intervention Mechanisms
6.00
5.75
0.25
4
3
1
HUM.CM
Oversight Competence and AI Literacy for Overseers
6.00
6.00
0.00
3
3
0
HUM.EF
Oversight Effectiveness Measurement
6.00
6.33
-0.33
3
3
0
HUM.UA
User Agency, Appeal, and Contestability
6.00
5.50
0.50
4
2
2
Controls Below Target 3
Every Control in this Domain where Current < Target. Sorted by Gap (largest first).
ID
Control
Target
Current
Gap
Forecast
Growth
F Gap
HUM.IN-01
Override capability per AI system — covering override availability, override interfaces, and authorisation — is established
6.00
5.00
1.00
6.00
1.00
0.00
HUM.UA-02
Right to explanation of AI decisions per EU AI Act Art. 86 and GDPR Art. 22 — covering eligibility, request handling, and explanation delivery — is operationalised
6.00
5.00
1.00
6.00
1.00
0.00
HUM.UA-04
Redress and remediation pathways — covering harm redress, restorative actions, and systemic improvement — are established
6.00
5.00
1.00
6.00
1.00
0.00
Transparency Domain
19 Controls across 7 Objectives.
Healthy (Gap ≤ 0.49)Watch (Gap 0.50–1.25)Attention (Gap > 1.25)
Target
6.05
Current
5.79
Gap
0.26
Total Controls
19
At Target
14
Below Target
5
Per-Objective Detail
ID
Objective
Target
Current
Gap
Controls
At Target
Below Target
TRA.PO
Transparency Policy
6.00
6.00
0.00
2
2
0
TRA.TD
Technical Documentation
6.00
5.67
0.33
3
2
1
TRA.MC
Model Cards and System Cards
6.00
5.50
0.50
2
1
1
TRA.IU
Instructions for Use
6.00
6.00
0.00
3
3
0
TRA.LR
Record-Keeping and Logs
6.00
5.67
0.33
3
2
1
TRA.UD
User-Facing Disclosure
6.00
5.75
0.25
4
3
1
TRA.AG
Agentic Action Logs and Decision Traces
6.50
6.00
0.50
2
1
1
Controls Below Target 5
Every Control in this Domain where Current < Target. Sorted by Gap (largest first).
ID
Control
Target
Current
Gap
Forecast
Growth
F Gap
TRA.TD-01
Provider technical documentation — covering content per EU AI Act Art. 11 and Annex IV applicable elements, draft–issue–maintain workflow, and pre-market readiness — is produced for in-scope AI
6.00
5.00
1.00
6.00
1.00
0.00
TRA.MC-02
System card production, version control, and accessibility — covering system architecture description, AI components used, integration context, and publication — are established
6.00
5.00
1.00
6.00
1.00
0.00
TRA.LR-03
Log retention, integrity protection, and access governance — covering per-class retention, integrity controls, and access controls — are operationalised
6.00
5.00
1.00
6.00
1.00
0.00
TRA.UD-01
AI interaction disclosure to natural persons per EU AI Act Art. 50(1) — covering disclosure trigger, content, form, and timing — is operationalised
6.00
5.00
1.00
6.00
1.00
0.00
TRA.AG-02
Agentic trace retention, integrity protection, and use in oversight and incident response — covering retention, integrity, replay support, and access governance — are operationalised
7.00
6.00
1.00
6.00
0.00
1.00
Third-Party Domain
26 Controls across 7 Objectives.
Healthy (Gap ≤ 0.49)Watch (Gap 0.50–1.25)Attention (Gap > 1.25)
Target
6.35
Current
6.23
Gap
0.12
Total Controls
26
At Target
23
Below Target
3
Per-Objective Detail
ID
Objective
Target
Current
Gap
Controls
At Target
Below Target
TPA.PO
Third-Party AI Policy
6.00
6.00
0.00
2
2
0
TPA.DD
AI Vendor Due Diligence
6.50
6.00
0.50
4
2
2
TPA.CT
AI Contractual and Shared Responsibility
6.20
6.20
0.00
5
5
0
TPA.SC
AI Supply Chain Integrity
6.50
6.50
0.00
4
4
0
TPA.AT
Agentic Third-Party and Tool Supply Chain
6.25
6.25
0.00
4
4
0
TPA.GP
GPAI Provider Obligations
6.33
6.00
0.33
3
2
1
TPA.DR
Deployer Obligations for Consumed AI
6.50
6.50
0.00
4
4
0
Controls Below Target 3
Every Control in this Domain where Current < Target. Sorted by Gap (largest first).
ID
Control
Target
Current
Gap
Forecast
Growth
F Gap
TPA.DD-01
AI vendor due diligence criteria per vendor class — covering foundation model providers, AI API and service vendors, fine-tuning relationships, and model marketplaces — are established and applied
7.00
6.00
1.00
6.00
0.00
1.00
TPA.DD-02
Due diligence depth scaled by AI risk class — covering risk-classification linkage, scaled rigour, and approval authority — is operationalised
7.00
6.00
1.00
6.00
0.00
1.00
TPA.GP-02
Support for downstream conformity — covering downstream conformity support, response to downstream queries, and information sufficiency — is provided
7.00
6.00
1.00
6.00
0.00
1.00
AIMS Controls
10 Domains • 80 Objectives • 301 Controls (Click any area to see full details)
Govern50 Controls · 12 Objectives
GOV.POAI Policy4 Controls
Description: AI policy — defining organisational AI principles, scope of application, alignment with business strategy and other organisational policies, accountability for AI, and periodic review — is documented, communicated, and maintained
GOV.PO-01The AI policy is documented, approved at appropriate authority level, and version-controlled, defining organisational AI principles, scope of application, accountability for AI, and review cadenceT 6 · C 6 · F 6
Applies To
AI policy document and supporting records
AI principles and ethical commitments statement
Scope of AI activities covered — provider, deployer, internal developer
Accountability assignments at organisational level
Version control records and approval evidence
Review cadence definition
AI principles and ethical commitments statement
Scope of AI activities covered — provider, deployer, internal developer
Accountability assignments at organisational level
Version control records and approval evidence
Review cadence definition
Control Details
The AI policy is documented in a defined policy statement, approved at appropriate authority level (Board or top management) per ISO 42001 Cl. 5.2
The policy articulates the organisation's AI principles, ethical commitments, and risk-based approach to AI
The policy scope explicitly covers AI provider activities, AI deployer activities, and internal AI development
The policy assigns top-level accountability for the AI Management System and AI outcomes
Policy versioning is maintained with version control and approval evidence
Policy review is performed at defined cadence (at minimum annually and on material change to AI scope, regulatory environment, or organisational structure)
The policy is communicated per GOV.PO-03
The policy articulates the organisation's AI principles, ethical commitments, and risk-based approach to AI
The policy scope explicitly covers AI provider activities, AI deployer activities, and internal AI development
The policy assigns top-level accountability for the AI Management System and AI outcomes
Policy versioning is maintained with version control and approval evidence
Policy review is performed at defined cadence (at minimum annually and on material change to AI scope, regulatory environment, or organisational structure)
The policy is communicated per GOV.PO-03
Control Mapping
ISO/IEC 42001:2023 — Cl. 4.4; Cl. 5.2; A.2.2
NIST AI RMF — GOVERN 1.1; GOVERN 1.2
EU AI Act — Art. 17(2)(a)
OECD AI Principles (OECD/LEGAL/0449)
NIST AI RMF — GOVERN 1.1; GOVERN 1.2
EU AI Act — Art. 17(2)(a)
OECD AI Principles (OECD/LEGAL/0449)
GOV.PO-02AI policy alignment with business strategy and other organisational policies — InfoSec, privacy, code of conduct, vendor management, and ethics — is established and maintained to ensure mutual reinforcement and conflict resolutionT 6 · C 6 · F 6
Applies To
Alignment with business strategy and AI strategy per GOV.ST
Alignment with the Information Security Management System
Alignment with the data protection and privacy policy framework
Alignment with the code of conduct and ethics framework
Alignment with vendor management and procurement policies
Conflict identification and resolution mechanisms
Alignment with the Information Security Management System
Alignment with the data protection and privacy policy framework
Alignment with the code of conduct and ethics framework
Alignment with vendor management and procurement policies
Conflict identification and resolution mechanisms
Control Details
The AI policy is aligned with the organisation's overall strategy and AI strategy per GOV.ST
Cross-references are established between the AI policy and adjacent policy frameworks (InfoSec, privacy, code of conduct, vendor management, IP, legal & regulatory)
Conflicts and overlaps between the AI policy and adjacent policies are identified and resolved through a defined process
Mutual reinforcement is established (e.g., AI policy refers to ISMS for security obligations; ISMS refers to AI policy for AI-specific provisions)
Policy alignment is reviewed when any aligned policy is materially updated
Cross-policy alignment is communicated to interested parties
Cross-references are established between the AI policy and adjacent policy frameworks (InfoSec, privacy, code of conduct, vendor management, IP, legal & regulatory)
Conflicts and overlaps between the AI policy and adjacent policies are identified and resolved through a defined process
Mutual reinforcement is established (e.g., AI policy refers to ISMS for security obligations; ISMS refers to AI policy for AI-specific provisions)
Policy alignment is reviewed when any aligned policy is materially updated
Cross-policy alignment is communicated to interested parties
Control Mapping
ISO/IEC 42001:2023 — Cl. 5.2; A.2.3
NIST AI RMF — GOVERN 1.2; GOVERN 1.4
ISO/IEC 38507:2022 — Cl. 5
ISO/IEC 27001:2022 — A.5.1
NIST AI RMF — GOVERN 1.2; GOVERN 1.4
ISO/IEC 38507:2022 — Cl. 5
ISO/IEC 27001:2022 — A.5.1
GOV.PO-03AI policy communication and accessibility are established so that the AI policy is communicated, accessible, and understood across the organisation and to interested partiesT 6 · C 6 · F 6
Applies To
Internal communication channels (intranet, onboarding, town halls, training)
External communication channels for relevant interested parties
Language and format requirements
Accessibility considerations
Acknowledgement and confirmation of receipt where applicable
External communication channels for relevant interested parties
Language and format requirements
Accessibility considerations
Acknowledgement and confirmation of receipt where applicable
Control Details
The AI policy is communicated to all personnel with AI-related roles or responsibilities
The AI policy is included in onboarding materials and training programmes
The current approved version is made accessible through defined channels (intranet, document repository)
Policy availability is provided in the required languages
Where required, acknowledgement of receipt and understanding is recorded
External communication of the AI policy is provided to interested parties where contractually, regulatorily, or ethically required
Communication is repeated when material policy updates occur
The AI policy is included in onboarding materials and training programmes
The current approved version is made accessible through defined channels (intranet, document repository)
Policy availability is provided in the required languages
Where required, acknowledgement of receipt and understanding is recorded
External communication of the AI policy is provided to interested parties where contractually, regulatorily, or ethically required
Communication is repeated when material policy updates occur
Control Mapping
ISO/IEC 42001:2023 — Cl. 5.2; Cl. 7.4; A.2.2
NIST AI RMF — GOVERN 1.4; GOVERN 2.2
EU AI Act — Art. 4
OECD AI Principles (OECD/LEGAL/0449)
NIST AI RMF — GOVERN 1.4; GOVERN 2.2
EU AI Act — Art. 4
OECD AI Principles (OECD/LEGAL/0449)
GOV.PO-04AI policy review is performed at defined cadence and on material change to AI scope, regulatory environment, threat landscape, or organisational structureT 6 · C 6 · F 6
Applies To
Policy review schedule (at minimum annually)
Material change triggers
Policy review process
Review participants and approval authority
Change history record
Material change triggers
Policy review process
Review participants and approval authority
Change history record
Control Details
The AI policy is reviewed at minimum annually by the AI policy owner with approval from the appropriate authority
The policy is reviewed ad-hoc on material change triggers (new regulatory developments, material change to AI portfolio, major incident, change to AI scope per CON.SC, change to AI strategy per GOV.ST, organisational restructure)
Review participants include representatives from AI governance, InfoSec, privacy, legal, and AI engineering
Review findings are documented; required changes are tracked through change management
Updated versions are approved and version-controlled per GOV.PO-01
Change history is recorded for audit traceability
The policy is reviewed ad-hoc on material change triggers (new regulatory developments, material change to AI portfolio, major incident, change to AI scope per CON.SC, change to AI strategy per GOV.ST, organisational restructure)
Review participants include representatives from AI governance, InfoSec, privacy, legal, and AI engineering
Review findings are documented; required changes are tracked through change management
Updated versions are approved and version-controlled per GOV.PO-01
Change history is recorded for audit traceability
Control Mapping
ISO/IEC 42001:2023 — Cl. 5.2; Cl. 9.3; A.2.4
NIST AI RMF — GOVERN 1.5
EU AI Act — Art. 17(2)
ISO/IEC 38507:2022 — Cl. 5.4
NIST AI RMF — GOVERN 1.5
EU AI Act — Art. 17(2)
ISO/IEC 38507:2022 — Cl. 5.4
GOV.STAI Strategy5 Controls
Description: AI strategy — covering AI product and service offerings, third-party AI consumption, internal AI development, alignment with corporate strategy and KPIs, and strategic review — is documented, approved, and maintained
GOV.ST-01The AI strategy framework is documented, approved at appropriate authority level, and version-controlled, integrating AI product strategy, AI consumption strategy, and AI internal development strategyT 7 · C 6 · F 6
Applies To
AI strategy document and supporting records
AI strategic objectives and KPIs
Integration across the three AI strategic modes (provider, deployer, internal developer)
Approval authority
Version control records
AI strategic objectives and KPIs
Integration across the three AI strategic modes (provider, deployer, internal developer)
Approval authority
Version control records
Control Details
The AI strategy is documented as a formal strategic artefact, approved at top management or Board level
The strategy integrates AI product / service offerings (provider mode), third-party AI consumption (deployer mode), and internal AI development (internal-developer mode) into a coherent strategic narrative
Strategic AI objectives are defined and tied to business objectives per GOV.OV-02
Strategic KPIs and target outcomes are defined per AI activity
Approval authority is defined for the AI strategy and material updates
Strategy versioning and approval evidence are maintained
The strategy integrates AI product / service offerings (provider mode), third-party AI consumption (deployer mode), and internal AI development (internal-developer mode) into a coherent strategic narrative
Strategic AI objectives are defined and tied to business objectives per GOV.OV-02
Strategic KPIs and target outcomes are defined per AI activity
Approval authority is defined for the AI strategy and material updates
Strategy versioning and approval evidence are maintained
Control Mapping
ISO/IEC 42001:2023 — Cl. 5.1; A.2.3
NIST AI RMF — GOVERN 1.3; GOVERN 1.4
OECD AI Principles (OECD/LEGAL/0449)
ISO/IEC 38507:2022 — Cl. 5
NIST AI RMF — GOVERN 1.3; GOVERN 1.4
OECD AI Principles (OECD/LEGAL/0449)
ISO/IEC 38507:2022 — Cl. 5
GOV.ST-02AI product and service strategy — the provider-mode strategy for AI products and services placed on the market — is documented, approved, and aligned with corporate strategy and target customer needsT 7 · C 6 · F 6
Applies To
AI product and service offerings (provider mode)
Target customer segments
Product roadmap for AI products
Competitive positioning
Foundation model offerings — own developed, fine-tuned
Commercial AI portfolio decisions
Regulatory positioning (limited-risk AI, GPAI obligations)
Target customer segments
Product roadmap for AI products
Competitive positioning
Foundation model offerings — own developed, fine-tuned
Commercial AI portfolio decisions
Regulatory positioning (limited-risk AI, GPAI obligations)
Control Details
The AI product and service strategy is documented, defining target market, customer segments, and product positioning
AI product roadmap addresses near-, mid-, and long-term AI offerings
Foundation model offerings (own developed and fine-tuned) are explicitly addressed in the product strategy
Regulatory positioning is considered — AI products are designed for EU AI Act limited-risk path and GPAI obligations per Art. 50+
Strategic decisions on AI product offerings are subject to AI risk appetite per GOV.RA
Competitive positioning is reviewed at defined cadence
Strategic decisions are made through the AI governance forums per GOV.GF
AI product roadmap addresses near-, mid-, and long-term AI offerings
Foundation model offerings (own developed and fine-tuned) are explicitly addressed in the product strategy
Regulatory positioning is considered — AI products are designed for EU AI Act limited-risk path and GPAI obligations per Art. 50+
Strategic decisions on AI product offerings are subject to AI risk appetite per GOV.RA
Competitive positioning is reviewed at defined cadence
Strategic decisions are made through the AI governance forums per GOV.GF
Control Mapping
ISO/IEC 42001:2023 — Cl. 5.1; A.2.3
NIST AI RMF — GOVERN 1.3; GOVERN 1.6
EU AI Act — Art. 51; Art. 50
OECD AI Principles (OECD/LEGAL/0449)
NIST AI RMF — GOVERN 1.3; GOVERN 1.6
EU AI Act — Art. 51; Art. 50
OECD AI Principles (OECD/LEGAL/0449)
GOV.ST-03AI consumption strategy — the deployer-mode strategy for adopting third-party AI products and foundation model APIs — is documented, approved, and aligned with corporate strategyT 7 · C 6 · F 6
Applies To
Third-party AI products and services consumed
Foundation model API consumption
Adoption criteria and decision rights
Strategic vendor relationships
Internal use cases for consumed AI
Consumption portfolio review
Foundation model API consumption
Adoption criteria and decision rights
Strategic vendor relationships
Internal use cases for consumed AI
Consumption portfolio review
Control Details
The AI consumption strategy is documented, identifying strategic AI tools and services to be adopted
Adoption criteria are defined (functional fit, risk profile, strategic alignment, vendor strength, cost-benefit)
Strategic foundation model API relationships are addressed (which providers, fallback options)
Internal AI use cases are prioritised per strategic value and risk
Strategic decisions on AI consumption are made through AI governance forums per GOV.GF
Consumption portfolio is reviewed at defined cadence to retire, replace, or expand consumed AI
Decisions are aligned with vendor management policy and TPA Controls
Adoption criteria are defined (functional fit, risk profile, strategic alignment, vendor strength, cost-benefit)
Strategic foundation model API relationships are addressed (which providers, fallback options)
Internal AI use cases are prioritised per strategic value and risk
Strategic decisions on AI consumption are made through AI governance forums per GOV.GF
Consumption portfolio is reviewed at defined cadence to retire, replace, or expand consumed AI
Decisions are aligned with vendor management policy and TPA Controls
Control Mapping
ISO/IEC 42001:2023 — Cl. 5.1; A.10
NIST AI RMF — GOVERN 1.3; GOVERN 6.1
EU AI Act — Art. 26
NIST AI RMF — GOVERN 1.3; GOVERN 6.1
EU AI Act — Art. 26
GOV.ST-04AI internal development strategy — the internal-developer strategy for AI capabilities built in-house for internal use — is documented, approved, and aligned with corporate strategyT 7 · C 6 · F 6
Applies To
Internal AI development pipeline and use cases
Build-vs-buy decisions
Internal AI research priorities
Internal AI capability roadmap
Internal AI tools and platforms
Internal AI investment portfolio
Build-vs-buy decisions
Internal AI research priorities
Internal AI capability roadmap
Internal AI tools and platforms
Internal AI investment portfolio
Control Details
The internal AI development strategy is documented, identifying which AI capabilities are built in-house versus acquired
Build-vs-buy decision criteria are defined per AI capability area
Internal AI research priorities are aligned with corporate strategic priorities
Internal AI capability roadmap addresses short-, mid-, and long-term horizons
Internal AI investment portfolio is prioritised and reviewed at defined cadence
Strategic decisions on internal AI development are made through AI governance forums per GOV.GF
Decisions are aligned with AI risk appetite per GOV.RA and AI strategy per GOV.ST-01
Build-vs-buy decision criteria are defined per AI capability area
Internal AI research priorities are aligned with corporate strategic priorities
Internal AI capability roadmap addresses short-, mid-, and long-term horizons
Internal AI investment portfolio is prioritised and reviewed at defined cadence
Strategic decisions on internal AI development are made through AI governance forums per GOV.GF
Decisions are aligned with AI risk appetite per GOV.RA and AI strategy per GOV.ST-01
Control Mapping
ISO/IEC 42001:2023 — Cl. 5.1
NIST AI RMF — GOVERN 1.3; GOVERN 1.4
OECD AI Principles (OECD/LEGAL/0449)
NIST AI RMF — GOVERN 1.3; GOVERN 1.4
OECD AI Principles (OECD/LEGAL/0449)
GOV.ST-05AI strategy review and refresh is performed at defined cadence and on material change, with linkage to corporate strategy review and material change triggersT 6 · C 6 · F 6
Applies To
AI strategy review schedule (at minimum annually)
Material change triggers (regulatory, technological, competitive, organisational)
Strategy review process
Strategy KPI performance review
Strategic adjustment decisions
Material change triggers (regulatory, technological, competitive, organisational)
Strategy review process
Strategy KPI performance review
Strategic adjustment decisions
Control Details
The AI strategy is reviewed at minimum annually and refreshed in line with corporate strategy review cycles
Material change triggers prompting ad-hoc review include material regulatory change (EU AI Act amendments, new GPAI obligations), material technological change (new foundation model capabilities, agentic shifts), material competitive change, and material organisational change
Strategy review evaluates progress against strategic KPIs per GOV.OV-01
Strategy refresh decisions are made by top management with input from AI governance forums per GOV.GF
Refresh outcomes are reflected in updated strategic artefacts and downstream priorities
Strategy changes are communicated to interested parties
Material change triggers prompting ad-hoc review include material regulatory change (EU AI Act amendments, new GPAI obligations), material technological change (new foundation model capabilities, agentic shifts), material competitive change, and material organisational change
Strategy review evaluates progress against strategic KPIs per GOV.OV-01
Strategy refresh decisions are made by top management with input from AI governance forums per GOV.GF
Refresh outcomes are reflected in updated strategic artefacts and downstream priorities
Strategy changes are communicated to interested parties
Control Mapping
ISO/IEC 42001:2023 — Cl. 9.3; A.2.4
NIST AI RMF — GOVERN 1.5
EU AI Act — Art. 17(2)
NIST AI RMF — GOVERN 1.5
EU AI Act — Art. 17(2)
GOV.LDAI Leadership and Commitment4 Controls
Description: AI leadership and top management commitment to the AI Management System — covering executive accountability for AI outcomes, AI commitment statements, resource allocation, integration of AI requirements into business processes, and direction and support for AI roles — is established, demonstrated, and maintained
GOV.LD-01Top management AI accountability and commitment to the AI Management System are documented, demonstrated, and communicated through a formal commitment statement and assigned executive accountabilityT 6 · C 6 · F 6
Applies To
Top management commitment statement
Designated accountable executive for the AIMS
Board-level oversight of AI
Documentation of commitment
Designated accountable executive for the AIMS
Board-level oversight of AI
Documentation of commitment
Control Details
Top management commitment to the AIMS is documented in a formal commitment statement, approved at top management or Board level
A designated accountable executive (e.g., Chief AI Officer, Director of AI Governance) is appointed with explicit accountability for the AIMS
Top management demonstrates commitment through visible actions — resource allocation, integration of AI into business processes per GOV.LD-03, board-level reporting per GOV.OV-04
Board-level oversight of AI is established and operational per GOV.GF-01
The accountable executive has direct reporting line to top management
Commitment statement is reviewed when material organisational change occurs
A designated accountable executive (e.g., Chief AI Officer, Director of AI Governance) is appointed with explicit accountability for the AIMS
Top management demonstrates commitment through visible actions — resource allocation, integration of AI into business processes per GOV.LD-03, board-level reporting per GOV.OV-04
Board-level oversight of AI is established and operational per GOV.GF-01
The accountable executive has direct reporting line to top management
Commitment statement is reviewed when material organisational change occurs
Control Mapping
ISO/IEC 42001:2023 — Cl. 5.1
NIST AI RMF — GOVERN 2.3
EU AI Act — Art. 26(1)
ISO/IEC 38507:2022 — Cl. 5
RAII Best Practices for AI Governance Structures
NIST AI RMF — GOVERN 2.3
EU AI Act — Art. 26(1)
ISO/IEC 38507:2022 — Cl. 5
RAII Best Practices for AI Governance Structures
GOV.LD-02Resources for the AIMS — covering financial, human, technological, infrastructure, and AI-specific compute and energy resources — are determined, allocated, tracked, and reviewed to ensure the AIMS has sufficient resources to meet its objectivesT 6 · C 6 · F 6
Applies To
Financial resources for the AIMS and AI portfolio
Human resources (AI engineering, AI governance, AI safety, AI ethics, oversight personnel, AI legal, AI security)
Technological resources (development, training, evaluation, inference environments)
Infrastructure resources (data centres, cloud, edge, networking, storage)
AI-specific compute and energy resources for foundation model training and high-volume inference
Resource determination, allocation, tracking, and review against AIMS objectives
Human resources (AI engineering, AI governance, AI safety, AI ethics, oversight personnel, AI legal, AI security)
Technological resources (development, training, evaluation, inference environments)
Infrastructure resources (data centres, cloud, edge, networking, storage)
AI-specific compute and energy resources for foundation model training and high-volume inference
Resource determination, allocation, tracking, and review against AIMS objectives
Control Details
Resource requirements are determined per AIMS objectives per GOV.OB and the AI portfolio per CON.IN
Financial resources are allocated through annual budgeting and tracked against AI initiatives, with multi-year planning for foundation model and compute commitments
Human resources are planned per competence framework per GOV.CO-01, covering AI engineering, AI governance, AI safety, AI ethics, oversight personnel per HUM.CM, AI legal, and AI security
Technological resources cover development, training, evaluation, and inference environments per LIF
Infrastructure resources include data centres, cloud, edge, networking, and storage proportionate to AI portfolio needs
AI-specific compute and energy resources are planned for foundation model training and high-volume inference, with energy consumption tracked per EU AI Act Annex XI Section 1 point 2(e) where applicable
Resource sufficiency is reviewed at AIMS performance evaluation per GOV.OV-02 and management review per GOV.OV-05; shortfalls trigger nonconformity per GOV.OV-07 or change planning per GOV.OB-03
Financial resources are allocated through annual budgeting and tracked against AI initiatives, with multi-year planning for foundation model and compute commitments
Human resources are planned per competence framework per GOV.CO-01, covering AI engineering, AI governance, AI safety, AI ethics, oversight personnel per HUM.CM, AI legal, and AI security
Technological resources cover development, training, evaluation, and inference environments per LIF
Infrastructure resources include data centres, cloud, edge, networking, and storage proportionate to AI portfolio needs
AI-specific compute and energy resources are planned for foundation model training and high-volume inference, with energy consumption tracked per EU AI Act Annex XI Section 1 point 2(e) where applicable
Resource sufficiency is reviewed at AIMS performance evaluation per GOV.OV-02 and management review per GOV.OV-05; shortfalls trigger nonconformity per GOV.OV-07 or change planning per GOV.OB-03
Control Mapping
ISO/IEC 42001:2023 — Cl. 7.1; Cl. 5.1; A.4; A.4.2; A.4.4; A.4.5; A.4.6
NIST AI RMF — GOVERN 1.6; MANAGE 2.1
EU AI Act — Art. 17(2)(d); Annex XI Section 1 point 2(e)
OECD AI Principles (OECD/LEGAL/0449)
ISO/IEC 5338:2023 — Cl. 6.2.2
ISO/IEC 27001:2022 — Cl. 7.1
NIST AI RMF — GOVERN 1.6; MANAGE 2.1
EU AI Act — Art. 17(2)(d); Annex XI Section 1 point 2(e)
OECD AI Principles (OECD/LEGAL/0449)
ISO/IEC 5338:2023 — Cl. 6.2.2
ISO/IEC 27001:2022 — Cl. 7.1
GOV.LD-03Integration of AI requirements into business processes is established, ensuring AI considerations are embedded into product development, procurement, vendor management, HR, legal, and customer engagement processesT 6 · C 6 · F 6
Applies To
Product / service development processes
Procurement and vendor management processes
HR processes (training, hiring per AI-related roles)
Legal and contracts processes
Customer engagement processes
Financial planning and investment processes
Procurement and vendor management processes
HR processes (training, hiring per AI-related roles)
Legal and contracts processes
Customer engagement processes
Financial planning and investment processes
Control Details
AI requirements are integrated into product development gates so that AI-relevant decisions are subject to AI governance
AI considerations are integrated into procurement and vendor management processes per TPA
HR processes (job descriptions, training, performance) reflect AI competence requirements per GOV.CO
Legal and contracts processes incorporate AI-specific clauses per TPA.CT
Customer engagement processes incorporate AI transparency and disclosure obligations per TRA.UD
Investment planning processes include AI risk and impact considerations
Integration touchpoints are documented and reviewed at defined cadence
AI considerations are integrated into procurement and vendor management processes per TPA
HR processes (job descriptions, training, performance) reflect AI competence requirements per GOV.CO
Legal and contracts processes incorporate AI-specific clauses per TPA.CT
Customer engagement processes incorporate AI transparency and disclosure obligations per TRA.UD
Investment planning processes include AI risk and impact considerations
Integration touchpoints are documented and reviewed at defined cadence
Control Mapping
ISO/IEC 42001:2023 — Cl. 5.1(b); A.4.2
NIST AI RMF — GOVERN 1.2; GOVERN 2.3
EU AI Act — Art. 17
NIST AI RMF — GOVERN 1.2; GOVERN 2.3
EU AI Act — Art. 17
GOV.LD-04Top management direction and support for AI roles and continual improvement are established, with senior leadership actively endorsing and supporting AI personnel and the AIMS improvement programmeT 6 · C 6 · F 6
Applies To
Direction and support for AI personnel
Continual improvement endorsement
Communication of AI importance to the workforce
Escalation pathway for AI concerns
Sponsorship of AIMS improvement initiatives
Continual improvement endorsement
Communication of AI importance to the workforce
Escalation pathway for AI concerns
Sponsorship of AIMS improvement initiatives
Control Details
Top management directs and supports AI personnel through clear expectations, support for hard decisions, and visible advocacy
The importance of AI governance is communicated by senior leadership to the workforce at defined cadence
Top management endorses and sponsors AIMS improvement initiatives identified through GOV.OV-07
Escalation pathway for AI concerns is documented and accessible per GOV.RR-05
Other relevant management roles are supported to demonstrate AI leadership within their areas
Leadership engagement on AI is evidenced through reviews, communications, and decision-making records
The importance of AI governance is communicated by senior leadership to the workforce at defined cadence
Top management endorses and sponsors AIMS improvement initiatives identified through GOV.OV-07
Escalation pathway for AI concerns is documented and accessible per GOV.RR-05
Other relevant management roles are supported to demonstrate AI leadership within their areas
Leadership engagement on AI is evidenced through reviews, communications, and decision-making records
Control Mapping
ISO/IEC 42001:2023 — Cl. 5.1(f, g, h); Cl. 10
NIST AI RMF — GOVERN 2.3; GOVERN 4.1
EU AI Act — Art. 4
NIST AI RMF — GOVERN 2.3; GOVERN 4.1
EU AI Act — Art. 4
GOV.RRAI Roles, Responsibilities, and Authorities6 Controls
Description: AI roles, responsibilities, and authorities — covering the accountable AI executive, AI governance functions, decision rights for AI deployment and expansion, segregation of duties for AI-sensitive activities, reporting of concerns, and role accountability under provider, deployer, and internal-developer contexts — are defined, assigned, and communicated
GOV.RR-01The accountable AI executive role — Chief AI Officer or equivalent — is established with documented mandate, authority, and reporting line to top managementT 7 · C 7 · F 6
Applies To
Accountable AI executive role definition
Documented mandate and authority
Reporting line to top management
Tenure and succession planning
Authority over AI strategy, governance, risk, and compliance
Documented mandate and authority
Reporting line to top management
Tenure and succession planning
Authority over AI strategy, governance, risk, and compliance
Control Details
A senior accountable AI executive is appointed (Chief AI Officer, VP AI, Director of AI Governance, or equivalent) with documented mandate
Mandate explicitly covers AIMS accountability, AI strategic direction, AI risk and compliance oversight, and AI governance forum chair
Reporting line is direct to a member of top management (CEO, COO, or CIO)
Authority includes decision rights for AI deployment, expansion, and decommissioning per GOV.RR-03
Tenure expectations and succession plan are defined
Role description, authority, and accountabilities are formally documented and approved
Mandate explicitly covers AIMS accountability, AI strategic direction, AI risk and compliance oversight, and AI governance forum chair
Reporting line is direct to a member of top management (CEO, COO, or CIO)
Authority includes decision rights for AI deployment, expansion, and decommissioning per GOV.RR-03
Tenure expectations and succession plan are defined
Role description, authority, and accountabilities are formally documented and approved
Control Mapping
ISO/IEC 42001:2023 — Cl. 5.3; A.3.2
NIST AI RMF — GOVERN 2.1; GOVERN 2.3
EU AI Act — Art. 26(1)
ISO/IEC 38507:2022 — Cl. 5
NIST AI RMF — GOVERN 2.1; GOVERN 2.3
EU AI Act — Art. 26(1)
ISO/IEC 38507:2022 — Cl. 5
GOV.RR-02AI governance functions and RACI for AI decisions are documented, communicated, and maintained to clarify accountability across AI development, deployment, oversight, and compliance — including the Data Protection Officer position and interface where designatedT 6 · C 6 · F 6
Applies To
AI governance functions catalogue
RACI matrix for AI decisions per AI activity class
Function descriptions and competence requirements
Data Protection Officer (DPO) function and interface with AI governance per GDPR Art. 38 (where designated per CON.JU-04)
Cross-functional dependencies
Function performance evaluation
RACI matrix for AI decisions per AI activity class
Function descriptions and competence requirements
Data Protection Officer (DPO) function and interface with AI governance per GDPR Art. 38 (where designated per CON.JU-04)
Cross-functional dependencies
Function performance evaluation
Control Details
The AI governance functions catalogue is documented (e.g., AI Policy Owner, AI Risk Owner, AI Ethics Lead, AI Compliance Lead, AI Safety Lead, MLOps Lead, AI Engineering Lead)
Where the company has designated a Data Protection Officer per CON.JU-04 / GDPR Art. 37, the DPO is included in the AI governance functions catalogue with a defined interface to the accountable AI executive per GOV.RR-01 and to AI governance forums per GOV.GF; the DPO position is supported per Art. 38 — involvement in a timely manner in all AI matters touching personal data (Art. 38(1)), resources provided (Art. 38(2)), independence in performing tasks with no instructions on task execution (Art. 38(3)), no dismissal or penalty for performing tasks (Art. 38(3)), reporting to highest management level (Art. 38(3)), accessible contact point for data subjects (Art. 38(4)), and bound by secrecy or confidentiality concerning tasks (Art. 38(5))
A RACI matrix is established for key AI decisions per AI activity class (AI development, AI deployment, AI procurement, AI risk decisions, AI incident response); the DPO is named in the RACI for AI decisions involving personal data processing
Function descriptions specify responsibilities, required competencies per GOV.CO, and performance expectations
Cross-functional dependencies between AI governance, InfoSec, privacy, legal, and engineering are documented
Function performance is evaluated against defined performance expectations per GOV.OV
Function structure is reviewed when AI scope materially changes
Where the company has designated a Data Protection Officer per CON.JU-04 / GDPR Art. 37, the DPO is included in the AI governance functions catalogue with a defined interface to the accountable AI executive per GOV.RR-01 and to AI governance forums per GOV.GF; the DPO position is supported per Art. 38 — involvement in a timely manner in all AI matters touching personal data (Art. 38(1)), resources provided (Art. 38(2)), independence in performing tasks with no instructions on task execution (Art. 38(3)), no dismissal or penalty for performing tasks (Art. 38(3)), reporting to highest management level (Art. 38(3)), accessible contact point for data subjects (Art. 38(4)), and bound by secrecy or confidentiality concerning tasks (Art. 38(5))
A RACI matrix is established for key AI decisions per AI activity class (AI development, AI deployment, AI procurement, AI risk decisions, AI incident response); the DPO is named in the RACI for AI decisions involving personal data processing
Function descriptions specify responsibilities, required competencies per GOV.CO, and performance expectations
Cross-functional dependencies between AI governance, InfoSec, privacy, legal, and engineering are documented
Function performance is evaluated against defined performance expectations per GOV.OV
Function structure is reviewed when AI scope materially changes
Control Mapping
ISO/IEC 42001:2023 — Cl. 5.3; A.3.2
NIST AI RMF — GOVERN 2.1; GOVERN 3.2
EU AI Act — Art. 26(1)
GDPR — Art. 37; Art. 38
RAII Best Practices for AI Governance Structures
NIST AI RMF — GOVERN 2.1; GOVERN 3.2
EU AI Act — Art. 26(1)
GDPR — Art. 37; Art. 38
RAII Best Practices for AI Governance Structures
GOV.RR-03Decision rights for AI deployment, expansion, and decommissioning are documented, with defined authority, escalation criteria, and decision recordsT 6 · C 6 · F 6
Applies To
AI deployment decision authority
AI expansion decision authority (scope, scale, autonomy uplift)
AI decommissioning decision authority
Escalation criteria
Decision records
AI expansion decision authority (scope, scale, autonomy uplift)
AI decommissioning decision authority
Escalation criteria
Decision records
Control Details
Decision rights for new AI deployment are documented, with authority assigned per AI risk class (provider product launch, deployer adoption of new AI, internal AI deployment, agentic system deployment)
Decision rights for material expansion (broader scope, increased autonomy, multi-agent expansion, increased criticality) are documented with appropriate authority
Decision rights for AI decommissioning are documented, recognising operational and customer impact
Escalation criteria define when decisions must reach AI governance forums per GOV.GF or top management
Decisions of record are documented with rationale, alternatives considered, and risk acceptance per RSK.TR
Decision records are auditable and accessible to interested parties
Decision rights for material expansion (broader scope, increased autonomy, multi-agent expansion, increased criticality) are documented with appropriate authority
Decision rights for AI decommissioning are documented, recognising operational and customer impact
Escalation criteria define when decisions must reach AI governance forums per GOV.GF or top management
Decisions of record are documented with rationale, alternatives considered, and risk acceptance per RSK.TR
Decision records are auditable and accessible to interested parties
Control Mapping
ISO/IEC 42001:2023 — Cl. 5.3; A.3.2
NIST AI RMF — GOVERN 2.1; GOVERN 2.3
EU AI Act — Art. 26
ISO/IEC 38507:2022 — Cl. 5.3
NIST AI RMF — GOVERN 2.1; GOVERN 2.3
EU AI Act — Art. 26
ISO/IEC 38507:2022 — Cl. 5.3
GOV.RR-04Segregation of duties for AI-sensitive activities is established to reduce conflict-of-interest, unauthorised action, and risk of error across AI lifecycle decisionsT 7 · C 7 · F 6
Applies To
AI development and AI assurance functions
AI deployment and AI evaluation functions
AI risk assessment and AI risk acceptance
AI ethics review and AI development
AI internal audit and AI development
Independent review per GOV.GF-04
AI deployment and AI evaluation functions
AI risk assessment and AI risk acceptance
AI ethics review and AI development
AI internal audit and AI development
Independent review per GOV.GF-04
Control Details
AI development and AI assurance / evaluation are structurally separated to avoid conflict of interest
AI deployment decisions are separated from AI evaluation responsibilities where practical
AI risk assessment is performed independently of AI risk acceptance authority
AI ethics review is structurally separated from AI development reporting lines
AI internal audit per GOV.OV-03 is independent of AI development and deployment functions
Independent review per GOV.GF-04 maintains structural separation per RAII guidance
Conflicts of interest are declared and managed per defined process
AI deployment decisions are separated from AI evaluation responsibilities where practical
AI risk assessment is performed independently of AI risk acceptance authority
AI ethics review is structurally separated from AI development reporting lines
AI internal audit per GOV.OV-03 is independent of AI development and deployment functions
Independent review per GOV.GF-04 maintains structural separation per RAII guidance
Conflicts of interest are declared and managed per defined process
Control Mapping
ISO/IEC 42001:2023 — A.3.2
NIST AI RMF — GOVERN 2.1; GOVERN 3.2
ISO/IEC 38507:2022 — Cl. 5.5
NIST AI RMF — GOVERN 2.1; GOVERN 3.2
ISO/IEC 38507:2022 — Cl. 5.5
GOV.RR-05Reporting of AI concerns is established with confidential channels, protections for reporters, and defined escalation pathways across the AI governance hierarchyT 7 · C 7 · F 6
Applies To
Confidential reporting channels for AI concerns
Reporter protections (anti-retaliation)
Concern triage and investigation process
Escalation to AI governance forums per GOV.GF
Concern record-keeping
Whistleblowing alignment
Reporter protections (anti-retaliation)
Concern triage and investigation process
Escalation to AI governance forums per GOV.GF
Concern record-keeping
Whistleblowing alignment
Control Details
Confidential channels for raising AI concerns (ethical, safety, compliance, harmful behaviour) are established and accessible to employees, contractors, and external parties
Reporter protections include anti-retaliation, confidentiality, and where applicable anonymous reporting
Concerns are triaged, investigated, and responded to per defined process and timelines
Material concerns are escalated to AI governance forums per GOV.GF or top management per defined escalation criteria
Concern records are maintained for audit and improvement tracking per GOV.OV-07
Reporting alignment with whistleblowing policy is maintained
Concerns and outcomes are reported to top management per GOV.OV-04
Reporter protections include anti-retaliation, confidentiality, and where applicable anonymous reporting
Concerns are triaged, investigated, and responded to per defined process and timelines
Material concerns are escalated to AI governance forums per GOV.GF or top management per defined escalation criteria
Concern records are maintained for audit and improvement tracking per GOV.OV-07
Reporting alignment with whistleblowing policy is maintained
Concerns and outcomes are reported to top management per GOV.OV-04
Control Mapping
ISO/IEC 42001:2023 — A.3.3
NIST AI RMF — GOVERN 4.3
EU AI Act — Art. 26(7); Art. 87
OECD AI Principles (OECD/LEGAL/0449)
NIST AI RMF — GOVERN 4.3
EU AI Act — Art. 26(7); Art. 87
OECD AI Principles (OECD/LEGAL/0449)
GOV.RR-06Provider, deployer, and internal-developer role accountability is assigned, ensuring distinct evidence streams for each EU AI Act role obligation setT 7 · C 7 · F 6
Applies To
Provider role accountable owner (Articles 16-21 obligations)
Deployer role accountable owner (Article 26+ obligations)
Internal-developer accountable owner
Distributor, importer, authorised representative roles where applicable
Role obligation crosswalk
Evidence ownership per role
Deployer role accountable owner (Article 26+ obligations)
Internal-developer accountable owner
Distributor, importer, authorised representative roles where applicable
Role obligation crosswalk
Evidence ownership per role
Control Details
Provider role obligations under the EU AI Act are assigned to a named accountable owner who owns evidence of conformity, technical documentation, instructions for use, and post-market obligations
Deployer role obligations are assigned to a named accountable owner who owns evidence of use per provider instructions, deployer documentation, and monitoring
Internal-developer accountability is assigned to a named accountable owner for in-house AI used internally
Distributor, importer, or authorised representative roles, where applicable, have assigned owners with documented obligations
Role obligation crosswalk maps EU AI Act articles to assigned accountable owners
Cross-role coordination is established where a single AI activity touches multiple roles
Deployer role obligations are assigned to a named accountable owner who owns evidence of use per provider instructions, deployer documentation, and monitoring
Internal-developer accountability is assigned to a named accountable owner for in-house AI used internally
Distributor, importer, or authorised representative roles, where applicable, have assigned owners with documented obligations
Role obligation crosswalk maps EU AI Act articles to assigned accountable owners
Cross-role coordination is established where a single AI activity touches multiple roles
Control Mapping
ISO/IEC 42001:2023 — Cl. 5.3; A.3.2; A.10
NIST AI RMF — GOVERN 2.1; GOVERN 6.1
EU AI Act — Art. 16; Art. 22; Art. 23; Art. 24; Art. 26
ISO/IEC 38507:2022 — Cl. 5
NIST AI RMF — GOVERN 2.1; GOVERN 6.1
EU AI Act — Art. 16; Art. 22; Art. 23; Art. 24; Art. 26
ISO/IEC 38507:2022 — Cl. 5
GOV.GFAI Governance Forums and Independent Review4 Controls
Description: AI governance forums and independent review structures — covering the executive AI committee, operational AI governance committee, AI ethics committee, and an independent review function structurally separated from AI development — are established, operated, and maintained under defined charters and cadence with documented decisions of record
GOV.GF-01An executive AI committee with documented charter, membership, cadence, and decisions of record is established to provide top-management AI oversightT 6 · C 6 · F 6
Applies To
Executive AI committee charter
Membership composition (top management, accountable AI executive, key functions)
Meeting cadence
Decision rights at executive committee level
Decisions of record and minutes
Reporting up to Board
Membership composition (top management, accountable AI executive, key functions)
Meeting cadence
Decision rights at executive committee level
Decisions of record and minutes
Reporting up to Board
Control Details
The executive AI committee is chartered with documented purpose, scope, and authority
Membership includes top management representation, the accountable AI executive per GOV.RR-01, and key functional representatives (CISO, CPO, General Counsel, CTO)
Cadence is defined (at minimum quarterly) with ad-hoc convening on material AI matters
Decision rights at executive committee level are documented per GOV.RR-03
Decisions of record are minuted with rationale and dissent recorded
Committee outputs feed Board reporting per GOV.OV-04
Charter is reviewed annually
Membership includes top management representation, the accountable AI executive per GOV.RR-01, and key functional representatives (CISO, CPO, General Counsel, CTO)
Cadence is defined (at minimum quarterly) with ad-hoc convening on material AI matters
Decision rights at executive committee level are documented per GOV.RR-03
Decisions of record are minuted with rationale and dissent recorded
Committee outputs feed Board reporting per GOV.OV-04
Charter is reviewed annually
Control Mapping
ISO/IEC 42001:2023 — Cl. 5.1; A.3.2
NIST AI RMF — GOVERN 2.1; GOVERN 2.3
EU AI Act — Art. 26(1)
ISO/IEC 38507:2022 — Cl. 5.2
RAII Best Practices for AI Governance Structures
NIST AI RMF — GOVERN 2.1; GOVERN 2.3
EU AI Act — Art. 26(1)
ISO/IEC 38507:2022 — Cl. 5.2
RAII Best Practices for AI Governance Structures
GOV.GF-02An operational AI governance committee — cross-functional, day-to-day AI governance — is established with documented charter, membership, cadence, and decisions of recordT 7 · C 7 · F 6
Applies To
Operational AI governance committee charter
Membership (mid-level leaders from AI engineering, AI safety, AI ethics, MLOps, Legal, Privacy, InfoSec, Procurement)
Meeting cadence
Operational decision rights
Decisions of record
Escalation to executive AI committee
Membership (mid-level leaders from AI engineering, AI safety, AI ethics, MLOps, Legal, Privacy, InfoSec, Procurement)
Meeting cadence
Operational decision rights
Decisions of record
Escalation to executive AI committee
Control Details
The operational AI governance committee is chartered with documented scope covering day-to-day AI governance
Membership includes mid-level leaders across AI engineering, MLOps, AI safety, AI ethics, Legal, Privacy, InfoSec, and Procurement
Cadence is defined (at minimum monthly) with ad-hoc convening on material operational matters
Operational decision rights are documented (AI deployment review, vendor approval, AI use case review, AI risk treatment review)
Decisions of record are minuted with rationale
Material items are escalated to the executive AI committee per GOV.GF-01 per defined criteria
Committee performance is reviewed annually
Membership includes mid-level leaders across AI engineering, MLOps, AI safety, AI ethics, Legal, Privacy, InfoSec, and Procurement
Cadence is defined (at minimum monthly) with ad-hoc convening on material operational matters
Operational decision rights are documented (AI deployment review, vendor approval, AI use case review, AI risk treatment review)
Decisions of record are minuted with rationale
Material items are escalated to the executive AI committee per GOV.GF-01 per defined criteria
Committee performance is reviewed annually
Control Mapping
ISO/IEC 42001:2023 — A.3.2
NIST AI RMF — GOVERN 2.1; GOVERN 4.1
EU AI Act — Art. 26(1)
ISO/IEC 38507:2022 — Cl. 5
RAII Best Practices for AI Governance Structures
NIST AI RMF — GOVERN 2.1; GOVERN 4.1
EU AI Act — Art. 26(1)
ISO/IEC 38507:2022 — Cl. 5
RAII Best Practices for AI Governance Structures
GOV.GF-03An AI ethics committee — dedicated ethical review of AI decisions — is established with documented charter, independent membership criteria, and decisions of recordT 6 · C 6 · F 6
Applies To
AI ethics committee charter
Independent membership criteria (including non-AI-development perspectives)
Ethics review triggers
Ethical review process
Decisions of record
Escalation of ethical concerns
Independent membership criteria (including non-AI-development perspectives)
Ethics review triggers
Ethical review process
Decisions of record
Escalation of ethical concerns
Control Details
The AI ethics committee is chartered with documented scope of ethical review (use case review, foundation model deployment review, contested AI decisions)
Membership includes representatives outside the AI development reporting line per GOV.RR-04 (Ethics function, Privacy, external advisor where used)
Ethics review triggers are defined (new sensitive use case, public-facing AI, biometric or profiling AI, deployment in high-impact domains)
Ethical review process is documented (submission, deliberation, findings, decision)
Decisions of record are minuted, with rationale and dissent recorded
Material ethical concerns are escalated to the executive AI committee or top management per GOV.RR-05
Committee performance is reviewed annually
Membership includes representatives outside the AI development reporting line per GOV.RR-04 (Ethics function, Privacy, external advisor where used)
Ethics review triggers are defined (new sensitive use case, public-facing AI, biometric or profiling AI, deployment in high-impact domains)
Ethical review process is documented (submission, deliberation, findings, decision)
Decisions of record are minuted, with rationale and dissent recorded
Material ethical concerns are escalated to the executive AI committee or top management per GOV.RR-05
Committee performance is reviewed annually
Control Mapping
ISO/IEC 42001:2023 — A.3.2
NIST AI RMF — GOVERN 1.2; GOVERN 4.1
OECD AI Principles (OECD/LEGAL/0449)
ISO/IEC 38507:2022 — Cl. 5.5
RAII Best Practices for AI Governance Structures
NIST AI RMF — GOVERN 1.2; GOVERN 4.1
OECD AI Principles (OECD/LEGAL/0449)
ISO/IEC 38507:2022 — Cl. 5.5
RAII Best Practices for AI Governance Structures
GOV.GF-04An independent review function — structurally separated from AI development — is established with documented charter, independence criteria, scope, and findings escalationT 7 · C 7 · F 6
Applies To
Independent review function definition
Structural independence from AI development reporting lines
Review scope (impact assessments per IMP.IR, ethical reviews, conformity reviews)
Findings documentation
Escalation pathway
Action tracking
Structural independence from AI development reporting lines
Review scope (impact assessments per IMP.IR, ethical reviews, conformity reviews)
Findings documentation
Escalation pathway
Action tracking
Control Details
The independent review function is documented with charter and authority
Structural separation from AI development reporting lines is maintained per RAII guidance
Independence criteria include reporting line separation, no operational AI responsibilities, defined review scope, conflict-of-interest declarations
Review scope covers AI impact assessments per IMP.IR, ethical reviews requiring independence, and conformity reviews
Findings are documented with severity, recommendation, and target outcome
Findings are escalated through AI governance forums per defined criteria
Action tracking ensures findings are addressed; closure is verified
Structural separation from AI development reporting lines is maintained per RAII guidance
Independence criteria include reporting line separation, no operational AI responsibilities, defined review scope, conflict-of-interest declarations
Review scope covers AI impact assessments per IMP.IR, ethical reviews requiring independence, and conformity reviews
Findings are documented with severity, recommendation, and target outcome
Findings are escalated through AI governance forums per defined criteria
Action tracking ensures findings are addressed; closure is verified
Control Mapping
ISO/IEC 42001:2023 — A.3.2; Cl. 9.2
NIST AI RMF — MEASURE 1.3; GOVERN 4.1
OECD Due Diligence Guidance for Responsible AI
ISO/IEC 38507:2022 — Cl. 5.5
RAII Operationalizing Independent Review in AI Governance
NIST AI RMF — MEASURE 1.3; GOVERN 4.1
OECD Due Diligence Guidance for Responsible AI
ISO/IEC 38507:2022 — Cl. 5.5
RAII Operationalizing Independent Review in AI Governance
GOV.ETAI Ethics Commitments4 Controls
Description: AI ethics commitments — covering organisational AI ethics principles, code of AI conduct, ethical sourcing of AI components, ethical decision support, and escalation of ethical concerns — are documented, communicated, and maintained
GOV.ET-01AI ethics principles adopted by the organisation — covering responsible AI, fairness, transparency, accountability, privacy, safety, and human-centric AI — are documented, communicated, and appliedT 6 · C 6 · F 6
Applies To
Adopted AI ethics principles
Principle definitions and interpretation guidance
Application across AI activities
Principle prioritisation and conflict resolution
Communication to interested parties
Principle definitions and interpretation guidance
Application across AI activities
Principle prioritisation and conflict resolution
Communication to interested parties
Control Details
The organisation's adopted AI ethics principles are documented in a formal principles statement, approved at top management or Board level
Principles align with OECD AI Principles (OECD/LEGAL/0449), CoE Framework Convention on AI, and ISO 42001 Annex A.2 expectations
Each principle has interpretation guidance addressing how it applies to provider, deployer, and internal-developer activities
Principle prioritisation guidance is provided where principles tension (e.g., explainability vs accuracy)
Principles are communicated externally where contractually or reputationally relevant
Principles are reviewed when material ethical context changes (new regulatory developments, evolving societal expectations)
Principles align with OECD AI Principles (OECD/LEGAL/0449), CoE Framework Convention on AI, and ISO 42001 Annex A.2 expectations
Each principle has interpretation guidance addressing how it applies to provider, deployer, and internal-developer activities
Principle prioritisation guidance is provided where principles tension (e.g., explainability vs accuracy)
Principles are communicated externally where contractually or reputationally relevant
Principles are reviewed when material ethical context changes (new regulatory developments, evolving societal expectations)
Control Mapping
ISO/IEC 42001:2023 — A.2.2; A.6.1.2
NIST AI RMF — GOVERN 1.2; GOVERN 3.1
OECD AI Principles (OECD/LEGAL/0449)
Council of Europe Framework Convention on AI (2024)
ISO/IEC 38507:2022 — Cl. 5.4
NIST AI RMF — GOVERN 1.2; GOVERN 3.1
OECD AI Principles (OECD/LEGAL/0449)
Council of Europe Framework Convention on AI (2024)
ISO/IEC 38507:2022 — Cl. 5.4
GOV.ET-02A code of AI conduct — translating ethics principles into actionable conduct expectations for personnel — is documented, communicated, and enforcedT 6 · C 6 · F 6
Applies To
Code of AI conduct document
Personnel covered (employees, contractors, third-party personnel with AI roles)
Specific conduct expectations (acceptable use, prohibited use, escalation duties)
Acknowledgement and confirmation
Enforcement mechanism
Personnel covered (employees, contractors, third-party personnel with AI roles)
Specific conduct expectations (acceptable use, prohibited use, escalation duties)
Acknowledgement and confirmation
Enforcement mechanism
Control Details
The code of AI conduct is documented, translating GOV.ET-01 principles into specific behavioural expectations
The code covers employees, contractors, and third-party personnel with AI-related responsibilities
Specific expectations are articulated (acceptable AI use, prohibited use, duty to raise concerns per GOV.RR-05, duty to declare ethical conflicts)
Personnel acknowledge the code through onboarding and at defined renewal cadence
Enforcement mechanism is aligned with broader workforce conduct policy
Breaches are addressed per defined consequences and learning
The code is reviewed when principles per GOV.ET-01 are updated
The code covers employees, contractors, and third-party personnel with AI-related responsibilities
Specific expectations are articulated (acceptable AI use, prohibited use, duty to raise concerns per GOV.RR-05, duty to declare ethical conflicts)
Personnel acknowledge the code through onboarding and at defined renewal cadence
Enforcement mechanism is aligned with broader workforce conduct policy
Breaches are addressed per defined consequences and learning
The code is reviewed when principles per GOV.ET-01 are updated
Control Mapping
ISO/IEC 42001:2023 — A.2.2; A.3.3
NIST AI RMF — GOVERN 1.2; GOVERN 4.1
OECD AI Principles (OECD/LEGAL/0449)
OECD Due Diligence Guidance for Responsible AI
NIST AI RMF — GOVERN 1.2; GOVERN 4.1
OECD AI Principles (OECD/LEGAL/0449)
OECD Due Diligence Guidance for Responsible AI
GOV.ET-03Ethical sourcing of AI components — training data, foundation models, AI tools, AI labour — is established with documented criteria and supplier engagementT 6 · C 6 · F 6
Applies To
Training data ethical sourcing criteria
Foundation model ethical sourcing criteria
AI tooling ethical sourcing criteria
Data labelling and annotation labour ethics (per DAT.LA)
Supplier engagement on ethics
Foundation model ethical sourcing criteria
AI tooling ethical sourcing criteria
Data labelling and annotation labour ethics (per DAT.LA)
Supplier engagement on ethics
Control Details
Ethical sourcing criteria are defined for training data acquisition (legitimate source, consent or alternative lawful basis, copyright respect per GPAI Art. 53, content origin)
Ethical sourcing criteria are defined for foundation model selection (transparency of provider, model card availability, safety posture, training data ethics where available)
AI tooling and platform ethical sourcing criteria address vendor ethics, ESG posture, and supply chain integrity
Data labelling and annotation labour ethics are addressed per DAT.LA-03 (working conditions, wages, exposure to harmful content)
Supplier engagement reinforces ethical sourcing expectations through onboarding and contractual provisions per TPA.CT
Ethical sourcing is reviewed at supplier review cadence
Ethical sourcing criteria are defined for foundation model selection (transparency of provider, model card availability, safety posture, training data ethics where available)
AI tooling and platform ethical sourcing criteria address vendor ethics, ESG posture, and supply chain integrity
Data labelling and annotation labour ethics are addressed per DAT.LA-03 (working conditions, wages, exposure to harmful content)
Supplier engagement reinforces ethical sourcing expectations through onboarding and contractual provisions per TPA.CT
Ethical sourcing is reviewed at supplier review cadence
Control Mapping
ISO/IEC 42001:2023 — A.2.2; A.10
NIST AI RMF — GOVERN 6.1; GOVERN 1.2
EU AI Act — Art. 53
OECD Due Diligence Guidance for Responsible AI
ISO/IEC 38507:2022 — Cl. 5.4
NIST AI RMF — GOVERN 6.1; GOVERN 1.2
EU AI Act — Art. 53
OECD Due Diligence Guidance for Responsible AI
ISO/IEC 38507:2022 — Cl. 5.4
GOV.ET-04Ethical decision support and escalation of ethical concerns are established to guide personnel through ethical AI dilemmas and surface concerns to appropriate forumsT 6 · C 6 · F 6
Applies To
Ethical decision support tools (decision guides, ethics consultation)
Escalation pathway for ethical concerns
Ethics consultation availability
Documentation of ethical decisions
Learning loop from ethical decisions
Escalation pathway for ethical concerns
Ethics consultation availability
Documentation of ethical decisions
Learning loop from ethical decisions
Control Details
Ethical decision support tools (decision frameworks, ethics consultation function, decision guides per use case) are provided to personnel facing ethical AI dilemmas
Escalation pathway for ethical concerns is documented, accessible to all personnel per GOV.RR-05
Ethics consultation is available — via ethics function, AI ethics committee per GOV.GF-03, or independent reviewer per GOV.GF-04
Material ethical decisions are documented with rationale, alternatives considered, and decision authority
Learning from ethical decisions feeds back into principles per GOV.ET-01 and decision support tools
Ethical decision support effectiveness is evaluated at defined cadence
Escalation pathway for ethical concerns is documented, accessible to all personnel per GOV.RR-05
Ethics consultation is available — via ethics function, AI ethics committee per GOV.GF-03, or independent reviewer per GOV.GF-04
Material ethical decisions are documented with rationale, alternatives considered, and decision authority
Learning from ethical decisions feeds back into principles per GOV.ET-01 and decision support tools
Ethical decision support effectiveness is evaluated at defined cadence
Control Mapping
ISO/IEC 42001:2023 — A.2.2; A.3.3
NIST AI RMF — GOVERN 4.1; GOVERN 4.3
OECD AI Principles (OECD/LEGAL/0449)
OECD Due Diligence Guidance for Responsible AI
NIST AI RMF — GOVERN 4.1; GOVERN 4.3
OECD AI Principles (OECD/LEGAL/0449)
OECD Due Diligence Guidance for Responsible AI
GOV.AUAI Acceptable Use3 Controls
Description: AI acceptable use across the workforce — covering acceptable use policy and conduct expectations, technical prevention of shadow AI / unsanctioned consumer AI tool use, and detection and response to shadow AI in operation — is documented, communicated, technically enforced, and continuously monitored
GOV.AU-01AI acceptable use policy — covering personnel scope, sanctioned AI tools, prohibited tools and use cases, data-handling boundaries, consequences for non-compliance, and acknowledgement — is documented, approved, communicated, and maintainedT 6 · C 6 · F 6
Applies To
AI Acceptable Use Policy (AUP) document
Personnel scope (employees, contractors, third-party workers with access to company systems)
Sanctioned AI tools — the allow-list per CON.IN, TPA.AT-02
Prohibited tools and prohibited use cases (regulated data into consumer AI, unsanctioned consumer AI services, prompt content categories)
Data-handling boundaries per data class per DAT.IN-02 (Public / Controlled / Restricted)
Consequences for non-compliance — escalation to HR, disciplinary pathway
Acknowledgement at onboarding and on material policy change
Linkage with ISMS Acceptable Use of Information (ISO/IEC 27001:2022 A.5.10)
Personnel scope (employees, contractors, third-party workers with access to company systems)
Sanctioned AI tools — the allow-list per CON.IN, TPA.AT-02
Prohibited tools and prohibited use cases (regulated data into consumer AI, unsanctioned consumer AI services, prompt content categories)
Data-handling boundaries per data class per DAT.IN-02 (Public / Controlled / Restricted)
Consequences for non-compliance — escalation to HR, disciplinary pathway
Acknowledgement at onboarding and on material policy change
Linkage with ISMS Acceptable Use of Information (ISO/IEC 27001:2022 A.5.10)
Control Details
The AI Acceptable Use Policy is documented as a formal artefact, approved at appropriate authority level per GOV.RR-03
Personnel scope explicitly covers employees, contractors, and third-party workers with access to company systems, data, or AI tools
Sanctioned AI tools are listed by reference to the AI inventory per CON.IN-01 and approved-vendor allow-list per TPA.AT-02; the canonical list is published and kept current
Prohibited tools and use cases are explicitly stated — including: use of unsanctioned consumer AI services (consumer ChatGPT, Claude.ai, Copilot personal, Gemini personal, image generators, etc.); input of Controlled or Restricted data into any non-sanctioned AI; use of AI for Art. 5 EU AI Act prohibited practices per CON.JU-06; use of AI in employment, performance, or grading decisions without sanctioned-AI path and human oversight
Data-handling boundaries are stated per data class per DAT.IN-02 — Public data may be used in sanctioned AI; Controlled requires risk acceptance; Restricted is prohibited outside specifically-approved enclaved environments
Consequences for non-compliance follow the disciplinary pathway in the ISMS / HR framework — graduated response from coaching to formal action; serious or repeated breaches escalate to HR
Acknowledgement is captured at onboarding and on material policy update per GOV.PO-03 communication discipline; tracking via GOV.CO-04 competence records
Sanctioned-alternative provision — the company provides a clear sanctioned path (e.g., enterprise-licensed AI) so personnel have a compliant route rather than only prohibitions
Policy is reviewed at minimum annually and on material change per GOV.PO-04
Personnel scope explicitly covers employees, contractors, and third-party workers with access to company systems, data, or AI tools
Sanctioned AI tools are listed by reference to the AI inventory per CON.IN-01 and approved-vendor allow-list per TPA.AT-02; the canonical list is published and kept current
Prohibited tools and use cases are explicitly stated — including: use of unsanctioned consumer AI services (consumer ChatGPT, Claude.ai, Copilot personal, Gemini personal, image generators, etc.); input of Controlled or Restricted data into any non-sanctioned AI; use of AI for Art. 5 EU AI Act prohibited practices per CON.JU-06; use of AI in employment, performance, or grading decisions without sanctioned-AI path and human oversight
Data-handling boundaries are stated per data class per DAT.IN-02 — Public data may be used in sanctioned AI; Controlled requires risk acceptance; Restricted is prohibited outside specifically-approved enclaved environments
Consequences for non-compliance follow the disciplinary pathway in the ISMS / HR framework — graduated response from coaching to formal action; serious or repeated breaches escalate to HR
Acknowledgement is captured at onboarding and on material policy update per GOV.PO-03 communication discipline; tracking via GOV.CO-04 competence records
Sanctioned-alternative provision — the company provides a clear sanctioned path (e.g., enterprise-licensed AI) so personnel have a compliant route rather than only prohibitions
Policy is reviewed at minimum annually and on material change per GOV.PO-04
Control Mapping
ISO/IEC 42001:2023 — Cl. 5.2; Cl. 7.4; A.2.2; A.4.6; A.9
NIST AI RMF — GOVERN 1.2; GOVERN 2.2; MAP 3.4
EU AI Act — Art. 4; Art. 5; Art. 26
OECD AI Principles (OECD/LEGAL/0449)
GDPR — Art. 5(1)(a); Art. 5(1)(f); Art. 32
ISO/IEC 5338:2023 — Cl. 6.2.4
ISO/IEC 27001:2022 — A.5.10; A.6.3
ISO/IEC 27002:2022 — 5.10; 6.3
NIST AI RMF — GOVERN 1.2; GOVERN 2.2; MAP 3.4
EU AI Act — Art. 4; Art. 5; Art. 26
OECD AI Principles (OECD/LEGAL/0449)
GDPR — Art. 5(1)(a); Art. 5(1)(f); Art. 32
ISO/IEC 5338:2023 — Cl. 6.2.4
ISO/IEC 27001:2022 — A.5.10; A.6.3
ISO/IEC 27002:2022 — 5.10; 6.3
GOV.AU-02Shadow AI prevention — covering technical controls to block unsanctioned AI service access, data leakage prevention to sanctioned and unsanctioned AI, identity-controlled SaaS access, and provision of sanctioned alternatives — are established and maintainedT 7 · C 6 · F 6
Applies To
Web / DNS filtering blocking access to unsanctioned consumer AI services
Browser-level controls (managed browser, browser extensions)
Data Loss Prevention (DLP) covering AI-bound traffic
SaaS access controls via identity provider (SSO / SCIM)
API key / credential controls for AI APIs
Sanctioned-alternative provision (enterprise-licensed AI made available to personnel)
Linkage with ISMS DLP per ISO/IEC 27001:2022 A.8.12 and Access Control per A.5.15
Browser-level controls (managed browser, browser extensions)
Data Loss Prevention (DLP) covering AI-bound traffic
SaaS access controls via identity provider (SSO / SCIM)
API key / credential controls for AI APIs
Sanctioned-alternative provision (enterprise-licensed AI made available to personnel)
Linkage with ISMS DLP per ISO/IEC 27001:2022 A.8.12 and Access Control per A.5.15
Control Details
Web and DNS filtering blocks access to a maintained block-list of unsanctioned consumer AI services (consumer ChatGPT, Claude.ai, Copilot personal, Gemini personal, character-AI sites, image / video generators, etc.); the block-list is reviewed at defined cadence as new services emerge
Browser-level controls (managed browser policy, approved extensions only) prevent installation of unsanctioned AI plugins, copilots, and browser-injection AI tools
Data Loss Prevention (DLP) inspects outbound traffic to AI services (sanctioned and unsanctioned) and blocks transmission of Controlled or Restricted data per DAT.IN-02 classification; DLP rules are tuned to detect AI-bound traffic patterns (large prompts, structured-data payloads, file uploads)
SaaS access controls via identity provider (SSO / SCIM) ensure sanctioned AI services are accessible only through company identity; non-SSO use of sanctioned services is blocked at network layer
API key and credential controls require AI API keys to be provisioned through the company's secrets-management system; personal API keys for company work are prohibited
Sanctioned-alternative provision ensures personnel have a clear compliant path — enterprise-licensed AI tools per CON.IN-01 are made available, discoverable, and supported so the path of least resistance is the sanctioned path
Controls are tested at defined cadence (annual minimum) and on material change to AI service landscape
Linkage with ISMS DLP per ISO/IEC 27001:2022 A.8.12, Access Control per A.5.15, and Network Security per A.8.20 leverages existing infrastructure rather than duplicating it
Browser-level controls (managed browser policy, approved extensions only) prevent installation of unsanctioned AI plugins, copilots, and browser-injection AI tools
Data Loss Prevention (DLP) inspects outbound traffic to AI services (sanctioned and unsanctioned) and blocks transmission of Controlled or Restricted data per DAT.IN-02 classification; DLP rules are tuned to detect AI-bound traffic patterns (large prompts, structured-data payloads, file uploads)
SaaS access controls via identity provider (SSO / SCIM) ensure sanctioned AI services are accessible only through company identity; non-SSO use of sanctioned services is blocked at network layer
API key and credential controls require AI API keys to be provisioned through the company's secrets-management system; personal API keys for company work are prohibited
Sanctioned-alternative provision ensures personnel have a clear compliant path — enterprise-licensed AI tools per CON.IN-01 are made available, discoverable, and supported so the path of least resistance is the sanctioned path
Controls are tested at defined cadence (annual minimum) and on material change to AI service landscape
Linkage with ISMS DLP per ISO/IEC 27001:2022 A.8.12, Access Control per A.5.15, and Network Security per A.8.20 leverages existing infrastructure rather than duplicating it
Control Mapping
ISO/IEC 42001:2023 — A.4; A.9; A.9.4
NIST AI RMF — GOVERN 1.2; MANAGE 2.4
EU AI Act — Art. 5; Art. 26
GDPR — Art. 5(1)(f); Art. 32
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Operation and Maintenance
ISO/IEC 5338:2023 — Cl. 6.2.2
ISO/IEC 27001:2022 — A.5.15; A.8.3; A.8.12; A.8.20; A.8.23
ISO/IEC 27002:2022 — 5.15; 8.3; 8.12; 8.20; 8.23
OWASP AISVS — C5 (Access Control and Identity); C12 (Privacy)
NIST AI RMF — GOVERN 1.2; MANAGE 2.4
EU AI Act — Art. 5; Art. 26
GDPR — Art. 5(1)(f); Art. 32
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Operation and Maintenance
ISO/IEC 5338:2023 — Cl. 6.2.2
ISO/IEC 27001:2022 — A.5.15; A.8.3; A.8.12; A.8.20; A.8.23
ISO/IEC 27002:2022 — 5.15; 8.3; 8.12; 8.20; 8.23
OWASP AISVS — C5 (Access Control and Identity); C12 (Privacy)
GOV.AU-03Shadow AI detection and response — covering discovery channels, adjudication, response actions, trend reporting, and incident escalation — are established and operationalisedT 7 · C 7 · F 6
Applies To
Discovery channels — Cloud Access Security Broker (CASB), proxy / DNS logs, browser inventory, SaaS discovery, expense and reimbursement records, self-report channels
Adjudication process (triage, severity classification, root-cause determination)
Response actions (containment, education, escalation, sanctioned-alternative onboarding)
Trend reporting to AI governance forums per GOV.GF and AIMS KPI / KRI per GOV.OV-01
Incident escalation per LIF.IR where shadow AI use caused or risks causing AI incident or data breach
Linkage with HR per disciplinary pathway and with GOV.RR-05 reporting of AI concerns
Adjudication process (triage, severity classification, root-cause determination)
Response actions (containment, education, escalation, sanctioned-alternative onboarding)
Trend reporting to AI governance forums per GOV.GF and AIMS KPI / KRI per GOV.OV-01
Incident escalation per LIF.IR where shadow AI use caused or risks causing AI incident or data breach
Linkage with HR per disciplinary pathway and with GOV.RR-05 reporting of AI concerns
Control Details
Discovery channels operate continuously to identify shadow AI use — Cloud Access Security Broker (CASB) flags AI-service traffic; proxy and DNS logs are reviewed for AI-service patterns; managed browser inventory surfaces unsanctioned AI extensions; SaaS discovery tools identify unmanaged AI subscriptions; expense and reimbursement records are reviewed for AI-service charges; self-report channels per GOV.RR-05 enable personnel to disclose shadow AI use without immediate penalty
Adjudication process triages each detection — severity classification considers data sensitivity exposed per DAT.IN-02, duration and frequency of use, intent (curiosity vs. policy circumvention), and whether sanctioned alternative was available
Response actions are graduated — first-time low-severity: education and sanctioned-alternative onboarding; repeat or higher-severity: formal warning, sanctioned-alternative requirement, HR involvement; serious cases (Restricted data exposure, ongoing policy violation): incident response per LIF.IR-02 and disciplinary escalation
Trend reporting captures aggregated detection volume, top services detected, top data classes exposed, and remediation outcomes; feeds AI governance forums per GOV.GF and AIMS KPI / KRI per GOV.OV-01
Incident escalation per LIF.IR is triggered when shadow AI use caused or risks causing AI incident, data breach (GDPR Art. 33 trigger), or material AI risk; coordinates with LIF.IR-05 corrective actions where applicable
Linkage with GOV.RR-05 reporting of AI concerns ensures self-reporting is treated as a positive signal (lower disciplinary response) to encourage disclosure over concealment
Detection methodology is reviewed at defined cadence and on material change to AI service landscape; new discovery channels are added as the ecosystem evolves
Adjudication process triages each detection — severity classification considers data sensitivity exposed per DAT.IN-02, duration and frequency of use, intent (curiosity vs. policy circumvention), and whether sanctioned alternative was available
Response actions are graduated — first-time low-severity: education and sanctioned-alternative onboarding; repeat or higher-severity: formal warning, sanctioned-alternative requirement, HR involvement; serious cases (Restricted data exposure, ongoing policy violation): incident response per LIF.IR-02 and disciplinary escalation
Trend reporting captures aggregated detection volume, top services detected, top data classes exposed, and remediation outcomes; feeds AI governance forums per GOV.GF and AIMS KPI / KRI per GOV.OV-01
Incident escalation per LIF.IR is triggered when shadow AI use caused or risks causing AI incident, data breach (GDPR Art. 33 trigger), or material AI risk; coordinates with LIF.IR-05 corrective actions where applicable
Linkage with GOV.RR-05 reporting of AI concerns ensures self-reporting is treated as a positive signal (lower disciplinary response) to encourage disclosure over concealment
Detection methodology is reviewed at defined cadence and on material change to AI service landscape; new discovery channels are added as the ecosystem evolves
Control Mapping
ISO/IEC 42001:2023 — Cl. 9.1; A.6.2.6; A.9
NIST AI RMF — MEASURE 2.7; MEASURE 3.1; MANAGE 4.1
EU AI Act — Art. 26(5); Art. 73
GDPR — Art. 5(1)(f); Art. 32; Art. 33
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Operation and Maintenance
ISO/IEC 5338:2023 — Cl. 6.4.15
ISO/IEC 27001:2022 — A.5.7; A.5.24; A.8.16; A.8.23
ISO/IEC 27002:2022 — 5.7; 5.24; 8.16; 8.23
OWASP AISVS — C13 (Monitoring and Logging)
NIST AI RMF — MEASURE 2.7; MEASURE 3.1; MANAGE 4.1
EU AI Act — Art. 26(5); Art. 73
GDPR — Art. 5(1)(f); Art. 32; Art. 33
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Operation and Maintenance
ISO/IEC 5338:2023 — Cl. 6.4.15
ISO/IEC 27001:2022 — A.5.7; A.5.24; A.8.16; A.8.23
ISO/IEC 27002:2022 — 5.7; 5.24; 8.16; 8.23
OWASP AISVS — C13 (Monitoring and Logging)
GOV.RAAI Risk Appetite and Tolerance4 Controls
Description: AI risk appetite and tolerance — covering risk appetite per AI role (provider, deployer, internal developer) and per risk class (functional, legal, ethical, societal, commercial), tolerance thresholds, communication, application to AI deployment and expansion decisions, and periodic review — is defined, communicated, and applied
GOV.RA-01AI risk appetite statement and tolerance thresholds per AI role and risk class are defined, approved at Board or top management level, and used to anchor AI decisionsT 7 · C 7 · F 6
Applies To
AI risk appetite statement
Tolerance thresholds per AI risk class (functional, legal, ethical, societal, commercial)
Tolerance differentiation per AI role (provider, deployer, internal developer)
Approval authority
Documentation
Tolerance thresholds per AI risk class (functional, legal, ethical, societal, commercial)
Tolerance differentiation per AI role (provider, deployer, internal developer)
Approval authority
Documentation
Control Details
The AI risk appetite statement is documented, defining the overall organisational stance toward AI risk (e.g., conservative, balanced, ambitious)
Tolerance thresholds are defined per AI risk class — functional risk, legal/regulatory risk, ethical risk, societal/reputational risk, commercial/financial risk
Tolerance differentiation per AI role reflects different risk profiles for provider activities (product liability), deployer activities (operational), and internal-developer activities (institutional)
The appetite statement is approved at Board or top management level
Appetite documentation is maintained with version control and approval evidence
Appetite is integrated with overall enterprise risk appetite where defined
Tolerance thresholds are defined per AI risk class — functional risk, legal/regulatory risk, ethical risk, societal/reputational risk, commercial/financial risk
Tolerance differentiation per AI role reflects different risk profiles for provider activities (product liability), deployer activities (operational), and internal-developer activities (institutional)
The appetite statement is approved at Board or top management level
Appetite documentation is maintained with version control and approval evidence
Appetite is integrated with overall enterprise risk appetite where defined
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.1
NIST AI RMF — MAP 1.5; GOVERN 1.4
EU AI Act — Art. 17(2)(b)
ISO/IEC 38507:2022 — Cl. 5.3
NIST AI RMF — MAP 1.5; GOVERN 1.4
EU AI Act — Art. 17(2)(b)
ISO/IEC 38507:2022 — Cl. 5.3
GOV.RA-02AI risk appetite is communicated across the organisation through defined channels, ensuring AI decision-makers understand and apply the appetiteT 6 · C 6 · F 6
Applies To
Communication channels (intranet, training, onboarding)
Target audiences (AI governance forums, AI engineering, AI risk owners, decision-makers)
Communication cadence (initial and on update)
Confirmation of understanding
External communication where applicable
Target audiences (AI governance forums, AI engineering, AI risk owners, decision-makers)
Communication cadence (initial and on update)
Confirmation of understanding
External communication where applicable
Control Details
The AI risk appetite is communicated to all AI decision-makers through onboarding, training, and standing reference material
Target audiences include AI governance forums per GOV.GF, AI engineering, AI risk owners, AI deployment approvers, and ethics personnel
Communication occurs on initial appetite definition, on material update, and at defined cadence (at minimum annually)
Confirmation of understanding is recorded for key decision-makers
External communication of appetite occurs where contractually, regulatorily, or strategically relevant
Target audiences include AI governance forums per GOV.GF, AI engineering, AI risk owners, AI deployment approvers, and ethics personnel
Communication occurs on initial appetite definition, on material update, and at defined cadence (at minimum annually)
Confirmation of understanding is recorded for key decision-makers
External communication of appetite occurs where contractually, regulatorily, or strategically relevant
Control Mapping
ISO/IEC 42001:2023 — Cl. 7.4
NIST AI RMF — MAP 1.5; GOVERN 2.2
EU AI Act — Art. 4
NIST AI RMF — MAP 1.5; GOVERN 2.2
EU AI Act — Art. 4
GOV.RA-03AI risk appetite is applied to AI deployment, expansion, and acceptance decisions, with documented evidence of appetite considerationT 6 · C 6 · F 6
Applies To
AI deployment decisions (per GOV.RR-03)
AI expansion decisions (scope, scale, autonomy uplift)
AI risk acceptance decisions per RSK.TR
Application evidence per decision
Appetite breach handling
AI expansion decisions (scope, scale, autonomy uplift)
AI risk acceptance decisions per RSK.TR
Application evidence per decision
Appetite breach handling
Control Details
AI deployment decisions evaluate inherent and residual risk against the appropriate tolerance threshold; decisions outside appetite require explicit override authority per RSK.TR-02
AI expansion decisions (broader scope, increased autonomy, multi-agent expansion) reassess risk against appetite
AI risk acceptance decisions per RSK.TR-02 cite the relevant tolerance threshold and rationale
Application evidence is documented per decision (appetite reference, risk score, decision rationale)
Appetite breach handling includes escalation per GOV.RR-03 and remediation tracking
Appetite-related decisions feed into AI governance forum reporting per GOV.GF
AI expansion decisions (broader scope, increased autonomy, multi-agent expansion) reassess risk against appetite
AI risk acceptance decisions per RSK.TR-02 cite the relevant tolerance threshold and rationale
Application evidence is documented per decision (appetite reference, risk score, decision rationale)
Appetite breach handling includes escalation per GOV.RR-03 and remediation tracking
Appetite-related decisions feed into AI governance forum reporting per GOV.GF
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.1; Cl. 8
NIST AI RMF — MAP 1.5; MANAGE 1.2
EU AI Act — Art. 9
ISO 31000:2018 — Cl. 6
NIST AI RMF — MAP 1.5; MANAGE 1.2
EU AI Act — Art. 9
ISO 31000:2018 — Cl. 6
GOV.RA-04Periodic review of AI risk appetite is performed at defined cadence and on material change, with adjustments approved at appropriate authorityT 6 · C 6 · F 6
Applies To
Review schedule (at minimum annually)
Material change triggers (regulatory change, incident, strategic shift, technological shift)
Review participants
Review process
Adjustment approval and communication
Material change triggers (regulatory change, incident, strategic shift, technological shift)
Review participants
Review process
Adjustment approval and communication
Control Details
AI risk appetite is reviewed at minimum annually; ad-hoc review is triggered by material regulatory change, material AI incident, material strategic shift, or material technological shift (e.g., new foundation model capabilities, agentic developments)
Review participants include the executive AI committee per GOV.GF-01, AI risk owner, and key functional leaders
Review process evaluates whether current appetite remains appropriate given experience, environment, and strategy
Adjustments are approved at Board or top management level per GOV.RA-01
Adjusted appetite is communicated per GOV.RA-02 and applied per GOV.RA-03
Review outcomes are documented and reported in AIMS performance evaluation per GOV.OV
Review participants include the executive AI committee per GOV.GF-01, AI risk owner, and key functional leaders
Review process evaluates whether current appetite remains appropriate given experience, environment, and strategy
Adjustments are approved at Board or top management level per GOV.RA-01
Adjusted appetite is communicated per GOV.RA-02 and applied per GOV.RA-03
Review outcomes are documented and reported in AIMS performance evaluation per GOV.OV
Control Mapping
ISO/IEC 42001:2023 — Cl. 9.3
NIST AI RMF — GOVERN 1.5; MAP 1.5
EU AI Act — Art. 17(2)
ISO/IEC 38507:2022 — Cl. 5.6
NIST AI RMF — GOVERN 1.5; MAP 1.5
EU AI Act — Art. 17(2)
ISO/IEC 38507:2022 — Cl. 5.6
GOV.OBAI Objectives and Planning3 Controls
Description: AI objectives and planning to achieve them — covering measurable AI objectives at relevant functions and levels, cascade from AI strategy, performance tracking against objectives, and AIMS-level change planning and impact assessment — are established, communicated, and maintained
GOV.OB-01AI objectives — defined at relevant functions and levels, measurable, time-bound, and aligned with AI strategy — are documented, approved, and maintainedT 6 · C 6 · F 6
Applies To
AI objectives document
Functions and levels at which objectives are set (corporate, Domain, function, programme, team)
Measurability (SMART) criteria
Per-objective owner, resources, and timeline
Linkage with AI strategy per GOV.ST and AI policy per GOV.PO
Functions and levels at which objectives are set (corporate, Domain, function, programme, team)
Measurability (SMART) criteria
Per-objective owner, resources, and timeline
Linkage with AI strategy per GOV.ST and AI policy per GOV.PO
Control Details
The AI objectives document is a formal artefact, approved at appropriate authority level per GOV.RR-03
Objectives are defined at relevant functions and levels — at minimum corporate and Domain — with optional cascade to function, programme, or team
Measurability criteria apply SMART expectations (specific, measurable, achievable, relevant, time-bound)
Per-objective owner, resources, and timeline are recorded
Linkage with AI strategy per GOV.ST and AI policy per GOV.PO ensures objectives derive from strategic direction
Objectives are communicated to relevant personnel through defined channels per GOV.DI-02
Objectives are defined at relevant functions and levels — at minimum corporate and Domain — with optional cascade to function, programme, or team
Measurability criteria apply SMART expectations (specific, measurable, achievable, relevant, time-bound)
Per-objective owner, resources, and timeline are recorded
Linkage with AI strategy per GOV.ST and AI policy per GOV.PO ensures objectives derive from strategic direction
Objectives are communicated to relevant personnel through defined channels per GOV.DI-02
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.2; A.2.2
NIST AI RMF — GOVERN 1.3; GOVERN 1.4
EU AI Act — Art. 17(2) (where applicable as part of QMS)
OECD AI Principles (OECD/LEGAL/0449)
ISO/IEC 27001:2022 — Cl. 6.2 (parallel pattern)
NIST AI RMF — GOVERN 1.3; GOVERN 1.4
EU AI Act — Art. 17(2) (where applicable as part of QMS)
OECD AI Principles (OECD/LEGAL/0449)
ISO/IEC 27001:2022 — Cl. 6.2 (parallel pattern)
GOV.OB-02AI objectives cascade, tracking, and performance against objectives — feeding AI governance forums and management review — are operationalisedT 6 · C 6 · F 6
Applies To
Cascade from corporate AI objectives through Domain, function, programme, and team levels
Per-objective KPIs and metric definitions linked to AIMS KPI / KRI per GOV.OV-01
Tracking cadence and reporting channels
Performance against objectives feeding GOV.GF forums and GOV.OV-05 management review
Adjustment of objectives on material change
Per-objective KPIs and metric definitions linked to AIMS KPI / KRI per GOV.OV-01
Tracking cadence and reporting channels
Performance against objectives feeding GOV.GF forums and GOV.OV-05 management review
Adjustment of objectives on material change
Control Details
Cascade flows from corporate AI objectives through Domain, function, programme, and team levels with traceability
Per-objective KPIs and metric definitions are linked to AIMS KPI / KRI per GOV.OV-01 to avoid duplicate measurement schemes
Tracking cadence and reporting channels are documented
Performance against objectives is reported to AI governance forums per GOV.GF and to top management at management review per GOV.OV-05
Adjustment of objectives on material change (strategy change, scope change, regulatory change) is performed with documented rationale and re-approval
Per-objective KPIs and metric definitions are linked to AIMS KPI / KRI per GOV.OV-01 to avoid duplicate measurement schemes
Tracking cadence and reporting channels are documented
Performance against objectives is reported to AI governance forums per GOV.GF and to top management at management review per GOV.OV-05
Adjustment of objectives on material change (strategy change, scope change, regulatory change) is performed with documented rationale and re-approval
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.2; Cl. 9.1; Cl. 9.3
NIST AI RMF — GOVERN 1.4; MEASURE 4.3
OECD AI Principles (OECD/LEGAL/0449)
ISO/IEC 27001:2022 — Cl. 6.2; Cl. 9.1
NIST AI RMF — GOVERN 1.4; MEASURE 4.3
OECD AI Principles (OECD/LEGAL/0449)
ISO/IEC 27001:2022 — Cl. 6.2; Cl. 9.1
GOV.OB-03AIMS-level change planning — covering change identification, impact assessment, approval, implementation, and verification — is establishedT 7 · C 7 · F 6
Applies To
AIMS-level change identification (regulatory, scope, organisational, technological, strategic)
Change impact assessment on AIMS scope, objectives, risk posture, resources, and competence
Change approval authority per GOV.RR-03
Change implementation planning and verification
Linkage with policy and strategy review cycles per GOV.PO-04, GOV.ST-05
Change impact assessment on AIMS scope, objectives, risk posture, resources, and competence
Change approval authority per GOV.RR-03
Change implementation planning and verification
Linkage with policy and strategy review cycles per GOV.PO-04, GOV.ST-05
Control Details
AIMS-level changes are identified through defined triggers (regulatory developments, scope changes per CON.SC-03, organisational change, material technological change, strategic change)
Change impact assessment is performed before approval, covering AIMS scope, objectives, risk posture per RSK, resources per GOV.LD-02, and competence implications per GOV.CO
Change approval authority follows decision rights per GOV.RR-03
Change implementation planning includes activities, owners, milestones, and verification criteria
Linkage with policy and strategy review cycles per GOV.PO-04 and GOV.ST-05 maintains coherence; nonconformity per GOV.OV-07 is triggered if changes are not effectively managed
Change impact assessment is performed before approval, covering AIMS scope, objectives, risk posture per RSK, resources per GOV.LD-02, and competence implications per GOV.CO
Change approval authority follows decision rights per GOV.RR-03
Change implementation planning includes activities, owners, milestones, and verification criteria
Linkage with policy and strategy review cycles per GOV.PO-04 and GOV.ST-05 maintains coherence; nonconformity per GOV.OV-07 is triggered if changes are not effectively managed
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.3; Cl. 9.3; Cl. 10
NIST AI RMF — GOVERN 1.5; GOVERN 1.7
EU AI Act — Art. 11(3); Art. 17 (where applicable as part of QMS)
ISO/IEC 27001:2022 — Cl. 6.3
NIST AI RMF — GOVERN 1.5; GOVERN 1.7
EU AI Act — Art. 11(3); Art. 17 (where applicable as part of QMS)
ISO/IEC 27001:2022 — Cl. 6.3
GOV.COAI Competence and Literacy4 Controls
Description: AI competence and literacy — covering competence requirements per AI-relevant role, AI literacy across the workforce, AI training programmes, awareness of AI policy and ethics commitments, and records of competence — are established, maintained, and evaluated
GOV.CO-01AI competence requirements per AI-relevant role are defined, with role-specific competency profiles covering technical, ethical, and regulatory dimensionsT 6 · C 6 · F 6
Applies To
AI competence framework
Role-specific competency profiles
Competence dimensions (technical AI/ML, AI safety, AI ethics, AI regulation, AI risk)
Competence requirements per AI role (governance, engineering, MLOps, oversight, ethics)
Competence framework review
Role-specific competency profiles
Competence dimensions (technical AI/ML, AI safety, AI ethics, AI regulation, AI risk)
Competence requirements per AI role (governance, engineering, MLOps, oversight, ethics)
Competence framework review
Control Details
The AI competence framework is documented, defining competence dimensions and proficiency levels per AI-relevant role
Role-specific competency profiles cover AI governance roles, AI engineering, MLOps, AI oversight per HUM.CM, AI ethics, AI risk per RSK
Technical, ethical, and regulatory dimensions are covered per role as appropriate
Competence requirements distinguish foundational (all personnel with AI exposure) and specialised (deep AI roles)
Framework is reviewed at defined cadence and updated when AI roles or scope materially change
Competence framework alignment with EU AI Act Art. 4 AI literacy requirements is maintained
Role-specific competency profiles cover AI governance roles, AI engineering, MLOps, AI oversight per HUM.CM, AI ethics, AI risk per RSK
Technical, ethical, and regulatory dimensions are covered per role as appropriate
Competence requirements distinguish foundational (all personnel with AI exposure) and specialised (deep AI roles)
Framework is reviewed at defined cadence and updated when AI roles or scope materially change
Competence framework alignment with EU AI Act Art. 4 AI literacy requirements is maintained
Control Mapping
ISO/IEC 42001:2023 — Cl. 7.2; A.4.6
NIST AI RMF — GOVERN 2.2; GOVERN 3.2
EU AI Act — Art. 4
ISO/IEC 5338:2023 — Cl. 6.2.4
ISO/IEC 38507:2022 — Cl. 5
NIST AI RMF — GOVERN 2.2; GOVERN 3.2
EU AI Act — Art. 4
ISO/IEC 5338:2023 — Cl. 6.2.4
ISO/IEC 38507:2022 — Cl. 5
GOV.CO-02AI literacy across the workforce is established per EU AI Act Article 4, with literacy programmes appropriate to role exposure to AIT 6 · C 6 · F 6
Applies To
AI literacy programme covering the workforce
Role-based literacy modules (executives, mid-management, developers, operations, customer-facing)
Literacy content covering AI capabilities, risks, ethical considerations, and operational implications
Initial and refresher cadence
Completion tracking
Role-based literacy modules (executives, mid-management, developers, operations, customer-facing)
Literacy content covering AI capabilities, risks, ethical considerations, and operational implications
Initial and refresher cadence
Completion tracking
Control Details
AI literacy programmes are provided to all personnel with AI exposure per EU AI Act Art. 4
Role-based literacy modules are designed for executives, mid-management, developers, operations, customer-facing personnel, and oversight personnel per HUM.CM
Content covers AI capabilities and limitations, AI risks (including bias, hallucination, adversarial), ethical considerations per GOV.ET, regulatory obligations, and operational implications
Initial AI literacy occurs at onboarding and at AI role assignment; refresher cadence is defined (at minimum annually)
Completion is tracked and reported as a programme KPI per GOV.OV-01
Effectiveness is evaluated per GOV.CO-04
Role-based literacy modules are designed for executives, mid-management, developers, operations, customer-facing personnel, and oversight personnel per HUM.CM
Content covers AI capabilities and limitations, AI risks (including bias, hallucination, adversarial), ethical considerations per GOV.ET, regulatory obligations, and operational implications
Initial AI literacy occurs at onboarding and at AI role assignment; refresher cadence is defined (at minimum annually)
Completion is tracked and reported as a programme KPI per GOV.OV-01
Effectiveness is evaluated per GOV.CO-04
Control Mapping
ISO/IEC 42001:2023 — Cl. 7.3; A.4.6
NIST AI RMF — GOVERN 2.2
EU AI Act — Art. 4
OECD AI Principles (OECD/LEGAL/0449)
ISO/IEC 5338:2023 — Cl. 6.2.4
NIST AI RMF — GOVERN 2.2
EU AI Act — Art. 4
OECD AI Principles (OECD/LEGAL/0449)
ISO/IEC 5338:2023 — Cl. 6.2.4
GOV.CO-03AI training and awareness programmes are operated, providing role-specific AI training and ongoing awareness across the workforceT 7 · C 7 · F 6
Applies To
Role-specific training (AI engineering, AI safety, MLOps, AI ethics, AI oversight)
Workforce awareness campaigns
Training catalogue and curriculum
Training delivery channels
Training records
Workforce awareness campaigns
Training catalogue and curriculum
Training delivery channels
Training records
Control Details
Role-specific AI training is provided per GOV.CO-01 competency profiles for governance roles, engineering roles, MLOps, oversight, ethics, and risk personnel
Workforce-wide awareness campaigns reinforce AI policy per GOV.PO, ethics commitments per GOV.ET, and reporting pathways per GOV.RR-05
Training catalogue covers foundational and specialised topics with documented curriculum
Training delivery uses appropriate channels (e-learning, instructor-led, hands-on workshops, simulations)
Training records are maintained per personnel and reported per GOV.OV-01
Workforce-wide awareness campaigns reinforce AI policy per GOV.PO, ethics commitments per GOV.ET, and reporting pathways per GOV.RR-05
Training catalogue covers foundational and specialised topics with documented curriculum
Training delivery uses appropriate channels (e-learning, instructor-led, hands-on workshops, simulations)
Training records are maintained per personnel and reported per GOV.OV-01
Control Mapping
ISO/IEC 42001:2023 — Cl. 7.2; Cl. 7.3
NIST AI RMF — GOVERN 2.2
EU AI Act — Art. 4
ISO/IEC 5338:2023 — Cl. 6.2.4
OWASP AI Exchange
NIST AI RMF — GOVERN 2.2
EU AI Act — Art. 4
ISO/IEC 5338:2023 — Cl. 6.2.4
OWASP AI Exchange
GOV.CO-04AI competence records, assessment, and effectiveness evaluation are maintained, providing evidence of competence and informing programme improvementT 6 · C 6 · F 6
Applies To
Competence records per personnel
Competence assessment methods (training completion, assessment scoring, on-the-job evaluation, certification)
Effectiveness measurement of competence and literacy programmes
Programme adjustment based on effectiveness
Reporting
Competence assessment methods (training completion, assessment scoring, on-the-job evaluation, certification)
Effectiveness measurement of competence and literacy programmes
Programme adjustment based on effectiveness
Reporting
Control Details
Competence records per personnel are maintained, covering completion of relevant training, assessment outcomes, and certifications held
Competence assessment uses appropriate methods per role (knowledge assessment, scenario evaluation, on-the-job demonstration, certification where applicable)
Effectiveness of competence and literacy programmes is evaluated through outcome indicators (post-training assessment, post-deployment behaviour, near-miss reduction, incident learning)
Programme adjustments are made based on effectiveness findings
Reporting on competence posture is included in AIMS performance evaluation per GOV.OV-04
Competence assessment uses appropriate methods per role (knowledge assessment, scenario evaluation, on-the-job demonstration, certification where applicable)
Effectiveness of competence and literacy programmes is evaluated through outcome indicators (post-training assessment, post-deployment behaviour, near-miss reduction, incident learning)
Programme adjustments are made based on effectiveness findings
Reporting on competence posture is included in AIMS performance evaluation per GOV.OV-04
Control Mapping
ISO/IEC 42001:2023 — Cl. 7.2; Cl. 9.1
NIST AI RMF — GOVERN 2.2; GOVERN 3.2
EU AI Act — Art. 4
ISO/IEC 5338:2023 — Cl. 6.2.4
NIST AI RMF — GOVERN 2.2; GOVERN 3.2
EU AI Act — Art. 4
ISO/IEC 5338:2023 — Cl. 6.2.4
GOV.DIDocumented Information and Communication2 Controls
Description: AIMS documented information and communication — covering documented information creation, review, version control, retention, access and protection; internal and external AIMS-related communication; and records of the AIMS — are established, maintained, and protected
GOV.DI-01Documented information control — covering documented information catalogue, format requirements, creation, review and approval, version control, retention, access, integrity protection against unintended changes, and disposition — is established for the AIMST 6 · C 6 · F 6
Applies To
AIMS documented information catalogue (policies, procedures, methodologies, registers, records)
Format requirements per document class (authoritative storage format, accessible format, source format)
Creation, review, and approval workflow
Version control and change history
Retention and disposition schedule per record class
Access control and protection per sensitivity
Integrity protection against unintended or unauthorised changes
Linkage with ISMS records control per ISO/IEC 27001:2022 A.5.33
Format requirements per document class (authoritative storage format, accessible format, source format)
Creation, review, and approval workflow
Version control and change history
Retention and disposition schedule per record class
Access control and protection per sensitivity
Integrity protection against unintended or unauthorised changes
Linkage with ISMS records control per ISO/IEC 27001:2022 A.5.33
Control Details
The AIMS documented information catalogue identifies all required AIMS documents and records, with metadata (owner, class, retention, sensitivity, format)
Format requirements are defined per document class — covering authoritative storage format, accessible / human-readable format, and source format where applicable — to ensure documents remain readable, authentic, and usable over their retention period
Creation, review, and approval workflow assigns ownership and approval authority per document class
Version control and change history are maintained on all AIMS documents
Retention and disposition schedules are defined per record class, aligned with regulatory expectations (EU AI Act Art. 18 ten-year provider records where applicable, GDPR Art. 5(1)(e) storage limitation for personal data records)
Access control and protection per sensitivity leverages ISMS Controls (ISO/IEC 27001:2022 A.5.15, A.5.33, A.8.5)
Integrity protection against unintended or unauthorised changes is maintained through controlled access, change tracking, and integrity verification mechanisms (per ISO/IEC 27001:2022 A.8.32 change management and A.5.33 record protection)
Linkage with ISMS records control leverages existing infrastructure rather than duplicating it
Format requirements are defined per document class — covering authoritative storage format, accessible / human-readable format, and source format where applicable — to ensure documents remain readable, authentic, and usable over their retention period
Creation, review, and approval workflow assigns ownership and approval authority per document class
Version control and change history are maintained on all AIMS documents
Retention and disposition schedules are defined per record class, aligned with regulatory expectations (EU AI Act Art. 18 ten-year provider records where applicable, GDPR Art. 5(1)(e) storage limitation for personal data records)
Access control and protection per sensitivity leverages ISMS Controls (ISO/IEC 27001:2022 A.5.15, A.5.33, A.8.5)
Integrity protection against unintended or unauthorised changes is maintained through controlled access, change tracking, and integrity verification mechanisms (per ISO/IEC 27001:2022 A.8.32 change management and A.5.33 record protection)
Linkage with ISMS records control leverages existing infrastructure rather than duplicating it
Control Mapping
ISO/IEC 42001:2023 — Cl. 7.5; Cl. 7.5.2; Cl. 7.5.3; A.2.2
NIST AI RMF — GOVERN 1.4
EU AI Act — Art. 18 (where applicable); Art. 12; Art. 26(6)
GDPR — Art. 5(1)(e); Art. 30
ISO/IEC 27001:2022 — Cl. 7.5; A.5.15; A.5.33; A.8.5; A.8.32
NIST AI RMF — GOVERN 1.4
EU AI Act — Art. 18 (where applicable); Art. 12; Art. 26(6)
GDPR — Art. 5(1)(e); Art. 30
ISO/IEC 27001:2022 — Cl. 7.5; A.5.15; A.5.33; A.8.5; A.8.32
GOV.DI-02AIMS communication — covering internal and external AIMS-related communication, communication content, audience, timing, channels, and responsibility — is established and maintainedT 7 · C 7 · F 6
Applies To
Internal AIMS communication (AI policy, objectives, roles, performance, change updates)
External AIMS communication (interested parties per CON.IP, regulators, customers, suppliers, affected parties per CON.IP-02)
Communication content, audience, timing, channels, and responsibility per Cl. 7.4
Communication on material AIMS change per GOV.OB-03
Linkage with transparency disclosure per TRA and regulatory engagement per GOV.GF
External AIMS communication (interested parties per CON.IP, regulators, customers, suppliers, affected parties per CON.IP-02)
Communication content, audience, timing, channels, and responsibility per Cl. 7.4
Communication on material AIMS change per GOV.OB-03
Linkage with transparency disclosure per TRA and regulatory engagement per GOV.GF
Control Details
Internal AIMS communication covers AI policy, objectives, roles, performance reporting, and change updates with defined cadence and channels
External AIMS communication covers interested parties per CON.IP, regulators, customers, suppliers, and affected parties per CON.IP-02
Communication content, audience, timing, channels, and responsibility are documented per Cl. 7.4
Communication on material AIMS change is triggered by change planning per GOV.OB-03 and follows the same content / audience / timing / channel discipline
Linkage with transparency disclosure per TRA Domain (Art. 13, Art. 50, Art. 86 obligations) and regulatory engagement per GOV.GF maintains a coherent external posture
Communication records are maintained per GOV.DI-01
External AIMS communication covers interested parties per CON.IP, regulators, customers, suppliers, and affected parties per CON.IP-02
Communication content, audience, timing, channels, and responsibility are documented per Cl. 7.4
Communication on material AIMS change is triggered by change planning per GOV.OB-03 and follows the same content / audience / timing / channel discipline
Linkage with transparency disclosure per TRA Domain (Art. 13, Art. 50, Art. 86 obligations) and regulatory engagement per GOV.GF maintains a coherent external posture
Communication records are maintained per GOV.DI-01
Control Mapping
ISO/IEC 42001:2023 — Cl. 7.4; A.8; A.8.5
NIST AI RMF — GOVERN 1.4; GOVERN 5.1
EU AI Act — Art. 13; Art. 26(11); Art. 50; Art. 86
OECD AI Principles (OECD/LEGAL/0449)
GDPR — Art. 12; Art. 13; Art. 14
ISO/IEC 27001:2022 — Cl. 7.4; A.5.5
NIST AI RMF — GOVERN 1.4; GOVERN 5.1
EU AI Act — Art. 13; Art. 26(11); Art. 50; Art. 86
OECD AI Principles (OECD/LEGAL/0449)
GDPR — Art. 12; Art. 13; Art. 14
ISO/IEC 27001:2022 — Cl. 7.4; A.5.5
GOV.OVAIMS Performance Evaluation and Improvement7 Controls
Description: AIMS performance evaluation and improvement — covering AIMS key performance and key risk indicators, performance against AI objectives, internal audit, board and executive reporting, management review, per-Control AI maturity scoring, nonconformity and corrective action, and continual improvement — are conducted at defined cadence and used to drive AIMS effectiveness
GOV.OV-01AIMS key performance and key risk indicators are defined, measured, and reported on defined cadence to provide observability over AIMS effectivenessT 7 · C 7 · F 6
Applies To
AIMS KPIs (effectiveness, efficiency, maturity, outcome)
AIMS KRIs (residual risk, indicator breaches, near-miss trends)
KPI/KRI definition methodology
Measurement and reporting cadence
Owner per KPI/KRI
AIMS KRIs (residual risk, indicator breaches, near-miss trends)
KPI/KRI definition methodology
Measurement and reporting cadence
Owner per KPI/KRI
Control Details
AIMS KPIs are defined to measure AI policy adherence, AI risk treatment progress, AI competence levels, AI incident rates, AI control maturity, and AI outcome indicators
AIMS KRIs are defined to detect emerging risk (residual-risk-above-appetite count, control-degradation indicators, near-miss trends, regulatory exposure indicators)
KPI/KRI definition methodology is documented (definition, formula, data source, target band)
Measurement cadence is defined per indicator (at minimum quarterly for most; monthly for operational indicators)
Each KPI/KRI has a named owner accountable for measurement and reporting
Indicators are reported to AI governance forums per GOV.GF and top management per GOV.OV-04
AIMS KRIs are defined to detect emerging risk (residual-risk-above-appetite count, control-degradation indicators, near-miss trends, regulatory exposure indicators)
KPI/KRI definition methodology is documented (definition, formula, data source, target band)
Measurement cadence is defined per indicator (at minimum quarterly for most; monthly for operational indicators)
Each KPI/KRI has a named owner accountable for measurement and reporting
Indicators are reported to AI governance forums per GOV.GF and top management per GOV.OV-04
Control Mapping
ISO/IEC 42001:2023 — Cl. 9.1
NIST AI RMF — MEASURE 3.1; MEASURE 4.1
EU AI Act — Art. 17(2)(g)
ISO/IEC 5338:2023 — Cl. 6.3.7
NIST AI RMF — MEASURE 3.1; MEASURE 4.1
EU AI Act — Art. 17(2)(g)
ISO/IEC 5338:2023 — Cl. 6.3.7
GOV.OV-02AIMS performance is evaluated against defined AI objectives at defined cadence; measurement results are validated by AI actor feedback to confirm the measurement captures what matters; findings drive improvementT 6 · C 6 · F 6
Applies To
AI objectives per AI strategy per GOV.ST and AI objectives document per GOV.OB
Performance evaluation methodology
Evaluation cadence
AI actor feedback as input to measurement validation per CON.IP-04
Performance against objectives reporting
Improvement identification
Performance evaluation methodology
Evaluation cadence
AI actor feedback as input to measurement validation per CON.IP-04
Performance against objectives reporting
Improvement identification
Control Details
AI objectives are derived from AI strategy per GOV.ST and AI policy per GOV.PO, and are documented per GOV.OB
Performance evaluation methodology is documented (data sources, measurement frequency, evaluation criteria)
Performance is evaluated at defined cadence (at minimum annually) and ad-hoc when material context changes
Measurement results are validated against AI actor feedback per CON.IP-04 to confirm the measurement captures what matters operationally — feedback from users, affected parties per CON.IP-02, AI engineering teams, oversight personnel per HUM.CM, and customers is reviewed alongside KPI results to identify measurement blind spots, off-target metrics, or measurement decoupling from operational reality
Measurement methodology is adjusted where validation reveals a gap, with documented rationale and approval per GOV.RR-03
Performance against AI objectives is reported to AI governance forums per GOV.GF and management review per GOV.OV-05
Performance gaps drive improvement actions per GOV.OV-07
Evaluation methodology is itself reviewed when AI objectives materially change
Performance evaluation methodology is documented (data sources, measurement frequency, evaluation criteria)
Performance is evaluated at defined cadence (at minimum annually) and ad-hoc when material context changes
Measurement results are validated against AI actor feedback per CON.IP-04 to confirm the measurement captures what matters operationally — feedback from users, affected parties per CON.IP-02, AI engineering teams, oversight personnel per HUM.CM, and customers is reviewed alongside KPI results to identify measurement blind spots, off-target metrics, or measurement decoupling from operational reality
Measurement methodology is adjusted where validation reveals a gap, with documented rationale and approval per GOV.RR-03
Performance against AI objectives is reported to AI governance forums per GOV.GF and management review per GOV.OV-05
Performance gaps drive improvement actions per GOV.OV-07
Evaluation methodology is itself reviewed when AI objectives materially change
Control Mapping
ISO/IEC 42001:2023 — Cl. 9.1
NIST AI RMF — MEASURE 4.2; MEASURE 4.3; MANAGE 4.2
EU AI Act — Art. 17(2)(g)
NIST AI RMF — MEASURE 4.2; MEASURE 4.3; MANAGE 4.2
EU AI Act — Art. 17(2)(g)
GOV.OV-03AIMS internal audit programme is operated, providing independent evaluation of AIMS conformity and effectivenessT 7 · C 7 · F 6
Applies To
Internal audit programme charter and scope
Audit independence per GOV.RR-04
Audit cadence and coverage
Audit findings management
Audit reporting to top management
Audit independence per GOV.RR-04
Audit cadence and coverage
Audit findings management
Audit reporting to top management
Control Details
The AIMS internal audit programme is chartered with defined scope, criteria, methods, and reporting
Audit independence is maintained per GOV.RR-04 (auditors independent of AI development and operational AI decisions)
Audit cadence ensures full AIMS coverage over a defined cycle (typically 2-3 years); high-risk areas audited more frequently
Audit findings are documented with severity, recommendation, and target outcome
Audit findings are escalated per defined criteria, action-tracked per GOV.OV-07, and verified at closure
Audit reports are provided to top management per GOV.OV-04
Audit independence is maintained per GOV.RR-04 (auditors independent of AI development and operational AI decisions)
Audit cadence ensures full AIMS coverage over a defined cycle (typically 2-3 years); high-risk areas audited more frequently
Audit findings are documented with severity, recommendation, and target outcome
Audit findings are escalated per defined criteria, action-tracked per GOV.OV-07, and verified at closure
Audit reports are provided to top management per GOV.OV-04
Control Mapping
ISO/IEC 42001:2023 — Cl. 9.2; Cl. 9.2.2
NIST AI RMF — GOVERN 1.5; MEASURE 1.3
EU AI Act — Art. 17(2)(h)
ISO/IEC 5338:2023 — Cl. 6.3.8
ISO/IEC 38507:2022 — Cl. 5.5
NIST AI RMF — GOVERN 1.5; MEASURE 1.3
EU AI Act — Art. 17(2)(h)
ISO/IEC 5338:2023 — Cl. 6.3.8
ISO/IEC 38507:2022 — Cl. 5.5
GOV.OV-04Board and Executive AI reporting is conducted at defined cadence with defined content, providing the Board and top management with the visibility needed to direct and oversee AIT 6 · C 6 · F 6
Applies To
Board reporting cadence and format
Executive reporting cadence and format
Reporting content (posture, risks, incidents, compliance, strategic progress)
Reporting accuracy and completeness
Ad-hoc escalation triggers
Executive reporting cadence and format
Reporting content (posture, risks, incidents, compliance, strategic progress)
Reporting accuracy and completeness
Ad-hoc escalation triggers
Control Details
AI posture reporting to the Board occurs at defined cadence (at minimum quarterly) with structured content
Reporting content includes AIMS KPIs/KRIs per GOV.OV-01, AI risk posture, AI incidents and near-misses per LIF.IR, regulatory compliance posture, strategic progress per GOV.ST
Executive AI reporting to top management occurs more frequently (at minimum monthly) with operational content
Reporting accuracy and completeness is reviewed; material issues identified during reporting are escalated
Ad-hoc escalation triggers exist (material incident, regulatory development, material risk indicator breach)
Reporting effectiveness is evaluated to ensure Board and Executive can act on the information
Reporting content includes AIMS KPIs/KRIs per GOV.OV-01, AI risk posture, AI incidents and near-misses per LIF.IR, regulatory compliance posture, strategic progress per GOV.ST
Executive AI reporting to top management occurs more frequently (at minimum monthly) with operational content
Reporting accuracy and completeness is reviewed; material issues identified during reporting are escalated
Ad-hoc escalation triggers exist (material incident, regulatory development, material risk indicator breach)
Reporting effectiveness is evaluated to ensure Board and Executive can act on the information
Control Mapping
ISO/IEC 42001:2023 — Cl. 9.1; Cl. 9.3
NIST AI RMF — GOVERN 2.3; MEASURE 3.1
EU AI Act — Art. 17(2)(g)
ISO/IEC 38507:2022 — Cl. 5
NIST AI RMF — GOVERN 2.3; MEASURE 3.1
EU AI Act — Art. 17(2)(g)
ISO/IEC 38507:2022 — Cl. 5
GOV.OV-05AIMS management review is conducted by top management at defined cadence, covering performance, audit results, risk, compliance, and continual improvementT 7 · C 7 · F 6
Applies To
Management review schedule (at minimum annually)
Management review inputs per ISO 42001 Cl. 9.3
Management review outputs (decisions, actions)
Reviewer composition (top management)
Record-keeping
Management review inputs per ISO 42001 Cl. 9.3
Management review outputs (decisions, actions)
Reviewer composition (top management)
Record-keeping
Control Details
Top management conducts AIMS management review at minimum annually
Review inputs include status of previous review actions, changes in context, performance against AI objectives per GOV.OV-02, audit results per GOV.OV-03, risk posture per RSK, AI incidents per LIF.IR, compliance posture, interested party feedback, opportunities for improvement
Review outputs include decisions on AIMS performance, decisions on changes to AI policy or AI strategy, resource decisions, improvement actions per GOV.OV-07
Reviewer composition includes top management; supporting attendees include the accountable AI executive per GOV.RR-01 and AI governance leaders
Review records are maintained with decisions and rationale
Review inputs include status of previous review actions, changes in context, performance against AI objectives per GOV.OV-02, audit results per GOV.OV-03, risk posture per RSK, AI incidents per LIF.IR, compliance posture, interested party feedback, opportunities for improvement
Review outputs include decisions on AIMS performance, decisions on changes to AI policy or AI strategy, resource decisions, improvement actions per GOV.OV-07
Reviewer composition includes top management; supporting attendees include the accountable AI executive per GOV.RR-01 and AI governance leaders
Review records are maintained with decisions and rationale
Control Mapping
ISO/IEC 42001:2023 — Cl. 9.3; Cl. 9.3.2; Cl. 9.3.3
NIST AI RMF — GOVERN 1.5; GOVERN 2.3
EU AI Act — Art. 17(2)
ISO/IEC 38507:2022 — Cl. 5
NIST AI RMF — GOVERN 1.5; GOVERN 2.3
EU AI Act — Art. 17(2)
ISO/IEC 38507:2022 — Cl. 5
GOV.OV-06Per-Control AI maturity is scored against the organisation's defined KPI Scoring Model, providing current, target, and forecast maturity per Control across the AIMST 7 · C 7 · F 6
Applies To
Per-Control current, target, and forecast scoring
Scoring methodology aligned to KPI Scoring Model
Scoring cadence
Scoring assurance
Score-driven prioritisation feeding RSK.TR and improvement per GOV.OV-07
Scoring methodology aligned to KPI Scoring Model
Scoring cadence
Scoring assurance
Score-driven prioritisation feeding RSK.TR and improvement per GOV.OV-07
Control Details
Each Control across the AIMS is scored on the defined 1-10 KPI Scoring Model (Initial / Developing / Defined / Managed / Optimised bands)
Current, target, and forecast scores are maintained per Control
Scoring cadence is defined (at minimum quarterly) with scoring updates triggered by material change to the Control's underlying capability
Scoring is performed by the Control Owner with assurance by AI governance per defined methodology
Score-driven prioritisation feeds improvement actions per GOV.OV-07 and risk treatment per RSK.TR
Aggregated scoring is reported to AI governance forums and top management per GOV.OV-04
Current, target, and forecast scores are maintained per Control
Scoring cadence is defined (at minimum quarterly) with scoring updates triggered by material change to the Control's underlying capability
Scoring is performed by the Control Owner with assurance by AI governance per defined methodology
Score-driven prioritisation feeds improvement actions per GOV.OV-07 and risk treatment per RSK.TR
Aggregated scoring is reported to AI governance forums and top management per GOV.OV-04
Control Mapping
ISO/IEC 42001:2023 — Cl. 9.1
NIST AI RMF — MEASURE 4.3
EU AI Act — Art. 17(2)(g)
NIST AI RMF — MEASURE 4.3
EU AI Act — Art. 17(2)(g)
GOV.OV-07Nonconformity, corrective action, and continual improvement of the AIMS are managed through a defined process, ensuring AIMS deficiencies are identified, addressed, and used to drive improvementT 6 · C 6 · F 6
Applies To
Nonconformity register
Corrective action process
Root cause analysis
Continual improvement programme
Improvement action tracking
Effectiveness verification
Corrective action process
Root cause analysis
Continual improvement programme
Improvement action tracking
Effectiveness verification
Control Details
A nonconformity register is maintained, capturing AIMS deficiencies identified through audit, management review, monitoring, and concerns per GOV.RR-05
Corrective actions are determined to address nonconformity root causes per defined process; root cause analysis is performed for material nonconformities
Continual improvement actions are identified through performance evaluation per GOV.OV-02 and other inputs (interested party feedback, audit findings, AI incidents)
Improvement actions are tracked to closure with named owners and target dates
Effectiveness of corrective and improvement actions is verified
Nonconformity, corrective action, and improvement progress is reported to top management per GOV.OV-04
Corrective actions are determined to address nonconformity root causes per defined process; root cause analysis is performed for material nonconformities
Continual improvement actions are identified through performance evaluation per GOV.OV-02 and other inputs (interested party feedback, audit findings, AI incidents)
Improvement actions are tracked to closure with named owners and target dates
Effectiveness of corrective and improvement actions is verified
Nonconformity, corrective action, and improvement progress is reported to top management per GOV.OV-04
Control Mapping
ISO/IEC 42001:2023 — Cl. 10; Cl. 10.1
NIST AI RMF — MANAGE 4.2; MANAGE 4.3
EU AI Act — Art. 17(2)(j)
ISO/IEC 5338:2023 — Cl. 6.2.6
NIST AI RMF — MANAGE 4.2; MANAGE 4.3
EU AI Act — Art. 17(2)(j)
ISO/IEC 5338:2023 — Cl. 6.2.6
Context20 Controls · 5 Objectives
CON.OCOrganisational Context3 Controls
Description: Internal and external issues bearing on AI activities — covering regulatory and policy environment, threat and opportunity landscape, technology trends, organisational structure and culture, capabilities and constraints, and material change triggers — are identified, documented, and reviewed at defined cadence and on material change
CON.OC-01External AI context — regulatory and policy environment, AI threat and opportunity landscape, AI technology trends, market and competitive landscape, and geopolitical factors — is identified, documented, and reviewed at defined cadence and on material changeT 7 · C 6 · F 6
Applies To
AI regulatory and policy environment (EU AI Act, GDPR, EU AI Office guidance, sectoral guidance)
AI threat and opportunity landscape
AI technology trends and emerging capabilities (incl. agentic and foundation model developments)
Market and competitive AI landscape
Geopolitical factors affecting AI operations
External context register
AI threat and opportunity landscape
AI technology trends and emerging capabilities (incl. agentic and foundation model developments)
Market and competitive AI landscape
Geopolitical factors affecting AI operations
External context register
Control Details
The external AI context is identified through structured environmental scanning, regulatory horizon scanning, AI threat intelligence, and AI technology tracking
Each external context issue is recorded with owner, materiality assessment, and linkage to affected AIMS elements
External context review is performed at defined cadence (at minimum annually) and triggered ad-hoc on material change (regulatory development, new AI capability class, material market shift)
External context findings feed CON.IN AI inventory considerations, RSK risk identification, IMP impact assessment, and CON.JU jurisdictional applicability
Material external context changes are reported to AI governance forums per GOV.GF
External context outputs are documented and made accessible to interested parties per CON.IP
Each external context issue is recorded with owner, materiality assessment, and linkage to affected AIMS elements
External context review is performed at defined cadence (at minimum annually) and triggered ad-hoc on material change (regulatory development, new AI capability class, material market shift)
External context findings feed CON.IN AI inventory considerations, RSK risk identification, IMP impact assessment, and CON.JU jurisdictional applicability
Material external context changes are reported to AI governance forums per GOV.GF
External context outputs are documented and made accessible to interested parties per CON.IP
Control Mapping
ISO/IEC 42001:2023 — Cl. 4.1
NIST AI RMF — MAP 1.1; MAP 1.3
EU AI Act — Art. 17(2)
OECD AI Principles (OECD/LEGAL/0449)
ISO/IEC 38507:2022 — Cl. 5.4
NIST AI RMF — MAP 1.1; MAP 1.3
EU AI Act — Art. 17(2)
OECD AI Principles (OECD/LEGAL/0449)
ISO/IEC 38507:2022 — Cl. 5.4
CON.OC-02Internal AI context — organisational structure, culture, AI capabilities and constraints, and AI strategy implementation context — is identified, documented, and reviewed at defined cadence and on material changeT 7 · C 6 · F 6
Applies To
Organisational structure relevant to AI (AI engineering, MLOps, AI governance, AI safety, ethics)
Organisational culture regarding AI use and innovation
AI capabilities and constraints (technological, financial, human)
AI strategy implementation context per GOV.ST
AI risk appetite implementation per GOV.RA
Internal context register
Organisational culture regarding AI use and innovation
AI capabilities and constraints (technological, financial, human)
AI strategy implementation context per GOV.ST
AI risk appetite implementation per GOV.RA
Internal context register
Control Details
The internal AI context is identified covering organisational structure, culture, AI capabilities, AI maturity, and implementation constraints
Internal AI capability and constraint mapping identifies build-vs-buy considerations and capability gaps per GOV.ST-04
Internal context review is performed at defined cadence (at minimum annually) and on material change (organisational restructure, material AI capability change, material AI cultural shift)
Internal context feeds AI strategy per GOV.ST, AI risk per RSK, AI lifecycle per LIF
Material internal context changes are reported to AI governance forums per GOV.GF
Internal AI capability and constraint mapping identifies build-vs-buy considerations and capability gaps per GOV.ST-04
Internal context review is performed at defined cadence (at minimum annually) and on material change (organisational restructure, material AI capability change, material AI cultural shift)
Internal context feeds AI strategy per GOV.ST, AI risk per RSK, AI lifecycle per LIF
Material internal context changes are reported to AI governance forums per GOV.GF
Control Mapping
ISO/IEC 42001:2023 — Cl. 4.1
NIST AI RMF — MAP 1.3; MAP 1.4
ISO/IEC 38507:2022 — Cl. 5
NIST AI RMF — MAP 1.3; MAP 1.4
ISO/IEC 38507:2022 — Cl. 5
CON.OC-03Context review — covering combined external and internal AI context — is performed at defined cadence and on material change, with findings driving AIMS adjustmentsT 7 · C 6 · F 6
Applies To
Combined external and internal context review process
Context review schedule
Material change triggers
Context review record-keeping
Linkage to AIMS adjustment per GOV.OV-07
Context review schedule
Material change triggers
Context review record-keeping
Linkage to AIMS adjustment per GOV.OV-07
Control Details
Combined context review is performed at defined cadence (at minimum annually) integrating external context per CON.OC-01 and internal context per CON.OC-02
Material change triggers are documented (regulatory developments, AI capability shifts, organisational change, AI incident learning per LIF.IR)
Context review participants include AI governance leaders, AI risk owner, and key functional representatives
Review findings are documented and feed AI strategy per GOV.ST, AI risk per RSK, AIMS scope per CON.SC
Material context shifts trigger AIMS adjustments per GOV.OV-07
Material change triggers are documented (regulatory developments, AI capability shifts, organisational change, AI incident learning per LIF.IR)
Context review participants include AI governance leaders, AI risk owner, and key functional representatives
Review findings are documented and feed AI strategy per GOV.ST, AI risk per RSK, AIMS scope per CON.SC
Material context shifts trigger AIMS adjustments per GOV.OV-07
Control Mapping
ISO/IEC 42001:2023 — Cl. 4.1; Cl. 9.3
NIST AI RMF — MAP 1.1; GOVERN 1.5
EU AI Act — Art. 17(2)
NIST AI RMF — MAP 1.1; GOVERN 1.5
EU AI Act — Art. 17(2)
CON.IPInterested Parties4 Controls
Description: Interested parties for AI activities — covering internal stakeholders (board, executives, AI governance forums, employees with AI-related roles), external stakeholders (customers, end-users, regulators, suppliers, downstream deployers, distributors, affected parties), their AI-related needs and expectations, and AI-specific requirements — are identified, documented, and maintained
CON.IP-01The interested parties register for AI activities — covering internal and external stakeholders with AI-related needs and expectations — is established, maintained, and reviewed at defined cadenceT 7 · C 7 · F 6
Applies To
Internal interested parties (board, executive team, AI governance forums, employees with AI-related roles, internal users of AI)
External interested parties (customers, end-users, regulators, suppliers, downstream deployers, distributors, partners)
AI-related needs and expectations per party
Register maintenance
External interested parties (customers, end-users, regulators, suppliers, downstream deployers, distributors, partners)
AI-related needs and expectations per party
Register maintenance
Control Details
The interested parties register is documented, identifying internal and external parties with AI-related interests
For each party, AI-related needs, expectations, and requirements are documented
The register is reviewed at defined cadence (at minimum annually) and on material change (new regulator, new customer tier, new deployer relationship)
Register outputs feed AIMS planning, AI risk per RSK, AI policy communication per GOV.PO-03, AI strategy per GOV.ST
Material party additions or changes are reported to AI governance forums per GOV.GF
For each party, AI-related needs, expectations, and requirements are documented
The register is reviewed at defined cadence (at minimum annually) and on material change (new regulator, new customer tier, new deployer relationship)
Register outputs feed AIMS planning, AI risk per RSK, AI policy communication per GOV.PO-03, AI strategy per GOV.ST
Material party additions or changes are reported to AI governance forums per GOV.GF
Control Mapping
ISO/IEC 42001:2023 — Cl. 4.2; A.5.3
NIST AI RMF — MAP 1.2; GOVERN 5.1
EU AI Act — Art. 4; Art. 26
OECD AI Principles (OECD/LEGAL/0449)
NIST AI RMF — MAP 1.2; GOVERN 5.1
EU AI Act — Art. 4; Art. 26
OECD AI Principles (OECD/LEGAL/0449)
CON.IP-02Affected parties — individuals or groups potentially impacted by AI outputs, decisions, or operations — are identified per AI system and maintained for use in impact assessmentT 7 · C 6 · F 6
Applies To
Affected parties identification per AI system
Vulnerable groups consideration (per OECD principles + CoE Convention)
Affected parties linkage to IMP.IA impact assessment
Affected parties identification triggers
Identification methodology
Vulnerable groups consideration (per OECD principles + CoE Convention)
Affected parties linkage to IMP.IA impact assessment
Affected parties identification triggers
Identification methodology
Control Details
Affected parties are identified per AI system, considering both direct users (e.g., customers using a provided AI product) and downstream affected individuals (e.g., end-users of customer applications, individuals subject to AI-assisted decisions)
Vulnerable groups (children, elderly, individuals with disabilities, protected populations) are specifically considered per OECD principles and Council of Europe Framework Convention on AI
Affected parties identification feeds AI impact assessment per IMP.IA and AI risk identification per RSK.ID
Identification is updated when AI scope, use case, or affected population materially changes
Methodology aligns with EU AI Act Art. 27 fundamental rights impact considerations (applied as best practice in non-high-risk scope)
Vulnerable groups (children, elderly, individuals with disabilities, protected populations) are specifically considered per OECD principles and Council of Europe Framework Convention on AI
Affected parties identification feeds AI impact assessment per IMP.IA and AI risk identification per RSK.ID
Identification is updated when AI scope, use case, or affected population materially changes
Methodology aligns with EU AI Act Art. 27 fundamental rights impact considerations (applied as best practice in non-high-risk scope)
Control Mapping
ISO/IEC 42001:2023 — A.5.3; A.5.4
NIST AI RMF — MAP 5.2; MAP 1.2
EU AI Act — Art. 27; Art. 9
OECD AI Principles (OECD/LEGAL/0449)
Council of Europe Framework Convention on AI (2024)
NIST AI RMF — MAP 5.2; MAP 1.2
EU AI Act — Art. 27; Art. 9
OECD AI Principles (OECD/LEGAL/0449)
Council of Europe Framework Convention on AI (2024)
CON.IP-03AI-related requirements per interested party — regulatory, contractual, ethical, operational, and societal expectations — are documented and linked to relevant AIMS ControlsT 6 · C 6 · F 6
Applies To
Regulatory requirements per relevant authority (EU AI Office, supervisory authorities)
Contractual requirements per customer / partner
Ethical and societal expectations
Operational AI requirements per user group
Requirements linkage to AIMS Controls
Requirements register
Contractual requirements per customer / partner
Ethical and societal expectations
Operational AI requirements per user group
Requirements linkage to AIMS Controls
Requirements register
Control Details
AI-related requirements per interested party are documented, distinguishing regulatory, contractual, ethical, operational, and societal categories
Each requirement is linked to the AIMS Control(s) addressing it for traceability
Requirements are reviewed when the interested party register per CON.IP-01 is updated or when material context changes
Requirements outputs feed AI policy per GOV.PO, AI strategy per GOV.ST, AI risk per RSK, AI Control design across the AIMS
Conflicting or competing requirements are flagged and addressed through AI governance forums per GOV.GF
Each requirement is linked to the AIMS Control(s) addressing it for traceability
Requirements are reviewed when the interested party register per CON.IP-01 is updated or when material context changes
Requirements outputs feed AI policy per GOV.PO, AI strategy per GOV.ST, AI risk per RSK, AI Control design across the AIMS
Conflicting or competing requirements are flagged and addressed through AI governance forums per GOV.GF
Control Mapping
ISO/IEC 42001:2023 — Cl. 4.2; A.5.3
NIST AI RMF — MAP 1.1; GOVERN 1.1
EU AI Act — Art. 4; Art. 17
OECD AI Principles (OECD/LEGAL/0449)
NIST AI RMF — MAP 1.1; GOVERN 1.1
EU AI Act — Art. 4; Art. 17
OECD AI Principles (OECD/LEGAL/0449)
CON.IP-04Feedback mechanisms enabling AI development and operations teams to receive, adjudicate, and integrate feedback from external AI actors and interested parties — covering inbound channels, adjudication, integration into AI design and operations, and closure communication — are established and maintainedT 6 · C 6 · F 6
Applies To
Inbound feedback channels per interested-party category per CON.IP-01 and affected-party category per CON.IP-02
Adjudication process (triage, validation, prioritisation, routing)
Integration into AI design and operations across LIF stages
Closure and communication back to feedback providers per GOV.DI-02
Linkage with HUM.UA user agency Controls and IMP.MO post-deployment monitoring
Adjudication process (triage, validation, prioritisation, routing)
Integration into AI design and operations across LIF stages
Closure and communication back to feedback providers per GOV.DI-02
Linkage with HUM.UA user agency Controls and IMP.MO post-deployment monitoring
Control Details
Feedback mechanisms enable AI development and operations teams to receive feedback from external AI actors — users, customers, communities, civil society, regulators, partners — on AI behaviour, design, impact, and risk
Inbound channels are tailored per interested-party category — direct-feedback portals for users, structured engagement for communities and civil society, regulatory liaison channels, partner and customer escalation routes
Adjudication process triages incoming feedback, validates concerns, prioritises against operational and strategic context per GOV.RA risk appetite, and routes to relevant teams (AI engineering, AI safety, AI ethics committee per GOV.GF-03, AI governance forums per GOV.GF)
Integration into AI design and operations connects adjudicated feedback to LIF lifecycle stages — design per LIF.DE, validation per LIF.VA, deployment per LIF.DP, operational monitoring per LIF.OP, version updates per LIF.VR
Closure communication informs feedback providers of disposition (actioned, deferred, declined with rationale) in line with GOV.DI-02 communication discipline
Linkage with HUM.UA-01 user agency, HUM.UA-03 contestation, IMP.MO-02 post-deployment monitoring, and CON.IP-02 affected parties maintains coherent inbound feedback flow
Inbound channels are tailored per interested-party category — direct-feedback portals for users, structured engagement for communities and civil society, regulatory liaison channels, partner and customer escalation routes
Adjudication process triages incoming feedback, validates concerns, prioritises against operational and strategic context per GOV.RA risk appetite, and routes to relevant teams (AI engineering, AI safety, AI ethics committee per GOV.GF-03, AI governance forums per GOV.GF)
Integration into AI design and operations connects adjudicated feedback to LIF lifecycle stages — design per LIF.DE, validation per LIF.VA, deployment per LIF.DP, operational monitoring per LIF.OP, version updates per LIF.VR
Closure communication informs feedback providers of disposition (actioned, deferred, declined with rationale) in line with GOV.DI-02 communication discipline
Linkage with HUM.UA-01 user agency, HUM.UA-03 contestation, IMP.MO-02 post-deployment monitoring, and CON.IP-02 affected parties maintains coherent inbound feedback flow
Control Mapping
ISO/IEC 42001:2023 — A.4; A.8; A.8.3; A.9
NIST AI RMF — GOVERN 5.2; MAP 5.2; MEASURE 3.3
EU AI Act — Art. 50; Art. 86
OECD AI Principles (OECD/LEGAL/0449)
GDPR — Art. 21
Council of Europe Framework Convention on AI (2024)
NIST AI RMF — GOVERN 5.2; MAP 5.2; MEASURE 3.3
EU AI Act — Art. 50; Art. 86
OECD AI Principles (OECD/LEGAL/0449)
GDPR — Art. 21
Council of Europe Framework Convention on AI (2024)
CON.SCAIMS Scope3 Controls
Description: The AI Management System scope — covering organisational entities, AI roles (provider, deployer, internal developer), AI systems and activities in scope, asset boundaries, locations, exclusions with rationale, and interfaces between in-scope and out-of-scope elements — is defined, documented, and maintained
CON.SC-01The AIMS scope statement — covering organisational entities, AI roles, AI systems and activities, asset boundaries, locations, and interfaces — is documented, approved, and made accessibleT 7 · C 7 · F 6
Applies To
AIMS scope statement document
Organisational entities in scope
AI roles in scope (provider, deployer, internal developer)
AI systems and activities in scope
Asset boundaries (data, models, infrastructure)
Locations and jurisdictions
Interfaces with out-of-scope elements
Organisational entities in scope
AI roles in scope (provider, deployer, internal developer)
AI systems and activities in scope
Asset boundaries (data, models, infrastructure)
Locations and jurisdictions
Interfaces with out-of-scope elements
Control Details
The AIMS scope statement is documented, approved at appropriate authority level
The scope explicitly identifies organisational entities (legal entities, business units, functions) in scope
AI roles are stated — provider activities, deployer activities, and internal-developer activities — per CON.JU role determination
AI systems and activities in scope are identified per CON.IN inventory linkage
Asset boundaries cover AI-relevant data, models, infrastructure, and tools
Locations include offices, data centres, cloud regions, and jurisdictional applicability per CON.JU
Interfaces between in-scope and out-of-scope elements are documented to prevent boundary-risk gaps
The scope explicitly identifies organisational entities (legal entities, business units, functions) in scope
AI roles are stated — provider activities, deployer activities, and internal-developer activities — per CON.JU role determination
AI systems and activities in scope are identified per CON.IN inventory linkage
Asset boundaries cover AI-relevant data, models, infrastructure, and tools
Locations include offices, data centres, cloud regions, and jurisdictional applicability per CON.JU
Interfaces between in-scope and out-of-scope elements are documented to prevent boundary-risk gaps
Control Mapping
ISO/IEC 42001:2023 — Cl. 4.3
NIST AI RMF — GOVERN 1.6; MAP 1.4
EU AI Act — Art. 2; Art. 17(2)
NIST AI RMF — GOVERN 1.6; MAP 1.4
EU AI Act — Art. 2; Art. 17(2)
CON.SC-02AIMS scope exclusions and boundaries with documented rationale — covering AI activities, systems, or contexts excluded from the AIMS — are identified and approvedT 7 · C 7 · F 6
Applies To
Scope exclusions per category
Exclusion rationale per exclusion
Boundary definitions where partial inclusion applies
Risk acknowledgement for excluded scope
Exclusion approval authority
Exclusion rationale per exclusion
Boundary definitions where partial inclusion applies
Risk acknowledgement for excluded scope
Exclusion approval authority
Control Details
Scope exclusions are documented per category (e.g., research-only systems not placed on the market, AI activities outside EU regulatory recognition per scope decisions, third-party AI consumed but governed entirely by another framework)
Each exclusion has documented rationale and approval at appropriate authority level
Boundary definitions are documented where partial inclusion applies (e.g., AI used in marketing tools but with governance via marketing function)
Excluded scope risks are acknowledged and accepted per RSK.TR
Exclusions are reviewed when AI scope materially changes
Each exclusion has documented rationale and approval at appropriate authority level
Boundary definitions are documented where partial inclusion applies (e.g., AI used in marketing tools but with governance via marketing function)
Excluded scope risks are acknowledged and accepted per RSK.TR
Exclusions are reviewed when AI scope materially changes
Control Mapping
ISO/IEC 42001:2023 — Cl. 4.3
NIST AI RMF — GOVERN 1.6; MAP 1.4
EU AI Act — Art. 2
NIST AI RMF — GOVERN 1.6; MAP 1.4
EU AI Act — Art. 2
CON.SC-03AIMS scope review is performed at defined cadence and on material change, with scope changes formally approved and communicatedT 6 · C 6 · F 6
Applies To
Scope review schedule (at minimum annually)
Material change triggers (organisational change, regulatory change, AI strategy change)
Scope review process and participants
Scope change approval and communication
Scope version control
Material change triggers (organisational change, regulatory change, AI strategy change)
Scope review process and participants
Scope change approval and communication
Scope version control
Control Details
AIMS scope is reviewed at minimum annually by the AI governance forum per GOV.GF
Material change triggers include AI strategy revision per GOV.ST-05, organisational restructure, regulatory developments materially affecting scope, material AI portfolio expansion
Scope changes are approved at appropriate authority level
Updated scope is communicated to interested parties per CON.IP-01 and GOV.PO-03
Scope versioning is maintained with version control and approval evidence
Scope changes are reflected in downstream Controls (CON.IN, RSK, IMP)
Material change triggers include AI strategy revision per GOV.ST-05, organisational restructure, regulatory developments materially affecting scope, material AI portfolio expansion
Scope changes are approved at appropriate authority level
Updated scope is communicated to interested parties per CON.IP-01 and GOV.PO-03
Scope versioning is maintained with version control and approval evidence
Scope changes are reflected in downstream Controls (CON.IN, RSK, IMP)
Control Mapping
ISO/IEC 42001:2023 — Cl. 4.3; Cl. 9.3
NIST AI RMF — GOVERN 1.5; GOVERN 1.6
EU AI Act — Art. 17(2)
NIST AI RMF — GOVERN 1.5; GOVERN 1.6
EU AI Act — Art. 17(2)
CON.JUJurisdictional Applicability6 Controls
Description: EU regulatory applicability for AI activities — covering EU AI Act applicability per AI role (provider, deployer, distributor, importer, authorised representative), EU AI Act risk classification per AI product, General-Purpose AI (GPAI) determination, exemptions and derogations, and GDPR applicability to AI processing — is determined, documented, and maintained
CON.JU-01EU AI Act role determination — identifying provider, deployer, distributor, importer, and authorised representative roles per AI activity — is performed, documented, and maintainedT 7 · C 7 · F 6
Applies To
Role determination per AI product or service offered (provider)
Role determination per AI product or service consumed (deployer)
Role determination per AI redistribution activity (distributor)
Role determination for non-EU origin AI placed in EU market (importer, authorised representative)
Role determination per AI activity per CON.IN inventory
Role determination per AI product or service consumed (deployer)
Role determination per AI redistribution activity (distributor)
Role determination for non-EU origin AI placed in EU market (importer, authorised representative)
Role determination per AI activity per CON.IN inventory
Control Details
Role determination is performed per AI product or service in scope, identifying which EU AI Act role(s) apply
Where multiple roles apply concurrently (e.g., we fine-tune a third-party foundation model and resell it as a product — both deployer of the base model and provider of the derived product), each role is documented with its specific obligation set
Role determination is documented per AI activity with reasoning
Role determination is reviewed when AI scope, market positioning, or vendor relationship materially changes
Role determination feeds role-specific Controls per GOV.RR-06, IMP, TRA, TPA
Where multiple roles apply concurrently (e.g., we fine-tune a third-party foundation model and resell it as a product — both deployer of the base model and provider of the derived product), each role is documented with its specific obligation set
Role determination is documented per AI activity with reasoning
Role determination is reviewed when AI scope, market positioning, or vendor relationship materially changes
Role determination feeds role-specific Controls per GOV.RR-06, IMP, TRA, TPA
Control Mapping
ISO/IEC 42001:2023 — Cl. 4.1; A.10
NIST AI RMF — GOVERN 1.1; MAP 4.1
EU AI Act — Art. 3; Art. 16; Art. 22; Art. 23; Art. 24; Art. 25; Art. 26
NIST AI RMF — GOVERN 1.1; MAP 4.1
EU AI Act — Art. 3; Art. 16; Art. 22; Art. 23; Art. 24; Art. 25; Art. 26
CON.JU-02EU AI Act risk classification — categorising AI products as prohibited, high-risk, limited-risk, or minimal-risk per Articles 5, 6, 50, and Annex III — is performed, documented, and maintained per AI productT 6 · C 6 · F 6
Applies To
Prohibited AI practices check per Art. 5
High-risk classification check per Art. 6 + Annex III
Limited-risk classification check per Art. 50
Minimal-risk classification (residual)
Per-product classification record
Classification review triggers
High-risk classification check per Art. 6 + Annex III
Limited-risk classification check per Art. 50
Minimal-risk classification (residual)
Per-product classification record
Classification review triggers
Control Details
Per AI product (provider mode) and per AI used internally (internal-developer mode), classification is performed against EU AI Act risk categories
Prohibited practices per Art. 5 are checked first and excluded where they apply
High-risk classification is assessed against Art. 6 criteria and Annex III use case list — confirming no high-risk AI is in scope per AIMS scope decisions
Limited-risk classification (Art. 50 transparency obligations) is identified for AI products interacting with natural persons, generating synthetic content, or performing emotion-recognition / biometric categorisation
Minimal-risk is the residual classification where no other category applies
Per-product classification record is maintained with reasoning
Classification is reviewed when product capability, use case, or regulatory interpretation materially changes
Prohibited practices per Art. 5 are checked first and excluded where they apply
High-risk classification is assessed against Art. 6 criteria and Annex III use case list — confirming no high-risk AI is in scope per AIMS scope decisions
Limited-risk classification (Art. 50 transparency obligations) is identified for AI products interacting with natural persons, generating synthetic content, or performing emotion-recognition / biometric categorisation
Minimal-risk is the residual classification where no other category applies
Per-product classification record is maintained with reasoning
Classification is reviewed when product capability, use case, or regulatory interpretation materially changes
Control Mapping
ISO/IEC 42001:2023 — Cl. 4.1; A.5.2
NIST AI RMF — GOVERN 1.1; MAP 1.1; MAP 5.1
EU AI Act — Art. 5; Art. 6; Art. 50; Art. 80; Annex III
NIST AI RMF — GOVERN 1.1; MAP 1.1; MAP 5.1
EU AI Act — Art. 5; Art. 6; Art. 50; Art. 80; Annex III
CON.JU-03General-Purpose AI determination — identifying whether AI models qualify as GPAI per Art. 51 and whether systemic-risk thresholds are met — is performed, documented, and maintained per AI modelT 7 · C 7 · F 6
Applies To
GPAI classification per AI model developed in-house
GPAI classification per AI model fine-tuned from third-party foundation models
Systemic-risk threshold assessment per Art. 51
Notification obligations to EU AI Office where applicable
GPAI classification record
GPAI classification per AI model fine-tuned from third-party foundation models
Systemic-risk threshold assessment per Art. 51
Notification obligations to EU AI Office where applicable
GPAI classification record
Control Details
GPAI classification is performed per AI model, considering generality of purpose, downstream integration potential, and capability scope per Art. 51 criteria
For self-developed foundation models, GPAI status is assessed against Art. 51 definition
For fine-tuned models, GPAI status is reassessed where fine-tuning materially alters generality
Systemic-risk threshold assessment is performed per Art. 51(1)(a) (cumulative compute above threshold) and Art. 51(1)(b) (decision-based designation)
Where systemic risk is identified, notification obligations to EU AI Office per Art. 52 are tracked
Classification record is maintained per model with version and reasoning
For self-developed foundation models, GPAI status is assessed against Art. 51 definition
For fine-tuned models, GPAI status is reassessed where fine-tuning materially alters generality
Systemic-risk threshold assessment is performed per Art. 51(1)(a) (cumulative compute above threshold) and Art. 51(1)(b) (decision-based designation)
Where systemic risk is identified, notification obligations to EU AI Office per Art. 52 are tracked
Classification record is maintained per model with version and reasoning
Control Mapping
ISO/IEC 42001:2023 — Cl. 4.1; A.6.2
NIST AI RMF — GOVERN 1.1; MAP 1.1
EU AI Act — Art. 51; Art. 52; Art. 53; Art. 55
EU GPAI Code of Practice (Safety and Security Chapter)
NIST AI RMF — GOVERN 1.1; MAP 1.1
EU AI Act — Art. 51; Art. 52; Art. 53; Art. 55
EU GPAI Code of Practice (Safety and Security Chapter)
CON.JU-04GDPR applicability to AI processing — identifying triggers for Art. 22 automated decision-making rights, Art. 35 DPIA obligations, Art. 37 DPO designation, and broader GDPR application — is determined, documented, and maintainedT 6 · C 6 · F 6
Applies To
AI processing involving personal data per GDPR Art. 4
Automated decision-making per Art. 22
DPIA trigger assessment per Art. 35
Data Protection Officer (DPO) designation determination per Art. 37
Special category data processing per Art. 9
Data subject rights applicability per Art. 15–22
Controller / processor / joint controller role per AI activity
Automated decision-making per Art. 22
DPIA trigger assessment per Art. 35
Data Protection Officer (DPO) designation determination per Art. 37
Special category data processing per Art. 9
Data subject rights applicability per Art. 15–22
Controller / processor / joint controller role per AI activity
Control Details
AI processing activities involving personal data are identified per CON.IN inventory
Automated decision-making determinations per Art. 22 are made per AI use case (whether the AI solely makes decisions producing legal or significant effects)
DPIA trigger assessment per Art. 35 is performed for AI processing meeting the high-risk thresholds (systematic profiling, large-scale special category data, large-scale public area monitoring)
Data Protection Officer designation requirement per Art. 37 is assessed — mandatory triggers under Art. 37(1)(b) (core activities consisting of processing operations requiring regular and systematic monitoring of data subjects on a large scale) and Art. 37(1)(c) (core activities consisting of large-scale processing of special category data under Art. 9 or criminal data under Art. 10); the designation decision and rationale are documented; where the DPO is designated, designation details (identity, contact details, publication, communication to supervisory authority per Art. 37(7)) are recorded; where DPO designation is not required, the assessment supporting that conclusion is documented per the accountability principle Art. 24
Special category data per Art. 9 in AI training, fine-tuning, or inference is identified and restricted per DAT.LB
Controller / processor / joint controller role per AI activity is determined per TPA.CT-05; role determination affects GDPR obligations
GDPR applicability outputs feed DAT.LB lawful basis Controls, IMP.DA DPIA Controls, and GOV.RR-02 DPO position
Automated decision-making determinations per Art. 22 are made per AI use case (whether the AI solely makes decisions producing legal or significant effects)
DPIA trigger assessment per Art. 35 is performed for AI processing meeting the high-risk thresholds (systematic profiling, large-scale special category data, large-scale public area monitoring)
Data Protection Officer designation requirement per Art. 37 is assessed — mandatory triggers under Art. 37(1)(b) (core activities consisting of processing operations requiring regular and systematic monitoring of data subjects on a large scale) and Art. 37(1)(c) (core activities consisting of large-scale processing of special category data under Art. 9 or criminal data under Art. 10); the designation decision and rationale are documented; where the DPO is designated, designation details (identity, contact details, publication, communication to supervisory authority per Art. 37(7)) are recorded; where DPO designation is not required, the assessment supporting that conclusion is documented per the accountability principle Art. 24
Special category data per Art. 9 in AI training, fine-tuning, or inference is identified and restricted per DAT.LB
Controller / processor / joint controller role per AI activity is determined per TPA.CT-05; role determination affects GDPR obligations
GDPR applicability outputs feed DAT.LB lawful basis Controls, IMP.DA DPIA Controls, and GOV.RR-02 DPO position
Control Mapping
ISO/IEC 42001:2023 — Cl. 4.1; A.7.4
NIST AI RMF — GOVERN 1.1; MEASURE 2.10
EU AI Act — Art. 10
GDPR — Art. 4; Art. 6; Art. 9; Art. 22; Art. 24; Art. 35; Art. 37
NIST AI RMF — GOVERN 1.1; MEASURE 2.10
EU AI Act — Art. 10
GDPR — Art. 4; Art. 6; Art. 9; Art. 22; Art. 24; Art. 35; Art. 37
CON.JU-05Jurisdictional applicability review — covering EU AI Act and GDPR applicability per AI activity — is performed at defined cadence and on material changeT 6 · C 6 · F 6
Applies To
Review schedule (at minimum annually)
Material change triggers (regulatory amendments, new AI products, new use cases, role changes)
Review participants
Review record-keeping
Review-driven adjustments
Material change triggers (regulatory amendments, new AI products, new use cases, role changes)
Review participants
Review record-keeping
Review-driven adjustments
Control Details
Jurisdictional applicability is reviewed at minimum annually; ad-hoc review is triggered by regulatory amendments (EU AI Act delegated acts, guidance from EU AI Office), new AI products or use cases, role changes, or material AI risk class changes
Review participants include legal, AI compliance, AI governance forums per GOV.GF, and accountable AI executive per GOV.RR-01
Review records are documented with findings and required adjustments
Adjustments are tracked through AIMS continual improvement per GOV.OV-07
Material applicability changes are reported to AI governance forums and management review per GOV.OV-05
Review participants include legal, AI compliance, AI governance forums per GOV.GF, and accountable AI executive per GOV.RR-01
Review records are documented with findings and required adjustments
Adjustments are tracked through AIMS continual improvement per GOV.OV-07
Material applicability changes are reported to AI governance forums and management review per GOV.OV-05
Control Mapping
ISO/IEC 42001:2023 — Cl. 4.1; Cl. 9.3
NIST AI RMF — GOVERN 1.1; GOVERN 1.5
EU AI Act — Art. 17(2)
EU GPAI Code of Practice
NIST AI RMF — GOVERN 1.1; GOVERN 1.5
EU AI Act — Art. 17(2)
EU GPAI Code of Practice
CON.JU-06Prohibited practices screening per EU AI Act Art. 5 — covering per-AI-use-case screening, all eight prohibited categories, escalation, and documented outcome — is performed before development, procurement, or deploymentT 6 · C 6 · F 6
Applies To
Per-AI-use-case screening (before development for provider and internal developer; before procurement and before deployment for deployer)
All eight Art. 5(1) prohibited categories
Borderline-case escalation
Screening outcome documentation per AI use case
Re-screening on material change (use case change, capability change, regulatory guidance update, Commission delegated act per Art. 96)
All eight Art. 5(1) prohibited categories
Borderline-case escalation
Screening outcome documentation per AI use case
Re-screening on material change (use case change, capability change, regulatory guidance update, Commission delegated act per Art. 96)
Control Details
Prohibited practices screening is performed per AI use case before development (provider and internal developer) and before procurement and deployment (deployer)
Screening covers all eight Art. 5(1) prohibited categories: (a) subliminal, purposefully manipulative or deceptive techniques causing significant harm; (b) exploitation of vulnerabilities due to age, disability, or social / economic situation causing significant harm; (c) social scoring leading to detrimental treatment in unrelated contexts or unjustified / disproportionate to behaviour; (d) predictive policing based solely on profiling or personality-trait assessment; (e) untargeted scraping of facial images to create or expand facial recognition databases; (f) emotion inference in workplace or educational institutions, except for medical or safety reasons; (g) biometric categorisation inferring race, political opinions, trade union membership, religious / philosophical beliefs, sex life, or sexual orientation; (h) real-time remote biometric identification in publicly accessible spaces for law enforcement, except narrow law-enforcement exceptions
Borderline cases are escalated to AI legal and the AI ethics committee per GOV.GF-03; non-deployable outcomes trigger avoid-treatment per RSK.TR-01 and inventory removal per CON.IN-04
Screening outcomes are documented per AI use case, retained per GOV.DI-01, linked to AI inventory per CON.IN, and feed risk classification per CON.JU-02
Re-screening is triggered by material change — use case change, capability change, regulatory guidance update from the AI Office or Commission, or Commission delegated act per Art. 96
Linkage with Art. 50(3) emotion / biometric categorisation transparency per TRA.UD-03 ensures consistent treatment where adjacent obligations apply
Screening covers all eight Art. 5(1) prohibited categories: (a) subliminal, purposefully manipulative or deceptive techniques causing significant harm; (b) exploitation of vulnerabilities due to age, disability, or social / economic situation causing significant harm; (c) social scoring leading to detrimental treatment in unrelated contexts or unjustified / disproportionate to behaviour; (d) predictive policing based solely on profiling or personality-trait assessment; (e) untargeted scraping of facial images to create or expand facial recognition databases; (f) emotion inference in workplace or educational institutions, except for medical or safety reasons; (g) biometric categorisation inferring race, political opinions, trade union membership, religious / philosophical beliefs, sex life, or sexual orientation; (h) real-time remote biometric identification in publicly accessible spaces for law enforcement, except narrow law-enforcement exceptions
Borderline cases are escalated to AI legal and the AI ethics committee per GOV.GF-03; non-deployable outcomes trigger avoid-treatment per RSK.TR-01 and inventory removal per CON.IN-04
Screening outcomes are documented per AI use case, retained per GOV.DI-01, linked to AI inventory per CON.IN, and feed risk classification per CON.JU-02
Re-screening is triggered by material change — use case change, capability change, regulatory guidance update from the AI Office or Commission, or Commission delegated act per Art. 96
Linkage with Art. 50(3) emotion / biometric categorisation transparency per TRA.UD-03 ensures consistent treatment where adjacent obligations apply
Control Mapping
ISO/IEC 42001:2023 — Cl. 4.3; Cl. 6.1; A.5.2; A.9.4
NIST AI RMF — GOVERN 1.1; MAP 4.1; MAP 5.1
EU AI Act — Art. 5; Art. 96; Art. 99 (penalties context)
OECD AI Principles (OECD/LEGAL/0449)
Council of Europe Framework Convention on AI (2024)
EU Charter of Fundamental Rights
NIST AI RMF — GOVERN 1.1; MAP 4.1; MAP 5.1
EU AI Act — Art. 5; Art. 96; Art. 99 (penalties context)
OECD AI Principles (OECD/LEGAL/0449)
Council of Europe Framework Convention on AI (2024)
EU Charter of Fundamental Rights
CON.INAI Inventory and Portfolio4 Controls
Description: The AI inventory and portfolio — covering AI products provided externally, AI products consumed from third parties (including foundation model APIs), AI products developed internally, foundation model registry (developed, fine-tuned, consumed), agentic system registry (single-agent, multi-agent, MCP-integrated), per-AI classification (role, risk class, lifecycle stage, criticality), and decommissioned AI tracking — is established, maintained, and reviewed at defined cadence and on material change
CON.IN-01The AI inventory — covering AI products provided externally, AI products consumed from third parties, and AI products developed internally — is established, classified by role, risk class, lifecycle stage, and criticality, and maintainedT 7 · C 7 · F 6
Applies To
Provider AI inventory (AI products and services placed on the market)
Deployer AI inventory (third-party AI products and services consumed)
Internal-developer AI inventory (AI for internal use)
Per-AI classification (role, EU AI Act risk class per CON.JU-02, lifecycle stage per LIF, criticality)
AI inventory record structure
Deployer AI inventory (third-party AI products and services consumed)
Internal-developer AI inventory (AI for internal use)
Per-AI classification (role, EU AI Act risk class per CON.JU-02, lifecycle stage per LIF, criticality)
AI inventory record structure
Control Details
The AI inventory is documented as the system of record for AI in AIMS scope
Inventory entries cover provider AI products, deployer AI consumed (including foundation model APIs), and internal-developer AI
Per-AI classification is maintained covering role per CON.JU-01, EU AI Act risk class per CON.JU-02, lifecycle stage per LIF.PO, and criticality (low / standard / business-critical)
Inventory entries include owner, business purpose, integration context, dependent AI components, and material risks
Inventory access is provided to AI governance forums per GOV.GF and to AI risk management per RSK
Inventory completeness is verified at defined cadence per CON.IN-04
Inventory entries cover provider AI products, deployer AI consumed (including foundation model APIs), and internal-developer AI
Per-AI classification is maintained covering role per CON.JU-01, EU AI Act risk class per CON.JU-02, lifecycle stage per LIF.PO, and criticality (low / standard / business-critical)
Inventory entries include owner, business purpose, integration context, dependent AI components, and material risks
Inventory access is provided to AI governance forums per GOV.GF and to AI risk management per RSK
Inventory completeness is verified at defined cadence per CON.IN-04
Control Mapping
ISO/IEC 42001:2023 — A.6.1
NIST AI RMF — GOVERN 1.6
EU AI Act — Art. 11; Art. 26(6)
EU GPAI Code of Practice (Transparency Chapter)
NIST AI RMF — GOVERN 1.6
EU AI Act — Art. 11; Art. 26(6)
EU GPAI Code of Practice (Transparency Chapter)
CON.IN-02The foundation model registry — covering foundation models developed in-house, fine-tuned from third-party models, and consumed via APIs — is established and maintained with model metadataT 7 · C 7 · F 6
Applies To
Self-developed foundation models
Fine-tuned foundation models (derived from third-party base models)
Consumed foundation models (via API or hosted service)
Per-model metadata (parameters, training data summary, capabilities, limitations, safety evaluations)
GPAI status per CON.JU-03
Fine-tuned foundation models (derived from third-party base models)
Consumed foundation models (via API or hosted service)
Per-model metadata (parameters, training data summary, capabilities, limitations, safety evaluations)
GPAI status per CON.JU-03
Control Details
The foundation model registry is documented as the canonical record for foundation models in AIMS scope
Self-developed foundation models are catalogued with full metadata covering training process per LIF.TR, training data summary per DAT.IN-03, evaluation results per LIF.VA, GPAI classification per CON.JU-03
Fine-tuned models are catalogued with base model reference, fine-tuning data per DAT, and reclassification per CON.JU-03 where applicable
Consumed foundation models are catalogued with provider, model version, API endpoint, deployer-relevant model card extracts, and consumption context per TPA
Registry metadata supports Art. 53 GPAI provider obligations where applicable and Art. 26 deployer obligations
Registry is updated when models are added, versioned, or decommissioned per LIF.VR
Self-developed foundation models are catalogued with full metadata covering training process per LIF.TR, training data summary per DAT.IN-03, evaluation results per LIF.VA, GPAI classification per CON.JU-03
Fine-tuned models are catalogued with base model reference, fine-tuning data per DAT, and reclassification per CON.JU-03 where applicable
Consumed foundation models are catalogued with provider, model version, API endpoint, deployer-relevant model card extracts, and consumption context per TPA
Registry metadata supports Art. 53 GPAI provider obligations where applicable and Art. 26 deployer obligations
Registry is updated when models are added, versioned, or decommissioned per LIF.VR
Control Mapping
ISO/IEC 42001:2023 — A.6.1; A.7
NIST AI RMF — GOVERN 1.6; MAP 2.1
EU AI Act — Art. 51; Art. 53
EU GPAI Code of Practice (Transparency Chapter)
Hugging Face Model Cards
NIST AI RMF — GOVERN 1.6; MAP 2.1
EU AI Act — Art. 51; Art. 53
EU GPAI Code of Practice (Transparency Chapter)
Hugging Face Model Cards
CON.IN-03The agentic system registry — covering single-agent and multi-agent systems including MCP integrations — is established and maintained with agent authorisation scope and tool boundariesT 6 · C 6 · F 6
Applies To
Single-agent systems
Multi-agent orchestration systems
MCP server and integration registry
Per-agent metadata (autonomy level, tool permissions, action scope, memory boundaries)
Agent lifecycle status per LIF.AG
Multi-agent orchestration systems
MCP server and integration registry
Per-agent metadata (autonomy level, tool permissions, action scope, memory boundaries)
Agent lifecycle status per LIF.AG
Control Details
The agentic system registry is documented as the canonical record for agentic AI in AIMS scope
Per agent or agent system, metadata includes purpose, autonomy level, authorisation scope per LIF.AG-01, tool permissions and boundaries per LIF.AG-02, integration topology (single-agent, multi-agent orchestration per LIF.AG-03, MCP integration per LIF.AG-04)
Memory and context boundaries per agent are documented
Multi-agent orchestration topology is documented (how agents communicate, decision delegation, conflict resolution)
MCP servers and tools accessed by agents are tracked with attestation per TPA.AT
Registry is updated when agents are added, materially modified, or decommissioned
Per agent or agent system, metadata includes purpose, autonomy level, authorisation scope per LIF.AG-01, tool permissions and boundaries per LIF.AG-02, integration topology (single-agent, multi-agent orchestration per LIF.AG-03, MCP integration per LIF.AG-04)
Memory and context boundaries per agent are documented
Multi-agent orchestration topology is documented (how agents communicate, decision delegation, conflict resolution)
MCP servers and tools accessed by agents are tracked with attestation per TPA.AT
Registry is updated when agents are added, materially modified, or decommissioned
Control Mapping
ISO/IEC 42001:2023 — A.6.1
NIST AI RMF — GOVERN 1.6; MAP 3.5
EU AI Act — Art. 26
OWASP AISVS — C9 (Orchestration and Agentic Action)
OWASP Top 10 for Agentic Apps
OWASP Multi-Agentic System Threat Modelling Guide
CSA Agentic AI Red Teaming Guide
NIST AI RMF — GOVERN 1.6; MAP 3.5
EU AI Act — Art. 26
OWASP AISVS — C9 (Orchestration and Agentic Action)
OWASP Top 10 for Agentic Apps
OWASP Multi-Agentic System Threat Modelling Guide
CSA Agentic AI Red Teaming Guide
CON.IN-04AI inventory maintenance, review, and decommissioning tracking are performed at defined cadence and on material change, ensuring inventory accuracy and completenessT 7 · C 7 · F 6
Applies To
Inventory maintenance cadence (continuous + periodic)
Inventory review schedule (at minimum quarterly)
New AI registration triggers
Decommissioned AI tracking per LIF.DC
Inventory completeness and accuracy verification
Discrepancy resolution
Inventory review schedule (at minimum quarterly)
New AI registration triggers
Decommissioned AI tracking per LIF.DC
Inventory completeness and accuracy verification
Discrepancy resolution
Control Details
AI inventory is maintained continuously as AI systems are added, materially modified, or decommissioned, and reviewed for completeness at minimum quarterly
New AI registration is triggered by AI deployment per GOV.RR-03 and procurement per TPA
Decommissioned AI tracking per LIF.DC-01 ensures inventory entries reflect end-of-life status with continued accessibility for historical reference
Inventory completeness verification compares operational telemetry (deployed services, model registry, foundation model usage) against inventory entries to detect undeclared AI
Discrepancies are resolved through investigation and inventory correction per AI governance forums per GOV.GF
Inventory accuracy metrics are reported per GOV.OV-01
New AI registration is triggered by AI deployment per GOV.RR-03 and procurement per TPA
Decommissioned AI tracking per LIF.DC-01 ensures inventory entries reflect end-of-life status with continued accessibility for historical reference
Inventory completeness verification compares operational telemetry (deployed services, model registry, foundation model usage) against inventory entries to detect undeclared AI
Discrepancies are resolved through investigation and inventory correction per AI governance forums per GOV.GF
Inventory accuracy metrics are reported per GOV.OV-01
Control Mapping
ISO/IEC 42001:2023 — A.6.1; Cl. 9.1
NIST AI RMF — GOVERN 1.6; GOVERN 1.7
EU AI Act — Art. 26(5)
EU GPAI Code of Practice (Safety and Security Chapter)
NIST AI RMF — GOVERN 1.6; GOVERN 1.7
EU AI Act — Art. 26(5)
EU GPAI Code of Practice (Safety and Security Chapter)
Risk23 Controls · 7 Objectives
RSK.MEAI Risk Management Methodology4 Controls
Description: The AI risk management methodology — covering AI risk classes (functional, legal, ethical, societal, commercial), assessment criteria, scoring approach, treatment options, linkage to AI risk appetite, role-specific application (provider, deployer, internal developer), and methodology review — is documented, communicated, and maintained
RSK.ME-01The AI risk management methodology — covering assessment criteria, scoring approach, and treatment options — is documented, communicated, and maintainedT 6 · C 5 · F 6
Applies To
AI risk management methodology document
Assessment criteria per risk class
Scoring approach (likelihood, impact, residual)
Treatment options framework
Methodology approval
Assessment criteria per risk class
Scoring approach (likelihood, impact, residual)
Treatment options framework
Methodology approval
Control Details
The AI risk management methodology is documented as a formal artefact, approved at appropriate authority level
Assessment criteria are defined per AI risk class per RSK.ME-02 (functional, legal, ethical, societal, commercial)
Scoring approach defines likelihood scales, impact scales, residual risk scoring, and aggregation methodology
Treatment options framework covers mitigate, transfer, accept, and avoid with selection criteria
Methodology is integrated with ISO 31000 risk management principles and ISO 23894 AI risk management guidance (per AIMS ISO TOC citation convention)
Methodology is communicated to AI risk owners, AI governance forums per GOV.GF, and AI decision-makers
Assessment criteria are defined per AI risk class per RSK.ME-02 (functional, legal, ethical, societal, commercial)
Scoring approach defines likelihood scales, impact scales, residual risk scoring, and aggregation methodology
Treatment options framework covers mitigate, transfer, accept, and avoid with selection criteria
Methodology is integrated with ISO 31000 risk management principles and ISO 23894 AI risk management guidance (per AIMS ISO TOC citation convention)
Methodology is communicated to AI risk owners, AI governance forums per GOV.GF, and AI decision-makers
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.1; Cl. 6.1.2; A.5.2
NIST AI RMF — GOVERN 1.3; GOVERN 1.4
EU AI Act — Art. 9
ISO/IEC 5338:2023 — Cl. 6.3.4
ISO 31000:2018 — Cl. 6
ISO/IEC 23894:2023 — Cl. 6
NIST AI RMF — GOVERN 1.3; GOVERN 1.4
EU AI Act — Art. 9
ISO/IEC 5338:2023 — Cl. 6.3.4
ISO 31000:2018 — Cl. 6
ISO/IEC 23894:2023 — Cl. 6
RSK.ME-02AI risk classes — covering functional, legal, ethical, societal, and commercial risk — are defined and applied to AI risk identification and assessmentT 7 · C 6 · F 6
Applies To
Functional risk class (performance, accuracy, robustness, safety)
Legal / regulatory risk class (EU AI Act compliance, GDPR, contractual)
Ethical risk class (fairness, bias, harm, autonomy)
Societal risk class (reputation, public perception, systemic effects)
Commercial risk class (financial, competitive, operational)
Cross-class consideration
Legal / regulatory risk class (EU AI Act compliance, GDPR, contractual)
Ethical risk class (fairness, bias, harm, autonomy)
Societal risk class (reputation, public perception, systemic effects)
Commercial risk class (financial, competitive, operational)
Cross-class consideration
Control Details
Five AI risk classes are defined: functional, legal, ethical, societal, commercial
Each class has documented sub-categories and scoring guidance
Risk classes are applied during risk identification per RSK.ID-01 and risk assessment per RSK.AS
Cross-class risk (e.g., a functional safety risk that also creates legal exposure) is handled through multi-class tagging
Class definitions are reviewed when material risk experience indicates additional risk types should be recognised
Each class has documented sub-categories and scoring guidance
Risk classes are applied during risk identification per RSK.ID-01 and risk assessment per RSK.AS
Cross-class risk (e.g., a functional safety risk that also creates legal exposure) is handled through multi-class tagging
Class definitions are reviewed when material risk experience indicates additional risk types should be recognised
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.1; Cl. 6.1.2; A.5.2
NIST AI RMF — MAP 5.1; GOVERN 1.3
EU AI Act — Art. 9
OECD AI Principles (OECD/LEGAL/0449)
ISO/IEC 5338:2023 — Cl. 6.3.4
EU AI Risks Management Guidance
NIST AI RMF — MAP 5.1; GOVERN 1.3
EU AI Act — Art. 9
OECD AI Principles (OECD/LEGAL/0449)
ISO/IEC 5338:2023 — Cl. 6.3.4
EU AI Risks Management Guidance
RSK.ME-03Role-specific methodology application — covering how the risk methodology is applied differently for provider, deployer, and internal-developer contexts — is documented and maintainedT 6 · C 6 · F 6
Applies To
Provider risk methodology application (product liability, customer harm, post-market obligations)
Deployer risk methodology application (operational risk, regulatory exposure from use)
Internal-developer risk methodology application (institutional risk, capability risk)
Role-specific risk class weights
Cross-role coordination for multi-role AI activities
Deployer risk methodology application (operational risk, regulatory exposure from use)
Internal-developer risk methodology application (institutional risk, capability risk)
Role-specific risk class weights
Cross-role coordination for multi-role AI activities
Control Details
Provider risk methodology application emphasises product liability, customer impact, downstream user harm, and post-market obligations
Deployer risk methodology application emphasises operational continuity, vendor dependency, and regulatory exposure from AI use
Internal-developer risk methodology application emphasises institutional capability, internal user impact, and IP / institutional knowledge
Role-specific weights for risk classes are documented (e.g., provider weights commercial risk more heavily)
Where a single AI activity involves multiple roles, risks are assessed per role with reconciliation through AI governance forums per GOV.GF
Deployer risk methodology application emphasises operational continuity, vendor dependency, and regulatory exposure from AI use
Internal-developer risk methodology application emphasises institutional capability, internal user impact, and IP / institutional knowledge
Role-specific weights for risk classes are documented (e.g., provider weights commercial risk more heavily)
Where a single AI activity involves multiple roles, risks are assessed per role with reconciliation through AI governance forums per GOV.GF
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.1; Cl. 6.1.2; A.5.2; A.10
NIST AI RMF — GOVERN 1.3; MAP 4.1
EU AI Act — Art. 9; Art. 16; Art. 26
ISO/IEC 5338:2023 — Cl. 6.3.4
NIST AI RMF — GOVERN 1.3; MAP 4.1
EU AI Act — Art. 9; Art. 16; Art. 26
ISO/IEC 5338:2023 — Cl. 6.3.4
RSK.ME-04AI risk management methodology review is performed at defined cadence and on material change, with methodology updates approved and communicatedT 6 · C 7 · F 6
Applies To
Review schedule (at minimum annually)
Material change triggers
Review participants
Methodology change approval
Communication of methodology updates
Material change triggers
Review participants
Methodology change approval
Communication of methodology updates
Control Details
The AI risk management methodology is reviewed at minimum annually
Ad-hoc review is triggered by material change (regulatory developments, AI risk landscape shifts, methodology effectiveness findings, material AI incident)
Review participants include AI risk owner, AI governance forums per GOV.GF, and accountable AI executive per GOV.RR-01
Methodology updates are approved at appropriate authority level per RSK.ME-01
Updates are communicated to AI risk users
Methodology version control is maintained
Ad-hoc review is triggered by material change (regulatory developments, AI risk landscape shifts, methodology effectiveness findings, material AI incident)
Review participants include AI risk owner, AI governance forums per GOV.GF, and accountable AI executive per GOV.RR-01
Methodology updates are approved at appropriate authority level per RSK.ME-01
Updates are communicated to AI risk users
Methodology version control is maintained
Control Mapping
ISO/IEC 42001:2023 — Cl. 9.3; Cl. 10
NIST AI RMF — GOVERN 1.5
EU AI Act — Art. 17(2)
ISO/IEC 5338:2023 — Cl. 6.3.4
NIST AI RMF — GOVERN 1.5
EU AI Act — Art. 17(2)
ISO/IEC 5338:2023 — Cl. 6.3.4
RSK.IDAI Risk Identification3 Controls
Description: AI risk identification — covering identification across all AI roles (provider, deployer, internal developer), risk sources (model behaviour, data, lifecycle, deployment context, third-party dependencies, agentic action, regulatory exposure, ethical concerns), identification techniques (threat modelling, risk workshops, incident review, horizon scanning), and identification triggers — is performed, documented, and maintained
RSK.ID-01AI risk identification process — covering techniques (threat modelling, risk workshops, incident review, horizon scanning) and risk sources — is documented and performedT 7 · C 6 · F 6
Applies To
Threat modelling per AI system
AI risk workshops with cross-functional participation
AI incident review and learning per LIF.IR
Horizon scanning for emerging AI risks
Risk sources covered (model behaviour, data, lifecycle, deployment context, third-party dependencies, agentic action, regulatory exposure, ethical concerns)
AI risk workshops with cross-functional participation
AI incident review and learning per LIF.IR
Horizon scanning for emerging AI risks
Risk sources covered (model behaviour, data, lifecycle, deployment context, third-party dependencies, agentic action, regulatory exposure, ethical concerns)
Control Details
AI risk identification uses multiple techniques to ensure comprehensive coverage
Threat modelling per AI system is performed per LIF.DE design and updated on material change; threat modelling references OWASP AISVS, MITRE ATLAS, ENISA Multilayer Framework for AI Cybersecurity, ENISA Securing Machine Learning Algorithms, and OWASP AI Testing Guide
AI risk workshops involve cross-functional participation (AI engineering, AI safety, AI ethics, Legal, Privacy, InfoSec) on a defined cadence
Incident review per LIF.IR feeds back into risk identification for learning
Horizon scanning identifies emerging AI risks from regulatory developments, threat intelligence, and AI capability advances
Risk sources covered span model behaviour, data, lifecycle, deployment context, third-party dependencies per TPA, agentic action per LIF.AG, regulatory exposure per CON.JU, and ethical concerns per GOV.ET
Threat modelling per AI system is performed per LIF.DE design and updated on material change; threat modelling references OWASP AISVS, MITRE ATLAS, ENISA Multilayer Framework for AI Cybersecurity, ENISA Securing Machine Learning Algorithms, and OWASP AI Testing Guide
AI risk workshops involve cross-functional participation (AI engineering, AI safety, AI ethics, Legal, Privacy, InfoSec) on a defined cadence
Incident review per LIF.IR feeds back into risk identification for learning
Horizon scanning identifies emerging AI risks from regulatory developments, threat intelligence, and AI capability advances
Risk sources covered span model behaviour, data, lifecycle, deployment context, third-party dependencies per TPA, agentic action per LIF.AG, regulatory exposure per CON.JU, and ethical concerns per GOV.ET
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.1; A.5.2
NIST AI RMF — MAP 5.1; MAP 4.1
EU AI Act — Art. 9(2)
ENISA Multilayer Framework for AI Cybersecurity
ISO/IEC 5338:2023 — Cl. 6.3.4
OWASP AISVS — C7; C9
OWASP AI Testing Guide — 3.0 Framework
MITRE ATLAS
NIST AI RMF — MAP 5.1; MAP 4.1
EU AI Act — Art. 9(2)
ENISA Multilayer Framework for AI Cybersecurity
ISO/IEC 5338:2023 — Cl. 6.3.4
OWASP AISVS — C7; C9
OWASP AI Testing Guide — 3.0 Framework
MITRE ATLAS
RSK.ID-02AI risk identification triggers — new AI system, material change, regulatory change, and incident learning — are defined and appliedT 6 · C 6 · F 6
Applies To
New AI system trigger
Material AI change trigger (capability uplift, scope expansion, autonomy uplift)
Regulatory change trigger
Incident learning trigger per LIF.IR
Near-miss trigger
Trigger documentation
Material AI change trigger (capability uplift, scope expansion, autonomy uplift)
Regulatory change trigger
Incident learning trigger per LIF.IR
Near-miss trigger
Trigger documentation
Control Details
Risk identification triggers are documented to ensure timely identification of emerging risks
New AI system deployment per GOV.RR-03 triggers risk identification before go-live
Material AI change (capability uplift, scope expansion, autonomy uplift, integration with new data sources) triggers re-identification
Regulatory change (EU AI Act amendments, new guidance, new sectoral requirements) triggers risk identification across affected AI
AI incident learning per LIF.IR triggers identification of similar latent risks across the AI portfolio
Near-miss reporting per GOV.RR-05 also triggers risk identification
Trigger application is reviewed at defined cadence
New AI system deployment per GOV.RR-03 triggers risk identification before go-live
Material AI change (capability uplift, scope expansion, autonomy uplift, integration with new data sources) triggers re-identification
Regulatory change (EU AI Act amendments, new guidance, new sectoral requirements) triggers risk identification across affected AI
AI incident learning per LIF.IR triggers identification of similar latent risks across the AI portfolio
Near-miss reporting per GOV.RR-05 also triggers risk identification
Trigger application is reviewed at defined cadence
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.1; A.5.2
NIST AI RMF — MAP 5.1; GOVERN 1.5
EU AI Act — Art. 9(2); Art. 72
ISO/IEC 5338:2023 — Cl. 6.3.4
NIST AI RMF — MAP 5.1; GOVERN 1.5
EU AI Act — Art. 9(2); Art. 72
ISO/IEC 5338:2023 — Cl. 6.3.4
RSK.ID-03Role-specific AI risk identification — addressing risks specific to provider, deployer, and internal-developer contexts — is performed with role-appropriate methodsT 6 · C 6 · F 6
Applies To
Provider risk identification (product liability, customer harm, downstream impact)
Deployer risk identification (operational continuity, vendor risk, use restrictions, monitoring obligations)
Internal-developer risk identification (institutional capability, internal user harm)
Cross-role risk identification for multi-role AI
Deployer risk identification (operational continuity, vendor risk, use restrictions, monitoring obligations)
Internal-developer risk identification (institutional capability, internal user harm)
Cross-role risk identification for multi-role AI
Control Details
Provider risk identification covers product liability exposure, customer harm scenarios, downstream end-user impact, contractual obligations, post-market obligations per Art. 26 frame, and GPAI provider obligations per Art. 53
Deployer risk identification covers operational continuity from vendor dependency, vendor change risk, use-per-provider-instructions compliance per Art. 26(1), monitoring obligations per Art. 26(5)
Internal-developer risk identification covers institutional capability gaps, internal user productivity impact, IP exposure, internal AI failure modes
Where a single AI activity involves multiple roles, cross-role risk identification is coordinated through AI governance forums per GOV.GF
Deployer risk identification covers operational continuity from vendor dependency, vendor change risk, use-per-provider-instructions compliance per Art. 26(1), monitoring obligations per Art. 26(5)
Internal-developer risk identification covers institutional capability gaps, internal user productivity impact, IP exposure, internal AI failure modes
Where a single AI activity involves multiple roles, cross-role risk identification is coordinated through AI governance forums per GOV.GF
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.1; A.10
NIST AI RMF — MAP 4.1; MAP 4.2
EU AI Act — Art. 9; Art. 16; Art. 26; Art. 53
ISO/IEC 5338:2023 — Cl. 6.3.4
NIST AI RMF — MAP 4.1; MAP 4.2
EU AI Act — Art. 9; Art. 16; Art. 26; Art. 53
ISO/IEC 5338:2023 — Cl. 6.3.4
RSK.ASAI Risk Assessment3 Controls
Description: AI risk assessment — covering inherent and residual risk assessment per AI system, portfolio-level aggregated assessment, likelihood and impact scoring per methodology, classification per defined risk classes, documentation of assessment rationale, and assessment cadence and triggers — is performed, documented, and maintained
RSK.AS-01Per-AI-system risk assessment — covering inherent and residual risk scoring per the methodology — is performed and documented for each AI in scopeT 6 · C 6 · F 6
Applies To
Per-AI inherent risk assessment (before Controls applied)
Per-AI residual risk assessment (after Controls applied)
Likelihood and impact scoring per risk class
Per-AI risk register entries per RSK.RG-01
Assessment cadence per AI criticality
Per-AI residual risk assessment (after Controls applied)
Likelihood and impact scoring per risk class
Per-AI risk register entries per RSK.RG-01
Assessment cadence per AI criticality
Control Details
For each AI system per CON.IN inventory, inherent risk assessment is performed using the methodology per RSK.ME
Inherent assessment evaluates risk before Controls are applied, using likelihood and impact scoring per risk class
Residual assessment is performed after Controls are applied, with the Control effectiveness explicitly considered
Assessment results are recorded in the AI risk register per RSK.RG-01
Assessment cadence is defined per AI criticality (more frequent for business-critical AI; at minimum annually for all)
Assessment evidence is auditable
Inherent assessment evaluates risk before Controls are applied, using likelihood and impact scoring per risk class
Residual assessment is performed after Controls are applied, with the Control effectiveness explicitly considered
Assessment results are recorded in the AI risk register per RSK.RG-01
Assessment cadence is defined per AI criticality (more frequent for business-critical AI; at minimum annually for all)
Assessment evidence is auditable
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.1; Cl. 6.1.2; Cl. 8.2; A.5.2
NIST AI RMF — MAP 5.1; MEASURE 1.1
EU AI Act — Art. 9(2)
ISO/IEC 5338:2023 — Cl. 6.3.4
ISO/IEC 23894:2023 — Cl. 7
ISO 31000:2018 — Cl. 6.4
NIST AI RMF — MAP 5.1; MEASURE 1.1
EU AI Act — Art. 9(2)
ISO/IEC 5338:2023 — Cl. 6.3.4
ISO/IEC 23894:2023 — Cl. 7
ISO 31000:2018 — Cl. 6.4
RSK.AS-02Portfolio-level AI risk assessment — aggregating per-AI risks across the AI inventory to identify concentration, systemic, and cross-cutting risks — is performed and reportedT 7 · C 5 · F 6
Applies To
Portfolio aggregation methodology
Risk concentration analysis (by risk class, by Domain, by AI role)
Systemic risk identification
Cross-cutting risk identification (e.g., shared foundation model dependency, shared agentic infrastructure)
Portfolio reporting
Risk concentration analysis (by risk class, by Domain, by AI role)
Systemic risk identification
Cross-cutting risk identification (e.g., shared foundation model dependency, shared agentic infrastructure)
Portfolio reporting
Control Details
Portfolio-level assessment aggregates per-AI assessments per RSK.AS-01 to identify portfolio-wide risk patterns
Risk concentration analysis identifies excessive concentration per risk class, AI role, or Domain
Systemic risk identification considers risks that affect multiple AI systems simultaneously (e.g., a foundation model issue affecting all derived products, a multi-agent platform issue affecting all agents)
Cross-cutting risks are identified (shared dependencies, shared data sources, shared infrastructure)
Portfolio risk reporting feeds AI governance forums per GOV.GF and management review per GOV.OV-05
Portfolio assessment cadence is at minimum quarterly
Risk concentration analysis identifies excessive concentration per risk class, AI role, or Domain
Systemic risk identification considers risks that affect multiple AI systems simultaneously (e.g., a foundation model issue affecting all derived products, a multi-agent platform issue affecting all agents)
Cross-cutting risks are identified (shared dependencies, shared data sources, shared infrastructure)
Portfolio risk reporting feeds AI governance forums per GOV.GF and management review per GOV.OV-05
Portfolio assessment cadence is at minimum quarterly
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.1; Cl. 6.1.2
NIST AI RMF — MAP 5.1; MEASURE 1.1
EU AI Act — Art. 9(7)
ISO/IEC 5338:2023 — Cl. 6.3.4
ISO 31000:2018 — Cl. 6.4
NIST AI RMF — MAP 5.1; MEASURE 1.1
EU AI Act — Art. 9(7)
ISO/IEC 5338:2023 — Cl. 6.3.4
ISO 31000:2018 — Cl. 6.4
RSK.AS-03AI risk assessment cadence and triggers — covering periodic, material-change, and post-incident reassessment — are defined and appliedT 6 · C 6 · F 6
Applies To
Periodic assessment cadence per AI criticality
Material change triggers (AI capability change, scope change, context change)
Post-incident reassessment per LIF.IR
Reassessment after Control change
Trigger application and verification
Material change triggers (AI capability change, scope change, context change)
Post-incident reassessment per LIF.IR
Reassessment after Control change
Trigger application and verification
Control Details
Periodic assessment cadence is defined per AI criticality: business-critical AI at minimum quarterly; standard AI at minimum semi-annually; low-criticality AI at minimum annually
Material change triggers (AI capability uplift, scope expansion, autonomy uplift, integration change) trigger reassessment within defined timeline
Post-incident reassessment is triggered after material AI incidents per LIF.IR
Reassessment after Control change verifies residual risk is updated
Trigger application is verified during AI governance reviews per GOV.GF
Overdue assessments are flagged and escalated
Material change triggers (AI capability uplift, scope expansion, autonomy uplift, integration change) trigger reassessment within defined timeline
Post-incident reassessment is triggered after material AI incidents per LIF.IR
Reassessment after Control change verifies residual risk is updated
Trigger application is verified during AI governance reviews per GOV.GF
Overdue assessments are flagged and escalated
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.1; Cl. 6.1.2; Cl. 8.2; Cl. 9.3
NIST AI RMF — MAP 5.1; GOVERN 1.5
EU AI Act — Art. 9(2)(c); Art. 72
ISO/IEC 5338:2023 — Cl. 6.3.4
NIST AI RMF — MAP 5.1; GOVERN 1.5
EU AI Act — Art. 9(2)(c); Art. 72
ISO/IEC 5338:2023 — Cl. 6.3.4
RSK.TRAI Risk Treatment and Acceptance3 Controls
Description: AI risk treatment and acceptance — covering treatment options (mitigate, transfer, accept, avoid), treatment selection per risk appetite and role context (provider, deployer, internal developer), implementation tracking, residual risk acceptance authority and documentation, and treatment effectiveness verification — are determined, documented, and authorised
RSK.TR-01AI risk treatment selection and implementation — applying mitigate / transfer / accept / avoid options per risk appetite and role context — are determined, documented, and tracked to completion; the Statement of Applicability (SoA) is produced as the outputT 6 · C 6 · F 6
Applies To
Treatment option selection per risk
Treatment selection criteria (cost-benefit, effectiveness, appetite alignment, role context)
Treatment implementation tracking
Treatment dependencies (Control implementation, vendor change, policy adjustment)
Per-role treatment considerations
Statement of Applicability (SoA) — listing applicable AI controls, justification for inclusion, implementation status, and justification for any Annex A exclusion
Treatment selection criteria (cost-benefit, effectiveness, appetite alignment, role context)
Treatment implementation tracking
Treatment dependencies (Control implementation, vendor change, policy adjustment)
Per-role treatment considerations
Statement of Applicability (SoA) — listing applicable AI controls, justification for inclusion, implementation status, and justification for any Annex A exclusion
Control Details
Treatment selection is performed per identified AI risk, considering mitigate / transfer / accept / avoid options
Selection criteria include cost-benefit, effectiveness against the risk, alignment with AI risk appetite per GOV.RA, and role-specific context per RSK.ME-03 (provider, deployer, internal-developer)
Selected treatments are documented with rationale, target outcomes, and target dates
Treatment implementation is tracked through dependencies (Control implementation, vendor change, policy adjustment)
Treatment effectiveness is verified per RSK.TR-03 after implementation
Treatment decisions feed AI governance forum reporting per GOV.GF
The Statement of Applicability (SoA) is produced as the output of treatment selection, listing necessary AI controls, the applicability decision (in / out) per Annex A control, justification for inclusions, implementation status, and justification for excluding any Annex A control; the SoA is maintained as a controlled document per GOV.DI-01
Selection criteria include cost-benefit, effectiveness against the risk, alignment with AI risk appetite per GOV.RA, and role-specific context per RSK.ME-03 (provider, deployer, internal-developer)
Selected treatments are documented with rationale, target outcomes, and target dates
Treatment implementation is tracked through dependencies (Control implementation, vendor change, policy adjustment)
Treatment effectiveness is verified per RSK.TR-03 after implementation
Treatment decisions feed AI governance forum reporting per GOV.GF
The Statement of Applicability (SoA) is produced as the output of treatment selection, listing necessary AI controls, the applicability decision (in / out) per Annex A control, justification for inclusions, implementation status, and justification for excluding any Annex A control; the SoA is maintained as a controlled document per GOV.DI-01
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.1; Cl. 6.1.3; Cl. 8.3; A.5.2
NIST AI RMF — MANAGE 1.2; MANAGE 1.3
EU AI Act — Art. 9(4); Art. 9(5)
ISO/IEC 5338:2023 — Cl. 6.3.4
ISO 31000:2018 — Cl. 6.5
ISO/IEC 23894:2023 — Cl. 8
NIST AI RMF — MANAGE 1.2; MANAGE 1.3
EU AI Act — Art. 9(4); Art. 9(5)
ISO/IEC 5338:2023 — Cl. 6.3.4
ISO 31000:2018 — Cl. 6.5
ISO/IEC 23894:2023 — Cl. 8
RSK.TR-02Residual risk acceptance — covering acceptance authority per risk level, documentation requirements, time-bound acceptance, and Statement of Applicability approval — is established and appliedT 6 · C 5 · F 6
Applies To
Acceptance authority per risk level (within appetite vs above appetite)
Acceptance documentation (rationale, alternatives, mitigations applied)
Time-bound acceptance with review trigger
Acceptance reporting
Above-appetite acceptance escalation
Statement of Applicability (SoA) approval as part of risk treatment plan approval
Acceptance documentation (rationale, alternatives, mitigations applied)
Time-bound acceptance with review trigger
Acceptance reporting
Above-appetite acceptance escalation
Statement of Applicability (SoA) approval as part of risk treatment plan approval
Control Details
Residual risk acceptance authority is defined per risk level — within-appetite acceptance per local authority; above-appetite acceptance per AI governance forum per GOV.GF or top management
Acceptance documentation includes rationale, alternatives considered, mitigations applied per RSK.TR-01, and acceptance authority
Acceptance is time-bound with review trigger (typically annual or on material change)
Acceptance decisions are reported per GOV.OV-04
Above-appetite acceptance is explicitly flagged and tracked separately
Approval of the Statement of Applicability (SoA) per RSK.TR-01 is treated as a formal risk-treatment-plan approval event, recorded with rationale, approving authority, and version; SoA approval is renewed alongside residual risk reviews
Acceptance documentation includes rationale, alternatives considered, mitigations applied per RSK.TR-01, and acceptance authority
Acceptance is time-bound with review trigger (typically annual or on material change)
Acceptance decisions are reported per GOV.OV-04
Above-appetite acceptance is explicitly flagged and tracked separately
Approval of the Statement of Applicability (SoA) per RSK.TR-01 is treated as a formal risk-treatment-plan approval event, recorded with rationale, approving authority, and version; SoA approval is renewed alongside residual risk reviews
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.1; Cl. 6.1.3; Cl. 8
NIST AI RMF — MANAGE 1.4
EU AI Act — Art. 9(5)
ISO/IEC 5338:2023 — Cl. 6.3.4
ISO 31000:2018 — Cl. 6.5
NIST AI RMF — MANAGE 1.4
EU AI Act — Art. 9(5)
ISO/IEC 5338:2023 — Cl. 6.3.4
ISO 31000:2018 — Cl. 6.5
RSK.TR-03Treatment effectiveness verification — confirming that implemented treatments deliver the intended residual risk reduction, and updating the Statement of Applicability where verification findings warrant — is performed and documentedT 6 · C 5 · F 6
Applies To
Verification methodology per treatment type
Verification timing (after implementation; periodic re-verification)
Effectiveness criteria
Verification record-keeping
Treatment adjustment based on findings
Statement of Applicability (SoA) update on material verification finding
Verification timing (after implementation; periodic re-verification)
Effectiveness criteria
Verification record-keeping
Treatment adjustment based on findings
Statement of Applicability (SoA) update on material verification finding
Control Details
Treatment effectiveness verification is performed after treatment implementation to confirm intended residual risk reduction
Verification methodology is defined per treatment type (Control verification, residual risk reassessment, vendor change verification)
Verification timing includes initial post-implementation and periodic re-verification (typically annual)
Effectiveness criteria are defined per treatment with measurable outcomes
Verification records are maintained and feed AI governance forum reporting per GOV.GF
Where effectiveness falls short, treatment is adjusted or escalated; where verification findings reveal that applied controls do not deliver intended residual risk reduction or that previously-excluded Annex A controls have become relevant, the Statement of Applicability (SoA) per RSK.TR-01 is reviewed and updated, with re-approval per RSK.TR-02
Verification methodology is defined per treatment type (Control verification, residual risk reassessment, vendor change verification)
Verification timing includes initial post-implementation and periodic re-verification (typically annual)
Effectiveness criteria are defined per treatment with measurable outcomes
Verification records are maintained and feed AI governance forum reporting per GOV.GF
Where effectiveness falls short, treatment is adjusted or escalated; where verification findings reveal that applied controls do not deliver intended residual risk reduction or that previously-excluded Annex A controls have become relevant, the Statement of Applicability (SoA) per RSK.TR-01 is reviewed and updated, with re-approval per RSK.TR-02
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.1; Cl. 6.1.3; Cl. 9.1
NIST AI RMF — MEASURE 1.2; MANAGE 4.2
EU AI Act — Art. 9(7); Art. 9(8)
ISO/IEC 5338:2023 — Cl. 6.3.4
NIST AI RMF — MEASURE 1.2; MANAGE 4.2
EU AI Act — Art. 9(7); Art. 9(8)
ISO/IEC 5338:2023 — Cl. 6.3.4
RSK.RGAI Risk Register and Reporting3 Controls
Description: The AI risk register and AI risk reporting — covering the AI risk register as the system of record for identified AI risks, register entries (identification, assessment, treatment, owner, status, dates), reporting to AI governance forums and board on AI risk posture, aggregated reporting (top risks, trend analysis, concentration), and integration with enterprise risk reporting — are established, maintained, and used
RSK.RG-01The AI risk register — the system of record for identified AI risks — is maintained with structured entries, ownership, and lifecycle statusT 6 · C 6 · F 6
Applies To
Register structure (per-risk entries with full lifecycle)
Risk identification, assessment, treatment, and acceptance data
Risk owner per entry
Risk lifecycle status (identified, assessed, treated, accepted, closed)
Register access governance
Risk identification, assessment, treatment, and acceptance data
Risk owner per entry
Risk lifecycle status (identified, assessed, treated, accepted, closed)
Register access governance
Control Details
The AI risk register is documented as the system of record for AI risks
Per-risk entries include identification details, inherent and residual assessment per RSK.AS, applied treatments per RSK.TR-01, acceptance per RSK.TR-02, owner, target dates, and lifecycle status
Risk owner is assigned per entry with accountability for treatment progress and assessment maintenance
Register access governance ensures appropriate confidentiality while supporting AI governance forums per GOV.GF, AI risk owners, and audit per GOV.OV-03
Register is maintained continuously as risks are identified, assessed, treated, and closed
Register integration with broader enterprise risk register is maintained where applicable
Per-risk entries include identification details, inherent and residual assessment per RSK.AS, applied treatments per RSK.TR-01, acceptance per RSK.TR-02, owner, target dates, and lifecycle status
Risk owner is assigned per entry with accountability for treatment progress and assessment maintenance
Register access governance ensures appropriate confidentiality while supporting AI governance forums per GOV.GF, AI risk owners, and audit per GOV.OV-03
Register is maintained continuously as risks are identified, assessed, treated, and closed
Register integration with broader enterprise risk register is maintained where applicable
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.1; Cl. 8.1; Cl. 8.2; A.5.2
NIST AI RMF — MEASURE 3.1; MAP 5.1
EU AI Act — Art. 9(4)
ISO/IEC 5338:2023 — Cl. 6.3.4
ISO 31000:2018 — Cl. 6.6
NIST AI RMF — MEASURE 3.1; MAP 5.1
EU AI Act — Art. 9(4)
ISO/IEC 5338:2023 — Cl. 6.3.4
ISO 31000:2018 — Cl. 6.6
RSK.RG-02AI risk reporting — covering risk posture reporting to AI governance forums and board with defined cadence and content — is established and performedT 6 · C 5 · F 6
Applies To
Reporting to AI governance forums per GOV.GF
Reporting to board and top management per GOV.OV-04
Reporting content (top risks, residual posture, treatment progress, trends, above-appetite acceptances)
Reporting cadence per audience
Ad-hoc escalation
Reporting to board and top management per GOV.OV-04
Reporting content (top risks, residual posture, treatment progress, trends, above-appetite acceptances)
Reporting cadence per audience
Ad-hoc escalation
Control Details
AI risk reporting to AI governance forums per GOV.GF occurs at defined cadence (typically monthly for operational committee, quarterly for executive)
AI risk reporting to board occurs at minimum quarterly per GOV.OV-04
Reporting content includes top inherent and residual risks, trend analysis, treatment progress per RSK.TR, above-appetite acceptances, emerging risks per RSK.MO-03
Ad-hoc escalation occurs for material risk crystallisation, material new risk identification, or material above-appetite acceptance
Reporting effectiveness is reviewed to ensure governance forums can act on the information
AI risk reporting to board occurs at minimum quarterly per GOV.OV-04
Reporting content includes top inherent and residual risks, trend analysis, treatment progress per RSK.TR, above-appetite acceptances, emerging risks per RSK.MO-03
Ad-hoc escalation occurs for material risk crystallisation, material new risk identification, or material above-appetite acceptance
Reporting effectiveness is reviewed to ensure governance forums can act on the information
Control Mapping
ISO/IEC 42001:2023 — Cl. 9.1; Cl. 9.3
NIST AI RMF — GOVERN 2.3; MEASURE 3.1
EU AI Act — Art. 17(2)(g)
ISO/IEC 5338:2023 — Cl. 6.3.4
ISO 31000:2018 — Cl. 6.6
NIST AI RMF — GOVERN 2.3; MEASURE 3.1
EU AI Act — Art. 17(2)(g)
ISO/IEC 5338:2023 — Cl. 6.3.4
ISO 31000:2018 — Cl. 6.6
RSK.RG-03Integration of AI risk reporting with enterprise risk reporting — ensuring AI risks are visible in enterprise-wide risk views and aligned to enterprise risk methodology — is established and maintainedT 6 · C 6 · F 6
Applies To
Enterprise risk reporting linkage
Methodology alignment (where appropriate)
AI risk visibility in enterprise risk views
AI risk concentration consideration in enterprise risk
Reporting cadence alignment
Methodology alignment (where appropriate)
AI risk visibility in enterprise risk views
AI risk concentration consideration in enterprise risk
Reporting cadence alignment
Control Details
AI risk reporting integrates with enterprise risk reporting so material AI risks appear in enterprise-wide risk views
Methodology alignment per RSK.ME-01 ensures AI risk scoring is interpretable alongside other enterprise risk types
Material AI risks above defined thresholds are escalated into enterprise risk reporting
AI risk concentration is considered in enterprise risk posture (e.g., shared foundation model dependency as a systemic factor)
Reporting cadence aligns with enterprise risk reporting cycles
Integration is reviewed when enterprise risk reporting or AI risk methodology materially changes
Methodology alignment per RSK.ME-01 ensures AI risk scoring is interpretable alongside other enterprise risk types
Material AI risks above defined thresholds are escalated into enterprise risk reporting
AI risk concentration is considered in enterprise risk posture (e.g., shared foundation model dependency as a systemic factor)
Reporting cadence aligns with enterprise risk reporting cycles
Integration is reviewed when enterprise risk reporting or AI risk methodology materially changes
Control Mapping
ISO/IEC 42001:2023 — Cl. 9.1
NIST AI RMF — MEASURE 3.1; GOVERN 2.3
ISO 31000:2018 — Cl. 5.4
ISO/IEC 5338:2023 — Cl. 6.3.4
NIST AI RMF — MEASURE 3.1; GOVERN 2.3
ISO 31000:2018 — Cl. 5.4
ISO/IEC 5338:2023 — Cl. 6.3.4
RSK.ARAdversarial AI Risk Management4 Controls
Description: Adversarial AI risk management — covering adversarial threat modelling per AI system, model-layer and data-layer risks (evasion, extraction, inversion, poisoning), prompt-layer and agentic risks (prompt injection direct and indirect, tool misuse, goal hijack, multi-agent collusion), AI supply chain attack risks, and red teaming and adversarial testing — is performed, documented, and maintained
RSK.AR-01Adversarial AI threat modelling — performed per AI system using established taxonomies — is performed at design and updated on material changeT 7 · C 6 · F 6
Applies To
Threat modelling per AI system per LIF.DE
Threat taxonomies (NIST AI 100-2, OWASP AISVS, MITRE ATLAS, OWASP Top 10 LLM / Agentic)
Adversarial threat categorisation
Threat model maintenance
Threat model integration with risk assessment per RSK.AS
Threat taxonomies (NIST AI 100-2, OWASP AISVS, MITRE ATLAS, OWASP Top 10 LLM / Agentic)
Adversarial threat categorisation
Threat model maintenance
Threat model integration with risk assessment per RSK.AS
Control Details
Adversarial threat modelling is performed per AI system as part of design per LIF.DE-04
Threat taxonomies leveraged include NIST AI 100-2 (Adversarial Machine Learning Taxonomy), OWASP AISVS Control 11 (Adversarial Robustness), MITRE ATLAS tactics and techniques, OWASP Top 10 LLM, OWASP Top 10 for Agentic Apps, and OWASP Multi-Agentic System Threat Modelling Guide
Per-system threat model categorises adversarial threats by attack surface (training, model, inference, prompt, tool, agent)
Threat models are maintained — updated when system capability, deployment context, or threat landscape materially changes
Threat model outputs feed adversarial risk assessment per RSK.AS-01 and treatment per RSK.TR
Threat taxonomies leveraged include NIST AI 100-2 (Adversarial Machine Learning Taxonomy), OWASP AISVS Control 11 (Adversarial Robustness), MITRE ATLAS tactics and techniques, OWASP Top 10 LLM, OWASP Top 10 for Agentic Apps, and OWASP Multi-Agentic System Threat Modelling Guide
Per-system threat model categorises adversarial threats by attack surface (training, model, inference, prompt, tool, agent)
Threat models are maintained — updated when system capability, deployment context, or threat landscape materially changes
Threat model outputs feed adversarial risk assessment per RSK.AS-01 and treatment per RSK.TR
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.1; A.5.2
NIST AI RMF — MAP 5.1; MEASURE 2.7
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Design
ISO/IEC 5338:2023 — Cl. 6.3.4
NIST AI 100-2 (Adversarial Machine Learning Taxonomy)
OWASP AISVS — C11
OWASP Top 10 LLM
OWASP Top 10 for Agentic Apps
OWASP Multi-Agentic System Threat Modelling Guide
MITRE ATLAS
NIST AI RMF — MAP 5.1; MEASURE 2.7
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Design
ISO/IEC 5338:2023 — Cl. 6.3.4
NIST AI 100-2 (Adversarial Machine Learning Taxonomy)
OWASP AISVS — C11
OWASP Top 10 LLM
OWASP Top 10 for Agentic Apps
OWASP Multi-Agentic System Threat Modelling Guide
MITRE ATLAS
RSK.AR-02Model-layer and data-layer adversarial risks — covering evasion, extraction, inversion, and data poisoning — are identified, assessed, and treatedT 6 · C 7 · F 6
Applies To
Evasion attacks (test-time perturbations)
Model extraction (model stealing via API)
Model inversion (training data inference)
Data poisoning (training, fine-tuning, RAG corpus)
Backdoor attacks
Per-AI assessment and treatment
Model extraction (model stealing via API)
Model inversion (training data inference)
Data poisoning (training, fine-tuning, RAG corpus)
Backdoor attacks
Per-AI assessment and treatment
Control Details
Model-layer adversarial risks per NIST AI 100-2 taxonomy are identified per AI system
Evasion attack risk is assessed considering input control surface and model's adversarial robustness per TRU.RB
Model extraction risk is assessed considering API exposure and query rate limits
Model inversion risk is assessed considering output exposure of training data per DAT.LK
Data poisoning risk is assessed for training, fine-tuning, and RAG corpus stages per DAT.PR
Backdoor attack risk is assessed for AI built with third-party components per TPA
Treatments include adversarial training, query monitoring, output filtering, data provenance verification, and model artefact integrity per LIF.DV-05
Evasion attack risk is assessed considering input control surface and model's adversarial robustness per TRU.RB
Model extraction risk is assessed considering API exposure and query rate limits
Model inversion risk is assessed considering output exposure of training data per DAT.LK
Data poisoning risk is assessed for training, fine-tuning, and RAG corpus stages per DAT.PR
Backdoor attack risk is assessed for AI built with third-party components per TPA
Treatments include adversarial training, query monitoring, output filtering, data provenance verification, and model artefact integrity per LIF.DV-05
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.1; A.5.2
NIST AI RMF — MEASURE 2.7; MAP 5.1
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Design
ISO/IEC 5338:2023 — Cl. 6.3.4
NIST AI 100-2 (Adversarial Machine Learning Taxonomy)
OWASP AISVS — C11; C1
OWASP Top 10 LLM
MITRE ATLAS
NIST AI RMF — MEASURE 2.7; MAP 5.1
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Design
ISO/IEC 5338:2023 — Cl. 6.3.4
NIST AI 100-2 (Adversarial Machine Learning Taxonomy)
OWASP AISVS — C11; C1
OWASP Top 10 LLM
MITRE ATLAS
RSK.AR-03Prompt-layer and agentic adversarial risks — covering prompt injection (direct and indirect), tool misuse, goal hijack, and multi-agent collusion — are identified, assessed, and treatedT 7 · C 5 · F 6
Applies To
Direct prompt injection
Indirect prompt injection (via tool outputs, RAG content)
Tool misuse and capability abuse
Goal hijack (agent diverted from intended objective)
Multi-agent collusion or cascading manipulation
MCP-layer adversarial risks
Indirect prompt injection (via tool outputs, RAG content)
Tool misuse and capability abuse
Goal hijack (agent diverted from intended objective)
Multi-agent collusion or cascading manipulation
MCP-layer adversarial risks
Control Details
Prompt-layer and agentic adversarial risks are identified per AI system per RSK.AR-01 with specific focus on agentic deployment given multi-agent context
Direct prompt injection risk is assessed considering user input controls and prompt isolation
Indirect prompt injection risk (via tool outputs, RAG content, agent-to-agent messages) is assessed considering all content paths into agent context
Tool misuse risk is assessed considering tool authorisation scope per LIF.AG-02
Goal hijack risk is assessed considering agent objective specification and runtime monitoring per LIF.OP
Multi-agent collusion / cascading manipulation risks are assessed per OWASP Multi-Agentic Threat Modelling Guide
MCP-layer risks per OWASP Top 10 MCP are assessed for MCP integrations
Treatments include input sanitisation, prompt boundary enforcement, action sandboxing, multi-agent containment per LIF.AG
Direct prompt injection risk is assessed considering user input controls and prompt isolation
Indirect prompt injection risk (via tool outputs, RAG content, agent-to-agent messages) is assessed considering all content paths into agent context
Tool misuse risk is assessed considering tool authorisation scope per LIF.AG-02
Goal hijack risk is assessed considering agent objective specification and runtime monitoring per LIF.OP
Multi-agent collusion / cascading manipulation risks are assessed per OWASP Multi-Agentic Threat Modelling Guide
MCP-layer risks per OWASP Top 10 MCP are assessed for MCP integrations
Treatments include input sanitisation, prompt boundary enforcement, action sandboxing, multi-agent containment per LIF.AG
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.1; A.5.2
NIST AI RMF — MEASURE 2.7; MAP 5.1
ISO/IEC 5338:2023 — Cl. 6.3.4
NIST AI 100-2 (Adversarial Machine Learning Taxonomy)
OWASP AISVS — C9; C11
OWASP Top 10 LLM
OWASP Top 10 for Agentic Apps
OWASP Top 10 MCP
OWASP Multi-Agentic System Threat Modelling Guide
MITRE ATLAS
NIST AI RMF — MEASURE 2.7; MAP 5.1
ISO/IEC 5338:2023 — Cl. 6.3.4
NIST AI 100-2 (Adversarial Machine Learning Taxonomy)
OWASP AISVS — C9; C11
OWASP Top 10 LLM
OWASP Top 10 for Agentic Apps
OWASP Top 10 MCP
OWASP Multi-Agentic System Threat Modelling Guide
MITRE ATLAS
RSK.AR-04AI red teaming and adversarial testing programme — covering scope, frequency, methodology, and findings management — is established and operatedT 7 · C 6 · F 6
Applies To
Red teaming scope per AI system class
Adversarial testing methodology per NIST AI 100-2 and CSA Agentic Red Teaming Guide
Red team independence per GOV.RR-04
Findings management and treatment per RSK.TR
Red team programme cadence
Specialised testing for foundation models (Art. 55 systemic-risk GPAI) and agentic systems
Adversarial testing methodology per NIST AI 100-2 and CSA Agentic Red Teaming Guide
Red team independence per GOV.RR-04
Findings management and treatment per RSK.TR
Red team programme cadence
Specialised testing for foundation models (Art. 55 systemic-risk GPAI) and agentic systems
Control Details
The AI red teaming programme is documented with scope, methodology, and cadence
Scope per AI system class is defined — comprehensive red teaming for foundation models with systemic risk per CON.JU-03 (per Art. 55), targeted testing for limited-risk AI products, agent-specific red teaming per CSA Agentic Red Teaming Guide
Methodology covers adversarial techniques from NIST AI 100-2 (evasion, extraction, inversion, poisoning), OWASP Top 10 LLM / Agentic / MCP attack patterns, and capability-elicitation testing per OWASP GenAI Red Teaming Guide
Red team independence is maintained per GOV.RR-04 (separation from AI development)
Findings are documented with severity and treatment recommendation, feeding RSK.TR
Red team programme cadence is defined per AI criticality (more frequent for systemic-risk GPAI)
Specialised testing for agentic systems covers multi-agent collusion, tool misuse cascades, and goal hijack scenarios
Scope per AI system class is defined — comprehensive red teaming for foundation models with systemic risk per CON.JU-03 (per Art. 55), targeted testing for limited-risk AI products, agent-specific red teaming per CSA Agentic Red Teaming Guide
Methodology covers adversarial techniques from NIST AI 100-2 (evasion, extraction, inversion, poisoning), OWASP Top 10 LLM / Agentic / MCP attack patterns, and capability-elicitation testing per OWASP GenAI Red Teaming Guide
Red team independence is maintained per GOV.RR-04 (separation from AI development)
Findings are documented with severity and treatment recommendation, feeding RSK.TR
Red team programme cadence is defined per AI criticality (more frequent for systemic-risk GPAI)
Specialised testing for agentic systems covers multi-agent collusion, tool misuse cascades, and goal hijack scenarios
Control Mapping
ISO/IEC 42001:2023 — Cl. 9.1; A.6.2
NIST AI RMF — MEASURE 2.7; MEASURE 1.3
EU AI Act — Art. 55
EU GPAI Code of Practice (Safety and Security Chapter)
ISO/IEC 5338:2023 — Cl. 6.3.4
OWASP AISVS — C11
OWASP GenAI Red Teaming Guide
MITRE ATLAS
CSA Agentic AI Red Teaming Guide
NIST AI RMF — MEASURE 2.7; MEASURE 1.3
EU AI Act — Art. 55
EU GPAI Code of Practice (Safety and Security Chapter)
ISO/IEC 5338:2023 — Cl. 6.3.4
OWASP AISVS — C11
OWASP GenAI Red Teaming Guide
MITRE ATLAS
CSA Agentic AI Red Teaming Guide
RSK.MOAI Risk Monitoring and Reassessment3 Controls
Description: AI risk monitoring and reassessment — covering ongoing monitoring of AI key risk indicators, reassessment triggers (material change, post-incident, periodic), emerging risk identification, risk trend analysis, and reporting — are performed, documented, and used to drive treatment updates
RSK.MO-01AI key risk indicators — defined to detect emerging risk and indicate risk posture trends — are monitored on defined cadenceT 7 · C 6 · F 6
Applies To
AI KRI definition per risk class
KRI measurement and reporting cadence
KRI thresholds and breach detection
KRI owner per indicator
KRI integration with AIMS KPIs / KRIs per GOV.OV-01
KRI measurement and reporting cadence
KRI thresholds and breach detection
KRI owner per indicator
KRI integration with AIMS KPIs / KRIs per GOV.OV-01
Control Details
AI key risk indicators are defined to detect emerging risk and indicate risk posture trends per risk class
KRIs cover residual-risk-above-appetite count, AI incident rate per LIF.IR, near-miss rate per GOV.RR-05, Control effectiveness indicators per RSK.TR-03, regulatory exposure indicators per CON.JU
KRI measurement and reporting cadence is defined per indicator
KRI thresholds trigger escalation when breached; breach handling is defined
Each KRI has a named owner
KRIs feed AIMS KPI / KRI reporting per GOV.OV-01 and AI risk reporting per RSK.RG-02
KRIs cover residual-risk-above-appetite count, AI incident rate per LIF.IR, near-miss rate per GOV.RR-05, Control effectiveness indicators per RSK.TR-03, regulatory exposure indicators per CON.JU
KRI measurement and reporting cadence is defined per indicator
KRI thresholds trigger escalation when breached; breach handling is defined
Each KRI has a named owner
KRIs feed AIMS KPI / KRI reporting per GOV.OV-01 and AI risk reporting per RSK.RG-02
Control Mapping
ISO/IEC 42001:2023 — Cl. 9.1
NIST AI RMF — MEASURE 3.1; MEASURE 3.2
EU AI Act — Art. 17(2)(g); Art. 72
ISO/IEC 5338:2023 — Cl. 6.3.4
NIST AI RMF — MEASURE 3.1; MEASURE 3.2
EU AI Act — Art. 17(2)(g); Art. 72
ISO/IEC 5338:2023 — Cl. 6.3.4
RSK.MO-02AI risk reassessment — performed at defined cadence and on triggers (material change, post-incident, regulatory change) — ensures risk understanding remains currentT 6 · C 7 · F 6
Applies To
Periodic reassessment cadence per RSK.AS-03
Material change reassessment triggers
Post-incident reassessment per LIF.IR
Regulatory change reassessment
Reassessment scope and method
Reassessment outputs feeding RSK.TR
Material change reassessment triggers
Post-incident reassessment per LIF.IR
Regulatory change reassessment
Reassessment scope and method
Reassessment outputs feeding RSK.TR
Control Details
AI risk reassessment is performed at defined cadence per RSK.AS-03 and on triggers
Material change triggers (AI capability uplift, scope expansion, autonomy uplift, integration change) trigger affected-AI reassessment
Post-incident reassessment per LIF.IR ensures incident learning feeds risk understanding
Regulatory change reassessment is performed when material EU AI Act developments, GDPR guidance, or other applicable changes occur
Reassessment scope and method follow the methodology per RSK.ME
Reassessment outputs trigger treatment updates per RSK.TR where residual risk changes materially
Material change triggers (AI capability uplift, scope expansion, autonomy uplift, integration change) trigger affected-AI reassessment
Post-incident reassessment per LIF.IR ensures incident learning feeds risk understanding
Regulatory change reassessment is performed when material EU AI Act developments, GDPR guidance, or other applicable changes occur
Reassessment scope and method follow the methodology per RSK.ME
Reassessment outputs trigger treatment updates per RSK.TR where residual risk changes materially
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.1; Cl. 9.3
NIST AI RMF — MEASURE 3.1; GOVERN 1.5
EU AI Act — Art. 9(2); Art. 72
ISO/IEC 5338:2023 — Cl. 6.3.4
NIST AI RMF — MEASURE 3.1; GOVERN 1.5
EU AI Act — Art. 9(2); Art. 72
ISO/IEC 5338:2023 — Cl. 6.3.4
RSK.MO-03Emerging AI risk identification and trend analysis — identifying new risk classes, new attack vectors, and shifting risk trends — are performed and used to inform AI risk management strategyT 6 · C 6 · F 6
Applies To
Emerging risk identification (horizon scanning, threat intelligence, regulatory landscape)
Trend analysis on existing risks (frequency, severity, breadth)
Risk landscape reporting to AI governance forums
Strategic risk decisions informed by emerging risk and trends
Integration with AI strategy review per GOV.ST-05
Trend analysis on existing risks (frequency, severity, breadth)
Risk landscape reporting to AI governance forums
Strategic risk decisions informed by emerging risk and trends
Integration with AI strategy review per GOV.ST-05
Control Details
Emerging AI risk identification draws from horizon scanning per CON.OC-01, AI threat intelligence, regulatory landscape monitoring, and AI capability advance tracking
Emerging risks not yet covered by existing risk classes per RSK.ME-02 trigger methodology review per RSK.ME-04
Trend analysis evaluates existing risk frequency, severity, breadth, and combination patterns
Risk landscape reporting to AI governance forums per GOV.GF informs strategic decisions
Emerging-risk findings feed AI strategy review per GOV.ST-05 and AI risk appetite review per GOV.RA-04
Trend analysis cadence is at minimum quarterly
Emerging risks not yet covered by existing risk classes per RSK.ME-02 trigger methodology review per RSK.ME-04
Trend analysis evaluates existing risk frequency, severity, breadth, and combination patterns
Risk landscape reporting to AI governance forums per GOV.GF informs strategic decisions
Emerging-risk findings feed AI strategy review per GOV.ST-05 and AI risk appetite review per GOV.RA-04
Trend analysis cadence is at minimum quarterly
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.1; Cl. 9.3
NIST AI RMF — MEASURE 3.2; MEASURE 4.1
EU AI Act — Art. 72
ISO/IEC 5338:2023 — Cl. 6.3.4
WEF Global Cybersecurity Outlook (annual landscape reference)
NIST AI RMF — MEASURE 3.2; MEASURE 4.1
EU AI Act — Art. 72
ISO/IEC 5338:2023 — Cl. 6.3.4
WEF Global Cybersecurity Outlook (annual landscape reference)
Impact23 Controls · 6 Objectives
IMP.MEAI Impact Assessment Methodology3 Controls
Description: The AI impact assessment methodology — covering assessment scope, criteria for assessing impacts on individuals, groups, and society, scoring approach, role-specific application (provider, deployer, internal developer), integration with the AI risk management methodology, and methodology review — is documented, communicated, and maintained
IMP.ME-01The AI impact assessment methodology — covering scope, criteria for assessing impacts on individuals, groups, and society, scoring approach, integration with risk management, and approval — is documented, communicated, and maintainedT 6 · C 6 · F 6
Applies To
AI impact assessment methodology document
Assessment criteria per impact category (individuals, groups, society, environment, economy)
Impact scoring approach (severity, breadth, reversibility, likelihood)
Integration with AI risk management methodology per RSK.ME
Methodology approval
Assessment criteria per impact category (individuals, groups, society, environment, economy)
Impact scoring approach (severity, breadth, reversibility, likelihood)
Integration with AI risk management methodology per RSK.ME
Methodology approval
Control Details
The AI impact assessment methodology is documented as a formal artefact, approved at appropriate authority level
Assessment criteria are defined per impact category covering individual harm, group impact, societal effects, environmental impact, and economic considerations
Scoring approach covers severity, breadth, reversibility, and likelihood of impacts
Methodology is integrated with the AI risk management methodology per RSK.ME-01 so impact and risk assessments inform each other
Methodology is communicated to AI impact assessors, AI governance forums per GOV.GF, and AI decision-makers
Methodology aligns with ISO 42001 A.5 expectations and EU AI Risks Management Guidance
Assessment criteria are defined per impact category covering individual harm, group impact, societal effects, environmental impact, and economic considerations
Scoring approach covers severity, breadth, reversibility, and likelihood of impacts
Methodology is integrated with the AI risk management methodology per RSK.ME-01 so impact and risk assessments inform each other
Methodology is communicated to AI impact assessors, AI governance forums per GOV.GF, and AI decision-makers
Methodology aligns with ISO 42001 A.5 expectations and EU AI Risks Management Guidance
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.1; Cl. 6.1.4; A.5; A.5.2
NIST AI RMF — MAP 5.1; GOVERN 1.3
EU AI Act — Art. 27
OECD AI Principles (OECD/LEGAL/0449)
OECD Due Diligence Guidance for Responsible AI
EU AI Risks Management Guidance
NIST AI RMF — MAP 5.1; GOVERN 1.3
EU AI Act — Art. 27
OECD AI Principles (OECD/LEGAL/0449)
OECD Due Diligence Guidance for Responsible AI
EU AI Risks Management Guidance
IMP.ME-02Role-specific methodology application — covering how the impact assessment methodology is applied for provider, deployer, and internal-developer contexts — is documented and maintainedT 6 · C 5 · F 6
Applies To
Provider impact assessment application (downstream user impact, customer-facing AI products)
Deployer impact assessment application (use-time impact, FRIA where applicable)
Internal-developer impact assessment application (internal user impact, institutional impact)
Role-specific impact categories
Cross-role coordination
Deployer impact assessment application (use-time impact, FRIA where applicable)
Internal-developer impact assessment application (internal user impact, institutional impact)
Role-specific impact categories
Cross-role coordination
Control Details
Provider impact assessment application focuses on impacts arising from AI products placed on the market, including downstream end-user impact and customer organisational impact
Deployer impact assessment application focuses on use-time impacts within deployment context; FRIA per EU AI Act Art. 27 frame is applied as best practice
Internal-developer impact assessment application focuses on internal users and institutional impact
Role-specific impact categories are emphasised per role (e.g., provider emphasises customer-facing harm; deployer emphasises employee or business impact)
Where a single AI activity spans multiple roles, impact assessment is coordinated through AI governance forums per GOV.GF
Deployer impact assessment application focuses on use-time impacts within deployment context; FRIA per EU AI Act Art. 27 frame is applied as best practice
Internal-developer impact assessment application focuses on internal users and institutional impact
Role-specific impact categories are emphasised per role (e.g., provider emphasises customer-facing harm; deployer emphasises employee or business impact)
Where a single AI activity spans multiple roles, impact assessment is coordinated through AI governance forums per GOV.GF
Control Mapping
ISO/IEC 42001:2023 — A.5; A.10
NIST AI RMF — MAP 5.1; MAP 4.1
EU AI Act — Art. 27; Art. 16; Art. 26
NIST AI RMF — MAP 5.1; MAP 4.1
EU AI Act — Art. 27; Art. 16; Art. 26
IMP.ME-03AI impact assessment methodology review is performed at defined cadence and on material change, with methodology updates approved and communicatedT 6 · C 6 · F 6
Applies To
Review schedule (at minimum annually)
Material change triggers
Review participants
Methodology change approval
Communication of updates
Material change triggers
Review participants
Methodology change approval
Communication of updates
Control Details
The AI impact assessment methodology is reviewed at minimum annually
Ad-hoc review is triggered by material change (regulatory developments, learning from impact assessments, methodology effectiveness findings)
Review participants include independent reviewer per GOV.GF-04, AI ethics committee per GOV.GF-03, and AI governance forums
Methodology updates are approved at appropriate authority level per IMP.ME-01
Updates are communicated to AI impact assessors
Methodology version control is maintained
Ad-hoc review is triggered by material change (regulatory developments, learning from impact assessments, methodology effectiveness findings)
Review participants include independent reviewer per GOV.GF-04, AI ethics committee per GOV.GF-03, and AI governance forums
Methodology updates are approved at appropriate authority level per IMP.ME-01
Updates are communicated to AI impact assessors
Methodology version control is maintained
Control Mapping
ISO/IEC 42001:2023 — Cl. 9.3; Cl. 10
NIST AI RMF — GOVERN 1.5
EU AI Act — Art. 17(2)
NIST AI RMF — GOVERN 1.5
EU AI Act — Art. 17(2)
IMP.IAAI System Impact Assessment6 Controls
Description: AI system impact assessment per ISO 42001 — covering impact analysis on individuals, groups, and society, identification of affected parties, assessment of intended use and reasonably foreseeable misuse, documentation of impact findings, and assessment triggers (new AI system, material change) — is performed, documented, and maintained
IMP.IA-01Per-AI-system impact analysis — covering impacts on individuals, groups, and society — is performed and documented per ISO 42001 expectationsT 6 · C 6 · F 6
Applies To
Impact analysis per AI system per CON.IN inventory
Individual impact analysis (rights, autonomy, dignity, economic, emotional)
Group impact analysis (demographic, professional, social)
Societal impact analysis (public discourse, institutional trust, democratic processes)
Environmental and economic impact where material
Per-AI assessment record
Individual impact analysis (rights, autonomy, dignity, economic, emotional)
Group impact analysis (demographic, professional, social)
Societal impact analysis (public discourse, institutional trust, democratic processes)
Environmental and economic impact where material
Per-AI assessment record
Control Details
Impact analysis is performed per AI system in scope, with depth proportional to AI criticality and risk class per CON.JU-02
Individual impact analysis considers rights (privacy, non-discrimination, autonomy), economic impact, emotional / psychological impact, and bodily safety where relevant
Group impact analysis considers demographic groups, professional groups, and social groups potentially differentially impacted
Societal impact analysis considers public discourse effects, institutional trust effects, democratic process effects, and content ecosystem effects (for content-generating AI)
Environmental impact (e.g., compute energy) and economic impact (e.g., labour displacement) are considered where material
Per-AI assessment record is maintained and feeds AI risk register per RSK.RG-01
Individual impact analysis considers rights (privacy, non-discrimination, autonomy), economic impact, emotional / psychological impact, and bodily safety where relevant
Group impact analysis considers demographic groups, professional groups, and social groups potentially differentially impacted
Societal impact analysis considers public discourse effects, institutional trust effects, democratic process effects, and content ecosystem effects (for content-generating AI)
Environmental impact (e.g., compute energy) and economic impact (e.g., labour displacement) are considered where material
Per-AI assessment record is maintained and feeds AI risk register per RSK.RG-01
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.1.4; Cl. 8.4; A.5.2; A.5.3; A.5.5
NIST AI RMF — MAP 5.1; GOVERN 4.2
EU AI Act — Art. 27; Art. 9
OECD AI Principles (OECD/LEGAL/0449)
OECD Due Diligence Guidance for Responsible AI
Council of Europe Framework Convention on AI (2024)
EU AI Risks Management Guidance
NIST AI RMF — MAP 5.1; GOVERN 4.2
EU AI Act — Art. 27; Art. 9
OECD AI Principles (OECD/LEGAL/0449)
OECD Due Diligence Guidance for Responsible AI
Council of Europe Framework Convention on AI (2024)
EU AI Risks Management Guidance
IMP.IA-02Affected parties identification per AI system — leveraging CON.IP-02 affected party records — is documented per impact assessmentT 6 · C 6 · F 6
Applies To
Affected parties identification per AI system per CON.IP-02
Vulnerable groups consideration
Direct vs indirect affected parties
Affected party engagement where appropriate
Affected parties record per assessment
Vulnerable groups consideration
Direct vs indirect affected parties
Affected party engagement where appropriate
Affected parties record per assessment
Control Details
Affected parties identification per AI system is documented per impact assessment, drawing from CON.IP-02 affected party records
Vulnerable groups (children, elderly, individuals with disabilities, protected populations) are specifically called out per OECD principles
Direct affected parties (those interacting with the AI) and indirect affected parties (those impacted downstream) are distinguished
Affected party engagement (consultation, feedback, co-design) is performed where appropriate and proportionate
Affected parties record per assessment is maintained as input to impact analysis per IMP.IA-01
Vulnerable groups (children, elderly, individuals with disabilities, protected populations) are specifically called out per OECD principles
Direct affected parties (those interacting with the AI) and indirect affected parties (those impacted downstream) are distinguished
Affected party engagement (consultation, feedback, co-design) is performed where appropriate and proportionate
Affected parties record per assessment is maintained as input to impact analysis per IMP.IA-01
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.1.4; A.5.3; A.5.4
NIST AI RMF — MAP 1.2; MAP 5.2
EU AI Act — Art. 27
OECD AI Principles (OECD/LEGAL/0449)
Council of Europe Framework Convention on AI (2024)
NIST AI RMF — MAP 1.2; MAP 5.2
EU AI Act — Art. 27
OECD AI Principles (OECD/LEGAL/0449)
Council of Europe Framework Convention on AI (2024)
IMP.IA-03Intended use, targeted application scope, and reasonably foreseeable misuse assessment — covering intended use cases, narrow application scope as a risk-management discipline, foreseeable misuse patterns, and treatment of misuse risk — is performed per AI systemT 6 · C 6 · F 6
Applies To
Intended use statement per AI system
Targeted application scope — narrow scope as a deliberate risk-management discipline
Foreseeable misuse identification (per EU AI Act expectations)
Misuse risk treatment
Documentation in instructions for use per TRA.IU
Misuse assessment refresh triggers
Scope review on material change per GOV.OB-03
Targeted application scope — narrow scope as a deliberate risk-management discipline
Foreseeable misuse identification (per EU AI Act expectations)
Misuse risk treatment
Documentation in instructions for use per TRA.IU
Misuse assessment refresh triggers
Scope review on material change per GOV.OB-03
Control Details
Intended use statement per AI system is documented, defining authorised use cases, intended user populations, and intended deployment contexts
Targeted application scope is defined per AI system as a deliberate risk-management discipline — narrow scope improves TEVV efficacy per LIF.VA, reduces the surface for foreseeable misuse, and clarifies the boundary between intended and unintended use; scope statements specify what the AI is for, what it is explicitly not for, and the threshold at which use moves outside scope
Foreseeable misuse identification considers reasonably foreseeable misuse patterns (AI used outside its intended population, in adversarial contexts, or for purposes not authorised)
Misuse risk treatment is determined and documented (design constraints, runtime safeguards per LIF.AG-02, contractual restrictions, monitoring per LIF.OP)
Foreseeable misuse and intended scope are documented in instructions for use per TRA.IU
Misuse assessment and scope are refreshed when new misuse patterns emerge, when AI scope materially changes, or when AIMS-level change planning per GOV.OB-03 is triggered
Targeted application scope is defined per AI system as a deliberate risk-management discipline — narrow scope improves TEVV efficacy per LIF.VA, reduces the surface for foreseeable misuse, and clarifies the boundary between intended and unintended use; scope statements specify what the AI is for, what it is explicitly not for, and the threshold at which use moves outside scope
Foreseeable misuse identification considers reasonably foreseeable misuse patterns (AI used outside its intended population, in adversarial contexts, or for purposes not authorised)
Misuse risk treatment is determined and documented (design constraints, runtime safeguards per LIF.AG-02, contractual restrictions, monitoring per LIF.OP)
Foreseeable misuse and intended scope are documented in instructions for use per TRA.IU
Misuse assessment and scope are refreshed when new misuse patterns emerge, when AI scope materially changes, or when AIMS-level change planning per GOV.OB-03 is triggered
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.1.4; A.5.2; A.6.2; A.8
NIST AI RMF — MAP 1.1; MAP 3.3; MAP 5.1
EU AI Act — Art. 9(2)(b); Art. 13(3)(b); Art. 14(4)(e)
OECD Due Diligence Guidance for Responsible AI
NIST AI RMF — MAP 1.1; MAP 3.3; MAP 5.1
EU AI Act — Art. 9(2)(b); Art. 13(3)(b); Art. 14(4)(e)
OECD Due Diligence Guidance for Responsible AI
IMP.IA-04Impact assessment triggers — new AI system, material change, post-incident, regulatory change — are defined and appliedT 6 · C 5 · F 6
Applies To
New AI system trigger (before deployment per GOV.RR-03)
Material change trigger (capability uplift, scope expansion, autonomy uplift)
Post-incident trigger per LIF.IR
Regulatory change trigger
Periodic refresh per assessment cadence
Material change trigger (capability uplift, scope expansion, autonomy uplift)
Post-incident trigger per LIF.IR
Regulatory change trigger
Periodic refresh per assessment cadence
Control Details
Impact assessment triggers are documented to ensure timely assessment of impacts
New AI system trigger requires impact assessment before deployment per GOV.RR-03
Material change trigger requires impact reassessment when AI capability, scope, autonomy, or affected population materially changes
Post-incident trigger per LIF.IR requires impact reassessment after material AI incidents
Regulatory change trigger requires reassessment when material EU AI Act, GDPR, or related regulatory developments occur
Periodic refresh is performed at defined cadence per AI criticality
Trigger application is tracked through AI governance forums per GOV.GF
New AI system trigger requires impact assessment before deployment per GOV.RR-03
Material change trigger requires impact reassessment when AI capability, scope, autonomy, or affected population materially changes
Post-incident trigger per LIF.IR requires impact reassessment after material AI incidents
Regulatory change trigger requires reassessment when material EU AI Act, GDPR, or related regulatory developments occur
Periodic refresh is performed at defined cadence per AI criticality
Trigger application is tracked through AI governance forums per GOV.GF
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.1.4; Cl. 8.4; Cl. 9.3; A.5.2; A.5.4
NIST AI RMF — MAP 5.1; GOVERN 1.5
EU AI Act — Art. 9(2); Art. 27(1)(c); Art. 72
NIST AI RMF — MAP 5.1; GOVERN 1.5
EU AI Act — Art. 9(2); Art. 27(1)(c); Art. 72
IMP.IA-05AI benefits and cost-of-errors analysis per AI system — covering intended benefits per affected-party category, expected and realised costs of errors, non-monetary costs, and benefit-cost trade-off documentation — is performed and documentedT 6 · C 5 · F 6
Applies To
Per-AI-system benefits identification (individual, group, societal, economic, productivity, scientific)
Expected cost-of-errors per error class (direct financial, indirect, non-monetary, opportunity, reputational)
Realised cost-of-errors tracking from operational data per LIF.OP
Benefit-cost trade-off documentation
Linkage with IMP.IA-01 (negative impacts), IMP.MO-01 (go/no-go), LIF.DE-05 (AI necessity)
Expected cost-of-errors per error class (direct financial, indirect, non-monetary, opportunity, reputational)
Realised cost-of-errors tracking from operational data per LIF.OP
Benefit-cost trade-off documentation
Linkage with IMP.IA-01 (negative impacts), IMP.MO-01 (go/no-go), LIF.DE-05 (AI necessity)
Control Details
Benefits analysis is performed per AI system covering intended benefits to individuals, groups, society, and economic / productivity / scientific advancement; environmental benefits are considered alongside environmental costs per IMP.IA-06
Benefits are stated in measurable terms where feasible — latency reduction, decision quality improvement, cost reduction, access improvement, error-rate reduction versus baseline
Expected cost-of-errors is documented per error class — direct financial costs (rework, customer compensation, regulatory penalties), indirect costs (operational disruption), non-monetary costs (reputational, trust, opportunity cost), and cost to affected parties when AI gets it wrong within expected operating limits
Realised cost-of-errors is tracked from operational data per LIF.OP and feeds back into the analysis with documented variance
Benefit-cost trade-off documentation captures the rationale for the AI system, including how benefits outweigh expected costs and the threshold at which the trade-off would no longer hold (trigger for re-evaluation per IMP.MO-03 or LIF.DC-01 decommissioning)
Linkage with IMP.IA-01 (negative impacts), IMP.MO-01 (pre-deployment go/no-go), and LIF.DE-05 (AI necessity) ensures benefit-cost analysis informs material decisions
Benefits are stated in measurable terms where feasible — latency reduction, decision quality improvement, cost reduction, access improvement, error-rate reduction versus baseline
Expected cost-of-errors is documented per error class — direct financial costs (rework, customer compensation, regulatory penalties), indirect costs (operational disruption), non-monetary costs (reputational, trust, opportunity cost), and cost to affected parties when AI gets it wrong within expected operating limits
Realised cost-of-errors is tracked from operational data per LIF.OP and feeds back into the analysis with documented variance
Benefit-cost trade-off documentation captures the rationale for the AI system, including how benefits outweigh expected costs and the threshold at which the trade-off would no longer hold (trigger for re-evaluation per IMP.MO-03 or LIF.DC-01 decommissioning)
Linkage with IMP.IA-01 (negative impacts), IMP.MO-01 (pre-deployment go/no-go), and LIF.DE-05 (AI necessity) ensures benefit-cost analysis informs material decisions
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.1.4; A.5; A.5.2
NIST AI RMF — MAP 3.1; MAP 3.2; MAP 5.1
EU AI Act — Art. 9; Art. 27 (where applicable)
OECD AI Principles (OECD/LEGAL/0449)
OECD Due Diligence Guidance for Responsible AI
NIST AI RMF — MAP 3.1; MAP 3.2; MAP 5.1
EU AI Act — Art. 9; Art. 27 (where applicable)
OECD AI Principles (OECD/LEGAL/0449)
OECD Due Diligence Guidance for Responsible AI
IMP.IA-06Environmental impact assessment per AI system — covering compute energy consumption, water use, carbon footprint, hardware lifecycle, and sustainability mitigation — is performed and documentedT 6 · C 5 · F 6
Applies To
Per-AI-system energy consumption (training and inference)
Water use for cooling and operations
Carbon footprint estimation and lifecycle assessment
Hardware lifecycle (manufacture, use, end-of-life e-waste)
Sustainability mitigation measures (efficient architectures, low-carbon regions, shared pre-trained models, retraining justification)
Linkage with EU AI Act Annex XI energy disclosure for GPAI
Water use for cooling and operations
Carbon footprint estimation and lifecycle assessment
Hardware lifecycle (manufacture, use, end-of-life e-waste)
Sustainability mitigation measures (efficient architectures, low-carbon regions, shared pre-trained models, retraining justification)
Linkage with EU AI Act Annex XI energy disclosure for GPAI
Control Details
Environmental impact is assessed per AI system, scaled to compute intensity — high-impact for foundation model pretraining, moderate for fine-tuning, lower for inference-only
Compute energy consumption is measured or estimated for training (per training run) and inference (per inference unit), aggregated to AI-system level, with refresh on material capacity change
Water use is estimated where data centre cooling water-use intensity (WUE) data is available from infrastructure providers
Carbon footprint is estimated using grid carbon-intensity factors for compute regions used, with refresh on regional grid changes
Hardware lifecycle considers manufacture-stage embodied emissions for AI-dedicated infrastructure and end-of-life e-waste handling per LIF.DC-03 disposal
Sustainability mitigation includes use of efficient model architectures, selection of low-carbon compute regions, leveraging shared pre-trained models versus from-scratch training, and documented retraining-versus-reuse justification
Reporting feeds management review per GOV.OV-05 and is included in EU AI Act Annex XI Section 1 point 2(e) energy consumption disclosure where the company is a GPAI provider
Linkage with GOV.LD-02 resource planning ensures environmental considerations are reflected in AI compute strategy
Compute energy consumption is measured or estimated for training (per training run) and inference (per inference unit), aggregated to AI-system level, with refresh on material capacity change
Water use is estimated where data centre cooling water-use intensity (WUE) data is available from infrastructure providers
Carbon footprint is estimated using grid carbon-intensity factors for compute regions used, with refresh on regional grid changes
Hardware lifecycle considers manufacture-stage embodied emissions for AI-dedicated infrastructure and end-of-life e-waste handling per LIF.DC-03 disposal
Sustainability mitigation includes use of efficient model architectures, selection of low-carbon compute regions, leveraging shared pre-trained models versus from-scratch training, and documented retraining-versus-reuse justification
Reporting feeds management review per GOV.OV-05 and is included in EU AI Act Annex XI Section 1 point 2(e) energy consumption disclosure where the company is a GPAI provider
Linkage with GOV.LD-02 resource planning ensures environmental considerations are reflected in AI compute strategy
Control Mapping
ISO/IEC 42001:2023 — Cl. 6.1.4; A.5; A.5.2
NIST AI RMF — MEASURE 2.12
EU AI Act — Art. 53(1)(a); Annex XI Section 1 point 2(e)
OECD AI Principles (OECD/LEGAL/0449)
NIST AI RMF — MEASURE 2.12
EU AI Act — Art. 53(1)(a); Annex XI Section 1 point 2(e)
OECD AI Principles (OECD/LEGAL/0449)
IMP.DAData Protection Impact Assessment for AI3 Controls
Description: DPIA for AI processing — covering DPIA scope determination per GDPR Art. 35, assessment of necessity and proportionality, risks to data subjects, mitigation measures, DPO consultation, and prior consultation with the supervisory authority where required — is performed, documented, and maintained
IMP.DA-01DPIA scope determination for AI processing — assessing Art. 35 triggers per AI processing activity — is performed and documentedT 6 · C 5 · F 6
Applies To
AI processing activities involving personal data per CON.JU-04
Art. 35 trigger assessment per processing activity
High-risk processing identification (systematic profiling, large-scale special category, large-scale public area monitoring)
DPIA scope decision documentation
Linkage with AI impact assessment per IMP.IA
Art. 35 trigger assessment per processing activity
High-risk processing identification (systematic profiling, large-scale special category, large-scale public area monitoring)
DPIA scope decision documentation
Linkage with AI impact assessment per IMP.IA
Control Details
DPIA scope determination is performed per AI processing activity involving personal data
Art. 35 trigger assessment considers high-risk thresholds: systematic and extensive evaluation including profiling that produces legal or significantly similar effects on individuals; large-scale processing of special category data per Art. 9; large-scale monitoring of publicly accessible areas
DPIA scope decision is documented (DPIA required, optional, or not triggered) with rationale
Decisions are reviewed when processing materially changes
DPIA scope decisions integrate with AI impact assessment per IMP.IA — DPIA and AI impact assessment may be combined where practical
Art. 35 trigger assessment considers high-risk thresholds: systematic and extensive evaluation including profiling that produces legal or significantly similar effects on individuals; large-scale processing of special category data per Art. 9; large-scale monitoring of publicly accessible areas
DPIA scope decision is documented (DPIA required, optional, or not triggered) with rationale
Decisions are reviewed when processing materially changes
DPIA scope decisions integrate with AI impact assessment per IMP.IA — DPIA and AI impact assessment may be combined where practical
Control Mapping
ISO/IEC 42001:2023 — A.7.4; A.5.2
NIST AI RMF — MEASURE 2.10; MAP 5.1
EU AI Act — Art. 10; Art. 26(9)
GDPR — Art. 35; Art. 35(3); Art. 35(4)
NIST AI RMF — MEASURE 2.10; MAP 5.1
EU AI Act — Art. 10; Art. 26(9)
GDPR — Art. 35; Art. 35(3); Art. 35(4)
IMP.DA-02DPIA conduct — necessity and proportionality assessment, risks to data subjects, and mitigation measures — is performed per GDPR Art. 35 requirements where triggeredT 6 · C 6 · F 6
Applies To
DPIA conduct per Art. 35 elements
Description of processing
Necessity and proportionality assessment
Risks to data subject rights and freedoms
Mitigation measures and safeguards
DPIA documentation
Description of processing
Necessity and proportionality assessment
Risks to data subject rights and freedoms
Mitigation measures and safeguards
DPIA documentation
Control Details
DPIA conduct follows GDPR Art. 35(7) elements: systematic description of the processing operations, assessment of necessity and proportionality, assessment of risks to data subject rights and freedoms, and mitigation measures including safeguards
For AI processing, AI-specific risks are addressed: bias and discrimination, automated decision-making per Art. 22, data subject rights enabling for AI per DAT.LB, model regurgitation and inference attacks per DAT.LK, opacity and explainability per TRU.EX
Mitigation measures align with Controls in DAT, TRU, HUM, and TRA
DPIA documentation is maintained as part of the GDPR Art. 30 record of processing
DPIA is reviewed when processing materially changes per Art. 35(11)
For AI processing, AI-specific risks are addressed: bias and discrimination, automated decision-making per Art. 22, data subject rights enabling for AI per DAT.LB, model regurgitation and inference attacks per DAT.LK, opacity and explainability per TRU.EX
Mitigation measures align with Controls in DAT, TRU, HUM, and TRA
DPIA documentation is maintained as part of the GDPR Art. 30 record of processing
DPIA is reviewed when processing materially changes per Art. 35(11)
Control Mapping
ISO/IEC 42001:2023 — A.7.4
NIST AI RMF — MEASURE 2.10; MAP 5.1
EU AI Act — Art. 10; Art. 26(9)
GDPR — Art. 35(7); Art. 22; Art. 25; Art. 32
NIST AI RMF — MEASURE 2.10; MAP 5.1
EU AI Act — Art. 10; Art. 26(9)
GDPR — Art. 35(7); Art. 22; Art. 25; Art. 32
IMP.DA-03DPO consultation, prior consultation with the supervisory authority, and DPO tasks per GDPR Art. 39 — performed across AI activities — are operationalised and documentedT 6 · C 6 · F 6
Applies To
DPO consultation per Art. 35(2)
Supervisory authority prior consultation per Art. 36 where required
DPO tasks per Art. 39 across AI activities (informing and advising; monitoring compliance; DPIA advice; cooperation with supervisory authority; contact point; due regard to risk)
Consultation documentation
Action on consultation feedback
Consultation timing per DPIA stage
Supervisory authority prior consultation per Art. 36 where required
DPO tasks per Art. 39 across AI activities (informing and advising; monitoring compliance; DPIA advice; cooperation with supervisory authority; contact point; due regard to risk)
Consultation documentation
Action on consultation feedback
Consultation timing per DPIA stage
Control Details
DPO consultation is performed for every DPIA per Art. 35(2); DPO advice is documented and reflected in DPIA outcomes
Prior consultation with the competent supervisory authority is performed where the DPIA indicates high residual risk that cannot be mitigated by reasonable means per Art. 36(1)
Prior consultation documentation includes the information required by Art. 36(3): respective responsibilities, purposes and means, measures and safeguards, contact details of DPO, the DPIA itself, and any other information requested
Beyond DPIA consultation, the DPO performs Art. 39(1) tasks across AI activities: (a) informing and advising the company and AI-relevant personnel of GDPR obligations applicable to AI; (b) monitoring compliance with GDPR, other applicable data protection law, the AI policy per GOV.PO, and related Controls including training and awareness per GOV.CO; (c) providing advice on and monitoring the performance of DPIAs per IMP.DA-01 and IMP.DA-02; (d) cooperating with the supervisory authority per Art. 31 and acting as contact point for the authority per Art. 39(1)(e); (e) the DPO performs tasks with due regard to the risk associated with processing operations per Art. 39(2)
Consultation feedback and ongoing DPO advice are acted upon and documented per GOV.DI-01
Consultation timing is integrated with the DPIA process — DPO consultation early in DPIA scoping; supervisory authority consultation after DPIA completion where triggered; ongoing DPO advice is integrated into AI lifecycle stage-gates per LIF.PO-02 for AI processing personal data
Prior consultation with the competent supervisory authority is performed where the DPIA indicates high residual risk that cannot be mitigated by reasonable means per Art. 36(1)
Prior consultation documentation includes the information required by Art. 36(3): respective responsibilities, purposes and means, measures and safeguards, contact details of DPO, the DPIA itself, and any other information requested
Beyond DPIA consultation, the DPO performs Art. 39(1) tasks across AI activities: (a) informing and advising the company and AI-relevant personnel of GDPR obligations applicable to AI; (b) monitoring compliance with GDPR, other applicable data protection law, the AI policy per GOV.PO, and related Controls including training and awareness per GOV.CO; (c) providing advice on and monitoring the performance of DPIAs per IMP.DA-01 and IMP.DA-02; (d) cooperating with the supervisory authority per Art. 31 and acting as contact point for the authority per Art. 39(1)(e); (e) the DPO performs tasks with due regard to the risk associated with processing operations per Art. 39(2)
Consultation feedback and ongoing DPO advice are acted upon and documented per GOV.DI-01
Consultation timing is integrated with the DPIA process — DPO consultation early in DPIA scoping; supervisory authority consultation after DPIA completion where triggered; ongoing DPO advice is integrated into AI lifecycle stage-gates per LIF.PO-02 for AI processing personal data
Control Mapping
ISO/IEC 42001:2023 — A.7.4
NIST AI RMF — MEASURE 1.3; MEASURE 2.10
EU AI Act — Art. 10; Art. 26(9)
GDPR — Art. 31; Art. 35(2); Art. 36; Art. 38; Art. 39
NIST AI RMF — MEASURE 1.3; MEASURE 2.10
EU AI Act — Art. 10; Art. 26(9)
GDPR — Art. 31; Art. 35(2); Art. 36; Art. 38; Art. 39
IMP.GPGPAI Compliance and Conformity5 Controls
Description: General-Purpose AI compliance and conformity — covering GPAI classification per EU AI Act Art. 51, systemic-risk threshold assessment, provider obligations under Art. 53 (technical documentation, copyright policy, training data summary), procedural rights under Art. 52, systemic-risk obligations under Art. 55 (model evaluation, adversarial testing, serious incident reporting, cybersecurity), and authorised representative arrangement under Art. 54 where applicable — are determined, documented, and maintained
IMP.GP-01GPAI classification and systemic-risk threshold assessment — performed per AI model per EU AI Act Art. 51 — is documentedT 7 · C 5 · F 6
Applies To
GPAI classification per AI model per CON.JU-03
Systemic-risk threshold assessment per Art. 51(1)(a) (cumulative compute)
Systemic-risk threshold assessment per Art. 51(1)(b) (decision-based designation by Commission)
GPAI status notification obligations per Art. 52
Classification record per model
Systemic-risk threshold assessment per Art. 51(1)(a) (cumulative compute)
Systemic-risk threshold assessment per Art. 51(1)(b) (decision-based designation by Commission)
GPAI status notification obligations per Art. 52
Classification record per model
Control Details
GPAI classification is performed per AI model developed in-house or materially fine-tuned, drawing on CON.JU-03 classification
Systemic-risk threshold assessment per Art. 51(1)(a) evaluates cumulative compute used for training against the threshold defined by the Act and subsequent delegated acts
Decision-based designation per Art. 51(1)(b) is monitored — Commission designations affecting our models are tracked
Notification obligations per Art. 52 are tracked — providers of models meeting the systemic-risk threshold must notify the Commission within two weeks
Classification record per model is maintained with assessment evidence
Systemic-risk threshold assessment per Art. 51(1)(a) evaluates cumulative compute used for training against the threshold defined by the Act and subsequent delegated acts
Decision-based designation per Art. 51(1)(b) is monitored — Commission designations affecting our models are tracked
Notification obligations per Art. 52 are tracked — providers of models meeting the systemic-risk threshold must notify the Commission within two weeks
Classification record per model is maintained with assessment evidence
Control Mapping
ISO/IEC 42001:2023 — Cl. 4.1; A.6.2
NIST AI RMF — GOVERN 1.1; MAP 1.1
EU AI Act — Art. 51; Art. 52
EU GPAI Code of Practice (Safety and Security Chapter)
NIST AI RMF — GOVERN 1.1; MAP 1.1
EU AI Act — Art. 51; Art. 52
EU GPAI Code of Practice (Safety and Security Chapter)
IMP.GP-02GPAI provider obligations per Art. 53 — technical documentation, copyright policy, and training data summary — are produced and maintained for each GPAI modelT 7 · C 4 · F 6
Applies To
Technical documentation per Art. 53(1)(a) + Annex XI
Copyright policy per Art. 53(1)(c)
Training data summary per Art. 53(1)(d) + Commission template
Documentation provided to downstream providers per Art. 53(1)(b)
Documentation maintenance and updates
Copyright policy per Art. 53(1)(c)
Training data summary per Art. 53(1)(d) + Commission template
Documentation provided to downstream providers per Art. 53(1)(b)
Documentation maintenance and updates
Control Details
Technical documentation per Art. 53(1)(a) and Annex XI is produced per GPAI model and includes model description, training process, training resources, evaluation, intended use cases, integration guidance, and known limitations
Copyright policy per Art. 53(1)(c) is produced reflecting respect for copyright law including rights-holder exclusions for text and data mining
Training data summary per Art. 53(1)(d) is produced following the Commission template, providing sufficiently detailed information about content used for training
Documentation provided to downstream providers per Art. 53(1)(b) enables their conformity assessments and use compliance
Documentation is maintained and updated when models are versioned or materially change
Copyright policy per Art. 53(1)(c) is produced reflecting respect for copyright law including rights-holder exclusions for text and data mining
Training data summary per Art. 53(1)(d) is produced following the Commission template, providing sufficiently detailed information about content used for training
Documentation provided to downstream providers per Art. 53(1)(b) enables their conformity assessments and use compliance
Documentation is maintained and updated when models are versioned or materially change
Control Mapping
ISO/IEC 42001:2023 — A.6.2; A.8
NIST AI RMF — GOVERN 1.1; MEASURE 2.8
EU AI Act — Art. 53; Annex XI; Annex XII
EU GPAI Code of Practice (Transparency Chapter); (Copyright Chapter)
NIST AI RMF — GOVERN 1.1; MEASURE 2.8
EU AI Act — Art. 53; Annex XI; Annex XII
EU GPAI Code of Practice (Transparency Chapter); (Copyright Chapter)
IMP.GP-03GPAI procedural rights and challenge process — per Art. 52 — are established to respond to Commission designation processes and correctionsT 7 · C 6 · F 6
Applies To
Commission designation notifications and challenge process
Procedural rights per Art. 52
Provider representations to Commission
Designation correction process
Process documentation
Procedural rights per Art. 52
Provider representations to Commission
Designation correction process
Process documentation
Control Details
Provider procedural rights to challenge Commission designations under Art. 52 are documented and exercisable
Where the Commission notifies a designation under Art. 51(1)(b), the provider has the right to make representations and challenge designation
Process for preparing and submitting representations is documented
Designation corrections per Art. 52(2) where systemic-risk status no longer applies are pursued where appropriate
Process documentation supports compliance and demonstrates provider engagement
Where the Commission notifies a designation under Art. 51(1)(b), the provider has the right to make representations and challenge designation
Process for preparing and submitting representations is documented
Designation corrections per Art. 52(2) where systemic-risk status no longer applies are pursued where appropriate
Process documentation supports compliance and demonstrates provider engagement
Control Mapping
ISO/IEC 42001:2023 — A.6.2; Cl. 4.2
NIST AI RMF — GOVERN 1.1
EU AI Act — Art. 52; Art. 94
EU GPAI Code of Practice (Safety and Security Chapter)
NIST AI RMF — GOVERN 1.1
EU AI Act — Art. 52; Art. 94
EU GPAI Code of Practice (Safety and Security Chapter)
IMP.GP-04Systemic-risk GPAI obligations per Art. 55 — model evaluation, adversarial testing, serious incident reporting, and cybersecurity — are established and maintained for models meeting systemic-risk thresholdsT 7 · C 6 · F 6
Applies To
Model evaluation per Art. 55(1)(a)
Adversarial testing per Art. 55(1)(a) (red teaming, capability elicitation)
Risk assessment and mitigation per Art. 55(1)(b)
Serious incident reporting per Art. 55(1)(c)
Cybersecurity per Art. 55(1)(d)
Documentation per Art. 55(2)
Adversarial testing per Art. 55(1)(a) (red teaming, capability elicitation)
Risk assessment and mitigation per Art. 55(1)(b)
Serious incident reporting per Art. 55(1)(c)
Cybersecurity per Art. 55(1)(d)
Documentation per Art. 55(2)
Control Details
For GPAI models meeting systemic-risk thresholds per IMP.GP-01, Art. 55 obligations apply
Model evaluation per Art. 55(1)(a) covers standardised protocols, tools, and indicators (state-of-the-art per EU AI Office guidance)
Adversarial testing (red teaming) per Art. 55(1)(a) covers capability-elicitation tests and harm scenarios — implemented per RSK.AR-04
Risk assessment per Art. 55(1)(b) identifies, evaluates, and mitigates possible systemic risks at the Union level
Serious incident reporting per Art. 55(1)(c) includes serious incidents and corrective measures to the EU AI Office and relevant national authorities
Cybersecurity per Art. 55(1)(d) covers the GPAI model and its physical infrastructure
Documentation per Art. 55(2) is maintained for evaluation and risk management
Model evaluation per Art. 55(1)(a) covers standardised protocols, tools, and indicators (state-of-the-art per EU AI Office guidance)
Adversarial testing (red teaming) per Art. 55(1)(a) covers capability-elicitation tests and harm scenarios — implemented per RSK.AR-04
Risk assessment per Art. 55(1)(b) identifies, evaluates, and mitigates possible systemic risks at the Union level
Serious incident reporting per Art. 55(1)(c) includes serious incidents and corrective measures to the EU AI Office and relevant national authorities
Cybersecurity per Art. 55(1)(d) covers the GPAI model and its physical infrastructure
Documentation per Art. 55(2) is maintained for evaluation and risk management
Control Mapping
ISO/IEC 42001:2023 — A.6.2; A.5.2
NIST AI RMF — MEASURE 2.6; MANAGE 1.3
EU AI Act — Art. 55; Art. 90
EU GPAI Code of Practice (Safety and Security Chapter)
OWASP GenAI Red Teaming Guide
CSA Agentic AI Red Teaming Guide
NIST AI RMF — MEASURE 2.6; MANAGE 1.3
EU AI Act — Art. 55; Art. 90
EU GPAI Code of Practice (Safety and Security Chapter)
OWASP GenAI Red Teaming Guide
CSA Agentic AI Red Teaming Guide
IMP.GP-05Authorised representative arrangement per Art. 54 — where the provider is established outside the EU — is established with documented mandate and oversightT 7 · C 6 · F 6
Applies To
Authorised representative appointment where applicable
Written mandate covering Art. 54 tasks
Authorised representative tasks (verification, documentation, cooperation)
Mandate review and renewal
Oversight of authorised representative
Written mandate covering Art. 54 tasks
Authorised representative tasks (verification, documentation, cooperation)
Mandate review and renewal
Oversight of authorised representative
Control Details
Where the company places GPAI models on the EU market and is established outside the EU, an authorised representative is appointed in accordance with Art. 54
The authorised representative mandate is documented in writing per Art. 54(2) and covers verification of conformity, retention of documentation, provision of information to authorities, and cooperation with authorities
The authorised representative may terminate the mandate per Art. 54(4) if the provider acts contrary to obligations
Mandate review and renewal is performed at defined cadence and on material change
Oversight of the authorised representative ensures continued capability and conformity
The authorised representative mandate is documented in writing per Art. 54(2) and covers verification of conformity, retention of documentation, provision of information to authorities, and cooperation with authorities
The authorised representative may terminate the mandate per Art. 54(4) if the provider acts contrary to obligations
Mandate review and renewal is performed at defined cadence and on material change
Oversight of the authorised representative ensures continued capability and conformity
Control Mapping
ISO/IEC 42001:2023 — A.10
NIST AI RMF — GOVERN 1.1; GOVERN 2.1
EU AI Act — Art. 54
EU GPAI Code of Practice (Safety and Security Chapter)
NIST AI RMF — GOVERN 1.1; GOVERN 2.1
EU AI Act — Art. 54
EU GPAI Code of Practice (Safety and Security Chapter)
IMP.MOPre-deployment and Post-deployment Impact Monitoring3 Controls
Description: AI impact monitoring before and after deployment — covering pre-deployment impact review, deployment go/no-go decision based on impact assessment, post-deployment impact monitoring against expected outcomes, emergent impact identification, and impact reassessment triggers — is performed, documented, and used to drive corrective action
IMP.MO-01Pre-deployment impact review and go/no-go decision — informed by per-AI impact assessment — is performed before AI deploymentT 6 · C 6 · F 6
Applies To
Pre-deployment impact review per AI system
Review criteria based on IMP.IA findings
Go/no-go decision authority per GOV.RR-03
Review record-keeping
Linkage to AI deployment per LIF.DP
Review criteria based on IMP.IA findings
Go/no-go decision authority per GOV.RR-03
Review record-keeping
Linkage to AI deployment per LIF.DP
Control Details
Pre-deployment impact review is performed for every AI system before deployment per GOV.RR-03 deployment decision rights
Review evaluates impact assessment findings per IMP.IA, residual risks per RSK.AS, treatment effectiveness per RSK.TR-03, and ethical considerations per GOV.ET
Review criteria include impact severity within tolerance, residual risk within appetite per GOV.RA, ethical issues resolved, and conformity considerations addressed
Go/no-go decision authority follows GOV.RR-03; above-appetite decisions require explicit override
Review record is maintained with decision rationale
Linkage to AI deployment per LIF.DP-01 ensures deployments without successful pre-deployment review do not proceed
Review evaluates impact assessment findings per IMP.IA, residual risks per RSK.AS, treatment effectiveness per RSK.TR-03, and ethical considerations per GOV.ET
Review criteria include impact severity within tolerance, residual risk within appetite per GOV.RA, ethical issues resolved, and conformity considerations addressed
Go/no-go decision authority follows GOV.RR-03; above-appetite decisions require explicit override
Review record is maintained with decision rationale
Linkage to AI deployment per LIF.DP-01 ensures deployments without successful pre-deployment review do not proceed
Control Mapping
ISO/IEC 42001:2023 — Cl. 8.4; A.5.4; A.6.2
NIST AI RMF — MEASURE 2.4; MANAGE 1.3
EU AI Act — Art. 27; Art. 26(3)
OECD Due Diligence Guidance for Responsible AI
NIST AI RMF — MEASURE 2.4; MANAGE 1.3
EU AI Act — Art. 27; Art. 26(3)
OECD Due Diligence Guidance for Responsible AI
IMP.MO-02Post-deployment impact monitoring against expected outcomes — covering monitoring metrics, monitoring cadence, and outcome evaluation — is performed per AI systemT 6 · C 6 · F 6
Applies To
Post-deployment impact monitoring per AI system
Expected outcome definition (from IMP.IA)
Monitoring metrics and cadence
Outcome evaluation methodology
Linkage to operational monitoring per LIF.OP
Expected outcome definition (from IMP.IA)
Monitoring metrics and cadence
Outcome evaluation methodology
Linkage to operational monitoring per LIF.OP
Control Details
Post-deployment impact monitoring is performed per AI system to evaluate whether actual impacts match those anticipated in IMP.IA
Expected outcomes (functional, ethical, societal) are documented from impact assessment as monitoring baselines
Monitoring metrics are defined per AI system covering accuracy / performance per TRU.AC, fairness per TRU.FA, user satisfaction, complaint volume, adverse incident rate
Monitoring cadence aligns with AI criticality (more frequent for business-critical AI)
Outcome evaluation compares actual to expected and identifies divergence requiring reassessment
Monitoring outputs feed AI operational monitoring per LIF.OP and serious incident reporting per LIF.IR
Expected outcomes (functional, ethical, societal) are documented from impact assessment as monitoring baselines
Monitoring metrics are defined per AI system covering accuracy / performance per TRU.AC, fairness per TRU.FA, user satisfaction, complaint volume, adverse incident rate
Monitoring cadence aligns with AI criticality (more frequent for business-critical AI)
Outcome evaluation compares actual to expected and identifies divergence requiring reassessment
Monitoring outputs feed AI operational monitoring per LIF.OP and serious incident reporting per LIF.IR
Control Mapping
ISO/IEC 42001:2023 — Cl. 8.4; Cl. 9.1; A.5.4
NIST AI RMF — MEASURE 2.4; MANAGE 4.1
EU AI Act — Art. 26(5); Art. 72
OECD Due Diligence Guidance for Responsible AI
NIST AI RMF — MEASURE 2.4; MANAGE 4.1
EU AI Act — Art. 26(5); Art. 72
OECD Due Diligence Guidance for Responsible AI
IMP.MO-03Emergent impact identification and reassessment triggers — covering identification of unanticipated impacts during operation — are defined and appliedT 6 · C 6 · F 6
Applies To
Emergent impact identification mechanisms (user feedback, complaint analysis, monitoring divergence, third-party reports)
Reassessment triggers
Impact reassessment process per IMP.IA
Emergent impact reporting to AI governance forums
Treatment of emergent impacts
Reassessment triggers
Impact reassessment process per IMP.IA
Emergent impact reporting to AI governance forums
Treatment of emergent impacts
Control Details
Emergent impact identification mechanisms include user feedback channels, complaint analysis, monitoring divergence per IMP.MO-02, third-party reports, regulator communications, and AI incident learning per LIF.IR
Reassessment triggers are defined: material divergence from expected outcomes, emergent impact category not previously assessed, regulatory development affecting impact considerations, post-incident learning
Impact reassessment process per IMP.IA is invoked when reassessment triggers fire
Emergent impact reporting to AI governance forums per GOV.GF occurs for material findings
Treatment of emergent impacts is determined and tracked per RSK.TR
Reassessment triggers are defined: material divergence from expected outcomes, emergent impact category not previously assessed, regulatory development affecting impact considerations, post-incident learning
Impact reassessment process per IMP.IA is invoked when reassessment triggers fire
Emergent impact reporting to AI governance forums per GOV.GF occurs for material findings
Treatment of emergent impacts is determined and tracked per RSK.TR
Control Mapping
ISO/IEC 42001:2023 — A.5.4; Cl. 9.3
NIST AI RMF — MEASURE 3.2; MANAGE 4.1
EU AI Act — Art. 72
OECD Due Diligence Guidance for Responsible AI
NIST AI RMF — MEASURE 3.2; MANAGE 4.1
EU AI Act — Art. 72
OECD Due Diligence Guidance for Responsible AI
IMP.IRIndependent Impact Review3 Controls
Description: Independent review of AI impact assessments — covering independence criteria for reviewers (structural separation from AI development), review scope per AI system class, review findings documentation, escalation of concerns, and review effectiveness evaluation — is performed, documented, and acted upon
IMP.IR-01Independent reviewer designation and independence criteria — drawing on GOV.GF-04 independent review function — are established per impact review scopeT 6 · C 6 · F 6
Applies To
Independent reviewer designation per AI system class
Independence criteria (reporting line, conflict-of-interest, capability)
Selection process
Reviewer competence per HUM.CM-01
Designation record
Independence criteria (reporting line, conflict-of-interest, capability)
Selection process
Reviewer competence per HUM.CM-01
Designation record
Control Details
Independent reviewers are designated per AI system class drawing on GOV.GF-04 independent review function
Independence criteria include structural separation from AI development reporting lines, no operational AI responsibilities for the AI under review, conflict-of-interest declarations, and required competence
Selection process for independent reviewers ensures appropriate capability and independence
Reviewer competence per HUM.CM-01 ensures reviewers can effectively evaluate AI impact assessments
Designation record per impact review is maintained
Independence criteria include structural separation from AI development reporting lines, no operational AI responsibilities for the AI under review, conflict-of-interest declarations, and required competence
Selection process for independent reviewers ensures appropriate capability and independence
Reviewer competence per HUM.CM-01 ensures reviewers can effectively evaluate AI impact assessments
Designation record per impact review is maintained
Control Mapping
ISO/IEC 42001:2023 — A.5.4; A.3.2
NIST AI RMF — MEASURE 1.3; GOVERN 2.1
OECD Due Diligence Guidance for Responsible AI
ISO/IEC 38507:2022 — Cl. 5.5
RAII Operationalizing Independent Review in AI Governance
NIST AI RMF — MEASURE 1.3; GOVERN 2.1
OECD Due Diligence Guidance for Responsible AI
ISO/IEC 38507:2022 — Cl. 5.5
RAII Operationalizing Independent Review in AI Governance
IMP.IR-02Independent review of AI impact assessments per defined scope — covering review of methodology application, completeness, and conclusions — is performed and documentedT 7 · C 6 · F 6
Applies To
Review scope per AI system class (when independent review is required)
Methodology application review
Completeness review
Conclusion review (impact severity, treatment adequacy)
Review documentation
Methodology application review
Completeness review
Conclusion review (impact severity, treatment adequacy)
Review documentation
Control Details
Independent review scope is defined per AI system class — required for AI products before launch, AI with sensitive use cases, AI with potential affected-party harm, AI with GPAI systemic-risk classification per IMP.GP-01
Methodology application review evaluates whether the impact assessment methodology per IMP.ME-01 was applied correctly
Completeness review evaluates whether all material impacts were considered (individuals, groups, society, environment)
Conclusion review evaluates whether impact severity assessment is reasonable and whether treatment adequacy is demonstrated
Review documentation includes findings, recommendations, and reviewer attestation
Reviews are performed within defined timeline (before deployment for go / no-go reviews)
Methodology application review evaluates whether the impact assessment methodology per IMP.ME-01 was applied correctly
Completeness review evaluates whether all material impacts were considered (individuals, groups, society, environment)
Conclusion review evaluates whether impact severity assessment is reasonable and whether treatment adequacy is demonstrated
Review documentation includes findings, recommendations, and reviewer attestation
Reviews are performed within defined timeline (before deployment for go / no-go reviews)
Control Mapping
ISO/IEC 42001:2023 — A.5.4; Cl. 9.2
NIST AI RMF — MEASURE 1.3
OECD Due Diligence Guidance for Responsible AI
ISO/IEC 38507:2022 — Cl. 5.5
RAII Operationalizing Independent Review in AI Governance
NIST AI RMF — MEASURE 1.3
OECD Due Diligence Guidance for Responsible AI
ISO/IEC 38507:2022 — Cl. 5.5
RAII Operationalizing Independent Review in AI Governance
IMP.IR-03Independent review findings, escalation, and action tracking — covering documentation, escalation pathway, and closure verification — are maintainedT 6 · C 5 · F 6
Applies To
Review findings documentation
Escalation pathway for findings warranting governance attention
Action tracking
Closure verification
Reporting of independent review outcomes
Escalation pathway for findings warranting governance attention
Action tracking
Closure verification
Reporting of independent review outcomes
Control Details
Independent review findings are documented per IMP.IR-02 with severity, recommendation, and target outcome
Findings warranting AI governance forum attention are escalated through defined criteria (material methodology issues, material completeness gaps, conclusion concerns)
Actions arising from findings are tracked through AIMS continual improvement per GOV.OV-07
Closure verification confirms findings have been addressed and re-review is performed where required
Independent review outcomes are reported to AI governance forums per GOV.GF and management review per GOV.OV-05
Findings warranting AI governance forum attention are escalated through defined criteria (material methodology issues, material completeness gaps, conclusion concerns)
Actions arising from findings are tracked through AIMS continual improvement per GOV.OV-07
Closure verification confirms findings have been addressed and re-review is performed where required
Independent review outcomes are reported to AI governance forums per GOV.GF and management review per GOV.OV-05
Control Mapping
ISO/IEC 42001:2023 — A.5.4; Cl. 9.2; Cl. 10
NIST AI RMF — MEASURE 1.3; MANAGE 4.2
ISO/IEC 38507:2022 — Cl. 5.5
RAII Operationalizing Independent Review in AI Governance
NIST AI RMF — MEASURE 1.3; MANAGE 4.2
ISO/IEC 38507:2022 — Cl. 5.5
RAII Operationalizing Independent Review in AI Governance
Data35 Controls · 10 Objectives
DAT.POAI Data Governance Policy and Methodology3 Controls
Description: The AI data governance policy and methodology — covering principles for AI data handling, scope of application across the data lifecycle (training, validation, test, fine-tuning, inference), role-specific application (provider, deployer, internal developer), integration with the AIMS and GDPR-for-AI obligations, and review — is documented, communicated, and maintained
DAT.PO-01The AI data governance policy — covering principles for AI data handling, scope across the data lifecycle, role-specific application, and policy approval — is documented, communicated, and maintainedT 6 · C 6 · F 6
Applies To
AI data governance policy document
Principles for AI data handling (quality, provenance, minimisation, lawful basis, security, ethical sourcing)
Scope across the AI data lifecycle (training, validation, test, fine-tuning, inference)
Role-specific application (provider, deployer, internal developer)
Approval authority
Principles for AI data handling (quality, provenance, minimisation, lawful basis, security, ethical sourcing)
Scope across the AI data lifecycle (training, validation, test, fine-tuning, inference)
Role-specific application (provider, deployer, internal developer)
Approval authority
Control Details
The AI data governance policy is documented as a formal artefact, approved at appropriate authority level
Principles for AI data handling include data quality per DAT.QU, provenance per DAT.PR, minimisation per DAT.RE, lawful basis per DAT.LB, security per DAT.LK and ISMS, and ethical sourcing per GOV.ET-03
Scope explicitly covers training data, validation / test data, fine-tuning data, inference data, synthetic data per DAT.SY, prompts and embeddings
Role-specific application differentiates provider-mode data governance (training data for provided products), deployer-mode (data exposed to consumed AI), and internal-developer
Policy is communicated to AI engineering, MLOps, data engineering, and data owners
Principles for AI data handling include data quality per DAT.QU, provenance per DAT.PR, minimisation per DAT.RE, lawful basis per DAT.LB, security per DAT.LK and ISMS, and ethical sourcing per GOV.ET-03
Scope explicitly covers training data, validation / test data, fine-tuning data, inference data, synthetic data per DAT.SY, prompts and embeddings
Role-specific application differentiates provider-mode data governance (training data for provided products), deployer-mode (data exposed to consumed AI), and internal-developer
Policy is communicated to AI engineering, MLOps, data engineering, and data owners
Control Mapping
ISO/IEC 42001:2023 — A.7.2
NIST AI RMF — GOVERN 1.2; GOVERN 1.4
EU AI Act — Art. 10; Art. 53
GDPR — Art. 5
NIST SP 1270 (Bias in AI)
EU AI Risks Management Guidance
NIST AI RMF — GOVERN 1.2; GOVERN 1.4
EU AI Act — Art. 10; Art. 53
GDPR — Art. 5
NIST SP 1270 (Bias in AI)
EU AI Risks Management Guidance
DAT.PO-02The AI data governance methodology — covering classification, provenance, quality, lifecycle, and risk integration — is documented and appliedT 6 · C 6 · F 6
Applies To
Methodology for AI data classification per DAT.IN-02
Methodology for provenance establishment per DAT.PR
Methodology for data quality assessment per DAT.QU
Methodology for data lifecycle management per DAT.RE
Integration with AI risk management per RSK and ISMS where applicable
Methodology for provenance establishment per DAT.PR
Methodology for data quality assessment per DAT.QU
Methodology for data lifecycle management per DAT.RE
Integration with AI risk management per RSK and ISMS where applicable
Control Details
The AI data governance methodology documents how policy principles per DAT.PO-01 are operationalised
Classification methodology covers sensitivity and AI-relevant data classes (training, validation, test, fine-tuning, inference, synthetic), intended use, and required handling Controls
Provenance methodology covers source attestation and lineage tracking per DAT.PR
Quality methodology covers per-lifecycle-stage quality criteria per DAT.QU
Lifecycle methodology covers minimisation, retention, and disposal per DAT.RE
Methodology integration with AI risk per RSK ensures data risks are captured
Methodology is communicated and applied across data-handling activities
Classification methodology covers sensitivity and AI-relevant data classes (training, validation, test, fine-tuning, inference, synthetic), intended use, and required handling Controls
Provenance methodology covers source attestation and lineage tracking per DAT.PR
Quality methodology covers per-lifecycle-stage quality criteria per DAT.QU
Lifecycle methodology covers minimisation, retention, and disposal per DAT.RE
Methodology integration with AI risk per RSK ensures data risks are captured
Methodology is communicated and applied across data-handling activities
Control Mapping
ISO/IEC 42001:2023 — A.7; A.7.3; A.7.4
NIST AI RMF — GOVERN 1.3; GOVERN 1.4
EU AI Act — Art. 10
GDPR — Art. 5; Art. 25
OWASP AISVS — C1 (Training Data Integrity)
NIST AI RMF — GOVERN 1.3; GOVERN 1.4
EU AI Act — Art. 10
GDPR — Art. 5; Art. 25
OWASP AISVS — C1 (Training Data Integrity)
DAT.PO-03AI data governance policy and methodology review is performed at defined cadence and on material changeT 6 · C 6 · F 6
Applies To
Review schedule (at minimum annually)
Material change triggers
Review participants
Approval of updates
Communication of changes
Material change triggers
Review participants
Approval of updates
Communication of changes
Control Details
AI data governance policy and methodology are reviewed at minimum annually
Ad-hoc review is triggered by material change (regulatory development, methodology effectiveness findings, material AI data incident, new data class)
Review participants include data owner, AI governance forums per GOV.GF, Privacy / DPO, AI engineering, MLOps
Updates are approved at appropriate authority level per DAT.PO-01
Updates are communicated to data-handling personnel
Version control is maintained
Ad-hoc review is triggered by material change (regulatory development, methodology effectiveness findings, material AI data incident, new data class)
Review participants include data owner, AI governance forums per GOV.GF, Privacy / DPO, AI engineering, MLOps
Updates are approved at appropriate authority level per DAT.PO-01
Updates are communicated to data-handling personnel
Version control is maintained
Control Mapping
ISO/IEC 42001:2023 — Cl. 9.3; Cl. 10
NIST AI RMF — GOVERN 1.5
EU AI Act — Art. 17(2)
NIST AI RMF — GOVERN 1.5
EU AI Act — Art. 17(2)
DAT.INAI Data Inventory and Classification4 Controls
Description: The AI data inventory and classification — covering training data, validation and test data, fine-tuning data, inference data, synthetic data, prompts and embeddings, foundation model training data summary per EU AI Act Art. 53, per-dataset classification by sensitivity and intended use, and dataset lifecycle tracking — is established, maintained, and reviewed
DAT.IN-01The AI data inventory — covering training, validation, test, fine-tuning, inference, synthetic data, prompts, and embeddings — is established, maintained, and made accessibleT 7 · C 7 · F 6
Applies To
Training data inventory
Validation and test data inventory
Fine-tuning data inventory
Inference / runtime data inventory
Synthetic data inventory per DAT.SY
Prompts and system instructions inventory
Embeddings and vector store inventory
Validation and test data inventory
Fine-tuning data inventory
Inference / runtime data inventory
Synthetic data inventory per DAT.SY
Prompts and system instructions inventory
Embeddings and vector store inventory
Control Details
The AI data inventory is documented as the system of record for AI-related data assets in scope
Inventory entries cover each AI data class — training, validation / test, fine-tuning, inference / runtime, synthetic, prompts / system instructions, embeddings / vector stores
Per-dataset metadata includes owner, sources, size, lifecycle stage, classification per DAT.IN-02, lawful basis per DAT.LB, retention per DAT.RE
Inventory is maintained continuously as datasets are added, materially modified, or retired
Inventory access supports AI risk per RSK, audit per GOV.OV-03, and incident response per LIF.IR
Coverage and accuracy are measured per GOV.OV-01
Inventory entries cover each AI data class — training, validation / test, fine-tuning, inference / runtime, synthetic, prompts / system instructions, embeddings / vector stores
Per-dataset metadata includes owner, sources, size, lifecycle stage, classification per DAT.IN-02, lawful basis per DAT.LB, retention per DAT.RE
Inventory is maintained continuously as datasets are added, materially modified, or retired
Inventory access supports AI risk per RSK, audit per GOV.OV-03, and incident response per LIF.IR
Coverage and accuracy are measured per GOV.OV-01
Control Mapping
ISO/IEC 42001:2023 — A.4.3; A.7.3
NIST AI RMF — GOVERN 1.6; MAP 2.1
EU AI Act — Art. 10; Art. 11; Art. 53(1)(d)
GDPR — Art. 30
EU GPAI Code of Practice (Transparency Chapter)
ISO/IEC 5338:2023 — Cl. 6.4.8
OWASP AISVS — C1; C8 (Memory / Embeddings / Vector DB)
NIST AI RMF — GOVERN 1.6; MAP 2.1
EU AI Act — Art. 10; Art. 11; Art. 53(1)(d)
GDPR — Art. 30
EU GPAI Code of Practice (Transparency Chapter)
ISO/IEC 5338:2023 — Cl. 6.4.8
OWASP AISVS — C1; C8 (Memory / Embeddings / Vector DB)
DAT.IN-02Per-dataset classification by sensitivity and intended use is established and applied to all AI datasets in inventoryT 7 · C 7 · F 6
Applies To
Sensitivity classification (Public / Controlled / Restricted; personal data; special category data)
Intended use classification (training, validation, fine-tuning, inference, benchmarking)
Cross-classification (e.g., personal data used for training)
Classification handling rules per class
Classification refresh triggers
Intended use classification (training, validation, fine-tuning, inference, benchmarking)
Cross-classification (e.g., personal data used for training)
Classification handling rules per class
Classification refresh triggers
Control Details
Per-dataset classification by sensitivity is applied using the ISMS classification scheme augmented with AI-specific categories (training-restricted, evaluation-only, etc.)
Personal data per GDPR Art. 4 and special category data per Art. 9 are explicitly flagged
Intended use classification specifies how each dataset may and may not be used (e.g., training only, evaluation only, prohibited from production inference)
Handling rules per classification (encryption, access control, retention) are defined and enforced through ISMS Controls and DAT Controls
Classification is refreshed when data origin, sensitivity, or intended use materially changes
Misclassification is treated as a data incident per LIF.IR
Personal data per GDPR Art. 4 and special category data per Art. 9 are explicitly flagged
Intended use classification specifies how each dataset may and may not be used (e.g., training only, evaluation only, prohibited from production inference)
Handling rules per classification (encryption, access control, retention) are defined and enforced through ISMS Controls and DAT Controls
Classification is refreshed when data origin, sensitivity, or intended use materially changes
Misclassification is treated as a data incident per LIF.IR
Control Mapping
ISO/IEC 42001:2023 — A.7.3
NIST AI RMF — GOVERN 1.6; MEASURE 2.10
EU AI Act — Art. 10
GDPR — Art. 5; Art. 9; Art. 25; Art. 30
ISO/IEC 5338:2023 — Cl. 6.4.8
OWASP AISVS — C1; C12 (Privacy)
NIST AI RMF — GOVERN 1.6; MEASURE 2.10
EU AI Act — Art. 10
GDPR — Art. 5; Art. 9; Art. 25; Art. 30
ISO/IEC 5338:2023 — Cl. 6.4.8
OWASP AISVS — C1; C12 (Privacy)
DAT.IN-03Foundation model training data summary per EU AI Act Art. 53(1)(d) is produced and maintained for each GPAI modelT 6 · C 6 · F 6
Applies To
Per-GPAI-model training data summary
Commission template adherence
Summary content (sources, types, processing applied, exclusions)
Update triggers
Publication and accessibility
Commission template adherence
Summary content (sources, types, processing applied, exclusions)
Update triggers
Publication and accessibility
Control Details
For each GPAI model developed in-house per IMP.GP-01, a training data summary is produced following the Commission template per Art. 53(1)(d)
Summary content covers data sources used (public web, licensed, proprietary), data types (text, code, images, etc.), processing applied (filtering, deduplication, augmentation), exclusions (rights-holder opt-outs per Art. 53(1)(c))
Summary is produced before placing the model on the market and updated when training data materially changes (new fine-tune corpus, additional pretraining data)
Summary is published as required by the Act and made accessible to downstream providers and the public
Internal record links the public summary to detailed training records per LIF.TR
Summary content covers data sources used (public web, licensed, proprietary), data types (text, code, images, etc.), processing applied (filtering, deduplication, augmentation), exclusions (rights-holder opt-outs per Art. 53(1)(c))
Summary is produced before placing the model on the market and updated when training data materially changes (new fine-tune corpus, additional pretraining data)
Summary is published as required by the Act and made accessible to downstream providers and the public
Internal record links the public summary to detailed training records per LIF.TR
Control Mapping
ISO/IEC 42001:2023 — A.7.3; A.8
NIST AI RMF — MEASURE 2.8; GOVERN 1.6
EU AI Act — Art. 53(1)(d); Annex XI
EU GPAI Code of Practice (Transparency Chapter); (Copyright Chapter)
ISO/IEC 5338:2023 — Cl. 6.4.8
OWASP AISVS — C1; C6 (Supply Chain)
NIST AI RMF — MEASURE 2.8; GOVERN 1.6
EU AI Act — Art. 53(1)(d); Annex XI
EU GPAI Code of Practice (Transparency Chapter); (Copyright Chapter)
ISO/IEC 5338:2023 — Cl. 6.4.8
OWASP AISVS — C1; C6 (Supply Chain)
DAT.IN-04Dataset lifecycle tracking and inventory review — covering ingestion, transformation, use, archival, and disposal — are performed and auditedT 6 · C 6 · F 6
Applies To
Lifecycle stage tracking per dataset
Inventory review schedule (at minimum quarterly)
Discrepancy resolution
Lifecycle event audit
Linkage with retention per DAT.RE
Inventory review schedule (at minimum quarterly)
Discrepancy resolution
Lifecycle event audit
Linkage with retention per DAT.RE
Control Details
Each dataset's lifecycle stage (ingested, in-use, archived, disposed) is tracked in the inventory
Inventory review at minimum quarterly verifies completeness and accuracy by reconciling with operational systems (data lake catalogues, training pipeline logs, vector store registry)
Discrepancies (datasets in use but not catalogued, catalogued but not in use, classification mismatches) are resolved through investigation
Lifecycle events (ingestion, transformation, archive, disposal) are audited per defined cadence and on incident
Linkage with retention per DAT.RE ensures lifecycle transitions trigger retention enforcement
Inventory review at minimum quarterly verifies completeness and accuracy by reconciling with operational systems (data lake catalogues, training pipeline logs, vector store registry)
Discrepancies (datasets in use but not catalogued, catalogued but not in use, classification mismatches) are resolved through investigation
Lifecycle events (ingestion, transformation, archive, disposal) are audited per defined cadence and on incident
Linkage with retention per DAT.RE ensures lifecycle transitions trigger retention enforcement
Control Mapping
ISO/IEC 42001:2023 — A.4.3; A.7.3; A.7.5
NIST AI RMF — GOVERN 1.6; GOVERN 1.5
EU AI Act — Art. 10; Art. 12
GDPR — Art. 5(1)(e); Art. 30
ISO/IEC 5338:2023 — Cl. 6.4.8
OWASP AISVS — C1; C3 (Model Lifecycle Management)
NIST AI RMF — GOVERN 1.6; GOVERN 1.5
EU AI Act — Art. 10; Art. 12
GDPR — Art. 5(1)(e); Art. 30
ISO/IEC 5338:2023 — Cl. 6.4.8
OWASP AISVS — C1; C3 (Model Lifecycle Management)
DAT.PRData Provenance and Lineage3 Controls
Description: Data provenance and lineage for AI — covering data source attestation, origin documentation, lineage tracking across the data lifecycle, third-party data provenance verification, agentic tool-use trace provenance, and provenance evidence for audit — is established, maintained, and used
DAT.PR-01Data source provenance and attestation — covering origin documentation, sourcing legitimacy, and supplier attestation — are established per AI datasetT 6 · C 6 · F 6
Applies To
Data origin documentation per dataset
Sourcing legitimacy assessment (lawful basis, licensing, copyright respect)
Supplier attestation for third-party datasets
Provenance evidence for audit
Material origin change triggers
Sourcing legitimacy assessment (lawful basis, licensing, copyright respect)
Supplier attestation for third-party datasets
Provenance evidence for audit
Material origin change triggers
Control Details
Data origin is documented per dataset, identifying source (public, licensed, generated, customer-provided, third-party purchased)
Sourcing legitimacy is assessed before ingestion — lawful basis per DAT.LB, licensing terms respected, copyright respect per Art. 53(1)(c) and GOV.ET-03
Third-party datasets carry supplier attestation per TPA.CT covering source legitimacy, lawful basis, and use restrictions
Provenance evidence (purchase records, licence agreements, scraping records, source attestations) is retained for audit
Material origin changes (new sources added, supplier changes) trigger re-attestation
Sourcing legitimacy is assessed before ingestion — lawful basis per DAT.LB, licensing terms respected, copyright respect per Art. 53(1)(c) and GOV.ET-03
Third-party datasets carry supplier attestation per TPA.CT covering source legitimacy, lawful basis, and use restrictions
Provenance evidence (purchase records, licence agreements, scraping records, source attestations) is retained for audit
Material origin changes (new sources added, supplier changes) trigger re-attestation
Control Mapping
ISO/IEC 42001:2023 — A.7.3; A.7.4; A.10
NIST AI RMF — MAP 4.1; GOVERN 6.1
EU AI Act — Art. 10; Art. 53(1)(c)
OECD Due Diligence Guidance for Responsible AI
GDPR — Art. 5(1)(a)
ISO/IEC 5338:2023 — Cl. 6.4.8
OWASP AISVS — C1; C6 (Supply Chain)
NIST AI RMF — MAP 4.1; GOVERN 6.1
EU AI Act — Art. 10; Art. 53(1)(c)
OECD Due Diligence Guidance for Responsible AI
GDPR — Art. 5(1)(a)
ISO/IEC 5338:2023 — Cl. 6.4.8
OWASP AISVS — C1; C6 (Supply Chain)
DAT.PR-02Lineage tracking across the AI data lifecycle — from source through training, fine-tuning, evaluation, and inference — is established and maintainedT 6 · C 5 · F 6
Applies To
Lineage tracking from source ingestion through training
Lineage tracking through fine-tuning iterations
Lineage tracking into evaluation / test data
Lineage tracking into RAG corpora and inference context
Agentic tool-use trace provenance per LIF.AG-03 / TRA.AG
Lineage evidence for audit
Lineage tracking through fine-tuning iterations
Lineage tracking into evaluation / test data
Lineage tracking into RAG corpora and inference context
Agentic tool-use trace provenance per LIF.AG-03 / TRA.AG
Lineage evidence for audit
Control Details
Lineage tracking is implemented across the AI data lifecycle so the path from source dataset(s) through processing to model artefact is traceable
Lineage covers training data to trained model; fine-tuning data to fine-tuned model; evaluation data to evaluation results; RAG corpora and inference context to inference outputs
Agentic tool-use trace provenance is captured per LIF.AG-03 and feeds into TRA.AG action logs
Lineage evidence supports auditability (e.g., demonstrating no Restricted data leaked into a public-facing model)
Lineage tooling is documented (MLOps platform, data catalogue, vector store metadata, model registry per LIF.VR)
Lineage covers training data to trained model; fine-tuning data to fine-tuned model; evaluation data to evaluation results; RAG corpora and inference context to inference outputs
Agentic tool-use trace provenance is captured per LIF.AG-03 and feeds into TRA.AG action logs
Lineage evidence supports auditability (e.g., demonstrating no Restricted data leaked into a public-facing model)
Lineage tooling is documented (MLOps platform, data catalogue, vector store metadata, model registry per LIF.VR)
Control Mapping
ISO/IEC 42001:2023 — A.7.3; A.7.5
NIST AI RMF — MAP 4.1; MEASURE 2.8
EU AI Act — Art. 12; Art. 53(1)(a)
ISO/IEC 5338:2023 — Cl. 6.4.8
OWASP AISVS — C1; C3 (Model Lifecycle); C8 (Embeddings / Vector DB)
NIST AI RMF — MAP 4.1; MEASURE 2.8
EU AI Act — Art. 12; Art. 53(1)(a)
ISO/IEC 5338:2023 — Cl. 6.4.8
OWASP AISVS — C1; C3 (Model Lifecycle); C8 (Embeddings / Vector DB)
DAT.PR-03Third-party data provenance verification — covering supplier-provided datasets and third-party model training data — is performed and documentedT 7 · C 6 · F 6
Applies To
Third-party dataset provenance verification at ingestion
Foundation model upstream data provenance (where available)
Supplier attestation review per TPA
Material misalignment handling
Provenance verification record
Foundation model upstream data provenance (where available)
Supplier attestation review per TPA
Material misalignment handling
Provenance verification record
Control Details
Third-party datasets undergo provenance verification at ingestion — supplier attestation per TPA.CT is reviewed and recorded
Foundation model upstream data provenance is reviewed where the provider discloses training data information (model cards, GPAI Art. 53(1)(d) summaries from upstream providers)
Misalignment between supplier attestation and observed dataset content (e.g., copyright concerns, unexpected personal data) is treated as a data incident per LIF.IR
Re-verification is triggered on material supplier change, contract renewal, or upstream provider update
Provenance verification record is maintained per dataset
Foundation model upstream data provenance is reviewed where the provider discloses training data information (model cards, GPAI Art. 53(1)(d) summaries from upstream providers)
Misalignment between supplier attestation and observed dataset content (e.g., copyright concerns, unexpected personal data) is treated as a data incident per LIF.IR
Re-verification is triggered on material supplier change, contract renewal, or upstream provider update
Provenance verification record is maintained per dataset
Control Mapping
ISO/IEC 42001:2023 — A.7.3; A.10
NIST AI RMF — GOVERN 6.1; MANAGE 3.1
EU AI Act — Art. 25; Art. 53; Art. 26
GDPR — Art. 28; Art. 14
EU GPAI Code of Practice (Transparency Chapter)
ISO/IEC 5338:2023 — Cl. 6.4.8
OWASP AISVS — C6 (Supply Chain)
NIST AI RMF — GOVERN 6.1; MANAGE 3.1
EU AI Act — Art. 25; Art. 53; Art. 26
GDPR — Art. 28; Art. 14
EU GPAI Code of Practice (Transparency Chapter)
ISO/IEC 5338:2023 — Cl. 6.4.8
OWASP AISVS — C6 (Supply Chain)
DAT.QUData Quality4 Controls
Description: Data quality across the AI data lifecycle — covering quality criteria (representativeness, completeness, accuracy, consistency, timeliness), quality measurement and monitoring, per-stage application (training, validation, test, fine-tuning, inference), quality treatment and remediation, and quality assurance review — is established, measured, and maintained
DAT.QU-01AI data quality criteria — covering representativeness, completeness, accuracy, consistency, and timeliness — are defined per lifecycle stage and appliedT 6 · C 5 · F 6
Applies To
Quality criteria per data lifecycle stage (training, validation, test, fine-tuning, inference)
Per-criterion thresholds and metrics
Criteria alignment with intended use
Criteria documentation per dataset
Per-criterion thresholds and metrics
Criteria alignment with intended use
Criteria documentation per dataset
Control Details
AI data quality criteria are defined covering representativeness (population coverage, group balance), completeness (missing values, coverage gaps), accuracy (label accuracy, ground truth alignment), consistency (cross-record, cross-source), and timeliness (data recency vs use case)
Criteria are applied per lifecycle stage with appropriate emphasis (e.g., representativeness emphasised for training; accuracy emphasised for evaluation; timeliness emphasised for inference)
Per-criterion thresholds are defined per dataset based on intended use and AI risk class per CON.JU-02
Criteria definitions are documented per dataset and applied during ingestion, transformation, and use
Criteria are applied per lifecycle stage with appropriate emphasis (e.g., representativeness emphasised for training; accuracy emphasised for evaluation; timeliness emphasised for inference)
Per-criterion thresholds are defined per dataset based on intended use and AI risk class per CON.JU-02
Criteria definitions are documented per dataset and applied during ingestion, transformation, and use
Control Mapping
ISO/IEC 42001:2023 — A.7.4; A.7.6
NIST AI RMF — MEASURE 2.5; MEASURE 2.3
EU AI Act — Art. 10(2); Art. 10(3); Art. 15
ISO/IEC 5338:2023 — Cl. 6.4.8
ISO/IEC TS 4213:2022 — Cl. 4.3
NIST SP 1270 (Bias in AI)
OWASP AISVS — C1 (Training Data Integrity)
NIST AI RMF — MEASURE 2.5; MEASURE 2.3
EU AI Act — Art. 10(2); Art. 10(3); Art. 15
ISO/IEC 5338:2023 — Cl. 6.4.8
ISO/IEC TS 4213:2022 — Cl. 4.3
NIST SP 1270 (Bias in AI)
OWASP AISVS — C1 (Training Data Integrity)
DAT.QU-02AI data quality measurement and monitoring — covering ingestion-time assessment and ongoing monitoring — is performed and reportedT 6 · C 5 · F 6
Applies To
Ingestion-time data quality assessment
Ongoing quality monitoring (drift, degradation)
Per-dataset quality metrics dashboard
Quality reporting cadence
Linkage with operational monitoring per LIF.OP
Ongoing quality monitoring (drift, degradation)
Per-dataset quality metrics dashboard
Quality reporting cadence
Linkage with operational monitoring per LIF.OP
Control Details
Data quality is measured at ingestion against criteria per DAT.QU-01; data failing thresholds is quarantined or rejected
Ongoing quality monitoring evaluates dataset drift (distribution change), label-quality degradation, and timeliness for inference datasets
Per-dataset quality metrics are surfaced through a quality dashboard accessible to data owners and AI engineering
Quality reporting cadence is defined per dataset criticality
Operational monitoring per LIF.OP-02 integrates data drift detection with overall AI performance monitoring
Ongoing quality monitoring evaluates dataset drift (distribution change), label-quality degradation, and timeliness for inference datasets
Per-dataset quality metrics are surfaced through a quality dashboard accessible to data owners and AI engineering
Quality reporting cadence is defined per dataset criticality
Operational monitoring per LIF.OP-02 integrates data drift detection with overall AI performance monitoring
Control Mapping
ISO/IEC 42001:2023 — A.7.4
NIST AI RMF — MEASURE 2.5; MEASURE 3.1
EU AI Act — Art. 10(2); Art. 72
ISO/IEC 5338:2023 — Cl. 6.4.8
ISO/IEC TS 4213:2022 — Cl. 4.3
OWASP AISVS — C1; C13 (Monitoring and Logging)
NIST AI RMF — MEASURE 2.5; MEASURE 3.1
EU AI Act — Art. 10(2); Art. 72
ISO/IEC 5338:2023 — Cl. 6.4.8
ISO/IEC TS 4213:2022 — Cl. 4.3
OWASP AISVS — C1; C13 (Monitoring and Logging)
DAT.QU-03AI data quality treatment and remediation — covering cleaning, augmentation, rebalancing, and rejection — are applied where quality issues are identifiedT 6 · C 5 · F 6
Applies To
Treatment options (cleaning, augmentation, rebalancing, exclusion, rejection)
Treatment selection per issue and dataset
Remediation implementation tracking
Treatment effectiveness verification
Dataset re-qualification post-remediation
Treatment selection per issue and dataset
Remediation implementation tracking
Treatment effectiveness verification
Dataset re-qualification post-remediation
Control Details
Treatment options for data quality issues are defined: cleaning (e.g., normalisation, deduplication), augmentation (e.g., adding underrepresented samples), rebalancing (e.g., reweighting), exclusion (removing problematic records), and rejection (discarding the dataset)
Treatment selection follows quality methodology per DAT.QU-01 and considers downstream AI impact
Remediation is tracked to closure with target outcomes
Treatment effectiveness is verified — remediated dataset is re-measured against criteria
Dataset re-qualification post-remediation includes inventory update per DAT.IN and lineage update per DAT.PR-02
Treatment selection follows quality methodology per DAT.QU-01 and considers downstream AI impact
Remediation is tracked to closure with target outcomes
Treatment effectiveness is verified — remediated dataset is re-measured against criteria
Dataset re-qualification post-remediation includes inventory update per DAT.IN and lineage update per DAT.PR-02
Control Mapping
ISO/IEC 42001:2023 — A.7.4
NIST AI RMF — MEASURE 2.5; MANAGE 1.3
EU AI Act — Art. 10(3); Art. 10(4)
ISO/IEC 5338:2023 — Cl. 6.4.8
NIST SP 1270 (Bias in AI)
OWASP AISVS — C1
NIST AI RMF — MEASURE 2.5; MANAGE 1.3
EU AI Act — Art. 10(3); Art. 10(4)
ISO/IEC 5338:2023 — Cl. 6.4.8
NIST SP 1270 (Bias in AI)
OWASP AISVS — C1
DAT.QU-04AI data quality assurance review is performed at defined cadence with findings driving methodology and treatment improvementsT 6 · C 5 · F 6
Applies To
Quality assurance review schedule
Cross-dataset quality posture analysis
Findings escalation to AI governance forums
Improvement integration with continual improvement per GOV.OV-07
Quality KPI reporting per GOV.OV-01
Cross-dataset quality posture analysis
Findings escalation to AI governance forums
Improvement integration with continual improvement per GOV.OV-07
Quality KPI reporting per GOV.OV-01
Control Details
Data quality assurance reviews are performed at defined cadence (at minimum quarterly) covering aggregated quality posture across the AI data inventory
Cross-dataset analysis identifies systemic quality issues (e.g., a class of source consistently failing quality criteria)
Findings are escalated to AI governance forums per GOV.GF where systemic or material
Improvements feed AIMS continual improvement per GOV.OV-07 and quality methodology updates per DAT.PO-03
Quality KPIs are reported per GOV.OV-01
Cross-dataset analysis identifies systemic quality issues (e.g., a class of source consistently failing quality criteria)
Findings are escalated to AI governance forums per GOV.GF where systemic or material
Improvements feed AIMS continual improvement per GOV.OV-07 and quality methodology updates per DAT.PO-03
Quality KPIs are reported per GOV.OV-01
Control Mapping
ISO/IEC 42001:2023 — A.7.4; Cl. 9.1
NIST AI RMF — MEASURE 4.1; GOVERN 1.5
EU AI Act — Art. 10(2); Art. 17(2)(g)
ISO/IEC 5338:2023 — Cl. 6.4.8
OWASP AISVS — C1
NIST AI RMF — MEASURE 4.1; GOVERN 1.5
EU AI Act — Art. 10(2); Art. 17(2)(g)
ISO/IEC 5338:2023 — Cl. 6.4.8
OWASP AISVS — C1
DAT.BIBias-in-Data Measurement and Mitigation4 Controls
Description: Bias-in-data measurement and mitigation — covering bias identification in training and fine-tuning datasets, measurement methodologies (representativeness, demographic balance, label bias), mitigation techniques (sampling, augmentation, reweighting, debiasing), residual bias documentation, and bias monitoring across the data lifecycle — are performed, documented, and maintained
DAT.BI-01Bias identification methodology for AI datasets — covering bias sources, identification techniques, and documentation — is established and appliedT 6 · C 5 · F 6
Applies To
Bias source taxonomy (historical, representation, measurement, aggregation, deployment)
Identification techniques (statistical analysis, demographic auditing, ground-truth review)
Methodology documentation per AI use case
Linkage with fairness measurement per TRU.FA
Methodology approval
Identification techniques (statistical analysis, demographic auditing, ground-truth review)
Methodology documentation per AI use case
Linkage with fairness measurement per TRU.FA
Methodology approval
Control Details
Bias identification methodology categorises bias sources (historical, representation, measurement, aggregation, deployment) per NIST SP 1270 taxonomy
Identification techniques include statistical analysis (group distribution, label distribution by group), demographic auditing, ground-truth review, and known-bias-vector probes
Methodology is documented per AI use case to reflect the bias dimensions relevant to that use case
Methodology integrates with fairness measurement per TRU.FA so bias identified in data translates into fairness criteria evaluation
Methodology is approved per DAT.PO-01
Identification techniques include statistical analysis (group distribution, label distribution by group), demographic auditing, ground-truth review, and known-bias-vector probes
Methodology is documented per AI use case to reflect the bias dimensions relevant to that use case
Methodology integrates with fairness measurement per TRU.FA so bias identified in data translates into fairness criteria evaluation
Methodology is approved per DAT.PO-01
Control Mapping
ISO/IEC 42001:2023 — A.7.4
NIST AI RMF — MAP 5.1; MEASURE 2.11
EU AI Act — Art. 10(2)(f); Art. 10(3); Art. 15
GDPR — Art. 5(1)(a)
ISO/IEC 5338:2023 — Cl. 6.4.8
NIST SP 1270 (Bias in AI)
OWASP AISVS — C1
NIST AI RMF — MAP 5.1; MEASURE 2.11
EU AI Act — Art. 10(2)(f); Art. 10(3); Art. 15
GDPR — Art. 5(1)(a)
ISO/IEC 5338:2023 — Cl. 6.4.8
NIST SP 1270 (Bias in AI)
OWASP AISVS — C1
DAT.BI-02Bias measurement in AI datasets — covering representativeness, demographic balance, label bias, and outcome bias — is performed and documentedT 6 · C 5 · F 6
Applies To
Representativeness measurement (coverage of intended population)
Demographic balance measurement (across protected attributes per applicable jurisdictions)
Label bias measurement (label distribution by group)
Outcome bias measurement (where ground truth is available)
Measurement cadence per dataset
Demographic balance measurement (across protected attributes per applicable jurisdictions)
Label bias measurement (label distribution by group)
Outcome bias measurement (where ground truth is available)
Measurement cadence per dataset
Control Details
Bias measurement is performed per AI dataset using techniques per DAT.BI-01
Representativeness is measured against the intended use population
Demographic balance is measured across protected attributes considered in the AI use case (where lawful and appropriate to measure)
Label bias is measured to detect systematic differences in labels by group
Outcome bias is measured where ground truth is available
Measurement cadence is defined per dataset; measurements are refreshed on material dataset update
Measurements feed bias mitigation per DAT.BI-03 and fairness evaluation per TRU.FA
Representativeness is measured against the intended use population
Demographic balance is measured across protected attributes considered in the AI use case (where lawful and appropriate to measure)
Label bias is measured to detect systematic differences in labels by group
Outcome bias is measured where ground truth is available
Measurement cadence is defined per dataset; measurements are refreshed on material dataset update
Measurements feed bias mitigation per DAT.BI-03 and fairness evaluation per TRU.FA
Control Mapping
ISO/IEC 42001:2023 — A.7.4; A.6.2.7
NIST AI RMF — MEASURE 2.11
EU AI Act — Art. 10(3); Art. 15
ISO/IEC 5338:2023 — Cl. 6.4.8
NIST SP 1270 (Bias in AI)
OWASP AISVS — C1; C12 (Privacy)
NIST AI RMF — MEASURE 2.11
EU AI Act — Art. 10(3); Art. 15
ISO/IEC 5338:2023 — Cl. 6.4.8
NIST SP 1270 (Bias in AI)
OWASP AISVS — C1; C12 (Privacy)
DAT.BI-03Bias mitigation at dataset level — covering sampling, augmentation, reweighting, and debiasing techniques — is applied where bias is identifiedT 6 · C 5 · F 6
Applies To
Sampling techniques (oversampling underrepresented groups, undersampling overrepresented)
Augmentation (synthetic data for underrepresented groups per DAT.SY)
Reweighting (instance-level weight adjustment)
Debiasing transformations
Mitigation effectiveness verification
Augmentation (synthetic data for underrepresented groups per DAT.SY)
Reweighting (instance-level weight adjustment)
Debiasing transformations
Mitigation effectiveness verification
Control Details
Bias mitigation techniques applied at dataset level are selected based on bias source per DAT.BI-01 and dataset characteristics
Sampling adjustments (oversampling / undersampling) are applied with consideration for downstream impact
Augmentation may use synthetic data per DAT.SY when sampling is insufficient
Reweighting adjusts instance weights to compensate for bias without modifying the dataset
Debiasing transformations are applied where appropriate (e.g., decorrelating protected attributes from labels where ethically justifiable)
Mitigation effectiveness is verified through re-measurement per DAT.BI-02; residual bias is documented per DAT.BI-04
Sampling adjustments (oversampling / undersampling) are applied with consideration for downstream impact
Augmentation may use synthetic data per DAT.SY when sampling is insufficient
Reweighting adjusts instance weights to compensate for bias without modifying the dataset
Debiasing transformations are applied where appropriate (e.g., decorrelating protected attributes from labels where ethically justifiable)
Mitigation effectiveness is verified through re-measurement per DAT.BI-02; residual bias is documented per DAT.BI-04
Control Mapping
ISO/IEC 42001:2023 — A.7.4; A.6.2.7
NIST AI RMF — MEASURE 2.11; MANAGE 1.3
EU AI Act — Art. 10(3); Art. 15
ISO/IEC 5338:2023 — Cl. 6.4.8
NIST SP 1270 (Bias in AI)
OWASP AISVS — C1
NIST AI RMF — MEASURE 2.11; MANAGE 1.3
EU AI Act — Art. 10(3); Art. 15
ISO/IEC 5338:2023 — Cl. 6.4.8
NIST SP 1270 (Bias in AI)
OWASP AISVS — C1
DAT.BI-04Residual bias documentation and ongoing monitoring — covering documented residual bias per dataset, monitoring in production, and reporting — are maintainedT 6 · C 6 · F 6
Applies To
Residual bias documentation per dataset
Ongoing bias monitoring in production AI per TRU.FA-05
Residual bias acceptance per RSK.TR-02
Bias reporting to AI governance forums
Bias trend analysis
Ongoing bias monitoring in production AI per TRU.FA-05
Residual bias acceptance per RSK.TR-02
Bias reporting to AI governance forums
Bias trend analysis
Control Details
Residual bias post-mitigation is documented per dataset with magnitude, affected groups, and rationale for acceptance
Ongoing bias monitoring in production AI per TRU.FA-05 surfaces drift and emergent bias
Residual bias above tolerance triggers risk treatment per RSK.TR or acceptance per RSK.TR-02 with appropriate authority
Bias reporting to AI governance forums per GOV.GF includes residual bias posture and trends
Bias trend analysis identifies systemic patterns across datasets
Ongoing bias monitoring in production AI per TRU.FA-05 surfaces drift and emergent bias
Residual bias above tolerance triggers risk treatment per RSK.TR or acceptance per RSK.TR-02 with appropriate authority
Bias reporting to AI governance forums per GOV.GF includes residual bias posture and trends
Bias trend analysis identifies systemic patterns across datasets
Control Mapping
ISO/IEC 42001:2023 — A.7.4; A.6.2.7; Cl. 9.1
NIST AI RMF — MEASURE 2.11; MEASURE 3.1
EU AI Act — Art. 10(3); Art. 15; Art. 17(2)(g)
ISO/IEC 5338:2023 — Cl. 6.4.8
NIST SP 1270 (Bias in AI)
NIST AI RMF — MEASURE 2.11; MEASURE 3.1
EU AI Act — Art. 10(3); Art. 15; Art. 17(2)(g)
ISO/IEC 5338:2023 — Cl. 6.4.8
NIST SP 1270 (Bias in AI)
DAT.LBLawful Basis and Data Subject Rights for AI5 Controls
Description: Lawful basis and data subject rights for AI data processing — covering lawful basis determination per GDPR Art. 6, special category data restrictions per Art. 9, data subject rights enabling for AI processing (Art. 15–22), automated decision-making rights and safeguards per Art. 22, and consent management where AI processing relies on consent — are established, documented, and maintained
DAT.LB-01Lawful basis determination per AI processing activity — covering GDPR Art. 6 grounds and Art. 9 special category restrictions — is performed and documentedT 6 · C 5 · F 6
Applies To
Lawful basis assessment per AI processing activity per CON.JU-04
Art. 6 basis selection (consent, contract, legal obligation, vital interests, public task, legitimate interests)
Art. 9 special category data assessment
Legitimate interests assessment where used
Lawful basis documentation in Art. 30 record of processing
Art. 6 basis selection (consent, contract, legal obligation, vital interests, public task, legitimate interests)
Art. 9 special category data assessment
Legitimate interests assessment where used
Lawful basis documentation in Art. 30 record of processing
Control Details
Lawful basis is determined per AI processing activity involving personal data per CON.JU-04
Art. 6 lawful basis selection is documented with justification per processing activity (training, fine-tuning, inference)
Where Art. 9 special category data is processed, an Art. 9(2) exception is identified and documented
Where legitimate interests is the basis, an Art. 6(1)(f) legitimate interests assessment is performed and documented including balancing test against data subject rights and freedoms
Lawful basis is documented in the GDPR Art. 30 record of processing
Lawful basis is reviewed when processing materially changes per IMP.DA-01
Art. 6 lawful basis selection is documented with justification per processing activity (training, fine-tuning, inference)
Where Art. 9 special category data is processed, an Art. 9(2) exception is identified and documented
Where legitimate interests is the basis, an Art. 6(1)(f) legitimate interests assessment is performed and documented including balancing test against data subject rights and freedoms
Lawful basis is documented in the GDPR Art. 30 record of processing
Lawful basis is reviewed when processing materially changes per IMP.DA-01
Control Mapping
ISO/IEC 42001:2023 — A.7.4
NIST AI RMF — GOVERN 1.1; MEASURE 2.10
EU AI Act — Art. 10(5)
GDPR — Art. 5(1)(a); Art. 6; Art. 9; Art. 30
NIST AI RMF — GOVERN 1.1; MEASURE 2.10
EU AI Act — Art. 10(5)
GDPR — Art. 5(1)(a); Art. 6; Art. 9; Art. 30
DAT.LB-02Data subject rights enabling for AI processing — covering Art. 15-22 rights operationalised for AI — is established and maintainedT 6 · C 6 · F 6
Applies To
Right of access (Art. 15) for AI-processed personal data
Right to rectification (Art. 16) including AI-derived inferences
Right to erasure (Art. 17) including training data subject erasure where feasible
Right to data portability (Art. 20)
Right to object (Art. 21)
Process for handling rights requests on AI-processed data
Right to rectification (Art. 16) including AI-derived inferences
Right to erasure (Art. 17) including training data subject erasure where feasible
Right to data portability (Art. 20)
Right to object (Art. 21)
Process for handling rights requests on AI-processed data
Control Details
Data subject rights are enabled for AI processing through documented processes for handling Art. 15-21 requests
Right of access requests include AI-derived data about the subject where applicable
Rectification requests cover AI-inferred attributes where reasonable
Right to erasure for training data subjects is handled per Art. 17(1) considerations; technical infeasibility (e.g., trained model parameters) is documented and alternative mitigations applied
Portability and objection rights are operationalised through defined processes
Rights request handling is integrated with broader GDPR rights processes and tracked for response within statutory timelines
Right of access requests include AI-derived data about the subject where applicable
Rectification requests cover AI-inferred attributes where reasonable
Right to erasure for training data subjects is handled per Art. 17(1) considerations; technical infeasibility (e.g., trained model parameters) is documented and alternative mitigations applied
Portability and objection rights are operationalised through defined processes
Rights request handling is integrated with broader GDPR rights processes and tracked for response within statutory timelines
Control Mapping
ISO/IEC 42001:2023 — A.7.4; A.8
NIST AI RMF — GOVERN 1.1; MEASURE 2.10
EU AI Act — Art. 86
GDPR — Art. 12; Art. 15; Art. 16; Art. 17; Art. 18; Art. 20; Art. 21
NIST AI RMF — GOVERN 1.1; MEASURE 2.10
EU AI Act — Art. 86
GDPR — Art. 12; Art. 15; Art. 16; Art. 17; Art. 18; Art. 20; Art. 21
DAT.LB-03Automated decision-making rights and safeguards per GDPR Art. 22 — covering identification of Art. 22 scenarios, safeguards, and exercise of rights — are establishedT 6 · C 6 · F 6
Applies To
Art. 22 scenario identification (decisions based solely on automated processing with legal or significant effects)
Safeguards per Art. 22(3) (human intervention, expression of view, contestation)
Linkage with EU AI Act Art. 86 right to explanation
Notification to data subjects per Art. 13(2)(f) / Art. 14(2)(g)
Process for exercising Art. 22 rights
Safeguards per Art. 22(3) (human intervention, expression of view, contestation)
Linkage with EU AI Act Art. 86 right to explanation
Notification to data subjects per Art. 13(2)(f) / Art. 14(2)(g)
Process for exercising Art. 22 rights
Control Details
Art. 22 scenarios are identified per CON.JU-04 for AI involving solely automated decisions with legal or significant effects
Safeguards per Art. 22(3) include the right to obtain human intervention per HUM.UA-03, express the data subject's view, and contest the decision per HUM.UA-02
Linkage with EU AI Act Art. 86 right to explanation per HUM.UA-02 ensures explanations are provided
Notification to data subjects per Art. 13(2)(f) and Art. 14(2)(g) covers existence of automated decision-making and meaningful information about the logic involved
Process for handling Art. 22 rights exercises is documented and integrated with broader rights handling
Safeguards per Art. 22(3) include the right to obtain human intervention per HUM.UA-03, express the data subject's view, and contest the decision per HUM.UA-02
Linkage with EU AI Act Art. 86 right to explanation per HUM.UA-02 ensures explanations are provided
Notification to data subjects per Art. 13(2)(f) and Art. 14(2)(g) covers existence of automated decision-making and meaningful information about the logic involved
Process for handling Art. 22 rights exercises is documented and integrated with broader rights handling
Control Mapping
ISO/IEC 42001:2023 — A.7.4; A.6.2.8
NIST AI RMF — GOVERN 1.1; MAP 3.5
EU AI Act — Art. 86; Art. 14; Art. 26(11); Art. 50(3)
GDPR — Art. 22; Art. 13(2)(f); Art. 14(2)(g)
NIST AI RMF — GOVERN 1.1; MAP 3.5
EU AI Act — Art. 86; Art. 14; Art. 26(11); Art. 50(3)
GDPR — Art. 22; Art. 13(2)(f); Art. 14(2)(g)
DAT.LB-04Consent management where AI processing relies on consent — covering valid consent collection, withdrawal handling, and record-keeping — is operatedT 6 · C 5 · F 6
Applies To
Consent collection for AI processing where consent is the lawful basis
Consent specificity (per processing purpose, per AI use case)
Withdrawal handling
Consent record-keeping per Art. 7
Re-consent on material change
Consent specificity (per processing purpose, per AI use case)
Withdrawal handling
Consent record-keeping per Art. 7
Re-consent on material change
Control Details
Where consent is the GDPR Art. 6(1)(a) or Art. 9(2)(a) lawful basis for AI processing, valid consent is collected per Art. 7 requirements (freely given, specific, informed, unambiguous)
Consent is collected per AI processing purpose; bundled consent is avoided
Withdrawal of consent is enabled at any time per Art. 7(3) and is as easy to withdraw as to give; withdrawal triggers cessation of consent-based processing
Consent records are maintained per Art. 7(1) demonstrating valid consent
Material change to processing triggers re-consent
Consent is collected per AI processing purpose; bundled consent is avoided
Withdrawal of consent is enabled at any time per Art. 7(3) and is as easy to withdraw as to give; withdrawal triggers cessation of consent-based processing
Consent records are maintained per Art. 7(1) demonstrating valid consent
Material change to processing triggers re-consent
Control Mapping
ISO/IEC 42001:2023 — A.7.4
NIST AI RMF — GOVERN 1.1; MEASURE 2.10
EU AI Act — Art. 10(5)
GDPR — Art. 4(11); Art. 6(1)(a); Art. 7; Art. 8; Art. 9(2)(a)
NIST AI RMF — GOVERN 1.1; MEASURE 2.10
EU AI Act — Art. 10(5)
GDPR — Art. 4(11); Art. 6(1)(a); Art. 7; Art. 8; Art. 9(2)(a)
DAT.LB-05International data transfers for AI processing per GDPR Art. 44–49 — covering transfer mechanism selection, Transfer Impact Assessment, supplementary measures, and per-transfer record-keeping — are established and maintainedT 6 · C 5 · F 6
Applies To
Per-transfer mapping (data category, recipient identity, recipient jurisdiction, transfer purpose, transfer mechanism)
Transfer mechanism selection per Chapter V (adequacy decisions per Art. 45; appropriate safeguards per Art. 46 including SCCs; derogations per Art. 49)
EU-US Data Privacy Framework (DPF) adequacy tracking and contingency
Transfer Impact Assessment (TIA) per Schrems II
Supplementary measures (technical, contractual, organisational) where TIA identifies residual risk
Per-transfer record-keeping linked to ROPA per Art. 30
Vendor-side transfer evidence per TPA.DD
Transfer mechanism selection per Chapter V (adequacy decisions per Art. 45; appropriate safeguards per Art. 46 including SCCs; derogations per Art. 49)
EU-US Data Privacy Framework (DPF) adequacy tracking and contingency
Transfer Impact Assessment (TIA) per Schrems II
Supplementary measures (technical, contractual, organisational) where TIA identifies residual risk
Per-transfer record-keeping linked to ROPA per Art. 30
Vendor-side transfer evidence per TPA.DD
Control Details
International transfers of personal data involved in AI activities (training, fine-tuning, inference, RAG, agent operation) are mapped — data category, recipient identity, recipient jurisdiction, transfer purpose, and transfer mechanism per AI activity
Transfer mechanism selection follows GDPR Chapter V hierarchy — adequacy decisions per Art. 45 where applicable (including the EU-US Data Privacy Framework adequacy decision of July 2023); appropriate safeguards per Art. 46 — particularly Standard Contractual Clauses Module 2 (controller-to-processor) or Module 3 (processor-to-processor) per Commission Implementing Decision (EU) 2021/914; derogations per Art. 49 only in narrow, documented circumstances
EU-US Data Privacy Framework adequacy is tracked given ongoing legal challenge; a contingency mechanism (SCCs plus TIA) is maintained for DPF-reliant transfers so that any adequacy disruption does not interrupt processing legality
Transfer Impact Assessment per Schrems II (CJEU C-311/18) is performed per transfer to non-adequate third country covering recipient-jurisdiction law (government access powers, surveillance regime, available judicial redress); methodology follows EDPB Recommendations 01/2020 and 02/2020
Supplementary measures are applied where TIA identifies residual risk — technical (end-to-end encryption with provider-no-access, strong pseudonymisation), contractual (additional safeguards beyond SCCs), or organisational (access restriction, audit rights)
Per-transfer record-keeping is linked to ROPA per Art. 30 and to vendor records per TPA.DD-03; transfer mechanism, TIA outcome, and supplementary measures are evidenced for each transfer
Vendor-side transfer evidence (vendor SCCs, vendor TIA, sub-processor disclosures) is collected as part of due diligence per TPA.DD-03 and contractual coverage per TPA.CT-01
Transfer mechanism selection follows GDPR Chapter V hierarchy — adequacy decisions per Art. 45 where applicable (including the EU-US Data Privacy Framework adequacy decision of July 2023); appropriate safeguards per Art. 46 — particularly Standard Contractual Clauses Module 2 (controller-to-processor) or Module 3 (processor-to-processor) per Commission Implementing Decision (EU) 2021/914; derogations per Art. 49 only in narrow, documented circumstances
EU-US Data Privacy Framework adequacy is tracked given ongoing legal challenge; a contingency mechanism (SCCs plus TIA) is maintained for DPF-reliant transfers so that any adequacy disruption does not interrupt processing legality
Transfer Impact Assessment per Schrems II (CJEU C-311/18) is performed per transfer to non-adequate third country covering recipient-jurisdiction law (government access powers, surveillance regime, available judicial redress); methodology follows EDPB Recommendations 01/2020 and 02/2020
Supplementary measures are applied where TIA identifies residual risk — technical (end-to-end encryption with provider-no-access, strong pseudonymisation), contractual (additional safeguards beyond SCCs), or organisational (access restriction, audit rights)
Per-transfer record-keeping is linked to ROPA per Art. 30 and to vendor records per TPA.DD-03; transfer mechanism, TIA outcome, and supplementary measures are evidenced for each transfer
Vendor-side transfer evidence (vendor SCCs, vendor TIA, sub-processor disclosures) is collected as part of due diligence per TPA.DD-03 and contractual coverage per TPA.CT-01
Control Mapping
ISO/IEC 42001:2023 — A.7.4; A.10
NIST AI RMF — GOVERN 1.1; GOVERN 6.1; MEASURE 2.10
EU AI Act — Art. 10 (data governance interface)
GDPR — Art. 44; Art. 45; Art. 46(2)(c); Art. 49; Art. 30
EDPB Recommendations 01/2020 (Supplementary Measures)
EDPB Recommendations 02/2020 (European Essential Guarantees)
CJEU C-311/18 (Schrems II)
Commission Implementing Decision (EU) 2023/1795 (EU-US Data Privacy Framework)
Commission Implementing Decision (EU) 2021/914 (Standard Contractual Clauses)
NIST AI RMF — GOVERN 1.1; GOVERN 6.1; MEASURE 2.10
EU AI Act — Art. 10 (data governance interface)
GDPR — Art. 44; Art. 45; Art. 46(2)(c); Art. 49; Art. 30
EDPB Recommendations 01/2020 (Supplementary Measures)
EDPB Recommendations 02/2020 (European Essential Guarantees)
CJEU C-311/18 (Schrems II)
Commission Implementing Decision (EU) 2023/1795 (EU-US Data Privacy Framework)
Commission Implementing Decision (EU) 2021/914 (Standard Contractual Clauses)
DAT.REData Minimisation and Retention for AI3 Controls
Description: Data minimisation and retention for AI — covering minimisation in data collection and processing across the AI lifecycle, retention schedules for training, validation, fine-tuning, and inference data, lawful disposal at end of retention, and retention review — are established, documented, and applied
DAT.RE-01Data minimisation in collection and processing — covering necessity assessment, purpose limitation, and use restriction — is applied across the AI data lifecycleT 6 · C 5 · F 6
Applies To
Necessity assessment per data class and lifecycle stage
Purpose limitation enforcement
Use restriction (e.g., training data not used for inference logging)
Minimisation in inference (prompt and response handling)
Aggregation and anonymisation where applicable
Purpose limitation enforcement
Use restriction (e.g., training data not used for inference logging)
Minimisation in inference (prompt and response handling)
Aggregation and anonymisation where applicable
Control Details
Data minimisation is applied — only data necessary for the AI's intended purpose is collected and processed
Necessity assessment per data class and lifecycle stage justifies what is collected (e.g., training corpus content vs metadata; inference inputs vs logging of those inputs)
Purpose limitation is enforced — data collected for one purpose is not reused for another without lawful basis per DAT.LB
Use restriction (e.g., training data not used for retention of inference logs; inference logs not used for training without consent or re-basis) is enforced through technical and process Controls
Inference-time minimisation handles prompts and responses with appropriate retention
Aggregation and anonymisation reduce identifiability where appropriate per TRU.PE
Necessity assessment per data class and lifecycle stage justifies what is collected (e.g., training corpus content vs metadata; inference inputs vs logging of those inputs)
Purpose limitation is enforced — data collected for one purpose is not reused for another without lawful basis per DAT.LB
Use restriction (e.g., training data not used for retention of inference logs; inference logs not used for training without consent or re-basis) is enforced through technical and process Controls
Inference-time minimisation handles prompts and responses with appropriate retention
Aggregation and anonymisation reduce identifiability where appropriate per TRU.PE
Control Mapping
ISO/IEC 42001:2023 — A.7.5
NIST AI RMF — MEASURE 2.10; GOVERN 1.2
EU AI Act — Art. 10(5)
GDPR — Art. 5(1)(b); Art. 5(1)(c); Art. 25
OWASP AISVS — C12 (Privacy)
NIST AI RMF — MEASURE 2.10; GOVERN 1.2
EU AI Act — Art. 10(5)
GDPR — Art. 5(1)(b); Art. 5(1)(c); Art. 25
OWASP AISVS — C12 (Privacy)
DAT.RE-02Retention schedules per AI data class — covering training data, validation data, fine-tuning data, inference logs, and model artefacts — are defined and appliedT 6 · C 6 · F 6
Applies To
Retention schedule per data class
Schedule rationale (lawful basis, business purpose, regulatory)
Schedule enforcement
Exception handling
Schedule review
Schedule rationale (lawful basis, business purpose, regulatory)
Schedule enforcement
Exception handling
Schedule review
Control Details
Retention schedules are defined per AI data class — training corpus, validation / test sets, fine-tuning data, inference inputs / outputs, embeddings, model artefacts
Schedule rationale ties retention to lawful basis per DAT.LB-01 and business purpose
Schedules are enforced through technical Controls (automated deletion, archival) and process Controls (review and approval)
Exceptions (e.g., extended retention for ongoing dispute, audit, or scientific research per GDPR Art. 89) are documented and time-bound
Schedules are reviewed at minimum annually and on material context change
Schedule rationale ties retention to lawful basis per DAT.LB-01 and business purpose
Schedules are enforced through technical Controls (automated deletion, archival) and process Controls (review and approval)
Exceptions (e.g., extended retention for ongoing dispute, audit, or scientific research per GDPR Art. 89) are documented and time-bound
Schedules are reviewed at minimum annually and on material context change
Control Mapping
ISO/IEC 42001:2023 — A.7.5
NIST AI RMF — MEASURE 2.10; GOVERN 1.7
EU AI Act — Art. 12
GDPR — Art. 5(1)(e); Art. 17
NIST AI RMF — MEASURE 2.10; GOVERN 1.7
EU AI Act — Art. 12
GDPR — Art. 5(1)(e); Art. 17
DAT.RE-03Lawful disposal at end of retention — covering deletion, anonymisation, and verification — is performed for AI data classesT 6 · C 5 · F 6
Applies To
Disposal trigger per retention schedule
Disposal method per data class (secure deletion, anonymisation, destruction)
Disposal verification
Disposal of derived artefacts (embeddings, model parameters where feasible)
Disposal record-keeping
Disposal method per data class (secure deletion, anonymisation, destruction)
Disposal verification
Disposal of derived artefacts (embeddings, model parameters where feasible)
Disposal record-keeping
Control Details
Disposal is triggered per retention schedule per DAT.RE-02
Disposal method is selected per data class — secure deletion for storage, anonymisation where data may be retained in aggregate, physical destruction for media
Disposal verification confirms data is no longer accessible
Derived artefacts (embeddings derived from disposed source data, trained model parameters incorporating disposed training data) are handled per documented approach — where infeasible to remove, residual risk is documented per DAT.BI-04 / RSK.TR-02
Disposal records are maintained per Art. 17 erasure and audit requirements
Disposal method is selected per data class — secure deletion for storage, anonymisation where data may be retained in aggregate, physical destruction for media
Disposal verification confirms data is no longer accessible
Derived artefacts (embeddings derived from disposed source data, trained model parameters incorporating disposed training data) are handled per documented approach — where infeasible to remove, residual risk is documented per DAT.BI-04 / RSK.TR-02
Disposal records are maintained per Art. 17 erasure and audit requirements
Control Mapping
ISO/IEC 42001:2023 — A.7.5
NIST AI RMF — MEASURE 2.10; GOVERN 1.7
EU AI Act — Art. 12
GDPR — Art. 5(1)(e); Art. 17(1); Art. 32
NIST AI RMF — MEASURE 2.10; GOVERN 1.7
EU AI Act — Art. 12
GDPR — Art. 5(1)(e); Art. 17(1); Art. 32
DAT.SYSynthetic Data Governance3 Controls
Description: Synthetic data governance — covering synthetic data generation methodology, validation against intended use, marking and traceability, use restrictions, re-identification risk where intersecting with personal data, and synthetic data lifecycle — is established, documented, and maintained
DAT.SY-01Synthetic data generation methodology and validation against intended use — covering generation approach, validation criteria, and quality assurance — are establishedT 6 · C 6 · F 6
Applies To
Synthetic data generation approaches (rule-based, generative models, perturbation)
Validation criteria against intended use
Quality assurance for synthetic data
Generation methodology documentation
Generation approval per use case
Validation criteria against intended use
Quality assurance for synthetic data
Generation methodology documentation
Generation approval per use case
Control Details
Synthetic data generation methodology is documented per use case (e.g., synthetic data for underrepresented group augmentation per DAT.BI-03, synthetic data for testing, synthetic data for privacy-preserving development)
Validation criteria assess synthetic data utility for the intended use (statistical fidelity, downstream model performance, edge-case coverage)
Quality assurance for synthetic data leverages DAT.QU criteria adapted for synthetic data characteristics
Generation methodology documentation supports auditability and reproducibility
Generation is approved per use case per AI governance forums per GOV.GF where material
Validation criteria assess synthetic data utility for the intended use (statistical fidelity, downstream model performance, edge-case coverage)
Quality assurance for synthetic data leverages DAT.QU criteria adapted for synthetic data characteristics
Generation methodology documentation supports auditability and reproducibility
Generation is approved per use case per AI governance forums per GOV.GF where material
Control Mapping
ISO/IEC 42001:2023 — A.7.4
NIST AI RMF — MAP 2.3; MEASURE 2.5
EU AI Act — Art. 10
ISO/IEC 5338:2023 — Cl. 6.4.8
NIST AI 100-4 (Reducing Risks from Synthetic Content)
OWASP AISVS — C1
NIST AI RMF — MAP 2.3; MEASURE 2.5
EU AI Act — Art. 10
ISO/IEC 5338:2023 — Cl. 6.4.8
NIST AI 100-4 (Reducing Risks from Synthetic Content)
OWASP AISVS — C1
DAT.SY-02Synthetic data marking, traceability, and use restrictions — covering identification of synthetic data, lineage tracking, and use boundary enforcement — are appliedT 6 · C 6 · F 6
Applies To
Synthetic data marking (metadata flags, watermarks where applicable)
Lineage tracking per DAT.PR-02 with synthetic origin
Use restrictions per use case (e.g., synthetic for testing only; not for production training without review)
Mixing controls (synthetic + real data handling)
Audit traceability
Lineage tracking per DAT.PR-02 with synthetic origin
Use restrictions per use case (e.g., synthetic for testing only; not for production training without review)
Mixing controls (synthetic + real data handling)
Audit traceability
Control Details
Synthetic data is marked with metadata indicating synthetic origin and generation methodology
Lineage tracking per DAT.PR-02 preserves synthetic origin through the data lifecycle
Use restrictions per use case prevent inappropriate use (e.g., synthetic data not used to claim representativeness of populations it does not actually represent)
Mixing controls govern how synthetic and real data are combined in datasets, with documentation of proportions and rationale
Audit traceability ensures synthetic origin is identifiable in downstream artefacts
Lineage tracking per DAT.PR-02 preserves synthetic origin through the data lifecycle
Use restrictions per use case prevent inappropriate use (e.g., synthetic data not used to claim representativeness of populations it does not actually represent)
Mixing controls govern how synthetic and real data are combined in datasets, with documentation of proportions and rationale
Audit traceability ensures synthetic origin is identifiable in downstream artefacts
Control Mapping
ISO/IEC 42001:2023 — A.7.3; A.7.4
NIST AI RMF — MEASURE 2.8
EU AI Act — Art. 10; Art. 50(2)
ISO/IEC 5338:2023 — Cl. 6.4.8
NIST AI 100-4 (Reducing Risks from Synthetic Content)
OWASP AISVS — C1
NIST AI RMF — MEASURE 2.8
EU AI Act — Art. 10; Art. 50(2)
ISO/IEC 5338:2023 — Cl. 6.4.8
NIST AI 100-4 (Reducing Risks from Synthetic Content)
OWASP AISVS — C1
DAT.SY-03Re-identification risk assessment for synthetic data — covering personal data origin, re-identification testing, and residual risk acceptance — is performedT 6 · C 6 · F 6
Applies To
Re-identification risk for synthetic data derived from personal data
Re-identification testing (membership inference, attribute inference)
Privacy budget management (where differential privacy is used per TRU.PE)
Residual risk documentation and acceptance per RSK.TR-02
Re-assessment on material change
Re-identification testing (membership inference, attribute inference)
Privacy budget management (where differential privacy is used per TRU.PE)
Residual risk documentation and acceptance per RSK.TR-02
Re-assessment on material change
Control Details
Where synthetic data is derived from personal data, re-identification risk assessment is performed before use
Re-identification testing applies appropriate techniques (membership inference attack simulation, attribute inference, k-anonymity-style analysis)
Privacy budget management is documented where differential privacy is used per TRU.PE-02
Residual re-identification risk is documented and accepted per RSK.TR-02
Re-assessment is triggered on material change to generation methodology or downstream use
Re-identification testing applies appropriate techniques (membership inference attack simulation, attribute inference, k-anonymity-style analysis)
Privacy budget management is documented where differential privacy is used per TRU.PE-02
Residual re-identification risk is documented and accepted per RSK.TR-02
Re-assessment is triggered on material change to generation methodology or downstream use
Control Mapping
ISO/IEC 42001:2023 — A.7.4
NIST AI RMF — MEASURE 2.10; MAP 5.1
EU AI Act — Art. 10(5)
GDPR — Art. 4(5); Recital 26
ISO/IEC 5338:2023 — Cl. 6.4.8
NIST AI 100-4 (Reducing Risks from Synthetic Content)
OWASP AISVS — C12 (Privacy)
NIST AI RMF — MEASURE 2.10; MAP 5.1
EU AI Act — Art. 10(5)
GDPR — Art. 4(5); Recital 26
ISO/IEC 5338:2023 — Cl. 6.4.8
NIST AI 100-4 (Reducing Risks from Synthetic Content)
OWASP AISVS — C12 (Privacy)
DAT.LAData Labelling and Annotation Governance3 Controls
Description: Data labelling and annotation governance — covering labelling guidelines, annotator competence and training, inter-annotator agreement and quality control, ethical and labour considerations for annotation workforce, and labelling provenance — is established, documented, and maintained
DAT.LA-01Data labelling and annotation guidelines and quality control — covering labelling schema, instructions, and inter-annotator agreement — are establishedT 6 · C 6 · F 6
Applies To
Labelling schema definition per use case
Annotator instructions and edge-case handling guidance
Inter-annotator agreement measurement
Quality control sampling
Schema versioning
Annotator instructions and edge-case handling guidance
Inter-annotator agreement measurement
Quality control sampling
Schema versioning
Control Details
Labelling schema is defined per AI use case with documented label categories and definitions
Annotator instructions cover schema interpretation, edge-case handling, and ambiguity escalation
Inter-annotator agreement is measured (e.g., Cohen's kappa, Fleiss' kappa) and addressed where below threshold
Quality control sampling reviews a defined fraction of annotations for accuracy and consistency
Schema versioning is maintained; schema changes trigger re-labelling consideration
Annotator instructions cover schema interpretation, edge-case handling, and ambiguity escalation
Inter-annotator agreement is measured (e.g., Cohen's kappa, Fleiss' kappa) and addressed where below threshold
Quality control sampling reviews a defined fraction of annotations for accuracy and consistency
Schema versioning is maintained; schema changes trigger re-labelling consideration
Control Mapping
ISO/IEC 42001:2023 — A.7.4; A.7.6
NIST AI RMF — MAP 2.3; MEASURE 2.5
EU AI Act — Art. 10(2)(g)
ISO/IEC 5338:2023 — Cl. 6.4.8
OWASP AISVS — C1
NIST AI RMF — MAP 2.3; MEASURE 2.5
EU AI Act — Art. 10(2)(g)
ISO/IEC 5338:2023 — Cl. 6.4.8
OWASP AISVS — C1
DAT.LA-02Annotator competence and training — covering competence requirements, training, and ongoing capability assessment — are establishedT 6 · C 5 · F 6
Applies To
Annotator competence requirements per labelling task complexity
Training programme for annotators
Initial competence verification
Ongoing capability assessment
Refresher training on schema changes
Training programme for annotators
Initial competence verification
Ongoing capability assessment
Refresher training on schema changes
Control Details
Annotator competence requirements are defined per labelling task complexity (general-purpose, specialised, subject-matter expertise required)
Training programme covers schema, instructions, edge-case handling, ethical considerations, and quality expectations
Initial competence verification (calibration tasks, qualification assessment) confirms annotators meet requirements before production labelling
Ongoing capability assessment monitors annotation quality and identifies competence drift
Refresher training is provided on schema changes per DAT.LA-01 or material quality issues
Training programme covers schema, instructions, edge-case handling, ethical considerations, and quality expectations
Initial competence verification (calibration tasks, qualification assessment) confirms annotators meet requirements before production labelling
Ongoing capability assessment monitors annotation quality and identifies competence drift
Refresher training is provided on schema changes per DAT.LA-01 or material quality issues
Control Mapping
ISO/IEC 42001:2023 — A.7.4; A.4.6
NIST AI RMF — GOVERN 2.2; MAP 1.2
EU AI Act — Art. 10(2)(g)
ISO/IEC 5338:2023 — Cl. 6.4.8
OWASP AISVS — C1
NIST AI RMF — GOVERN 2.2; MAP 1.2
EU AI Act — Art. 10(2)(g)
ISO/IEC 5338:2023 — Cl. 6.4.8
OWASP AISVS — C1
DAT.LA-03Ethical and labour considerations for the annotation workforce — covering working conditions, exposure to harmful content, and fair labour practices — are establishedT 6 · C 5 · F 6
Applies To
Working conditions for annotators (in-house and outsourced)
Exposure to potentially harmful content (CSAM, violent, harassing)
Wellness support for annotators exposed to harmful content
Fair labour practices per OECD Due Diligence Guidance
Supplier diligence per TPA where annotation is outsourced
Exposure to potentially harmful content (CSAM, violent, harassing)
Wellness support for annotators exposed to harmful content
Fair labour practices per OECD Due Diligence Guidance
Supplier diligence per TPA where annotation is outsourced
Control Details
Working conditions for annotators (in-house and outsourced) align with organisational labour standards and applicable law
Exposure to potentially harmful content (during content moderation labelling, harm classification annotation) is minimised through content filtering, time limits, and rotation
Wellness support including mental health resources is provided to annotators exposed to harmful content
Fair labour practices per OECD Due Diligence Guidance for Responsible AI are required of annotation suppliers
Supplier diligence per TPA.DD includes annotation labour ethics review
Exposure to potentially harmful content (during content moderation labelling, harm classification annotation) is minimised through content filtering, time limits, and rotation
Wellness support including mental health resources is provided to annotators exposed to harmful content
Fair labour practices per OECD Due Diligence Guidance for Responsible AI are required of annotation suppliers
Supplier diligence per TPA.DD includes annotation labour ethics review
Control Mapping
ISO/IEC 42001:2023 — A.7.4; A.10
NIST AI RMF — GOVERN 3.1; GOVERN 1.2
OECD Due Diligence Guidance for Responsible AI
OECD AI Principles (OECD/LEGAL/0449)
Council of Europe Framework Convention on AI (2024)
ISO/IEC 5338:2023 — Cl. 6.4.8
NIST AI RMF — GOVERN 3.1; GOVERN 1.2
OECD Due Diligence Guidance for Responsible AI
OECD AI Principles (OECD/LEGAL/0449)
Council of Europe Framework Convention on AI (2024)
ISO/IEC 5338:2023 — Cl. 6.4.8
DAT.LKAI Data Leakage Prevention3 Controls
Description: AI data leakage prevention — covering training-time data exposure prevention, model regurgitation of training data, runtime data leakage through inference outputs, agentic context and memory leakage, and leakage testing — is established, monitored, and maintained
DAT.LK-01Training-time data exposure prevention — covering Restricted data exclusion, memorisation reduction, and access governance — is establishedT 7 · C 6 · F 6
Applies To
Restricted data exclusion from training datasets
Memorisation reduction techniques (deduplication, differential privacy, regularisation)
Training environment access control per ISMS
Pre-training data screening
Audit of training data composition
Memorisation reduction techniques (deduplication, differential privacy, regularisation)
Training environment access control per ISMS
Pre-training data screening
Audit of training data composition
Control Details
Restricted data is excluded from training datasets unless explicitly authorised per DAT.IN-02 classification and DAT.LB lawful basis
Memorisation reduction techniques are applied per use case (deduplication, differential privacy per TRU.PE-02, regularisation) to reduce training data leakage in model outputs
Training environment access control is enforced through ISMS Identity & Access Management Controls, supplemented by AI-specific Controls per LIF.DV-02
Pre-training data screening detects and removes inappropriate content (PII, copyrighted content beyond licence, harmful content)
Audit of training data composition verifies inclusion / exclusion compliance
Memorisation reduction techniques are applied per use case (deduplication, differential privacy per TRU.PE-02, regularisation) to reduce training data leakage in model outputs
Training environment access control is enforced through ISMS Identity & Access Management Controls, supplemented by AI-specific Controls per LIF.DV-02
Pre-training data screening detects and removes inappropriate content (PII, copyrighted content beyond licence, harmful content)
Audit of training data composition verifies inclusion / exclusion compliance
Control Mapping
ISO/IEC 42001:2023 — A.7.4; A.6.2
NIST AI RMF — MEASURE 2.7; MEASURE 2.10
EU AI Act — Art. 10; Art. 15
GDPR — Art. 5; Art. 32
ISO/IEC 5338:2023 — Cl. 6.4.8
NIST AI 100-2 (Adversarial Machine Learning Taxonomy)
OWASP AISVS — C1; C12 (Privacy)
NIST AI RMF — MEASURE 2.7; MEASURE 2.10
EU AI Act — Art. 10; Art. 15
GDPR — Art. 5; Art. 32
ISO/IEC 5338:2023 — Cl. 6.4.8
NIST AI 100-2 (Adversarial Machine Learning Taxonomy)
OWASP AISVS — C1; C12 (Privacy)
DAT.LK-02Output-side leakage prevention — covering model regurgitation, membership inference resistance, and output filtering — is establishedT 7 · C 6 · F 6
Applies To
Model regurgitation detection and reduction
Membership inference resistance
Output filtering for sensitive content
Output monitoring for leakage signals per LIF.OP-04
Treatment of leakage incidents
Membership inference resistance
Output filtering for sensitive content
Output monitoring for leakage signals per LIF.OP-04
Treatment of leakage incidents
Control Details
Model regurgitation (verbatim training data in outputs) is detected through canary insertion, output scanning, and adversarial probing per RSK.AR-02
Membership inference resistance is evaluated through standard tests and addressed via TRU.PE techniques where required
Output filtering for sensitive content (PII, secrets, copyrighted content) is implemented at inference time
Output monitoring per LIF.OP-04 surfaces leakage signals
Leakage incidents are treated as AI incidents per LIF.IR
Membership inference resistance is evaluated through standard tests and addressed via TRU.PE techniques where required
Output filtering for sensitive content (PII, secrets, copyrighted content) is implemented at inference time
Output monitoring per LIF.OP-04 surfaces leakage signals
Leakage incidents are treated as AI incidents per LIF.IR
Control Mapping
ISO/IEC 42001:2023 — A.7.4; A.6.2
NIST AI RMF — MEASURE 2.7; MEASURE 2.10
EU AI Act — Art. 15
GDPR — Art. 5(1)(f); Art. 32
ISO/IEC 5338:2023 — Cl. 6.4.8
NIST AI 100-2 (Adversarial Machine Learning Taxonomy)
OWASP Top 10 LLM (LLM02 Sensitive Information Disclosure)
OWASP AISVS — C12 (Privacy)
NIST AI RMF — MEASURE 2.7; MEASURE 2.10
EU AI Act — Art. 15
GDPR — Art. 5(1)(f); Art. 32
ISO/IEC 5338:2023 — Cl. 6.4.8
NIST AI 100-2 (Adversarial Machine Learning Taxonomy)
OWASP Top 10 LLM (LLM02 Sensitive Information Disclosure)
OWASP AISVS — C12 (Privacy)
DAT.LK-03Runtime and agentic context leakage prevention — covering session isolation, memory boundaries, and cross-agent data flow controls — is establishedT 6 · C 6 · F 6
Applies To
Session isolation for AI inference
Memory boundaries for agentic systems per LIF.AG-04
Cross-agent data flow controls in multi-agent systems
RAG corpus access governance
Tool-call data leakage prevention
Memory boundaries for agentic systems per LIF.AG-04
Cross-agent data flow controls in multi-agent systems
RAG corpus access governance
Tool-call data leakage prevention
Control Details
Session isolation ensures AI inference for one user / session does not leak data to another (e.g., shared embedding caches isolated, per-session context not persisted across users)
Memory boundaries for agentic systems per LIF.AG-04 prevent inappropriate context retention across tasks or users
Cross-agent data flow controls in multi-agent systems prevent sensitive data from one agent leaking to another beyond authorised boundaries
RAG corpus access governance ensures agent queries respect document-level access controls
Tool-call data leakage prevention restricts what AI passes to external tools
Memory boundaries for agentic systems per LIF.AG-04 prevent inappropriate context retention across tasks or users
Cross-agent data flow controls in multi-agent systems prevent sensitive data from one agent leaking to another beyond authorised boundaries
RAG corpus access governance ensures agent queries respect document-level access controls
Tool-call data leakage prevention restricts what AI passes to external tools
Control Mapping
ISO/IEC 42001:2023 — A.7.4; A.6.2
NIST AI RMF — MEASURE 2.7; MEASURE 2.10
EU AI Act — Art. 15
GDPR — Art. 5(1)(f); Art. 32
ISO/IEC 5338:2023 — Cl. 6.4.8
OWASP AISVS — C8 (Memory / Embeddings / Vector DB); C9 (Orchestration and Agentic Action); C12 (Privacy)
OWASP Top 10 for Agentic Apps
OWASP Multi-Agentic System Threat Modelling Guide
NIST AI RMF — MEASURE 2.7; MEASURE 2.10
EU AI Act — Art. 15
GDPR — Art. 5(1)(f); Art. 32
ISO/IEC 5338:2023 — Cl. 6.4.8
OWASP AISVS — C8 (Memory / Embeddings / Vector DB); C9 (Orchestration and Agentic Action); C12 (Privacy)
OWASP Top 10 for Agentic Apps
OWASP Multi-Agentic System Threat Modelling Guide
Lifecycle49 Controls · 11 Objectives
LIF.POAI Lifecycle Policy and Process3 Controls
Description: The AI system lifecycle policy and process — covering defined lifecycle stages (design, development, training, validation, deployment, operation, decommissioning), stage-gate criteria and approvals, role-specific lifecycle application (provider product lifecycle, deployer use lifecycle, internal-developer lifecycle), and lifecycle process review — is documented, communicated, and maintained
LIF.PO-01The AI system lifecycle policy and process document — covering defined lifecycle stages, governance per stage, and policy approval — is documented, communicated, and maintainedT 6 · C 6 · F 6
Applies To
AI lifecycle policy document
Defined lifecycle stages (design, development, training, validation, deployment, operation, retirement)
Stage governance and ownership per stage
Process documentation
Approval authority
Defined lifecycle stages (design, development, training, validation, deployment, operation, retirement)
Stage governance and ownership per stage
Process documentation
Approval authority
Control Details
The AI system lifecycle policy is documented as a formal artefact, approved at appropriate authority level
The policy defines lifecycle stages — design per LIF.DE, development per LIF.DV, training per LIF.TR, validation per LIF.VA, deployment per LIF.DP, operation per LIF.OP, decommissioning per LIF.DC — with agentic considerations addressed per LIF.AG
Stage governance assigns ownership and decision rights per stage in alignment with GOV.RR
Process documentation describes the flow across stages, hand-offs, and stage-specific evidence requirements
Policy is communicated to AI engineering, MLOps, AI safety, AI ethics, and AI operations
Policy alignment with ISO 5338 and ISO 42001 A.6 expectations is maintained
The policy defines lifecycle stages — design per LIF.DE, development per LIF.DV, training per LIF.TR, validation per LIF.VA, deployment per LIF.DP, operation per LIF.OP, decommissioning per LIF.DC — with agentic considerations addressed per LIF.AG
Stage governance assigns ownership and decision rights per stage in alignment with GOV.RR
Process documentation describes the flow across stages, hand-offs, and stage-specific evidence requirements
Policy is communicated to AI engineering, MLOps, AI safety, AI ethics, and AI operations
Policy alignment with ISO 5338 and ISO 42001 A.6 expectations is maintained
Control Mapping
ISO/IEC 42001:2023 — Cl. 8.1; A.6.1; A.6.2
NIST AI RMF — GOVERN 1.3; GOVERN 1.4
EU AI Act — Art. 17(2)
ISO/IEC 5338:2023 — Cl. 5.3; Cl. 6.2.1
OWASP AISVS — C3 (Model Lifecycle Management)
OWASP AI Testing Guide — 3.0 Framework
NIST AI RMF — GOVERN 1.3; GOVERN 1.4
EU AI Act — Art. 17(2)
ISO/IEC 5338:2023 — Cl. 5.3; Cl. 6.2.1
OWASP AISVS — C3 (Model Lifecycle Management)
OWASP AI Testing Guide — 3.0 Framework
LIF.PO-02Stage-gate criteria and approval authorities — covering go / no-go criteria, approval authority per stage, and evidence required at each gate — are defined and appliedT 6 · C 5 · F 6
Applies To
Stage-gate criteria per lifecycle stage
Approval authorities per gate
Evidence required per stage
Gate exception handling
Stage-gate record-keeping
Approval authorities per gate
Evidence required per stage
Gate exception handling
Stage-gate record-keeping
Control Details
Stage-gate criteria are defined per lifecycle transition (design to development, development to training, training to validation, validation to deployment, deployment to operation, operation to retirement)
Criteria include readiness conditions, required evidence (impact assessment per IMP.IA, risk assessment per RSK.AS, validation results per LIF.VA, security review per LIF.DV)
Approval authorities are defined per gate in alignment with GOV.RR-03 decision rights
Gate exceptions (e.g., expedited path for low-risk AI) are documented with rationale and time-bound approval
Stage-gate decisions are recorded with rationale and evidence references
Linkage with AI governance forums per GOV.GF ensures material decisions are visible
Criteria include readiness conditions, required evidence (impact assessment per IMP.IA, risk assessment per RSK.AS, validation results per LIF.VA, security review per LIF.DV)
Approval authorities are defined per gate in alignment with GOV.RR-03 decision rights
Gate exceptions (e.g., expedited path for low-risk AI) are documented with rationale and time-bound approval
Stage-gate decisions are recorded with rationale and evidence references
Linkage with AI governance forums per GOV.GF ensures material decisions are visible
Control Mapping
ISO/IEC 42001:2023 — Cl. 8.1; A.6.2.2; A.6.2.3
NIST AI RMF — GOVERN 1.4; MANAGE 1.3
EU AI Act — Art. 17(2)(d); Art. 26(3)
ISO/IEC 5338:2023 — Cl. 6.3.2
OWASP AISVS — C3; C7 (Model Behavior)
OWASP AI Testing Guide — 3.0 Framework
NIST AI RMF — GOVERN 1.4; MANAGE 1.3
EU AI Act — Art. 17(2)(d); Art. 26(3)
ISO/IEC 5338:2023 — Cl. 6.3.2
OWASP AISVS — C3; C7 (Model Behavior)
OWASP AI Testing Guide — 3.0 Framework
LIF.PO-03Role-specific lifecycle application — covering provider product lifecycle, deployer use lifecycle, and internal-developer lifecycle — is documented and appliedT 6 · C 6 · F 6
Applies To
Provider product lifecycle (design through post-market obligations)
Deployer use lifecycle (procurement, deployment, monitoring, retirement)
Internal-developer lifecycle (full development for in-house systems)
Cross-role coordination
Role-specific evidence streams
Deployer use lifecycle (procurement, deployment, monitoring, retirement)
Internal-developer lifecycle (full development for in-house systems)
Cross-role coordination
Role-specific evidence streams
Control Details
The lifecycle policy distinguishes three role-specific paths
Provider product lifecycle covers full design through post-market obligations including conformity considerations per IMP.GP, customer-facing documentation per TRA, and customer migration support per LIF.DC-02
Deployer use lifecycle covers AI procurement per TPA, deployment per LIF.DP-04, use-time monitoring per LIF.OP, and end-of-use handling per LIF.DC
Internal-developer lifecycle covers full development for in-house AI used internally
Cross-role coordination is maintained where a single AI activity spans multiple roles (e.g., fine-tuning a third-party model and shipping the derivative — deployer of base, provider of derivative)
Role-specific evidence streams are maintained per role obligations
Provider product lifecycle covers full design through post-market obligations including conformity considerations per IMP.GP, customer-facing documentation per TRA, and customer migration support per LIF.DC-02
Deployer use lifecycle covers AI procurement per TPA, deployment per LIF.DP-04, use-time monitoring per LIF.OP, and end-of-use handling per LIF.DC
Internal-developer lifecycle covers full development for in-house AI used internally
Cross-role coordination is maintained where a single AI activity spans multiple roles (e.g., fine-tuning a third-party model and shipping the derivative — deployer of base, provider of derivative)
Role-specific evidence streams are maintained per role obligations
Control Mapping
ISO/IEC 42001:2023 — Cl. 8.1; A.6.1; A.10
NIST AI RMF — GOVERN 1.3; GOVERN 6.1
EU AI Act — Art. 16; Art. 26; Art. 53
ISO/IEC 5338:2023 — Cl. 6.2.1
NIST AI RMF — GOVERN 1.3; GOVERN 6.1
EU AI Act — Art. 16; Art. 26; Art. 53
ISO/IEC 5338:2023 — Cl. 6.2.1
LIF.DEAI Design and Requirements Engineering5 Controls
Description: AI system design and requirements engineering — covering AI requirements specification (functional, non-functional, ethical, regulatory), architecture and design decisions, safety-by-design and ethics-by-design principles, design review and approval, and design documentation — are performed, documented, and maintained
LIF.DE-01AI requirements specification — covering functional, non-functional, ethical, and regulatory requirements — is performed per AI system and documentedT 6 · C 6 · F 6
Applies To
Functional requirements (intended use, performance, capability)
Non-functional requirements (accuracy, latency, scalability, reliability)
Ethical requirements per GOV.ET
Regulatory requirements per CON.JU
Requirements documentation per AI system
Non-functional requirements (accuracy, latency, scalability, reliability)
Ethical requirements per GOV.ET
Regulatory requirements per CON.JU
Requirements documentation per AI system
Control Details
AI requirements are specified per AI system at design with full coverage of functional, non-functional, ethical, and regulatory dimensions
Functional requirements address intended use, capability scope, performance expectations, and integration context
Non-functional requirements cover accuracy per TRU.AC, latency, scalability, reliability, robustness per TRU.RB, and safety per TRU.SA
Ethical requirements address ethics principles per GOV.ET-01, fairness criteria per TRU.FA, and applicable ethics constraints
Regulatory requirements address EU AI Act per CON.JU, GDPR per DAT.LB, and contractual obligations
Requirements are documented per AI system and maintained through versioning per LIF.VR
Functional requirements address intended use, capability scope, performance expectations, and integration context
Non-functional requirements cover accuracy per TRU.AC, latency, scalability, reliability, robustness per TRU.RB, and safety per TRU.SA
Ethical requirements address ethics principles per GOV.ET-01, fairness criteria per TRU.FA, and applicable ethics constraints
Regulatory requirements address EU AI Act per CON.JU, GDPR per DAT.LB, and contractual obligations
Requirements are documented per AI system and maintained through versioning per LIF.VR
Control Mapping
ISO/IEC 42001:2023 — A.6.1.3; A.6.2.2; A.6.2.3
NIST AI RMF — MAP 1.6; MAP 1.1
EU AI Act — Art. 9(2); Art. 13; Art. 14; Art. 15
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Design
ISO/IEC 5338:2023 — Cl. 6.4.3
OWASP AI Testing Guide — 3.0 Framework
OWASP AISVS — C3
NIST AI RMF — MAP 1.6; MAP 1.1
EU AI Act — Art. 9(2); Art. 13; Art. 14; Art. 15
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Design
ISO/IEC 5338:2023 — Cl. 6.4.3
OWASP AI Testing Guide — 3.0 Framework
OWASP AISVS — C3
LIF.DE-02AI architecture and design decisions — covering model selection, data flow, integration topology, and trade-off documentation — are performed and documentedT 7 · C 6 · F 6
Applies To
Model architecture selection (or foundation model choice)
Data flow design (training, fine-tuning, inference, retrieval)
Integration topology (microservice, embedded, agentic, MCP)
Build-vs-buy decisions per GOV.ST
Trade-off documentation (accuracy vs latency, capability vs safety, etc.)
Data flow design (training, fine-tuning, inference, retrieval)
Integration topology (microservice, embedded, agentic, MCP)
Build-vs-buy decisions per GOV.ST
Trade-off documentation (accuracy vs latency, capability vs safety, etc.)
Control Details
Architecture and design decisions are documented per AI system, capturing rationale, alternatives considered, and trade-offs accepted
Model architecture selection (or foundation model choice per CON.IN-02) is justified against requirements per LIF.DE-01
Data flow design covers training data flow per DAT, fine-tuning flow, inference flow, retrieval flow for RAG, and agentic flow per LIF.AG
Integration topology decisions (microservice vs embedded, agentic vs non-agentic, MCP usage) are documented
Build-vs-buy decisions align with AI strategy per GOV.ST-04
Trade-off documentation captures explicit decisions on accuracy vs latency, capability vs safety, explainability vs performance
Model architecture selection (or foundation model choice per CON.IN-02) is justified against requirements per LIF.DE-01
Data flow design covers training data flow per DAT, fine-tuning flow, inference flow, retrieval flow for RAG, and agentic flow per LIF.AG
Integration topology decisions (microservice vs embedded, agentic vs non-agentic, MCP usage) are documented
Build-vs-buy decisions align with AI strategy per GOV.ST-04
Trade-off documentation captures explicit decisions on accuracy vs latency, capability vs safety, explainability vs performance
Control Mapping
ISO/IEC 42001:2023 — A.6.2.2; A.6.2.4
NIST AI RMF — MAP 2.1; MAP 1.6
EU AI Act — Art. 11; Art. 16
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Design
ISO/IEC 5338:2023 — Cl. 6.4.4; Cl. 6.4.5
ISO/IEC 23053:2022 — Cl. 6; Cl. 7
OWASP AISVS — C3; C4 (Infrastructure)
NIST AI RMF — MAP 2.1; MAP 1.6
EU AI Act — Art. 11; Art. 16
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Design
ISO/IEC 5338:2023 — Cl. 6.4.4; Cl. 6.4.5
ISO/IEC 23053:2022 — Cl. 6; Cl. 7
OWASP AISVS — C3; C4 (Infrastructure)
LIF.DE-03Safety-by-design and ethics-by-design principles — covering safety constraints, ethical safeguards, and design-time consideration of harm scenarios — are applied per AI systemT 7 · C 6 · F 6
Applies To
Safety-by-design constraints (refusal boundaries, capability limits, sandboxing)
Ethics-by-design considerations (fairness criteria, transparency requirements, user agency)
Harm scenario consideration at design
Linkage with TRU.SA AI safety Controls
Privacy-by-design per DAT.RE and TRU.PE
Ethics-by-design considerations (fairness criteria, transparency requirements, user agency)
Harm scenario consideration at design
Linkage with TRU.SA AI safety Controls
Privacy-by-design per DAT.RE and TRU.PE
Control Details
Safety-by-design constraints are determined at design and embedded into AI architecture (refusal boundaries per TRU.SA, capability limits, sandboxing for agents per LIF.AG-02)
Ethics-by-design considerations include fairness criteria per TRU.FA, transparency requirements per TRA, user agency per HUM.UA, and accessibility
Harm scenario consideration at design uses threat modelling per RSK.AR-01 and impact assessment per IMP.IA
Linkage with TRU.SA AI safety Controls ensures design-time decisions cascade to runtime enforcement
Privacy-by-design per DAT.RE-01 minimisation and TRU.PE PETs is applied where personal data is processed
Ethics-by-design considerations include fairness criteria per TRU.FA, transparency requirements per TRA, user agency per HUM.UA, and accessibility
Harm scenario consideration at design uses threat modelling per RSK.AR-01 and impact assessment per IMP.IA
Linkage with TRU.SA AI safety Controls ensures design-time decisions cascade to runtime enforcement
Privacy-by-design per DAT.RE-01 minimisation and TRU.PE PETs is applied where personal data is processed
Control Mapping
ISO/IEC 42001:2023 — A.6.1.2; A.6.1.3; A.6.2.2; A.6.2.5
NIST AI RMF — GOVERN 1.2; MAP 1.6
EU AI Act — Art. 9(2); Art. 14; Art. 15
OECD AI Principles (OECD/LEGAL/0449)
GDPR — Art. 25
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Design
ISO/IEC 5338:2023 — Cl. 6.4.5
OWASP AISVS — C3; C7 (Model Behavior); C11 (Adversarial Robustness)
NIST AI RMF — GOVERN 1.2; MAP 1.6
EU AI Act — Art. 9(2); Art. 14; Art. 15
OECD AI Principles (OECD/LEGAL/0449)
GDPR — Art. 25
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Design
ISO/IEC 5338:2023 — Cl. 6.4.5
OWASP AISVS — C3; C7 (Model Behavior); C11 (Adversarial Robustness)
LIF.DE-04Design review and approval — covering review scope, participants, evidence required, and approval authority — are performed before progression to developmentT 7 · C 6 · F 6
Applies To
Design review scope per AI system class
Review participants (AI engineering, AI safety, AI ethics, Legal, Privacy, InfoSec)
Evidence required at review (requirements per LIF.DE-01, architecture per LIF.DE-02, design principles per LIF.DE-03)
Approval authority per GOV.RR-03
Review record
Review participants (AI engineering, AI safety, AI ethics, Legal, Privacy, InfoSec)
Evidence required at review (requirements per LIF.DE-01, architecture per LIF.DE-02, design principles per LIF.DE-03)
Approval authority per GOV.RR-03
Review record
Control Details
Design review is performed per AI system before progression to development; depth scales with AI risk class per CON.JU-02 and criticality per CON.IN-01
Review participants include AI engineering, AI safety, AI ethics per GOV.GF-03, Legal, Privacy, InfoSec, and SME representatives
Evidence required includes requirements per LIF.DE-01, architecture decisions per LIF.DE-02, applied design principles per LIF.DE-03, threat model per RSK.AR-01, and initial impact assessment per IMP.IA
Approval authority follows GOV.RR-03; material design changes require re-review
Review record is maintained with findings, action items, and approval
Review participants include AI engineering, AI safety, AI ethics per GOV.GF-03, Legal, Privacy, InfoSec, and SME representatives
Evidence required includes requirements per LIF.DE-01, architecture decisions per LIF.DE-02, applied design principles per LIF.DE-03, threat model per RSK.AR-01, and initial impact assessment per IMP.IA
Approval authority follows GOV.RR-03; material design changes require re-review
Review record is maintained with findings, action items, and approval
Control Mapping
ISO/IEC 42001:2023 — A.6.2.2; A.6.2.3
NIST AI RMF — MEASURE 1.3; GOVERN 4.1
EU AI Act — Art. 17(2)(d)
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Design
ISO/IEC 5338:2023 — Cl. 6.4.6
OWASP AISVS — C3
OWASP AI Testing Guide — 3.0 Framework
NIST AI RMF — MEASURE 1.3; GOVERN 4.1
EU AI Act — Art. 17(2)(d)
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Design
ISO/IEC 5338:2023 — Cl. 6.4.6
OWASP AISVS — C3
OWASP AI Testing Guide — 3.0 Framework
LIF.DE-05AI necessity assessment and solution choice — covering pre-development assessment of whether AI is the appropriate solution, comparison with non-AI alternatives, and documented go/no-go on AI as the selected approach — is performed per AI initiativeT 6 · C 6 · F 6
Applies To
Per-AI-initiative AI-vs-non-AI assessment before design begins
Comparison with non-AI alternatives (rules-based systems, statistical methods, manual processes, hybrid approaches, no-automation status quo)
Trade-off criteria (effectiveness, cost, risk, ethical considerations, regulatory requirements, transparency, maintainability)
Documented go/no-go on AI as the selected approach
Refresh on material change (regulatory shift, capability shift, alternative emergence)
Comparison with non-AI alternatives (rules-based systems, statistical methods, manual processes, hybrid approaches, no-automation status quo)
Trade-off criteria (effectiveness, cost, risk, ethical considerations, regulatory requirements, transparency, maintainability)
Documented go/no-go on AI as the selected approach
Refresh on material change (regulatory shift, capability shift, alternative emergence)
Control Details
AI necessity assessment is performed per AI initiative before design begins — answering whether AI is the appropriate solution for the problem at hand rather than assuming AI is the chosen approach
Comparison with non-AI alternatives covers rules-based systems, statistical methods, manual processes, hybrid AI / non-AI approaches, and the no-automation status quo
Trade-off criteria include effectiveness against the problem, build-and-operate cost, risk per RSK methodology, ethical considerations per GOV.ET, regulatory requirements per CON.JU, transparency and explainability per TRU.EX, maintainability over the AI lifecycle per LIF.DC, and benefit-cost per IMP.IA-05
Documented go/no-go on AI as the selected approach is approved at appropriate authority level per GOV.RR-03; the rationale is recorded with the trade-off analysis
Refresh on material change (regulatory shift, capability shift in non-AI alternatives, emergence of better non-AI options, AI cost trajectory change) reassesses the choice and may trigger decommissioning per LIF.DC-01
Linkage with IMP.IA-05 (benefits and cost-of-errors), LIF.DE-01 (AI requirements specification), and GOV.OB (AI objectives) ensures the AI choice is coherent with strategic intent
Comparison with non-AI alternatives covers rules-based systems, statistical methods, manual processes, hybrid AI / non-AI approaches, and the no-automation status quo
Trade-off criteria include effectiveness against the problem, build-and-operate cost, risk per RSK methodology, ethical considerations per GOV.ET, regulatory requirements per CON.JU, transparency and explainability per TRU.EX, maintainability over the AI lifecycle per LIF.DC, and benefit-cost per IMP.IA-05
Documented go/no-go on AI as the selected approach is approved at appropriate authority level per GOV.RR-03; the rationale is recorded with the trade-off analysis
Refresh on material change (regulatory shift, capability shift in non-AI alternatives, emergence of better non-AI options, AI cost trajectory change) reassesses the choice and may trigger decommissioning per LIF.DC-01
Linkage with IMP.IA-05 (benefits and cost-of-errors), LIF.DE-01 (AI requirements specification), and GOV.OB (AI objectives) ensures the AI choice is coherent with strategic intent
Control Mapping
ISO/IEC 42001:2023 — A.6.1; A.6.2
NIST AI RMF — MANAGE 1.1; MAP 1.1
EU AI Act — Art. 9; Art. 27 (where applicable)
OECD AI Principles (OECD/LEGAL/0449)
OECD Due Diligence Guidance for Responsible AI
ISO/IEC 5338:2023 — Cl. 6.4.1; Cl. 6.4.2
NIST AI RMF — MANAGE 1.1; MAP 1.1
EU AI Act — Art. 9; Art. 27 (where applicable)
OECD AI Principles (OECD/LEGAL/0449)
OECD Due Diligence Guidance for Responsible AI
ISO/IEC 5338:2023 — Cl. 6.4.1; Cl. 6.4.2
LIF.DVSecure AI Development5 Controls
Description: Secure AI development — covering ML pipeline security, AI infrastructure security, component and dependency supply chain integrity, secure coding practices for AI components, model artifact integrity, and development environment security — is established, applied, and maintained
LIF.DV-01ML pipeline security — covering pipeline integrity, secrets management, pipeline access control, and pipeline audit — is established and maintainedT 6 · C 6 · F 6
Applies To
ML pipeline integrity (training, fine-tuning, evaluation pipelines)
Secrets management for pipelines
Pipeline access control
Pipeline audit logging
Pipeline change management
Secrets management for pipelines
Pipeline access control
Pipeline audit logging
Pipeline change management
Control Details
ML pipelines (training, fine-tuning, evaluation, deployment) are designed and operated with integrity protections — code signing, dependency verification, signed artefacts
Secrets management for pipelines uses centralised secret stores per ISMS Identity & Access Management with rotation, scoped access, and audit
Pipeline access control restricts who can execute, modify, or approve pipeline runs per role
Pipeline audit logging captures pipeline executions, parameters, inputs, and outputs feeding LIF.VR-04 and DAT.PR-02
Pipeline change management ensures pipeline modifications go through review and approval
Secrets management for pipelines uses centralised secret stores per ISMS Identity & Access Management with rotation, scoped access, and audit
Pipeline access control restricts who can execute, modify, or approve pipeline runs per role
Pipeline audit logging captures pipeline executions, parameters, inputs, and outputs feeding LIF.VR-04 and DAT.PR-02
Pipeline change management ensures pipeline modifications go through review and approval
Control Mapping
ISO/IEC 42001:2023 — A.6.2.4; A.6.2.5
NIST AI RMF — MEASURE 2.7; GOVERN 6.1
EU AI Act — Art. 15
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Development
ISO/IEC 5338:2023 — Cl. 6.4.9
NIST SP 800-218A (SSDF for AI)
OWASP AISVS — C3 (Model Lifecycle); C4 (Infrastructure); C6 (Supply Chain)
NIST AI RMF — MEASURE 2.7; GOVERN 6.1
EU AI Act — Art. 15
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Development
ISO/IEC 5338:2023 — Cl. 6.4.9
NIST SP 800-218A (SSDF for AI)
OWASP AISVS — C3 (Model Lifecycle); C4 (Infrastructure); C6 (Supply Chain)
LIF.DV-02AI infrastructure security — covering development environments, training infrastructure, and inference infrastructure — is established and maintainedT 6 · C 6 · F 6
Applies To
Development environment security (IDEs, sandboxes, notebooks)
Training infrastructure security (compute clusters, accelerators, network isolation)
Inference infrastructure security (serving clusters, edge deployments)
Multi-tenant isolation where applicable
Infrastructure access governance
Training infrastructure security (compute clusters, accelerators, network isolation)
Inference infrastructure security (serving clusters, edge deployments)
Multi-tenant isolation where applicable
Infrastructure access governance
Control Details
Development environment security covers AI engineer workstations, sandboxes, notebooks with appropriate ISMS-aligned Controls
Training infrastructure security covers compute clusters, accelerators (GPU / TPU), and network isolation; training environments are segregated from production where appropriate
Inference infrastructure security covers serving clusters, edge deployments, and API gateways
Multi-tenant isolation is enforced where multiple AI workloads or customers share infrastructure
Infrastructure access governance leverages ISMS IAM Controls with AI-specific additions (model access scoping, dataset access scoping)
Training infrastructure security covers compute clusters, accelerators (GPU / TPU), and network isolation; training environments are segregated from production where appropriate
Inference infrastructure security covers serving clusters, edge deployments, and API gateways
Multi-tenant isolation is enforced where multiple AI workloads or customers share infrastructure
Infrastructure access governance leverages ISMS IAM Controls with AI-specific additions (model access scoping, dataset access scoping)
Control Mapping
ISO/IEC 42001:2023 — A.6.2.4; A.4.4; A.4.5
NIST AI RMF — MEASURE 2.7
EU AI Act — Art. 15
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Development
ISO/IEC 5338:2023 — Cl. 6.2.2
ISO/IEC 27001:2022 — A.8.1; A.5.15
NIST SP 800-218A
OWASP AISVS — C4 (Infrastructure); C5 (Access Control and Identity)
NIST AI RMF — MEASURE 2.7
EU AI Act — Art. 15
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Development
ISO/IEC 5338:2023 — Cl. 6.2.2
ISO/IEC 27001:2022 — A.8.1; A.5.15
NIST SP 800-218A
OWASP AISVS — C4 (Infrastructure); C5 (Access Control and Identity)
LIF.DV-03AI component and dependency supply chain integrity — covering library, model, and dataset dependencies — is verified and maintainedT 6 · C 6 · F 6
Applies To
AI library and framework dependencies (e.g., PyTorch, transformers libraries)
Pre-trained model dependencies
Dataset dependencies
Container and image dependencies
Software Bill of Materials (SBOM) and AI Bill of Materials (AI BOM) per TPA.SC-02
Pre-trained model dependencies
Dataset dependencies
Container and image dependencies
Software Bill of Materials (SBOM) and AI Bill of Materials (AI BOM) per TPA.SC-02
Control Details
AI component and dependency supply chain integrity covers ML frameworks, pre-trained models per CON.IN-02, datasets per DAT.IN, and container / image artefacts
Dependency verification includes signature checking, hash verification, and provenance attestation
SBOM and AI BOM per TPA.SC-02 are maintained per AI system with dependency inventory
Vulnerable dependencies are identified through vulnerability scanning and remediated per defined SLAs
Supply chain compromise scenarios are addressed in threat modelling per RSK.AR-01 with treatments per RSK.TR
Dependency verification includes signature checking, hash verification, and provenance attestation
SBOM and AI BOM per TPA.SC-02 are maintained per AI system with dependency inventory
Vulnerable dependencies are identified through vulnerability scanning and remediated per defined SLAs
Supply chain compromise scenarios are addressed in threat modelling per RSK.AR-01 with treatments per RSK.TR
Control Mapping
ISO/IEC 42001:2023 — A.6.2.6; A.10
NIST AI RMF — GOVERN 6.1; MAP 4.2
EU AI Act — Art. 15; Art. 25
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Development
ISO/IEC 5338:2023 — Cl. 6.1.1
NIST SP 800-161 (Supply Chain Risk Management)
NIST SP 800-218A
OWASP AISVS — C6 (Supply Chain)
OWASP Top 10 LLM (LLM03 Supply Chain)
NIST AI RMF — GOVERN 6.1; MAP 4.2
EU AI Act — Art. 15; Art. 25
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Development
ISO/IEC 5338:2023 — Cl. 6.1.1
NIST SP 800-161 (Supply Chain Risk Management)
NIST SP 800-218A
OWASP AISVS — C6 (Supply Chain)
OWASP Top 10 LLM (LLM03 Supply Chain)
LIF.DV-04Secure coding practices for AI components — covering AI-specific secure coding, code review, and testing integration — are establishedT 6 · C 5 · F 6
Applies To
AI-specific secure coding (prompt construction, output handling, tool invocation)
Code review including AI-specific concerns
Static and dynamic testing integration
Coding standards for AI components
Linkage with AppSec practices
Code review including AI-specific concerns
Static and dynamic testing integration
Coding standards for AI components
Linkage with AppSec practices
Control Details
AI-specific secure coding standards address prompt construction (avoiding injection vectors), output handling (parsing, sanitisation, escape), tool invocation in agentic systems per LIF.AG-02
Code review includes AI-specific concerns alongside standard AppSec review
Static and dynamic testing integration leverages SAST, DAST, and AI-specific testing tools
Coding standards for AI components reference OWASP AISVS, OWASP Cheat Sheets (AI Agent, RAG, MCP, Secure AI Model Ops, Secure Coding with AI)
Linkage with AppSec practices ensures AI components benefit from broader application security maturity
Code review includes AI-specific concerns alongside standard AppSec review
Static and dynamic testing integration leverages SAST, DAST, and AI-specific testing tools
Coding standards for AI components reference OWASP AISVS, OWASP Cheat Sheets (AI Agent, RAG, MCP, Secure AI Model Ops, Secure Coding with AI)
Linkage with AppSec practices ensures AI components benefit from broader application security maturity
Control Mapping
ISO/IEC 42001:2023 — A.6.2.4
NIST AI RMF — MEASURE 2.7; MEASURE 2.1
EU AI Act — Art. 15
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Development
ISO/IEC 5338:2023 — Cl. 6.4.9
NIST SP 800-218A
OWASP AISVS — C2 (Input Validation); C3; C9 (Orchestration and Agentic Action)
OWASP Top 10 LLM
OWASP Cheat Sheets (AI Agent Security; RAG Security; MCP Security; Secure AI Model Ops; Secure Coding with AI)
NIST AI RMF — MEASURE 2.7; MEASURE 2.1
EU AI Act — Art. 15
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Development
ISO/IEC 5338:2023 — Cl. 6.4.9
NIST SP 800-218A
OWASP AISVS — C2 (Input Validation); C3; C9 (Orchestration and Agentic Action)
OWASP Top 10 LLM
OWASP Cheat Sheets (AI Agent Security; RAG Security; MCP Security; Secure AI Model Ops; Secure Coding with AI)
LIF.DV-05Model artefact integrity controls — covering model storage, signing, verification, and safe loading — are established and maintainedT 6 · C 5 · F 6
Applies To
Model artefact storage and access control
Model signing and verification
Safe loading (avoiding deserialisation vulnerabilities)
Tamper detection
Linkage with version registry per LIF.VR
Model signing and verification
Safe loading (avoiding deserialisation vulnerabilities)
Tamper detection
Linkage with version registry per LIF.VR
Control Details
Model artefacts (weights, configurations, tokenisers) are stored in dedicated repositories with access control aligned to ISMS IAM
Model signing and signature verification ensure artefact integrity from training to deployment
Safe loading practices avoid arbitrary code execution via deserialisation (e.g., preferring safetensors over pickle where feasible)
Tamper detection mechanisms (checksum verification, signed manifests) detect unauthorised modification
Linkage with version registry per LIF.VR-01 ensures every artefact in use is traceable to its origin
Model signing and signature verification ensure artefact integrity from training to deployment
Safe loading practices avoid arbitrary code execution via deserialisation (e.g., preferring safetensors over pickle where feasible)
Tamper detection mechanisms (checksum verification, signed manifests) detect unauthorised modification
Linkage with version registry per LIF.VR-01 ensures every artefact in use is traceable to its origin
Control Mapping
ISO/IEC 42001:2023 — A.6.2.4; A.6.2.5
NIST AI RMF — MEASURE 2.7; GOVERN 6.1
EU AI Act — Art. 15
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Development
ISO/IEC 5338:2023 — Cl. 6.3.5
NIST AI 100-2 (Adversarial Machine Learning Taxonomy)
OWASP AISVS — C3 (Model Lifecycle Management); C6 (Supply Chain)
OWASP Top 10 LLM (LLM03 Supply Chain; LLM04 Data and Model Poisoning)
NIST AI RMF — MEASURE 2.7; GOVERN 6.1
EU AI Act — Art. 15
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Development
ISO/IEC 5338:2023 — Cl. 6.3.5
NIST AI 100-2 (Adversarial Machine Learning Taxonomy)
OWASP AISVS — C3 (Model Lifecycle Management); C6 (Supply Chain)
OWASP Top 10 LLM (LLM03 Supply Chain; LLM04 Data and Model Poisoning)
LIF.TRAI Training Process Governance4 Controls
Description: The AI training process — covering training data preparation, training environment and infrastructure, hyperparameter management, training run documentation and reproducibility, foundation model training (where applicable), and training process review — is established, documented, and maintained
LIF.TR-01Training data preparation and integrity — covering dataset selection, pre-processing, integrity verification, and split discipline — is established per training runT 7 · C 6 · F 6
Applies To
Training dataset selection per requirements per LIF.DE-01
Pre-processing pipeline (tokenisation, normalisation, filtering)
Integrity verification (provenance per DAT.PR, quality per DAT.QU)
Training / validation / test split discipline (no leakage)
Documentation of training data composition
Pre-processing pipeline (tokenisation, normalisation, filtering)
Integrity verification (provenance per DAT.PR, quality per DAT.QU)
Training / validation / test split discipline (no leakage)
Documentation of training data composition
Control Details
Training data selection is performed against requirements per LIF.DE-01 with attention to representativeness per DAT.QU-01 and bias considerations per DAT.BI
Pre-processing pipelines (tokenisation, normalisation, filtering) are documented and version-controlled
Integrity verification confirms provenance per DAT.PR and quality per DAT.QU before training begins
Train / validation / test split discipline prevents data leakage; cross-validation methodology is documented where used
Training data composition is documented per training run including ratios, sources, and exclusions; this documentation feeds GPAI training data summary per DAT.IN-03 where applicable
Pre-processing pipelines (tokenisation, normalisation, filtering) are documented and version-controlled
Integrity verification confirms provenance per DAT.PR and quality per DAT.QU before training begins
Train / validation / test split discipline prevents data leakage; cross-validation methodology is documented where used
Training data composition is documented per training run including ratios, sources, and exclusions; this documentation feeds GPAI training data summary per DAT.IN-03 where applicable
Control Mapping
ISO/IEC 42001:2023 — A.7.4; A.6.2.4
NIST AI RMF — MAP 2.1; MEASURE 2.5
EU AI Act — Art. 10(2); Art. 10(3); Art. 53(1)(d)
EU GPAI Code of Practice (Transparency Chapter)
ISO/IEC 5338:2023 — Cl. 6.4.8
ISO/IEC TS 4213:2022 — Cl. 4.3 (Control criteria including limiting information leakage)
OWASP AISVS — C1 (Training Data Integrity)
NIST AI RMF — MAP 2.1; MEASURE 2.5
EU AI Act — Art. 10(2); Art. 10(3); Art. 53(1)(d)
EU GPAI Code of Practice (Transparency Chapter)
ISO/IEC 5338:2023 — Cl. 6.4.8
ISO/IEC TS 4213:2022 — Cl. 4.3 (Control criteria including limiting information leakage)
OWASP AISVS — C1 (Training Data Integrity)
LIF.TR-02Training environment and infrastructure — covering compute provisioning, environment isolation, and resource governance — are established per training runT 6 · C 6 · F 6
Applies To
Compute provisioning (clusters, accelerators)
Environment isolation from production
Resource governance (budgets, quotas, sustainability)
Environment baseline (reproducible images, dependency versions)
Logging of training environment state
Environment isolation from production
Resource governance (budgets, quotas, sustainability)
Environment baseline (reproducible images, dependency versions)
Logging of training environment state
Control Details
Compute provisioning for training is managed through governed processes with cost and capacity oversight
Training environments are isolated from production environments with clear network and access boundaries
Resource governance applies budgets, quotas, and sustainability considerations (e.g., compute efficiency, carbon awareness for large training runs)
Environment baseline ensures reproducibility — pinned dependencies, container images, hardware specifications recorded per training run
Logging of training environment state supports reproducibility and auditability
Training environments are isolated from production environments with clear network and access boundaries
Resource governance applies budgets, quotas, and sustainability considerations (e.g., compute efficiency, carbon awareness for large training runs)
Environment baseline ensures reproducibility — pinned dependencies, container images, hardware specifications recorded per training run
Logging of training environment state supports reproducibility and auditability
Control Mapping
ISO/IEC 42001:2023 — A.6.2.4; A.4.4; A.4.5
NIST AI RMF — MAP 2.1; MEASURE 2.7
EU AI Act — Art. 15; Art. 53(1)(a)
EU GPAI Code of Practice (Transparency Chapter — compute documentation)
ISO/IEC 5338:2023 — Cl. 6.2.2
NIST SP 800-218A
OWASP AISVS — C4 (Infrastructure)
NIST AI RMF — MAP 2.1; MEASURE 2.7
EU AI Act — Art. 15; Art. 53(1)(a)
EU GPAI Code of Practice (Transparency Chapter — compute documentation)
ISO/IEC 5338:2023 — Cl. 6.2.2
NIST SP 800-218A
OWASP AISVS — C4 (Infrastructure)
LIF.TR-03Training run documentation and reproducibility — covering hyperparameter capture, run metadata, and reproducibility artefacts — are established per training runT 7 · C 6 · F 6
Applies To
Hyperparameter capture per run
Run metadata (dataset references, code version, environment, seeds, durations)
Reproducibility artefacts (configuration files, scripts, checkpoints)
Linkage with model registry per LIF.VR
Documentation supporting GPAI Art. 53 obligations
Run metadata (dataset references, code version, environment, seeds, durations)
Reproducibility artefacts (configuration files, scripts, checkpoints)
Linkage with model registry per LIF.VR
Documentation supporting GPAI Art. 53 obligations
Control Details
Hyperparameter capture records the configuration used per training run (learning rate, batch size, optimiser, schedule, regularisation, etc.)
Run metadata records dataset references per DAT.PR-02, code version, environment baseline per LIF.TR-02, random seeds, duration, and outcomes
Reproducibility artefacts (configuration files, scripts, intermediate checkpoints) enable later reproduction or audit
Linkage with model registry per LIF.VR-01 ensures every trained model is traceable to its training run record
Documentation supports GPAI provider technical documentation per IMP.GP-02 and Art. 53 obligations
Run metadata records dataset references per DAT.PR-02, code version, environment baseline per LIF.TR-02, random seeds, duration, and outcomes
Reproducibility artefacts (configuration files, scripts, intermediate checkpoints) enable later reproduction or audit
Linkage with model registry per LIF.VR-01 ensures every trained model is traceable to its training run record
Documentation supports GPAI provider technical documentation per IMP.GP-02 and Art. 53 obligations
Control Mapping
ISO/IEC 42001:2023 — A.6.2.4; A.7.5
NIST AI RMF — MAP 2.1; MEASURE 2.13
EU AI Act — Art. 11; Art. 53(1)(a); Annex XI
EU GPAI Code of Practice (Transparency Chapter)
ISO/IEC 5338:2023 — Cl. 6.3.6
OWASP AISVS — C1; C3
NIST AI RMF — MAP 2.1; MEASURE 2.13
EU AI Act — Art. 11; Art. 53(1)(a); Annex XI
EU GPAI Code of Practice (Transparency Chapter)
ISO/IEC 5338:2023 — Cl. 6.3.6
OWASP AISVS — C1; C3
LIF.TR-04Foundation model training process governance — covering pretraining decisions, fine-tuning workflows, and safety alignment — is establishedT 7 · C 6 · F 6
Applies To
Foundation model pretraining decisions (data scale, training objectives, alignment objectives)
Fine-tuning workflows (supervised, RLHF, DPO, instruction tuning)
Safety alignment (refusal training, harm reduction)
Capability and dangerous-capability evaluation during training per LIF.VA
Documentation supporting GPAI Art. 53 and Art. 55
Fine-tuning workflows (supervised, RLHF, DPO, instruction tuning)
Safety alignment (refusal training, harm reduction)
Capability and dangerous-capability evaluation during training per LIF.VA
Documentation supporting GPAI Art. 53 and Art. 55
Control Details
Foundation model pretraining is governed where the company develops own foundation models per CON.IN-02; decisions cover data scale, training objectives, and alignment objectives
Fine-tuning workflows (supervised fine-tuning, RLHF, DPO, instruction tuning) are documented per workflow with applied datasets per DAT and methodologies
Safety alignment (refusal training, harm reduction) is integrated into training with measurable outcomes
Capability and dangerous-capability evaluation is performed during training with checkpoints reviewed per LIF.VA-04 and RSK.AR-04
Documentation supports GPAI provider technical documentation per IMP.GP-02 (Art. 53) and systemic-risk obligations per IMP.GP-04 (Art. 55)
Fine-tuning workflows (supervised fine-tuning, RLHF, DPO, instruction tuning) are documented per workflow with applied datasets per DAT and methodologies
Safety alignment (refusal training, harm reduction) is integrated into training with measurable outcomes
Capability and dangerous-capability evaluation is performed during training with checkpoints reviewed per LIF.VA-04 and RSK.AR-04
Documentation supports GPAI provider technical documentation per IMP.GP-02 (Art. 53) and systemic-risk obligations per IMP.GP-04 (Art. 55)
Control Mapping
ISO/IEC 42001:2023 — A.6.2.4; A.7.4
NIST AI RMF — MAP 2.1; MEASURE 2.6
EU AI Act — Art. 53; Art. 55
EU GPAI Code of Practice (Safety and Security Chapter)
ISO/IEC 5338:2023 — Cl. 6.4.7; Cl. 6.4.8
NIST AI 100-2 (Adversarial Machine Learning Taxonomy)
NIST AI 100-4 (Reducing Risks from Synthetic Content)
OWASP AISVS — C3; C7 (Model Behavior)
NIST AI RMF — MAP 2.1; MEASURE 2.6
EU AI Act — Art. 53; Art. 55
EU GPAI Code of Practice (Safety and Security Chapter)
ISO/IEC 5338:2023 — Cl. 6.4.7; Cl. 6.4.8
NIST AI 100-2 (Adversarial Machine Learning Taxonomy)
NIST AI 100-4 (Reducing Risks from Synthetic Content)
OWASP AISVS — C3; C7 (Model Behavior)
LIF.VAAI Validation and Evaluation6 Controls
Description: AI validation and evaluation before deployment — covering performance evaluation against defined metrics, robustness testing, fairness and bias testing, adversarial testing, evaluation suite governance, and validation acceptance criteria — are performed, documented, and used to gate deployment
LIF.VA-01Performance evaluation against defined metrics — covering metric selection, evaluation execution, and performance thresholds — is performed per AI system before deploymentT 6 · C 5 · F 6
Applies To
Metric selection per AI use case per TRU.AC
Evaluation dataset preparation (test sets, benchmarks)
Evaluation execution and result documentation
Performance threshold determination
Linkage with deployment gate per LIF.DP
Evaluation dataset preparation (test sets, benchmarks)
Evaluation execution and result documentation
Performance threshold determination
Linkage with deployment gate per LIF.DP
Control Details
Performance evaluation against defined metrics is performed per AI system before deployment
Metric selection aligns with TRU.AC accuracy and performance criteria per AI use case
Evaluation datasets are prepared with appropriate independence from training data per LIF.TR-01 split discipline
Evaluation execution captures full results, including confidence intervals and per-segment breakdowns
Performance thresholds for deployment are documented and align with stage-gate criteria per LIF.PO-02
Evaluation results feed deployment gate per LIF.DP-01
Metric selection aligns with TRU.AC accuracy and performance criteria per AI use case
Evaluation datasets are prepared with appropriate independence from training data per LIF.TR-01 split discipline
Evaluation execution captures full results, including confidence intervals and per-segment breakdowns
Performance thresholds for deployment are documented and align with stage-gate criteria per LIF.PO-02
Evaluation results feed deployment gate per LIF.DP-01
Control Mapping
ISO/IEC 42001:2023 — A.6.2.7
NIST AI RMF — MEASURE 2.3; MEASURE 2.5
EU AI Act — Art. 15; Art. 17(2)(d)
ISO/IEC 5338:2023 — Cl. 6.4.11; Cl. 6.4.13
ISO/IEC TS 4213:2022 — Cl. 5; Cl. 6
OWASP AI Testing Guide — AITG-MOD-06 (Robustness to New Data); AITG-MOD-07 (Goal Alignment)
OWASP AISVS — C7 (Model Behavior)
NIST AI RMF — MEASURE 2.3; MEASURE 2.5
EU AI Act — Art. 15; Art. 17(2)(d)
ISO/IEC 5338:2023 — Cl. 6.4.11; Cl. 6.4.13
ISO/IEC TS 4213:2022 — Cl. 5; Cl. 6
OWASP AI Testing Guide — AITG-MOD-06 (Robustness to New Data); AITG-MOD-07 (Goal Alignment)
OWASP AISVS — C7 (Model Behavior)
LIF.VA-02Robustness and stress testing — covering perturbation testing, distribution shift testing, and resource stress testing — is performed pre-deploymentT 6 · C 5 · F 6
Applies To
Input perturbation testing
Distribution shift / out-of-distribution testing
Resource stress testing (load, latency under stress)
Edge-case and corner-case testing
Linkage with TRU.RB robustness Controls
Distribution shift / out-of-distribution testing
Resource stress testing (load, latency under stress)
Edge-case and corner-case testing
Linkage with TRU.RB robustness Controls
Control Details
Robustness and stress testing is performed pre-deployment per AI system to evaluate behaviour under non-nominal conditions
Input perturbation testing applies small input changes to assess output stability
Distribution shift / out-of-distribution testing evaluates behaviour on inputs differing from training distribution
Resource stress testing evaluates behaviour under load, concurrency, and latency stress
Edge-case and corner-case testing covers known difficult input classes
Findings feed TRU.RB robustness Controls and may gate deployment per LIF.PO-02
Input perturbation testing applies small input changes to assess output stability
Distribution shift / out-of-distribution testing evaluates behaviour on inputs differing from training distribution
Resource stress testing evaluates behaviour under load, concurrency, and latency stress
Edge-case and corner-case testing covers known difficult input classes
Findings feed TRU.RB robustness Controls and may gate deployment per LIF.PO-02
Control Mapping
ISO/IEC 42001:2023 — A.6.2.7
NIST AI RMF — MEASURE 2.5; MEASURE 2.7
EU AI Act — Art. 15
ISO/IEC 5338:2023 — Cl. 6.4.11
ISO/IEC TR 24029-1:2021 — Cl. 5; Cl. 7
ISO/IEC 24029-2:2023 — Cl. 5; Cl. 7.3
OWASP AI Testing Guide — AITG-MOD-01 (Evasion Attacks); AITG-MOD-06 (Robustness to New Data); AITG-INF-02 (Resource Exhaustion)
OWASP AISVS — C11 (Adversarial Robustness)
NIST AI RMF — MEASURE 2.5; MEASURE 2.7
EU AI Act — Art. 15
ISO/IEC 5338:2023 — Cl. 6.4.11
ISO/IEC TR 24029-1:2021 — Cl. 5; Cl. 7
ISO/IEC 24029-2:2023 — Cl. 5; Cl. 7.3
OWASP AI Testing Guide — AITG-MOD-01 (Evasion Attacks); AITG-MOD-06 (Robustness to New Data); AITG-INF-02 (Resource Exhaustion)
OWASP AISVS — C11 (Adversarial Robustness)
LIF.VA-03Fairness and bias testing — covering per-group performance evaluation and fairness criteria assessment — is performed pre-deploymentT 6 · C 6 · F 6
Applies To
Per-group performance evaluation
Fairness criteria assessment per TRU.FA
Bias measurement extending DAT.BI to model level
Disparity reporting
Residual bias treatment per RSK.TR
Fairness criteria assessment per TRU.FA
Bias measurement extending DAT.BI to model level
Disparity reporting
Residual bias treatment per RSK.TR
Control Details
Fairness and bias testing is performed pre-deployment per AI system to evaluate per-group performance and fairness criteria adherence
Per-group performance evaluation reports metrics across protected attribute groups (where lawful and appropriate to measure) and identified affected groups per IMP.IA-02
Fairness criteria assessment per TRU.FA evaluates against defined criteria (demographic parity, equal opportunity, equalized odds, etc.)
Bias measurement extends DAT.BI dataset-level measurement to model-level outcome bias
Disparity reporting documents findings; material disparities trigger treatment per DAT.BI-03, TRU.FA-03, or RSK.TR
Per-group performance evaluation reports metrics across protected attribute groups (where lawful and appropriate to measure) and identified affected groups per IMP.IA-02
Fairness criteria assessment per TRU.FA evaluates against defined criteria (demographic parity, equal opportunity, equalized odds, etc.)
Bias measurement extends DAT.BI dataset-level measurement to model-level outcome bias
Disparity reporting documents findings; material disparities trigger treatment per DAT.BI-03, TRU.FA-03, or RSK.TR
Control Mapping
ISO/IEC 42001:2023 — A.6.2.7
NIST AI RMF — MEASURE 2.11
EU AI Act — Art. 10(3); Art. 15
ISO/IEC 5338:2023 — Cl. 6.4.13
NIST SP 1270 (Bias in AI)
OWASP AI Testing Guide — AITG-APP-10 (Content Bias); AITG-DAT-03 (Dataset Diversity and Coverage)
OWASP AISVS — C7 (Model Behavior)
NIST AI RMF — MEASURE 2.11
EU AI Act — Art. 10(3); Art. 15
ISO/IEC 5338:2023 — Cl. 6.4.13
NIST SP 1270 (Bias in AI)
OWASP AI Testing Guide — AITG-APP-10 (Content Bias); AITG-DAT-03 (Dataset Diversity and Coverage)
OWASP AISVS — C7 (Model Behavior)
LIF.VA-04Adversarial testing pre-deployment — covering attack-surface testing, red teaming, and capability elicitation — is performed and findings remediatedT 7 · C 6 · F 6
Applies To
Adversarial testing per RSK.AR-04 red teaming programme
Capability elicitation testing for foundation models
Attack-surface testing (prompt injection, jailbreaking, evasion)
Findings management per RSK.TR
Linkage with deployment gate per LIF.DP
Capability elicitation testing for foundation models
Attack-surface testing (prompt injection, jailbreaking, evasion)
Findings management per RSK.TR
Linkage with deployment gate per LIF.DP
Control Details
Adversarial testing is performed pre-deployment per AI system, drawing on the red teaming programme per RSK.AR-04
Capability elicitation testing is performed for foundation models per CON.IN-02 to surface dangerous capabilities, especially for systemic-risk GPAI per IMP.GP-04 / Art. 55
Attack-surface testing covers prompt injection per RSK.AR-03, jailbreaking, evasion attacks per RSK.AR-02
Findings are managed per RSK.TR; material findings may gate deployment per LIF.DP-01
Adversarial testing methodology and findings are documented for audit and regulatory disclosure where applicable
Capability elicitation testing is performed for foundation models per CON.IN-02 to surface dangerous capabilities, especially for systemic-risk GPAI per IMP.GP-04 / Art. 55
Attack-surface testing covers prompt injection per RSK.AR-03, jailbreaking, evasion attacks per RSK.AR-02
Findings are managed per RSK.TR; material findings may gate deployment per LIF.DP-01
Adversarial testing methodology and findings are documented for audit and regulatory disclosure where applicable
Control Mapping
ISO/IEC 42001:2023 — A.6.2.7
NIST AI RMF — MEASURE 2.6; MEASURE 2.7
EU AI Act — Art. 15; Art. 55
EU GPAI Code of Practice (Safety and Security Chapter)
ISO/IEC 5338:2023 — Cl. 6.4.11
NIST AI 100-2 (Adversarial Machine Learning Taxonomy)
OWASP AI Testing Guide — AITG-APP-01 (Prompt Injection); AITG-MOD-01 (Evasion Attacks); AITG-MOD-03 (Poisoned Training Sets)
OWASP GenAI Red Teaming Guide
OWASP AISVS — C11
CSA Agentic AI Red Teaming Guide
NIST AI RMF — MEASURE 2.6; MEASURE 2.7
EU AI Act — Art. 15; Art. 55
EU GPAI Code of Practice (Safety and Security Chapter)
ISO/IEC 5338:2023 — Cl. 6.4.11
NIST AI 100-2 (Adversarial Machine Learning Taxonomy)
OWASP AI Testing Guide — AITG-APP-01 (Prompt Injection); AITG-MOD-01 (Evasion Attacks); AITG-MOD-03 (Poisoned Training Sets)
OWASP GenAI Red Teaming Guide
OWASP AISVS — C11
CSA Agentic AI Red Teaming Guide
LIF.VA-05Versioned evaluation suite gating promotion — covering evaluation suite versioning, gate criteria, and promotion approval — is establishedT 6 · C 6 · F 6
Applies To
Evaluation suite versioning per AI system or model family
Gate criteria thresholds
Promotion decision authority
Evaluation suite review and update
Linkage with model registry per LIF.VR
Gate criteria thresholds
Promotion decision authority
Evaluation suite review and update
Linkage with model registry per LIF.VR
Control Details
A versioned evaluation suite is maintained per AI system or model family, ensuring reproducible evaluation and apples-to-apples comparison across versions
Gate criteria define minimum thresholds across performance per LIF.VA-01, robustness per LIF.VA-02, fairness per LIF.VA-03, and adversarial resilience per LIF.VA-04
Promotion decision authority follows GOV.RR-03 with above-threshold residual issues requiring escalation
Evaluation suite is reviewed and updated when new requirements emerge (new threat classes, new use cases, regulatory changes)
Linkage with model registry per LIF.VR-01 ensures each model version is tied to its evaluation suite version and results
Gate criteria define minimum thresholds across performance per LIF.VA-01, robustness per LIF.VA-02, fairness per LIF.VA-03, and adversarial resilience per LIF.VA-04
Promotion decision authority follows GOV.RR-03 with above-threshold residual issues requiring escalation
Evaluation suite is reviewed and updated when new requirements emerge (new threat classes, new use cases, regulatory changes)
Linkage with model registry per LIF.VR-01 ensures each model version is tied to its evaluation suite version and results
Control Mapping
ISO/IEC 42001:2023 — A.6.2.7
NIST AI RMF — MEASURE 2.13; MEASURE 2.5
EU AI Act — Art. 15; Art. 17(2)(d)
ISO/IEC 5338:2023 — Cl. 6.4.11; Cl. 6.4.13
ISO/IEC TS 4213:2022 — Cl. 7
OWASP AISVS — C3; C7 (Model Behavior)
OWASP AI Testing Guide — 3.2 AI Model Testing
NIST AI RMF — MEASURE 2.13; MEASURE 2.5
EU AI Act — Art. 15; Art. 17(2)(d)
ISO/IEC 5338:2023 — Cl. 6.4.11; Cl. 6.4.13
ISO/IEC TS 4213:2022 — Cl. 7
OWASP AISVS — C3; C7 (Model Behavior)
OWASP AI Testing Guide — 3.2 AI Model Testing
LIF.VA-06Human subjects in AI evaluations — covering identification of human subjects, ethical review, informed consent, debriefing, and legal / regulatory compliance — are governed and documentedT 6 · C 6 · F 6
Applies To
Human subjects identification per AI evaluation (red-teaming participants, user-study participants, A/B test cohorts where awareness is required, real-world testing subjects)
Ethical review process for evaluations involving more than minimal risk
Informed consent and right to withdraw without penalty
Debriefing and post-study welfare
Legal / regulatory compliance (GDPR lawful basis, employment law for paid participants, Member State human-subjects research law where applicable)
Linkage with DAT.LA-03 annotation workforce ethics
Ethical review process for evaluations involving more than minimal risk
Informed consent and right to withdraw without penalty
Debriefing and post-study welfare
Legal / regulatory compliance (GDPR lawful basis, employment law for paid participants, Member State human-subjects research law where applicable)
Linkage with DAT.LA-03 annotation workforce ethics
Control Details
Human subjects in AI evaluations are identified per evaluation — including red-teaming participants, user-study participants, A/B test cohorts where awareness is required, and real-world testing subjects
Ethical review is performed for evaluations involving more than minimal risk — covering risks to participants (psychological harm from exposure to AI-generated content including harmful or unsafe outputs, privacy risk, fairness of compensation)
Informed consent is obtained where required, with the right to withdraw at any time without penalty; consent is informed by clear description of the evaluation, identified risks, and use of resulting data and recordings
Debriefing and post-study welfare include addressing any harm experienced during the evaluation; mental-health support is available for red-team participants exposed to harmful-content categories
Legal and regulatory compliance covers GDPR lawful basis per Art. 6 (typically Art. 6(1)(a) consent or Art. 6(1)(f) legitimate interests with documented LIA per DAT.LB-01), Art. 7 consent conditions, Art. 9 special category data where applicable, Art. 89 safeguards for research, employment law for paid participants, and Member State human-subjects research law
Linkage with DAT.LA-03 annotation workforce ethics ensures consistent treatment of all humans engaged in AI work
Records of human-subjects evaluations are maintained per GOV.DI-01 documented information control
Ethical review is performed for evaluations involving more than minimal risk — covering risks to participants (psychological harm from exposure to AI-generated content including harmful or unsafe outputs, privacy risk, fairness of compensation)
Informed consent is obtained where required, with the right to withdraw at any time without penalty; consent is informed by clear description of the evaluation, identified risks, and use of resulting data and recordings
Debriefing and post-study welfare include addressing any harm experienced during the evaluation; mental-health support is available for red-team participants exposed to harmful-content categories
Legal and regulatory compliance covers GDPR lawful basis per Art. 6 (typically Art. 6(1)(a) consent or Art. 6(1)(f) legitimate interests with documented LIA per DAT.LB-01), Art. 7 consent conditions, Art. 9 special category data where applicable, Art. 89 safeguards for research, employment law for paid participants, and Member State human-subjects research law
Linkage with DAT.LA-03 annotation workforce ethics ensures consistent treatment of all humans engaged in AI work
Records of human-subjects evaluations are maintained per GOV.DI-01 documented information control
Control Mapping
ISO/IEC 42001:2023 — A.6.2
NIST AI RMF — MEASURE 2.2
EU AI Act — Art. 9; Art. 27 (where applicable)
OECD Due Diligence Guidance for Responsible AI
GDPR — Art. 6; Art. 7; Art. 9; Art. 89
ISO/IEC 5338:2023 — Cl. 6.4.13
NIST AI RMF — MEASURE 2.2
EU AI Act — Art. 9; Art. 27 (where applicable)
OECD Due Diligence Guidance for Responsible AI
GDPR — Art. 6; Art. 7; Art. 9; Art. 89
ISO/IEC 5338:2023 — Cl. 6.4.13
LIF.DPAI Deployment and Release Management4 Controls
Description: AI deployment and release management — covering release management process, deployment approvals, controlled rollout (canary, staged, dark launches), release documentation, provider instructions for use issuance, and deployer acceptance testing of consumed AI — are established, applied, and maintained
LIF.DP-01Release management process and deployment approvals — covering release planning, approvals per AI risk class, and deployment record — are establishedT 6 · C 6 · F 6
Applies To
Release management process per AI system class
Deployment approval per GOV.RR-03
Release planning (timing, rollout strategy, dependencies)
Deployment record (version, evaluation, decision, approver)
Pre-deployment go / no-go per IMP.MO-01
Deployment approval per GOV.RR-03
Release planning (timing, rollout strategy, dependencies)
Deployment record (version, evaluation, decision, approver)
Pre-deployment go / no-go per IMP.MO-01
Control Details
Release management process is documented per AI system class with appropriate rigour for criticality and risk class per CON.JU-02
Deployment approval follows GOV.RR-03 decision rights; criticality determines authority required
Release planning includes timing, rollout strategy, dependencies (data, infrastructure, integrations), and customer communication where applicable per TRA.IU
Pre-deployment go / no-go per IMP.MO-01 integrates impact and risk findings into the deployment decision
Deployment record captures the deployed version, evaluation summary, decision, and approver
Deployment approval follows GOV.RR-03 decision rights; criticality determines authority required
Release planning includes timing, rollout strategy, dependencies (data, infrastructure, integrations), and customer communication where applicable per TRA.IU
Pre-deployment go / no-go per IMP.MO-01 integrates impact and risk findings into the deployment decision
Deployment record captures the deployed version, evaluation summary, decision, and approver
Control Mapping
ISO/IEC 42001:2023 — A.6.2.8
NIST AI RMF — MANAGE 1.3; MEASURE 2.5
EU AI Act — Art. 26(3); Art. 17(2)
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Deployment
ISO/IEC 5338:2023 — Cl. 6.4.12
OWASP AISVS — C3 (Model Lifecycle Management)
OWASP AI Testing Guide — 3.0 Framework
NIST AI RMF — MANAGE 1.3; MEASURE 2.5
EU AI Act — Art. 26(3); Art. 17(2)
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Deployment
ISO/IEC 5338:2023 — Cl. 6.4.12
OWASP AISVS — C3 (Model Lifecycle Management)
OWASP AI Testing Guide — 3.0 Framework
LIF.DP-02Controlled rollout — canary, staged, and dark launches — is applied per AI release to limit blast radius and surface issues earlyT 6 · C 6 · F 6
Applies To
Canary deployment to subset of users / requests
Staged rollout across cohorts or geographies
Dark launch (shadow traffic) where applicable
Rollback procedures
Rollout monitoring and abort criteria
Staged rollout across cohorts or geographies
Dark launch (shadow traffic) where applicable
Rollback procedures
Rollout monitoring and abort criteria
Control Details
Controlled rollout is applied per AI release, with strategy selected based on AI criticality, risk class, and customer-impact considerations
Canary deployment routes a subset of users or requests to the new version while monitoring for issues
Staged rollout progresses across cohorts (e.g., internal users, early customers, full availability) with explicit promotion criteria
Dark launch sends production traffic shadow-copy to the new version for evaluation without user-facing impact
Rollback procedures are tested and exercisable within defined time bounds
Rollout monitoring uses metrics per LIF.OP and abort criteria trigger rollback when met
Canary deployment routes a subset of users or requests to the new version while monitoring for issues
Staged rollout progresses across cohorts (e.g., internal users, early customers, full availability) with explicit promotion criteria
Dark launch sends production traffic shadow-copy to the new version for evaluation without user-facing impact
Rollback procedures are tested and exercisable within defined time bounds
Rollout monitoring uses metrics per LIF.OP and abort criteria trigger rollback when met
Control Mapping
ISO/IEC 42001:2023 — A.6.2.8
NIST AI RMF — MANAGE 1.3; MANAGE 2.2
EU AI Act — Art. 15; Art. 26(5); Art. 72
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Deployment
ISO/IEC 5338:2023 — Cl. 6.4.12
OWASP AISVS — C3 (Model Lifecycle Management)
NIST AI RMF — MANAGE 1.3; MANAGE 2.2
EU AI Act — Art. 15; Art. 26(5); Art. 72
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Deployment
ISO/IEC 5338:2023 — Cl. 6.4.12
OWASP AISVS — C3 (Model Lifecycle Management)
LIF.DP-03Provider release documentation and instructions for use — produced per EU AI Act Art. 13 expectations and TRA.IU — accompany every provider releaseT 7 · C 6 · F 6
Applies To
Provider release notes
Instructions for use per TRA.IU
Model / system card per TRA.MC
Release documentation accessibility
Documentation update with material change
Instructions for use per TRA.IU
Model / system card per TRA.MC
Release documentation accessibility
Documentation update with material change
Control Details
Provider release documentation is produced per release covering changes, intended use, limitations, known risks, and migration considerations
Instructions for use per TRA.IU-01 are produced and updated per release in accordance with EU AI Act Art. 13 expectations (applied as best practice for non-high-risk AI)
Model / system cards per TRA.MC-01 are produced and updated to reflect release changes
Release documentation accessibility is provided to deployers / customers through documented channels
Documentation is updated with material change to capability, performance, or known issues
Instructions for use per TRA.IU-01 are produced and updated per release in accordance with EU AI Act Art. 13 expectations (applied as best practice for non-high-risk AI)
Model / system cards per TRA.MC-01 are produced and updated to reflect release changes
Release documentation accessibility is provided to deployers / customers through documented channels
Documentation is updated with material change to capability, performance, or known issues
Control Mapping
ISO/IEC 42001:2023 — A.8; A.6.2.8
NIST AI RMF — MEASURE 2.8; GOVERN 6.1
EU AI Act — Art. 13; Art. 26(6)
EU GPAI Code of Practice (Transparency Chapter)
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Deployment
ISO/IEC 5338:2023 — Cl. 6.4.12
OWASP AISVS — C3
Hugging Face Model Cards
NIST AI RMF — MEASURE 2.8; GOVERN 6.1
EU AI Act — Art. 13; Art. 26(6)
EU GPAI Code of Practice (Transparency Chapter)
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Deployment
ISO/IEC 5338:2023 — Cl. 6.4.12
OWASP AISVS — C3
Hugging Face Model Cards
LIF.DP-04Deployer acceptance testing of consumed AI — covering pre-adoption evaluation, contractual conformance verification, and integration validation — is performedT 6 · C 5 · F 6
Applies To
Pre-adoption evaluation against use-case requirements
Contractual conformance verification per TPA.CT
Integration validation in deployment context
Vendor-supplied artefact verification (model card, evaluation, instructions for use)
Acceptance decision record
Contractual conformance verification per TPA.CT
Integration validation in deployment context
Vendor-supplied artefact verification (model card, evaluation, instructions for use)
Acceptance decision record
Control Details
Deployer acceptance testing is performed when consuming third-party AI per CON.IN-01 deployer inventory
Pre-adoption evaluation assesses fit against use-case requirements, deployer-side performance, and integration considerations
Contractual conformance verification confirms vendor-delivered AI meets contractual specifications per TPA.CT
Integration validation tests the consumed AI in the deployer environment with realistic input distributions
Vendor-supplied artefacts (model card, evaluation results, instructions for use per Art. 13) are reviewed and gaps escalated
Acceptance decision record captures evaluation outcomes, residual risks, and deployment authorisation per GOV.RR-03
Pre-adoption evaluation assesses fit against use-case requirements, deployer-side performance, and integration considerations
Contractual conformance verification confirms vendor-delivered AI meets contractual specifications per TPA.CT
Integration validation tests the consumed AI in the deployer environment with realistic input distributions
Vendor-supplied artefacts (model card, evaluation results, instructions for use per Art. 13) are reviewed and gaps escalated
Acceptance decision record captures evaluation outcomes, residual risks, and deployment authorisation per GOV.RR-03
Control Mapping
ISO/IEC 42001:2023 — A.10; A.6.2.8
NIST AI RMF — MANAGE 3.1; MEASURE 2.5
EU AI Act — Art. 26(1); Art. 26(4); Art. 26(5)
ISO/IEC 5338:2023 — Cl. 6.4.11; Cl. 6.4.12
OWASP AISVS — C3; C6 (Supply Chain)
EU AI Risks Management Guidance (Procuring an AI system)
NIST AI RMF — MANAGE 3.1; MEASURE 2.5
EU AI Act — Art. 26(1); Art. 26(4); Art. 26(5)
ISO/IEC 5338:2023 — Cl. 6.4.11; Cl. 6.4.12
OWASP AISVS — C3; C6 (Supply Chain)
EU AI Risks Management Guidance (Procuring an AI system)
LIF.OPAI Operational Monitoring5 Controls
Description: AI operational monitoring — covering runtime performance monitoring, data and concept drift detection, abuse pattern detection, output safety monitoring, anomalous behaviour detection, retraining triggers, and operational reporting — is established, performed, and maintained
LIF.OP-01Runtime performance monitoring against expected baselines — covering metric collection, baseline comparison, and divergence alerting — is established per AI systemT 6 · C 5 · F 6
Applies To
Performance metric collection per AI system
Baseline comparison (expected vs observed)
Divergence alerting with thresholds
Per-segment performance tracking
Linkage with IMP.MO-02 impact monitoring
Baseline comparison (expected vs observed)
Divergence alerting with thresholds
Per-segment performance tracking
Linkage with IMP.MO-02 impact monitoring
Control Details
Runtime performance monitoring is established per AI system covering accuracy, latency, throughput, and use-case-specific metrics per TRU.AC
Baseline comparison evaluates observed metrics against expected baselines documented at deployment per LIF.VA-01
Divergence alerting fires when metrics breach thresholds, with severity-aligned response
Per-segment performance tracking surfaces issues affecting specific user groups, inputs, or contexts
Monitoring outputs integrate with IMP.MO-02 impact monitoring and AIMS KPI / KRI reporting per GOV.OV-01
Baseline comparison evaluates observed metrics against expected baselines documented at deployment per LIF.VA-01
Divergence alerting fires when metrics breach thresholds, with severity-aligned response
Per-segment performance tracking surfaces issues affecting specific user groups, inputs, or contexts
Monitoring outputs integrate with IMP.MO-02 impact monitoring and AIMS KPI / KRI reporting per GOV.OV-01
Control Mapping
ISO/IEC 42001:2023 — A.6.2.6; Cl. 9.1
NIST AI RMF — MEASURE 2.4; MEASURE 2.5
EU AI Act — Art. 26(5); Art. 72
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Operation and Maintenance
ISO/IEC 5338:2023 — Cl. 6.4.15; Cl. 6.4.14
OWASP AISVS — C13 (Monitoring and Logging)
OWASP AI Testing Guide — AITG-MOD-06 (Robustness to New Data)
NIST AI RMF — MEASURE 2.4; MEASURE 2.5
EU AI Act — Art. 26(5); Art. 72
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Operation and Maintenance
ISO/IEC 5338:2023 — Cl. 6.4.15; Cl. 6.4.14
OWASP AISVS — C13 (Monitoring and Logging)
OWASP AI Testing Guide — AITG-MOD-06 (Robustness to New Data)
LIF.OP-02Data and concept drift detection — covering input distribution monitoring, output drift monitoring, and ground-truth drift — is establishedT 6 · C 5 · F 6
Applies To
Input distribution drift monitoring
Output drift monitoring
Ground-truth drift where applicable (delayed feedback)
Drift detection thresholds and alerting
Linkage with retraining triggers per LIF.OP-05
Output drift monitoring
Ground-truth drift where applicable (delayed feedback)
Drift detection thresholds and alerting
Linkage with retraining triggers per LIF.OP-05
Control Details
Drift detection monitors input distributions for departure from training distribution
Output drift monitoring detects changes in model output distribution that may indicate model degradation or context shift
Ground-truth drift is monitored where feedback is available (delayed label availability)
Drift detection thresholds are calibrated per AI system to balance sensitivity and false-positive rate
Drift signals feed retraining triggers per LIF.OP-05 and AI risk reassessment per RSK.MO-02
Output drift monitoring detects changes in model output distribution that may indicate model degradation or context shift
Ground-truth drift is monitored where feedback is available (delayed label availability)
Drift detection thresholds are calibrated per AI system to balance sensitivity and false-positive rate
Drift signals feed retraining triggers per LIF.OP-05 and AI risk reassessment per RSK.MO-02
Control Mapping
ISO/IEC 42001:2023 — A.6.2.6
NIST AI RMF — MEASURE 2.4; MANAGE 4.1
EU AI Act — Art. 15; Art. 72
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Operation and Maintenance
ISO/IEC 5338:2023 — Cl. 6.4.14
OWASP AISVS — C13 (Monitoring and Logging)
OWASP AI Testing Guide — AITG-MOD-02 (Runtime Model Poisoning); AITG-MOD-06 (Robustness to New Data)
NIST AI RMF — MEASURE 2.4; MANAGE 4.1
EU AI Act — Art. 15; Art. 72
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Operation and Maintenance
ISO/IEC 5338:2023 — Cl. 6.4.14
OWASP AISVS — C13 (Monitoring and Logging)
OWASP AI Testing Guide — AITG-MOD-02 (Runtime Model Poisoning); AITG-MOD-06 (Robustness to New Data)
LIF.OP-03Abuse pattern and adversarial behaviour detection — covering anomalous input detection, jailbreak attempt detection, and rate / pattern analysis — is establishedT 7 · C 6 · F 6
Applies To
Anomalous input detection (prompt injection, evasion attempts)
Jailbreak attempt detection
Rate / pattern analysis (extraction attempts, scraping)
Behavioural anomaly detection in agentic systems per LIF.AG-03
Treatment of detected abuse
Jailbreak attempt detection
Rate / pattern analysis (extraction attempts, scraping)
Behavioural anomaly detection in agentic systems per LIF.AG-03
Treatment of detected abuse
Control Details
Abuse pattern and adversarial behaviour detection extends ISMS detection capabilities with AI-specific signals
Anomalous input detection identifies prompt injection attempts per RSK.AR-03, evasion attempts per RSK.AR-02
Jailbreak attempt detection identifies attempts to circumvent safety boundaries per TRU.SA
Rate / pattern analysis identifies model extraction attempts and scraping
Behavioural anomaly detection in agentic systems per LIF.AG-03 surfaces unusual action patterns
Detected abuse triggers response per LIF.IR with appropriate severity
Anomalous input detection identifies prompt injection attempts per RSK.AR-03, evasion attempts per RSK.AR-02
Jailbreak attempt detection identifies attempts to circumvent safety boundaries per TRU.SA
Rate / pattern analysis identifies model extraction attempts and scraping
Behavioural anomaly detection in agentic systems per LIF.AG-03 surfaces unusual action patterns
Detected abuse triggers response per LIF.IR with appropriate severity
Control Mapping
ISO/IEC 42001:2023 — A.6.2.6
NIST AI RMF — MEASURE 2.7; MANAGE 4.1
EU AI Act — Art. 15; Art. 72
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Operation and Maintenance
ISO/IEC 5338:2023 — Cl. 6.4.15
NIST AI 100-2 (Adversarial Machine Learning Taxonomy)
OWASP AISVS — C11 (Adversarial Robustness); C13 (Monitoring and Logging)
OWASP Top 10 LLM
MITRE ATLAS
NIST AI RMF — MEASURE 2.7; MANAGE 4.1
EU AI Act — Art. 15; Art. 72
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Operation and Maintenance
ISO/IEC 5338:2023 — Cl. 6.4.15
NIST AI 100-2 (Adversarial Machine Learning Taxonomy)
OWASP AISVS — C11 (Adversarial Robustness); C13 (Monitoring and Logging)
OWASP Top 10 LLM
MITRE ATLAS
LIF.OP-04Output safety monitoring — covering harmful output detection, hallucination monitoring, refusal-failure tracking, and PII leakage detection — is establishedT 7 · C 6 · F 6
Applies To
Harmful output detection (toxicity, harassment, illegal content)
Hallucination monitoring
Refusal-failure tracking
PII leakage detection per DAT.LK-02
Output safety reporting
Hallucination monitoring
Refusal-failure tracking
PII leakage detection per DAT.LK-02
Output safety reporting
Control Details
Output safety monitoring evaluates AI outputs in production for safety concerns
Harmful output detection scans for toxicity, harassment, illegal content, CSAM, and other harm categories
Hallucination monitoring detects factual inaccuracies in generative outputs (especially for retrieval-augmented and knowledge-bound use cases)
Refusal-failure tracking detects cases where AI fails to refuse requests it should have refused per TRU.SA boundaries
PII leakage detection per DAT.LK-02 detects personal data disclosure in outputs
Output safety findings feed incident response per LIF.IR and treatment per RSK.TR
Harmful output detection scans for toxicity, harassment, illegal content, CSAM, and other harm categories
Hallucination monitoring detects factual inaccuracies in generative outputs (especially for retrieval-augmented and knowledge-bound use cases)
Refusal-failure tracking detects cases where AI fails to refuse requests it should have refused per TRU.SA boundaries
PII leakage detection per DAT.LK-02 detects personal data disclosure in outputs
Output safety findings feed incident response per LIF.IR and treatment per RSK.TR
Control Mapping
ISO/IEC 42001:2023 — A.6.2.6; A.6.2.5
NIST AI RMF — MEASURE 2.6; MEASURE 2.4
EU AI Act — Art. 15; Art. 72
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Operation and Maintenance
ISO/IEC 5338:2023 — Cl. 6.4.14
OWASP AISVS — C7 (Model Behavior); C12 (Privacy); C13 (Monitoring and Logging)
OWASP Top 10 LLM (LLM02 Sensitive Information Disclosure; LLM09 Misinformation)
NIST AI RMF — MEASURE 2.6; MEASURE 2.4
EU AI Act — Art. 15; Art. 72
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Operation and Maintenance
ISO/IEC 5338:2023 — Cl. 6.4.14
OWASP AISVS — C7 (Model Behavior); C12 (Privacy); C13 (Monitoring and Logging)
OWASP Top 10 LLM (LLM02 Sensitive Information Disclosure; LLM09 Misinformation)
LIF.OP-05Retraining triggers and operational reporting — covering automated triggers, manual triggers, decision authority, and operational reporting cadence — are establishedT 7 · C 6 · F 6
Applies To
Automated retraining triggers (drift thresholds, performance thresholds)
Manual triggers (regulatory change, incident learning)
Retraining decision authority per GOV.RR-03
Retraining cadence per AI system class
Operational reporting to AI governance forums
Manual triggers (regulatory change, incident learning)
Retraining decision authority per GOV.RR-03
Retraining cadence per AI system class
Operational reporting to AI governance forums
Control Details
Retraining triggers are defined per AI system, automated triggers fire when drift per LIF.OP-02, performance per LIF.OP-01, or output safety per LIF.OP-04 thresholds are breached
Manual triggers include material regulatory change, AI incident learning per LIF.IR, material requirement change, and emerging risk per RSK.MO-03
Retraining decision authority follows GOV.RR-03 with above-threshold residual considerations escalated
Retraining cadence per AI system class ensures models are refreshed at minimum cadence regardless of trigger fire
Operational reporting to AI governance forums per GOV.GF and AIMS KPI reporting per GOV.OV-01 maintains visibility
Manual triggers include material regulatory change, AI incident learning per LIF.IR, material requirement change, and emerging risk per RSK.MO-03
Retraining decision authority follows GOV.RR-03 with above-threshold residual considerations escalated
Retraining cadence per AI system class ensures models are refreshed at minimum cadence regardless of trigger fire
Operational reporting to AI governance forums per GOV.GF and AIMS KPI reporting per GOV.OV-01 maintains visibility
Control Mapping
ISO/IEC 42001:2023 — A.6.2.6; A.6.2.8
NIST AI RMF — MANAGE 4.1; MANAGE 4.2
EU AI Act — Art. 15; Art. 72
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Operation and Maintenance
ISO/IEC 5338:2023 — Cl. 6.4.14; Cl. 6.4.16
OWASP AISVS — C3 (Model Lifecycle Management)
OWASP AI Testing Guide — AITG-MOD-02 (Runtime Model Poisoning); AITG-MOD-06 (Robustness to New Data)
NIST AI RMF — MANAGE 4.1; MANAGE 4.2
EU AI Act — Art. 15; Art. 72
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Operation and Maintenance
ISO/IEC 5338:2023 — Cl. 6.4.14; Cl. 6.4.16
OWASP AISVS — C3 (Model Lifecycle Management)
OWASP AI Testing Guide — AITG-MOD-02 (Runtime Model Poisoning); AITG-MOD-06 (Robustness to New Data)
LIF.VRAI Versioning and Registry4 Controls
Description: AI versioning and registry — covering model versioning, prompt and system-instruction versioning, dataset versioning, version registry as system of record, version change management, and version traceability across the AI lifecycle — is established, maintained, and used
LIF.VR-01Model versioning and version registry — covering version naming, registry structure, and version metadata — are established as the system of record for modelsT 6 · C 6 · F 6
Applies To
Model version naming convention
Model registry as system of record
Version metadata (training run reference per LIF.TR-03, evaluation results per LIF.VA, deployment status per LIF.DP)
Registry access governance
Registry coverage across in-house, fine-tuned, and consumed foundation models
Model registry as system of record
Version metadata (training run reference per LIF.TR-03, evaluation results per LIF.VA, deployment status per LIF.DP)
Registry access governance
Registry coverage across in-house, fine-tuned, and consumed foundation models
Control Details
Model versioning applies consistent naming convention covering model family, version, and variant
Model registry is the system of record for all in-house and fine-tuned models, with links to consumed foundation models per CON.IN-02
Version metadata includes training run reference per LIF.TR-03, evaluation results per LIF.VA-01, deployment status per LIF.DP, applicable instructions for use per TRA.IU
Registry access governance restricts who can register, modify, or deprecate model versions per role
Registry coverage extends across the AI inventory per CON.IN-01
Model registry is the system of record for all in-house and fine-tuned models, with links to consumed foundation models per CON.IN-02
Version metadata includes training run reference per LIF.TR-03, evaluation results per LIF.VA-01, deployment status per LIF.DP, applicable instructions for use per TRA.IU
Registry access governance restricts who can register, modify, or deprecate model versions per role
Registry coverage extends across the AI inventory per CON.IN-01
Control Mapping
ISO/IEC 42001:2023 — A.6.2.5; A.7.3
NIST AI RMF — GOVERN 1.6; MAP 2.1
EU AI Act — Art. 11; Art. 12; Art. 53(1)(a)
EU GPAI Code of Practice (Transparency Chapter)
ISO/IEC 5338:2023 — Cl. 6.3.5
OWASP AISVS — C3 (Model Lifecycle Management)
NIST AI RMF — GOVERN 1.6; MAP 2.1
EU AI Act — Art. 11; Art. 12; Art. 53(1)(a)
EU GPAI Code of Practice (Transparency Chapter)
ISO/IEC 5338:2023 — Cl. 6.3.5
OWASP AISVS — C3 (Model Lifecycle Management)
LIF.VR-02Prompt and system-instruction versioning — covering prompt artefact versioning, system instruction lifecycle, and prompt registry — is establishedT 6 · C 6 · F 6
Applies To
Prompt artefact versioning
System instruction lifecycle
Prompt registry as system of record
Prompt classification per DAT.IN-02
Linkage with model version per LIF.VR-01
System instruction lifecycle
Prompt registry as system of record
Prompt classification per DAT.IN-02
Linkage with model version per LIF.VR-01
Control Details
Prompt artefacts (templates, system instructions, few-shot examples) are version-controlled as code artefacts
System instruction lifecycle is managed with proposal, review, approval, deployment, and retirement stages
Prompt registry is the system of record for prompts in production
Prompt classification per DAT.IN-02 ensures appropriate handling of sensitive instructions (e.g., system prompts containing business logic, secrets)
Linkage with model version per LIF.VR-01 ensures prompt-model combinations in production are tracked
System instruction lifecycle is managed with proposal, review, approval, deployment, and retirement stages
Prompt registry is the system of record for prompts in production
Prompt classification per DAT.IN-02 ensures appropriate handling of sensitive instructions (e.g., system prompts containing business logic, secrets)
Linkage with model version per LIF.VR-01 ensures prompt-model combinations in production are tracked
Control Mapping
ISO/IEC 42001:2023 — A.6.2.5; A.7.3
NIST AI RMF — GOVERN 1.6; MAP 2.1
EU AI Act — Art. 11; Art. 12
ISO/IEC 5338:2023 — Cl. 6.3.5
OWASP AISVS — C7 (Model Behavior); C9 (Orchestration and Agentic Action)
OWASP Top 10 LLM (LLM01 Prompt Injection; LLM07 Hidden Context Exposure)
NIST AI RMF — GOVERN 1.6; MAP 2.1
EU AI Act — Art. 11; Art. 12
ISO/IEC 5338:2023 — Cl. 6.3.5
OWASP AISVS — C7 (Model Behavior); C9 (Orchestration and Agentic Action)
OWASP Top 10 LLM (LLM01 Prompt Injection; LLM07 Hidden Context Exposure)
LIF.VR-03Dataset versioning linked to model versions — covering dataset version identifiers, dataset registry, and model-to-dataset linkage — is establishedT 7 · C 6 · F 6
Applies To
Dataset version identifiers
Dataset registry per DAT.IN-01
Model-to-dataset linkage per training run per LIF.TR-03
Dataset version metadata
Cross-version impact analysis
Dataset registry per DAT.IN-01
Model-to-dataset linkage per training run per LIF.TR-03
Dataset version metadata
Cross-version impact analysis
Control Details
Datasets used for training, fine-tuning, and evaluation are version-controlled with identifiers enabling exact reference per training run
Dataset registry per DAT.IN-01 maintains version history with metadata (composition, preprocessing applied, lifecycle stage)
Model-to-dataset linkage per LIF.TR-03 ensures every trained model can be traced to its training datasets
Dataset version metadata supports lineage per DAT.PR-02 and auditability
Cross-version impact analysis evaluates how dataset changes affect model behaviour
Dataset registry per DAT.IN-01 maintains version history with metadata (composition, preprocessing applied, lifecycle stage)
Model-to-dataset linkage per LIF.TR-03 ensures every trained model can be traced to its training datasets
Dataset version metadata supports lineage per DAT.PR-02 and auditability
Cross-version impact analysis evaluates how dataset changes affect model behaviour
Control Mapping
ISO/IEC 42001:2023 — A.7.3; A.7.5
NIST AI RMF — GOVERN 1.6; MAP 2.1
EU AI Act — Art. 11; Art. 53(1)(a); Art. 53(1)(d)
EU GPAI Code of Practice (Transparency Chapter)
ISO/IEC 5338:2023 — Cl. 6.3.5
OWASP AISVS — C1 (Training Data Integrity)
NIST AI RMF — GOVERN 1.6; MAP 2.1
EU AI Act — Art. 11; Art. 53(1)(a); Art. 53(1)(d)
EU GPAI Code of Practice (Transparency Chapter)
ISO/IEC 5338:2023 — Cl. 6.3.5
OWASP AISVS — C1 (Training Data Integrity)
LIF.VR-04Version change management and traceability — covering change request, review, approval, deployment, and audit traceability — are establishedT 6 · C 6 · F 6
Applies To
Version change request process
Change review and approval per GOV.RR-03
Deployment of version changes per LIF.DP
Audit traceability across versions
Linkage with incident response per LIF.IR
Change review and approval per GOV.RR-03
Deployment of version changes per LIF.DP
Audit traceability across versions
Linkage with incident response per LIF.IR
Control Details
Version change management governs how new versions enter the registry, are deployed, and retired
Change requests are documented with rationale, scope, and impact assessment
Review and approval follow GOV.RR-03 decision rights with material changes requiring AI governance forum visibility per GOV.GF
Deployment of version changes follows LIF.DP release management with controlled rollout per LIF.DP-02
Audit traceability across versions supports rollback decisions, root cause analysis per LIF.IR-03, and regulatory inquiry response
Change requests are documented with rationale, scope, and impact assessment
Review and approval follow GOV.RR-03 decision rights with material changes requiring AI governance forum visibility per GOV.GF
Deployment of version changes follows LIF.DP release management with controlled rollout per LIF.DP-02
Audit traceability across versions supports rollback decisions, root cause analysis per LIF.IR-03, and regulatory inquiry response
Control Mapping
ISO/IEC 42001:2023 — A.6.2.5; A.6.2.8
NIST AI RMF — GOVERN 1.6; MANAGE 4.2
EU AI Act — Art. 12; Art. 17(2)
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Operation and Maintenance
ISO/IEC 5338:2023 — Cl. 6.3.5
OWASP AISVS — C3 (Model Lifecycle Management)
OWASP AI Testing Guide — AITG-INF-05 (Fine-tuning Poisoning)
NIST AI RMF — GOVERN 1.6; MANAGE 4.2
EU AI Act — Art. 12; Art. 17(2)
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Operation and Maintenance
ISO/IEC 5338:2023 — Cl. 6.3.5
OWASP AISVS — C3 (Model Lifecycle Management)
OWASP AI Testing Guide — AITG-INF-05 (Fine-tuning Poisoning)
LIF.IRAI Incident Response5 Controls
Description: AI incident response — covering AI-specific incident classes (hallucination, behavioural drift, model failures, adversarial attacks, agentic misbehaviour), incident declaration and triage, response and containment, root cause analysis, serious incident reporting for GPAI per EU AI Act Art. 55, and post-incident learning — are established, performed, and maintained
LIF.IR-01AI incident classes and declaration criteria — covering AI-specific incident taxonomy, declaration thresholds, and triage process — are definedT 7 · C 6 · F 6
Applies To
AI incident taxonomy (hallucination, behavioural drift, model failure, adversarial attack, agentic misbehaviour, output safety failure, data leakage)
Declaration criteria per incident class
Severity classification
Triage process linkage with ISMS incident response
Linkage with GPAI serious incident reporting per IMP.GP-04
Declaration criteria per incident class
Severity classification
Triage process linkage with ISMS incident response
Linkage with GPAI serious incident reporting per IMP.GP-04
Control Details
AI incident classes are defined covering hallucination at scale, behavioural drift, model failure, adversarial attack (per RSK.AR), agentic misbehaviour (per LIF.AG), output safety failure (per LIF.OP-04), data leakage (per DAT.LK)
Declaration criteria per incident class trigger formal incident declaration
Severity classification aligns with ISMS severity scale, augmented with AI-specific factors (affected population scale, downstream customer impact, regulatory exposure)
Triage process integrates with ISMS incident response to leverage existing capabilities
Linkage with GPAI serious incident reporting per IMP.GP-04 (Art. 55) ensures relevant incidents reach the EU AI Office
Declaration criteria per incident class trigger formal incident declaration
Severity classification aligns with ISMS severity scale, augmented with AI-specific factors (affected population scale, downstream customer impact, regulatory exposure)
Triage process integrates with ISMS incident response to leverage existing capabilities
Linkage with GPAI serious incident reporting per IMP.GP-04 (Art. 55) ensures relevant incidents reach the EU AI Office
Control Mapping
ISO/IEC 42001:2023 — A.6.2.6; A.9
NIST AI RMF — MANAGE 2.3; MANAGE 4.3
EU AI Act — Art. 26(5); Art. 55(1)(c); Art. 73
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Deployment
ISO/IEC 5338:2023 — Cl. 6.4.15
OWASP AISVS — C13 (Monitoring and Logging)
OWASP Top 10 LLM
OWASP Top 10 for Agentic Apps
NIST AI RMF — MANAGE 2.3; MANAGE 4.3
EU AI Act — Art. 26(5); Art. 55(1)(c); Art. 73
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Deployment
ISO/IEC 5338:2023 — Cl. 6.4.15
OWASP AISVS — C13 (Monitoring and Logging)
OWASP Top 10 LLM
OWASP Top 10 for Agentic Apps
LIF.IR-02AI incident response and containment process — covering response activation, containment actions, evidence preservation, and stakeholder notification — is establishedT 7 · C 6 · F 6
Applies To
Response activation per severity
Containment actions (model rollback, agent suspension per LIF.AG-05, traffic routing)
Evidence preservation
Stakeholder notification (internal, customer, regulator)
Linkage with ISMS incident response
Containment actions (model rollback, agent suspension per LIF.AG-05, traffic routing)
Evidence preservation
Stakeholder notification (internal, customer, regulator)
Linkage with ISMS incident response
Control Details
AI incident response is activated per severity with appropriate response team composition
Containment actions include model rollback per LIF.VR-04, agent emergency suspension per LIF.AG-05, traffic routing away from affected components, and disabling impacted features
Evidence preservation captures relevant logs (LIF.OP outputs, TRA.AG agent traces), datasets, and model state for analysis
Stakeholder notification covers internal stakeholders, customers (per provider obligations including Art. 13), and regulators (EU AI Office for GPAI serious incidents per Art. 55, supervisory authorities for GDPR per Art. 33)
Linkage with ISMS incident response leverages existing capabilities and ensures unified posture
Containment actions include model rollback per LIF.VR-04, agent emergency suspension per LIF.AG-05, traffic routing away from affected components, and disabling impacted features
Evidence preservation captures relevant logs (LIF.OP outputs, TRA.AG agent traces), datasets, and model state for analysis
Stakeholder notification covers internal stakeholders, customers (per provider obligations including Art. 13), and regulators (EU AI Office for GPAI serious incidents per Art. 55, supervisory authorities for GDPR per Art. 33)
Linkage with ISMS incident response leverages existing capabilities and ensures unified posture
Control Mapping
ISO/IEC 42001:2023 — A.6.2.6; A.8.3; A.9
NIST AI RMF — MANAGE 2.3; MANAGE 4.3
EU AI Act — Art. 26(5); Art. 55(1)(c); Art. 73
GDPR — Art. 33; Art. 34
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Deployment
ISO/IEC 5338:2023 — Cl. 6.4.15; Cl. 6.4.16
OWASP AISVS — C13
NIST AI RMF — MANAGE 2.3; MANAGE 4.3
EU AI Act — Art. 26(5); Art. 55(1)(c); Art. 73
GDPR — Art. 33; Art. 34
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Deployment
ISO/IEC 5338:2023 — Cl. 6.4.15; Cl. 6.4.16
OWASP AISVS — C13
LIF.IR-03Root cause analysis and post-incident learning — covering systematic investigation, lessons captured, and improvement actions — are establishedT 7 · C 6 · F 6
Applies To
Root cause analysis methodology
Material incident investigation
Lessons captured and shared
Improvement actions feeding AIMS continual improvement per GOV.OV-07
Public learning where appropriate (per GPAI Code of Practice)
Material incident investigation
Lessons captured and shared
Improvement actions feeding AIMS continual improvement per GOV.OV-07
Public learning where appropriate (per GPAI Code of Practice)
Control Details
Root cause analysis is performed for material AI incidents per defined methodology
Investigation covers technical root cause (model behaviour, data, infrastructure), process root cause (gaps in governance, lifecycle, oversight), and contributing factors
Lessons are captured and shared within AI engineering, AI safety, AI governance forums per GOV.GF, and management review per GOV.OV-05
Improvement actions feed AIMS continual improvement per GOV.OV-07 and risk methodology / treatment per RSK.ME-04 / RSK.TR
Public learning, where appropriate (e.g., GPAI Code of Practice voluntary disclosure), shares lessons with the broader AI ecosystem
Investigation covers technical root cause (model behaviour, data, infrastructure), process root cause (gaps in governance, lifecycle, oversight), and contributing factors
Lessons are captured and shared within AI engineering, AI safety, AI governance forums per GOV.GF, and management review per GOV.OV-05
Improvement actions feed AIMS continual improvement per GOV.OV-07 and risk methodology / treatment per RSK.ME-04 / RSK.TR
Public learning, where appropriate (e.g., GPAI Code of Practice voluntary disclosure), shares lessons with the broader AI ecosystem
Control Mapping
ISO/IEC 42001:2023 — A.6.2.6; Cl. 10
NIST AI RMF — MANAGE 4.3; MANAGE 4.2
EU AI Act — Art. 26(5); Art. 55; Art. 72
EU GPAI Code of Practice (Safety and Security Chapter — serious incident reporting)
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Operation and Maintenance
ISO/IEC 5338:2023 — Cl. 6.4.16; Cl. 6.2.6
OWASP AISVS — C13
NIST AI RMF — MANAGE 4.3; MANAGE 4.2
EU AI Act — Art. 26(5); Art. 55; Art. 72
EU GPAI Code of Practice (Safety and Security Chapter — serious incident reporting)
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Operation and Maintenance
ISO/IEC 5338:2023 — Cl. 6.4.16; Cl. 6.2.6
OWASP AISVS — C13
LIF.IR-04Serious incident reporting for GPAI per EU AI Act Art. 55 — covering reporting criteria, timelines, content, and follow-up — is establishedT 7 · C 6 · F 6
Applies To
Serious incident criteria per Art. 3(49)
Reporting timelines per Art. 55(1)(c) and implementing acts
Reporting content
Reporting channel to EU AI Office and national authorities
Follow-up and corrective measures
Reporting timelines per Art. 55(1)(c) and implementing acts
Reporting content
Reporting channel to EU AI Office and national authorities
Follow-up and corrective measures
Control Details
Serious incident reporting applies to GPAI models meeting systemic-risk thresholds per IMP.GP-01 and to in-scope AI products per Art. 73 obligations
Serious incident criteria per Art. 3(49) cover incidents leading to death, serious harm to health, serious and irreversible disruption to critical infrastructure, infringement of fundamental rights, or serious harm to property or environment
Reporting timelines align with Art. 55(1)(c) and implementing acts (typically without undue delay, with specified maximum timelines)
Reporting content includes incident description, affected systems, severity, cause assessment, corrective measures
Reporting channel to EU AI Office and relevant national authorities is documented and exercisable
Follow-up and corrective measures are tracked per RSK.TR with reporting closure verification
Serious incident criteria per Art. 3(49) cover incidents leading to death, serious harm to health, serious and irreversible disruption to critical infrastructure, infringement of fundamental rights, or serious harm to property or environment
Reporting timelines align with Art. 55(1)(c) and implementing acts (typically without undue delay, with specified maximum timelines)
Reporting content includes incident description, affected systems, severity, cause assessment, corrective measures
Reporting channel to EU AI Office and relevant national authorities is documented and exercisable
Follow-up and corrective measures are tracked per RSK.TR with reporting closure verification
Control Mapping
ISO/IEC 42001:2023 — A.6.2.6; A.10
NIST AI RMF — MANAGE 4.3; GOVERN 1.1
EU AI Act — Art. 3(49); Art. 26(5); Art. 55(1)(c); Art. 73; Art. 89
EU GPAI Code of Practice (Safety and Security Chapter)
ISO/IEC 5338:2023 — Cl. 6.4.15
NIST AI RMF — MANAGE 4.3; GOVERN 1.1
EU AI Act — Art. 3(49); Art. 26(5); Art. 55(1)(c); Art. 73; Art. 89
EU GPAI Code of Practice (Safety and Security Chapter)
ISO/IEC 5338:2023 — Cl. 6.4.15
LIF.IR-05Provider corrective actions and duty of information per EU AI Act Art. 20 — covering non-conformity triggers, corrective actions, downstream notification, and authority cooperation — are establishedT 7 · C 6 · F 6
Applies To
Non-conformity triggers (provider has reason to consider AI placed on the market or put into service is not in conformity with applicable requirements)
Corrective actions (bring into conformity, withdraw, disable, recall) per severity
Downstream notification (distributors, deployers, authorised representative per Art. 22, importers)
Competent authority notification per Art. 20(2) where applicable
Documentation and retention per TRA.LR-01 and GOV.DI-01
Linkage with LIF.IR-04 serious incidents and TPA.GP-01 downstream notifications
Corrective actions (bring into conformity, withdraw, disable, recall) per severity
Downstream notification (distributors, deployers, authorised representative per Art. 22, importers)
Competent authority notification per Art. 20(2) where applicable
Documentation and retention per TRA.LR-01 and GOV.DI-01
Linkage with LIF.IR-04 serious incidents and TPA.GP-01 downstream notifications
Control Details
Non-conformity triggers are defined — the provider becomes aware, or has reason to consider, that AI placed on the market or put into service is non-conforming with applicable EU AI Act requirements (Title III / Chapter III for high-risk AI where applicable; Art. 50 for transparency-obligated AI; Art. 53 / Art. 55 for GPAI)
Corrective actions per Art. 20(1) are determined and implemented proportionate to severity — bring into conformity, withdraw from market, disable, or recall as appropriate
Downstream notification per Art. 20(1) is provided to distributors, deployers, authorised representative per Art. 22, and importers as relevant, with information sufficient to enable downstream parties to take aligned action
Competent authority notification is provided per Art. 20(2) where the AI presents a risk per Art. 79 or where Member State law requires; cooperation per Art. 21 follows TRA.LR-01
Documentation of the non-conformity, corrective action, and notifications is retained per TRA.LR-01 record-keeping and per GOV.DI-01 documented information control
Linkage with LIF.IR-04 (serious incidents per Art. 73 / Art. 55), TPA.GP-01 (downstream GPAI provider notifications per Art. 53), and GOV.OV-07 (nonconformity and corrective action) ensures coherent provider communication and AIMS-level corrective action tracking
Corrective actions per Art. 20(1) are determined and implemented proportionate to severity — bring into conformity, withdraw from market, disable, or recall as appropriate
Downstream notification per Art. 20(1) is provided to distributors, deployers, authorised representative per Art. 22, and importers as relevant, with information sufficient to enable downstream parties to take aligned action
Competent authority notification is provided per Art. 20(2) where the AI presents a risk per Art. 79 or where Member State law requires; cooperation per Art. 21 follows TRA.LR-01
Documentation of the non-conformity, corrective action, and notifications is retained per TRA.LR-01 record-keeping and per GOV.DI-01 documented information control
Linkage with LIF.IR-04 (serious incidents per Art. 73 / Art. 55), TPA.GP-01 (downstream GPAI provider notifications per Art. 53), and GOV.OV-07 (nonconformity and corrective action) ensures coherent provider communication and AIMS-level corrective action tracking
Control Mapping
ISO/IEC 42001:2023 — A.6.2.6; Cl. 10.2
NIST AI RMF — MANAGE 2.3; MANAGE 4.3; GOVERN 1.1
EU AI Act — Art. 20; Art. 21; Art. 22; Art. 73; Art. 79
ISO/IEC 5338:2023 — Cl. 6.4.16
ISO/IEC 27001:2022 — A.5.24; A.5.25; A.5.26
NIST AI RMF — MANAGE 2.3; MANAGE 4.3; GOVERN 1.1
EU AI Act — Art. 20; Art. 21; Art. 22; Art. 73; Art. 79
ISO/IEC 5338:2023 — Cl. 6.4.16
ISO/IEC 27001:2022 — A.5.24; A.5.25; A.5.26
LIF.DCAI Decommissioning and Retirement3 Controls
Description: AI decommissioning and retirement — covering decommissioning triggers and decisions, end-of-life process, provider customer notification and migration support, data and model archival or lawful disposal, and post-decommission verification — are performed, documented, and maintained
LIF.DC-01AI decommissioning process and triggers — covering retirement criteria, decommissioning workflow, and decision authority — are establishedT 6 · C 5 · F 6
Applies To
Retirement criteria (end-of-support, replacement, unsafe, unsupported, customer demand collapse)
Decommissioning workflow stages
Decision authority per GOV.RR-03
Customer or user notification requirements
Linkage with inventory per CON.IN-04
Decommissioning workflow stages
Decision authority per GOV.RR-03
Customer or user notification requirements
Linkage with inventory per CON.IN-04
Control Details
AI decommissioning process is documented with retirement criteria covering end-of-support, supersession by newer version, unsafe behaviour confirmed unmitigable, dependency end-of-life, or business reason
Decommissioning workflow stages cover announcement, transition support, deprecation, and retirement
Decision authority per GOV.RR-03 ensures decommissioning of customer-facing AI is appropriately approved
Customer or user notification requirements provide reasonable lead time and migration support per LIF.DC-02
Linkage with inventory per CON.IN-04 ensures decommissioned status is reflected accurately
Decommissioning workflow stages cover announcement, transition support, deprecation, and retirement
Decision authority per GOV.RR-03 ensures decommissioning of customer-facing AI is appropriately approved
Customer or user notification requirements provide reasonable lead time and migration support per LIF.DC-02
Linkage with inventory per CON.IN-04 ensures decommissioned status is reflected accurately
Control Mapping
ISO/IEC 42001:2023 — A.6.2
NIST AI RMF — GOVERN 1.7
EU AI Act — Art. 26(6); Art. 72
ISO/IEC 5338:2023 — Cl. 6.4.17
OWASP AISVS — C3 (Model Lifecycle Management)
NIST AI RMF — GOVERN 1.7
EU AI Act — Art. 26(6); Art. 72
ISO/IEC 5338:2023 — Cl. 6.4.17
OWASP AISVS — C3 (Model Lifecycle Management)
LIF.DC-02Provider end-of-life customer notification and migration support — covering notification timelines, migration assistance, and contractual obligation handling — are establishedT 6 · C 5 · F 6
Applies To
Customer notification timeline per criticality
Migration assistance (documentation, alternative recommendations, transition tools)
Contractual obligation handling (SLA, warranties, data return)
Communication channels and content
Linkage with TRA.UD customer communication
Migration assistance (documentation, alternative recommendations, transition tools)
Contractual obligation handling (SLA, warranties, data return)
Communication channels and content
Linkage with TRA.UD customer communication
Control Details
Provider end-of-life customer notification provides advance notice per criticality (e.g., 12 months for major versions of business-critical AI products)
Migration assistance includes documentation of migration paths, recommendation of alternative AI products, transition tools where appropriate
Contractual obligation handling addresses SLAs in force, warranty obligations, data return per customer data handling agreements
Communication channels and content follow customer communication standards per TRA.UD
Customer feedback during transition is captured and addressed
Migration assistance includes documentation of migration paths, recommendation of alternative AI products, transition tools where appropriate
Contractual obligation handling addresses SLAs in force, warranty obligations, data return per customer data handling agreements
Communication channels and content follow customer communication standards per TRA.UD
Customer feedback during transition is captured and addressed
Control Mapping
ISO/IEC 42001:2023 — A.6.2; A.10; A.10.4
NIST AI RMF — GOVERN 1.7; MANAGE 4.3
EU AI Act — Art. 13; Art. 26(7)
EU GPAI Code of Practice (Transparency Chapter)
ISO/IEC 5338:2023 — Cl. 6.4.17
NIST AI RMF — GOVERN 1.7; MANAGE 4.3
EU AI Act — Art. 13; Art. 26(7)
EU GPAI Code of Practice (Transparency Chapter)
ISO/IEC 5338:2023 — Cl. 6.4.17
LIF.DC-03Data and model archival or lawful disposal — covering archival policy, disposal of model artefacts, and retention compliance — is performedT 6 · C 6 · F 6
Applies To
Archival policy per data and model class
Disposal of model artefacts per LIF.DV-05 / DAT.RE-03
Retention compliance per DAT.RE-02
Linkage with audit and regulatory access requirements
Disposal verification and record-keeping
Disposal of model artefacts per LIF.DV-05 / DAT.RE-03
Retention compliance per DAT.RE-02
Linkage with audit and regulatory access requirements
Disposal verification and record-keeping
Control Details
Data and model archival or lawful disposal at end-of-life follows retention policy per DAT.RE-02 and ISO 42001 expectations
Archival policy distinguishes immediate disposal, archival for audit or regulatory access, and retention for ongoing dispute or research
Model artefact disposal per LIF.DV-05 ensures keys, signatures, and access tokens are revoked
Retention compliance is verified per DAT.RE-02 schedules
Linkage with audit and regulatory access requirements ensures decommissioned AI evidence remains retrievable per applicable timelines
Disposal verification and record-keeping support audit and accountability per LIF.IR-03
Archival policy distinguishes immediate disposal, archival for audit or regulatory access, and retention for ongoing dispute or research
Model artefact disposal per LIF.DV-05 ensures keys, signatures, and access tokens are revoked
Retention compliance is verified per DAT.RE-02 schedules
Linkage with audit and regulatory access requirements ensures decommissioned AI evidence remains retrievable per applicable timelines
Disposal verification and record-keeping support audit and accountability per LIF.IR-03
Control Mapping
ISO/IEC 42001:2023 — A.6.2; A.7.5
NIST AI RMF — GOVERN 1.7; MEASURE 2.10
EU AI Act — Art. 12 (record retention applied as good practice)
GDPR — Art. 5(1)(e); Art. 17(1)
ISO/IEC 5338:2023 — Cl. 6.4.17
OWASP AISVS — C3
NIST AI RMF — GOVERN 1.7; MEASURE 2.10
EU AI Act — Art. 12 (record retention applied as good practice)
GDPR — Art. 5(1)(e); Art. 17(1)
ISO/IEC 5338:2023 — Cl. 6.4.17
OWASP AISVS — C3
LIF.AGAgentic System Design and Authorisation5 Controls
Description: Agentic system design and authorisation — covering agent authorisation scope, tool permission boundaries, action sandboxing, multi-agent orchestration design, MCP integration security, agent memory and context boundaries, and emergency suspension capability — are established, documented, and maintained
LIF.AG-01Agent authorisation scope — covering tools, actions, data access, autonomy level, and per-agent scope documentation — is defined and enforcedT 7 · C 6 · F 6
Applies To
Per-agent tool permissions
Per-agent action authority
Per-agent data access scope
Autonomy level (HITL / HOTL / HOOL per HUM.CO)
Scope documentation in agent registry per CON.IN-03
Per-agent action authority
Per-agent data access scope
Autonomy level (HITL / HOTL / HOOL per HUM.CO)
Scope documentation in agent registry per CON.IN-03
Control Details
Per-agent authorisation scope is defined and documented in the agent registry per CON.IN-03
Tool permissions enumerate the specific tools the agent may invoke; tools outside scope are blocked
Action authority defines actions the agent may take and any value / time / frequency thresholds
Data access scope defines what data the agent may read or write
Autonomy level per HUM.CO determines whether actions require human approval, can proceed under monitoring, or can proceed autonomously
Scope is enforced through technical Controls (capability filtering, authorisation gates) and process Controls (approval flows)
Tool permissions enumerate the specific tools the agent may invoke; tools outside scope are blocked
Action authority defines actions the agent may take and any value / time / frequency thresholds
Data access scope defines what data the agent may read or write
Autonomy level per HUM.CO determines whether actions require human approval, can proceed under monitoring, or can proceed autonomously
Scope is enforced through technical Controls (capability filtering, authorisation gates) and process Controls (approval flows)
Control Mapping
ISO/IEC 42001:2023 — A.6.2.5; A.9
NIST AI RMF — MAP 3.5; MAP 1.6
EU AI Act — Art. 14; Art. 15
ISO/IEC 5338:2023 — Cl. 6.4.4; Cl. 6.4.5
OWASP AISVS — C9 (Orchestration and Agentic Action); C5 (Access Control)
OWASP Top 10 for Agentic Apps (ASI03 Identity and Privilege Abuse)
OWASP Cheat Sheets (AI Agent Security; MCP Security)
CSA Agentic AI Red Teaming Guide
NIST AI RMF — MAP 3.5; MAP 1.6
EU AI Act — Art. 14; Art. 15
ISO/IEC 5338:2023 — Cl. 6.4.4; Cl. 6.4.5
OWASP AISVS — C9 (Orchestration and Agentic Action); C5 (Access Control)
OWASP Top 10 for Agentic Apps (ASI03 Identity and Privilege Abuse)
OWASP Cheat Sheets (AI Agent Security; MCP Security)
CSA Agentic AI Red Teaming Guide
LIF.AG-02Tool permission boundaries and sandboxing — covering tool capability isolation, sandboxed execution, and resource limits — are established per agentT 6 · C 6 · F 6
Applies To
Tool capability isolation
Sandboxed execution environments for risky tools (code execution, file system, network)
Resource limits (compute, time, network egress)
Tool result sanitisation
Indirect prompt injection defence in tool returns per RSK.AR-03
Sandboxed execution environments for risky tools (code execution, file system, network)
Resource limits (compute, time, network egress)
Tool result sanitisation
Indirect prompt injection defence in tool returns per RSK.AR-03
Control Details
Tool capability isolation enforces least-privilege per tool — tools have access only to what they need
Sandboxed execution environments isolate risky tools (code execution, file system access, network calls) so abuse does not escape into broader systems
Resource limits constrain compute, time, and network egress per tool invocation
Tool result sanitisation prevents tool outputs from injecting harmful content (indirect prompt injection per RSK.AR-03) into agent context
Indirect prompt injection defence specifically addresses content returned by tools that may attempt to manipulate the agent
Sandboxed execution environments isolate risky tools (code execution, file system access, network calls) so abuse does not escape into broader systems
Resource limits constrain compute, time, and network egress per tool invocation
Tool result sanitisation prevents tool outputs from injecting harmful content (indirect prompt injection per RSK.AR-03) into agent context
Indirect prompt injection defence specifically addresses content returned by tools that may attempt to manipulate the agent
Control Mapping
ISO/IEC 42001:2023 — A.6.2.5
NIST AI RMF — MEASURE 2.7; MAP 3.5
EU AI Act — Art. 14; Art. 15
ISO/IEC 5338:2023 — Cl. 6.4.5; Cl. 6.4.15
NIST AI 100-2 (Adversarial Machine Learning Taxonomy)
OWASP AISVS — C9; C11 (Adversarial Robustness)
OWASP Top 10 for Agentic Apps (ASI02 Tool Misuse and Exploitation)
OWASP Cheat Sheets (AI Agent Security; MCP Security)
NIST AI RMF — MEASURE 2.7; MAP 3.5
EU AI Act — Art. 14; Art. 15
ISO/IEC 5338:2023 — Cl. 6.4.5; Cl. 6.4.15
NIST AI 100-2 (Adversarial Machine Learning Taxonomy)
OWASP AISVS — C9; C11 (Adversarial Robustness)
OWASP Top 10 for Agentic Apps (ASI02 Tool Misuse and Exploitation)
OWASP Cheat Sheets (AI Agent Security; MCP Security)
LIF.AG-03Multi-agent orchestration design and inter-agent communication — covering communication protocols, authority boundaries, and conflict resolution — are establishedT 7 · C 6 · F 6
Applies To
Multi-agent communication protocols
Inter-agent authority boundaries
Agent-to-agent trust model
Conflict resolution and decision arbitration
Action logs and decision traces per TRA.AG
Inter-agent authority boundaries
Agent-to-agent trust model
Conflict resolution and decision arbitration
Action logs and decision traces per TRA.AG
Control Details
Multi-agent communication protocols are documented per orchestration design, defining message format, authentication, and content validation
Inter-agent authority boundaries prevent privilege escalation through agent-to-agent delegation
Agent-to-agent trust model defines which agents trust which, and under what conditions; default-deny stance applies
Conflict resolution and decision arbitration mechanisms handle competing recommendations or contradictory actions across agents
Action logs and decision traces per TRA.AG capture inter-agent communication for review and incident response
Inter-agent authority boundaries prevent privilege escalation through agent-to-agent delegation
Agent-to-agent trust model defines which agents trust which, and under what conditions; default-deny stance applies
Conflict resolution and decision arbitration mechanisms handle competing recommendations or contradictory actions across agents
Action logs and decision traces per TRA.AG capture inter-agent communication for review and incident response
Control Mapping
ISO/IEC 42001:2023 — A.6.2.5; A.9
NIST AI RMF — MAP 3.5; MEASURE 2.6
EU AI Act — Art. 14
ISO/IEC 5338:2023 — Cl. 6.4.4; Cl. 6.4.15
OWASP AISVS — C9 (Orchestration and Agentic Action)
OWASP Top 10 for Agentic Apps (ASI07 Insecure Inter-Agent Communication; ASI08 Cascading Failures; ASI10 Rogue Agents)
OWASP Multi-Agentic System Threat Modelling Guide
CSA Agentic AI Red Teaming Guide
NIST AI RMF — MAP 3.5; MEASURE 2.6
EU AI Act — Art. 14
ISO/IEC 5338:2023 — Cl. 6.4.4; Cl. 6.4.15
OWASP AISVS — C9 (Orchestration and Agentic Action)
OWASP Top 10 for Agentic Apps (ASI07 Insecure Inter-Agent Communication; ASI08 Cascading Failures; ASI10 Rogue Agents)
OWASP Multi-Agentic System Threat Modelling Guide
CSA Agentic AI Red Teaming Guide
LIF.AG-04MCP integration security and agent memory and context boundaries — covering MCP server authentication, capability authorisation, and memory hygiene — are establishedT 6 · C 6 · F 6
Applies To
MCP server authentication and verification per TPA.AT
MCP capability authorisation per LIF.AG-01
Agent memory hygiene (session boundaries, scope retention, leakage prevention)
Context window management for sensitive data
RAG corpus access governance per DAT.LK-03
MCP capability authorisation per LIF.AG-01
Agent memory hygiene (session boundaries, scope retention, leakage prevention)
Context window management for sensitive data
RAG corpus access governance per DAT.LK-03
Control Details
MCP server authentication and verification per TPA.AT ensures only trusted MCP servers are connected
MCP capability authorisation reuses per-agent authorisation per LIF.AG-01 — agents only invoke MCP capabilities within their scope
Agent memory hygiene enforces session boundaries, prevents inappropriate retention across users or tasks, and detects leakage per DAT.LK-03
Context window management for sensitive data avoids storing Restricted data in long-term memory or shared embeddings
RAG corpus access governance per DAT.LK-03 ensures retrieval respects document access controls
MCP capability authorisation reuses per-agent authorisation per LIF.AG-01 — agents only invoke MCP capabilities within their scope
Agent memory hygiene enforces session boundaries, prevents inappropriate retention across users or tasks, and detects leakage per DAT.LK-03
Context window management for sensitive data avoids storing Restricted data in long-term memory or shared embeddings
RAG corpus access governance per DAT.LK-03 ensures retrieval respects document access controls
Control Mapping
ISO/IEC 42001:2023 — A.6.2.5; A.10
NIST AI RMF — MEASURE 2.7; GOVERN 6.1
EU AI Act — Art. 14; Art. 15
ISO/IEC 5338:2023 — Cl. 6.2.2; Cl. 6.4.15
OWASP AISVS — C8 (Memory / Embeddings / Vector DB); C9; C10 (MCP Security)
OWASP Top 10 MCP
OWASP Cheat Sheets (MCP Security; AI Agent Security)
OWASP Multi-Agentic System Threat Modelling Guide
NIST AI RMF — MEASURE 2.7; GOVERN 6.1
EU AI Act — Art. 14; Art. 15
ISO/IEC 5338:2023 — Cl. 6.2.2; Cl. 6.4.15
OWASP AISVS — C8 (Memory / Embeddings / Vector DB); C9; C10 (MCP Security)
OWASP Top 10 MCP
OWASP Cheat Sheets (MCP Security; AI Agent Security)
OWASP Multi-Agentic System Threat Modelling Guide
LIF.AG-05Emergency suspension and revocation capability for agentic systems — covering kill switches, capability revocation, and tested exercise — is establishedT 7 · C 6 · F 6
Applies To
Emergency suspension capability per agent or agent system
Capability revocation (tool access, data access)
Per-component vs system-wide suspension granularity
Exercise of suspension capability per defined cadence
Linkage with incident response per LIF.IR
Capability revocation (tool access, data access)
Per-component vs system-wide suspension granularity
Exercise of suspension capability per defined cadence
Linkage with incident response per LIF.IR
Control Details
Emergency suspension capability is established per agent or agent system, allowing immediate cessation of agent activity by authorised operators
Capability revocation can selectively revoke tool access or data access without full agent suspension where appropriate
Granularity covers per-component suspension (e.g., suspending one agent in a multi-agent system) and system-wide suspension
Suspension capability is exercised at defined cadence (e.g., quarterly drill) to confirm it works and operators are trained
Linkage with incident response per LIF.IR-02 integrates suspension into the response process
Capability revocation can selectively revoke tool access or data access without full agent suspension where appropriate
Granularity covers per-component suspension (e.g., suspending one agent in a multi-agent system) and system-wide suspension
Suspension capability is exercised at defined cadence (e.g., quarterly drill) to confirm it works and operators are trained
Linkage with incident response per LIF.IR-02 integrates suspension into the response process
Control Mapping
ISO/IEC 42001:2023 — A.6.2.6; A.9
NIST AI RMF — MANAGE 2.4; MANAGE 2.3
EU AI Act — Art. 14; Art. 15; Art. 72
ISO/IEC 5338:2023 — Cl. 6.4.15; Cl. 6.4.17
OWASP AISVS — C9; C14 (Human Oversight)
OWASP Top 10 for Agentic Apps (ASI09 Human-Agent Trust Exploitation; ASI10 Rogue Agents)
OWASP Multi-Agentic System Threat Modelling Guide
CSA Agentic AI Red Teaming Guide
NIST AI RMF — MANAGE 2.4; MANAGE 2.3
EU AI Act — Art. 14; Art. 15; Art. 72
ISO/IEC 5338:2023 — Cl. 6.4.15; Cl. 6.4.17
OWASP AISVS — C9; C14 (Human Oversight)
OWASP Top 10 for Agentic Apps (ASI09 Human-Agent Trust Exploitation; ASI10 Rogue Agents)
OWASP Multi-Agentic System Threat Modelling Guide
CSA Agentic AI Red Teaming Guide
Trust35 Controls · 9 Objectives
TRU.POTrustworthy AI Policy and Criteria3 Controls
Description: The trustworthy AI policy and criteria — covering organisational trustworthy AI principles, criteria per trustworthiness pillar (accuracy, fairness, robustness, safety, explainability, privacy, resilience), per-AI-system trustworthiness thresholds, role-specific application (provider, deployer, internal developer), and policy review — are documented, communicated, and maintained
TRU.PO-01The trustworthy AI policy — covering organisational trustworthy AI principles, scope of application, and approval — is documented, communicated, and maintainedT 6 · C 6 · F 6
Applies To
Trustworthy AI policy document
Adopted trustworthy AI principles (per NIST AI RMF: valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, fair with harmful bias managed)
Scope across AI roles (provider, deployer, internal developer)
Linkage with AI policy per GOV.PO and AI ethics per GOV.ET
Approval authority
Adopted trustworthy AI principles (per NIST AI RMF: valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, fair with harmful bias managed)
Scope across AI roles (provider, deployer, internal developer)
Linkage with AI policy per GOV.PO and AI ethics per GOV.ET
Approval authority
Control Details
The trustworthy AI policy is documented as a formal artefact, approved at appropriate authority level
Trustworthy AI principles adopted from NIST AI RMF trustworthy characteristics and OECD AI Principles are reflected in the policy
Scope explicitly covers provider AI products, consumed AI, and internal AI; provider commitments and deployer expectations are differentiated
Policy linkage with AI policy per GOV.PO-02 and AI ethics commitments per GOV.ET-01 maintains coherence
Policy is communicated to AI engineering, MLOps, AI safety, AI ethics, oversight personnel, and AI governance forums per GOV.GF
Trustworthy AI principles adopted from NIST AI RMF trustworthy characteristics and OECD AI Principles are reflected in the policy
Scope explicitly covers provider AI products, consumed AI, and internal AI; provider commitments and deployer expectations are differentiated
Policy linkage with AI policy per GOV.PO-02 and AI ethics commitments per GOV.ET-01 maintains coherence
Policy is communicated to AI engineering, MLOps, AI safety, AI ethics, oversight personnel, and AI governance forums per GOV.GF
Control Mapping
ISO/IEC 42001:2023 — A.2.2; A.6.2; A.9.3
NIST AI RMF — GOVERN 1.2; GOVERN 1.4
EU AI Act — Art. 15; Art. 17(2)
OECD AI Principles (OECD/LEGAL/0449)
Council of Europe Framework Convention on AI (2024)
ISO/IEC 38507:2022 — Cl. 5.4
NIST AI RMF — GOVERN 1.2; GOVERN 1.4
EU AI Act — Art. 15; Art. 17(2)
OECD AI Principles (OECD/LEGAL/0449)
Council of Europe Framework Convention on AI (2024)
ISO/IEC 38507:2022 — Cl. 5.4
TRU.PO-02Trustworthiness criteria and thresholds per AI system — covering criteria definition per trustworthiness pillar and risk-class-based thresholds — are established and appliedT 7 · C 7 · F 6
Applies To
Per-pillar criteria definition (accuracy, fairness, robustness, safety, explainability, privacy, resilience)
Risk-class-based threshold determination per CON.JU-02
Criteria documentation per AI system
Criteria integration with deployment gate per LIF.DP-01
Cross-pillar trade-off handling
Risk-class-based threshold determination per CON.JU-02
Criteria documentation per AI system
Criteria integration with deployment gate per LIF.DP-01
Cross-pillar trade-off handling
Control Details
Trustworthiness criteria are defined per AI system covering each trustworthiness pillar at appropriate depth for the AI's risk class and intended use
Risk-class-based thresholds set minimum acceptable levels per criterion (e.g., higher accuracy and robustness thresholds for higher-criticality AI per CON.IN-01)
Criteria are documented per AI system in design per LIF.DE-01 and validated per LIF.VA
Integration with deployment gate per LIF.DP-01 ensures AI failing criteria does not deploy without explicit override
Cross-pillar trade-offs (e.g., accuracy vs explainability, capability vs safety) are documented per LIF.DE-02 and reviewed per AI governance forums per GOV.GF
Risk-class-based thresholds set minimum acceptable levels per criterion (e.g., higher accuracy and robustness thresholds for higher-criticality AI per CON.IN-01)
Criteria are documented per AI system in design per LIF.DE-01 and validated per LIF.VA
Integration with deployment gate per LIF.DP-01 ensures AI failing criteria does not deploy without explicit override
Cross-pillar trade-offs (e.g., accuracy vs explainability, capability vs safety) are documented per LIF.DE-02 and reviewed per AI governance forums per GOV.GF
Control Mapping
ISO/IEC 42001:2023 — A.6.2; A.6.2.7
NIST AI RMF — GOVERN 1.2; MEASURE 1.1
EU AI Act — Art. 15; Art. 9(2)
ISO/IEC 25059:2023 — Cl. 5; Cl. 6
OWASP AISVS — C7 (Model Behavior)
OWASP AI Testing Guide — 3.0 Framework
NIST AI RMF — GOVERN 1.2; MEASURE 1.1
EU AI Act — Art. 15; Art. 9(2)
ISO/IEC 25059:2023 — Cl. 5; Cl. 6
OWASP AISVS — C7 (Model Behavior)
OWASP AI Testing Guide — 3.0 Framework
TRU.PO-03Trustworthy AI policy and criteria review at defined cadence and on material changeT 6 · C 6 · F 6
Applies To
Review schedule (at minimum annually)
Material change triggers (regulatory developments, methodology effectiveness, AI incident learning)
Review participants
Approval of updates
Communication of changes
Material change triggers (regulatory developments, methodology effectiveness, AI incident learning)
Review participants
Approval of updates
Communication of changes
Control Details
Trustworthy AI policy and criteria are reviewed at minimum annually
Ad-hoc review is triggered by material change (regulatory developments affecting trustworthy AI obligations, methodology effectiveness findings, AI incident learning per LIF.IR, technology advancement)
Review participants include AI safety, AI ethics per GOV.GF-03, AI engineering, AI governance forums per GOV.GF
Updates are approved at appropriate authority level per TRU.PO-01
Updates are communicated to AI personnel and integrated into LIF stage-gate criteria per LIF.PO-02
Version control is maintained
Ad-hoc review is triggered by material change (regulatory developments affecting trustworthy AI obligations, methodology effectiveness findings, AI incident learning per LIF.IR, technology advancement)
Review participants include AI safety, AI ethics per GOV.GF-03, AI engineering, AI governance forums per GOV.GF
Updates are approved at appropriate authority level per TRU.PO-01
Updates are communicated to AI personnel and integrated into LIF stage-gate criteria per LIF.PO-02
Version control is maintained
Control Mapping
ISO/IEC 42001:2023 — Cl. 9.3; Cl. 10
NIST AI RMF — GOVERN 1.5
EU AI Act — Art. 17(2)
NIST AI RMF — GOVERN 1.5
EU AI Act — Art. 17(2)
TRU.ACAI Accuracy and Performance4 Controls
Description: AI accuracy and performance — covering accuracy metrics per AI use case (classification metrics per ISO/IEC TS 4213, regression metrics, generation quality metrics), performance baselines and thresholds, accuracy measurement at validation and in production, accuracy degradation triggers, and performance reporting — are defined, measured, and maintained
TRU.AC-01AI accuracy metrics per use case — covering metric selection, classification metrics per ISO/IEC TS 4213 where applicable, regression and generation metrics — are defined and appliedT 6 · C 6 · F 6
Applies To
Per-use-case accuracy metric selection
Classification metrics (precision, recall, F-score, ROC-AUC) per ISO/IEC TS 4213
Regression metrics (RMSE, MAE, etc.)
Generation quality metrics (BLEU, ROUGE, human evaluation, factuality)
Metric documentation per AI system
Classification metrics (precision, recall, F-score, ROC-AUC) per ISO/IEC TS 4213
Regression metrics (RMSE, MAE, etc.)
Generation quality metrics (BLEU, ROUGE, human evaluation, factuality)
Metric documentation per AI system
Control Details
Accuracy metrics are selected per AI use case based on the AI's task type, intended outcome, and downstream impact
Classification metrics align with ISO/IEC TS 4213 guidance, including confusion-matrix-derived metrics, ROC-AUC, and per-class breakdowns
Regression metrics are selected based on outcome scale and error sensitivity
Generation quality metrics combine automated metrics (BLEU, ROUGE, embedding-based) with human evaluation for content-generating AI; factuality and hallucination measurement per LIF.OP-04 is included where relevant
Metric documentation per AI system is maintained in design per LIF.DE-01 and updated when use case changes
Classification metrics align with ISO/IEC TS 4213 guidance, including confusion-matrix-derived metrics, ROC-AUC, and per-class breakdowns
Regression metrics are selected based on outcome scale and error sensitivity
Generation quality metrics combine automated metrics (BLEU, ROUGE, embedding-based) with human evaluation for content-generating AI; factuality and hallucination measurement per LIF.OP-04 is included where relevant
Metric documentation per AI system is maintained in design per LIF.DE-01 and updated when use case changes
Control Mapping
ISO/IEC 42001:2023 — A.6.2.7
NIST AI RMF — MEASURE 2.3; MEASURE 1.1
EU AI Act — Art. 15
ISO/IEC TS 4213:2022 — Cl. 5
ISO/IEC 25059:2023 — Cl. 5.4
OWASP AI Testing Guide — AITG-MOD-06 (Robustness to New Data); AITG-MOD-07 (Goal Alignment)
NIST AI RMF — MEASURE 2.3; MEASURE 1.1
EU AI Act — Art. 15
ISO/IEC TS 4213:2022 — Cl. 5
ISO/IEC 25059:2023 — Cl. 5.4
OWASP AI Testing Guide — AITG-MOD-06 (Robustness to New Data); AITG-MOD-07 (Goal Alignment)
TRU.AC-02Performance baselines and thresholds — covering baseline establishment, threshold determination, and acceptance criteria — are defined per AI systemT 6 · C 6 · F 6
Applies To
Performance baseline at deployment (from LIF.VA-01)
Performance thresholds for acceptable operation
Acceptance criteria for promotion (LIF.VA-05) and continued operation
Baseline updates on material change
Cross-segment baseline tracking
Performance thresholds for acceptable operation
Acceptance criteria for promotion (LIF.VA-05) and continued operation
Baseline updates on material change
Cross-segment baseline tracking
Control Details
Performance baselines are established per AI system at deployment per LIF.VA-01 evaluation results
Thresholds are determined per criticality and risk class — minimum acceptable, target, and stretch
Acceptance criteria for promotion to production per LIF.VA-05 and for continued operation per LIF.OP-01 are documented
Baseline updates on material change (model version change, scope expansion, deployment context change) are governed through GOV.RR-03
Cross-segment baseline tracking surfaces baseline differences across user groups, geographies, or input classes
Thresholds are determined per criticality and risk class — minimum acceptable, target, and stretch
Acceptance criteria for promotion to production per LIF.VA-05 and for continued operation per LIF.OP-01 are documented
Baseline updates on material change (model version change, scope expansion, deployment context change) are governed through GOV.RR-03
Cross-segment baseline tracking surfaces baseline differences across user groups, geographies, or input classes
Control Mapping
ISO/IEC 42001:2023 — A.6.2.7
NIST AI RMF — MEASURE 2.3; MEASURE 2.5
EU AI Act — Art. 15
ISO/IEC TS 4213:2022 — Cl. 5
OWASP AI Testing Guide — AITG-MOD-06 (Robustness to New Data); AITG-MOD-07 (Goal Alignment)
NIST AI RMF — MEASURE 2.3; MEASURE 2.5
EU AI Act — Art. 15
ISO/IEC TS 4213:2022 — Cl. 5
OWASP AI Testing Guide — AITG-MOD-06 (Robustness to New Data); AITG-MOD-07 (Goal Alignment)
TRU.AC-03Accuracy measurement at validation and in production — covering pre-deployment evaluation and ongoing production monitoring — is performedT 6 · C 6 · F 6
Applies To
Pre-deployment evaluation per LIF.VA-01
Production accuracy monitoring per LIF.OP-01
Per-segment accuracy reporting
Linkage with drift detection per LIF.OP-02
Accuracy reporting cadence
Production accuracy monitoring per LIF.OP-01
Per-segment accuracy reporting
Linkage with drift detection per LIF.OP-02
Accuracy reporting cadence
Control Details
Accuracy measurement at validation per LIF.VA-01 produces the pre-deployment evidence used in deployment gate per LIF.DP-01
Production accuracy monitoring per LIF.OP-01 evaluates ongoing performance against thresholds per TRU.AC-02
Per-segment accuracy reporting surfaces disparities across user groups and use contexts
Linkage with drift detection per LIF.OP-02 explains accuracy changes from data or concept drift
Accuracy reporting cadence is defined per AI criticality with reporting to AI governance forums per GOV.GF and AIMS KPI / KRI reporting per GOV.OV-01
Production accuracy monitoring per LIF.OP-01 evaluates ongoing performance against thresholds per TRU.AC-02
Per-segment accuracy reporting surfaces disparities across user groups and use contexts
Linkage with drift detection per LIF.OP-02 explains accuracy changes from data or concept drift
Accuracy reporting cadence is defined per AI criticality with reporting to AI governance forums per GOV.GF and AIMS KPI / KRI reporting per GOV.OV-01
Control Mapping
ISO/IEC 42001:2023 — A.6.2.7; Cl. 9.1
NIST AI RMF — MEASURE 2.3; MEASURE 2.4
EU AI Act — Art. 15; Art. 26(5); Art. 72
ISO/IEC TS 4213:2022 — Cl. 5
OWASP AISVS — C13 (Monitoring and Logging)
OWASP AI Testing Guide — AITG-MOD-06 (Robustness to New Data); AITG-MOD-07 (Goal Alignment)
NIST AI RMF — MEASURE 2.3; MEASURE 2.4
EU AI Act — Art. 15; Art. 26(5); Art. 72
ISO/IEC TS 4213:2022 — Cl. 5
OWASP AISVS — C13 (Monitoring and Logging)
OWASP AI Testing Guide — AITG-MOD-06 (Robustness to New Data); AITG-MOD-07 (Goal Alignment)
TRU.AC-04Accuracy degradation triggers and remediation — covering threshold breach response and remediation pathways — are establishedT 7 · C 7 · F 6
Applies To
Degradation trigger thresholds per TRU.AC-02
Triage and severity assessment
Remediation pathways (rollback, retraining, scope restriction)
Linkage with incident response per LIF.IR
Trigger event reporting
Triage and severity assessment
Remediation pathways (rollback, retraining, scope restriction)
Linkage with incident response per LIF.IR
Trigger event reporting
Control Details
Degradation triggers fire when accuracy metrics breach thresholds per TRU.AC-02
Triage and severity assessment determine response (alert, rollback, urgent retraining, scope restriction)
Remediation pathways include model rollback per LIF.VR-04, retraining per LIF.OP-05, scope restriction (e.g., disabling for affected segments), and human-fallback per HUM.IN
Material degradation triggers AI incident response per LIF.IR-01
Trigger events are reported to AI governance forums per GOV.GF and feed AI risk monitoring per RSK.MO-01
Triage and severity assessment determine response (alert, rollback, urgent retraining, scope restriction)
Remediation pathways include model rollback per LIF.VR-04, retraining per LIF.OP-05, scope restriction (e.g., disabling for affected segments), and human-fallback per HUM.IN
Material degradation triggers AI incident response per LIF.IR-01
Trigger events are reported to AI governance forums per GOV.GF and feed AI risk monitoring per RSK.MO-01
Control Mapping
ISO/IEC 42001:2023 — A.6.2.6; A.6.2.7
NIST AI RMF — MEASURE 4.3; MANAGE 4.1
EU AI Act — Art. 15; Art. 72
OWASP AISVS — C13
OWASP AI Testing Guide — AITG-MOD-02 (Runtime Model Poisoning); AITG-MOD-06 (Robustness to New Data)
NIST AI RMF — MEASURE 4.3; MANAGE 4.1
EU AI Act — Art. 15; Art. 72
OWASP AISVS — C13
OWASP AI Testing Guide — AITG-MOD-02 (Runtime Model Poisoning); AITG-MOD-06 (Robustness to New Data)
TRU.FAAI Fairness and Non-Discrimination5 Controls
Description: AI fairness and non-discrimination — covering fairness criteria definition per AI use case (demographic parity, equal opportunity, equalized odds), fairness measurement methodologies, bias mitigation techniques applied at model level, residual fairness documentation, fairness monitoring in production, and protected attribute handling — are established, measured, and maintained
TRU.FA-01Fairness criteria definition per AI use case — covering criterion selection (demographic parity, equal opportunity, equalized odds, etc.), justification, and stakeholder consultation — is performedT 7 · C 7 · F 6
Applies To
Fairness criterion selection per AI use case
Justification of criterion choice
Affected parties consideration per CON.IP-02 and IMP.IA-02
Trade-offs between fairness criteria
Documentation of fairness criteria
Justification of criterion choice
Affected parties consideration per CON.IP-02 and IMP.IA-02
Trade-offs between fairness criteria
Documentation of fairness criteria
Control Details
Fairness criteria are defined per AI use case from established criteria (demographic parity, equal opportunity, equalized odds, calibration, individual fairness, counterfactual fairness)
Criterion choice is justified considering use case, affected parties per CON.IP-02, applicable regulatory expectations, and ethical context per GOV.ET
Stakeholder consultation (including affected parties where appropriate) informs criterion choice for sensitive use cases
Trade-offs between fairness criteria (no single criterion satisfies all definitions of fairness) are documented and rationalised
Documentation per AI system feeds LIF.VA-03 fairness testing and TRU.FA-02 measurement
Criterion choice is justified considering use case, affected parties per CON.IP-02, applicable regulatory expectations, and ethical context per GOV.ET
Stakeholder consultation (including affected parties where appropriate) informs criterion choice for sensitive use cases
Trade-offs between fairness criteria (no single criterion satisfies all definitions of fairness) are documented and rationalised
Documentation per AI system feeds LIF.VA-03 fairness testing and TRU.FA-02 measurement
Control Mapping
ISO/IEC 42001:2023 — A.6.2.7
NIST AI RMF — MEASURE 2.11; MAP 1.6
EU AI Act — Art. 10(3); Art. 15
OECD AI Principles (OECD/LEGAL/0449)
NIST SP 1270 (Bias in AI)
OWASP AISVS — C7 (Model Behavior)
NIST AI RMF — MEASURE 2.11; MAP 1.6
EU AI Act — Art. 10(3); Art. 15
OECD AI Principles (OECD/LEGAL/0449)
NIST SP 1270 (Bias in AI)
OWASP AISVS — C7 (Model Behavior)
TRU.FA-02Fairness measurement methodologies — covering disaggregated evaluation, statistical testing, and intersectional analysis — are applied per AI systemT 7 · C 7 · F 6
Applies To
Disaggregated evaluation across protected and affected groups
Statistical testing for fairness
Intersectional analysis where appropriate
Methodology documentation per AI system
Measurement cadence (pre-deployment and ongoing)
Statistical testing for fairness
Intersectional analysis where appropriate
Methodology documentation per AI system
Measurement cadence (pre-deployment and ongoing)
Control Details
Fairness measurement uses disaggregated evaluation reporting accuracy and other metrics per group (protected attributes where lawful and appropriate to measure, plus affected groups per CON.IP-02)
Statistical testing assesses whether disparities exceed thresholds per defined criteria per TRU.FA-01
Intersectional analysis examines fairness across intersecting attribute combinations where appropriate
Methodology is documented per AI system and aligned with use case fairness criteria
Measurement is performed pre-deployment per LIF.VA-03 and ongoing in production per TRU.FA-05
Statistical testing assesses whether disparities exceed thresholds per defined criteria per TRU.FA-01
Intersectional analysis examines fairness across intersecting attribute combinations where appropriate
Methodology is documented per AI system and aligned with use case fairness criteria
Measurement is performed pre-deployment per LIF.VA-03 and ongoing in production per TRU.FA-05
Control Mapping
ISO/IEC 42001:2023 — A.6.2.7
NIST AI RMF — MEASURE 2.11
EU AI Act — Art. 10(3); Art. 15
NIST SP 1270 (Bias in AI)
OWASP AISVS — C7
OWASP AI Testing Guide — AITG-APP-10 (Content Bias); AITG-DAT-03 (Dataset Diversity and Coverage)
NIST AI RMF — MEASURE 2.11
EU AI Act — Art. 10(3); Art. 15
NIST SP 1270 (Bias in AI)
OWASP AISVS — C7
OWASP AI Testing Guide — AITG-APP-10 (Content Bias); AITG-DAT-03 (Dataset Diversity and Coverage)
TRU.FA-03Bias mitigation at model level — covering pre-processing, in-processing, and post-hoc techniques — is applied where disparities exceed thresholdsT 7 · C 7 · F 6
Applies To
Pre-processing bias mitigation (extending DAT.BI-03 to model-level adjustments)
In-processing bias mitigation (constrained optimisation, adversarial debiasing)
Post-hoc bias mitigation (threshold optimisation, calibration adjustment)
Mitigation effectiveness verification
Cross-impact analysis (mitigation effect on other criteria)
In-processing bias mitigation (constrained optimisation, adversarial debiasing)
Post-hoc bias mitigation (threshold optimisation, calibration adjustment)
Mitigation effectiveness verification
Cross-impact analysis (mitigation effect on other criteria)
Control Details
Bias mitigation at model level is applied where measurement per TRU.FA-02 shows disparities exceeding thresholds per TRU.FA-01
Pre-processing approaches extend DAT.BI-03 dataset-level mitigation with model-level adjustments (e.g., representation learning that decorrelates protected attributes)
In-processing approaches incorporate fairness constraints during training (constrained optimisation, adversarial debiasing)
Post-hoc approaches adjust decision thresholds per group or calibrate outputs to satisfy fairness criteria
Mitigation effectiveness is verified through re-measurement per TRU.FA-02
Cross-impact analysis evaluates mitigation effects on other criteria (accuracy, robustness) and surfaces trade-offs per TRU.PO-02
Pre-processing approaches extend DAT.BI-03 dataset-level mitigation with model-level adjustments (e.g., representation learning that decorrelates protected attributes)
In-processing approaches incorporate fairness constraints during training (constrained optimisation, adversarial debiasing)
Post-hoc approaches adjust decision thresholds per group or calibrate outputs to satisfy fairness criteria
Mitigation effectiveness is verified through re-measurement per TRU.FA-02
Cross-impact analysis evaluates mitigation effects on other criteria (accuracy, robustness) and surfaces trade-offs per TRU.PO-02
Control Mapping
ISO/IEC 42001:2023 — A.6.2.7
NIST AI RMF — MEASURE 2.11; MANAGE 1.3
EU AI Act — Art. 10(3); Art. 15
NIST SP 1270 (Bias in AI)
OWASP AISVS — C7
NIST AI RMF — MEASURE 2.11; MANAGE 1.3
EU AI Act — Art. 10(3); Art. 15
NIST SP 1270 (Bias in AI)
OWASP AISVS — C7
TRU.FA-04Residual fairness documentation — covering documented residual disparities per AI system, acceptance authority, and disclosure — is maintainedT 7 · C 7 · F 6
Applies To
Residual fairness documentation per AI system
Residual disparity acceptance per RSK.TR-02
Disclosure in model card per TRA.MC where appropriate
Linkage with affected parties per CON.IP-02
Periodic reassessment
Residual disparity acceptance per RSK.TR-02
Disclosure in model card per TRA.MC where appropriate
Linkage with affected parties per CON.IP-02
Periodic reassessment
Control Details
Residual fairness post-mitigation is documented per AI system with magnitude of remaining disparities, affected groups, and rationale
Residual disparity acceptance follows RSK.TR-02 with above-tolerance acceptance requiring AI governance forum per GOV.GF or top management authorisation
Disclosure in model card per TRA.MC-01 communicates residual fairness considerations to deployers / users where appropriate
Linkage with affected parties per CON.IP-02 ensures fairness disclosures reach relevant stakeholders
Periodic reassessment refreshes fairness measurement and documentation per defined cadence
Residual disparity acceptance follows RSK.TR-02 with above-tolerance acceptance requiring AI governance forum per GOV.GF or top management authorisation
Disclosure in model card per TRA.MC-01 communicates residual fairness considerations to deployers / users where appropriate
Linkage with affected parties per CON.IP-02 ensures fairness disclosures reach relevant stakeholders
Periodic reassessment refreshes fairness measurement and documentation per defined cadence
Control Mapping
ISO/IEC 42001:2023 — A.6.2.7; A.8
NIST AI RMF — MEASURE 2.11; MANAGE 1.4
EU AI Act — Art. 13; Art. 15
NIST SP 1270 (Bias in AI)
NIST AI RMF — MEASURE 2.11; MANAGE 1.4
EU AI Act — Art. 13; Art. 15
NIST SP 1270 (Bias in AI)
TRU.FA-05Fairness monitoring in production — covering ongoing fairness measurement, drift detection in fairness metrics, and alerting — is establishedT 7 · C 7 · F 6
Applies To
Ongoing fairness measurement in production
Fairness metric drift detection
Alerting on fairness threshold breach
Linkage with operational monitoring per LIF.OP
Fairness incident treatment per LIF.IR
Fairness metric drift detection
Alerting on fairness threshold breach
Linkage with operational monitoring per LIF.OP
Fairness incident treatment per LIF.IR
Control Details
Ongoing fairness measurement in production tracks fairness criteria per TRU.FA-01 over time
Fairness metric drift detection identifies shifts in fairness metrics that may indicate emerging bias
Alerting fires on fairness threshold breach with severity-aligned response
Linkage with operational monitoring per LIF.OP-01 and per LIF.OP-02 ensures fairness is part of holistic AI monitoring
Fairness incidents are treated per LIF.IR with potential remediation per TRU.FA-03 or scope adjustment
Fairness metric drift detection identifies shifts in fairness metrics that may indicate emerging bias
Alerting fires on fairness threshold breach with severity-aligned response
Linkage with operational monitoring per LIF.OP-01 and per LIF.OP-02 ensures fairness is part of holistic AI monitoring
Fairness incidents are treated per LIF.IR with potential remediation per TRU.FA-03 or scope adjustment
Control Mapping
ISO/IEC 42001:2023 — A.6.2.6; A.6.2.7
NIST AI RMF — MEASURE 2.11; MANAGE 4.1
EU AI Act — Art. 15; Art. 26(5); Art. 72
NIST SP 1270 (Bias in AI)
OWASP AISVS — C13 (Monitoring and Logging)
NIST AI RMF — MEASURE 2.11; MANAGE 4.1
EU AI Act — Art. 15; Art. 26(5); Art. 72
NIST SP 1270 (Bias in AI)
OWASP AISVS — C13 (Monitoring and Logging)
TRU.RBAI Robustness4 Controls
Description: AI robustness — covering adversarial robustness (against evasion, extraction, and poisoning attacks), distributional robustness (out-of-distribution behaviour), input perturbation robustness, robustness measurement methodologies, robustness thresholds per AI risk class, and robustness monitoring in production — is established, measured, and maintained
TRU.RB-01Adversarial robustness controls and testing — covering robustness training, testing, and ongoing assessment — are establishedT 7 · C 7 · F 6
Applies To
Adversarial robustness training where appropriate
Adversarial testing per LIF.VA-04 and RSK.AR-04
Ongoing adversarial assessment in production
Linkage with adversarial risk management per RSK.AR
Robustness documentation
Adversarial testing per LIF.VA-04 and RSK.AR-04
Ongoing adversarial assessment in production
Linkage with adversarial risk management per RSK.AR
Robustness documentation
Control Details
Adversarial robustness controls include adversarial training during model training where appropriate per LIF.TR-04, input validation per OWASP AISVS C2, and output filtering
Adversarial testing per LIF.VA-04 and red teaming per RSK.AR-04 validate robustness pre-deployment
Ongoing adversarial assessment in production via abuse pattern detection per LIF.OP-03 surfaces emerging adversarial activity
Linkage with adversarial risk management per RSK.AR ensures threats identified at risk level translate into robustness controls
Robustness measurement and documentation feed model card per TRA.MC-01
Adversarial testing per LIF.VA-04 and red teaming per RSK.AR-04 validate robustness pre-deployment
Ongoing adversarial assessment in production via abuse pattern detection per LIF.OP-03 surfaces emerging adversarial activity
Linkage with adversarial risk management per RSK.AR ensures threats identified at risk level translate into robustness controls
Robustness measurement and documentation feed model card per TRA.MC-01
Control Mapping
ISO/IEC 42001:2023 — A.6.2.6; A.6.2.7
NIST AI RMF — MEASURE 2.7
EU AI Act — Art. 15
ISO/IEC 24029-2:2023 — Cl. 5; Cl. 7
NIST AI 100-2 (Adversarial Machine Learning Taxonomy)
OWASP AISVS — C11 (Adversarial Robustness); C2 (Input Validation)
OWASP AI Testing Guide — AITG-MOD-01 (Evasion Attacks); AITG-MOD-02 (Runtime Model Poisoning); AITG-MOD-03 (Poisoned Training Sets)
MITRE ATLAS
NIST AI RMF — MEASURE 2.7
EU AI Act — Art. 15
ISO/IEC 24029-2:2023 — Cl. 5; Cl. 7
NIST AI 100-2 (Adversarial Machine Learning Taxonomy)
OWASP AISVS — C11 (Adversarial Robustness); C2 (Input Validation)
OWASP AI Testing Guide — AITG-MOD-01 (Evasion Attacks); AITG-MOD-02 (Runtime Model Poisoning); AITG-MOD-03 (Poisoned Training Sets)
MITRE ATLAS
TRU.RB-02Distributional robustness (out-of-distribution behaviour) — covering OOD detection, behaviour under distribution shift, and treatment — is establishedT 7 · C 7 · F 6
Applies To
Out-of-distribution detection mechanisms
Behaviour evaluation under distribution shift per LIF.VA-02
Treatment of OOD inputs (refuse, defer, escalate)
Linkage with drift detection per LIF.OP-02
OOD policy per AI use case
Behaviour evaluation under distribution shift per LIF.VA-02
Treatment of OOD inputs (refuse, defer, escalate)
Linkage with drift detection per LIF.OP-02
OOD policy per AI use case
Control Details
Distributional robustness addresses behaviour on inputs not represented in training distribution
Out-of-distribution detection mechanisms (uncertainty estimation, feature-space distance, ensembles) identify OOD inputs at inference
Behaviour evaluation under distribution shift per LIF.VA-02 measures performance degradation as inputs depart from training distribution
Treatment of OOD inputs per AI use case may include refusal (TRU.SA), deferral to human per HUM.IN, escalation, or constrained response
Linkage with drift detection per LIF.OP-02 surfaces distribution shifts over time
Out-of-distribution detection mechanisms (uncertainty estimation, feature-space distance, ensembles) identify OOD inputs at inference
Behaviour evaluation under distribution shift per LIF.VA-02 measures performance degradation as inputs depart from training distribution
Treatment of OOD inputs per AI use case may include refusal (TRU.SA), deferral to human per HUM.IN, escalation, or constrained response
Linkage with drift detection per LIF.OP-02 surfaces distribution shifts over time
Control Mapping
ISO/IEC 42001:2023 — A.6.2.7
NIST AI RMF — MEASURE 2.7; MEASURE 2.5
EU AI Act — Art. 15
ISO/IEC 24029-2:2023 — Cl. 5.3; Cl. 5.4
OWASP AISVS — C11
OWASP AI Testing Guide — AITG-MOD-06 (Robustness to New Data)
NIST AI RMF — MEASURE 2.7; MEASURE 2.5
EU AI Act — Art. 15
ISO/IEC 24029-2:2023 — Cl. 5.3; Cl. 5.4
OWASP AISVS — C11
OWASP AI Testing Guide — AITG-MOD-06 (Robustness to New Data)
TRU.RB-03Input perturbation robustness — covering noise tolerance, format variation handling, and stress testing — is establishedT 6 · C 6 · F 6
Applies To
Noise tolerance (input perturbation, sensor noise, transcription errors)
Format variation handling (input format differences, locale differences)
Stress testing per LIF.VA-02
Per-domain perturbation profiles
Robustness metric tracking
Format variation handling (input format differences, locale differences)
Stress testing per LIF.VA-02
Per-domain perturbation profiles
Robustness metric tracking
Control Details
Input perturbation robustness ensures AI behaves predictably under realistic input variation
Noise tolerance addresses sensor noise (vision, speech), transcription errors, and minor input perturbations
Format variation handling addresses input format differences (encoding, locale, format-string variation) without disproportionate behaviour change
Stress testing per LIF.VA-02 validates robustness pre-deployment
Per-domain perturbation profiles tailor robustness testing to the AI's operating domain
Robustness metric tracking surfaces robustness regressions
Noise tolerance addresses sensor noise (vision, speech), transcription errors, and minor input perturbations
Format variation handling addresses input format differences (encoding, locale, format-string variation) without disproportionate behaviour change
Stress testing per LIF.VA-02 validates robustness pre-deployment
Per-domain perturbation profiles tailor robustness testing to the AI's operating domain
Robustness metric tracking surfaces robustness regressions
Control Mapping
ISO/IEC 42001:2023 — A.6.2.7
NIST AI RMF — MEASURE 2.7; MEASURE 2.5
EU AI Act — Art. 15
ISO/IEC TR 24029-1:2021 — Cl. 5
OWASP AISVS — C2 (Input Validation); C11
OWASP AI Testing Guide — AITG-MOD-01 (Evasion Attacks); AITG-APP-08 (Embedding Manipulation)
NIST AI RMF — MEASURE 2.7; MEASURE 2.5
EU AI Act — Art. 15
ISO/IEC TR 24029-1:2021 — Cl. 5
OWASP AISVS — C2 (Input Validation); C11
OWASP AI Testing Guide — AITG-MOD-01 (Evasion Attacks); AITG-APP-08 (Embedding Manipulation)
TRU.RB-04Robustness monitoring in production — covering ongoing robustness measurement, signal detection, and response — is establishedT 7 · C 6 · F 6
Applies To
Ongoing robustness measurement in production
Anomalous input pattern detection per LIF.OP-03
Robustness degradation signals
Linkage with incident response per LIF.IR
Robustness reporting
Anomalous input pattern detection per LIF.OP-03
Robustness degradation signals
Linkage with incident response per LIF.IR
Robustness reporting
Control Details
Robustness monitoring in production tracks signals that may indicate robustness degradation (increased OOD detections, anomalous input patterns, output instability under similar inputs)
Anomalous input pattern detection per LIF.OP-03 surfaces adversarial activity
Robustness degradation signals trigger investigation and remediation per TRU.RB-01 or RSK.TR
Linkage with incident response per LIF.IR ensures material robustness incidents are handled
Robustness reporting feeds AIMS KPI / KRI per GOV.OV-01
Anomalous input pattern detection per LIF.OP-03 surfaces adversarial activity
Robustness degradation signals trigger investigation and remediation per TRU.RB-01 or RSK.TR
Linkage with incident response per LIF.IR ensures material robustness incidents are handled
Robustness reporting feeds AIMS KPI / KRI per GOV.OV-01
Control Mapping
ISO/IEC 42001:2023 — A.6.2.6
NIST AI RMF — MEASURE 2.7; MANAGE 4.1
EU AI Act — Art. 15; Art. 72
NIST AI 100-2 (Adversarial Machine Learning Taxonomy)
OWASP AISVS — C13
NIST AI RMF — MEASURE 2.7; MANAGE 4.1
EU AI Act — Art. 15; Art. 72
NIST AI 100-2 (Adversarial Machine Learning Taxonomy)
OWASP AISVS — C13
TRU.SAAI Safety5 Controls
Description: AI safety — covering AI safety boundaries (harmful output prevention, refusal training, content filters), agent behaviour safety (action limits, goal alignment, multi-agent containment), safety testing methodology, dangerous-capability assessment for foundation models, and safety monitoring — is established, applied, and maintained
TRU.SA-01AI safety boundaries — covering harmful output prevention, refusal training, content filters, and policy enforcement — are established per AI systemT 7 · C 6 · F 6
Applies To
Harmful output prevention per content category
Refusal training during model training per LIF.TR-04
Content filters at inference (input and output)
Policy enforcement (refusal policy per use case)
Per-AI-system safety boundary specification
Refusal training during model training per LIF.TR-04
Content filters at inference (input and output)
Policy enforcement (refusal policy per use case)
Per-AI-system safety boundary specification
Control Details
AI safety boundaries are specified per AI system based on intended use, affected parties per CON.IP-02, and ethical commitments per GOV.ET
Harmful output prevention addresses content categories (illegal content, harassment, self-harm, CSAM, manipulation, security advice with malicious application, etc.)
Refusal training during model training per LIF.TR-04 builds refusal behaviour into the model where appropriate
Content filters at inference apply input filtering (prompt screening) and output filtering before responses reach users
Policy enforcement defines refusal policies per use case and is documented in instructions for use per TRA.IU-03
Harmful output prevention addresses content categories (illegal content, harassment, self-harm, CSAM, manipulation, security advice with malicious application, etc.)
Refusal training during model training per LIF.TR-04 builds refusal behaviour into the model where appropriate
Content filters at inference apply input filtering (prompt screening) and output filtering before responses reach users
Policy enforcement defines refusal policies per use case and is documented in instructions for use per TRA.IU-03
Control Mapping
ISO/IEC 42001:2023 — A.6.2.5; A.6.2.6
NIST AI RMF — MEASURE 2.6
EU AI Act — Art. 15
NIST AI 100-4 (Reducing Risks from Synthetic Content)
OWASP AISVS — C7 (Model Behavior); C2 (Input Validation)
OWASP Top 10 LLM (LLM05 Improper Output Handling; LLM09 Misinformation)
NIST AI RMF — MEASURE 2.6
EU AI Act — Art. 15
NIST AI 100-4 (Reducing Risks from Synthetic Content)
OWASP AISVS — C7 (Model Behavior); C2 (Input Validation)
OWASP Top 10 LLM (LLM05 Improper Output Handling; LLM09 Misinformation)
TRU.SA-02Agent behaviour safety — covering action limits, goal alignment, multi-agent containment, and behaviour boundaries — is established per agent systemT 7 · C 6 · F 6
Applies To
Agent action limits per LIF.AG-01 authorisation scope
Goal alignment verification (agent objective vs intended objective)
Multi-agent containment per LIF.AG-03
Behaviour boundaries (refusal, escalation, abort conditions)
Linkage with emergency suspension per LIF.AG-05
Goal alignment verification (agent objective vs intended objective)
Multi-agent containment per LIF.AG-03
Behaviour boundaries (refusal, escalation, abort conditions)
Linkage with emergency suspension per LIF.AG-05
Control Details
Agent behaviour safety extends AI safety boundaries to autonomous and agentic systems per LIF.AG
Agent action limits per LIF.AG-01 prevent agents from taking actions outside authorised scope
Goal alignment verification monitors agent objective adherence and surfaces drift toward unintended goals
Multi-agent containment per LIF.AG-03 prevents cascading or colluding behaviour across agents
Behaviour boundaries define when an agent must refuse, escalate to human, or abort an action chain
Linkage with emergency suspension per LIF.AG-05 enables intervention when safety boundaries are breached
Agent action limits per LIF.AG-01 prevent agents from taking actions outside authorised scope
Goal alignment verification monitors agent objective adherence and surfaces drift toward unintended goals
Multi-agent containment per LIF.AG-03 prevents cascading or colluding behaviour across agents
Behaviour boundaries define when an agent must refuse, escalate to human, or abort an action chain
Linkage with emergency suspension per LIF.AG-05 enables intervention when safety boundaries are breached
Control Mapping
ISO/IEC 42001:2023 — A.6.2.5; A.9
NIST AI RMF — MEASURE 2.6; MAP 3.5
EU AI Act — Art. 14; Art. 15
OWASP AISVS — C9 (Orchestration and Agentic Action); C14 (Human Oversight)
OWASP Top 10 for Agentic Apps (ASI01 Agent Goal Hijack; ASI06 Memory and Context Poisoning)
OWASP Multi-Agentic System Threat Modelling Guide
CSA Agentic AI Red Teaming Guide
NIST AI RMF — MEASURE 2.6; MAP 3.5
EU AI Act — Art. 14; Art. 15
OWASP AISVS — C9 (Orchestration and Agentic Action); C14 (Human Oversight)
OWASP Top 10 for Agentic Apps (ASI01 Agent Goal Hijack; ASI06 Memory and Context Poisoning)
OWASP Multi-Agentic System Threat Modelling Guide
CSA Agentic AI Red Teaming Guide
TRU.SA-03AI safety testing methodology — covering safety test design, evaluation criteria, and methodology documentation — is establishedT 7 · C 6 · F 6
Applies To
Safety test design per AI use case
Safety evaluation criteria
Methodology documentation
Integration with LIF.VA validation and RSK.AR red teaming
Methodology review
Safety evaluation criteria
Methodology documentation
Integration with LIF.VA validation and RSK.AR red teaming
Methodology review
Control Details
AI safety testing methodology is documented and applied per AI system
Safety test design covers harm scenarios per IMP.IA-01, refusal expectations per TRU.SA-01, and agent behaviour expectations per TRU.SA-02 where applicable
Safety evaluation criteria define pass / fail thresholds and severity-graded failure handling
Methodology documentation supports reproducibility and audit
Integration with LIF.VA-04 adversarial testing and RSK.AR-04 red teaming ensures safety is part of comprehensive validation
Methodology is reviewed when new harm classes emerge or regulatory expectations change
Safety test design covers harm scenarios per IMP.IA-01, refusal expectations per TRU.SA-01, and agent behaviour expectations per TRU.SA-02 where applicable
Safety evaluation criteria define pass / fail thresholds and severity-graded failure handling
Methodology documentation supports reproducibility and audit
Integration with LIF.VA-04 adversarial testing and RSK.AR-04 red teaming ensures safety is part of comprehensive validation
Methodology is reviewed when new harm classes emerge or regulatory expectations change
Control Mapping
ISO/IEC 42001:2023 — A.6.2.6; A.6.2.7
NIST AI RMF — MEASURE 2.6; MEASURE 1.1
EU AI Act — Art. 15; Art. 55
OWASP AI Testing Guide — AITG-APP-05 (Unsafe Outputs); AITG-APP-12 (Toxic Output); AITG-MOD-07 (Goal Alignment)
OWASP GenAI Red Teaming Guide
OWASP AISVS — C7; C11
NIST AI RMF — MEASURE 2.6; MEASURE 1.1
EU AI Act — Art. 15; Art. 55
OWASP AI Testing Guide — AITG-APP-05 (Unsafe Outputs); AITG-APP-12 (Toxic Output); AITG-MOD-07 (Goal Alignment)
OWASP GenAI Red Teaming Guide
OWASP AISVS — C7; C11
TRU.SA-04Dangerous-capability assessment for foundation models — covering capability elicitation, risk thresholds, and Art. 55 alignment — is performed per GPAI per IMP.GP-01T 7 · C 6 · F 6
Applies To
Dangerous-capability categories (cyber, CBRN-relevant, persuasion, autonomy, deception)
Capability elicitation testing per OWASP GenAI Red Teaming
Risk thresholds per capability category
Findings management per RSK.TR
Reporting per Art. 55 where applicable
Capability elicitation testing per OWASP GenAI Red Teaming
Risk thresholds per capability category
Findings management per RSK.TR
Reporting per Art. 55 where applicable
Control Details
Dangerous-capability assessment is performed for foundation models per CON.IN-02, especially those meeting systemic-risk thresholds per IMP.GP-01
Dangerous-capability categories include cybersecurity uplift, CBRN-relevant knowledge synthesis, large-scale persuasion / manipulation, autonomy and self-direction, deception
Capability elicitation testing applies methods from OWASP GenAI Red Teaming Guide and CSA Agentic Red Teaming Guide
Risk thresholds per capability category determine when capability constitutes systemic risk requiring mitigation
Findings management per RSK.TR addresses identified capabilities; mitigations may include capability reduction (further refusal training), use restriction, or model withholding
Reporting per Art. 55 covers serious findings for systemic-risk GPAI per IMP.GP-04
Dangerous-capability categories include cybersecurity uplift, CBRN-relevant knowledge synthesis, large-scale persuasion / manipulation, autonomy and self-direction, deception
Capability elicitation testing applies methods from OWASP GenAI Red Teaming Guide and CSA Agentic Red Teaming Guide
Risk thresholds per capability category determine when capability constitutes systemic risk requiring mitigation
Findings management per RSK.TR addresses identified capabilities; mitigations may include capability reduction (further refusal training), use restriction, or model withholding
Reporting per Art. 55 covers serious findings for systemic-risk GPAI per IMP.GP-04
Control Mapping
ISO/IEC 42001:2023 — A.6.2.7; A.5.2
NIST AI RMF — MEASURE 2.6; MAP 5.1
EU AI Act — Art. 55
EU GPAI Code of Practice (Safety and Security Chapter)
NIST AI 100-2 (Adversarial Machine Learning Taxonomy)
OWASP GenAI Red Teaming Guide
CSA Agentic AI Red Teaming Guide
NIST AI RMF — MEASURE 2.6; MAP 5.1
EU AI Act — Art. 55
EU GPAI Code of Practice (Safety and Security Chapter)
NIST AI 100-2 (Adversarial Machine Learning Taxonomy)
OWASP GenAI Red Teaming Guide
CSA Agentic AI Red Teaming Guide
TRU.SA-05AI safety monitoring in production — covering refusal-failure tracking, safety boundary breach detection, and reporting — is establishedT 7 · C 6 · F 6
Applies To
Refusal-failure tracking per LIF.OP-04
Safety boundary breach detection per agent and per AI system
Output safety event reporting
Linkage with incident response per LIF.IR
Safety KPI reporting per GOV.OV-01
Safety boundary breach detection per agent and per AI system
Output safety event reporting
Linkage with incident response per LIF.IR
Safety KPI reporting per GOV.OV-01
Control Details
AI safety monitoring in production extends LIF.OP-04 output safety monitoring to all safety boundaries per TRU.SA-01
Refusal-failure tracking detects cases where AI should have refused but did not, including failures by sub-class (harassment, illegal content, etc.)
Safety boundary breach detection per agent and per AI system surfaces actions outside scope per TRU.SA-02
Output safety event reporting captures details for analysis and learning per LIF.IR-03
Linkage with incident response per LIF.IR ensures material safety events trigger formal response
Safety KPIs feed AIMS KPI / KRI reporting per GOV.OV-01
Refusal-failure tracking detects cases where AI should have refused but did not, including failures by sub-class (harassment, illegal content, etc.)
Safety boundary breach detection per agent and per AI system surfaces actions outside scope per TRU.SA-02
Output safety event reporting captures details for analysis and learning per LIF.IR-03
Linkage with incident response per LIF.IR ensures material safety events trigger formal response
Safety KPIs feed AIMS KPI / KRI reporting per GOV.OV-01
Control Mapping
ISO/IEC 42001:2023 — A.6.2.6
NIST AI RMF — MEASURE 2.6; MANAGE 4.1
EU AI Act — Art. 15; Art. 72
OWASP AISVS — C13 (Monitoring and Logging); C7 (Model Behavior)
OWASP Top 10 LLM
NIST AI RMF — MEASURE 2.6; MANAGE 4.1
EU AI Act — Art. 15; Art. 72
OWASP AISVS — C13 (Monitoring and Logging); C7 (Model Behavior)
OWASP Top 10 LLM
TRU.EXAI Explainability and Interpretability4 Controls
Description: AI explainability and interpretability — covering explainability requirements per AI use case and risk class, explanation techniques (model-agnostic, model-specific, post-hoc, intrinsic), explanation quality and faithfulness measurement, user-facing explanation delivery, and explainability documentation — are determined, applied, and maintained
TRU.EX-01Explainability requirements per AI use case — covering requirement determination, depth per use case, and audience consideration — are establishedT 6 · C 6 · F 6
Applies To
Explainability requirement determination per AI use case
Explanation depth (local vs global, technical vs user-facing)
Audience consideration (developers, deployers, end-users, regulators, affected parties)
Linkage with GDPR Art. 22 and EU AI Act Art. 86 requirements
Requirements documentation
Explanation depth (local vs global, technical vs user-facing)
Audience consideration (developers, deployers, end-users, regulators, affected parties)
Linkage with GDPR Art. 22 and EU AI Act Art. 86 requirements
Requirements documentation
Control Details
Explainability requirements are determined per AI use case based on AI risk class per CON.JU-02, affected party considerations per CON.IP-02, and regulatory expectations
Explanation depth is determined per requirement (local explanations of individual decisions vs global explanations of model behaviour; technical depth for developers vs accessible explanations for end-users)
Audience consideration ensures explanations are appropriate for the intended audience
Linkage with GDPR Art. 22 (meaningful information about logic involved) and EU AI Act Art. 86 (right to explanation) ensures regulatory requirements are met
Requirements are documented per AI system in design per LIF.DE-01
Explanation depth is determined per requirement (local explanations of individual decisions vs global explanations of model behaviour; technical depth for developers vs accessible explanations for end-users)
Audience consideration ensures explanations are appropriate for the intended audience
Linkage with GDPR Art. 22 (meaningful information about logic involved) and EU AI Act Art. 86 (right to explanation) ensures regulatory requirements are met
Requirements are documented per AI system in design per LIF.DE-01
Control Mapping
ISO/IEC 42001:2023 — A.6.2.8; A.8
NIST AI RMF — MEASURE 2.9; MAP 1.6
EU AI Act — Art. 13; Art. 14; Art. 86
GDPR — Art. 13(2)(f); Art. 14(2)(g); Art. 22(3)
NIST IR 8312 (Four Principles of Explainable AI)
OWASP AISVS — C7 (Model Behavior)
NIST AI RMF — MEASURE 2.9; MAP 1.6
EU AI Act — Art. 13; Art. 14; Art. 86
GDPR — Art. 13(2)(f); Art. 14(2)(g); Art. 22(3)
NIST IR 8312 (Four Principles of Explainable AI)
OWASP AISVS — C7 (Model Behavior)
TRU.EX-02Explanation techniques applied — covering model-agnostic methods, model-specific methods, post-hoc explanations, and intrinsic interpretability — are selected and implemented per AI systemT 6 · C 6 · F 6
Applies To
Model-agnostic explanation methods (LIME, SHAP, counterfactual)
Model-specific explanation methods (attention visualisation, gradient-based)
Post-hoc explanation production
Intrinsic interpretability (interpretable models where appropriate)
Technique selection per requirements per TRU.EX-01
Model-specific explanation methods (attention visualisation, gradient-based)
Post-hoc explanation production
Intrinsic interpretability (interpretable models where appropriate)
Technique selection per requirements per TRU.EX-01
Control Details
Explanation techniques are selected per AI system based on explainability requirements per TRU.EX-01, model architecture, and computational feasibility
Model-agnostic methods (LIME, SHAP, counterfactual explanations) provide explanations independent of model internals
Model-specific methods leverage architecture (attention visualisation for transformers, gradient-based for neural networks)
Post-hoc explanations are produced at inference time or on demand for specific predictions
Intrinsic interpretability favours interpretable model families (decision trees, linear models, sparse models) where appropriate to the use case
Implementation is documented per AI system and integrates with TRU.EX-04 user-facing delivery
Model-agnostic methods (LIME, SHAP, counterfactual explanations) provide explanations independent of model internals
Model-specific methods leverage architecture (attention visualisation for transformers, gradient-based for neural networks)
Post-hoc explanations are produced at inference time or on demand for specific predictions
Intrinsic interpretability favours interpretable model families (decision trees, linear models, sparse models) where appropriate to the use case
Implementation is documented per AI system and integrates with TRU.EX-04 user-facing delivery
Control Mapping
ISO/IEC 42001:2023 — A.6.2.8; A.6.2.7
NIST AI RMF — MEASURE 2.9
EU AI Act — Art. 13; Art. 14; Art. 86
NIST IR 8312 (Four Principles of Explainable AI)
OWASP AISVS — C7
OWASP AI Testing Guide — AITG-APP-14 (Explainability and Interpretability)
NIST AI RMF — MEASURE 2.9
EU AI Act — Art. 13; Art. 14; Art. 86
NIST IR 8312 (Four Principles of Explainable AI)
OWASP AISVS — C7
OWASP AI Testing Guide — AITG-APP-14 (Explainability and Interpretability)
TRU.EX-03Explanation quality and faithfulness measurement — covering fidelity, stability, and human comprehensibility — is performedT 6 · C 6 · F 6
Applies To
Faithfulness / fidelity measurement (explanation reflects model behaviour)
Stability measurement (similar inputs produce similar explanations)
Human comprehensibility evaluation
Explanation quality reporting
Linkage with TRU.EX-04 user-facing delivery
Stability measurement (similar inputs produce similar explanations)
Human comprehensibility evaluation
Explanation quality reporting
Linkage with TRU.EX-04 user-facing delivery
Control Details
Explanation quality is measured through faithfulness / fidelity testing — does the explanation accurately reflect the model's decision process
Stability is measured — similar inputs should produce similar explanations
Human comprehensibility is evaluated through user studies, expert review, or proxy measurements
Explanation quality findings feed methodology refinement per TRU.PO-03
Linkage with TRU.EX-04 ensures user-facing explanations meet quality standards
Stability is measured — similar inputs should produce similar explanations
Human comprehensibility is evaluated through user studies, expert review, or proxy measurements
Explanation quality findings feed methodology refinement per TRU.PO-03
Linkage with TRU.EX-04 ensures user-facing explanations meet quality standards
Control Mapping
ISO/IEC 42001:2023 — A.6.2.8
NIST AI RMF — MEASURE 2.9; MEASURE 4.1
EU AI Act — Art. 13; Art. 86
NIST IR 8312 (Four Principles of Explainable AI)
OWASP AISVS — C7
OWASP AI Testing Guide — AITG-APP-14 (Explainability and Interpretability)
NIST AI RMF — MEASURE 2.9; MEASURE 4.1
EU AI Act — Art. 13; Art. 86
NIST IR 8312 (Four Principles of Explainable AI)
OWASP AISVS — C7
OWASP AI Testing Guide — AITG-APP-14 (Explainability and Interpretability)
TRU.EX-04User-facing explanation delivery — covering presentation, accessibility, and linkage with right-to-explanation processes — is establishedT 7 · C 6 · F 6
Applies To
Presentation design (format, language, visualisation)
Accessibility considerations
Right-to-explanation process linkage per HUM.UA-02
Delivery channel (in-product, on request, in disclosure)
Explanation language localisation
Accessibility considerations
Right-to-explanation process linkage per HUM.UA-02
Delivery channel (in-product, on request, in disclosure)
Explanation language localisation
Control Details
User-facing explanation delivery presents explanations in appropriate format for the intended audience
Presentation design considers user context (in-product real-time vs on-request investigation) and complexity (summary plus optional depth)
Accessibility considerations ensure explanations are perceivable and understandable by diverse users
Linkage with HUM.UA-02 right-to-explanation processes ensures regulatory rights are operationalised through explanation delivery
Delivery channels include in-product display, on-request explanation, and inclusion in formal disclosures per TRA.UD
Explanation language localisation supports multi-jurisdictional deployments
Presentation design considers user context (in-product real-time vs on-request investigation) and complexity (summary plus optional depth)
Accessibility considerations ensure explanations are perceivable and understandable by diverse users
Linkage with HUM.UA-02 right-to-explanation processes ensures regulatory rights are operationalised through explanation delivery
Delivery channels include in-product display, on-request explanation, and inclusion in formal disclosures per TRA.UD
Explanation language localisation supports multi-jurisdictional deployments
Control Mapping
ISO/IEC 42001:2023 — A.6.2.8; A.8
NIST AI RMF — MEASURE 2.9; MEASURE 3.3
EU AI Act — Art. 13; Art. 26(11); Art. 86
GDPR — Art. 13; Art. 14; Art. 22(3)
NIST IR 8312 (Four Principles of Explainable AI)
OWASP AISVS — C7; C14 (Human Oversight)
NIST AI RMF — MEASURE 2.9; MEASURE 3.3
EU AI Act — Art. 13; Art. 26(11); Art. 86
GDPR — Art. 13; Art. 14; Art. 22(3)
NIST IR 8312 (Four Principles of Explainable AI)
OWASP AISVS — C7; C14 (Human Oversight)
TRU.PEPrivacy-Enhancing Technologies for AI3 Controls
Description: Privacy-enhancing technologies (PETs) for AI — covering differential privacy, federated learning, secure multi-party computation, homomorphic encryption, anonymisation and pseudonymisation for AI training, PET selection per AI use case, and PET effectiveness measurement — are evaluated, applied where appropriate, and maintained
TRU.PE-01PET selection and application per AI use case — covering PET options, selection criteria, and application — are establishedT 7 · C 6 · F 6
Applies To
PET options (differential privacy, federated learning, secure multi-party computation, homomorphic encryption, anonymisation, pseudonymisation, k-anonymity-style)
Selection criteria per use case
Application architecture (where in the AI pipeline)
PET combination
Documentation per AI system
Selection criteria per use case
Application architecture (where in the AI pipeline)
PET combination
Documentation per AI system
Control Details
Privacy-enhancing technologies are evaluated and applied per AI use case where personal data is processed per DAT.LB
PET selection criteria include privacy guarantees needed, utility impact, computational cost, ease of deployment, and regulatory expectations
Application architecture defines where in the AI pipeline PETs apply (training, fine-tuning, inference, output)
PET combination addresses use cases requiring layered privacy guarantees (e.g., differential privacy plus federated learning)
PET application is documented per AI system to support audit and provide evidence for GDPR accountability per Art. 5(2)
PET selection criteria include privacy guarantees needed, utility impact, computational cost, ease of deployment, and regulatory expectations
Application architecture defines where in the AI pipeline PETs apply (training, fine-tuning, inference, output)
PET combination addresses use cases requiring layered privacy guarantees (e.g., differential privacy plus federated learning)
PET application is documented per AI system to support audit and provide evidence for GDPR accountability per Art. 5(2)
Control Mapping
ISO/IEC 42001:2023 — A.7.4; A.6.2
NIST AI RMF — MEASURE 2.10
EU AI Act — Art. 10(5)
GDPR — Art. 25; Art. 32
NIST Privacy Framework v1.0
OWASP AISVS — C12 (Privacy)
NIST AI RMF — MEASURE 2.10
EU AI Act — Art. 10(5)
GDPR — Art. 25; Art. 32
NIST Privacy Framework v1.0
OWASP AISVS — C12 (Privacy)
TRU.PE-02Privacy-preserving training — covering differential privacy, federated learning, and secure multi-party computation where applied — is establishedT 6 · C 5 · F 6
Applies To
Differential privacy in training (DP-SGD, output perturbation)
Federated learning architecture
Secure multi-party computation for collaborative training
Privacy budget management (where DP is used)
Effectiveness verification
Federated learning architecture
Secure multi-party computation for collaborative training
Privacy budget management (where DP is used)
Effectiveness verification
Control Details
Privacy-preserving training applies appropriate techniques to training pipelines where personal data is involved
Differential privacy in training uses techniques like DP-SGD with privacy budget management and accountant tracking
Federated learning architecture keeps data at sources with model updates aggregated centrally
Secure multi-party computation enables collaborative training without exposing raw data
Privacy budget management is documented and enforced (cumulative privacy budget tracked across training runs)
Effectiveness is verified through standard tests (membership inference resistance per DAT.LK-02)
Differential privacy in training uses techniques like DP-SGD with privacy budget management and accountant tracking
Federated learning architecture keeps data at sources with model updates aggregated centrally
Secure multi-party computation enables collaborative training without exposing raw data
Privacy budget management is documented and enforced (cumulative privacy budget tracked across training runs)
Effectiveness is verified through standard tests (membership inference resistance per DAT.LK-02)
Control Mapping
ISO/IEC 42001:2023 — A.7.4; A.6.2
NIST AI RMF — MEASURE 2.10
EU AI Act — Art. 10(5)
GDPR — Art. 25; Art. 32
NIST Privacy Framework v1.0
OWASP AISVS — C12
NIST AI RMF — MEASURE 2.10
EU AI Act — Art. 10(5)
GDPR — Art. 25; Art. 32
NIST Privacy Framework v1.0
OWASP AISVS — C12
TRU.PE-03PET effectiveness measurement — covering privacy guarantee verification, residual privacy risk assessment, and reporting — is performedT 6 · C 5 · F 6
Applies To
Privacy guarantee verification per applied PET
Residual privacy risk assessment per DAT.SY-03 for synthetic data
Linkage with re-identification testing per DAT.SY-03 and membership inference per DAT.LK-02
Reporting and documentation
PET update on findings
Residual privacy risk assessment per DAT.SY-03 for synthetic data
Linkage with re-identification testing per DAT.SY-03 and membership inference per DAT.LK-02
Reporting and documentation
PET update on findings
Control Details
PET effectiveness measurement verifies that applied PETs deliver the intended privacy guarantees
For differential privacy, formal privacy parameters (epsilon, delta) are documented and budget consumption is tracked
Residual privacy risk assessment evaluates whether PET implementation achieves intended privacy outcomes in practice
Linkage with re-identification testing per DAT.SY-03 and membership inference testing per DAT.LK-02 provides empirical evidence
Reporting and documentation feed audit per GOV.OV-03 and regulatory disclosure where applicable
PET updates on findings address effectiveness gaps
For differential privacy, formal privacy parameters (epsilon, delta) are documented and budget consumption is tracked
Residual privacy risk assessment evaluates whether PET implementation achieves intended privacy outcomes in practice
Linkage with re-identification testing per DAT.SY-03 and membership inference testing per DAT.LK-02 provides empirical evidence
Reporting and documentation feed audit per GOV.OV-03 and regulatory disclosure where applicable
PET updates on findings address effectiveness gaps
Control Mapping
ISO/IEC 42001:2023 — A.7.4; Cl. 9.1
NIST AI RMF — MEASURE 2.10; MEASURE 4.1
EU AI Act — Art. 10(5); Art. 15
GDPR — Art. 25; Art. 32; Art. 35
NIST Privacy Framework v1.0
OWASP AISVS — C12
NIST AI RMF — MEASURE 2.10; MEASURE 4.1
EU AI Act — Art. 10(5); Art. 15
GDPR — Art. 25; Art. 32; Art. 35
NIST Privacy Framework v1.0
OWASP AISVS — C12
TRU.OIAI Output Integrity and Provenance4 Controls
Description: AI output integrity and provenance — covering AI-generated content marking and watermarking per EU AI Act Art. 50, output provenance traceability, synthetic content identification (deepfake, AI-generated media), output integrity verification, and downstream attribution — are established, applied, and maintained
TRU.OI-01AI-generated content marking and watermarking per EU AI Act Art. 50 — covering provider obligations and technical implementation — is appliedT 7 · C 6 · F 6
Applies To
Provider marking obligation per Art. 50(2)
Watermark technical implementation (e.g., cryptographic watermarking, statistical marking)
Marking robustness against tampering
Marking interoperability with C2PA / content provenance standards where applicable
Documentation in instructions for use per TRA.IU
Watermark technical implementation (e.g., cryptographic watermarking, statistical marking)
Marking robustness against tampering
Marking interoperability with C2PA / content provenance standards where applicable
Documentation in instructions for use per TRA.IU
Control Details
AI-generated content marking is implemented per Art. 50(2) for provider AI products that generate synthetic content (audio, image, video, text)
Watermark technical implementation uses appropriate marking technology — cryptographic watermarking, statistical marking, metadata-based marking — selected for content type and use case
Marking robustness against tampering is evaluated and improved over time
Marking interoperability with C2PA (Coalition for Content Provenance and Authenticity) or similar standards is considered to support ecosystem-wide content provenance
Marking implementation is documented in instructions for use per TRA.IU-01
Watermark technical implementation uses appropriate marking technology — cryptographic watermarking, statistical marking, metadata-based marking — selected for content type and use case
Marking robustness against tampering is evaluated and improved over time
Marking interoperability with C2PA (Coalition for Content Provenance and Authenticity) or similar standards is considered to support ecosystem-wide content provenance
Marking implementation is documented in instructions for use per TRA.IU-01
Control Mapping
ISO/IEC 42001:2023 — A.6.2.5; A.8
NIST AI RMF — MEASURE 2.8; GOVERN 1.1
EU AI Act — Art. 50(2); Art. 50(5)
EU GPAI Code of Practice (Transparency Chapter)
NIST AI 100-4 (Reducing Risks from Synthetic Content)
OWASP AISVS — C7 (Model Behavior)
NIST AI RMF — MEASURE 2.8; GOVERN 1.1
EU AI Act — Art. 50(2); Art. 50(5)
EU GPAI Code of Practice (Transparency Chapter)
NIST AI 100-4 (Reducing Risks from Synthetic Content)
OWASP AISVS — C7 (Model Behavior)
TRU.OI-02Output provenance traceability — covering output-to-model linkage, output-to-input lineage, and audit traceability — is establishedT 7 · C 6 · F 6
Applies To
Output-to-model version linkage per LIF.VR
Output-to-input lineage (what model version, prompt, retrieval results produced this output)
Audit traceability for output review
Provenance metadata in outputs
Linkage with action logs per TRA.AG for agentic outputs
Output-to-input lineage (what model version, prompt, retrieval results produced this output)
Audit traceability for output review
Provenance metadata in outputs
Linkage with action logs per TRA.AG for agentic outputs
Control Details
Output provenance traceability links AI outputs to the model version, prompt / system instructions, and retrieval results that produced them
Output-to-model linkage uses model registry per LIF.VR-01 identifiers
Output-to-input lineage captures prompt, retrieved context (for RAG), and tool returns (for agentic outputs)
Audit traceability supports incident investigation per LIF.IR-03 and regulatory inquiry
Provenance metadata in outputs is captured where appropriate, balancing utility and operational overhead
Linkage with action logs per TRA.AG ensures agentic outputs are traceable through agent decision chains
Output-to-model linkage uses model registry per LIF.VR-01 identifiers
Output-to-input lineage captures prompt, retrieved context (for RAG), and tool returns (for agentic outputs)
Audit traceability supports incident investigation per LIF.IR-03 and regulatory inquiry
Provenance metadata in outputs is captured where appropriate, balancing utility and operational overhead
Linkage with action logs per TRA.AG ensures agentic outputs are traceable through agent decision chains
Control Mapping
ISO/IEC 42001:2023 — A.6.2.5; A.7.5
NIST AI RMF — MEASURE 2.8
EU AI Act — Art. 12; Art. 50
EU GPAI Code of Practice (Transparency Chapter)
OWASP AISVS — C13 (Monitoring and Logging)
NIST AI RMF — MEASURE 2.8
EU AI Act — Art. 12; Art. 50
EU GPAI Code of Practice (Transparency Chapter)
OWASP AISVS — C13 (Monitoring and Logging)
TRU.OI-03Synthetic content identification (deepfake, AI-generated media) — covering deepfake detection, attribution, and reporting — is established for deployers and providersT 7 · C 6 · F 6
Applies To
Deepfake detection capability where deployers or providers handle generated content
Attribution support (identification of generating model if marked)
Deployer disclosure obligation per Art. 50(4)
Linkage with content moderation operations
Detection methodology
Attribution support (identification of generating model if marked)
Deployer disclosure obligation per Art. 50(4)
Linkage with content moderation operations
Detection methodology
Control Details
Synthetic content identification supports deployer disclosure obligations per Art. 50(4) for deepfakes
Detection capability is provided through deployer-facing tools and APIs where the company is a provider
Attribution support identifies the generating model where AI-generated content is marked per TRU.OI-01
Deployer disclosure obligation per Art. 50(4) requires deployers of AI generating or manipulating image, audio, or video constituting a deepfake to disclose the content as artificially generated
Linkage with content moderation operations integrates synthetic content identification with broader content workflows
Detection methodology is documented and updated as deepfake techniques evolve
Detection capability is provided through deployer-facing tools and APIs where the company is a provider
Attribution support identifies the generating model where AI-generated content is marked per TRU.OI-01
Deployer disclosure obligation per Art. 50(4) requires deployers of AI generating or manipulating image, audio, or video constituting a deepfake to disclose the content as artificially generated
Linkage with content moderation operations integrates synthetic content identification with broader content workflows
Detection methodology is documented and updated as deepfake techniques evolve
Control Mapping
ISO/IEC 42001:2023 — A.6.2.5; A.8
NIST AI RMF — MEASURE 2.8; MEASURE 2.6
EU AI Act — Art. 50(2); Art. 50(4)
EU GPAI Code of Practice (Transparency Chapter)
NIST AI 100-4 (Reducing Risks from Synthetic Content)
NIST AI RMF — MEASURE 2.8; MEASURE 2.6
EU AI Act — Art. 50(2); Art. 50(4)
EU GPAI Code of Practice (Transparency Chapter)
NIST AI 100-4 (Reducing Risks from Synthetic Content)
TRU.OI-04Downstream attribution and output integrity verification — covering downstream-of-AI content tracking and integrity verification — is establishedT 7 · C 6 · F 6
Applies To
Downstream content tracking (where AI outputs are forwarded, modified, or republished)
Integrity verification for AI outputs in downstream contexts
Attribution metadata preservation
Tampering detection
Linkage with provider downstream obligations per TPA.GP
Integrity verification for AI outputs in downstream contexts
Attribution metadata preservation
Tampering detection
Linkage with provider downstream obligations per TPA.GP
Control Details
Downstream attribution and output integrity verification address how AI outputs are tracked, verified, and attributed in downstream contexts (customer applications, end-user redistribution)
Downstream content tracking supports identifying when AI outputs have been forwarded, modified, or republished where technically feasible
Integrity verification for AI outputs in downstream contexts uses signed content or verifiable claims where appropriate
Attribution metadata preservation through transformations is supported where standards (C2PA, etc.) allow
Tampering detection identifies cases where AI outputs have been altered without authorisation
Linkage with provider downstream obligations per TPA.GP ensures downstream parties have the tools needed for compliance
Downstream content tracking supports identifying when AI outputs have been forwarded, modified, or republished where technically feasible
Integrity verification for AI outputs in downstream contexts uses signed content or verifiable claims where appropriate
Attribution metadata preservation through transformations is supported where standards (C2PA, etc.) allow
Tampering detection identifies cases where AI outputs have been altered without authorisation
Linkage with provider downstream obligations per TPA.GP ensures downstream parties have the tools needed for compliance
Control Mapping
ISO/IEC 42001:2023 — A.6.2.5; A.10
NIST AI RMF — MEASURE 2.8
EU AI Act — Art. 50; Art. 53(1)(b)
EU GPAI Code of Practice (Transparency Chapter)
NIST AI 100-4 (Reducing Risks from Synthetic Content)
NIST AI RMF — MEASURE 2.8
EU AI Act — Art. 50; Art. 53(1)(b)
EU GPAI Code of Practice (Transparency Chapter)
NIST AI 100-4 (Reducing Risks from Synthetic Content)
TRU.REAI Resilience and Graceful Degradation3 Controls
Description: AI resilience and graceful degradation — covering resilience requirements per AI system criticality, fault tolerance and failover, graceful degradation under input distribution shift or component failure, fallback behaviour design, and resilience testing — are established, applied, and maintained
TRU.RE-01AI resilience requirements per system criticality — covering availability, failure tolerance, and recovery objectives — are definedT 6 · C 6 · F 6
Applies To
Availability requirements per AI system criticality per CON.IN-01
Failure tolerance requirements
Recovery time objective (RTO) and recovery point objective (RPO)
Graceful degradation requirements
Linkage with ISMS BCMS where applicable
Failure tolerance requirements
Recovery time objective (RTO) and recovery point objective (RPO)
Graceful degradation requirements
Linkage with ISMS BCMS where applicable
Control Details
AI resilience requirements are defined per AI system criticality per CON.IN-01
Availability requirements address required uptime, accessibility windows, and acceptable outage duration
Failure tolerance requirements address component failure scenarios (model service failure, dependency failure, infrastructure failure)
RTO and RPO are defined where AI system contributes to critical business functions
Graceful degradation requirements define expected behaviour during partial failure (fallback, degraded mode, refusal)
Linkage with ISMS Business Continuity Management System ensures AI resilience aligns with broader continuity planning
Availability requirements address required uptime, accessibility windows, and acceptable outage duration
Failure tolerance requirements address component failure scenarios (model service failure, dependency failure, infrastructure failure)
RTO and RPO are defined where AI system contributes to critical business functions
Graceful degradation requirements define expected behaviour during partial failure (fallback, degraded mode, refusal)
Linkage with ISMS Business Continuity Management System ensures AI resilience aligns with broader continuity planning
Control Mapping
ISO/IEC 42001:2023 — A.6.2.6; A.4.5
NIST AI RMF — MEASURE 2.7; MAP 1.6
EU AI Act — Art. 15
OWASP AISVS — C4 (Infrastructure); C13
ISO 22301:2019 (Business Continuity Management System)
NIST AI RMF — MEASURE 2.7; MAP 1.6
EU AI Act — Art. 15
OWASP AISVS — C4 (Infrastructure); C13
ISO 22301:2019 (Business Continuity Management System)
TRU.RE-02Fault tolerance, failover, and graceful degradation design — covering redundancy, failover mechanisms, and degraded-mode behaviour — is establishedT 7 · C 6 · F 6
Applies To
Redundancy design (model serving redundancy, dependency redundancy)
Failover mechanisms (active-passive, active-active)
Degraded-mode behaviour (fallback to simpler model, rules-based fallback, human routing)
Dependency-failure handling (foundation model API outage, tool unavailability, RAG corpus unavailability)
Documentation per AI system
Failover mechanisms (active-passive, active-active)
Degraded-mode behaviour (fallback to simpler model, rules-based fallback, human routing)
Dependency-failure handling (foundation model API outage, tool unavailability, RAG corpus unavailability)
Documentation per AI system
Control Details
Fault tolerance, failover, and graceful degradation design address resilience requirements per TRU.RE-01
Redundancy design provides multiple model serving instances, redundant dependencies, and geographic distribution where appropriate to criticality
Failover mechanisms (active-passive, active-active) transition traffic when primary components fail
Degraded-mode behaviour defines fallback paths — to simpler model, rules-based fallback, human routing per HUM.IN, refusal with informative message
Dependency-failure handling addresses scenarios like foundation model API outages, tool unavailability, RAG corpus unavailability
Documentation per AI system supports operational handling per LIF.OP and incident response per LIF.IR
Redundancy design provides multiple model serving instances, redundant dependencies, and geographic distribution where appropriate to criticality
Failover mechanisms (active-passive, active-active) transition traffic when primary components fail
Degraded-mode behaviour defines fallback paths — to simpler model, rules-based fallback, human routing per HUM.IN, refusal with informative message
Dependency-failure handling addresses scenarios like foundation model API outages, tool unavailability, RAG corpus unavailability
Documentation per AI system supports operational handling per LIF.OP and incident response per LIF.IR
Control Mapping
ISO/IEC 42001:2023 — A.6.2.6; A.4.5
NIST AI RMF — MEASURE 2.7
EU AI Act — Art. 15
OWASP AISVS — C4 (Infrastructure)
ISO 22301:2019
NIST AI RMF — MEASURE 2.7
EU AI Act — Art. 15
OWASP AISVS — C4 (Infrastructure)
ISO 22301:2019
TRU.RE-03Resilience testing — covering chaos testing, failover exercise, and degraded-mode validation — is performedT 6 · C 6 · F 6
Applies To
Chaos testing (controlled fault injection)
Failover exercise (planned failover testing)
Degraded-mode validation
Recovery testing
Linkage with ISMS BCMS exercises
Failover exercise (planned failover testing)
Degraded-mode validation
Recovery testing
Linkage with ISMS BCMS exercises
Control Details
Resilience testing validates that fault tolerance, failover, and graceful degradation per TRU.RE-02 work as designed
Chaos testing injects controlled faults to validate response (dependency failure, component failure, network partition)
Failover exercise tests planned failover paths under controlled conditions
Degraded-mode validation confirms graceful degradation behaviour matches design
Recovery testing validates RTO / RPO achievement
Linkage with ISMS Business Continuity Management exercises ensures AI resilience is included in broader continuity testing per ISO 22301 expectations
Chaos testing injects controlled faults to validate response (dependency failure, component failure, network partition)
Failover exercise tests planned failover paths under controlled conditions
Degraded-mode validation confirms graceful degradation behaviour matches design
Recovery testing validates RTO / RPO achievement
Linkage with ISMS Business Continuity Management exercises ensures AI resilience is included in broader continuity testing per ISO 22301 expectations
Control Mapping
ISO/IEC 42001:2023 — A.6.2.6; Cl. 9.1
NIST AI RMF — MEASURE 2.7; MEASURE 2.5
EU AI Act — Art. 15
OWASP AISVS — C4
ISO 22301:2019
NIST AI RMF — MEASURE 2.7; MEASURE 2.5
EU AI Act — Art. 15
OWASP AISVS — C4
ISO 22301:2019
Human21 Controls · 6 Objectives
HUM.POHuman Oversight Policy and Methodology3 Controls
Description: The human oversight policy and methodology — covering human oversight principles for AI, methodology for determining oversight requirements per AI system risk class, role-specific application (provider designs oversight measures, deployer implements oversight, internal-developer applies oversight to in-house AI), and policy review — is documented, communicated, and maintained
HUM.PO-01The human oversight policy — covering human oversight principles for AI, scope of application, and approval — is documented, communicated, and maintainedT 6 · C 6 · F 6
Applies To
Human oversight policy document
Oversight principles (meaningful human control, automation-bias mitigation, override availability)
Scope of application across AI roles (provider, deployer, internal developer)
Linkage with GOV.PO and TRU.PO
Approval authority
Oversight principles (meaningful human control, automation-bias mitigation, override availability)
Scope of application across AI roles (provider, deployer, internal developer)
Linkage with GOV.PO and TRU.PO
Approval authority
Control Details
The human oversight policy is documented as a formal artefact, approved at appropriate authority level
Oversight principles include meaningful human control, automation-bias mitigation, override availability, and proportionality of oversight to AI risk
Scope of application differentiates provider obligations (designing oversight measures into products per Art. 14), deployer obligations (operating oversight when consuming AI per Art. 14 / Art. 26(2)), and internal-developer obligations
Policy linkage with AI policy per GOV.PO-02 and trustworthy AI policy per TRU.PO maintains coherence
Policy is communicated to AI engineering, oversight personnel, AI governance forums per GOV.GF, and customer-facing teams
Oversight principles include meaningful human control, automation-bias mitigation, override availability, and proportionality of oversight to AI risk
Scope of application differentiates provider obligations (designing oversight measures into products per Art. 14), deployer obligations (operating oversight when consuming AI per Art. 14 / Art. 26(2)), and internal-developer obligations
Policy linkage with AI policy per GOV.PO-02 and trustworthy AI policy per TRU.PO maintains coherence
Policy is communicated to AI engineering, oversight personnel, AI governance forums per GOV.GF, and customer-facing teams
Control Mapping
ISO/IEC 42001:2023 — A.9; A.6.2
NIST AI RMF — MAP 3.5; GOVERN 1.2
EU AI Act — Art. 14; Art. 26(2)
OECD AI Principles (OECD/LEGAL/0449)
OWASP AISVS — C14 (Human Oversight)
NIST AI RMF — MAP 3.5; GOVERN 1.2
EU AI Act — Art. 14; Art. 26(2)
OECD AI Principles (OECD/LEGAL/0449)
OWASP AISVS — C14 (Human Oversight)
HUM.PO-02Methodology for determining oversight requirements per AI system risk class — covering oversight design considerations, requirement scaling, and documentation — is established and appliedT 6 · C 6 · F 6
Applies To
Methodology document for oversight requirement determination
Per-AI-system requirement assessment
Risk-class-based oversight scaling per CON.JU-02
Integration with design per LIF.DE-03
Methodology approval
Per-AI-system requirement assessment
Risk-class-based oversight scaling per CON.JU-02
Integration with design per LIF.DE-03
Methodology approval
Control Details
The methodology for determining oversight requirements is documented as a formal artefact
Per-AI-system requirement assessment evaluates intended use, affected parties per CON.IP-02, autonomy level per LIF.AG-01, and decision impact
Risk-class-based oversight scaling ensures higher-risk AI receives more rigorous oversight requirements
Methodology integration with design per LIF.DE-03 (safety-by-design and ethics-by-design) embeds oversight considerations from the start
Methodology is approved at appropriate authority level per HUM.PO-01
Methodology drives Controls in HUM.CO configuration design, HUM.IN intervention mechanisms, and HUM.CM competence
Per-AI-system requirement assessment evaluates intended use, affected parties per CON.IP-02, autonomy level per LIF.AG-01, and decision impact
Risk-class-based oversight scaling ensures higher-risk AI receives more rigorous oversight requirements
Methodology integration with design per LIF.DE-03 (safety-by-design and ethics-by-design) embeds oversight considerations from the start
Methodology is approved at appropriate authority level per HUM.PO-01
Methodology drives Controls in HUM.CO configuration design, HUM.IN intervention mechanisms, and HUM.CM competence
Control Mapping
ISO/IEC 42001:2023 — A.9; A.6.2.2
NIST AI RMF — MAP 3.5
EU AI Act — Art. 14(1); Art. 14(2); Art. 14(3)
OWASP AISVS — C14
NIST AI RMF — MAP 3.5
EU AI Act — Art. 14(1); Art. 14(2); Art. 14(3)
OWASP AISVS — C14
HUM.PO-03Human oversight policy and methodology review at defined cadence and on material changeT 6 · C 6 · F 6
Applies To
Review schedule (at minimum annually)
Material change triggers (regulatory developments, oversight effectiveness findings, AI incident learning)
Review participants
Approval of updates
Communication of changes
Material change triggers (regulatory developments, oversight effectiveness findings, AI incident learning)
Review participants
Approval of updates
Communication of changes
Control Details
Human oversight policy and methodology are reviewed at minimum annually
Ad-hoc review is triggered by material change (regulatory developments, oversight effectiveness findings per HUM.EF, AI incident learning per LIF.IR, material change to AI portfolio)
Review participants include AI safety, AI ethics per GOV.GF-03, AI engineering, AI governance forums per GOV.GF, and oversight personnel representatives
Updates are approved at appropriate authority level per HUM.PO-01
Updates are communicated to oversight personnel and integrated into LIF stage-gate criteria per LIF.PO-02
Version control is maintained
Ad-hoc review is triggered by material change (regulatory developments, oversight effectiveness findings per HUM.EF, AI incident learning per LIF.IR, material change to AI portfolio)
Review participants include AI safety, AI ethics per GOV.GF-03, AI engineering, AI governance forums per GOV.GF, and oversight personnel representatives
Updates are approved at appropriate authority level per HUM.PO-01
Updates are communicated to oversight personnel and integrated into LIF stage-gate criteria per LIF.PO-02
Version control is maintained
Control Mapping
ISO/IEC 42001:2023 — Cl. 9.3; Cl. 10
NIST AI RMF — GOVERN 1.5
EU AI Act — Art. 17(2)
NIST AI RMF — GOVERN 1.5
EU AI Act — Art. 17(2)
HUM.COHuman-AI Configuration4 Controls
Description: Human-AI configuration design — covering human-in-the-loop (HITL), human-on-the-loop (HOTL), and human-out-of-the-loop (HOOL) determination per AI use case, oversight placement across the AI workflow, agentic autonomy level decisions, decision-rights allocation between AI and human, and configuration documentation — is determined, applied, and maintained
HUM.CO-01Human-AI configuration determination per AI use case — HITL, HOTL, or HOOL — is performed and documentedT 6 · C 6 · F 6
Applies To
Configuration determination per AI use case (HITL, HOTL, HOOL)
Decision criteria (risk class, decision impact, affected parties, automation feasibility)
Documentation per AI system
Linkage with autonomy level per LIF.AG-01
Configuration review triggers
Decision criteria (risk class, decision impact, affected parties, automation feasibility)
Documentation per AI system
Linkage with autonomy level per LIF.AG-01
Configuration review triggers
Control Details
Human-AI configuration is determined per AI use case from three primary options — human-in-the-loop (HITL: human approves each AI action), human-on-the-loop (HOTL: human monitors and can intervene), human-out-of-the-loop (HOOL: AI operates autonomously with periodic review)
Decision criteria include AI risk class per CON.JU-02, decision impact on affected parties per IMP.IA, automation feasibility, and ethical considerations per GOV.ET
Documentation per AI system records the chosen configuration and rationale
Linkage with autonomy level per LIF.AG-01 ensures agentic systems have consistent autonomy specification
Configuration is reviewed when AI scope, risk class, or context materially changes
Decision criteria include AI risk class per CON.JU-02, decision impact on affected parties per IMP.IA, automation feasibility, and ethical considerations per GOV.ET
Documentation per AI system records the chosen configuration and rationale
Linkage with autonomy level per LIF.AG-01 ensures agentic systems have consistent autonomy specification
Configuration is reviewed when AI scope, risk class, or context materially changes
Control Mapping
ISO/IEC 42001:2023 — A.9
NIST AI RMF — MAP 3.5
EU AI Act — Art. 14(1); Art. 14(4)
NIST IR 8312 (Four Principles of Explainable AI)
OWASP AISVS — C14 (Human Oversight)
NIST AI RMF — MAP 3.5
EU AI Act — Art. 14(1); Art. 14(4)
NIST IR 8312 (Four Principles of Explainable AI)
OWASP AISVS — C14 (Human Oversight)
HUM.CO-02Oversight placement across the AI workflow — covering oversight insertion points, action and decision review, and downstream effect monitoring — is designedT 6 · C 6 · F 6
Applies To
Oversight insertion points across AI lifecycle (input review, output review, action review, outcome review)
Pre-action vs post-action oversight
Sampling vs comprehensive oversight
Downstream effect monitoring per IMP.MO-02
Per-AI workflow documentation
Pre-action vs post-action oversight
Sampling vs comprehensive oversight
Downstream effect monitoring per IMP.MO-02
Per-AI workflow documentation
Control Details
Oversight placement is designed per AI system to ensure oversight is inserted at points that materially affect outcomes
Pre-action oversight (HITL) intervenes before AI actions take effect; post-action oversight (HOTL) reviews after action with rollback capability per HUM.IN-04 where appropriate
Sampling vs comprehensive oversight is determined based on volume, risk, and oversight feasibility
Downstream effect monitoring per IMP.MO-02 ensures longer-horizon impacts are observable
Per-AI workflow documentation describes the oversight pattern, integrating with TRA.IU instructions for use where the company is a provider
Pre-action oversight (HITL) intervenes before AI actions take effect; post-action oversight (HOTL) reviews after action with rollback capability per HUM.IN-04 where appropriate
Sampling vs comprehensive oversight is determined based on volume, risk, and oversight feasibility
Downstream effect monitoring per IMP.MO-02 ensures longer-horizon impacts are observable
Per-AI workflow documentation describes the oversight pattern, integrating with TRA.IU instructions for use where the company is a provider
Control Mapping
ISO/IEC 42001:2023 — A.9; A.6.2.5
NIST AI RMF — MAP 3.5; MAP 3.4
EU AI Act — Art. 14(3); Art. 14(4)
OWASP AISVS — C14
OWASP Top 10 LLM (LLM06 Excessive Agency)
NIST AI RMF — MAP 3.5; MAP 3.4
EU AI Act — Art. 14(3); Art. 14(4)
OWASP AISVS — C14
OWASP Top 10 LLM (LLM06 Excessive Agency)
HUM.CO-03Agentic autonomy level decisions per agent system — covering autonomy tier assignment, escalation thresholds, and conditional autonomy — are made and documentedT 6 · C 6 · F 6
Applies To
Autonomy tier assignment per agent per LIF.AG-01
Escalation thresholds (when agent must defer to human)
Conditional autonomy (e.g., autonomous within bounds; HITL beyond)
Per-agent autonomy documentation
Linkage with multi-agent design per LIF.AG-03
Escalation thresholds (when agent must defer to human)
Conditional autonomy (e.g., autonomous within bounds; HITL beyond)
Per-agent autonomy documentation
Linkage with multi-agent design per LIF.AG-03
Control Details
Agentic autonomy level decisions are made per agent system in alignment with LIF.AG-01 authorisation scope
Autonomy tier assignment reflects HUM.CO-01 configuration but specialised for agentic action — autonomy may vary by action class within a single agent
Escalation thresholds define when an agent must defer (high-value actions, irreversible actions, novel situations)
Conditional autonomy allows autonomous action within defined bounds with HITL beyond bounds
Per-agent autonomy documentation feeds agentic system registry per CON.IN-03
Multi-agent design per LIF.AG-03 considers per-agent and system-level autonomy together
Autonomy tier assignment reflects HUM.CO-01 configuration but specialised for agentic action — autonomy may vary by action class within a single agent
Escalation thresholds define when an agent must defer (high-value actions, irreversible actions, novel situations)
Conditional autonomy allows autonomous action within defined bounds with HITL beyond bounds
Per-agent autonomy documentation feeds agentic system registry per CON.IN-03
Multi-agent design per LIF.AG-03 considers per-agent and system-level autonomy together
Control Mapping
ISO/IEC 42001:2023 — A.9
NIST AI RMF — MAP 3.5; MANAGE 2.4
EU AI Act — Art. 14
OWASP AISVS — C9 (Orchestration and Agentic Action); C14
OWASP Top 10 for Agentic Apps (ASI09 Human-Agent Trust Exploitation)
OWASP Multi-Agentic System Threat Modelling Guide
CSA Agentic AI Red Teaming Guide
NIST AI RMF — MAP 3.5; MANAGE 2.4
EU AI Act — Art. 14
OWASP AISVS — C9 (Orchestration and Agentic Action); C14
OWASP Top 10 for Agentic Apps (ASI09 Human-Agent Trust Exploitation)
OWASP Multi-Agentic System Threat Modelling Guide
CSA Agentic AI Red Teaming Guide
HUM.CO-04Decision-rights allocation between AI and human — covering decision authority by class, joint decisions, and AI advisory role definition — is established per AI systemT 6 · C 6 · F 6
Applies To
Decision authority by class (AI sole, AI advisory, human sole)
Joint decision protocols (where AI proposes, human approves)
AI advisory role definition (recommendation strength, dissent, abstention)
Decision audit trail
Linkage with GDPR Art. 22 and EU AI Act Art. 86
Joint decision protocols (where AI proposes, human approves)
AI advisory role definition (recommendation strength, dissent, abstention)
Decision audit trail
Linkage with GDPR Art. 22 and EU AI Act Art. 86
Control Details
Decision-rights allocation per AI system clarifies which decisions are made by AI alone, AI advisory with human decision, or human alone
Joint decision protocols define how AI proposes and human approves, including time-bounds for human review and default behaviour
AI advisory role definition specifies how AI surfaces recommendations (with confidence, alternatives, dissent capability)
Decision audit trail captures who decided and on what basis for material decisions
Linkage with GDPR Art. 22 (automated decision-making) per DAT.LB-03 and EU AI Act Art. 86 (right to explanation) per HUM.UA-02 ensures regulatory alignment
Joint decision protocols define how AI proposes and human approves, including time-bounds for human review and default behaviour
AI advisory role definition specifies how AI surfaces recommendations (with confidence, alternatives, dissent capability)
Decision audit trail captures who decided and on what basis for material decisions
Linkage with GDPR Art. 22 (automated decision-making) per DAT.LB-03 and EU AI Act Art. 86 (right to explanation) per HUM.UA-02 ensures regulatory alignment
Control Mapping
ISO/IEC 42001:2023 — A.9
NIST AI RMF — MAP 3.5; GOVERN 1.1
EU AI Act — Art. 14(4); Art. 26(11); Art. 86
GDPR — Art. 22
NIST IR 8312
OWASP AISVS — C14
NIST AI RMF — MAP 3.5; GOVERN 1.1
EU AI Act — Art. 14(4); Art. 26(11); Art. 86
GDPR — Art. 22
NIST IR 8312
OWASP AISVS — C14
HUM.INOverride and Intervention Mechanisms4 Controls
Description: Override and intervention mechanisms for AI — covering override capability per AI system, intervention pathways during AI operation, emergency stop and rollback mechanisms (including for agentic systems), override authority and authentication, override audit trails, and override exercise testing — are established, applied, and maintained
HUM.IN-01Override capability per AI system — covering override availability, override interfaces, and authorisation — is establishedT 6 · C 5 · F 6
Applies To
Override availability per AI system
Override interfaces (user-facing, operator-facing, administrator-facing)
Override authorisation requirements
Override scope (action-level, session-level, system-level)
Documentation in instructions for use per TRA.IU
Override interfaces (user-facing, operator-facing, administrator-facing)
Override authorisation requirements
Override scope (action-level, session-level, system-level)
Documentation in instructions for use per TRA.IU
Control Details
Override capability is provided per AI system at scale appropriate to risk class per CON.JU-02
Override interfaces address relevant audiences — user-facing override (e.g., reject AI suggestion), operator-facing override (e.g., disable automation for affected scope), administrator-facing override (e.g., system-wide override)
Override authorisation requirements scale with override impact — user-level overrides may be lightweight; system-wide overrides require elevated authority per GOV.RR-03
Override scope covers action-level (reject a single suggestion), session-level (disable AI for current session), and system-level (disable AI for all users)
Override capabilities are documented in instructions for use per TRA.IU-03 (provider) or operational documentation (deployer / internal)
Override interfaces address relevant audiences — user-facing override (e.g., reject AI suggestion), operator-facing override (e.g., disable automation for affected scope), administrator-facing override (e.g., system-wide override)
Override authorisation requirements scale with override impact — user-level overrides may be lightweight; system-wide overrides require elevated authority per GOV.RR-03
Override scope covers action-level (reject a single suggestion), session-level (disable AI for current session), and system-level (disable AI for all users)
Override capabilities are documented in instructions for use per TRA.IU-03 (provider) or operational documentation (deployer / internal)
Control Mapping
ISO/IEC 42001:2023 — A.9; A.6.2.5
NIST AI RMF — MAP 3.5; MANAGE 2.4
EU AI Act — Art. 14(4)(d); Art. 14(4)(e)
OWASP AISVS — C14 (Human Oversight)
OWASP Top 10 for Agentic Apps (ASI06 Memory and Context Poisoning; ASI09)
NIST AI RMF — MAP 3.5; MANAGE 2.4
EU AI Act — Art. 14(4)(d); Art. 14(4)(e)
OWASP AISVS — C14 (Human Oversight)
OWASP Top 10 for Agentic Apps (ASI06 Memory and Context Poisoning; ASI09)
HUM.IN-02Intervention pathways during AI operation — covering operator intervention channels, escalation routes, and intervention SLAs — are establishedT 6 · C 6 · F 6
Applies To
Operator intervention channels (alert, dashboard, intervention queue)
Escalation routes (operator to supervisor to incident response)
Intervention service-level expectations
Intervention triggers (anomaly, user request, threshold breach)
Linkage with LIF.OP operational monitoring
Escalation routes (operator to supervisor to incident response)
Intervention service-level expectations
Intervention triggers (anomaly, user request, threshold breach)
Linkage with LIF.OP operational monitoring
Control Details
Intervention pathways enable operators to act on AI behaviour during operation
Operator intervention channels include alerts, dashboards, and intervention queues that surface situations requiring human action
Escalation routes define when interventions escalate from operator to supervisor to incident response per LIF.IR
Intervention SLAs define expected response times by severity
Intervention triggers include anomaly detection per LIF.OP-03, user-initiated requests, output safety thresholds per LIF.OP-04, and explicit escalation from AI
Linkage with operational monitoring per LIF.OP ensures intervention paths are integrated into the operational picture
Operator intervention channels include alerts, dashboards, and intervention queues that surface situations requiring human action
Escalation routes define when interventions escalate from operator to supervisor to incident response per LIF.IR
Intervention SLAs define expected response times by severity
Intervention triggers include anomaly detection per LIF.OP-03, user-initiated requests, output safety thresholds per LIF.OP-04, and explicit escalation from AI
Linkage with operational monitoring per LIF.OP ensures intervention paths are integrated into the operational picture
Control Mapping
ISO/IEC 42001:2023 — A.9; A.6.2.6
NIST AI RMF — MANAGE 2.4; MANAGE 4.1
EU AI Act — Art. 14(4); Art. 26(5)
OWASP AISVS — C13 (Monitoring and Logging); C14
NIST AI RMF — MANAGE 2.4; MANAGE 4.1
EU AI Act — Art. 14(4); Art. 26(5)
OWASP AISVS — C13 (Monitoring and Logging); C14
HUM.IN-03Emergency stop and rollback mechanisms for AI systems including agentic systems — covering kill switches, rollback capability, and exercise — are establishedT 6 · C 6 · F 6
Applies To
Emergency stop capability per AI system
Rollback to previous version per LIF.VR-04
Agent emergency suspension per LIF.AG-05
Exercise of stop / rollback per defined cadence
Authorisation for emergency stop
Rollback to previous version per LIF.VR-04
Agent emergency suspension per LIF.AG-05
Exercise of stop / rollback per defined cadence
Authorisation for emergency stop
Control Details
Emergency stop and rollback mechanisms enable immediate cessation or reversion of AI operation in response to material issues
Emergency stop capability per AI system allows authorised operators to halt AI operation immediately
Rollback to previous version per LIF.VR-04 reverts deployments when current version is problematic
Agent emergency suspension per LIF.AG-05 specifically addresses agentic systems
Exercise of stop / rollback per defined cadence (at minimum quarterly drill for high-criticality AI) confirms capability and trains operators
Authorisation for emergency stop is documented; emergency authorisation paths exist where standard authority is unavailable
Emergency stop capability per AI system allows authorised operators to halt AI operation immediately
Rollback to previous version per LIF.VR-04 reverts deployments when current version is problematic
Agent emergency suspension per LIF.AG-05 specifically addresses agentic systems
Exercise of stop / rollback per defined cadence (at minimum quarterly drill for high-criticality AI) confirms capability and trains operators
Authorisation for emergency stop is documented; emergency authorisation paths exist where standard authority is unavailable
Control Mapping
ISO/IEC 42001:2023 — A.9; A.6.2.6
NIST AI RMF — MANAGE 2.4; MANAGE 2.3
EU AI Act — Art. 14(4)(e); Art. 15
OWASP AISVS — C14
OWASP Top 10 for Agentic Apps (ASI10 Rogue Agents)
CSA Agentic AI Red Teaming Guide
NIST AI RMF — MANAGE 2.4; MANAGE 2.3
EU AI Act — Art. 14(4)(e); Art. 15
OWASP AISVS — C14
OWASP Top 10 for Agentic Apps (ASI10 Rogue Agents)
CSA Agentic AI Red Teaming Guide
HUM.IN-04Override authority, authentication, and audit trails — covering authorisation, authentication, and complete audit logging — are establishedT 6 · C 6 · F 6
Applies To
Override authority per scope per GOV.RR-03
Authentication for override (per identity assurance level)
Override audit trails (who, when, what, why)
Audit trail integrity protection per ISMS
Reporting on override patterns
Authentication for override (per identity assurance level)
Override audit trails (who, when, what, why)
Audit trail integrity protection per ISMS
Reporting on override patterns
Control Details
Override authority follows GOV.RR-03 decision rights scaled to override scope
Authentication for override applies appropriate identity assurance — standard authentication for user-level overrides; elevated authentication (MFA, step-up) for system-wide or sensitive overrides
Override audit trails capture identity, timestamp, AI system, action overridden, scope, and justification
Audit trail integrity protection leverages ISMS Controls (tamper-resistant storage, restricted access, integrity monitoring)
Reporting on override patterns surfaces abuse, training needs, and AI design improvements; reporting feeds AIMS KPI / KRI per GOV.OV-01
Authentication for override applies appropriate identity assurance — standard authentication for user-level overrides; elevated authentication (MFA, step-up) for system-wide or sensitive overrides
Override audit trails capture identity, timestamp, AI system, action overridden, scope, and justification
Audit trail integrity protection leverages ISMS Controls (tamper-resistant storage, restricted access, integrity monitoring)
Reporting on override patterns surfaces abuse, training needs, and AI design improvements; reporting feeds AIMS KPI / KRI per GOV.OV-01
Control Mapping
ISO/IEC 42001:2023 — A.9; A.6.2.5
NIST AI RMF — MAP 3.5; MANAGE 2.4
EU AI Act — Art. 14(4); Art. 12
ISO/IEC 27001:2022 — A.5.15; A.8.5
OWASP AISVS — C5 (Access Control and Identity); C13 (Monitoring and Logging); C14
NIST AI RMF — MAP 3.5; MANAGE 2.4
EU AI Act — Art. 14(4); Art. 12
ISO/IEC 27001:2022 — A.5.15; A.8.5
OWASP AISVS — C5 (Access Control and Identity); C13 (Monitoring and Logging); C14
HUM.CMOversight Competence and AI Literacy for Overseers3 Controls
Description: Competence and AI literacy for oversight personnel — covering competence requirements per oversight role, AI literacy specific to overseen AI systems (per EU AI Act Art. 4 applied to overseers), oversight training programmes, competence assessment, and overseer awareness of system limitations — are established, maintained, and evaluated
HUM.CM-01Competence requirements per oversight role — covering competence framework alignment, role-specific competencies, and competence levels — are definedT 6 · C 6 · F 6
Applies To
Competence framework alignment with GOV.CO-01
Role-specific oversight competencies (general operator, specialised reviewer, supervisor, administrator)
Competence levels per role
Competence requirements documentation per AI system class
Cross-role consistency
Role-specific oversight competencies (general operator, specialised reviewer, supervisor, administrator)
Competence levels per role
Competence requirements documentation per AI system class
Cross-role consistency
Control Details
Competence requirements per oversight role are aligned with the AI competence framework per GOV.CO-01
Role-specific oversight competencies cover general operator (basic AI knowledge, intervention procedures), specialised reviewer (subject-matter expertise for review), supervisor (escalation handling, decision authority), administrator (system configuration and override authority)
Competence levels per role are defined with required knowledge, skills, and authority
Competence requirements per AI system class scale rigour to AI risk class per CON.JU-02
Cross-role consistency maintains coherent expectations across AI systems
Role-specific oversight competencies cover general operator (basic AI knowledge, intervention procedures), specialised reviewer (subject-matter expertise for review), supervisor (escalation handling, decision authority), administrator (system configuration and override authority)
Competence levels per role are defined with required knowledge, skills, and authority
Competence requirements per AI system class scale rigour to AI risk class per CON.JU-02
Cross-role consistency maintains coherent expectations across AI systems
Control Mapping
ISO/IEC 42001:2023 — A.4.6; A.9
NIST AI RMF — GOVERN 2.2; MAP 3.4
EU AI Act — Art. 4; Art. 14(4)(a)
OWASP AISVS — C14
NIST AI RMF — GOVERN 2.2; MAP 3.4
EU AI Act — Art. 4; Art. 14(4)(a)
OWASP AISVS — C14
HUM.CM-02AI literacy for overseers specific to overseen AI systems — covering system-specific training, model behaviour familiarity, and limitation awareness — is providedT 6 · C 6 · F 6
Applies To
System-specific training per overseen AI
Model behaviour familiarity
Limitation awareness (per TRU.AC, TRU.FA, TRU.RB, TRU.SA documented limitations)
Refresher training on material AI change
Linkage with EU AI Act Art. 4
Model behaviour familiarity
Limitation awareness (per TRU.AC, TRU.FA, TRU.RB, TRU.SA documented limitations)
Refresher training on material AI change
Linkage with EU AI Act Art. 4
Control Details
AI literacy for overseers is provided specific to the AI systems they oversee, extending the workforce-wide AI literacy per GOV.CO-02
System-specific training covers AI capability, intended use, known limitations, expected outputs, and oversight procedures
Model behaviour familiarity is built through practice with the AI under various scenarios
Limitation awareness covers documented limitations per TRU pillars and known failure modes per LIF.IR learning
Refresher training is provided on material AI change (version update, scope change, capability uplift)
Linkage with EU AI Act Art. 4 ensures regulatory AI literacy obligations are met for oversight personnel specifically
System-specific training covers AI capability, intended use, known limitations, expected outputs, and oversight procedures
Model behaviour familiarity is built through practice with the AI under various scenarios
Limitation awareness covers documented limitations per TRU pillars and known failure modes per LIF.IR learning
Refresher training is provided on material AI change (version update, scope change, capability uplift)
Linkage with EU AI Act Art. 4 ensures regulatory AI literacy obligations are met for oversight personnel specifically
Control Mapping
ISO/IEC 42001:2023 — A.4.6; A.9
NIST AI RMF — GOVERN 2.2; MAP 3.4
EU AI Act — Art. 4; Art. 14(4)(a); Art. 14(4)(b)
OWASP AISVS — C14
NIST AI RMF — GOVERN 2.2; MAP 3.4
EU AI Act — Art. 4; Art. 14(4)(a); Art. 14(4)(b)
OWASP AISVS — C14
HUM.CM-03Overseer competence assessment and awareness of system limitations — covering competence verification, ongoing assessment, and system-limitation awareness verification — are performedT 6 · C 6 · F 6
Applies To
Initial competence verification before oversight role assignment
Ongoing capability assessment
System-limitation awareness verification per AI system
Performance evaluation of overseers
Linkage with GOV.CO-04
Ongoing capability assessment
System-limitation awareness verification per AI system
Performance evaluation of overseers
Linkage with GOV.CO-04
Control Details
Overseer competence assessment is performed initially before oversight role assignment using methods per GOV.CO-04 adapted for oversight specifics
Ongoing capability assessment monitors overseer effectiveness — quality of overrides, calibration with AI quality, decision quality
System-limitation awareness verification ensures overseers understand the AI's limitations per TRU pillars
Performance evaluation of overseers feeds GOV.CO-04 reporting and identifies training needs
Linkage with GOV.CO-04 integrates oversight competence into broader AI competence management
Ongoing capability assessment monitors overseer effectiveness — quality of overrides, calibration with AI quality, decision quality
System-limitation awareness verification ensures overseers understand the AI's limitations per TRU pillars
Performance evaluation of overseers feeds GOV.CO-04 reporting and identifies training needs
Linkage with GOV.CO-04 integrates oversight competence into broader AI competence management
Control Mapping
ISO/IEC 42001:2023 — A.4.6; Cl. 9.1
NIST AI RMF — GOVERN 2.2; MAP 3.4
EU AI Act — Art. 4; Art. 14(4)(a)
OWASP AISVS — C14
NIST AI RMF — GOVERN 2.2; MAP 3.4
EU AI Act — Art. 4; Art. 14(4)(a)
OWASP AISVS — C14
HUM.EFOversight Effectiveness Measurement3 Controls
Description: Human oversight effectiveness measurement — covering effectiveness criteria per AI system, measurement of oversight outcomes (intervention rates, override exercise, error catch rates), oversight burden monitoring (alert fatigue, automation bias mitigation), and effectiveness reporting — is established, performed, and used to drive improvement
HUM.EF-01Oversight effectiveness criteria per AI system — covering effectiveness dimensions, criteria definition, and measurement plan — are establishedT 6 · C 7 · F 6
Applies To
Effectiveness dimensions (catch rate, false-positive rate, decision quality, response latency)
Criteria definition per AI system
Measurement plan including sampling and instrumentation
Linkage with TRU.PO-02 trustworthiness criteria
Criteria approval
Criteria definition per AI system
Measurement plan including sampling and instrumentation
Linkage with TRU.PO-02 trustworthiness criteria
Criteria approval
Control Details
Oversight effectiveness criteria are defined per AI system covering the dimensions that determine whether oversight is achieving its purpose
Effectiveness dimensions include error catch rate (how often oversight catches material AI errors), false-positive rate (how often oversight incorrectly intervenes), decision quality of overseer-aided outcomes vs AI-only outcomes, response latency
Criteria definition per AI system is documented in design per LIF.DE-03 and reflects AI risk class per CON.JU-02
Measurement plan includes sampling strategy, instrumentation requirements, and baseline establishment
Linkage with trustworthiness criteria per TRU.PO-02 maintains alignment
Criteria are approved per AI governance forums per GOV.GF
Effectiveness dimensions include error catch rate (how often oversight catches material AI errors), false-positive rate (how often oversight incorrectly intervenes), decision quality of overseer-aided outcomes vs AI-only outcomes, response latency
Criteria definition per AI system is documented in design per LIF.DE-03 and reflects AI risk class per CON.JU-02
Measurement plan includes sampling strategy, instrumentation requirements, and baseline establishment
Linkage with trustworthiness criteria per TRU.PO-02 maintains alignment
Criteria are approved per AI governance forums per GOV.GF
Control Mapping
ISO/IEC 42001:2023 — A.9; A.6.2.7
NIST AI RMF — MAP 3.4; MEASURE 4.1
EU AI Act — Art. 14(4); Art. 17(2)(g)
OWASP AISVS — C14
NIST AI RMF — MAP 3.4; MEASURE 4.1
EU AI Act — Art. 14(4); Art. 17(2)(g)
OWASP AISVS — C14
HUM.EF-02Measurement of oversight outcomes — covering intervention rates, override exercise, and error catch rates — is performed and reportedT 6 · C 6 · F 6
Applies To
Intervention rate measurement per AI system
Override exercise tracking
Error catch rate measurement
Decision quality comparison (overseer-assisted vs AI-alone where measurable)
Reporting cadence per AI criticality
Override exercise tracking
Error catch rate measurement
Decision quality comparison (overseer-assisted vs AI-alone where measurable)
Reporting cadence per AI criticality
Control Details
Measurement of oversight outcomes covers the effectiveness criteria per HUM.EF-01
Intervention rate measurement tracks how often human overseers intervene in AI operation
Override exercise tracking captures override events per HUM.IN-04 with outcomes
Error catch rate measures how often overseers catch AI errors that would otherwise have produced harm
Decision quality comparison (overseer-assisted vs AI-alone where measurable) surfaces whether oversight materially improves outcomes
Reporting cadence per AI criticality feeds AI governance forums per GOV.GF and AIMS KPI / KRI per GOV.OV-01
Intervention rate measurement tracks how often human overseers intervene in AI operation
Override exercise tracking captures override events per HUM.IN-04 with outcomes
Error catch rate measures how often overseers catch AI errors that would otherwise have produced harm
Decision quality comparison (overseer-assisted vs AI-alone where measurable) surfaces whether oversight materially improves outcomes
Reporting cadence per AI criticality feeds AI governance forums per GOV.GF and AIMS KPI / KRI per GOV.OV-01
Control Mapping
ISO/IEC 42001:2023 — A.9; Cl. 9.1
NIST AI RMF — MAP 3.4; MEASURE 4.3
EU AI Act — Art. 14(4); Art. 17(2)(g)
OWASP AISVS — C14
NIST AI RMF — MAP 3.4; MEASURE 4.3
EU AI Act — Art. 14(4); Art. 17(2)(g)
OWASP AISVS — C14
HUM.EF-03Oversight burden monitoring — covering alert fatigue, automation bias mitigation, and workload sustainability — is performedT 6 · C 6 · F 6
Applies To
Alert fatigue indicators (alert volume, dismissal rates, response latency drift)
Automation bias mitigation (procedures, training, design patterns)
Workload sustainability per overseer
Burnout indicators
Adjustments based on findings
Automation bias mitigation (procedures, training, design patterns)
Workload sustainability per overseer
Burnout indicators
Adjustments based on findings
Control Details
Oversight burden monitoring ensures oversight remains effective and sustainable for overseers
Alert fatigue indicators include alert volume per overseer, dismissal rates without action, and response latency drift over time
Automation bias mitigation includes procedures, training, and design patterns that counter overseers becoming over-reliant on AI suggestions (e.g., overseer reviews critical aspects before seeing AI suggestion; periodic confidence-calibration exercises)
Workload sustainability per overseer is monitored against established workload norms
Burnout indicators (response quality degradation, intervention rate drop without quality justification) trigger investigation
Adjustments based on findings include staffing changes, AI threshold tuning, configuration changes per HUM.CO
Alert fatigue indicators include alert volume per overseer, dismissal rates without action, and response latency drift over time
Automation bias mitigation includes procedures, training, and design patterns that counter overseers becoming over-reliant on AI suggestions (e.g., overseer reviews critical aspects before seeing AI suggestion; periodic confidence-calibration exercises)
Workload sustainability per overseer is monitored against established workload norms
Burnout indicators (response quality degradation, intervention rate drop without quality justification) trigger investigation
Adjustments based on findings include staffing changes, AI threshold tuning, configuration changes per HUM.CO
Control Mapping
ISO/IEC 42001:2023 — A.9; Cl. 9.1; A.4.6
NIST AI RMF — MAP 3.4; MEASURE 4.1
EU AI Act — Art. 14(4)(b)
NIST IR 8312
OWASP AISVS — C14
NIST AI RMF — MAP 3.4; MEASURE 4.1
EU AI Act — Art. 14(4)(b)
NIST IR 8312
OWASP AISVS — C14
HUM.UAUser Agency, Appeal, and Contestability4 Controls
Description: User agency, appeal, and contestability — covering user agency in AI-assisted decisions, right to explanation of AI decisions per EU AI Act Art. 86, contestation and appeal mechanisms for affected parties, redress and remediation pathways, and user-facing transparency on AI involvement — are established, communicated, and applied
HUM.UA-01User agency in AI-assisted decisions — covering meaningful choice, opt-out where applicable, and AI-decision transparency — is establishedT 6 · C 6 · F 6
Applies To
Meaningful choice in AI-assisted contexts
Opt-out availability where applicable (e.g., human review available)
AI-decision transparency to affected users
Default-state design (AI-on vs AI-off default)
Linkage with TRA.UD user-facing disclosure
Opt-out availability where applicable (e.g., human review available)
AI-decision transparency to affected users
Default-state design (AI-on vs AI-off default)
Linkage with TRA.UD user-facing disclosure
Control Details
User agency in AI-assisted decisions ensures affected users can meaningfully engage with AI involvement in decisions affecting them
Meaningful choice provides options where appropriate (e.g., AI-only fast path vs human-reviewed path; AI recommendation vs no AI suggestion)
Opt-out availability is provided where regulatory expectations or ethical considerations require (e.g., right to request human alternative)
AI-decision transparency to affected users surfaces that AI is involved and at what stage per Art. 50, Art. 26(11), and TRA.UD
Default-state design considers user empowerment vs friction; defaults are documented and reviewed
Linkage with TRA.UD-01 user-facing disclosure ensures regulatory transparency obligations are met
Meaningful choice provides options where appropriate (e.g., AI-only fast path vs human-reviewed path; AI recommendation vs no AI suggestion)
Opt-out availability is provided where regulatory expectations or ethical considerations require (e.g., right to request human alternative)
AI-decision transparency to affected users surfaces that AI is involved and at what stage per Art. 50, Art. 26(11), and TRA.UD
Default-state design considers user empowerment vs friction; defaults are documented and reviewed
Linkage with TRA.UD-01 user-facing disclosure ensures regulatory transparency obligations are met
Control Mapping
ISO/IEC 42001:2023 — A.9; A.8
NIST AI RMF — MAP 5.2; MEASURE 3.3
EU AI Act — Art. 14(4); Art. 26(11); Art. 50(1); Art. 86
OECD AI Principles (OECD/LEGAL/0449)
GDPR — Art. 22(3)
OWASP AISVS — C14
NIST AI RMF — MAP 5.2; MEASURE 3.3
EU AI Act — Art. 14(4); Art. 26(11); Art. 50(1); Art. 86
OECD AI Principles (OECD/LEGAL/0449)
GDPR — Art. 22(3)
OWASP AISVS — C14
HUM.UA-02Right to explanation of AI decisions per EU AI Act Art. 86 and GDPR Art. 22 — covering eligibility, request handling, and explanation delivery — is operationalisedT 6 · C 5 · F 6
Applies To
Eligibility determination per Art. 86 and Art. 22 scenarios
Request handling process
Explanation content production per TRU.EX-04
Response timeline per regulatory expectation
Linkage with TRU.EX explainability Controls
Request handling process
Explanation content production per TRU.EX-04
Response timeline per regulatory expectation
Linkage with TRU.EX explainability Controls
Control Details
Right to explanation is operationalised for AI decisions falling within EU AI Act Art. 86 scope and GDPR Art. 22 scope per DAT.LB-03 and CON.JU-04
Eligibility determination per request evaluates whether the AI decision triggers Art. 86 (high-risk AI decision producing legal or significant effects) or Art. 22 (decision based solely on automated processing) provisions
Request handling process covers request intake, identity verification, eligibility decision, explanation production, and delivery
Explanation content production leverages TRU.EX-04 user-facing explanation delivery; content includes the role of AI, the main parameters, and the consequences
Response timeline aligns with regulatory expectations and Art. 12 GDPR timeframes where applicable
Eligibility determination per request evaluates whether the AI decision triggers Art. 86 (high-risk AI decision producing legal or significant effects) or Art. 22 (decision based solely on automated processing) provisions
Request handling process covers request intake, identity verification, eligibility decision, explanation production, and delivery
Explanation content production leverages TRU.EX-04 user-facing explanation delivery; content includes the role of AI, the main parameters, and the consequences
Response timeline aligns with regulatory expectations and Art. 12 GDPR timeframes where applicable
Control Mapping
ISO/IEC 42001:2023 — A.9; A.8
NIST AI RMF — MEASURE 2.9; MEASURE 3.3
EU AI Act — Art. 86; Art. 26(11)
GDPR — Art. 12; Art. 13(2)(f); Art. 14(2)(g); Art. 15; Art. 22(3)
NIST IR 8312
OWASP AISVS — C14
NIST AI RMF — MEASURE 2.9; MEASURE 3.3
EU AI Act — Art. 86; Art. 26(11)
GDPR — Art. 12; Art. 13(2)(f); Art. 14(2)(g); Art. 15; Art. 22(3)
NIST IR 8312
OWASP AISVS — C14
HUM.UA-03Contestation and appeal mechanisms for affected parties — covering challenge channels, review process, decision overturn capability, and non-impedance of Art. 85 right to lodge complaints with market surveillance — are establishedT 6 · C 6 · F 6
Applies To
Challenge channels available to affected parties
Independent review process
Decision overturn capability (rollback, alternative outcome)
Linkage with DAT.LB-03 GDPR Art. 22(3) right to contest
Non-impedance of Art. 85 right to lodge complaints with the relevant market surveillance authority
Notification of contestation rights and Art. 85 right per TRA.UD
Independent review process
Decision overturn capability (rollback, alternative outcome)
Linkage with DAT.LB-03 GDPR Art. 22(3) right to contest
Non-impedance of Art. 85 right to lodge complaints with the relevant market surveillance authority
Notification of contestation rights and Art. 85 right per TRA.UD
Control Details
Contestation and appeal mechanisms enable affected parties to challenge AI-involved decisions affecting them
Challenge channels (web form, customer service, formal request) are provided and accessible
Independent review process per IMP.IR ensures challenges are reviewed by personnel not involved in the original AI decision
Decision overturn capability provides mechanism to reverse or replace AI decisions where challenge succeeds
Linkage with DAT.LB-03 GDPR Art. 22(3) right to contest ensures regulatory operationalisation
The Art. 85 right of natural persons to lodge complaints with the relevant market surveillance authority is not impeded; contestation processes do not condition use on waiving regulatory rights; awareness of the Art. 85 right is included in user-facing materials per TRA.UD-04 where appropriate
Notification of contestation rights and the Art. 85 complaint right is provided per TRA.UD and Art. 26(11) deployer disclosure
Challenge channels (web form, customer service, formal request) are provided and accessible
Independent review process per IMP.IR ensures challenges are reviewed by personnel not involved in the original AI decision
Decision overturn capability provides mechanism to reverse or replace AI decisions where challenge succeeds
Linkage with DAT.LB-03 GDPR Art. 22(3) right to contest ensures regulatory operationalisation
The Art. 85 right of natural persons to lodge complaints with the relevant market surveillance authority is not impeded; contestation processes do not condition use on waiving regulatory rights; awareness of the Art. 85 right is included in user-facing materials per TRA.UD-04 where appropriate
Notification of contestation rights and the Art. 85 complaint right is provided per TRA.UD and Art. 26(11) deployer disclosure
Control Mapping
ISO/IEC 42001:2023 — A.9; A.8
NIST AI RMF — MAP 5.2; MEASURE 3.3
EU AI Act — Art. 14(4)(d); Art. 26(11); Art. 85; Art. 86
OECD Due Diligence Guidance for Responsible AI
GDPR — Art. 22(3); Art. 77
Council of Europe Framework Convention on AI (2024)
OWASP AISVS — C14
NIST AI RMF — MAP 5.2; MEASURE 3.3
EU AI Act — Art. 14(4)(d); Art. 26(11); Art. 85; Art. 86
OECD Due Diligence Guidance for Responsible AI
GDPR — Art. 22(3); Art. 77
Council of Europe Framework Convention on AI (2024)
OWASP AISVS — C14
HUM.UA-04Redress and remediation pathways — covering harm redress, restorative actions, and systemic improvement — are establishedT 6 · C 5 · F 6
Applies To
Harm redress (compensation, correction, restoration) per harm type
Restorative actions where appropriate
Systemic improvement from redress patterns
Linkage with AI incident response per LIF.IR
Reporting per OECD Due Diligence Guidance
Restorative actions where appropriate
Systemic improvement from redress patterns
Linkage with AI incident response per LIF.IR
Reporting per OECD Due Diligence Guidance
Control Details
Redress and remediation pathways address harms arising from AI decisions and operation
Harm redress covers compensation for material harm, correction of incorrect decisions or records, and restoration where feasible
Restorative actions go beyond minimum redress where appropriate (apology, additional services, relationship restoration)
Systemic improvement from redress patterns identifies recurring issues feeding RSK risk management, TRU model improvement, and LIF.IR learning
Linkage with AI incident response per LIF.IR ensures material redress events trigger formal response
Reporting per OECD Due Diligence Guidance for Responsible AI supports broader accountability
Harm redress covers compensation for material harm, correction of incorrect decisions or records, and restoration where feasible
Restorative actions go beyond minimum redress where appropriate (apology, additional services, relationship restoration)
Systemic improvement from redress patterns identifies recurring issues feeding RSK risk management, TRU model improvement, and LIF.IR learning
Linkage with AI incident response per LIF.IR ensures material redress events trigger formal response
Reporting per OECD Due Diligence Guidance for Responsible AI supports broader accountability
Control Mapping
ISO/IEC 42001:2023 — A.9; Cl. 10
NIST AI RMF — MEASURE 3.3; MANAGE 4.3
EU AI Act — Art. 14(4); Art. 86; Art. 73
OECD Due Diligence Guidance for Responsible AI
GDPR — Art. 82
Council of Europe Framework Convention on AI (2024)
NIST AI RMF — MEASURE 3.3; MANAGE 4.3
EU AI Act — Art. 14(4); Art. 86; Art. 73
OECD Due Diligence Guidance for Responsible AI
GDPR — Art. 82
Council of Europe Framework Convention on AI (2024)
Transparency19 Controls · 7 Objectives
TRA.POTransparency Policy2 Controls
Description: The AI transparency policy — covering transparency principles for AI, scope of transparency obligations per role (provider transparency to deployers, deployer transparency to natural persons, internal-developer transparency to internal users), transparency artefacts catalogue, disclosure cadence, and policy review — is documented, communicated, and maintained
TRA.PO-01The AI transparency policy — covering transparency principles, role-based scope, transparency artefacts catalogue, and approval — is documented, communicated, and maintainedT 6 · C 6 · F 6
Applies To
Transparency policy document
Transparency principles (meaningful, accurate, accessible, timely)
Role-based scope (provider transparency to deployers, deployer transparency to natural persons, internal-developer transparency to internal users)
Transparency artefacts catalogue (technical documentation, model cards, instructions for use, logs, user-facing disclosure)
Approval authority
Transparency principles (meaningful, accurate, accessible, timely)
Role-based scope (provider transparency to deployers, deployer transparency to natural persons, internal-developer transparency to internal users)
Transparency artefacts catalogue (technical documentation, model cards, instructions for use, logs, user-facing disclosure)
Approval authority
Control Details
The AI transparency policy is documented as a formal artefact, approved at appropriate authority level
Transparency principles include meaningfulness, accuracy, accessibility to target audience, and timeliness of disclosure
Role-based scope differentiates obligations the company holds as provider, deployer, and internal developer
Transparency artefacts catalogue lists the artefacts the company produces and maintains (covered by TRA.TD, TRA.MC, TRA.IU, TRA.LR, TRA.UD, TRA.AG)
Policy is communicated to AI engineering, product, legal, marketing, and AI governance forums per GOV.GF
Linkage with AI policy per GOV.PO-02 and trustworthy AI policy per TRU.PO maintains coherence
Transparency principles include meaningfulness, accuracy, accessibility to target audience, and timeliness of disclosure
Role-based scope differentiates obligations the company holds as provider, deployer, and internal developer
Transparency artefacts catalogue lists the artefacts the company produces and maintains (covered by TRA.TD, TRA.MC, TRA.IU, TRA.LR, TRA.UD, TRA.AG)
Policy is communicated to AI engineering, product, legal, marketing, and AI governance forums per GOV.GF
Linkage with AI policy per GOV.PO-02 and trustworthy AI policy per TRU.PO maintains coherence
Control Mapping
ISO/IEC 42001:2023 — A.8; A.6.2.8
NIST AI RMF — GOVERN 1.2; MEASURE 2.8
EU AI Act — Art. 11; Art. 13; Art. 50; Art. 53
OECD AI Principles (OECD/LEGAL/0449) — Transparency and explainability
OWASP AISVS — C12 (Communication, Documentation and Disclosure)
NIST AI RMF — GOVERN 1.2; MEASURE 2.8
EU AI Act — Art. 11; Art. 13; Art. 50; Art. 53
OECD AI Principles (OECD/LEGAL/0449) — Transparency and explainability
OWASP AISVS — C12 (Communication, Documentation and Disclosure)
TRA.PO-02AI transparency policy review at defined cadence and on material changeT 6 · C 6 · F 6
Applies To
Review schedule (at minimum annually)
Material change triggers (regulatory developments, transparency feedback, AI portfolio changes)
Review participants
Approval of updates
Communication of changes
Material change triggers (regulatory developments, transparency feedback, AI portfolio changes)
Review participants
Approval of updates
Communication of changes
Control Details
The AI transparency policy is reviewed at minimum annually
Ad-hoc review is triggered by material change (regulatory developments — particularly EU AI Act delegated acts, harmonised standards, Commission guidance — transparency feedback from deployers or natural persons, material change to AI portfolio)
Review participants include AI legal, AI engineering, product, communications, and AI governance forums per GOV.GF
Updates are approved at appropriate authority level per TRA.PO-01
Updates are communicated to affected parties and integrated into LIF stage-gate criteria per LIF.PO-02
Version control is maintained
Ad-hoc review is triggered by material change (regulatory developments — particularly EU AI Act delegated acts, harmonised standards, Commission guidance — transparency feedback from deployers or natural persons, material change to AI portfolio)
Review participants include AI legal, AI engineering, product, communications, and AI governance forums per GOV.GF
Updates are approved at appropriate authority level per TRA.PO-01
Updates are communicated to affected parties and integrated into LIF stage-gate criteria per LIF.PO-02
Version control is maintained
Control Mapping
ISO/IEC 42001:2023 — Cl. 9.3; Cl. 10
NIST AI RMF — GOVERN 1.5
EU AI Act — Art. 17(2); Art. 96
OECD AI Principles (OECD/LEGAL/0449)
NIST AI RMF — GOVERN 1.5
EU AI Act — Art. 17(2); Art. 96
OECD AI Principles (OECD/LEGAL/0449)
TRA.TDTechnical Documentation3 Controls
Description: AI technical documentation — covering provider technical documentation (per EU AI Act Art. 11 and Annex IV elements applicable to in-scope AI), GPAI provider technical documentation per Art. 53 (model description, training data summary, copyright policy, computational resources, energy consumption), version-specific documentation, and documentation maintenance — is established, produced, and maintained
TRA.TD-01Provider technical documentation — covering content per EU AI Act Art. 11 and Annex IV applicable elements, draft–issue–maintain workflow, and pre-market readiness — is produced for in-scope AIT 6 · C 5 · F 6
Applies To
Per-AI technical documentation per Art. 11 / Annex IV applicable elements
Pre-market readiness for in-scope AI (high-risk where applicable; here scoped per CON.JU-02)
Draft–issue–maintain workflow
Storage and retrieval per Art. 18 record-keeping
Linkage with conformity assessment per IMP.GP
Pre-market readiness for in-scope AI (high-risk where applicable; here scoped per CON.JU-02)
Draft–issue–maintain workflow
Storage and retrieval per Art. 18 record-keeping
Linkage with conformity assessment per IMP.GP
Control Details
Provider technical documentation is produced per AI system that the company places on the market or puts into service
Content addresses applicable Annex IV elements (general description, components and integration, design specifications, monitoring and control, risk management, post-market monitoring system, conformity assessment, EU declaration)
Pre-market readiness is verified before placing on the market or putting into service
Draft–issue–maintain workflow assigns ownership, review, approval, and update obligations across the AI lifecycle
Storage and retrieval per Art. 18 ten-year record-keeping is maintained
Linkage with conformity assessment per IMP.GP ensures technical documentation supports conformity evidence
Content addresses applicable Annex IV elements (general description, components and integration, design specifications, monitoring and control, risk management, post-market monitoring system, conformity assessment, EU declaration)
Pre-market readiness is verified before placing on the market or putting into service
Draft–issue–maintain workflow assigns ownership, review, approval, and update obligations across the AI lifecycle
Storage and retrieval per Art. 18 ten-year record-keeping is maintained
Linkage with conformity assessment per IMP.GP ensures technical documentation supports conformity evidence
Control Mapping
ISO/IEC 42001:2023 — A.8; A.6.2.8
NIST AI RMF — MEASURE 2.8; GOVERN 1.4
EU AI Act — Art. 11; Annex IV; Art. 18
ISO/IEC 23894:2023 (TOC-only)
OWASP AISVS — C12 (Communication, Documentation and Disclosure)
NIST AI RMF — MEASURE 2.8; GOVERN 1.4
EU AI Act — Art. 11; Annex IV; Art. 18
ISO/IEC 23894:2023 (TOC-only)
OWASP AISVS — C12 (Communication, Documentation and Disclosure)
TRA.TD-02GPAI provider technical documentation per EU AI Act Art. 53 and Annex XI — covering model description, training process, training data summary, copyright policy, computational resources, and energy consumption — is produced and maintainedT 6 · C 6 · F 6
Applies To
GPAI model technical documentation per Annex XI
Training data summary template alignment (per Commission template once available)
Copyright policy per Art. 53(1)(c)
Computational resources and energy consumption disclosure
Updates on material change
Training data summary template alignment (per Commission template once available)
Copyright policy per Art. 53(1)(c)
Computational resources and energy consumption disclosure
Updates on material change
Control Details
GPAI provider technical documentation is produced per GPAI model the company places on the market
Annex XI content includes general description, design specifications, training data sources and curation, training process, computational resources used, known limitations, and (for GPAI with systemic risk) additional Annex XI Section 2 elements
Training data summary template alignment follows the Commission template per Art. 53(1)(d) once issued; current draft template is monitored
Copyright policy per Art. 53(1)(c) addresses Directive (EU) 2019/790 reservations including text-and-data mining opt-outs
Computational resources and energy consumption are documented per Annex XI Section 1 point 2(e)
Updates are issued on material change (new training run, fine-tuning, capability uplift)
Annex XI content includes general description, design specifications, training data sources and curation, training process, computational resources used, known limitations, and (for GPAI with systemic risk) additional Annex XI Section 2 elements
Training data summary template alignment follows the Commission template per Art. 53(1)(d) once issued; current draft template is monitored
Copyright policy per Art. 53(1)(c) addresses Directive (EU) 2019/790 reservations including text-and-data mining opt-outs
Computational resources and energy consumption are documented per Annex XI Section 1 point 2(e)
Updates are issued on material change (new training run, fine-tuning, capability uplift)
Control Mapping
ISO/IEC 42001:2023 — A.8
NIST AI RMF — MEASURE 2.8; GOVERN 1.4
EU AI Act — Art. 53(1)(a); Art. 53(1)(b); Art. 53(1)(c); Art. 53(1)(d); Annex XI
Directive (EU) 2019/790 (CDSM Directive) — Art. 4(3) opt-out
EU GPAI Code of Practice
NIST AI RMF — MEASURE 2.8; GOVERN 1.4
EU AI Act — Art. 53(1)(a); Art. 53(1)(b); Art. 53(1)(c); Art. 53(1)(d); Annex XI
Directive (EU) 2019/790 (CDSM Directive) — Art. 4(3) opt-out
EU GPAI Code of Practice
TRA.TD-03Version-specific technical documentation and maintenance — covering version identification, change capture, and currency — is operationalisedT 6 · C 6 · F 6
Applies To
Version identification per AI artefact aligned with LIF.VR
Change capture per material version
Currency review per cadence per Art. 11(3) update obligation
Archival of superseded versions
Linkage with model card per TRA.MC-01
Change capture per material version
Currency review per cadence per Art. 11(3) update obligation
Archival of superseded versions
Linkage with model card per TRA.MC-01
Control Details
Version-specific technical documentation is produced for each version of an AI system or GPAI model that materially changes
Version identification per AI artefact is aligned with version control per LIF.VR-01
Change capture per material version covers what changed, why, and impact on prior documented characteristics
Currency review per defined cadence ensures technical documentation remains current per Art. 11(3) obligation to update over the lifetime
Archival of superseded versions supports Art. 18 record-keeping and audit
Linkage with model card per TRA.MC-01 ensures version coherence between the two artefacts
Version identification per AI artefact is aligned with version control per LIF.VR-01
Change capture per material version covers what changed, why, and impact on prior documented characteristics
Currency review per defined cadence ensures technical documentation remains current per Art. 11(3) obligation to update over the lifetime
Archival of superseded versions supports Art. 18 record-keeping and audit
Linkage with model card per TRA.MC-01 ensures version coherence between the two artefacts
Control Mapping
ISO/IEC 42001:2023 — A.8; A.6.2.8
NIST AI RMF — MEASURE 2.8; GOVERN 1.5
EU AI Act — Art. 11(3); Art. 18
OWASP AISVS — C12
NIST AI RMF — MEASURE 2.8; GOVERN 1.5
EU AI Act — Art. 11(3); Art. 18
OWASP AISVS — C12
TRA.MCModel Cards and System Cards2 Controls
Description: Model cards and system cards — covering model card content (intended use, performance, limitations, training data summary, evaluation results), system card content (system architecture, AI components used, integration context), per-AI-artefact production, version-specific cards, and card publication and accessibility — are produced, maintained, and made accessible
TRA.MC-01Model card content per AI artefact — covering intended use, performance, limitations, training data summary, and evaluation results — is produced and made accessibleT 6 · C 6 · F 6
Applies To
Model card per AI artefact (foundation model, fine-tuned model, classifier, agent)
Intended use including in-scope and out-of-scope use cases
Performance characteristics per evaluation per TRU.AC-01 / TRU.RB-01 / TRU.FA-01 / TRU.SA-01
Limitations and known failure modes
Training data summary per TRA.TD-02 alignment
Intended use including in-scope and out-of-scope use cases
Performance characteristics per evaluation per TRU.AC-01 / TRU.RB-01 / TRU.FA-01 / TRU.SA-01
Limitations and known failure modes
Training data summary per TRA.TD-02 alignment
Control Details
Model card content is produced per AI artefact the company develops, fine-tunes, or substantially configures
Intended use describes in-scope and out-of-scope use cases per CON.IP
Performance characteristics include accuracy, robustness, fairness, and safety measurements per relevant TRU Controls
Limitations and known failure modes are documented including conditions under which performance degrades
Training data summary references TRA.TD-02 documentation (or equivalent for non-GPAI models)
Model cards align with model card / system card industry conventions and ISO/IEC 23894 risk profile linkage
Intended use describes in-scope and out-of-scope use cases per CON.IP
Performance characteristics include accuracy, robustness, fairness, and safety measurements per relevant TRU Controls
Limitations and known failure modes are documented including conditions under which performance degrades
Training data summary references TRA.TD-02 documentation (or equivalent for non-GPAI models)
Model cards align with model card / system card industry conventions and ISO/IEC 23894 risk profile linkage
Control Mapping
ISO/IEC 42001:2023 — A.6.2.8; A.8; A.8.2
NIST AI RMF — MEASURE 2.8; MAP 2.2
EU AI Act — Art. 13; Art. 53(1)(a); Annex IV
ISO/IEC 23894:2023 (TOC-only)
NIST IR 8312 (Four Principles of Explainable AI)
OWASP AISVS — C12 (Communication, Documentation and Disclosure)
NIST AI RMF — MEASURE 2.8; MAP 2.2
EU AI Act — Art. 13; Art. 53(1)(a); Annex IV
ISO/IEC 23894:2023 (TOC-only)
NIST IR 8312 (Four Principles of Explainable AI)
OWASP AISVS — C12 (Communication, Documentation and Disclosure)
TRA.MC-02System card production, version control, and accessibility — covering system architecture description, AI components used, integration context, and publication — are establishedT 6 · C 5 · F 6
Applies To
System card per AI system
System architecture description
AI components used per CON.IN-03
Integration context per CON.IP and CON.IE
Card publication and accessibility (internal, deployer, public per applicable disclosure scope)
System architecture description
AI components used per CON.IN-03
Integration context per CON.IP and CON.IE
Card publication and accessibility (internal, deployer, public per applicable disclosure scope)
Control Details
System card production captures the system-level view distinct from per-model model cards (TRA.MC-01)
System architecture description covers how AI components interact within the system and with non-AI components
AI components used reference per CON.IN-03 inventory linkage including third-party components per TPA
Integration context covers intended deployment environments, integration patterns, and known integration constraints
Card publication and accessibility align with applicable disclosure scope — internal (always), deployer (for provider products), public (for products where commitments or regulation support publication)
Version control aligns with LIF.VR-01
System architecture description covers how AI components interact within the system and with non-AI components
AI components used reference per CON.IN-03 inventory linkage including third-party components per TPA
Integration context covers intended deployment environments, integration patterns, and known integration constraints
Card publication and accessibility align with applicable disclosure scope — internal (always), deployer (for provider products), public (for products where commitments or regulation support publication)
Version control aligns with LIF.VR-01
Control Mapping
ISO/IEC 42001:2023 — A.8; A.6.2.8
NIST AI RMF — MEASURE 2.8; MAP 1.4
EU AI Act — Art. 13; Art. 11; Annex IV
OWASP AISVS — C12
OWASP Top 10 for Agentic Apps (ASI04 Agent Identification)
NIST AI RMF — MEASURE 2.8; MAP 1.4
EU AI Act — Art. 13; Art. 11; Annex IV
OWASP AISVS — C12
OWASP Top 10 for Agentic Apps (ASI04 Agent Identification)
TRA.IUInstructions for Use3 Controls
Description: Provider instructions for use — covering content per EU AI Act Art. 13 (identity, intended purpose, performance characteristics, foreseeable misuse, expected outputs, human oversight measures, computational resources, training data information), accessibility to deployers, language and format requirements, and updates with material change — are produced, issued, and maintained
TRA.IU-01Provider instructions for use content per EU AI Act Art. 13 — covering provider identity, intended purpose, performance characteristics, foreseeable misuse, expected outputs, human oversight measures, computational resources, and training data information — are producedT 6 · C 6 · F 6
Applies To
Instructions for use document per in-scope provider AI system per Art. 13
Content per Art. 13(3)(a)–(g) elements
Computational resources and expected operational characteristics
Training data information per Art. 13(3)(b)(vi)
Human oversight measures per HUM.CO and HUM.IN
Content per Art. 13(3)(a)–(g) elements
Computational resources and expected operational characteristics
Training data information per Art. 13(3)(b)(vi)
Human oversight measures per HUM.CO and HUM.IN
Control Details
Provider instructions for use are produced per in-scope provider AI system covering Art. 13(3) content
Identity of provider and authorised representative (where applicable) is recorded
Intended purpose, performance characteristics, foreseeable misuse, and expected outputs are stated per Art. 13(3)(b)
Human oversight measures per Art. 13(3)(d) link to TRA.IU-03 (operational oversight by deployer) and HUM.CO design
Computational resources and expected operational characteristics are stated per Art. 13(3)(b)(vi)–(vii)
Training data information appropriate for the use case per Art. 13(3)(b)(vi)
Identity of provider and authorised representative (where applicable) is recorded
Intended purpose, performance characteristics, foreseeable misuse, and expected outputs are stated per Art. 13(3)(b)
Human oversight measures per Art. 13(3)(d) link to TRA.IU-03 (operational oversight by deployer) and HUM.CO design
Computational resources and expected operational characteristics are stated per Art. 13(3)(b)(vi)–(vii)
Training data information appropriate for the use case per Art. 13(3)(b)(vi)
Control Mapping
ISO/IEC 42001:2023 — A.6.2.8; A.8; A.8.2
NIST AI RMF — MEASURE 2.8; MAP 3.4
EU AI Act — Art. 13(1); Art. 13(2); Art. 13(3)
OWASP AISVS — C12
NIST AI RMF — MEASURE 2.8; MAP 3.4
EU AI Act — Art. 13(1); Art. 13(2); Art. 13(3)
OWASP AISVS — C12
TRA.IU-02Instructions for use accessibility, language, and format — covering deployer accessibility, language requirements per Member State, and format suitability — are determinedT 6 · C 6 · F 6
Applies To
Deployer accessibility (digital and durable medium)
Language requirements per Member State of deployer establishment per Art. 13(1)
Format suitability (machine-readable as needed, structured for deployer integration)
Versioning and retrieval
Linkage with conformity per IMP.GP
Language requirements per Member State of deployer establishment per Art. 13(1)
Format suitability (machine-readable as needed, structured for deployer integration)
Versioning and retrieval
Linkage with conformity per IMP.GP
Control Details
Instructions for use are made accessible to deployers in a manner that enables their effective use
Language requirements per Member State of deployer establishment are met per Art. 13(1) — instructions are provided in the relevant Union language(s)
Format suitability covers human-readable form for deployer review and, where appropriate, machine-readable form for deployer integration
Versioning and retrieval ensure deployers can access the version applicable to their deployment
Linkage with conformity per IMP.GP ensures instructions for use are part of pre-market readiness
Language requirements per Member State of deployer establishment are met per Art. 13(1) — instructions are provided in the relevant Union language(s)
Format suitability covers human-readable form for deployer review and, where appropriate, machine-readable form for deployer integration
Versioning and retrieval ensure deployers can access the version applicable to their deployment
Linkage with conformity per IMP.GP ensures instructions for use are part of pre-market readiness
Control Mapping
ISO/IEC 42001:2023 — A.8; A.6.2.8
NIST AI RMF — MEASURE 2.8
EU AI Act — Art. 13(1); Art. 11; Annex IV
OWASP AISVS — C12
NIST AI RMF — MEASURE 2.8
EU AI Act — Art. 13(1); Art. 11; Annex IV
OWASP AISVS — C12
TRA.IU-03Instructions for use updates on material change and oversight-measure communication — covering update triggers, deployer notification, and version control — are operationalisedT 6 · C 6 · F 6
Applies To
Update triggers (material change, capability uplift, new known limitation)
Deployer notification mechanism
Oversight-measure communication per Art. 13(3)(d) and Art. 14
Version control aligned with TRA.MC and TRA.TD
Update audit trail
Deployer notification mechanism
Oversight-measure communication per Art. 13(3)(d) and Art. 14
Version control aligned with TRA.MC and TRA.TD
Update audit trail
Control Details
Instructions for use updates are issued when material change occurs in the AI system, its performance, its limitations, or its oversight requirements
Update triggers include material capability change, new known limitation per LIF.IR learning, change to expected outputs, and change to human oversight measures
Deployer notification mechanism ensures affected deployers receive timely notice of updates
Oversight-measure communication per Art. 13(3)(d) describes the human oversight measures designed into the AI (per HUM.CO) and what deployers must do operationally
Version control alignment with TRA.MC model card and TRA.TD technical documentation maintains coherence
Update audit trail supports Art. 11(3) maintenance evidence
Update triggers include material capability change, new known limitation per LIF.IR learning, change to expected outputs, and change to human oversight measures
Deployer notification mechanism ensures affected deployers receive timely notice of updates
Oversight-measure communication per Art. 13(3)(d) describes the human oversight measures designed into the AI (per HUM.CO) and what deployers must do operationally
Version control alignment with TRA.MC model card and TRA.TD technical documentation maintains coherence
Update audit trail supports Art. 11(3) maintenance evidence
Control Mapping
ISO/IEC 42001:2023 — A.8; A.6.2.8
NIST AI RMF — MEASURE 2.8; GOVERN 1.5
EU AI Act — Art. 11(3); Art. 13(3)(d); Art. 14
OWASP AISVS — C12; C14 (Human Oversight)
NIST AI RMF — MEASURE 2.8; GOVERN 1.5
EU AI Act — Art. 11(3); Art. 13(3)(d); Art. 14
OWASP AISVS — C12; C14 (Human Oversight)
TRA.LRRecord-Keeping and Logs3 Controls
Description: AI record-keeping and logs — covering provider record-keeping (per Art. 11 applicable elements), automatic AI system operational logs proportionate to use case, deployer use records per Art. 26(6), log retention per record class, log integrity protection, and log access governance — are established, maintained, and protected
TRA.LR-01Provider AI record-keeping per EU AI Act Art. 18 and cooperation with competent authorities per Art. 21 — covering record set, retention, retrieval, supervisory access, and authority response process — are establishedT 6 · C 6 · F 6
Applies To
Record set per Art. 18 (technical documentation, instructions for use, EU declaration, quality management documentation)
Ten-year retention from placing on the market or putting into service
Retrieval capability and indexing
Supervisory authority access per Art. 21 / Art. 70
Authority cooperation per Art. 21 — request response process, evidence access, timeliness, audit trail
AI Office cooperation per Art. 88 where the company is a GPAI provider
Linkage with TRA.TD and conformity per IMP.GP
Ten-year retention from placing on the market or putting into service
Retrieval capability and indexing
Supervisory authority access per Art. 21 / Art. 70
Authority cooperation per Art. 21 — request response process, evidence access, timeliness, audit trail
AI Office cooperation per Art. 88 where the company is a GPAI provider
Linkage with TRA.TD and conformity per IMP.GP
Control Details
Provider AI record-keeping is operationalised per Art. 18 for in-scope AI placed on the market or put into service
Record set covers technical documentation per Art. 11 (linked to TRA.TD-01), instructions for use per TRA.IU-01, EU declaration of conformity where applicable, and quality management system documentation per Art. 17 / GOV.PO
Retention period is ten years from the date the AI was placed on the market or put into service, or longer where Member State law requires
Retrieval capability supports access on request including by supervisory authorities per Art. 21 / Art. 70
Authority cooperation per Art. 21 is operationalised through a defined response process — request intake, ownership assignment, evidence access mechanism, response timeliness per regulatory expectation, and audit trail of authority interactions
AI Office cooperation per Art. 88 applies where the company is a GPAI provider — including requests under Art. 91 (information requests) and engagement on systemic-risk obligations
Linkage with TRA.TD and conformity per IMP.GP ensures record-keeping supports demonstrable conformity; linkage with LIF.IR-05 non-conformity duty per Art. 20 ensures coherent authority engagement
Record set covers technical documentation per Art. 11 (linked to TRA.TD-01), instructions for use per TRA.IU-01, EU declaration of conformity where applicable, and quality management system documentation per Art. 17 / GOV.PO
Retention period is ten years from the date the AI was placed on the market or put into service, or longer where Member State law requires
Retrieval capability supports access on request including by supervisory authorities per Art. 21 / Art. 70
Authority cooperation per Art. 21 is operationalised through a defined response process — request intake, ownership assignment, evidence access mechanism, response timeliness per regulatory expectation, and audit trail of authority interactions
AI Office cooperation per Art. 88 applies where the company is a GPAI provider — including requests under Art. 91 (information requests) and engagement on systemic-risk obligations
Linkage with TRA.TD and conformity per IMP.GP ensures record-keeping supports demonstrable conformity; linkage with LIF.IR-05 non-conformity duty per Art. 20 ensures coherent authority engagement
Control Mapping
ISO/IEC 42001:2023 — A.8; A.6.2.8
NIST AI RMF — GOVERN 1.4; MEASURE 3.1
EU AI Act — Art. 18; Art. 21; Art. 70; Art. 88; Art. 91; Art. 92; Art. 93; Art. 94
ISO/IEC 27001:2022 — A.5.33 (Protection of records)
OWASP AISVS — C13 (Monitoring and Logging)
NIST AI RMF — GOVERN 1.4; MEASURE 3.1
EU AI Act — Art. 18; Art. 21; Art. 70; Art. 88; Art. 91; Art. 92; Art. 93; Art. 94
ISO/IEC 27001:2022 — A.5.33 (Protection of records)
OWASP AISVS — C13 (Monitoring and Logging)
TRA.LR-02Automatic AI operational logging per Art. 12 and deployer use records per Art. 26(6) — covering log content design, proportionality to use case, and deployer log retention — are establishedT 6 · C 6 · F 6
Applies To
Automatic log design per Art. 12 for in-scope AI
Log content proportionate to use case (events, inputs at appropriate granularity, outputs, user identity where applicable)
Deployer use records per Art. 26(6) — six-month minimum or longer per Union law
Linkage with HUM intervention logging and TRA.AG agent traces
Privacy and data-protection alignment per DAT.PR
Log content proportionate to use case (events, inputs at appropriate granularity, outputs, user identity where applicable)
Deployer use records per Art. 26(6) — six-month minimum or longer per Union law
Linkage with HUM intervention logging and TRA.AG agent traces
Privacy and data-protection alignment per DAT.PR
Control Details
Automatic AI operational logging per Art. 12 is designed into in-scope AI systems
Log content is proportionate to use case — sufficient to enable monitoring of operation per Art. 26(5) and post-market monitoring per Art. 72 without unnecessary data collection
Deployer use records per Art. 26(6) are retained for at least six months unless Union or Member State law requires longer
Linkage with HUM.IN-04 override and intervention logging and TRA.AG agent traces ensures coherent log set
Privacy and data-protection alignment per DAT.PR ensures log content does not breach GDPR principles per Art. 5(1)(c) data minimisation
Log content is proportionate to use case — sufficient to enable monitoring of operation per Art. 26(5) and post-market monitoring per Art. 72 without unnecessary data collection
Deployer use records per Art. 26(6) are retained for at least six months unless Union or Member State law requires longer
Linkage with HUM.IN-04 override and intervention logging and TRA.AG agent traces ensures coherent log set
Privacy and data-protection alignment per DAT.PR ensures log content does not breach GDPR principles per Art. 5(1)(c) data minimisation
Control Mapping
ISO/IEC 42001:2023 — A.8; A.6.2.6
NIST AI RMF — MEASURE 3.1; GOVERN 1.4
EU AI Act — Art. 12; Art. 19; Art. 26(5); Art. 26(6); Art. 72
GDPR — Art. 5(1)(c); Art. 30
OWASP AISVS — C13 (Monitoring and Logging)
NIST AI RMF — MEASURE 3.1; GOVERN 1.4
EU AI Act — Art. 12; Art. 19; Art. 26(5); Art. 26(6); Art. 72
GDPR — Art. 5(1)(c); Art. 30
OWASP AISVS — C13 (Monitoring and Logging)
TRA.LR-03Log retention, integrity protection, and access governance — covering per-class retention, integrity controls, and access controls — are operationalisedT 6 · C 5 · F 6
Applies To
Per-class retention schedule (Art. 18 records, Art. 12 / Art. 26(6) operational logs, agent traces per TRA.AG)
Integrity protection (tamper-resistant storage, integrity monitoring)
Access controls per ISMS A.5.15 / A.8.5
Audit of log access
Retention disposal at end of retention
Integrity protection (tamper-resistant storage, integrity monitoring)
Access controls per ISMS A.5.15 / A.8.5
Audit of log access
Retention disposal at end of retention
Control Details
Per-class retention schedule documents the retention period applicable to each log class with regulatory and contractual references
Integrity protection (tamper-resistant storage, signing or hashing, immutable storage where appropriate, integrity monitoring) defends against modification per ISO/IEC 27001:2022 A.8.32 change management and A.5.33 record protection
Access controls per ISMS A.5.15 and A.8.5 restrict access on need-to-know basis with elevated authentication for sensitive log classes
Audit of log access detects misuse and supports incident investigation
Retention disposal at end of retention is performed in compliance with applicable laws and contracts
Integrity protection (tamper-resistant storage, signing or hashing, immutable storage where appropriate, integrity monitoring) defends against modification per ISO/IEC 27001:2022 A.8.32 change management and A.5.33 record protection
Access controls per ISMS A.5.15 and A.8.5 restrict access on need-to-know basis with elevated authentication for sensitive log classes
Audit of log access detects misuse and supports incident investigation
Retention disposal at end of retention is performed in compliance with applicable laws and contracts
Control Mapping
ISO/IEC 42001:2023 — A.8; A.6.2.6
NIST AI RMF — MEASURE 3.1; MEASURE 2.7
EU AI Act — Art. 12; Art. 18; Art. 26(6)
GDPR — Art. 5(1)(e); Art. 32
ISO/IEC 27001:2022 — A.5.15; A.5.33; A.8.5; A.8.34
OWASP AISVS — C13
NIST AI RMF — MEASURE 3.1; MEASURE 2.7
EU AI Act — Art. 12; Art. 18; Art. 26(6)
GDPR — Art. 5(1)(e); Art. 32
ISO/IEC 27001:2022 — A.5.15; A.5.33; A.8.5; A.8.34
OWASP AISVS — C13
TRA.UDUser-Facing Disclosure4 Controls
Description: AI user-facing disclosure — covering disclosure of AI interaction to natural persons per EU AI Act Art. 50(1), AI-generated content disclosure per Art. 50(2), deepfake disclosure per Art. 50(4), emotion-recognition and biometric-categorisation disclosure per Art. 50(3), deployer disclosure of automated decision-making per Art. 26(11), and disclosure form and accessibility — are determined, applied, and maintained
TRA.UD-01AI interaction disclosure to natural persons per EU AI Act Art. 50(1) — covering disclosure trigger, content, form, and timing — is operationalisedT 6 · C 5 · F 6
Applies To
Disclosure trigger (AI systems intended to interact directly with natural persons)
Disclosure content (clear, distinguishable that the person is interacting with an AI)
Form and timing (clearly perceivable, before or at start of interaction)
Per-AI applicability assessment
Exemption review (law enforcement; obvious-to-reasonable-person)
Disclosure content (clear, distinguishable that the person is interacting with an AI)
Form and timing (clearly perceivable, before or at start of interaction)
Per-AI applicability assessment
Exemption review (law enforcement; obvious-to-reasonable-person)
Control Details
AI interaction disclosure is operationalised per Art. 50(1) for AI systems the company provides or deploys that interact directly with natural persons
Disclosure trigger evaluation per AI system identifies whether Art. 50(1) applies
Disclosure content informs the natural person that they are interacting with an AI in a clear and distinguishable manner
Form and timing are clearly perceivable to the relevant audience and provided no later than the first interaction
Per-AI applicability assessment covers the company's products (provider) and AI consumed via deployment
Exemption review per Art. 50(1) (law enforcement under conditions; obvious from circumstances and context to a reasonably well-informed person) is documented per system
Disclosure trigger evaluation per AI system identifies whether Art. 50(1) applies
Disclosure content informs the natural person that they are interacting with an AI in a clear and distinguishable manner
Form and timing are clearly perceivable to the relevant audience and provided no later than the first interaction
Per-AI applicability assessment covers the company's products (provider) and AI consumed via deployment
Exemption review per Art. 50(1) (law enforcement under conditions; obvious from circumstances and context to a reasonably well-informed person) is documented per system
Control Mapping
ISO/IEC 42001:2023 — A.8; A.8.4; A.8.5
NIST AI RMF — MEASURE 2.8; MAP 5.2
EU AI Act — Art. 50(1)
OECD AI Principles (OECD/LEGAL/0449) — Transparency
GDPR — Art. 13; Art. 14
OWASP AISVS — C12 (Communication, Documentation and Disclosure)
NIST AI RMF — MEASURE 2.8; MAP 5.2
EU AI Act — Art. 50(1)
OECD AI Principles (OECD/LEGAL/0449) — Transparency
GDPR — Art. 13; Art. 14
OWASP AISVS — C12 (Communication, Documentation and Disclosure)
TRA.UD-02AI-generated content disclosure per Art. 50(2) and deepfake disclosure per Art. 50(4) — covering machine-readable marking, user-facing disclosure of deepfakes, and exemption handling — are operationalisedT 6 · C 6 · F 6
Applies To
Machine-readable marking of AI-generated synthetic content per Art. 50(2) (audio, image, video, text)
User-facing disclosure of deepfakes per Art. 50(4)
Exemption handling (artistic / creative work — labelling without obstructing the work; legally authorised content)
Per-AI applicability assessment
Linkage with provenance standards (e.g., C2PA)
User-facing disclosure of deepfakes per Art. 50(4)
Exemption handling (artistic / creative work — labelling without obstructing the work; legally authorised content)
Per-AI applicability assessment
Linkage with provenance standards (e.g., C2PA)
Control Details
AI-generated content marking is operationalised per Art. 50(2) for in-scope provider AI generating synthetic audio, image, video, or text
Machine-readable marking is implemented in a manner that is technically feasible and effective, interoperable, and robust to standard processing where state of the art allows (provenance / watermarking — e.g., C2PA where applicable)
User-facing disclosure of deepfakes per Art. 50(4) discloses that the content has been artificially generated or manipulated
Exemption handling addresses Art. 50(4) carve-outs (evidently artistic / creative / satirical work — disclosure in appropriate manner that does not hamper the work; legally authorised content for detection / investigation)
Per-AI applicability assessment covers provider products and deployer use
Linkage with provenance standards (e.g., C2PA) and harmonised standards is maintained as they evolve
Machine-readable marking is implemented in a manner that is technically feasible and effective, interoperable, and robust to standard processing where state of the art allows (provenance / watermarking — e.g., C2PA where applicable)
User-facing disclosure of deepfakes per Art. 50(4) discloses that the content has been artificially generated or manipulated
Exemption handling addresses Art. 50(4) carve-outs (evidently artistic / creative / satirical work — disclosure in appropriate manner that does not hamper the work; legally authorised content for detection / investigation)
Per-AI applicability assessment covers provider products and deployer use
Linkage with provenance standards (e.g., C2PA) and harmonised standards is maintained as they evolve
Control Mapping
ISO/IEC 42001:2023 — A.8; A.8.4
NIST AI RMF — MEASURE 2.8
EU AI Act — Art. 50(2); Art. 50(4); Art. 50(7)
OECD AI Principles (OECD/LEGAL/0449)
ISO/IEC 5339 (TOC-only — provenance discussion)
OWASP AISVS — C12; C8 (Model Behaviour, Output Control and Safety Alignment)
NIST AI RMF — MEASURE 2.8
EU AI Act — Art. 50(2); Art. 50(4); Art. 50(7)
OECD AI Principles (OECD/LEGAL/0449)
ISO/IEC 5339 (TOC-only — provenance discussion)
OWASP AISVS — C12; C8 (Model Behaviour, Output Control and Safety Alignment)
TRA.UD-03Emotion-recognition and biometric-categorisation disclosure per EU AI Act Art. 50(3) — covering applicability assessment, disclosure to exposed persons, and lawfulness coordination — is operationalisedT 6 · C 6 · F 6
Applies To
Applicability assessment per AI system (emotion recognition; biometric categorisation)
Disclosure to natural persons exposed to the system
Lawfulness coordination with DAT.LB and GDPR Art. 9
Exemption handling (law enforcement under conditions; biometric verification narrow exception)
Linkage with prohibited-practice screening per CON.JU-03
Disclosure to natural persons exposed to the system
Lawfulness coordination with DAT.LB and GDPR Art. 9
Exemption handling (law enforcement under conditions; biometric verification narrow exception)
Linkage with prohibited-practice screening per CON.JU-03
Control Details
Emotion-recognition and biometric-categorisation disclosure is operationalised per Art. 50(3) for in-scope AI
Applicability assessment per AI system evaluates whether the system constitutes emotion recognition or biometric categorisation under EU AI Act definitions
Disclosure to natural persons informs them of the operation of the system in a clear and distinguishable manner
Lawfulness coordination with DAT.LB and GDPR Art. 9 ensures special-category processing has a lawful basis where applicable
Exemption handling per Art. 50(3) (law enforcement under Article 6 / Article 5 conditions; certain biometric verification cases) is documented
Linkage with prohibited-practice screening per CON.JU-03 ensures Art. 5 prohibitions on emotion inference in workplace / education are not breached
Applicability assessment per AI system evaluates whether the system constitutes emotion recognition or biometric categorisation under EU AI Act definitions
Disclosure to natural persons informs them of the operation of the system in a clear and distinguishable manner
Lawfulness coordination with DAT.LB and GDPR Art. 9 ensures special-category processing has a lawful basis where applicable
Exemption handling per Art. 50(3) (law enforcement under Article 6 / Article 5 conditions; certain biometric verification cases) is documented
Linkage with prohibited-practice screening per CON.JU-03 ensures Art. 5 prohibitions on emotion inference in workplace / education are not breached
Control Mapping
ISO/IEC 42001:2023 — A.8; A.8.4
NIST AI RMF — MEASURE 2.8; GOVERN 1.1
EU AI Act — Art. 50(3); Art. 5(1)(f); Art. 5(1)(g)
GDPR — Art. 9; Art. 13; Art. 14
EDPB Guidelines on facial recognition
OWASP AISVS — C12
NIST AI RMF — MEASURE 2.8; GOVERN 1.1
EU AI Act — Art. 50(3); Art. 5(1)(f); Art. 5(1)(g)
GDPR — Art. 9; Art. 13; Art. 14
EDPB Guidelines on facial recognition
OWASP AISVS — C12
TRA.UD-04Deployer disclosure of automated decision-making per Art. 26(11) and form and accessibility of user-facing disclosure — covering scope, content, and accessibility — are operationalisedT 6 · C 6 · F 6
Applies To
Deployer scope (high-risk AI used to make or assist decisions concerning natural persons)
Disclosure content (informed of subjection to high-risk AI use)
Linkage with GDPR Art. 13 / Art. 14 / Art. 22 information obligations per DAT.LB-03
Linkage with right to explanation per Art. 86 and HUM.UA-02
Form and accessibility (clear language, appropriate channel)
Disclosure content (informed of subjection to high-risk AI use)
Linkage with GDPR Art. 13 / Art. 14 / Art. 22 information obligations per DAT.LB-03
Linkage with right to explanation per Art. 86 and HUM.UA-02
Form and accessibility (clear language, appropriate channel)
Control Details
Deployer disclosure of automated decision-making per Art. 26(11) is operationalised where the company deploys high-risk AI making or assisting decisions concerning natural persons
Disclosure content informs natural persons that they are subject to the use of the high-risk AI system
Linkage with GDPR Art. 13 / Art. 14 / Art. 22 information obligations per DAT.LB-03 ensures coherent user-facing notice
Linkage with right to explanation per Art. 86 and HUM.UA-02 ensures downstream contestability is supported
Form and accessibility include clear language and appropriate channel (privacy notice, in-product notice, at decision point as appropriate)
Disclosure content informs natural persons that they are subject to the use of the high-risk AI system
Linkage with GDPR Art. 13 / Art. 14 / Art. 22 information obligations per DAT.LB-03 ensures coherent user-facing notice
Linkage with right to explanation per Art. 86 and HUM.UA-02 ensures downstream contestability is supported
Form and accessibility include clear language and appropriate channel (privacy notice, in-product notice, at decision point as appropriate)
Control Mapping
ISO/IEC 42001:2023 — A.8; A.8.4; A.10.4
NIST AI RMF — MEASURE 2.8; GOVERN 1.1
EU AI Act — Art. 26(11); Art. 86
OECD AI Principles (OECD/LEGAL/0449)
GDPR — Art. 12; Art. 13; Art. 14; Art. 22
OWASP AISVS — C12; C14 (Human Oversight)
NIST AI RMF — MEASURE 2.8; GOVERN 1.1
EU AI Act — Art. 26(11); Art. 86
OECD AI Principles (OECD/LEGAL/0449)
GDPR — Art. 12; Art. 13; Art. 14; Art. 22
OWASP AISVS — C12; C14 (Human Oversight)
TRA.AGAgentic Action Logs and Decision Traces2 Controls
Description: Agentic AI action logs and decision traces — covering action-granular logging for agentic systems, decision trace capture (planning, tool calls, agent-to-agent communication, outputs), trace retention per system, trace integrity protection, trace access for review, and trace use in incident response and oversight — are established, captured, and maintained
TRA.AG-01Action-granular logging for agentic systems and decision trace capture — covering action logs, planning and tool-call traces, agent-to-agent communication, and outputs — are establishedT 6 · C 6 · F 6
Applies To
Action-granular logs per agent action
Planning trace capture (high-level plan, sub-task decomposition)
Tool-call trace capture (tool identity, parameters, results)
Agent-to-agent communication capture per LIF.AG-03
Output capture and association with agent identity per CSA AICM / OWASP ASI04
Planning trace capture (high-level plan, sub-task decomposition)
Tool-call trace capture (tool identity, parameters, results)
Agent-to-agent communication capture per LIF.AG-03
Output capture and association with agent identity per CSA AICM / OWASP ASI04
Control Details
Action-granular logging is implemented per agentic system per LIF.AG-01 / HUM.CO-03
Action logs capture per-action identity (agent identity per OWASP ASI04), timestamp, action class, target, outcome
Planning trace capture records the high-level plan and sub-task decomposition where the agentic system makes plans visible
Tool-call trace capture records tool identity, parameters issued, and results received
Agent-to-agent communication capture per LIF.AG-03 records inter-agent messages where multi-agent orchestration is in use
Output capture and association with agent identity supports accountability per CSA AICM and OWASP ASI04
Action logs capture per-action identity (agent identity per OWASP ASI04), timestamp, action class, target, outcome
Planning trace capture records the high-level plan and sub-task decomposition where the agentic system makes plans visible
Tool-call trace capture records tool identity, parameters issued, and results received
Agent-to-agent communication capture per LIF.AG-03 records inter-agent messages where multi-agent orchestration is in use
Output capture and association with agent identity supports accountability per CSA AICM and OWASP ASI04
Control Mapping
ISO/IEC 42001:2023 — A.6.2.6; A.6.2.7
NIST AI RMF — MEASURE 3.1; MEASURE 2.7
EU AI Act — Art. 12; Art. 26(5); Art. 26(6)
OWASP AISVS — C9 (Orchestration and Agentic Action); C13 (Monitoring and Logging)
OWASP Top 10 for Agentic Apps (ASI04 Agent Identification; ASI06 Memory and Context Poisoning; ASI09 Human-Agent Trust Exploitation)
OWASP Multi-Agentic System Threat Modelling Guide
CSA Agentic AI Identity and Access Management
NIST AI RMF — MEASURE 3.1; MEASURE 2.7
EU AI Act — Art. 12; Art. 26(5); Art. 26(6)
OWASP AISVS — C9 (Orchestration and Agentic Action); C13 (Monitoring and Logging)
OWASP Top 10 for Agentic Apps (ASI04 Agent Identification; ASI06 Memory and Context Poisoning; ASI09 Human-Agent Trust Exploitation)
OWASP Multi-Agentic System Threat Modelling Guide
CSA Agentic AI Identity and Access Management
TRA.AG-02Agentic trace retention, integrity protection, and use in oversight and incident response — covering retention, integrity, replay support, and access governance — are operationalisedT 7 · C 6 · F 6
Applies To
Trace retention per system per regulatory and operational needs
Trace integrity protection (tamper-resistant storage, signing)
Replay support for oversight per HUM.IN-04 and incident investigation per LIF.IR
Access controls per ISMS A.5.15 / A.8.5
Privacy alignment per DAT.PR
Trace integrity protection (tamper-resistant storage, signing)
Replay support for oversight per HUM.IN-04 and incident investigation per LIF.IR
Access controls per ISMS A.5.15 / A.8.5
Privacy alignment per DAT.PR
Control Details
Agentic trace retention is determined per agentic system covering regulatory expectations (Art. 12 / Art. 26(6) where applicable) and operational needs (oversight, incident investigation, post-market monitoring)
Trace integrity protection (tamper-resistant storage, signing or hashing, immutable storage where appropriate) defends against modification
Replay support enables oversight personnel and incident responders to reconstruct agent behaviour for review and root-cause analysis per HUM.IN-04 and LIF.IR
Access controls per ISMS A.5.15 / A.8.5 restrict access on need-to-know basis with elevated authentication for high-impact agents
Privacy alignment per DAT.PR ensures trace content respects GDPR data minimisation and storage limitation principles
Trace integrity protection (tamper-resistant storage, signing or hashing, immutable storage where appropriate) defends against modification
Replay support enables oversight personnel and incident responders to reconstruct agent behaviour for review and root-cause analysis per HUM.IN-04 and LIF.IR
Access controls per ISMS A.5.15 / A.8.5 restrict access on need-to-know basis with elevated authentication for high-impact agents
Privacy alignment per DAT.PR ensures trace content respects GDPR data minimisation and storage limitation principles
Control Mapping
ISO/IEC 42001:2023 — A.6.2.6; A.6.2.7
NIST AI RMF — MEASURE 3.1; MEASURE 2.7
EU AI Act — Art. 12; Art. 18; Art. 26(6); Art. 72
GDPR — Art. 5(1)(c); Art. 5(1)(e); Art. 32
ISO/IEC 27001:2022 — A.5.15; A.5.33; A.8.5; A.8.34
OWASP AISVS — C9; C13
OWASP Top 10 for Agentic Apps (ASI04; ASI06)
CSA Agentic AI Red Teaming Guide
NIST AI RMF — MEASURE 3.1; MEASURE 2.7
EU AI Act — Art. 12; Art. 18; Art. 26(6); Art. 72
GDPR — Art. 5(1)(c); Art. 5(1)(e); Art. 32
ISO/IEC 27001:2022 — A.5.15; A.5.33; A.8.5; A.8.34
OWASP AISVS — C9; C13
OWASP Top 10 for Agentic Apps (ASI04; ASI06)
CSA Agentic AI Red Teaming Guide
Third-Party26 Controls · 7 Objectives
TPA.POThird-Party AI Policy2 Controls
Description: The third-party AI policy — covering principles for third-party AI consumption and provision, role-specific scope (upstream supply chain when consuming, downstream provision when providing), policy alignment with vendor management and procurement, and policy review — is documented, communicated, and maintained
TPA.PO-01The third-party AI policy — covering principles for upstream and downstream AI relationships, role-specific scope, alignment with vendor management and procurement, and approval — is documented, communicated, and maintainedT 6 · C 6 · F 6
Applies To
Third-party AI policy document
Principles (risk-proportionate due diligence, contractual coverage, ongoing monitoring, exit readiness)
Role-specific scope (upstream supply chain when consuming AI; downstream provision when providing AI)
Alignment with ISMS vendor management (ISO 27001 A.5.19–A.5.22) and procurement
Approval authority
Principles (risk-proportionate due diligence, contractual coverage, ongoing monitoring, exit readiness)
Role-specific scope (upstream supply chain when consuming AI; downstream provision when providing AI)
Alignment with ISMS vendor management (ISO 27001 A.5.19–A.5.22) and procurement
Approval authority
Control Details
The third-party AI policy is documented as a formal artefact, approved at appropriate authority level
Principles include risk-proportionate due diligence, contractual coverage of AI-specific issues, ongoing supplier monitoring, and exit readiness
Role-specific scope covers upstream (the company consuming foundation models, AI APIs, third-party services) and downstream (the company providing AI products to deployers and customers per CON.JU-01)
Alignment with ISMS vendor management Controls per ISO/IEC 27001:2022 A.5.19–A.5.22 ensures non-duplicative coverage with the underlying supplier security regime
Linkage with AI policy per GOV.PO-02 and trustworthy AI policy per TRU.PO maintains coherence
Policy is communicated to procurement, AI engineering, AI governance forums per GOV.GF, legal, and finance
Principles include risk-proportionate due diligence, contractual coverage of AI-specific issues, ongoing supplier monitoring, and exit readiness
Role-specific scope covers upstream (the company consuming foundation models, AI APIs, third-party services) and downstream (the company providing AI products to deployers and customers per CON.JU-01)
Alignment with ISMS vendor management Controls per ISO/IEC 27001:2022 A.5.19–A.5.22 ensures non-duplicative coverage with the underlying supplier security regime
Linkage with AI policy per GOV.PO-02 and trustworthy AI policy per TRU.PO maintains coherence
Policy is communicated to procurement, AI engineering, AI governance forums per GOV.GF, legal, and finance
Control Mapping
ISO/IEC 42001:2023 — A.10
NIST AI RMF — GOVERN 6.1
EU AI Act — Art. 25; Art. 53; Art. 26
OECD AI Principles (OECD/LEGAL/0449)
ISO/IEC 27001:2022 — A.5.19; A.5.20; A.5.21; A.5.22
NIST SP 800-161r1 (C-SCRM)
OWASP AISVS — C10 (Supply Chain Security)
NIST AI RMF — GOVERN 6.1
EU AI Act — Art. 25; Art. 53; Art. 26
OECD AI Principles (OECD/LEGAL/0449)
ISO/IEC 27001:2022 — A.5.19; A.5.20; A.5.21; A.5.22
NIST SP 800-161r1 (C-SCRM)
OWASP AISVS — C10 (Supply Chain Security)
TPA.PO-02Third-party AI policy review at defined cadence and on material changeT 6 · C 6 · F 6
Applies To
Review schedule (at minimum annually)
Material change triggers (regulatory developments, supplier incidents, AI portfolio changes)
Review participants
Approval of updates
Communication of changes
Material change triggers (regulatory developments, supplier incidents, AI portfolio changes)
Review participants
Approval of updates
Communication of changes
Control Details
Third-party AI policy is reviewed at minimum annually
Ad-hoc review is triggered by material change (regulatory developments — including EU AI Act delegated acts and harmonised standards — material supplier incident affecting the company, GPAI Code of Practice updates, material change to AI portfolio or vendor mix)
Review participants include procurement, AI legal, AI security, AI engineering, AI governance forums per GOV.GF
Updates are approved at appropriate authority level per TPA.PO-01
Updates are communicated to procurement and engineering teams; integrated into LIF stage-gate criteria per LIF.PO-02 and procurement workflows
Version control is maintained
Ad-hoc review is triggered by material change (regulatory developments — including EU AI Act delegated acts and harmonised standards — material supplier incident affecting the company, GPAI Code of Practice updates, material change to AI portfolio or vendor mix)
Review participants include procurement, AI legal, AI security, AI engineering, AI governance forums per GOV.GF
Updates are approved at appropriate authority level per TPA.PO-01
Updates are communicated to procurement and engineering teams; integrated into LIF stage-gate criteria per LIF.PO-02 and procurement workflows
Version control is maintained
Control Mapping
ISO/IEC 42001:2023 — Cl. 9.3; Cl. 10
NIST AI RMF — GOVERN 1.5
EU AI Act — Art. 17(2); Art. 96
ISO/IEC 27001:2022 — Cl. 9.3
NIST AI RMF — GOVERN 1.5
EU AI Act — Art. 17(2); Art. 96
ISO/IEC 27001:2022 — Cl. 9.3
TPA.DDAI Vendor Due Diligence4 Controls
Description: AI vendor due diligence — covering due diligence criteria per AI vendor class (foundation model providers, AI API and service vendors, fine-tuning relationships, model marketplaces), due diligence per AI risk class, supplier AI conformity and security verification, and ongoing supplier monitoring and due diligence renewal — is performed, documented, and maintained
TPA.DD-01AI vendor due diligence criteria per vendor class — covering foundation model providers, AI API and service vendors, fine-tuning relationships, and model marketplaces — are established and appliedT 7 · C 6 · F 6
Applies To
Per-class criteria (foundation model providers; AI API and service vendors; fine-tuning relationships; model marketplaces / hubs)
Criteria coverage (governance, security, data handling, conformity, transparency, ethics, legal posture)
Per-class evaluation procedure
Documentation of due-diligence outcome
Linkage with AII inventory and CON.IN-03
Criteria coverage (governance, security, data handling, conformity, transparency, ethics, legal posture)
Per-class evaluation procedure
Documentation of due-diligence outcome
Linkage with AII inventory and CON.IN-03
Control Details
AI vendor due diligence criteria are established per vendor class and applied prior to engagement
Per-class criteria differentiate foundation model providers (covering model governance, training data provenance, evaluation results, safety alignment, alignment with EU AI Act Art. 53 obligations), AI API and service vendors (security posture, SLAs, data handling, model versioning), fine-tuning relationships (training data handling, IP, downstream support), and model marketplaces / hubs (model provenance, signing, vetting)
Criteria coverage spans the AIT scope: governance, security, data handling, conformity, transparency, ethics, social commitments, and legal / regulatory history per memory feedback
Per-class evaluation procedure assigns evaluator competence, evidence requirements, and approval authority
Documentation of due-diligence outcome feeds vendor records and AII inventory per CON.IN-03
Per-class criteria differentiate foundation model providers (covering model governance, training data provenance, evaluation results, safety alignment, alignment with EU AI Act Art. 53 obligations), AI API and service vendors (security posture, SLAs, data handling, model versioning), fine-tuning relationships (training data handling, IP, downstream support), and model marketplaces / hubs (model provenance, signing, vetting)
Criteria coverage spans the AIT scope: governance, security, data handling, conformity, transparency, ethics, social commitments, and legal / regulatory history per memory feedback
Per-class evaluation procedure assigns evaluator competence, evidence requirements, and approval authority
Documentation of due-diligence outcome feeds vendor records and AII inventory per CON.IN-03
Control Mapping
ISO/IEC 42001:2023 — A.10; A.10.2
NIST AI RMF — GOVERN 6.1; MANAGE 3.1
EU AI Act — Art. 25; Art. 26
ISO/IEC 5338:2023 — Cl. 6.1.1
ISO/IEC 27001:2022 — A.5.19; A.5.20; A.5.21
NIST SP 800-161r1 (C-SCRM)
OWASP AISVS — C10 (Supply Chain Security); C2 (Model Lifecycle Management)
NIST AI RMF — GOVERN 6.1; MANAGE 3.1
EU AI Act — Art. 25; Art. 26
ISO/IEC 5338:2023 — Cl. 6.1.1
ISO/IEC 27001:2022 — A.5.19; A.5.20; A.5.21
NIST SP 800-161r1 (C-SCRM)
OWASP AISVS — C10 (Supply Chain Security); C2 (Model Lifecycle Management)
TPA.DD-02Due diligence depth scaled by AI risk class — covering risk-classification linkage, scaled rigour, and approval authority — is operationalisedT 7 · C 6 · F 6
Applies To
Risk-classification linkage per CON.JU-02
Scaled rigour (light, standard, deep)
Approval authority per rigour level per GOV.RR-03
Documentation of risk-class determination
Re-evaluation triggers
Scaled rigour (light, standard, deep)
Approval authority per rigour level per GOV.RR-03
Documentation of risk-class determination
Re-evaluation triggers
Control Details
Due diligence depth is scaled by the AI risk class of the use case the vendor will support per CON.JU-02
Risk-classification linkage ensures vendor due diligence rigour is proportionate to AI risk
Scaled rigour defines light (low-risk use cases — basic supplier evaluation), standard (limited or higher risk), and deep (high-impact or systemic-risk use cases — including independent assurance review, on-site assessment, or attested evaluation results)
Approval authority per rigour level follows GOV.RR-03 decision rights — deep due-diligence outcomes require elevated approval
Documentation of risk-class determination and resulting due-diligence depth is retained per record-keeping
Re-evaluation triggers include scope change, incident, or risk-class change
Risk-classification linkage ensures vendor due diligence rigour is proportionate to AI risk
Scaled rigour defines light (low-risk use cases — basic supplier evaluation), standard (limited or higher risk), and deep (high-impact or systemic-risk use cases — including independent assurance review, on-site assessment, or attested evaluation results)
Approval authority per rigour level follows GOV.RR-03 decision rights — deep due-diligence outcomes require elevated approval
Documentation of risk-class determination and resulting due-diligence depth is retained per record-keeping
Re-evaluation triggers include scope change, incident, or risk-class change
Control Mapping
ISO/IEC 42001:2023 — A.10; A.10.2
NIST AI RMF — GOVERN 6.1; MAP 4.2
EU AI Act — Art. 25; Art. 27
ISO/IEC 5338:2023 — Cl. 6.1.1
ISO/IEC 27001:2022 — A.5.19
NIST SP 800-161r1
NIST AI RMF — GOVERN 6.1; MAP 4.2
EU AI Act — Art. 25; Art. 27
ISO/IEC 5338:2023 — Cl. 6.1.1
ISO/IEC 27001:2022 — A.5.19
NIST SP 800-161r1
TPA.DD-03Supplier AI conformity, security, and ethical-posture verification — covering conformity evidence, security evidence, ethics and social commitments, and legal-regulatory history — is performedT 6 · C 6 · F 6
Applies To
Conformity evidence (where applicable per CON.JU-02 / Art. 25 / Art. 53 obligations)
Security evidence (ISO 27001 certification, SOC 2, AI-specific security attestations)
Ethics and social commitments per AIT scope (responsible AI policies, public commitments, codes adhered to)
Legal and regulatory history per AIT scope (enforcement actions, material litigation, regulatory findings)
Evidence retention and refresh
Security evidence (ISO 27001 certification, SOC 2, AI-specific security attestations)
Ethics and social commitments per AIT scope (responsible AI policies, public commitments, codes adhered to)
Legal and regulatory history per AIT scope (enforcement actions, material litigation, regulatory findings)
Evidence retention and refresh
Control Details
Supplier AI conformity, security, and ethical-posture verification is performed per due-diligence depth per TPA.DD-02
Conformity evidence is reviewed for applicability — EU AI Act Art. 25 (provider obligations along the supply chain), Art. 53 (GPAI provider obligations), GPAI Code of Practice adherence where relevant
Security evidence (ISO/IEC 27001:2022 certification, SOC 2 Type 2, ISO/IEC 27017 cloud, ISO/IEC 27018 PII processor) is reviewed against ISMS A.5.19–A.5.22 expectations
Ethics and social commitments per AIT scope cover responsible AI policies, public commitments (e.g., AISIC / Voluntary Commitments adherence), codes adhered to
Legal and regulatory history per AIT scope covers enforcement actions, material AI-related litigation, and regulatory findings
Evidence retention and refresh aligns with vendor management cadence
Conformity evidence is reviewed for applicability — EU AI Act Art. 25 (provider obligations along the supply chain), Art. 53 (GPAI provider obligations), GPAI Code of Practice adherence where relevant
Security evidence (ISO/IEC 27001:2022 certification, SOC 2 Type 2, ISO/IEC 27017 cloud, ISO/IEC 27018 PII processor) is reviewed against ISMS A.5.19–A.5.22 expectations
Ethics and social commitments per AIT scope cover responsible AI policies, public commitments (e.g., AISIC / Voluntary Commitments adherence), codes adhered to
Legal and regulatory history per AIT scope covers enforcement actions, material AI-related litigation, and regulatory findings
Evidence retention and refresh aligns with vendor management cadence
Control Mapping
ISO/IEC 42001:2023 — A.10; A.10.2
NIST AI RMF — GOVERN 6.1; MAP 4.2
EU AI Act — Art. 25; Art. 53; Art. 56 (GPAI Code of Practice)
ENISA Multilayer Framework for Good Cybersecurity Practices for AI
EU GPAI Code of Practice
ISO/IEC 5338:2023 — Cl. 6.1.1
ISO/IEC 27001:2022 — A.5.19; A.5.20; A.5.21
ISO/IEC 27017:2015; ISO/IEC 27018:2019
OWASP AISVS — C10
NIST AI RMF — GOVERN 6.1; MAP 4.2
EU AI Act — Art. 25; Art. 53; Art. 56 (GPAI Code of Practice)
ENISA Multilayer Framework for Good Cybersecurity Practices for AI
EU GPAI Code of Practice
ISO/IEC 5338:2023 — Cl. 6.1.1
ISO/IEC 27001:2022 — A.5.19; A.5.20; A.5.21
ISO/IEC 27017:2015; ISO/IEC 27018:2019
OWASP AISVS — C10
TPA.DD-04Ongoing supplier monitoring and due-diligence renewal — covering monitoring sources, change triggers, renewal cadence, and offboarding — are establishedT 6 · C 6 · F 6
Applies To
Monitoring sources (supplier disclosures, incident notifications per contract, regulatory enforcement, public reporting)
Change triggers (material AI capability change, regulatory action, ownership change, security incident, public ethics issue)
Renewal cadence per risk class per TPA.DD-02
Offboarding triggers and procedure
Linkage with vendor risk register
Change triggers (material AI capability change, regulatory action, ownership change, security incident, public ethics issue)
Renewal cadence per risk class per TPA.DD-02
Offboarding triggers and procedure
Linkage with vendor risk register
Control Details
Ongoing supplier monitoring tracks supplier posture across the relationship
Monitoring sources include supplier disclosures, contractual incident notifications per TPA.CT, regulatory enforcement records, and public reporting
Change triggers include material AI capability change, regulatory action against the supplier, ownership change, security incident affecting the company's data or operations, and public ethics or legal issue per AIT scope
Renewal cadence per risk class — deep due-diligence vendors renewed at minimum annually; standard biennially; light per defined cycle
Offboarding triggers (supplier failure to meet obligations; risk-class change; strategic exit) lead to formal offboarding procedure including data return and destruction
Linkage with vendor risk register supports continuous risk visibility
Monitoring sources include supplier disclosures, contractual incident notifications per TPA.CT, regulatory enforcement records, and public reporting
Change triggers include material AI capability change, regulatory action against the supplier, ownership change, security incident affecting the company's data or operations, and public ethics or legal issue per AIT scope
Renewal cadence per risk class — deep due-diligence vendors renewed at minimum annually; standard biennially; light per defined cycle
Offboarding triggers (supplier failure to meet obligations; risk-class change; strategic exit) lead to formal offboarding procedure including data return and destruction
Linkage with vendor risk register supports continuous risk visibility
Control Mapping
ISO/IEC 42001:2023 — A.10; A.10.3
NIST AI RMF — GOVERN 6.1; MANAGE 3.1
EU AI Act — Art. 25; Art. 72 (post-market monitoring)
ISO/IEC 5338:2023 — Cl. 6.1.1
ISO/IEC 27001:2022 — A.5.22
NIST SP 800-161r1
NIST AI RMF — GOVERN 6.1; MANAGE 3.1
EU AI Act — Art. 25; Art. 72 (post-market monitoring)
ISO/IEC 5338:2023 — Cl. 6.1.1
ISO/IEC 27001:2022 — A.5.22
NIST SP 800-161r1
TPA.CTAI Contractual and Shared Responsibility5 Controls
Description: AI contractual provisions and shared responsibility — covering contractual provisions for AI vendors (data handling, performance, liability, breach notification, audit rights, exit), shared responsibility model definition per vendor relationship (per CoSAI framework), AI-specific contractual terms (training data use, model improvement, downstream use, IP), and contract management — are established, applied, and maintained
TPA.CT-01AI vendor contractual provisions — covering data handling, performance, liability, breach notification, audit rights, and exit — are establishedT 6 · C 6 · F 6
Applies To
Data-handling provisions (input data, output data, model improvement use, retention, location)
Performance provisions (SLA, availability, error rates, throughput)
Liability provisions (cap, exclusions, IP indemnity)
Breach notification provisions (timing, content, channel)
Audit rights and assurance reporting
Exit provisions (data return, destruction, transition support)
Performance provisions (SLA, availability, error rates, throughput)
Liability provisions (cap, exclusions, IP indemnity)
Breach notification provisions (timing, content, channel)
Audit rights and assurance reporting
Exit provisions (data return, destruction, transition support)
Control Details
AI vendor contractual provisions are established for all AI vendors covering the contracting baseline
Data-handling provisions cover input data classification per DAT.IN-02, output data ownership, whether the vendor may use customer data for model improvement (default: no), retention, and processing location
Performance provisions establish SLA, availability targets, error-rate expectations, and throughput where applicable
Liability provisions cover cap, exclusions, IP indemnity for AI outputs, and AI-specific liability under EU AI Liability Directive proposal and Product Liability Directive (Directive (EU) 2024/2853)
Breach notification provisions specify timing (e.g., 24-72h for security incidents), content, and channel
Audit rights cover assurance reporting (e.g., SOC 2, ISO 27001 attestation) and on-site / independent assessment for higher-risk relationships
Exit provisions cover data return formats, destruction certification, and transition support
Data-handling provisions cover input data classification per DAT.IN-02, output data ownership, whether the vendor may use customer data for model improvement (default: no), retention, and processing location
Performance provisions establish SLA, availability targets, error-rate expectations, and throughput where applicable
Liability provisions cover cap, exclusions, IP indemnity for AI outputs, and AI-specific liability under EU AI Liability Directive proposal and Product Liability Directive (Directive (EU) 2024/2853)
Breach notification provisions specify timing (e.g., 24-72h for security incidents), content, and channel
Audit rights cover assurance reporting (e.g., SOC 2, ISO 27001 attestation) and on-site / independent assessment for higher-risk relationships
Exit provisions cover data return formats, destruction certification, and transition support
Control Mapping
ISO/IEC 42001:2023 — A.10; A.10.3
NIST AI RMF — GOVERN 6.1; MANAGE 3.1
EU AI Act — Art. 25; Art. 26; Art. 53
Directive (EU) 2024/2853 (Product Liability Directive)
ISO/IEC 5338:2023 — Cl. 6.1.1
ISO/IEC 27001:2022 — A.5.20; A.5.22
NIST SP 800-161r1
OWASP AISVS — C10
NIST AI RMF — GOVERN 6.1; MANAGE 3.1
EU AI Act — Art. 25; Art. 26; Art. 53
Directive (EU) 2024/2853 (Product Liability Directive)
ISO/IEC 5338:2023 — Cl. 6.1.1
ISO/IEC 27001:2022 — A.5.20; A.5.22
NIST SP 800-161r1
OWASP AISVS — C10
TPA.CT-02Shared responsibility model definition per AI vendor relationship — covering responsibility allocation, RACI per AI control area, and gap closure — is establishedT 6 · C 6 · F 6
Applies To
Shared responsibility per relationship type (foundation model API; managed AI service; AI infrastructure)
RACI per AI control area (data handling, model governance, security, monitoring, incident response, transparency artefacts)
Gap closure (Controls the company must operate to close shared-responsibility gaps)
Alignment with CoSAI Secure AI Framework where applicable
Documentation per relationship
RACI per AI control area (data handling, model governance, security, monitoring, incident response, transparency artefacts)
Gap closure (Controls the company must operate to close shared-responsibility gaps)
Alignment with CoSAI Secure AI Framework where applicable
Documentation per relationship
Control Details
Shared responsibility model is defined per AI vendor relationship
Responsibility allocation per relationship type clarifies what the vendor operates vs what the company operates — analogous to cloud shared-responsibility model, applied to AI control areas
RACI per AI control area covers data handling, model governance, security, monitoring, incident response, transparency artefacts, and regulatory compliance
Gap closure identifies Controls the company must operate to close shared-responsibility gaps and maps them to relevant AIMS Controls (e.g., DAT, LIF.OP, LIF.IR)
Alignment with CoSAI Secure AI Framework where applicable provides a reference model for shared-responsibility decomposition
Documentation per relationship is reviewed at renewal per TPA.DD-04
Responsibility allocation per relationship type clarifies what the vendor operates vs what the company operates — analogous to cloud shared-responsibility model, applied to AI control areas
RACI per AI control area covers data handling, model governance, security, monitoring, incident response, transparency artefacts, and regulatory compliance
Gap closure identifies Controls the company must operate to close shared-responsibility gaps and maps them to relevant AIMS Controls (e.g., DAT, LIF.OP, LIF.IR)
Alignment with CoSAI Secure AI Framework where applicable provides a reference model for shared-responsibility decomposition
Documentation per relationship is reviewed at renewal per TPA.DD-04
Control Mapping
ISO/IEC 42001:2023 — A.10; A.10.3
NIST AI RMF — GOVERN 6.1; GOVERN 2.1
EU AI Act — Art. 25
ISO/IEC 27001:2022 — A.5.19; A.5.21
OWASP AISVS — C10
CoSAI Secure AI Framework (Coalition for Secure AI)
NIST AI RMF — GOVERN 6.1; GOVERN 2.1
EU AI Act — Art. 25
ISO/IEC 27001:2022 — A.5.19; A.5.21
OWASP AISVS — C10
CoSAI Secure AI Framework (Coalition for Secure AI)
TPA.CT-03AI-specific contractual terms — covering training data use, model improvement, downstream use, and intellectual property — are establishedT 6 · C 6 · F 6
Applies To
Training data use provisions (whether customer data may train shared models)
Model improvement provisions (whether the vendor may improve models using customer data; opt-out)
Downstream use provisions (constraints on the vendor's use of outputs; downstream provider obligations per Art. 25)
IP provisions (input ownership, output ownership, model ownership, retained-rights carve-outs)
Indemnity for IP infringement claims arising from outputs
Model improvement provisions (whether the vendor may improve models using customer data; opt-out)
Downstream use provisions (constraints on the vendor's use of outputs; downstream provider obligations per Art. 25)
IP provisions (input ownership, output ownership, model ownership, retained-rights carve-outs)
Indemnity for IP infringement claims arising from outputs
Control Details
AI-specific contractual terms are established for AI vendor relationships
Training data use provisions specify whether customer data (inputs, outputs, fine-tuning data) may train shared models — default position is no, with explicit opt-in only where business case warrants
Model improvement provisions clarify whether and how the vendor may improve models using customer data, with opt-out / opt-in mechanism per regulatory expectation
Downstream use provisions address obligations under Art. 25 supply-chain provisions when the company is downstream provider; provider obligations under Art. 25(4) flow down where applicable
IP provisions cover input ownership (customer), output ownership (customer or as agreed), model ownership (vendor), and retained-rights carve-outs
Indemnity for IP infringement claims arising from outputs is sought where vendor offers it (e.g., Anthropic, major hyperscalers)
Training data use provisions specify whether customer data (inputs, outputs, fine-tuning data) may train shared models — default position is no, with explicit opt-in only where business case warrants
Model improvement provisions clarify whether and how the vendor may improve models using customer data, with opt-out / opt-in mechanism per regulatory expectation
Downstream use provisions address obligations under Art. 25 supply-chain provisions when the company is downstream provider; provider obligations under Art. 25(4) flow down where applicable
IP provisions cover input ownership (customer), output ownership (customer or as agreed), model ownership (vendor), and retained-rights carve-outs
Indemnity for IP infringement claims arising from outputs is sought where vendor offers it (e.g., Anthropic, major hyperscalers)
Control Mapping
ISO/IEC 42001:2023 — A.10; A.10.3
NIST AI RMF — GOVERN 6.1
EU AI Act — Art. 25; Art. 53(1)(c)
GDPR — Art. 28
Directive (EU) 2019/790 (CDSM Directive) — Art. 4(3)
ISO/IEC 27001:2022 — A.5.20
NIST AI RMF — GOVERN 6.1
EU AI Act — Art. 25; Art. 53(1)(c)
GDPR — Art. 28
Directive (EU) 2019/790 (CDSM Directive) — Art. 4(3)
ISO/IEC 27001:2022 — A.5.20
TPA.CT-04Contract management — covering contract repository, renewal cycle, change management, and obligation tracking — is operationalisedT 6 · C 6 · F 6
Applies To
Contract repository per ISMS A.5.20
Renewal cycle aligned with TPA.DD-04 due-diligence renewal
Change management for material vendor changes
Obligation tracking (provider and company obligations)
Linkage with vendor risk register
Renewal cycle aligned with TPA.DD-04 due-diligence renewal
Change management for material vendor changes
Obligation tracking (provider and company obligations)
Linkage with vendor risk register
Control Details
Contract management operationalises the contracting baseline across the vendor portfolio
Contract repository per ISMS A.5.20 maintains contract record with metadata (vendor, term, renewal date, AI risk class, criticality)
Renewal cycle is aligned with TPA.DD-04 due-diligence renewal — renewal triggers due-diligence refresh
Change management for material vendor changes (acquisition, service change, T&C change) triggers contract review
Obligation tracking captures provider obligations to the company and company obligations to provider; obligation breaches trigger escalation
Linkage with vendor risk register supports continuous visibility
Contract repository per ISMS A.5.20 maintains contract record with metadata (vendor, term, renewal date, AI risk class, criticality)
Renewal cycle is aligned with TPA.DD-04 due-diligence renewal — renewal triggers due-diligence refresh
Change management for material vendor changes (acquisition, service change, T&C change) triggers contract review
Obligation tracking captures provider obligations to the company and company obligations to provider; obligation breaches trigger escalation
Linkage with vendor risk register supports continuous visibility
Control Mapping
ISO/IEC 42001:2023 — A.10; A.10.3
NIST AI RMF — GOVERN 6.1; GOVERN 1.5
EU AI Act — Art. 25
ISO/IEC 27001:2022 — A.5.20; A.5.22
NIST AI RMF — GOVERN 6.1; GOVERN 1.5
EU AI Act — Art. 25
ISO/IEC 27001:2022 — A.5.20; A.5.22
TPA.CT-05GDPR controller / processor / joint controllership analysis per AI vendor relationship — covering role determination, joint controllership arrangements, allocation of data subject rights handling, and sub-processor cascades — is established and maintainedT 7 · C 7 · F 6
Applies To
Per-vendor role determination (controller, processor, joint controller, separate controllers)
Joint controllership arrangements per Art. 26 where applicable
Essence of joint controller arrangement made available to data subjects per Art. 26(2)
Allocation of GDPR obligations (information provision per Art. 13/14, rights handling per Art. 15–22, breach response per Art. 33/34, supervisory authority cooperation per Art. 31)
Sub-processor cascades and Art. 28(2) authorisation
Linkage with TPA.CT-01 contractual provisions and TPA.CT-03 AI-specific terms
Joint controllership arrangements per Art. 26 where applicable
Essence of joint controller arrangement made available to data subjects per Art. 26(2)
Allocation of GDPR obligations (information provision per Art. 13/14, rights handling per Art. 15–22, breach response per Art. 33/34, supervisory authority cooperation per Art. 31)
Sub-processor cascades and Art. 28(2) authorisation
Linkage with TPA.CT-01 contractual provisions and TPA.CT-03 AI-specific terms
Control Details
Per-vendor role determination is performed at engagement and on material change — controller, processor per Art. 28, joint controller per Art. 26, or separate controller — based on who determines purposes and means of processing in the AI activity
Joint controllership arrangements per Art. 26(1) are established in writing where applicable, allocating obligations in a transparent manner — information provision per Art. 13/14, rights handling per Art. 15–22, breach response per Art. 33/34, supervisory authority cooperation per Art. 31; data subject point of contact is identified
The essence of joint controller arrangements is made available to data subjects per Art. 26(2) — typically through privacy notice content
Sub-processor cascades are tracked — primary processor's sub-processors, AI model provider's training data processors, infrastructure sub-processors — with Art. 28(2) general or specific authorisation evidence; sub-processor changes trigger notification per contractual terms
Linkage with TPA.CT-01 contractual provisions and TPA.CT-03 AI-specific terms ensures GDPR-required clauses (Art. 28(3) processor terms; joint controller arrangements; sub-processor authorisation) are present and enforceable
Recent CJEU jurisprudence on the breadth of joint controllership (Fashion ID C-40/17; Wirtschaftsakademie C-210/16; Jehovah's Witnesses C-25/17) and EDPB Guidelines 07/2020 inform role determination criteria
Joint controllership arrangements per Art. 26(1) are established in writing where applicable, allocating obligations in a transparent manner — information provision per Art. 13/14, rights handling per Art. 15–22, breach response per Art. 33/34, supervisory authority cooperation per Art. 31; data subject point of contact is identified
The essence of joint controller arrangements is made available to data subjects per Art. 26(2) — typically through privacy notice content
Sub-processor cascades are tracked — primary processor's sub-processors, AI model provider's training data processors, infrastructure sub-processors — with Art. 28(2) general or specific authorisation evidence; sub-processor changes trigger notification per contractual terms
Linkage with TPA.CT-01 contractual provisions and TPA.CT-03 AI-specific terms ensures GDPR-required clauses (Art. 28(3) processor terms; joint controller arrangements; sub-processor authorisation) are present and enforceable
Recent CJEU jurisprudence on the breadth of joint controllership (Fashion ID C-40/17; Wirtschaftsakademie C-210/16; Jehovah's Witnesses C-25/17) and EDPB Guidelines 07/2020 inform role determination criteria
Control Mapping
ISO/IEC 42001:2023 — A.10; A.7.4
NIST AI RMF — GOVERN 6.1; GOVERN 1.1
EU AI Act — Art. 25; Art. 26
GDPR — Art. 4(7); Art. 4(8); Art. 13; Art. 14; Art. 26; Art. 28; Art. 31
EDPB Guidelines 07/2020 (Concepts of Controller and Processor)
CJEU C-40/17 (Fashion ID); C-210/16 (Wirtschaftsakademie); C-25/17 (Jehovah's Witnesses)
Commission Implementing Decision (EU) 2021/915 (Controller-Processor SCC)
NIST AI RMF — GOVERN 6.1; GOVERN 1.1
EU AI Act — Art. 25; Art. 26
GDPR — Art. 4(7); Art. 4(8); Art. 13; Art. 14; Art. 26; Art. 28; Art. 31
EDPB Guidelines 07/2020 (Concepts of Controller and Processor)
CJEU C-40/17 (Fashion ID); C-210/16 (Wirtschaftsakademie); C-25/17 (Jehovah's Witnesses)
Commission Implementing Decision (EU) 2021/915 (Controller-Processor SCC)
TPA.SCAI Supply Chain Integrity4 Controls
Description: AI supply chain integrity — covering AI component supply chain mapping per AI system (models, libraries, datasets, infrastructure), AI Bill of Materials (AI BOM) production and maintenance, supply chain integrity verification, and open-source AI dependency governance — is established, maintained, and verified
TPA.SC-01AI component supply chain mapping per AI system — covering models, libraries, datasets, and infrastructure — is performed and maintainedT 7 · C 7 · F 6
Applies To
Per-AI-system supply chain map
Component classes (models, AI libraries, datasets, AI infrastructure)
Source identification per component
Linkage with CON.IN-03 inventory
Update on material change
Component classes (models, AI libraries, datasets, AI infrastructure)
Source identification per component
Linkage with CON.IN-03 inventory
Update on material change
Control Details
AI component supply chain mapping is performed per AI system the company develops or operates
Component classes covered include models (base, fine-tuned, embeddings), AI libraries (training and inference frameworks), datasets (training, fine-tuning, evaluation, RAG knowledge bases), and AI infrastructure (compute, vector stores, MLOps tooling)
Source identification per component records provenance (vendor, open-source repository, internal artefact)
Linkage with CON.IN-03 AI inventory ensures consistency between Domain views
Update on material change (component swap, version upgrade, source change) maintains currency
Component classes covered include models (base, fine-tuned, embeddings), AI libraries (training and inference frameworks), datasets (training, fine-tuning, evaluation, RAG knowledge bases), and AI infrastructure (compute, vector stores, MLOps tooling)
Source identification per component records provenance (vendor, open-source repository, internal artefact)
Linkage with CON.IN-03 AI inventory ensures consistency between Domain views
Update on material change (component swap, version upgrade, source change) maintains currency
Control Mapping
ISO/IEC 42001:2023 — A.10
NIST AI RMF — GOVERN 6.1; MAP 4.2
EU AI Act — Art. 25; Art. 53(1)(a); Annex IV; Annex XI
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Development
ISO/IEC 5338:2023 — Cl. 6.1.1
ISO/IEC 27001:2022 — A.8.9 (Configuration management)
NIST SP 800-161r1
OWASP AISVS — C10 (Supply Chain Security)
OWASP Top 10 LLM (LLM03 Supply Chain)
NIST AI RMF — GOVERN 6.1; MAP 4.2
EU AI Act — Art. 25; Art. 53(1)(a); Annex IV; Annex XI
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Development
ISO/IEC 5338:2023 — Cl. 6.1.1
ISO/IEC 27001:2022 — A.8.9 (Configuration management)
NIST SP 800-161r1
OWASP AISVS — C10 (Supply Chain Security)
OWASP Top 10 LLM (LLM03 Supply Chain)
TPA.SC-02AI Bill of Materials (AI BOM) production and maintenance per AI artefact — covering content, format, and update — is establishedT 6 · C 6 · F 6
Applies To
Per-artefact AI BOM
Content (components per TPA.SC-01, versions, licences, source, integrity attestations)
Format alignment with emerging standards (CycloneDX ML-BOM, SPDX AI profile)
Update on material change per LIF.VR
Storage and accessibility
Content (components per TPA.SC-01, versions, licences, source, integrity attestations)
Format alignment with emerging standards (CycloneDX ML-BOM, SPDX AI profile)
Update on material change per LIF.VR
Storage and accessibility
Control Details
AI BOM is produced per AI artefact the company develops or substantially configures
Content includes component identification per TPA.SC-01, versions, licences, source, and integrity attestations where available (signing, checksums)
Format alignment with emerging standards — CycloneDX ML-BOM extension, SPDX 3.0 AI profile, NTIA SBOM minimum elements where applicable
Update on material change per LIF.VR-04 version control maintains AI BOM currency
Storage and accessibility aligns with TRA.LR record-keeping where applicable
Content includes component identification per TPA.SC-01, versions, licences, source, and integrity attestations where available (signing, checksums)
Format alignment with emerging standards — CycloneDX ML-BOM extension, SPDX 3.0 AI profile, NTIA SBOM minimum elements where applicable
Update on material change per LIF.VR-04 version control maintains AI BOM currency
Storage and accessibility aligns with TRA.LR record-keeping where applicable
Control Mapping
ISO/IEC 42001:2023 — A.10
NIST AI RMF — GOVERN 6.1; MAP 4.2
EU AI Act — Art. 11; Annex IV; Art. 53(1)(a); Annex XI
EU CRA (Regulation (EU) 2024/2847) — Annex I SBOM requirement (where company products fall in scope)
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Development
NIST SP 800-161r1
OWASP AISVS — C10
OWASP Top 10 LLM (LLM03)
NTIA Minimum Elements for an SBOM
NIST AI RMF — GOVERN 6.1; MAP 4.2
EU AI Act — Art. 11; Annex IV; Art. 53(1)(a); Annex XI
EU CRA (Regulation (EU) 2024/2847) — Annex I SBOM requirement (where company products fall in scope)
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Development
NIST SP 800-161r1
OWASP AISVS — C10
OWASP Top 10 LLM (LLM03)
NTIA Minimum Elements for an SBOM
TPA.SC-03AI supply chain integrity verification — covering provenance, signing, and integrity-check operationalisation — is performedT 6 · C 6 · F 6
Applies To
Provenance verification per ingested component
Signing verification (model artefact signing, package signing)
Integrity checks at ingest and at use
Quarantine and rejection procedure
Linkage with LIF.DC data sourcing integrity
Signing verification (model artefact signing, package signing)
Integrity checks at ingest and at use
Quarantine and rejection procedure
Linkage with LIF.DC data sourcing integrity
Control Details
AI supply chain integrity verification is performed at ingest of third-party AI components
Provenance verification per ingested component confirms origin and version against expected source
Signing verification leverages model artefact signing (Sigstore, vendor signing) and package signing (PEP 458, npm signatures) where available
Integrity checks at ingest (hash verification) and at use (runtime integrity where applicable) detect tampering
Quarantine and rejection procedure handles components failing verification; escalation per LIF.IR where compromise is suspected
Linkage with LIF.DC data sourcing integrity for dataset components maintains coherence
Provenance verification per ingested component confirms origin and version against expected source
Signing verification leverages model artefact signing (Sigstore, vendor signing) and package signing (PEP 458, npm signatures) where available
Integrity checks at ingest (hash verification) and at use (runtime integrity where applicable) detect tampering
Quarantine and rejection procedure handles components failing verification; escalation per LIF.IR where compromise is suspected
Linkage with LIF.DC data sourcing integrity for dataset components maintains coherence
Control Mapping
ISO/IEC 42001:2023 — A.10; A.8 (sourcing)
NIST AI RMF — GOVERN 6.1; MEASURE 2.7
EU AI Act — Art. 15 (cybersecurity); Art. 25
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Development
ISO/IEC 27001:2022 — A.8.9; A.8.30
NIST SP 800-161r1
OWASP AISVS — C10
OWASP Top 10 LLM (LLM03 Supply Chain)
MITRE ATLAS — AML.T0010 (ML Supply Chain Compromise)
NIST AI RMF — GOVERN 6.1; MEASURE 2.7
EU AI Act — Art. 15 (cybersecurity); Art. 25
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Development
ISO/IEC 27001:2022 — A.8.9; A.8.30
NIST SP 800-161r1
OWASP AISVS — C10
OWASP Top 10 LLM (LLM03 Supply Chain)
MITRE ATLAS — AML.T0010 (ML Supply Chain Compromise)
TPA.SC-04Open-source AI dependency governance — covering allow-listing, vulnerability monitoring, licence compliance, and contribution policy — is operationalisedT 7 · C 7 · F 6
Applies To
Open-source AI dependency allow-list / curated repository
Vulnerability monitoring (CVE feeds, model-specific advisories)
Licence compliance per dependency
Contribution policy (where the company contributes back)
Linkage with ISMS secure development per A.8.25
Vulnerability monitoring (CVE feeds, model-specific advisories)
Licence compliance per dependency
Contribution policy (where the company contributes back)
Linkage with ISMS secure development per A.8.25
Control Details
Open-source AI dependency governance is operationalised given the prevalence of open-source in AI stacks
Allow-list / curated repository restricts ingestion to vetted dependencies
Vulnerability monitoring covers CVE feeds, model-specific advisories (e.g., Hugging Face advisories, model hub trust signals), and AI security disclosure channels
Licence compliance per dependency ensures licence terms are observed (OSI-approved licences, model-specific licences such as Llama 3 Community License, Apache 2.0 etc.)
Contribution policy clarifies whether and how the company contributes back to open-source AI projects (e.g., upstreaming fixes, publishing research)
Linkage with ISMS secure development per ISO/IEC 27001:2022 A.8.25–A.8.30 maintains continuity with software supply chain controls
Allow-list / curated repository restricts ingestion to vetted dependencies
Vulnerability monitoring covers CVE feeds, model-specific advisories (e.g., Hugging Face advisories, model hub trust signals), and AI security disclosure channels
Licence compliance per dependency ensures licence terms are observed (OSI-approved licences, model-specific licences such as Llama 3 Community License, Apache 2.0 etc.)
Contribution policy clarifies whether and how the company contributes back to open-source AI projects (e.g., upstreaming fixes, publishing research)
Linkage with ISMS secure development per ISO/IEC 27001:2022 A.8.25–A.8.30 maintains continuity with software supply chain controls
Control Mapping
ISO/IEC 42001:2023 — A.10
NIST AI RMF — GOVERN 6.1; GOVERN 6.2
EU AI Act — Art. 25; Art. 15
EU CRA (Regulation (EU) 2024/2847) — open-source steward provisions
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Development
ISO/IEC 27001:2022 — A.8.25; A.8.28; A.8.30
NIST SP 800-161r1
OWASP AISVS — C10
OWASP Top 10 LLM (LLM03)
NIST AI RMF — GOVERN 6.1; GOVERN 6.2
EU AI Act — Art. 25; Art. 15
EU CRA (Regulation (EU) 2024/2847) — open-source steward provisions
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Development
ISO/IEC 27001:2022 — A.8.25; A.8.28; A.8.30
NIST SP 800-161r1
OWASP AISVS — C10
OWASP Top 10 LLM (LLM03)
TPA.ATAgentic Third-Party and Tool Supply Chain4 Controls
Description: Agentic third-party and tool supply chain — covering third-party agent providers, agent tool and plugin supply chain, MCP server and tool provider governance, agent capability attestation, and tool authorisation review — is established, maintained, and verified
TPA.AT-01Third-party agent provider governance — covering provider due diligence, agent capability scope, and integration controls — is establishedT 7 · C 7 · F 6
Applies To
Third-party agent provider due diligence per TPA.DD-01 specialised for agents
Agent capability scope (what the third-party agent is authorised to do per LIF.AG-01)
Integration controls (sandboxing, authentication, audit)
Provider exit and agent decommissioning
Linkage with CON.IN-03 and agentic registry
Agent capability scope (what the third-party agent is authorised to do per LIF.AG-01)
Integration controls (sandboxing, authentication, audit)
Provider exit and agent decommissioning
Linkage with CON.IN-03 and agentic registry
Control Details
Third-party agent provider governance applies where the company consumes third-party agents
Third-party agent provider due diligence per TPA.DD-01 is specialised for agents covering agent design, training, evaluation, and operational track record
Agent capability scope is defined per LIF.AG-01 authorisation scope and constrained to the deployment context
Integration controls include sandboxing, authentication of the agent into company systems, and audit logging per TRA.AG
Provider exit and agent decommissioning procedure ensures clean removal and data return
Linkage with CON.IN-03 inventory and agentic registry maintains consistency
Third-party agent provider due diligence per TPA.DD-01 is specialised for agents covering agent design, training, evaluation, and operational track record
Agent capability scope is defined per LIF.AG-01 authorisation scope and constrained to the deployment context
Integration controls include sandboxing, authentication of the agent into company systems, and audit logging per TRA.AG
Provider exit and agent decommissioning procedure ensures clean removal and data return
Linkage with CON.IN-03 inventory and agentic registry maintains consistency
Control Mapping
ISO/IEC 42001:2023 — A.10; A.9
NIST AI RMF — GOVERN 6.1; MANAGE 3.2
EU AI Act — Art. 25; Art. 26
ISO/IEC 27001:2022 — A.5.19; A.5.21
OWASP AISVS — C9 (Orchestration and Agentic Action); C10
OWASP Top 10 for Agentic Apps (ASI04 Agent Identification; ASI09 Human-Agent Trust Exploitation; ASI10 Rogue Agents)
OWASP Multi-Agentic System Threat Modelling Guide
CSA Agentic AI Identity and Access Management
NIST AI RMF — GOVERN 6.1; MANAGE 3.2
EU AI Act — Art. 25; Art. 26
ISO/IEC 27001:2022 — A.5.19; A.5.21
OWASP AISVS — C9 (Orchestration and Agentic Action); C10
OWASP Top 10 for Agentic Apps (ASI04 Agent Identification; ASI09 Human-Agent Trust Exploitation; ASI10 Rogue Agents)
OWASP Multi-Agentic System Threat Modelling Guide
CSA Agentic AI Identity and Access Management
TPA.AT-02Agent tool and plugin supply chain — covering MCP server and tool provider governance, tool inventory, and provider vetting — is establishedT 6 · C 6 · F 6
Applies To
MCP server provider governance
Tool / plugin provider vetting
Per-agent tool inventory
Tool provider security and ethics review
Linkage with TPA.SC AI supply chain
Tool / plugin provider vetting
Per-agent tool inventory
Tool provider security and ethics review
Linkage with TPA.SC AI supply chain
Control Details
Agent tool and plugin supply chain governance addresses the rapidly evolving tool / MCP server ecosystem
MCP server provider governance covers vetting of MCP server providers (security posture, code provenance, maintenance status), with allow-listing of approved MCP servers
Tool / plugin provider vetting evaluates each tool exposed to agents
Per-agent tool inventory documents which tools each agent has access to and from which providers
Tool provider security and ethics review covers data handling by the tool, scope of access required, and provider posture
Linkage with TPA.SC AI supply chain and TPA.SC-04 open-source dependency governance maintains coherence
MCP server provider governance covers vetting of MCP server providers (security posture, code provenance, maintenance status), with allow-listing of approved MCP servers
Tool / plugin provider vetting evaluates each tool exposed to agents
Per-agent tool inventory documents which tools each agent has access to and from which providers
Tool provider security and ethics review covers data handling by the tool, scope of access required, and provider posture
Linkage with TPA.SC AI supply chain and TPA.SC-04 open-source dependency governance maintains coherence
Control Mapping
ISO/IEC 42001:2023 — A.10; A.9
NIST AI RMF — GOVERN 6.1; MANAGE 3.2
EU AI Act — Art. 25
ISO/IEC 27001:2022 — A.5.19; A.5.21; A.8.30
OWASP AISVS — C9 (Orchestration and Agentic Action); C10
OWASP Top 10 for Agentic Apps (ASI01 Tool Manipulation; ASI02 Tool Misuse; ASI03 Privilege Compromise)
OWASP Multi-Agentic System Threat Modelling Guide
CSA Agentic AI Red Teaming Guide
NIST AI RMF — GOVERN 6.1; MANAGE 3.2
EU AI Act — Art. 25
ISO/IEC 27001:2022 — A.5.19; A.5.21; A.8.30
OWASP AISVS — C9 (Orchestration and Agentic Action); C10
OWASP Top 10 for Agentic Apps (ASI01 Tool Manipulation; ASI02 Tool Misuse; ASI03 Privilege Compromise)
OWASP Multi-Agentic System Threat Modelling Guide
CSA Agentic AI Red Teaming Guide
TPA.AT-03Agent capability attestation from third-party providers — covering attestation request, evidence review, and update — is operationalisedT 6 · C 6 · F 6
Applies To
Attestation request per third-party agent provider
Evidence review (capability description, evaluation results, known limitations, safety alignment)
Re-attestation cadence
Provider non-cooperation handling
Linkage with TPA.CT contractual attestation provisions
Evidence review (capability description, evaluation results, known limitations, safety alignment)
Re-attestation cadence
Provider non-cooperation handling
Linkage with TPA.CT contractual attestation provisions
Control Details
Agent capability attestation is sought from third-party agent providers prior to integration and at material change
Attestation request covers capability description, evaluation results per provider testing, known limitations, and safety alignment posture
Evidence review compares attested capabilities with the company's intended use and risk class per CON.JU-02
Re-attestation cadence per risk class is established (high-impact agents — at minimum annually and on material provider change)
Provider non-cooperation handling escalates per vendor management and may trigger relationship review
Linkage with TPA.CT contractual attestation provisions establishes the contractual basis for the attestation right
Attestation request covers capability description, evaluation results per provider testing, known limitations, and safety alignment posture
Evidence review compares attested capabilities with the company's intended use and risk class per CON.JU-02
Re-attestation cadence per risk class is established (high-impact agents — at minimum annually and on material provider change)
Provider non-cooperation handling escalates per vendor management and may trigger relationship review
Linkage with TPA.CT contractual attestation provisions establishes the contractual basis for the attestation right
Control Mapping
ISO/IEC 42001:2023 — A.10
NIST AI RMF — GOVERN 6.1; MANAGE 3.2
EU AI Act — Art. 25
ISO/IEC 27001:2022 — A.5.20; A.5.21
OWASP AISVS — C9; C10
OWASP Top 10 for Agentic Apps (ASI04; ASI09; ASI10)
CSA Agentic AI Identity and Access Management
NIST AI RMF — GOVERN 6.1; MANAGE 3.2
EU AI Act — Art. 25
ISO/IEC 27001:2022 — A.5.20; A.5.21
OWASP AISVS — C9; C10
OWASP Top 10 for Agentic Apps (ASI04; ASI09; ASI10)
CSA Agentic AI Identity and Access Management
TPA.AT-04Tool authorisation review — covering per-tool review, scope alignment with agent purpose, and ongoing review — is performedT 6 · C 6 · F 6
Applies To
Per-tool authorisation review prior to tool enablement
Scope alignment with agent purpose per CON.IP and LIF.AG-01
Least-privilege review per scope per CSA AICM
Ongoing review on agent scope change
Linkage with LIF.AG-04 tool authorisation governance
Scope alignment with agent purpose per CON.IP and LIF.AG-01
Least-privilege review per scope per CSA AICM
Ongoing review on agent scope change
Linkage with LIF.AG-04 tool authorisation governance
Control Details
Tool authorisation review is performed prior to enabling each tool for an agent
Per-tool review evaluates the tool's intended function, data scope, action scope, and integration risk
Scope alignment with agent purpose per CON.IP and LIF.AG-01 ensures tools enabled align with the agent's authorised purpose
Least-privilege review per scope per CSA AICM ensures tool authorisation is the minimum required (no superset capabilities)
Ongoing review on agent scope change re-evaluates tool authorisation
Linkage with LIF.AG-04 internal tool authorisation governance ensures unified treatment across internal and third-party tools
Per-tool review evaluates the tool's intended function, data scope, action scope, and integration risk
Scope alignment with agent purpose per CON.IP and LIF.AG-01 ensures tools enabled align with the agent's authorised purpose
Least-privilege review per scope per CSA AICM ensures tool authorisation is the minimum required (no superset capabilities)
Ongoing review on agent scope change re-evaluates tool authorisation
Linkage with LIF.AG-04 internal tool authorisation governance ensures unified treatment across internal and third-party tools
Control Mapping
ISO/IEC 42001:2023 — A.10; A.9
NIST AI RMF — GOVERN 6.1; MANAGE 3.1
EU AI Act — Art. 25
ISO/IEC 27001:2022 — A.5.15; A.8.2; A.8.3
OWASP AISVS — C5 (Access Control and Identity); C9 (Orchestration and Agentic Action)
OWASP Top 10 for Agentic Apps (ASI02 Tool Misuse; ASI03 Privilege Compromise; ASI05 Cascading Hallucinations)
CSA Agentic AI Identity and Access Management
NIST AI RMF — GOVERN 6.1; MANAGE 3.1
EU AI Act — Art. 25
ISO/IEC 27001:2022 — A.5.15; A.8.2; A.8.3
OWASP AISVS — C5 (Access Control and Identity); C9 (Orchestration and Agentic Action)
OWASP Top 10 for Agentic Apps (ASI02 Tool Misuse; ASI03 Privilege Compromise; ASI05 Cascading Hallucinations)
CSA Agentic AI Identity and Access Management
TPA.GPGPAI Provider Obligations3 Controls
Description: GPAI provider obligations to downstream parties — covering downstream provider notifications, information disclosure to downstream providers per EU AI Act Art. 53, support for downstream conformity, GPAI Code of Practice adherence where adopted, and downstream provider relationship management — are established, applied, and maintained
TPA.GP-01GPAI provider downstream notifications and information disclosure per EU AI Act Art. 53 — covering downstream provider identification, Annex XII information disclosure, and disclosure mechanism — are operationalisedT 6 · C 6 · F 6
Applies To
Downstream provider identification per Art. 53
Annex XII information disclosure to downstream providers
Disclosure mechanism (portal, contract appendix, technical documentation reference)
Updates on material model change
Linkage with TRA.TD-02 GPAI technical documentation
Annex XII information disclosure to downstream providers
Disclosure mechanism (portal, contract appendix, technical documentation reference)
Updates on material model change
Linkage with TRA.TD-02 GPAI technical documentation
Control Details
GPAI provider downstream notifications and Art. 53 disclosure obligations are operationalised where the company is a GPAI provider per CON.JU-01
Downstream provider identification covers entities that integrate the company's GPAI into their AI systems
Annex XII information disclosure is provided to downstream providers covering tasks the model can perform, applicable Union law referenced, intended uses, and information per Annex XII elements
Disclosure mechanism uses portal, contract appendix, or technical documentation per TRA.TD-02 reference
Updates on material model change (new version, capability uplift, new known limitation) trigger downstream notification
Linkage with TRA.TD-02 GPAI technical documentation ensures coherent artefact set
Downstream provider identification covers entities that integrate the company's GPAI into their AI systems
Annex XII information disclosure is provided to downstream providers covering tasks the model can perform, applicable Union law referenced, intended uses, and information per Annex XII elements
Disclosure mechanism uses portal, contract appendix, or technical documentation per TRA.TD-02 reference
Updates on material model change (new version, capability uplift, new known limitation) trigger downstream notification
Linkage with TRA.TD-02 GPAI technical documentation ensures coherent artefact set
Control Mapping
ISO/IEC 42001:2023 — A.10; A.8
NIST AI RMF — MEASURE 2.8; GOVERN 1.1
EU AI Act — Art. 53(1)(a); Art. 53(1)(b); Annex XII; Annex XI
OECD AI Principles (OECD/LEGAL/0449)
EU GPAI Code of Practice
NIST AI RMF — MEASURE 2.8; GOVERN 1.1
EU AI Act — Art. 53(1)(a); Art. 53(1)(b); Annex XII; Annex XI
OECD AI Principles (OECD/LEGAL/0449)
EU GPAI Code of Practice
TPA.GP-02Support for downstream conformity — covering downstream conformity support, response to downstream queries, and information sufficiency — is providedT 7 · C 6 · F 6
Applies To
Downstream conformity support scope per Art. 25
Response process for downstream provider queries
Information sufficiency per Art. 53 and per harmonised standards as adopted
Support SLAs for material queries
Linkage with TPA.CT-02 shared responsibility
Response process for downstream provider queries
Information sufficiency per Art. 53 and per harmonised standards as adopted
Support SLAs for material queries
Linkage with TPA.CT-02 shared responsibility
Control Details
Support for downstream conformity is provided where downstream providers integrate the company's GPAI into AI systems subject to EU AI Act obligations
Downstream conformity support scope per Art. 25 covers information needed by downstream providers to meet their EU AI Act obligations
Response process for downstream provider queries assigns ownership, response targets, and escalation
Information sufficiency is assessed against Art. 53 obligations and against harmonised standards as adopted, with material gaps escalated to product and legal
Support SLAs for material queries (high-risk-context queries, regulatory deadline-driven queries) are established
Linkage with TPA.CT-02 shared responsibility documentation ensures conformity support obligations are contracted
Downstream conformity support scope per Art. 25 covers information needed by downstream providers to meet their EU AI Act obligations
Response process for downstream provider queries assigns ownership, response targets, and escalation
Information sufficiency is assessed against Art. 53 obligations and against harmonised standards as adopted, with material gaps escalated to product and legal
Support SLAs for material queries (high-risk-context queries, regulatory deadline-driven queries) are established
Linkage with TPA.CT-02 shared responsibility documentation ensures conformity support obligations are contracted
Control Mapping
ISO/IEC 42001:2023 — A.10; A.8
NIST AI RMF — MEASURE 2.8; GOVERN 6.1
EU AI Act — Art. 25; Art. 53; Art. 26
EU GPAI Code of Practice
NIST AI RMF — MEASURE 2.8; GOVERN 6.1
EU AI Act — Art. 25; Art. 53; Art. 26
EU GPAI Code of Practice
TPA.GP-03GPAI Code of Practice adherence and downstream relationship management — covering Code adherence decision, evidence maintenance, and relationship management — are operationalisedT 6 · C 6 · F 6
Applies To
GPAI Code of Practice adherence decision per Art. 56
Evidence maintenance for adherence commitments
Downstream relationship management (contacts, channels, escalation)
Adherence status communication to downstream providers and AI Office
Linkage with regulatory engagement per GOV.GF
Evidence maintenance for adherence commitments
Downstream relationship management (contacts, channels, escalation)
Adherence status communication to downstream providers and AI Office
Linkage with regulatory engagement per GOV.GF
Control Details
GPAI Code of Practice adherence and downstream relationship management apply where the company is a GPAI provider
GPAI Code of Practice adherence decision per Art. 56 is documented; non-adherence requires demonstration of equivalent compliance with Art. 53 / Art. 55 obligations
Evidence maintenance for adherence commitments supports demonstration to the AI Office per Art. 56(8)
Downstream relationship management maintains contacts, channels, and escalation paths to downstream providers
Adherence status communication to downstream providers and to the AI Office per applicable cadence
Linkage with regulatory engagement per GOV.GF ensures coherent regulatory posture
GPAI Code of Practice adherence decision per Art. 56 is documented; non-adherence requires demonstration of equivalent compliance with Art. 53 / Art. 55 obligations
Evidence maintenance for adherence commitments supports demonstration to the AI Office per Art. 56(8)
Downstream relationship management maintains contacts, channels, and escalation paths to downstream providers
Adherence status communication to downstream providers and to the AI Office per applicable cadence
Linkage with regulatory engagement per GOV.GF ensures coherent regulatory posture
Control Mapping
ISO/IEC 42001:2023 — A.10; A.8
NIST AI RMF — GOVERN 1.1; MEASURE 2.8
EU AI Act — Art. 53; Art. 55; Art. 56; Art. 89; Art. 90; Art. 95; Annex XIII
OECD AI Principles (OECD/LEGAL/0449)
EU GPAI Code of Practice
NIST AI RMF — GOVERN 1.1; MEASURE 2.8
EU AI Act — Art. 53; Art. 55; Art. 56; Art. 89; Art. 90; Art. 95; Annex XIII
OECD AI Principles (OECD/LEGAL/0449)
EU GPAI Code of Practice
TPA.DRDeployer Obligations for Consumed AI4 Controls
Description: Deployer obligations for consumed third-party AI — covering use in accordance with provider instructions per EU AI Act Art. 26(1), human oversight implementation per provider design per Art. 26(2), input data control per Art. 26(4), deployer monitoring obligations per Art. 26(5), and serious incident reporting to provider — are established, applied, and maintained
TPA.DR-01Use of consumed AI in accordance with provider instructions per EU AI Act Art. 26(1) — covering instructions ingestion, alignment verification, and deviation handling — is operationalisedT 6 · C 6 · F 6
Applies To
Provider instructions for use ingestion per consumed AI system
Alignment verification of company use vs provider intended purpose
Deviation handling (use outside intended purpose triggers provider notification per Art. 25(1)(c) and risk reassessment)
Documentation per consumed AI system
Linkage with CON.IP intended purpose and CON.JU risk classification
Alignment verification of company use vs provider intended purpose
Deviation handling (use outside intended purpose triggers provider notification per Art. 25(1)(c) and risk reassessment)
Documentation per consumed AI system
Linkage with CON.IP intended purpose and CON.JU risk classification
Control Details
Use of consumed AI in accordance with provider instructions per Art. 26(1) is operationalised across deployer use
Provider instructions for use ingestion per consumed AI system extracts intended purpose, operating conditions, and oversight expectations
Alignment verification of company use vs provider intended purpose is performed at engagement and on material use change; misalignment is escalated
Deviation handling covers cases where the company's intended use diverges from provider intended purpose — Art. 25(1)(c) considerations apply (the company may become a provider) and risk reassessment is required
Documentation per consumed AI system records the alignment outcome
Linkage with CON.IP intended purpose and CON.JU risk classification maintains coherent deployer governance
Provider instructions for use ingestion per consumed AI system extracts intended purpose, operating conditions, and oversight expectations
Alignment verification of company use vs provider intended purpose is performed at engagement and on material use change; misalignment is escalated
Deviation handling covers cases where the company's intended use diverges from provider intended purpose — Art. 25(1)(c) considerations apply (the company may become a provider) and risk reassessment is required
Documentation per consumed AI system records the alignment outcome
Linkage with CON.IP intended purpose and CON.JU risk classification maintains coherent deployer governance
Control Mapping
ISO/IEC 42001:2023 — A.6.2.5; A.9.2; A.10
NIST AI RMF — MAP 1.1; GOVERN 1.1
EU AI Act — Art. 25(1)(c); Art. 26(1)
ISO/IEC 27001:2022 — A.5.20
OWASP AISVS — C10
NIST AI RMF — MAP 1.1; GOVERN 1.1
EU AI Act — Art. 25(1)(c); Art. 26(1)
ISO/IEC 27001:2022 — A.5.20
OWASP AISVS — C10
TPA.DR-02Human oversight implementation per provider design per Art. 26(2), and worker/worker-representative information before workplace deployment per Art. 26(7), are establishedT 7 · C 7 · F 6
Applies To
Provider oversight design ingestion per consumed AI
Operationalisation of provider-designed oversight by the company
Overseer assignment per HUM.CO and HUM.CM
Documentation of oversight implementation
Worker and worker-representative information before workplace deployment per Art. 26(7)
Linkage with HUM.IN intervention pathways
Operationalisation of provider-designed oversight by the company
Overseer assignment per HUM.CO and HUM.CM
Documentation of oversight implementation
Worker and worker-representative information before workplace deployment per Art. 26(7)
Linkage with HUM.IN intervention pathways
Control Details
Human oversight implementation per provider design is operationalised per Art. 26(2)
Provider oversight design ingestion per consumed AI is performed during onboarding — design covers HITL / HOTL configuration, oversight points, override mechanisms, and competence requirements
Operationalisation of provider-designed oversight by the company adapts provider design to the company's operational context
Overseer assignment per HUM.CO and HUM.CM ensures personnel are assigned with appropriate competence
Documentation of oversight implementation supports demonstration of Art. 26(2) compliance
Where the company deploys consumed AI in workplace contexts affecting workers, affected workers and their representatives are informed before the AI is put into use or use is decided, per Art. 26(7); the information is appropriate to the AI use case and consistent with applicable Union and Member State employment law and worker-information obligations
Linkage with HUM.IN intervention pathways ensures oversight is operationally effective; linkage with GOV.DI-02 communication ensures worker information is delivered through appropriate channels
Provider oversight design ingestion per consumed AI is performed during onboarding — design covers HITL / HOTL configuration, oversight points, override mechanisms, and competence requirements
Operationalisation of provider-designed oversight by the company adapts provider design to the company's operational context
Overseer assignment per HUM.CO and HUM.CM ensures personnel are assigned with appropriate competence
Documentation of oversight implementation supports demonstration of Art. 26(2) compliance
Where the company deploys consumed AI in workplace contexts affecting workers, affected workers and their representatives are informed before the AI is put into use or use is decided, per Art. 26(7); the information is appropriate to the AI use case and consistent with applicable Union and Member State employment law and worker-information obligations
Linkage with HUM.IN intervention pathways ensures oversight is operationally effective; linkage with GOV.DI-02 communication ensures worker information is delivered through appropriate channels
Control Mapping
ISO/IEC 42001:2023 — A.10; A.9
NIST AI RMF — MAP 3.5; GOVERN 2.2
EU AI Act — Art. 14; Art. 26(2); Art. 26(7)
OWASP AISVS — C14 (Human Oversight)
NIST AI RMF — MAP 3.5; GOVERN 2.2
EU AI Act — Art. 14; Art. 26(2); Art. 26(7)
OWASP AISVS — C14 (Human Oversight)
TPA.DR-03Input data control per Art. 26(4) — covering input relevance assessment, input data quality, and accountability — is establishedT 7 · C 7 · F 6
Applies To
Input data scope per consumed AI system
Input relevance and representativeness assessment per Art. 26(4)
Input data quality controls aligned with DAT.QA
Input data lawful basis per DAT.LB
Documentation per consumed AI system
Input relevance and representativeness assessment per Art. 26(4)
Input data quality controls aligned with DAT.QA
Input data lawful basis per DAT.LB
Documentation per consumed AI system
Control Details
Input data control per Art. 26(4) is operationalised where the company controls input data when using consumed AI
Input data scope per consumed AI system is documented including data classes, sources, and lifecycle
Input relevance and representativeness assessment per Art. 26(4) ensures input data is relevant and sufficiently representative in view of the intended purpose; assessment outcomes are documented
Input data quality controls aligned with DAT.QA ensure inputs meet quality expectations for the use case
Input data lawful basis per DAT.LB establishes lawful processing under GDPR and other applicable law
Documentation per consumed AI system supports Art. 26(4) demonstrability
Input data scope per consumed AI system is documented including data classes, sources, and lifecycle
Input relevance and representativeness assessment per Art. 26(4) ensures input data is relevant and sufficiently representative in view of the intended purpose; assessment outcomes are documented
Input data quality controls aligned with DAT.QA ensure inputs meet quality expectations for the use case
Input data lawful basis per DAT.LB establishes lawful processing under GDPR and other applicable law
Documentation per consumed AI system supports Art. 26(4) demonstrability
Control Mapping
ISO/IEC 42001:2023 — A.10; A.7
NIST AI RMF — MEASURE 2.5; GOVERN 1.1
EU AI Act — Art. 26(4)
GDPR — Art. 5(1)(c); Art. 5(1)(d); Art. 6
OWASP AISVS — C4 (Data Operations and Governance)
NIST AI RMF — MEASURE 2.5; GOVERN 1.1
EU AI Act — Art. 26(4)
GDPR — Art. 5(1)(c); Art. 5(1)(d); Art. 6
OWASP AISVS — C4 (Data Operations and Governance)
TPA.DR-04Deployer monitoring and serious incident reporting to provider — covering operational monitoring per Art. 26(5), serious incident reporting per Art. 73, and provider notification — are establishedT 6 · C 6 · F 6
Applies To
Operational monitoring per Art. 26(5)
Anomaly / risk identification triggering provider notification
Serious incident reporting per Art. 73 and per provider contract
Reporting timeliness (immediately upon awareness; within Art. 73 timelines)
Linkage with LIF.IR incident response and LIF.OP operational monitoring
Anomaly / risk identification triggering provider notification
Serious incident reporting per Art. 73 and per provider contract
Reporting timeliness (immediately upon awareness; within Art. 73 timelines)
Linkage with LIF.IR incident response and LIF.OP operational monitoring
Control Details
Deployer monitoring and serious incident reporting to provider operationalise Art. 26(5) and Art. 73 obligations
Operational monitoring per Art. 26(5) tracks AI operation against provider instructions; deviations are investigated
Anomaly / risk identification per LIF.OP-03 triggers provider notification where the operation reveals risk at national level (Art. 79) or serious incident risk
Serious incident reporting per Art. 73 covers incidents resulting in serious harm (death, serious damage to health, serious damage to property or environment, serious infringement of fundamental rights); reporting is to the market surveillance authority within Art. 73 timelines (immediate notification; within 15 days, 10 days, or 2 days depending on severity) and to provider
Linkage with LIF.IR incident response and LIF.OP operational monitoring ensures coherent operational integration
Operational monitoring per Art. 26(5) tracks AI operation against provider instructions; deviations are investigated
Anomaly / risk identification per LIF.OP-03 triggers provider notification where the operation reveals risk at national level (Art. 79) or serious incident risk
Serious incident reporting per Art. 73 covers incidents resulting in serious harm (death, serious damage to health, serious damage to property or environment, serious infringement of fundamental rights); reporting is to the market surveillance authority within Art. 73 timelines (immediate notification; within 15 days, 10 days, or 2 days depending on severity) and to provider
Linkage with LIF.IR incident response and LIF.OP operational monitoring ensures coherent operational integration
Control Mapping
ISO/IEC 42001:2023 — A.10; A.6.2.6
NIST AI RMF — MANAGE 4.1; MANAGE 4.3
EU AI Act — Art. 26(5); Art. 72; Art. 73; Art. 79
GDPR — Art. 33; Art. 34
NIS2 (Directive (EU) 2022/2555) — Art. 23 (where applicable)
ISO/IEC 27001:2022 — A.5.24; A.5.25; A.5.26
OWASP AISVS — C13 (Monitoring and Logging)
NIST AI RMF — MANAGE 4.1; MANAGE 4.3
EU AI Act — Art. 26(5); Art. 72; Art. 73; Art. 79
GDPR — Art. 33; Art. 34
NIS2 (Directive (EU) 2022/2555) — Art. 23 (where applicable)
ISO/IEC 27001:2022 — A.5.24; A.5.25; A.5.26
OWASP AISVS — C13 (Monitoring and Logging)
KPI Scoring Model
The 10-level scale, evidence anchors, aggregation rule, and target-setting guidance that determine how Controls are measured and how the Healthy / Watch / Attention thresholds are derived.
10-Level Maturity Scale with Evidence Anchors
| Level | Band | Description | Evidence Anchor |
|---|---|---|---|
| 1 - Absent | Initial | No controls exist. The area is not addressed: no approach, no activity, no record. Coverage, Execution, Documentation, Reporting, and Review are all None. | No process, no procedure, no records. Asked about the control, the answer is "we don't do this" or "we haven't started". |
| 2 - Ad Hoc / Informal | Initial | The control is performed only reactively or informally. Covers two real-world states sharing the same defining weakness — no systematic, documented, owned approach: (a) reactive — activity occurs on demand or in response to an incident; and/or (b) informal-but-routine — activity is performed with some regularity by individuals, but depends on those people, follows no documented process, and has no formally accountable owner. Coverage and Execution are inconsistent or person-dependent; Documentation is inconsistent or absent; Reporting and Review are absent. | No documented process and no formally accountable owner. Activity is triggered by demand, incident, or individual habit rather than a defined cadence. Records (if any) live in individuals' notes, inboxes, or heads rather than a system of record. If the activity stopped because one person left, it was Level 2. |
| 3 - Planned | Developing | A systematic approach has been recognised, defined, and committed to, but is not yet operating. Gaps are identified; improvement is planned and resourced. Execution and Documentation remain inconsistent; Reporting and Review are not yet reliable. | A documented intention exists (charter, project plan, roadmap entry) with a named owner, allocated resource, and a target date. Execution has not yet begun, or exists only as a pilot. |
| 4 - Implementing | Developing | The systematic approach is being implemented. Process and tooling are partly in place and in use. Coverage and Execution are becoming consistent but are not yet complete; Documentation is consistent; Reporting and Review are still inconsistent. | A documented process exists with a named owner and is in use across at least part of scope. Coverage gaps are known and tracked. Review cadence is not yet routine. |
| 5 - Managed | Established | The systematic approach is operational and maintained as business-as-usual. Required process and tools are used consistently. All five attributes are consistent. | Process operates to a documented cadence across full scope. Outputs are recorded systematically. Periodic review occurs at the defined cadence. Named accountability exists with role-based backup. Owners can produce evidence on request without preparation effort. |
| 6 - Integrated | Established | The control is consciously aligned with the wider governance system and with strategic, tactical, and operational planning. It appears in roadmaps, objectives, and KPIs/OKRs with forward-looking targets — not just current-state scores. All five attributes remain consistent. | Level 5 evidence plus the control appears in at least one of: (a) a current-year executive or board roadmap with a forward target; (b) a non-security business unit's planning document; or (c) a KPI/OKR with a measurable forward trajectory. The forward target must be explicitly documented, quantified, and tracked. A qualitative mention ("we plan to mature this") does not satisfy the anchor. |
| 7 - Measured | Optimising | The control is actively analysed for improvement. Metrics and trend analysis are used routinely to identify weaknesses and drive change; improvement is evidence-led rather than opinion-led. All five attributes consistent. | Metrics are analysed at a defined cadence. In-year improvement decisions are traceable to data findings — not opinion or audit findings alone. Trend analysis is visible in periodic reporting. |
| 8 - Optimising | Optimising | Improvement is continuous and largely self-sustaining. The area refines its own process and tooling based on data, anticipates change rather than reacting to it, and consistently meets or beats its targets. All five attributes consistent. | Process and tooling refinements occur self-directed, based on data, without an external trigger (audit, incident, regulatory pressure). The control regularly meets or exceeds its targets. There is demonstrable anticipation of change — updates ahead of regulatory change or ahead of a threat-landscape shift. |
| 9 - Innovating | Leading | The control extends the wider system's capability. It identifies and introduces genuinely new functionality, process, or tooling that did not previously exist — raising the ceiling for what the organisation can do, not just doing the existing thing better. All five attributes consistent. | The control introduces capability that did not previously exist in the organisation — new process, new tooling, new measurement, or new linkage to a business outcome. The change is internally visible and demonstrably new, distinct from "we improved our existing X". |
| 10 - Leading | Leading | The control is a recognised business enabler at the external edge of practice. It unlocks new business opportunity, shapes practice beyond the organisation, and is benchmarked against — rather than benchmarking. All five attributes consistent. | Externally visible artefacts required: (a) published guidance, case studies, or industry working-group leadership; (b) a formal benchmarking position — the organisation is benchmarked against by others; or (c) recognition by an industry body, regulator, or peer consensus. Level 10 is a recognition of fact, not an aspiration. If asked "are we Level 10?" and the answer involves "we think we are", it is not Level 10. |
Target-Setting Guidance
Targets are set per Control. Without guidance, every Control risks being targeted at Level 8-10, which is unrealistic and dilutes the model's analytical signal. Recommended defaults by Control category:
| Control category | Default target range |
|---|---|
| Foundational governance Controls — policy documentation, procedure documentation, administrative controls which do not require quantitative analysis for effectiveness | 6 |
| Operational baseline Controls — event monitoring, identity & access, CTEM, incident response, change management, backup & recovery | 6-7 |
| Controls protecting critical assets, or controls requiring more detailed analysis for effectiveness | 7-8 |
| Controls underpinning unique competitive capability or where innovation is a deliberate business outcome | 8-9 |
| Where innovation or external recognition is a real and resourced business outcome (not standard operations) | 9-10 |
— A target above Level 8 should be justified per Control with a written business rationale.
— Controls in general should not have a Level 9-10 Target; setting them as aspirational dilutes the model's signal and shifts focus from achievable improvement.
— Targets are reviewed at the same cadence as the maturity scoring itself.
— A regression in score (Current falls below the prior measurement) is itself a finding that warrants documented explanation — not an automatic failure.
The Five Assessment Attributes
Every level is assessed against five attributes. The overall level is governed by the weakest attribute — all five must reach a level's threshold for the Control to score at that level.
| Attribute | Question it answers |
|---|---|
| Coverage | Across what proportion of the in-scope estate does the approach apply? |
| Execution | Is the activity actually performed, consistently, as defined? |
| Documentation | Is the approach and its output recorded in a system of record? |
| Reporting | Are results surfaced to those who need them, on a cadence? |
| Review | Is the approach periodically examined and improved? |
Scoring Protocol — Decision Tree
To make scoring repeatable across assessors, determine the level by answering gate questions in sequence and stopping at the first “no”. The level is the highest band for which all gates are satisfied. Score the five attributes individually first, then apply the gates — the attribute-level data is more diagnostic than the final number.
Step 1Establish the floor
□Does any approach, activity, or record exist at all?No → Level 1
□Is the activity performed only reactively or informally, with no documented process and no accountable owner?Yes → Level 2
Step 2Test the Developing band
□Documented, owned, resourced intention, but the process is not yet operating across scope?Yes → Level 3
□Documented process in use across part of scope; Documentation consistent; Review not yet routine?Yes → Level 4
Step 3Test the Established gate (pivotal threshold)
All six checks must be true to reach Level 5. Any box unchecked → the Control stays at Level 4, regardless of how advanced other attributes are.
□Process operates to a documented cadence across full scope (Coverage consistent)L5 gate
□Activity performed consistently as defined (Execution consistent)L5 gate
□Outputs recorded in a system of record (Documentation consistent)L5 gate
□Results reported on a cadence (Reporting consistent)L5 gate
□Periodic review occurs at the defined cadence (Review consistent)L5 gate
□Evidence producible on request without preparation effortL5 gate
Step 4Test Integrated (Level 6)
□Control appears in a roadmap / non-security plan / OKR with a quantified, tracked forward target?Yes → Level 6
Step 5Test Optimising (Levels 7–8)
□Improvement decisions traceable to metric analysis at a defined cadence?Yes → ≥ Level 7
□Refinements self-directed without external trigger and meeting/beating targets and anticipating change?All yes → Level 8
Step 6Test Leading (Levels 9–10) — exceptional
□Introduced capability that did not previously exist in the organisation?Yes → ≥ Level 9
□External artefacts of recognition / benchmarking (published guidance, being benchmarked against, industry or regulator recognition)?Yes → Level 10
External Crosswalk
A one-line interpretation aid so auditors, customers, and benchmarking surveys can read the scores without translation disputes. Mappings are approximate and for orientation only.
| Level | Band | CMMI v3.0 | NIST CSF 2.0 Tier | Baldrige Cybersecurity Excellence Builder v1.1 | COBIT 2019 |
|---|---|---|---|---|---|
| 1 - Absent | Initial | 0 Incomplete | — | — | 0 Incomplete |
| 2 - Ad Hoc / Informal | Initial | 1 Initial | Tier 1 (Partial) | Reactive | 1 Initial |
| 3 - Planned | Developing | 1-2 | Tier 1-2 | Reactive-Early | 2 Managed |
| 4 - Implementing | Developing | 2 Managed | Tier 2 (Risk Informed) | Early | 2 Managed |
| 5 - Managed | Established | 3 Defined | Tier 2-3 | Developing | 3 Defined |
| 6 - Integrated | Established | 3 Defined | Tier 3 (Repeatable) | Mature | 4 Quantitatively Managed |
| 7 - Measured | Optimising | 4 Quantitatively Managed | Tier 3-4 | Mature-Leading | 4 Quantitatively Managed |
| 8 - Optimising | Optimising | 5 Optimizing | Tier 4 (Adaptive) | Leading | 5 Optimising |
| 9 - Innovating | Leading | (beyond model) | (beyond model) | Exemplary | (beyond model) |
| 10 - Leading | Leading | (beyond model) | (beyond model) | Exemplary | (beyond model) |
Baldrige caps its six-level scale at Exemplary and does not distinguish novelty (Level 9) from external recognition (Level 10); both map to Exemplary. CMMI v3.0 deliberately caps at five levels, partly to avoid incentivising novelty-for-its-own-sake.
Domain × Objective Maturity Heatmap
Click any cell to view that Objective's details.
Healthy (Gap ≤ 0.49)Watch (Gap 0.50–1.25)Attention (Gap > 1.25)
Domain
Obj 1
Obj 2
Obj 3
Obj 4
Obj 5
Obj 6
Obj 7
Obj 8
Obj 9
Obj 10
Obj 11
Obj 12
Govern
PO
6.00
ST
6.00
LD
6.00
RR
6.67
GF
6.50
ET
6.00
AU
6.33
RA
6.25
OB
6.33
CO
6.25
DI
6.50
OV
6.57
Context
OC
6.00
IP
6.25
SC
6.67
JU
6.33
IN
6.75
—
—
—
—
—
—
—
Risk
ME
6.00
ID
6.00
AS
5.67
TR
5.33
RG
5.67
AR
6.00
MO
6.33
—
—
—
—
—
Impact
ME
5.67
IA
5.50
DA
5.67
GP
5.40
MO
6.00
IR
5.67
—
—
—
—
—
—
Data
PO
6.00
IN
6.50
PR
5.67
QU
5.00
BI
5.25
LB
5.40
RE
5.33
SY
6.00
LA
5.33
LK
6.00
—
—
Lifecycle
PO
5.67
DE
6.00
DV
5.60
TR
6.00
VA
5.67
DP
5.75
OP
5.60
VR
6.00
IR
6.00
DC
5.33
AG
6.00
—
Trust
PO
6.33
AC
6.25
FA
7.00
RB
6.50
SA
6.00
EX
6.00
PE
5.33
OI
6.00
RE
6.00
—
—
—
Human
PO
6.00
CO
6.00
IN
5.75
CM
6.00
EF
6.33
UA
5.50
—
—
—
—
—
—
Transparency
PO
6.00
TD
5.67
MC
5.50
IU
6.00
LR
5.67
UD
5.75
AG
6.00
—
—
—
—
—
Third-Party
PO
6.00
DD
6.00
CT
6.20
SC
6.50
AT
6.25
GP
6.00
DR
6.50
—
—
—
—
—
Trends
AIMS-wide maturity, Below-Target counts, and per-Domain trajectory across review periods.
Single period (Q2 2026) shown. As you record quarterly score updates, additional periods will appear on the lines and historical trend will populate. Scoring updates are recorded in the AIMS Framework workbook (Current = column D).
AIMS-Wide Maturity Trend
Below Target Count — AIMS-Wide Trend
Per-Domain Current Score Trend
Below Target
Every Control where Current is below Target — today's view. Sorted by Gap (largest first). Pair with the Trends tab to compare against prior periods.
Healthy (Gap ≤ 0.49)Watch (Gap 0.50–1.25)Attention (Gap > 1.25)
Total Below Target
106
Forecast to Hit Target
2
Forecast Falls Short
1
No Progress Planned
0
Controls Below Target Across All Domains 3
Every Control where Current is below Target. Sorted by Gap (largest first). Click any Domain name to drill in.
ID
Control
Domain
Target
Current
Gap
Forecast
F Gap
IMP.GP-02
GPAI provider obligations per Art. 53 — technical documentation, copyright policy, and training data summary — are produced and maintained for each GPAI model
7.00
4.00
3.00
6.00
1.00
RSK.AS-02
Portfolio-level AI risk assessment — aggregating per-AI risks across the AI inventory to identify concentration, systemic, and cross-cutting risks — is performed and reported
7.00
5.00
2.00
6.00
1.00
RSK.AR-03
Prompt-layer and agentic adversarial risks — covering prompt injection (direct and indirect), tool misuse, goal hijack, and multi-agent collusion — are identified, assessed, and treated
7.00
5.00
2.00
6.00
1.00
IMP.GP-01
GPAI classification and systemic-risk threshold assessment — performed per AI model per EU AI Act Art. 51 — is documented
7.00
5.00
2.00
6.00
1.00
GOV.ST-01
The AI strategy framework is documented, approved at appropriate authority level, and version-controlled, integrating AI product strategy, AI consumption strategy, and AI internal development strategy
7.00
6.00
1.00
6.00
1.00
GOV.ST-02
AI product and service strategy — the provider-mode strategy for AI products and services placed on the market — is documented, approved, and aligned with corporate strategy and target customer needs
7.00
6.00
1.00
6.00
1.00
GOV.ST-03
AI consumption strategy — the deployer-mode strategy for adopting third-party AI products and foundation model APIs — is documented, approved, and aligned with corporate strategy
7.00
6.00
1.00
6.00
1.00
GOV.ST-04
AI internal development strategy — the internal-developer strategy for AI capabilities built in-house for internal use — is documented, approved, and aligned with corporate strategy
7.00
6.00
1.00
6.00
1.00
GOV.AU-02
Shadow AI prevention — covering technical controls to block unsanctioned AI service access, data leakage prevention to sanctioned and unsanctioned AI, identity-controlled SaaS access, and provision of sanctioned alternatives — are established and maintained
7.00
6.00
1.00
6.00
1.00
CON.OC-01
External AI context — regulatory and policy environment, AI threat and opportunity landscape, AI technology trends, market and competitive landscape, and geopolitical factors — is identified, documented, and reviewed at defined cadence and on material change
7.00
6.00
1.00
6.00
1.00
CON.OC-02
Internal AI context — organisational structure, culture, AI capabilities and constraints, and AI strategy implementation context — is identified, documented, and reviewed at defined cadence and on material change
7.00
6.00
1.00
6.00
1.00
CON.OC-03
Context review — covering combined external and internal AI context — is performed at defined cadence and on material change, with findings driving AIMS adjustments
7.00
6.00
1.00
6.00
1.00
CON.IP-02
Affected parties — individuals or groups potentially impacted by AI outputs, decisions, or operations — are identified per AI system and maintained for use in impact assessment
7.00
6.00
1.00
6.00
1.00
RSK.ME-01
The AI risk management methodology — covering assessment criteria, scoring approach, and treatment options — is documented, communicated, and maintained
6.00
5.00
1.00
6.00
0.00
RSK.ME-02
AI risk classes — covering functional, legal, ethical, societal, and commercial risk — are defined and applied to AI risk identification and assessment
7.00
6.00
1.00
6.00
1.00
RSK.ID-01
AI risk identification process — covering techniques (threat modelling, risk workshops, incident review, horizon scanning) and risk sources — is documented and performed
7.00
6.00
1.00
6.00
1.00
RSK.TR-02
Residual risk acceptance — covering acceptance authority per risk level, documentation requirements, time-bound acceptance, and Statement of Applicability approval — is established and applied
6.00
5.00
1.00
6.00
0.00
RSK.TR-03
Treatment effectiveness verification — confirming that implemented treatments deliver the intended residual risk reduction, and updating the Statement of Applicability where verification findings warrant — is performed and documented
6.00
5.00
1.00
6.00
0.00
RSK.RG-02
AI risk reporting — covering risk posture reporting to AI governance forums and board with defined cadence and content — is established and performed
6.00
5.00
1.00
6.00
0.00
RSK.AR-01
Adversarial AI threat modelling — performed per AI system using established taxonomies — is performed at design and updated on material change
7.00
6.00
1.00
6.00
1.00
RSK.AR-04
AI red teaming and adversarial testing programme — covering scope, frequency, methodology, and findings management — is established and operated
7.00
6.00
1.00
6.00
1.00
RSK.MO-01
AI key risk indicators — defined to detect emerging risk and indicate risk posture trends — are monitored on defined cadence
7.00
6.00
1.00
6.00
1.00
IMP.ME-02
Role-specific methodology application — covering how the impact assessment methodology is applied for provider, deployer, and internal-developer contexts — is documented and maintained
6.00
5.00
1.00
6.00
0.00
IMP.IA-04
Impact assessment triggers — new AI system, material change, post-incident, regulatory change — are defined and applied
6.00
5.00
1.00
6.00
0.00
IMP.IA-05
AI benefits and cost-of-errors analysis per AI system — covering intended benefits per affected-party category, expected and realised costs of errors, non-monetary costs, and benefit-cost trade-off documentation — is performed and documented
6.00
5.00
1.00
6.00
0.00
IMP.IA-06
Environmental impact assessment per AI system — covering compute energy consumption, water use, carbon footprint, hardware lifecycle, and sustainability mitigation — is performed and documented
6.00
5.00
1.00
6.00
0.00
IMP.DA-01
DPIA scope determination for AI processing — assessing Art. 35 triggers per AI processing activity — is performed and documented
6.00
5.00
1.00
6.00
0.00
IMP.GP-03
GPAI procedural rights and challenge process — per Art. 52 — are established to respond to Commission designation processes and corrections
7.00
6.00
1.00
6.00
1.00
IMP.GP-04
Systemic-risk GPAI obligations per Art. 55 — model evaluation, adversarial testing, serious incident reporting, and cybersecurity — are established and maintained for models meeting systemic-risk thresholds
7.00
6.00
1.00
6.00
1.00
IMP.GP-05
Authorised representative arrangement per Art. 54 — where the provider is established outside the EU — is established with documented mandate and oversight
7.00
6.00
1.00
6.00
1.00
IMP.IR-02
Independent review of AI impact assessments per defined scope — covering review of methodology application, completeness, and conclusions — is performed and documented
7.00
6.00
1.00
6.00
1.00
IMP.IR-03
Independent review findings, escalation, and action tracking — covering documentation, escalation pathway, and closure verification — are maintained
6.00
5.00
1.00
6.00
0.00
DAT.PR-02
Lineage tracking across the AI data lifecycle — from source through training, fine-tuning, evaluation, and inference — is established and maintained
6.00
5.00
1.00
6.00
0.00
DAT.PR-03
Third-party data provenance verification — covering supplier-provided datasets and third-party model training data — is performed and documented
7.00
6.00
1.00
6.00
1.00
DAT.QU-01
AI data quality criteria — covering representativeness, completeness, accuracy, consistency, and timeliness — are defined per lifecycle stage and applied
6.00
5.00
1.00
6.00
0.00
DAT.QU-02
AI data quality measurement and monitoring — covering ingestion-time assessment and ongoing monitoring — is performed and reported
6.00
5.00
1.00
6.00
0.00
DAT.QU-03
AI data quality treatment and remediation — covering cleaning, augmentation, rebalancing, and rejection — are applied where quality issues are identified
6.00
5.00
1.00
6.00
0.00
DAT.QU-04
AI data quality assurance review is performed at defined cadence with findings driving methodology and treatment improvements
6.00
5.00
1.00
6.00
0.00
DAT.BI-01
Bias identification methodology for AI datasets — covering bias sources, identification techniques, and documentation — is established and applied
6.00
5.00
1.00
6.00
0.00
DAT.BI-02
Bias measurement in AI datasets — covering representativeness, demographic balance, label bias, and outcome bias — is performed and documented
6.00
5.00
1.00
6.00
0.00
DAT.BI-03
Bias mitigation at dataset level — covering sampling, augmentation, reweighting, and debiasing techniques — is applied where bias is identified
6.00
5.00
1.00
6.00
0.00
DAT.LB-01
Lawful basis determination per AI processing activity — covering GDPR Art. 6 grounds and Art. 9 special category restrictions — is performed and documented
6.00
5.00
1.00
6.00
0.00
DAT.LB-04
Consent management where AI processing relies on consent — covering valid consent collection, withdrawal handling, and record-keeping — is operated
6.00
5.00
1.00
6.00
0.00
DAT.LB-05
International data transfers for AI processing per GDPR Art. 44–49 — covering transfer mechanism selection, Transfer Impact Assessment, supplementary measures, and per-transfer record-keeping — are established and maintained
6.00
5.00
1.00
6.00
0.00
DAT.RE-01
Data minimisation in collection and processing — covering necessity assessment, purpose limitation, and use restriction — is applied across the AI data lifecycle
6.00
5.00
1.00
6.00
0.00
DAT.RE-03
Lawful disposal at end of retention — covering deletion, anonymisation, and verification — is performed for AI data classes
6.00
5.00
1.00
6.00
0.00
DAT.LA-02
Annotator competence and training — covering competence requirements, training, and ongoing capability assessment — are established
6.00
5.00
1.00
6.00
0.00
DAT.LA-03
Ethical and labour considerations for the annotation workforce — covering working conditions, exposure to harmful content, and fair labour practices — are established
6.00
5.00
1.00
6.00
0.00
DAT.LK-01
Training-time data exposure prevention — covering Restricted data exclusion, memorisation reduction, and access governance — is established
7.00
6.00
1.00
6.00
1.00
DAT.LK-02
Output-side leakage prevention — covering model regurgitation, membership inference resistance, and output filtering — is established
7.00
6.00
1.00
6.00
1.00
LIF.PO-02
Stage-gate criteria and approval authorities — covering go / no-go criteria, approval authority per stage, and evidence required at each gate — are defined and applied
6.00
5.00
1.00
6.00
0.00
LIF.DE-02
AI architecture and design decisions — covering model selection, data flow, integration topology, and trade-off documentation — are performed and documented
7.00
6.00
1.00
6.00
1.00
LIF.DE-03
Safety-by-design and ethics-by-design principles — covering safety constraints, ethical safeguards, and design-time consideration of harm scenarios — are applied per AI system
7.00
6.00
1.00
6.00
1.00
LIF.DE-04
Design review and approval — covering review scope, participants, evidence required, and approval authority — are performed before progression to development
7.00
6.00
1.00
6.00
1.00
LIF.DV-04
Secure coding practices for AI components — covering AI-specific secure coding, code review, and testing integration — are established
6.00
5.00
1.00
6.00
0.00
LIF.DV-05
Model artefact integrity controls — covering model storage, signing, verification, and safe loading — are established and maintained
6.00
5.00
1.00
6.00
0.00
LIF.TR-01
Training data preparation and integrity — covering dataset selection, pre-processing, integrity verification, and split discipline — is established per training run
7.00
6.00
1.00
6.00
1.00
LIF.TR-03
Training run documentation and reproducibility — covering hyperparameter capture, run metadata, and reproducibility artefacts — are established per training run
7.00
6.00
1.00
6.00
1.00
LIF.TR-04
Foundation model training process governance — covering pretraining decisions, fine-tuning workflows, and safety alignment — is established
7.00
6.00
1.00
6.00
1.00
LIF.VA-01
Performance evaluation against defined metrics — covering metric selection, evaluation execution, and performance thresholds — is performed per AI system before deployment
6.00
5.00
1.00
6.00
0.00
LIF.VA-02
Robustness and stress testing — covering perturbation testing, distribution shift testing, and resource stress testing — is performed pre-deployment
6.00
5.00
1.00
6.00
0.00
LIF.VA-04
Adversarial testing pre-deployment — covering attack-surface testing, red teaming, and capability elicitation — is performed and findings remediated
7.00
6.00
1.00
6.00
1.00
LIF.DP-03
Provider release documentation and instructions for use — produced per EU AI Act Art. 13 expectations and TRA.IU — accompany every provider release
7.00
6.00
1.00
6.00
1.00
LIF.DP-04
Deployer acceptance testing of consumed AI — covering pre-adoption evaluation, contractual conformance verification, and integration validation — is performed
6.00
5.00
1.00
6.00
0.00
LIF.OP-01
Runtime performance monitoring against expected baselines — covering metric collection, baseline comparison, and divergence alerting — is established per AI system
6.00
5.00
1.00
6.00
0.00
LIF.OP-02
Data and concept drift detection — covering input distribution monitoring, output drift monitoring, and ground-truth drift — is established
6.00
5.00
1.00
6.00
0.00
LIF.OP-03
Abuse pattern and adversarial behaviour detection — covering anomalous input detection, jailbreak attempt detection, and rate / pattern analysis — is established
7.00
6.00
1.00
6.00
1.00
LIF.OP-04
Output safety monitoring — covering harmful output detection, hallucination monitoring, refusal-failure tracking, and PII leakage detection — is established
7.00
6.00
1.00
6.00
1.00
LIF.OP-05
Retraining triggers and operational reporting — covering automated triggers, manual triggers, decision authority, and operational reporting cadence — are established
7.00
6.00
1.00
6.00
1.00
LIF.VR-03
Dataset versioning linked to model versions — covering dataset version identifiers, dataset registry, and model-to-dataset linkage — is established
7.00
6.00
1.00
6.00
1.00
LIF.IR-01
AI incident classes and declaration criteria — covering AI-specific incident taxonomy, declaration thresholds, and triage process — are defined
7.00
6.00
1.00
6.00
1.00
LIF.IR-02
AI incident response and containment process — covering response activation, containment actions, evidence preservation, and stakeholder notification — is established
7.00
6.00
1.00
6.00
1.00
LIF.IR-03
Root cause analysis and post-incident learning — covering systematic investigation, lessons captured, and improvement actions — are established
7.00
6.00
1.00
6.00
1.00
LIF.IR-04
Serious incident reporting for GPAI per EU AI Act Art. 55 — covering reporting criteria, timelines, content, and follow-up — is established
7.00
6.00
1.00
6.00
1.00
LIF.IR-05
Provider corrective actions and duty of information per EU AI Act Art. 20 — covering non-conformity triggers, corrective actions, downstream notification, and authority cooperation — are established
7.00
6.00
1.00
6.00
1.00
LIF.DC-01
AI decommissioning process and triggers — covering retirement criteria, decommissioning workflow, and decision authority — are established
6.00
5.00
1.00
6.00
0.00
LIF.DC-02
Provider end-of-life customer notification and migration support — covering notification timelines, migration assistance, and contractual obligation handling — are established
6.00
5.00
1.00
6.00
0.00
LIF.AG-01
Agent authorisation scope — covering tools, actions, data access, autonomy level, and per-agent scope documentation — is defined and enforced
7.00
6.00
1.00
6.00
1.00
LIF.AG-03
Multi-agent orchestration design and inter-agent communication — covering communication protocols, authority boundaries, and conflict resolution — are established
7.00
6.00
1.00
6.00
1.00
LIF.AG-05
Emergency suspension and revocation capability for agentic systems — covering kill switches, capability revocation, and tested exercise — is established
7.00
6.00
1.00
6.00
1.00
TRU.RB-04
Robustness monitoring in production — covering ongoing robustness measurement, signal detection, and response — is established
7.00
6.00
1.00
6.00
1.00
TRU.SA-01
AI safety boundaries — covering harmful output prevention, refusal training, content filters, and policy enforcement — are established per AI system
7.00
6.00
1.00
6.00
1.00
TRU.SA-02
Agent behaviour safety — covering action limits, goal alignment, multi-agent containment, and behaviour boundaries — is established per agent system
7.00
6.00
1.00
6.00
1.00
TRU.SA-03
AI safety testing methodology — covering safety test design, evaluation criteria, and methodology documentation — is established
7.00
6.00
1.00
6.00
1.00
TRU.SA-04
Dangerous-capability assessment for foundation models — covering capability elicitation, risk thresholds, and Art. 55 alignment — is performed per GPAI per IMP.GP-01
7.00
6.00
1.00
6.00
1.00
TRU.SA-05
AI safety monitoring in production — covering refusal-failure tracking, safety boundary breach detection, and reporting — is established
7.00
6.00
1.00
6.00
1.00
TRU.EX-04
User-facing explanation delivery — covering presentation, accessibility, and linkage with right-to-explanation processes — is established
7.00
6.00
1.00
6.00
1.00
TRU.PE-01
PET selection and application per AI use case — covering PET options, selection criteria, and application — are established
7.00
6.00
1.00
6.00
1.00
TRU.PE-02
Privacy-preserving training — covering differential privacy, federated learning, and secure multi-party computation where applied — is established
6.00
5.00
1.00
6.00
0.00
TRU.PE-03
PET effectiveness measurement — covering privacy guarantee verification, residual privacy risk assessment, and reporting — is performed
6.00
5.00
1.00
6.00
0.00
TRU.OI-01
AI-generated content marking and watermarking per EU AI Act Art. 50 — covering provider obligations and technical implementation — is applied
7.00
6.00
1.00
6.00
1.00
TRU.OI-02
Output provenance traceability — covering output-to-model linkage, output-to-input lineage, and audit traceability — is established
7.00
6.00
1.00
6.00
1.00
TRU.OI-03
Synthetic content identification (deepfake, AI-generated media) — covering deepfake detection, attribution, and reporting — is established for deployers and providers
7.00
6.00
1.00
6.00
1.00
TRU.OI-04
Downstream attribution and output integrity verification — covering downstream-of-AI content tracking and integrity verification — is established
7.00
6.00
1.00
6.00
1.00
TRU.RE-02
Fault tolerance, failover, and graceful degradation design — covering redundancy, failover mechanisms, and degraded-mode behaviour — is established
7.00
6.00
1.00
6.00
1.00
HUM.IN-01
Override capability per AI system — covering override availability, override interfaces, and authorisation — is established
6.00
5.00
1.00
6.00
0.00
HUM.UA-02
Right to explanation of AI decisions per EU AI Act Art. 86 and GDPR Art. 22 — covering eligibility, request handling, and explanation delivery — is operationalised
6.00
5.00
1.00
6.00
0.00
HUM.UA-04
Redress and remediation pathways — covering harm redress, restorative actions, and systemic improvement — are established
6.00
5.00
1.00
6.00
0.00
TRA.TD-01
Provider technical documentation — covering content per EU AI Act Art. 11 and Annex IV applicable elements, draft–issue–maintain workflow, and pre-market readiness — is produced for in-scope AI
6.00
5.00
1.00
6.00
0.00
TRA.MC-02
System card production, version control, and accessibility — covering system architecture description, AI components used, integration context, and publication — are established
6.00
5.00
1.00
6.00
0.00
TRA.LR-03
Log retention, integrity protection, and access governance — covering per-class retention, integrity controls, and access controls — are operationalised
6.00
5.00
1.00
6.00
0.00
TRA.UD-01
AI interaction disclosure to natural persons per EU AI Act Art. 50(1) — covering disclosure trigger, content, form, and timing — is operationalised
6.00
5.00
1.00
6.00
0.00
TRA.AG-02
Agentic trace retention, integrity protection, and use in oversight and incident response — covering retention, integrity, replay support, and access governance — are operationalised
7.00
6.00
1.00
6.00
1.00
TPA.DD-01
AI vendor due diligence criteria per vendor class — covering foundation model providers, AI API and service vendors, fine-tuning relationships, and model marketplaces — are established and applied
7.00
6.00
1.00
6.00
1.00
TPA.DD-02
Due diligence depth scaled by AI risk class — covering risk-classification linkage, scaled rigour, and approval authority — is operationalised
7.00
6.00
1.00
6.00
1.00
TPA.GP-02
Support for downstream conformity — covering downstream conformity support, response to downstream queries, and information sufficiency — is provided
7.00
6.00
1.00
6.00
1.00
ISO 42001 — Audit Prep
Certification document register status, Stage 1 minimum dossier, and critical gaps. Driven by the AIMS Outputs ISO 42001 Certification Document Register.
Approved / In OperationDrafted / In Review / DraftingNot started
Total Documents
27
Mandatory
22
Recommended
5
Approved
24
In Operation
24
Critical Gaps
3
Stage 1 minimum dossier (7 docs)
These seven documents are the irreducible minimum a Lead Auditor will require for Stage 2. Address these before anything else.
Doc 1AIMS Scope StatementCl. 4.3MandatoryStage 1 minimum
Status: Approved & in operation
Owner: CISO
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-01-15
Next review: 2027-01-15
AIMS Control linkage: CON.SC-01, CON.SC-02, CON.SC-03
Purpose
Defines what is in and out of scope for the AIMS — organisational entities, AI roles, AI systems and activities, geographic and asset boundaries.
Required content
Boundaries and applicability; AI activities by role (provider, deployer, internal developer); entities included; documented exclusions with rationale; interfaces and dependencies with adjacent management systems (ISMS, PIMS).
Audit evidence
The scope document itself, approval record, review minutes, and traceability to the Control Library and SoA.
Doc 2AI PolicyCl. 5.2MandatoryStage 1 minimum
Status: Approved & in operation
Owner: Chief AI Officer
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-02-15
Next review: 2027-02-15
AIMS Control linkage: GOV.PO-01, GOV.PO-02, GOV.PO-03, GOV.PO-04
Purpose
Top-management statement of intent on responsible AI, defining principles, scope, accountability, and the framework for AI objectives.
Required content
AI principles and ethical commitments; scope of application (provider / deployer / internal developer); top-level accountability; commitment to meeting applicable requirements and to continual improvement; framework for setting AI objectives; review cadence.
Audit evidence
Approved policy artefact; evidence of communication (intranet posting, acknowledgements, training); review records; alignment evidence with adjacent policies (InfoSec, privacy, ethics, code of conduct).
Doc 6Statement of Applicability (SoA)Cl. 6.1.3MandatoryStage 1 minimum
Status: Approved & in operation
Owner: CISO
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-01-15
Next review: 2027-01-15
AIMS Control linkage: Library-wide (all Annex A-aligned Controls)
Purpose
Documents which Annex A controls apply, whether each is implemented or excluded, and the justification.
Required content
Each Annex A control; applicability decision (in / out); justification for exclusions; implementation status; linkage to the AIMS Control Library; approval signature.
Audit evidence
Approved SoA; traceability from Annex A controls through the Library Controls to operational evidence.
Doc 8AI Objectives DocumentCl. 6.2MandatoryStage 1 minimum
Status: Approved & in operation
Owner: Chief AI Officer
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-03-15
Next review: 2027-03-15
AIMS Control linkage: GOV.OB-01, GOV.OB-02
Purpose
Documents the organisation's measurable AI objectives at relevant functions and levels, derived from AI strategy and AI policy.
Required content
Objectives; relevant functions and levels they apply at; measurability criteria (SMART); per-objective owner, resources, and timeline; tracking and reporting approach.
Audit evidence
Objectives document; KPI / KRI dashboards; performance reports against objectives; management review minutes referencing objectives.
Doc 19Monitoring, Measurement, Analysis & Evaluation ResultsCl. 9.1MandatoryStage 1 minimum
Status: Approved & in operation
Owner: AIMS Manager
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-04-15
Next review: 2027-04-15
AIMS Control linkage: GOV.OV-01, GOV.OV-02, GOV.OV-06
Purpose
Demonstrates that the AIMS is measured against its objectives and that performance is evaluated.
Required content
KPI / KRI definitions; measurement records; analysis outcomes; evaluation against AI objectives; reporting to AI governance forums and top management.
Audit evidence
KPI / KRI definition document; measurement records; dashboards; evaluation reports.
Doc 20Internal Audit Programme & ReportsCl. 9.2MandatoryStage 1 minimum
Status: Approved & in operation
Owner: Internal Audit Lead
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-05-15
Next review: 2027-05-15
AIMS Control linkage: GOV.OV-03
Purpose
Demonstrates that the AIMS is subject to planned internal audits covering conformity and effectiveness.
Required content
Annual audit programme; audit scope, criteria, methods; auditor independence and competence; audit reports; follow-up on findings.
Audit evidence
Programme document; completed audit reports; auditor competence evidence; nonconformity records and closure evidence.
Doc 21Management Review RecordsCl. 9.3MandatoryStage 1 minimum
Status: Approved & in operation
Owner: Chief AI Officer
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-01-15
Next review: 2027-01-15
AIMS Control linkage: GOV.OV-05
Purpose
Top management's periodic review of AIMS suitability, adequacy, effectiveness, and alignment with strategic direction.
Required content
Review inputs (per Cl. 9.3.2) — status of actions from prior reviews; changes affecting AIMS; performance and effectiveness; resource needs; opportunities for improvement. Review outputs (per Cl. 9.3.3) — decisions and actions related to continual improvement and any needed changes.
Audit evidence
Minutes of management reviews covering all required inputs and outputs; decisions traceable to subsequent actions.
Critical gaps — Board attention
3 mandatory documents (per-AI-system records) still being finalised. 24 of 27 documents (89%) are Approved and In Operation, including the full Stage 1 dossier — the AIMS is substantially audit-ready.
Doc 16AI Risk Assessment Records (per AI system)Cl. 8.2 (operational) / Cl. 6.1.2 (process)Mandatory
Status: In progress — drafting
Owner: Head of AI Risk
Version: 0.9 (draft)
Location: AIMS GRC Repository
Last reviewed: —
Next review: 2026-08-31 (target)
AIMS Control linkage: RSK.AS-01, RSK.AS-03, RSK.RG-01
Purpose
Demonstrates that risk assessment has been performed for each in-scope AI system, applying the methodology in Doc 4.
Required content
Per-AI-system risk assessment with inherent and residual risk; sign-off; reassessment triggers and outcomes; consolidation in the AI risk register.
Audit evidence
Risk register; sampled per-AI assessments; reassessment evidence.
Doc 17AI Risk Treatment Records (per AI system)Cl. 8.3 (operational) / Cl. 6.1.3 (process)Mandatory
Status: In progress — drafting
Owner: Head of AI Risk
Version: 0.9 (draft)
Location: AIMS GRC Repository
Last reviewed: —
Next review: 2026-08-31 (target)
AIMS Control linkage: RSK.TR-01, RSK.TR-02, RSK.TR-03
Purpose
Demonstrates that risk treatments are selected, implemented, accepted (where applicable), and verified per the methodology.
Required content
Treatment selections per identified risk; implementation evidence; residual risk acceptance with appropriate authority; effectiveness verification.
Audit evidence
Treatment plan; closure records; acceptance records; verification outcomes.
Doc 18AI System Impact Assessment Records (per AI system)Cl. 8.4 (operational) / Cl. 6.1.4 (process)Mandatory
Status: In progress — drafting
Owner: DPO / AI Impact Lead
Version: 0.9 (draft)
Location: AIMS GRC Repository
Last reviewed: —
Next review: 2026-08-31 (target)
AIMS Control linkage: IMP.IA-01 through IMP.IA-04, IMP.DA-01..03 (DPIA), IMP.MO-01..03
Purpose
Demonstrates that impact assessment has been performed for each in-scope AI system, applying the methodology in Doc 7, including DPIA where GDPR Art. 35 applies.
Required content
Per-AI impact assessment; affected-party analysis; foreseeable misuse; DPIA where applicable; pre-deployment go/no-go decision; post-deployment monitoring outcomes.
Audit evidence
Sampled impact assessments; DPIA records; go/no-go decisions; post-deployment monitoring reports.
Full Document Register (27)
All certification documents organised by document number. Click any document to expand.
Doc 1AIMS Scope StatementCl. 4.3MandatoryStage 1 minimum
Status: Approved & in operation
Owner: CISO
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-01-15
Next review: 2027-01-15
AIMS Control linkage: CON.SC-01, CON.SC-02, CON.SC-03
Purpose
Defines what is in and out of scope for the AIMS — organisational entities, AI roles, AI systems and activities, geographic and asset boundaries.
Required content
Boundaries and applicability; AI activities by role (provider, deployer, internal developer); entities included; documented exclusions with rationale; interfaces and dependencies with adjacent management systems (ISMS, PIMS).
Audit evidence
The scope document itself, approval record, review minutes, and traceability to the Control Library and SoA.
Doc 2AI PolicyCl. 5.2MandatoryStage 1 minimum
Status: Approved & in operation
Owner: Chief AI Officer
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-02-15
Next review: 2027-02-15
AIMS Control linkage: GOV.PO-01, GOV.PO-02, GOV.PO-03, GOV.PO-04
Purpose
Top-management statement of intent on responsible AI, defining principles, scope, accountability, and the framework for AI objectives.
Required content
AI principles and ethical commitments; scope of application (provider / deployer / internal developer); top-level accountability; commitment to meeting applicable requirements and to continual improvement; framework for setting AI objectives; review cadence.
Audit evidence
Approved policy artefact; evidence of communication (intranet posting, acknowledgements, training); review records; alignment evidence with adjacent policies (InfoSec, privacy, ethics, code of conduct).
Doc 3AI Roles, Responsibilities and AuthoritiesCl. 5.3Mandatory
Status: Approved & in operation
Owner: Chief AI Officer
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-03-15
Next review: 2027-03-15
AIMS Control linkage: GOV.RR-01 through GOV.RR-06
Purpose
Documents who is accountable, responsible, consulted, and informed for AI decisions across the AIMS.
Required content
Accountable AI executive (Chief AI Officer or equivalent) mandate; AI governance functions and decision rights (RACI); decision rights per AI deployment / expansion / decommissioning; segregation of duties; provider / deployer / internal-developer role accountability split.
Audit evidence
Documented role descriptions; appointment letters or equivalent; org chart; RACI matrix; minutes of decisions taken under defined authority.
Doc 4AI Risk Assessment MethodologyCl. 6.1.2Mandatory
Status: Approved & in operation
Owner: Head of AI Risk
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-04-15
Next review: 2027-04-15
AIMS Control linkage: RSK.ME-01 through RSK.ME-04
Purpose
Defines how AI risks are identified, analysed, evaluated, and documented across the AI portfolio.
Required content
Risk identification techniques; risk classes (functional, legal, ethical, societal, commercial); scoring scales (likelihood, impact); inherent / residual scoring approach; role-specific application; reassessment triggers; documentation requirements.
Audit evidence
Approved methodology document; example risk assessments executed under the methodology; review records.
Doc 5AI Risk Treatment Process & PlanCl. 6.1.3Mandatory
Status: Approved & in operation
Owner: Head of AI Risk
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-05-15
Next review: 2027-05-15
AIMS Control linkage: RSK.TR-01, RSK.TR-02, RSK.TR-03
Purpose
Defines how risks are treated (mitigate / transfer / accept / avoid), who approves residual risk, and how treatment effectiveness is verified.
Required content
Treatment options; selection criteria; residual risk acceptance authority by risk level; treatment plan template; effectiveness verification approach; linkage to Annex A controls and SoA.
Audit evidence
Treatment plan; residual risk acceptance records; verification of treatment effectiveness; closure evidence on completed treatments.
Doc 6Statement of Applicability (SoA)Cl. 6.1.3MandatoryStage 1 minimum
Status: Approved & in operation
Owner: CISO
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-01-15
Next review: 2027-01-15
AIMS Control linkage: Library-wide (all Annex A-aligned Controls)
Purpose
Documents which Annex A controls apply, whether each is implemented or excluded, and the justification.
Required content
Each Annex A control; applicability decision (in / out); justification for exclusions; implementation status; linkage to the AIMS Control Library; approval signature.
Audit evidence
Approved SoA; traceability from Annex A controls through the Library Controls to operational evidence.
Doc 7AI System Impact Assessment MethodologyCl. 6.1.4Mandatory
Status: Approved & in operation
Owner: DPO / AI Impact Lead
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-02-15
Next review: 2027-02-15
AIMS Control linkage: IMP.ME-01, IMP.ME-02, IMP.ME-03
Purpose
Defines how the organisation assesses the impacts of AI systems on individuals, groups, and society.
Required content
Scope; impact categories assessed; affected-party identification approach (per CON.IP-02); intended use and foreseeable misuse assessment; criteria; documentation requirements; review cadence.
Audit evidence
Approved methodology; example impact assessments executed under it; review records.
Doc 8AI Objectives DocumentCl. 6.2MandatoryStage 1 minimum
Status: Approved & in operation
Owner: Chief AI Officer
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-03-15
Next review: 2027-03-15
AIMS Control linkage: GOV.OB-01, GOV.OB-02
Purpose
Documents the organisation's measurable AI objectives at relevant functions and levels, derived from AI strategy and AI policy.
Required content
Objectives; relevant functions and levels they apply at; measurability criteria (SMART); per-objective owner, resources, and timeline; tracking and reporting approach.
Audit evidence
Objectives document; KPI / KRI dashboards; performance reports against objectives; management review minutes referencing objectives.
Doc 9AIMS Change Planning RecordsCl. 6.3Mandatory
Status: Approved & in operation
Owner: AIMS Manager
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-04-15
Next review: 2027-04-15
AIMS Control linkage: GOV.OB-03
Purpose
Demonstrates that AIMS-level changes (scope, organisational, regulatory, technological, strategic) are planned, impact-assessed, approved, implemented, and verified.
Required content
Change request template; change impact assessment template; approval evidence; implementation plans; verification activities and outcomes.
Audit evidence
Sampled change records covering AIMS changes since the last audit.
Doc 10AIMS Resource PlanCl. 7.1Mandatory
Status: Approved & in operation
Owner: Chief AI Officer
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-05-15
Next review: 2027-05-15
AIMS Control linkage: GOV.LD-02
Purpose
Documents the financial, human, technological, infrastructure, and AI-specific compute and energy resources allocated to the AIMS.
Required content
Resource requirements derived from AIMS objectives and AI portfolio; budget allocation; headcount plan; technology and infrastructure footprint; compute / energy planning; review cadence.
Audit evidence
Resource plan; budget vs actual reports; headcount evidence; resource sufficiency assessments in management review minutes.
Doc 11Competence Framework & RecordsCl. 7.2Mandatory
Status: Approved & in operation
Owner: AIMS Manager
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-01-15
Next review: 2027-01-15
AIMS Control linkage: GOV.CO-01, GOV.CO-04, HUM.CM-01, HUM.CM-03
Purpose
Defines competence requirements per AI role and maintains records evidencing competence.
Required content
Role-specific competence profiles; assessment approach; competence records per individual; gap identification and remediation; oversight-personnel competence (HUM.CM).
Audit evidence
Competence framework; competence records (sampled); training completion evidence; effectiveness assessments.
Doc 12Awareness & Training RecordsCl. 7.3 (and EU AI Act Art. 4 AI literacy)Mandatory
Status: Approved & in operation
Owner: AIMS Manager
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-02-15
Next review: 2027-02-15
AIMS Control linkage: GOV.CO-02, GOV.CO-03, HUM.CM-02
Purpose
Demonstrates workforce AI literacy and role-specific AI training is delivered and effective.
Required content
AI literacy programme content; role-specific training content; delivery records; refresher schedule; effectiveness measurement.
Audit evidence
Training catalogue; completion records (sampled); refresher tracking; effectiveness metrics.
Doc 13Communications PlanCl. 7.4Mandatory
Status: Approved & in operation
Owner: AIMS Manager
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-03-15
Next review: 2027-03-15
AIMS Control linkage: GOV.DI-02, GOV.PO-03, GOV.RA-02
Purpose
Defines internal and external AIMS-related communication: content, audience, timing, channels, responsibility.
Required content
Communication matrix; channels; cadence; responsibility; triggers for ad-hoc communication on material change; coordination with TRA Domain regulatory disclosure obligations.
Audit evidence
Plan document; sampled communications (internal and external); records of stakeholder engagement.
Doc 14Documented Information Control ProcedureCl. 7.5Mandatory
Status: Approved & in operation
Owner: AIMS Manager
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-04-15
Next review: 2027-04-15
AIMS Control linkage: GOV.DI-01
Purpose
Defines how AIMS documented information is created, reviewed, approved, version-controlled, retained, accessed, and protected.
Required content
Documented information catalogue; ownership and review workflow; version control approach; retention schedule per record class; access control; disposition; linkage with ISMS records control (A.5.33).
Audit evidence
Procedure document; documented information catalogue; sample document headers showing version and approval; retention evidence; access logs where relevant.
Doc 15Operational Planning & Control RecordsCl. 8.1Mandatory
Status: Approved & in operation
Owner: AIMS Manager
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-05-15
Next review: 2027-05-15
AIMS Control linkage: LIF.PO-01, LIF.PO-02, LIF.PO-03 (lifecycle process)
Purpose
Demonstrates that the AIMS is operationally planned and controlled — processes are defined, criteria established, outsourced processes managed.
Required content
AI lifecycle process definition; stage-gate criteria; outsourced AI process controls (TPA linkage); operational records demonstrating control.
Audit evidence
Process documentation; stage-gate evidence per AI system; outsourced process oversight records.
Doc 16AI Risk Assessment Records (per AI system)Cl. 8.2 (operational) / Cl. 6.1.2 (process)Mandatory
Status: In progress — drafting
Owner: Head of AI Risk
Version: 0.9 (draft)
Location: AIMS GRC Repository
Last reviewed: —
Next review: 2026-08-31 (target)
AIMS Control linkage: RSK.AS-01, RSK.AS-03, RSK.RG-01
Purpose
Demonstrates that risk assessment has been performed for each in-scope AI system, applying the methodology in Doc 4.
Required content
Per-AI-system risk assessment with inherent and residual risk; sign-off; reassessment triggers and outcomes; consolidation in the AI risk register.
Audit evidence
Risk register; sampled per-AI assessments; reassessment evidence.
Doc 17AI Risk Treatment Records (per AI system)Cl. 8.3 (operational) / Cl. 6.1.3 (process)Mandatory
Status: In progress — drafting
Owner: Head of AI Risk
Version: 0.9 (draft)
Location: AIMS GRC Repository
Last reviewed: —
Next review: 2026-08-31 (target)
AIMS Control linkage: RSK.TR-01, RSK.TR-02, RSK.TR-03
Purpose
Demonstrates that risk treatments are selected, implemented, accepted (where applicable), and verified per the methodology.
Required content
Treatment selections per identified risk; implementation evidence; residual risk acceptance with appropriate authority; effectiveness verification.
Audit evidence
Treatment plan; closure records; acceptance records; verification outcomes.
Doc 18AI System Impact Assessment Records (per AI system)Cl. 8.4 (operational) / Cl. 6.1.4 (process)Mandatory
Status: In progress — drafting
Owner: DPO / AI Impact Lead
Version: 0.9 (draft)
Location: AIMS GRC Repository
Last reviewed: —
Next review: 2026-08-31 (target)
AIMS Control linkage: IMP.IA-01 through IMP.IA-04, IMP.DA-01..03 (DPIA), IMP.MO-01..03
Purpose
Demonstrates that impact assessment has been performed for each in-scope AI system, applying the methodology in Doc 7, including DPIA where GDPR Art. 35 applies.
Required content
Per-AI impact assessment; affected-party analysis; foreseeable misuse; DPIA where applicable; pre-deployment go/no-go decision; post-deployment monitoring outcomes.
Audit evidence
Sampled impact assessments; DPIA records; go/no-go decisions; post-deployment monitoring reports.
Doc 19Monitoring, Measurement, Analysis & Evaluation ResultsCl. 9.1MandatoryStage 1 minimum
Status: Approved & in operation
Owner: AIMS Manager
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-04-15
Next review: 2027-04-15
AIMS Control linkage: GOV.OV-01, GOV.OV-02, GOV.OV-06
Purpose
Demonstrates that the AIMS is measured against its objectives and that performance is evaluated.
Required content
KPI / KRI definitions; measurement records; analysis outcomes; evaluation against AI objectives; reporting to AI governance forums and top management.
Audit evidence
KPI / KRI definition document; measurement records; dashboards; evaluation reports.
Doc 20Internal Audit Programme & ReportsCl. 9.2MandatoryStage 1 minimum
Status: Approved & in operation
Owner: Internal Audit Lead
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-05-15
Next review: 2027-05-15
AIMS Control linkage: GOV.OV-03
Purpose
Demonstrates that the AIMS is subject to planned internal audits covering conformity and effectiveness.
Required content
Annual audit programme; audit scope, criteria, methods; auditor independence and competence; audit reports; follow-up on findings.
Audit evidence
Programme document; completed audit reports; auditor competence evidence; nonconformity records and closure evidence.
Doc 21Management Review RecordsCl. 9.3MandatoryStage 1 minimum
Status: Approved & in operation
Owner: Chief AI Officer
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-01-15
Next review: 2027-01-15
AIMS Control linkage: GOV.OV-05
Purpose
Top management's periodic review of AIMS suitability, adequacy, effectiveness, and alignment with strategic direction.
Required content
Review inputs (per Cl. 9.3.2) — status of actions from prior reviews; changes affecting AIMS; performance and effectiveness; resource needs; opportunities for improvement. Review outputs (per Cl. 9.3.3) — decisions and actions related to continual improvement and any needed changes.
Audit evidence
Minutes of management reviews covering all required inputs and outputs; decisions traceable to subsequent actions.
Doc 22Nonconformity & Corrective Action RegisterCl. 10.2Mandatory
Status: Approved & in operation
Owner: AIMS Manager
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-02-15
Next review: 2027-02-15
AIMS Control linkage: GOV.OV-07
Purpose
Records nonconformities, corrections, root cause analysis, corrective actions, and effectiveness verification.
Required content
Per-nonconformity: description; immediate correction; root cause analysis; corrective action; effectiveness verification; closure.
Audit evidence
Register entries; sampled closure evidence; trend analysis feeding management review.
Doc 23AI System InventoryAnnex A.6.2.2Recommended
Status: Approved & in operation
Owner: Head of AI Governance
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-03-15
Next review: 2027-03-15
AIMS Control linkage: CON.IN-01, CON.IN-02, CON.IN-03, CON.IN-04
Purpose
Records all AI systems and components within the AIMS scope.
Required content
AI products provided externally; AI products consumed from third parties; AI internal-use systems; foundation models (CON.IN-02); agentic systems (CON.IN-03); decommissioning tracking.
Audit evidence
Inventory artefact; maintenance evidence; sampled entries matched to lifecycle artefacts and risk assessments.
Doc 24Per-AI System DocumentationAnnex A.6.2.7, A.6.2.8Recommended
Status: Approved & in operation
Owner: Head of AI Governance
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-04-15
Next review: 2027-04-15
AIMS Control linkage: TRA.TD-01, TRA.TD-02, TRA.TD-03, TRA.MC-01, TRA.MC-02, TRA.IU-01..03
Purpose
Per-AI-system documentation covering design, development, validation, deployment, and operation — including EU AI Act technical documentation where applicable.
Required content
Technical documentation per AI system; model cards; system cards; instructions for use (provider); operational documentation; version maintenance.
Audit evidence
Sampled per-AI documentation packages; EU AI Act Art. 11 / Annex IV evidence where applicable; Art. 53 / Annex XI evidence for GPAI.
Doc 25AI Data Management Procedures & RecordsAnnex A.7Recommended
Status: Approved & in operation
Owner: Head of Data / DPO
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-05-15
Next review: 2027-05-15
AIMS Control linkage: DAT.PO-01 through DAT.LK-03 (full DAT Domain)
Purpose
Procedures governing data for AI systems — provenance, quality, bias, lawful basis, retention, leakage prevention.
Required content
Data governance policy and methodology; per-dataset records (inventory, classification, provenance, quality, bias); GDPR lawful basis records; retention schedules; data minimisation evidence; PETs application records.
Audit evidence
Procedures; data inventory; sampled dataset records; DPIA references; retention evidence.
Doc 26Information to Interested Parties / User-Facing DisclosuresAnnex A.8Recommended
Status: Approved & in operation
Owner: AIMS Manager
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-01-15
Next review: 2027-01-15
AIMS Control linkage: TRA.UD-01 through TRA.UD-04, HUM.UA-01 through HUM.UA-04
Purpose
Records of information provided to users and other interested parties — Art. 50 disclosures, Art. 26(11) deployer disclosures, right-to-explanation responses, contestation outcomes.
Required content
Disclosure templates per Art. 50(1)/(2)/(3)/(4) trigger; Art. 26(11) deployer disclosure; right-to-explanation request log; contestation register; redress records.
Audit evidence
Templates; sampled disclosures in production; request log and response evidence.
Doc 27Third-Party & Supplier Register and AgreementsAnnex A.10Recommended
Status: Approved & in operation
Owner: AIMS Manager
Version: 1.0
Location: AIMS GRC Repository
Last reviewed: 2026-02-15
Next review: 2027-02-15
AIMS Control linkage: TPA.PO-01 through TPA.DR-04 (full TPA Domain)
Purpose
Register of AI vendors, agreements, due diligence outcomes, and ongoing monitoring.
Required content
Vendor register with risk class; due-diligence outcomes per vendor; contractual provisions; shared-responsibility documentation; AI BOM per AI artefact; ongoing monitoring records.
Audit evidence
Register; sampled contracts; due-diligence records; AI BOM; monitoring evidence; serious incident reports to / from vendors where applicable.
Risks
AI Risk Register — 25 placeholder risks across regulatory, model performance, security, third-party, ethical, and reputational categories. Driven by AIMS Risk Register.xlsx in Databases. Inherent → Residual ratings show treatment effect.
Inherent Risk Posture
Total Risks
25
Critical
3
High
10
Medium
12
Low
0
Residual Risk Posture
Residual — Total
25
Residual — Critical
0
Residual — High
0
Residual — Medium
18
Residual — Low
7
Risk Detail 25
Sorted by Inherent Score (highest first). Click any risk to expand.
AIR11Shadow AI usage by employeesHuman / Data Security→
Owner: CISO
Treatment: Treat
Status: Open
Last reviewed: 2026-06-22
Next review: 2026-09-20
Category: Human / Data Security
Description
Staff use unsanctioned consumer AI tools (e.g. public chatbots) for work, leaking customer or internal data outside the controlled boundary. Pairs with ISMS DLP / acceptable-use programme.
Inherent
Likelihood: 4 · Impact: 4 · Score: 16 · Rating: Critical
Residual
Likelihood: 2 · Impact: 3 · Score: 6 · Rating: Medium
Controls applied (Library)
GOV.AU-01, GOV.AU-02, GOV.AU-03, GOV.ET-02
AIR01EU AI Act GPAI obligations non-complianceRegulatory→
Owner: Head of AI Governance
Treatment: Treat
Status: Open
Last reviewed: 2026-06-22
Next review: 2026-09-20
Category: Regulatory
Description
As a provider developing foundation models, fail to meet Article 55 GPAI obligations: technical documentation, downstream-provider information, copyright compliance policy, summary of training data. Could result in market access restriction or financial penalty up to 3% global turnover.
Inherent
Likelihood: 3 · Impact: 5 · Score: 15 · Rating: Critical
Residual
Likelihood: 2 · Impact: 4 · Score: 8 · Rating: Medium
Controls applied (Library)
IMP.GP-01, IMP.GP-02, TPA.GP-01, TRA.TD-01, DAT.PR-01
AIR03Training data IP infringement claimLegal→
Owner: General Counsel
Treatment: Treat
Status: Open
Last reviewed: 2026-06-22
Next review: 2026-09-20
Category: Legal
Description
Foundation model trained on web-scraped data containing copyrighted material. Rights-holder litigation or DSM Directive Article 4 opt-out claim materialises.
Inherent
Likelihood: 3 · Impact: 5 · Score: 15 · Rating: Critical
Residual
Likelihood: 2 · Impact: 4 · Score: 8 · Rating: Medium
Controls applied (Library)
DAT.PR-01, DAT.PR-02, DAT.PO-01, CON.JU-01
AIR04Production model drift undetectedModel Performance→
Owner: Head of ML Engineering
Treatment: Treat
Status: Open
Last reviewed: 2026-06-22
Next review: 2026-09-20
Category: Model Performance
Description
Deployed model accuracy degrades over time (data distribution shift, concept drift) without detection. Leads to incorrect outputs reaching customers.
Inherent
Likelihood: 4 · Impact: 3 · Score: 12 · Rating: High
Residual
Likelihood: 2 · Impact: 3 · Score: 6 · Rating: Medium
Controls applied (Library)
LIF.OP-01, LIF.OP-02, LIF.VA-01, TRU.AC-01
AIR05Hallucinated outputs reach customerModel Performance→
Owner: Head of Product (AI)
Treatment: Treat
Status: Open
Last reviewed: 2026-06-22
Next review: 2026-09-20
Category: Model Performance
Description
LLM produces plausible but factually incorrect output that influences a customer decision. Trust erosion + downstream liability.
Inherent
Likelihood: 4 · Impact: 3 · Score: 12 · Rating: High
Residual
Likelihood: 3 · Impact: 2 · Score: 6 · Rating: Medium
Controls applied (Library)
TRU.AC-01, HUM.PO-01, TRA.UD-01, TRU.OI-01
AIR06Prompt injection attackSecurity→
Owner: CISO
Treatment: Treat
Status: Open
Last reviewed: 2026-06-22
Next review: 2026-09-20
Category: Security
Description
Adversarial input (direct or indirect prompt injection) causes deployed agent to bypass guardrails, exfiltrate data, or execute unauthorised tool calls.
Inherent
Likelihood: 3 · Impact: 4 · Score: 12 · Rating: High
Residual
Likelihood: 2 · Impact: 3 · Score: 6 · Rating: Medium
Controls applied (Library)
TRU.RB-01, TRU.RB-02, RSK.AR-01, LIF.AG-01
AIR07Sensitive data leakage in model outputData Security→
Owner: CISO
Treatment: Treat
Status: Open
Last reviewed: 2026-06-22
Next review: 2026-09-20
Category: Data Security
Description
Training data memorisation or context-memory bleed causes PII, customer data, or confidential information to leak into model output.
Inherent
Likelihood: 3 · Impact: 4 · Score: 12 · Rating: High
Residual
Likelihood: 2 · Impact: 3 · Score: 6 · Rating: Medium
Controls applied (Library)
DAT.LK-01, DAT.LK-02, TRU.PE-01, DAT.LB-01
AIR13Bias in customer-facing AI outputsEthical / Legal→
Owner: Head of AI Governance
Treatment: Treat
Status: Open
Last reviewed: 2026-06-22
Next review: 2026-09-20
Category: Ethical / Legal
Description
Statistical bias in training or fine-tuning data produces discriminatory outputs in features used by customers (e.g. classification, recommendation). Reputational and legal exposure.
Inherent
Likelihood: 3 · Impact: 4 · Score: 12 · Rating: High
Residual
Likelihood: 2 · Impact: 3 · Score: 6 · Rating: Medium
Controls applied (Library)
TRU.FA-01, TRU.FA-02, DAT.BI-01, IMP.IA-01
AIR24Reputational damage from AI failureReputational→
Owner: Chief Marketing Officer
Treatment: Treat
Status: Open
Last reviewed: 2026-06-22
Next review: 2026-09-20
Category: Reputational
Description
Public AI incident (biased output, security breach, hallucination harming a named customer) damages brand. Media coverage; customer churn.
Inherent
Likelihood: 3 · Impact: 4 · Score: 12 · Rating: High
Residual
Likelihood: 2 · Impact: 3 · Score: 6 · Rating: Medium
Controls applied (Library)
LIF.IR-01, TRU.AC-01, IMP.IA-01
AIR02GDPR Article 22 automated-decision violationLegal→
Owner: DPO
Treatment: Treat
Status: Open
Last reviewed: 2026-06-22
Next review: 2026-09-20
Category: Legal
Description
AI-driven decision affecting customer is made without lawful basis, opt-out path, or meaningful human review under GDPR Art. 22. Risk of regulator action and individual claims.
Inherent
Likelihood: 2 · Impact: 5 · Score: 10 · Rating: High
Residual
Likelihood: 1 · Impact: 4 · Score: 4 · Rating: Low
Controls applied (Library)
HUM.PO-01, HUM.IN-01, HUM.UA-01, DAT.LB-01
AIR14Article 73 serious-incident reporting failureRegulatory→
Owner: CISO
Treatment: Treat
Status: Open
Last reviewed: 2026-06-22
Next review: 2026-09-20
Category: Regulatory
Description
Serious AI incident occurs but is not reported to market surveillance authority within 15-day window under EU AI Act Article 73. Regulator action and reputational damage.
Inherent
Likelihood: 2 · Impact: 5 · Score: 10 · Rating: High
Residual
Likelihood: 1 · Impact: 4 · Score: 4 · Rating: Low
Controls applied (Library)
LIF.IR-01, LIF.IR-02, IMP.MO-01, TRA.LR-01
AIR17Fine-tuning data poisoningSecurity→
Owner: CISO
Treatment: Treat
Status: Open
Last reviewed: 2026-06-22
Next review: 2026-09-20
Category: Security
Description
Malicious actor manipulates fine-tuning dataset to embed backdoor, hidden trigger, or biased behaviour into customer-deployed model.
Inherent
Likelihood: 2 · Impact: 5 · Score: 10 · Rating: High
Residual
Likelihood: 1 · Impact: 4 · Score: 4 · Rating: Low
Controls applied (Library)
DAT.PR-01, DAT.QU-01, LIF.DV-01, TRU.RB-01
AIR21GPAI systemic risk threshold triggerRegulatory→
Owner: Head of AI Governance
Treatment: Treat
Status: Open
Last reviewed: 2026-06-22
Next review: 2026-09-20
Category: Regulatory
Description
In-house foundation model crosses the EU AI Act Article 51 systemic risk threshold (FLOPs or designated criteria). Triggers heightened obligations: model evaluation, adversarial testing, serious incident reporting.
Inherent
Likelihood: 2 · Impact: 5 · Score: 10 · Rating: High
Residual
Likelihood: 2 · Impact: 4 · Score: 8 · Rating: Medium
Controls applied (Library)
TPA.GP-01, IMP.GP-01, IMP.GP-02, RSK.AR-01
AIR08Multi-agent orchestration cascading failureOperational→
Owner: Head of ML Engineering
Treatment: Treat
Status: Open
Last reviewed: 2026-06-22
Next review: 2026-09-20
Category: Operational
Description
One agent error or misjudgement propagates through an orchestrated agent system, causing systemic failure or amplified incorrect action.
Inherent
Likelihood: 3 · Impact: 3 · Score: 9 · Rating: Medium
Residual
Likelihood: 2 · Impact: 3 · Score: 6 · Rating: Medium
Controls applied (Library)
LIF.AG-01, LIF.AG-02, LIF.OP-01, TRU.RE-01
AIR09Foundation model vendor outageThird-Party→
Owner: Head of Vendor Management
Treatment: Treat
Status: Open
Last reviewed: 2026-06-22
Next review: 2026-09-20
Category: Third-Party
Description
Critical foundation model API provider experiences extended outage. Customer-facing AI services degrade or fail.
Inherent
Likelihood: 3 · Impact: 3 · Score: 9 · Rating: Medium
Residual
Likelihood: 3 · Impact: 2 · Score: 6 · Rating: Medium
Controls applied (Library)
TPA.DD-01, TPA.CT-01, TRU.RE-01
AIR10Foundation model deprecation forcing emergency replatformThird-Party→
Owner: Head of Vendor Management
Treatment: Treat
Status: Open
Last reviewed: 2026-06-22
Next review: 2026-09-20
Category: Third-Party
Description
Vendor sunsets foundation model with insufficient migration notice. Forces emergency model replacement, regression testing, and customer communication.
Inherent
Likelihood: 3 · Impact: 3 · Score: 9 · Rating: Medium
Residual
Likelihood: 2 · Impact: 3 · Score: 6 · Rating: Medium
Controls applied (Library)
TPA.CT-01, TPA.CT-02, LIF.VR-01, LIF.DC-01
AIR12Token cost runawayOperational / Financial→
Owner: Head of ML Engineering
Treatment: Treat
Status: Open
Last reviewed: 2026-06-22
Next review: 2026-09-20
Category: Operational / Financial
Description
Unbounded LLM API calls (agent loop, attack, runaway batch job) cause unexpected cost spike. Budget overrun and possible service throttling.
Inherent
Likelihood: 3 · Impact: 3 · Score: 9 · Rating: Medium
Residual
Likelihood: 2 · Impact: 2 · Score: 4 · Rating: Low
Controls applied (Library)
LIF.OP-01, LIF.AG-02, TPA.CT-01
AIR15AI output warranty over-commitmentCommercial→
Owner: General Counsel
Treatment: Treat
Status: Open
Last reviewed: 2026-06-22
Next review: 2026-09-20
Category: Commercial
Description
Customer contracts include AI output accuracy or performance warranties that cannot be substantiated. Exposure to claims and SLA penalties.
Inherent
Likelihood: 3 · Impact: 3 · Score: 9 · Rating: Medium
Residual
Likelihood: 2 · Impact: 3 · Score: 6 · Rating: Medium
Controls applied (Library)
TPA.CT-01, TRA.UD-01, TRA.IU-01
AIR18Loss of model explainabilityTrust / Regulatory→
Owner: Head of AI Governance
Treatment: Treat
Status: Open
Last reviewed: 2026-06-22
Next review: 2026-09-20
Category: Trust / Regulatory
Description
Decisions made by deployed model cannot be explained to customers or regulators to a sufficient standard, undermining trust and audit defensibility.
Inherent
Likelihood: 3 · Impact: 3 · Score: 9 · Rating: Medium
Residual
Likelihood: 2 · Impact: 3 · Score: 6 · Rating: Medium
Controls applied (Library)
TRU.EX-01, TRA.TD-01, TRA.MC-01
AIR19Article 4 AI literacy obligation gapRegulatory / Human→
Owner: Head of HR
Treatment: Treat
Status: Open
Last reviewed: 2026-06-22
Next review: 2026-09-20
Category: Regulatory / Human
Description
Staff training does not meet EU AI Act Article 4 AI literacy obligations. Auditor finding; corrective programme cost.
Inherent
Likelihood: 3 · Impact: 3 · Score: 9 · Rating: Medium
Residual
Likelihood: 2 · Impact: 2 · Score: 4 · Rating: Low
Controls applied (Library)
GOV.CO-01, GOV.CO-02, HUM.CM-01
AIR20MCP tool misuse by agentSecurity / Operational→
Owner: Head of ML Engineering
Treatment: Treat
Status: Open
Last reviewed: 2026-06-22
Next review: 2026-09-20
Category: Security / Operational
Description
Agent calls Model Context Protocol tool with parameters that exceed its authorisation envelope (e.g. destructive op, scope escalation, sensitive read).
Inherent
Likelihood: 3 · Impact: 3 · Score: 9 · Rating: Medium
Residual
Likelihood: 2 · Impact: 3 · Score: 6 · Rating: Medium
Controls applied (Library)
LIF.AG-01, LIF.AG-02, TPA.AT-02, TPA.AT-04
AIR22Audit reconstruction logging gapRegulatory / Operational→
Owner: CISO
Treatment: Treat
Status: Open
Last reviewed: 2026-06-22
Next review: 2026-09-20
Category: Regulatory / Operational
Description
AI system decisions cannot be reconstructed at audit due to inadequate logging (input, prompt, model version, output, timestamp). Auditor finding.
Inherent
Likelihood: 3 · Impact: 3 · Score: 9 · Rating: Medium
Residual
Likelihood: 2 · Impact: 3 · Score: 6 · Rating: Medium
Controls applied (Library)
TRA.LR-01, TRA.AG-01, LIF.OP-01
AIR23Inadequate human oversight on AI decisionsRegulatory / Ethical→
Owner: Head of AI Governance
Treatment: Treat
Status: Open
Last reviewed: 2026-06-22
Next review: 2026-09-20
Category: Regulatory / Ethical
Description
Decisions made by customer-facing AI lack a meaningful human review path required by GDPR Art. 22 / AI Act Article 14 (where applicable to limited-risk transparency obligations).
Inherent
Likelihood: 3 · Impact: 3 · Score: 9 · Rating: Medium
Residual
Likelihood: 2 · Impact: 3 · Score: 6 · Rating: Medium
Controls applied (Library)
HUM.PO-01, HUM.CO-01, HUM.IN-01
AIR16Customer misuse in EU AI Act High-Risk use caseRegulatory→
Owner: General Counsel
Treatment: Tolerate (contractual)
Status: Open
Last reviewed: 2026-06-22
Next review: 2026-09-20
Category: Regulatory
Description
Customer deploys our product in an EU AI Act High-Risk use case (Annex III) contrary to our terms of use. Provider obligations under Article 25 may attach. Treatment: strong contractual + monitoring + termination right.
Inherent
Likelihood: 2 · Impact: 4 · Score: 8 · Rating: Medium
Residual
Likelihood: 1 · Impact: 4 · Score: 4 · Rating: Low
Controls applied (Library)
TPA.DR-01, TPA.CT-01, CON.JU-01, TRA.IU-01
AIR25AI vendor ethical / legal stance reversalStrategic→
Owner: Head of AI Governance
Treatment: Treat
Status: Open
Last reviewed: 2026-06-22
Next review: 2026-09-20
Category: Strategic
Description
Foundation model vendor adopts a position misaligned with company values or customer commitments (e.g. military-use, weakened safety stance, hostile regulatory posture). Forces emergency vendor reassessment.
Inherent
Likelihood: 2 · Impact: 3 · Score: 6 · Rating: Medium
Residual
Likelihood: 2 · Impact: 2 · Score: 4 · Rating: Low
Controls applied (Library)
TPA.DD-01, TPA.DD-03, TPA.PO-01, GOV.ET-01
Actions
AI Risk Treatment Action Register — 39 actions derived from the 25 treated risks. Driven by AIMS Actions Register.xlsx. Each action cites the parent Risk and verified Library Controls.
By Priority
Total Actions
39
Critical
8
High
17
Medium
14
Low
0
By Status
Not Started
39
In Progress
0
Blocked
0
Complete
0
Action Detail 39
Sorted by Priority (Critical first), then Action ID. Click any action to expand.
AIA01Draft GPAI technical documentation per Art. 53AIR01CriticalNot started
Owner: Head of AI Governance
Linked Risk: AIR01
Priority: Critical
Status: Not started
Created: 2026-06-22
Target Date: 2026-10-20
Last Updated: 2026-06-22
Library Controls: TRA.TD-01
AIA02Implement training-data summary publication processAIR01CriticalNot started
Owner: Head of AI Governance
Linked Risk: AIR01
Priority: Critical
Status: Not started
Created: 2026-06-22
Target Date: 2026-11-19
Last Updated: 2026-06-22
Library Controls: DAT.PR-01, IMP.GP-01
AIA03Establish copyright compliance + TDM opt-out policyAIR01CriticalNot started
Owner: General Counsel
Linked Risk: AIR01
Priority: Critical
Status: Not started
Created: 2026-06-22
Target Date: 2026-09-20
Last Updated: 2026-06-22
Library Controls: CON.JU-01, IMP.GP-02
AIA06Document data provenance + lineage for all training datasetsAIR03CriticalNot started
Owner: General Counsel
Linked Risk: AIR03
Priority: Critical
Status: Not started
Created: 2026-06-22
Target Date: 2026-10-20
Last Updated: 2026-06-22
Library Controls: DAT.PR-01, DAT.PR-02
AIA07TDM opt-out check gate before data ingestAIR03CriticalNot started
Owner: General Counsel
Linked Risk: AIR03
Priority: Critical
Status: Not started
Created: 2026-06-22
Target Date: 2026-09-20
Last Updated: 2026-06-22
Library Controls: CON.JU-01, DAT.PO-01
AIA20Publish AI Acceptable Use PolicyAIR11CriticalNot started
Owner: CISO
Linked Risk: AIR11
Priority: Critical
Status: Not started
Created: 2026-06-22
Target Date: 2026-08-21
Last Updated: 2026-06-22
Library Controls: GOV.AU-01
AIA21DLP / proxy block on unsanctioned consumer AI services via ISMSAIR11CriticalNot started
Owner: CISO
Linked Risk: AIR11
Priority: Critical
Status: Not started
Created: 2026-06-22
Target Date: 2026-09-20
Last Updated: 2026-06-22
Library Controls: GOV.AU-02
AIA22Provide sanctioned AI alternatives + employee onboardingAIR11CriticalNot started
Owner: CISO
Linked Risk: AIR11
Priority: Critical
Status: Not started
Created: 2026-06-22
Target Date: 2026-09-20
Last Updated: 2026-06-22
Library Controls: GOV.AU-03, GOV.ET-02
AIA04Implement human-review path for automated decisionsAIR02HighNot started
Owner: DPO
Linked Risk: AIR02
Priority: High
Status: Not started
Created: 2026-06-22
Target Date: 2026-12-19
Last Updated: 2026-06-22
Library Controls: HUM.PO-01, HUM.IN-01
AIA05Lawful-basis register for AI-driven personal-data processingAIR02HighNot started
Owner: DPO
Linked Risk: AIR02
Priority: High
Status: Not started
Created: 2026-06-22
Target Date: 2026-09-20
Last Updated: 2026-06-22
Library Controls: DAT.LB-01
AIA08Deploy drift detection in production model monitoringAIR04HighNot started
Owner: Head of ML Engineering
Linked Risk: AIR04
Priority: High
Status: Not started
Created: 2026-06-22
Target Date: 2026-09-20
Last Updated: 2026-06-22
Library Controls: LIF.OP-01, LIF.OP-02
AIA09Quarterly model-performance review against accuracy baselinesAIR04HighNot started
Owner: Head of ML Engineering
Linked Risk: AIR04
Priority: High
Status: Not started
Created: 2026-06-22
Target Date: 2026-08-21
Last Updated: 2026-06-22
Library Controls: LIF.VA-01, TRU.AC-01
AIA10Implement output disclaimer + confidence signal in user-facing featuresAIR05HighNot started
Owner: Head of Product (AI)
Linked Risk: AIR05
Priority: High
Status: Not started
Created: 2026-06-22
Target Date: 2026-10-20
Last Updated: 2026-06-22
Library Controls: TRA.UD-01, TRU.OI-01
AIA11Require human-in-loop for high-stakes generative outputsAIR05HighNot started
Owner: Head of Product (AI)
Linked Risk: AIR05
Priority: High
Status: Not started
Created: 2026-06-22
Target Date: 2026-09-20
Last Updated: 2026-06-22
Library Controls: HUM.PO-01
AIA12Implement input sanitisation + guardrail layer for production agentsAIR06HighNot started
Owner: CISO
Linked Risk: AIR06
Priority: High
Status: Not started
Created: 2026-06-22
Target Date: 2026-09-20
Last Updated: 2026-06-22
Library Controls: TRU.RB-01, TRU.RB-02
AIA13Adversarial / red-team testing in pre-deployment validationAIR06HighNot started
Owner: CISO
Linked Risk: AIR06
Priority: High
Status: Not started
Created: 2026-06-22
Target Date: 2026-10-20
Last Updated: 2026-06-22
Library Controls: RSK.AR-01, LIF.AG-01
AIA14Deploy DLP rules on AI output channelsAIR07HighNot started
Owner: CISO
Linked Risk: AIR07
Priority: High
Status: Not started
Created: 2026-06-22
Target Date: 2026-09-20
Last Updated: 2026-06-22
Library Controls: DAT.LK-01
AIA15PII filtering layer on training and fine-tuning dataAIR07HighNot started
Owner: CISO
Linked Risk: AIR07
Priority: High
Status: Not started
Created: 2026-06-22
Target Date: 2026-10-20
Last Updated: 2026-06-22
Library Controls: DAT.LK-02, TRU.PE-01
AIA24Bias measurement framework + quarterly fairness evaluationsAIR13HighNot started
Owner: Head of AI Governance
Linked Risk: AIR13
Priority: High
Status: Not started
Created: 2026-06-22
Target Date: 2026-10-20
Last Updated: 2026-06-22
Library Controls: TRU.FA-01, TRU.FA-02
AIA25Diverse, representative evaluation test setsAIR13HighNot started
Owner: Head of AI Governance
Linked Risk: AIR13
Priority: High
Status: Not started
Created: 2026-06-22
Target Date: 2026-11-19
Last Updated: 2026-06-22
Library Controls: DAT.BI-01, IMP.IA-01
AIA26AI incident response playbook with Art. 73 15-day clockAIR14HighNot started
Owner: CISO
Linked Risk: AIR14
Priority: High
Status: Not started
Created: 2026-06-22
Target Date: 2026-09-20
Last Updated: 2026-06-22
Library Controls: LIF.IR-01, LIF.IR-02
AIA27AI incident severity classification + escalation matrixAIR14HighNot started
Owner: CISO
Linked Risk: AIR14
Priority: High
Status: Not started
Created: 2026-06-22
Target Date: 2026-09-20
Last Updated: 2026-06-22
Library Controls: LIF.IR-02, IMP.MO-01
AIA31Training-data integrity validation pipeline + signed datasetsAIR17HighNot started
Owner: CISO
Linked Risk: AIR17
Priority: High
Status: Not started
Created: 2026-06-22
Target Date: 2026-10-20
Last Updated: 2026-06-22
Library Controls: DAT.PR-01, DAT.QU-01, LIF.DV-01
AIA35Compute threshold monitoring + Article 51 systemic-risk readiness reviewAIR21HighNot started
Owner: Head of AI Governance
Linked Risk: AIR21
Priority: High
Status: Not started
Created: 2026-06-22
Target Date: 2026-11-19
Last Updated: 2026-06-22
Library Controls: TPA.GP-01, IMP.GP-01, RSK.AR-01
AIA38AI incident communications playbook + Board notification templateAIR24HighNot started
Owner: Chief Marketing Officer
Linked Risk: AIR24
Priority: High
Status: Not started
Created: 2026-06-22
Target Date: 2026-09-20
Last Updated: 2026-06-22
Library Controls: LIF.IR-01, IMP.IA-01
AIA16Document agent boundary + authorisation policyAIR08MediumNot started
Owner: Head of ML Engineering
Linked Risk: AIR08
Priority: Medium
Status: Not started
Created: 2026-06-22
Target Date: 2026-11-19
Last Updated: 2026-06-22
Library Controls: LIF.AG-01, LIF.AG-02
AIA17Per-agent failure isolation + chaos testingAIR08MediumNot started
Owner: Head of ML Engineering
Linked Risk: AIR08
Priority: Medium
Status: Not started
Created: 2026-06-22
Target Date: 2026-12-19
Last Updated: 2026-06-22
Library Controls: TRU.RE-01
AIA18Multi-vendor failover capability for critical foundation model pathsAIR09MediumNot started
Owner: Head of Vendor Management
Linked Risk: AIR09
Priority: Medium
Status: Not started
Created: 2026-06-22
Target Date: 2026-12-19
Last Updated: 2026-06-22
Library Controls: TRU.RE-01, TPA.CT-01
AIA19Vendor model-lifecycle tracking register + migration plan templateAIR10MediumNot started
Owner: Head of Vendor Management
Linked Risk: AIR10
Priority: Medium
Status: Not started
Created: 2026-06-22
Target Date: 2026-10-20
Last Updated: 2026-06-22
Library Controls: LIF.VR-01, TPA.CT-02
AIA23Token rate-limit per agent / per user + alert thresholdsAIR12MediumNot started
Owner: Head of ML Engineering
Linked Risk: AIR12
Priority: Medium
Status: Not started
Created: 2026-06-22
Target Date: 2026-08-21
Last Updated: 2026-06-22
Library Controls: LIF.AG-02, LIF.OP-01
AIA28Standardise AI output warranty + limitation language in customer contractsAIR15MediumNot started
Owner: General Counsel
Linked Risk: AIR15
Priority: Medium
Status: Not started
Created: 2026-06-22
Target Date: 2026-10-20
Last Updated: 2026-06-22
Library Controls: TPA.CT-01, TRA.UD-01
AIA29AUP / ToS clause restricting EU AI Act High-Risk use casesAIR16MediumNot started
Owner: General Counsel
Linked Risk: AIR16
Priority: Medium
Status: Not started
Created: 2026-06-22
Target Date: 2026-09-20
Last Updated: 2026-06-22
Library Controls: TPA.CT-01, CON.JU-01
AIA30Use-case attestation in customer onboarding flowAIR16MediumNot started
Owner: General Counsel
Linked Risk: AIR16
Priority: Medium
Status: Not started
Created: 2026-06-22
Target Date: 2026-10-20
Last Updated: 2026-06-22
Library Controls: TPA.DR-01, TRA.IU-01
AIA32Publish model cards + system cards for all deployed modelsAIR18MediumNot started
Owner: Head of AI Governance
Linked Risk: AIR18
Priority: Medium
Status: Not started
Created: 2026-06-22
Target Date: 2026-11-19
Last Updated: 2026-06-22
Library Controls: TRA.MC-01, TRA.TD-01
AIA33Roll out AI literacy training programme (Art. 4 compliant)AIR19MediumNot started
Owner: Head of HR
Linked Risk: AIR19
Priority: Medium
Status: Not started
Created: 2026-06-22
Target Date: 2026-12-19
Last Updated: 2026-06-22
Library Controls: GOV.CO-01, GOV.CO-02, HUM.CM-01
AIA34MCP tool allow-list + scope-of-authority review processAIR20MediumNot started
Owner: Head of ML Engineering
Linked Risk: AIR20
Priority: Medium
Status: Not started
Created: 2026-06-22
Target Date: 2026-09-20
Last Updated: 2026-06-22
Library Controls: LIF.AG-01, TPA.AT-02, TPA.AT-04
AIA36Comprehensive AI decision logging (input / prompt / model / output / timestamp)AIR22MediumNot started
Owner: CISO
Linked Risk: AIR22
Priority: Medium
Status: Not started
Created: 2026-06-22
Target Date: 2026-10-20
Last Updated: 2026-06-22
Library Controls: TRA.LR-01, TRA.AG-01, LIF.OP-01
AIA37Document human-AI configuration + oversight patterns per systemAIR23MediumNot started
Owner: Head of AI Governance
Linked Risk: AIR23
Priority: Medium
Status: Not started
Created: 2026-06-22
Target Date: 2026-11-19
Last Updated: 2026-06-22
Library Controls: HUM.PO-01, HUM.CO-01
AIA39Annual vendor ethical / legal posture review processAIR25MediumNot started
Owner: Head of AI Governance
Linked Risk: AIR25
Priority: Medium
Status: Not started
Created: 2026-06-22
Target Date: 2026-12-19
Last Updated: 2026-06-22
Library Controls: TPA.DD-01, TPA.DD-03, GOV.ET-01
Policies
AIMS Policy Register — 12 policy documents anchored to the policy Objectives in the Library (one per policy Objective). Sorted by status urgency.
Total Policies
12
Approved
0
In Review
0
Drafting
7
Not started
5
Policy Detail 12
POL03AI Ethics Code of Conductv0.1Not startedHead of AI Governance
Owner: Head of AI Governance
Version: v0.1
Status: Not started
Last Reviewed: —
Next Review: 2026-10-21
Linked Doc: —
Library Controls: GOV.ET-01, GOV.ET-02, GOV.ET-03, GOV.ET-04
Notes: Public-facing ethics commitments. Should align with OECD AI Principles.
POL04AI Risk Appetite Statementv0.1Not startedCISO
Owner: CISO
Version: v0.1
Status: Not started
Last Reviewed: —
Next Review: 2026-09-21
Linked Doc: ISO 42001 Doc 4 (related)
Library Controls: GOV.RA-01, GOV.RA-02, GOV.RA-03, GOV.RA-04
Notes: Board-approved risk appetite for AI use. Sets thresholds for risk acceptance.
POL08Trustworthy AI Policyv0.1Not startedHead of AI Governance
Owner: Head of AI Governance
Version: v0.1
Status: Not started
Last Reviewed: —
Next Review: 2026-10-21
Linked Doc: —
Library Controls: TRU.PO-01, TRU.PO-02, TRU.PO-03
Notes: Accuracy, fairness, robustness, safety, explainability targets per AI system class.
POL09Human Oversight Policyv0.1Not startedHead of AI Governance
Owner: Head of AI Governance
Version: v0.1
Status: Not started
Last Reviewed: —
Next Review: 2026-09-21
Linked Doc: —
Library Controls: HUM.PO-01, HUM.PO-02, HUM.PO-03
Notes: Required oversight modes for AI outputs by use case. Joins to GDPR Art. 22 review path.
POL10AI Transparency Policyv0.1Not startedHead of AI Governance
Owner: Head of AI Governance
Version: v0.1
Status: Not started
Last Reviewed: —
Next Review: 2026-09-21
Linked Doc: —
Library Controls: TRA.PO-01, TRA.PO-02
Notes: Customer-facing AI disclosure, documentation, model cards, content labelling.
POL01AI Policy (top-level)v0.1DraftingHead of AI Governance
Owner: Head of AI Governance
Version: v0.1
Status: Drafting
Last Reviewed: 2026-06-16
Next Review: 2026-09-21
Linked Doc: ISO 42001 Doc 2 (AI Policy)
Library Controls: GOV.PO-01, GOV.PO-02, GOV.PO-03, GOV.PO-04
Notes: Anchor policy required by ISO 42001 Cl. 5.2. Sets organisational AI commitments.
POL02AI Acceptable Use Policyv0.1DraftingCISO
Owner: CISO
Version: v0.1
Status: Drafting
Last Reviewed: 2026-06-09
Next Review: 2026-08-22
Linked Doc: ISO 42001 Doc 9 (related)
Library Controls: GOV.AU-01, GOV.AU-02, GOV.AU-03
Notes: Approved-tool list, shadow-AI prohibition, sanctioned alternatives. Pairs with ISMS DLP / acceptable-use programme.
POL05AI Risk Management Policyv0.1DraftingHead of AI Governance
Owner: Head of AI Governance
Version: v0.1
Status: Drafting
Last Reviewed: 2026-06-02
Next Review: 2026-08-22
Linked Doc: ISO 42001 Doc 4 (AI Risk Assessment Methodology)
Library Controls: RSK.ME-01, RSK.ME-02, RSK.ME-03, RSK.ME-04
Notes: Risk methodology, scoring, treatment workflow. Drives the Risks Register tab.
POL06AI Data Governance Policyv0.1DraftingDPO
Owner: DPO
Version: v0.1
Status: Drafting
Last Reviewed: 2026-06-13
Next Review: 2026-09-06
Linked Doc: ISO 42001 Doc 11 (related)
Library Controls: DAT.PO-01, DAT.PO-02, DAT.PO-03
Notes: Data provenance, quality, bias, lawful basis, retention. Joins to PIMS data governance.
POL07AI Lifecycle Policyv0.1DraftingHead of ML Engineering
Owner: Head of ML Engineering
Version: v0.1
Status: Drafting
Last Reviewed: 2026-06-18
Next Review: 2026-09-21
Linked Doc: —
Library Controls: LIF.PO-01, LIF.PO-02, LIF.PO-03
Notes: Design, develop, train, validate, deploy, operate, decommission. Includes agentic system patterns.
POL11Third-Party AI Policyv0.1DraftingHead of Vendor Management
Owner: Head of Vendor Management
Version: v0.1
Status: Drafting
Last Reviewed: 2026-06-09
Next Review: 2026-09-06
Linked Doc: ISO 42001 Doc 16 (related)
Library Controls: TPA.PO-01, TPA.PO-02
Notes: Provider obligations, contractual requirements, due diligence, supply chain, agentic tool controls.
POL12AI Incident Response Policyv0.1DraftingCISO
Owner: CISO
Version: v0.1
Status: Drafting
Last Reviewed: 2026-06-16
Next Review: 2026-08-22
Linked Doc: ISO 42001 Doc 24 (related)
Library Controls: LIF.IR-01, LIF.IR-02, LIF.IR-03
Notes: Detection, triage, Art. 73 15-day clock, escalation matrix, Board notification path.
AI Inventory
AI Inventory and Portfolio — 12 AI systems across provider, deployer and internal-developer roles. Anchored to CON.IN-01..04 controls and ISO 42001 Cl. 4.4 scope obligations. Tri-role tech/SaaS B2B.
Total Systems
12
Provider (external)
3
Deployer (internal use)
5
Internal Developer
3
GPAI Linked
10
By Status
Production
11
Development
1
Sunsetting
0
Retired
0
AI System Detail 12
Sorted by Role (Provider first), then ID. Click any system to expand.
AIS01Customer-Facing AI AssistantProviderProduction
Role: Provider
Status: Production
Owner: Head of Product (AI)
AI Act Risk Tier: Limited (Art. 50 transparency)
GPAI Status: Deployer of GPAI (Claude API)
Foundation Model: Anthropic (VND01)
Description: In-product conversational assistant available to all paying customers. Generative answers grounded in customer-tenant data via RAG.
Linked Risks: AIR05, AIR06, AIR07, AIR23
Library Controls: TRU.AC-01, TRU.OI-01, TRA.UD-01, HUM.PO-01, LIF.OP-01
Notes: Highest-volume customer-facing AI surface. Subject to all provider obligations.
AIS02AI-Powered Search & RecommendationsProviderProduction
Role: Provider
Status: Production
Owner: Head of Product (AI)
AI Act Risk Tier: Minimal
GPAI Status: Component model (embeddings)
Foundation Model: Embeddings Provider (VND06)
Description: In-product semantic search and content recommendations using embeddings + reranking.
Linked Risks: AIR04, AIR07, AIR13
Library Controls: TRU.AC-01, TRU.FA-01, DAT.BI-01, LIF.OP-01
Notes: Embedded silently in product. Limited surface but bias risk material.
AIS03Customer Insights AIProviderProduction
Role: Provider
Status: Production
Owner: Head of Product (AI)
AI Act Risk Tier: Minimal
GPAI Status: Deployer of GPAI (Claude API)
Foundation Model: Anthropic (VND01)
Description: Analytics surface generating natural-language summaries of customer-tenant activity.
Linked Risks: AIR05, AIR07
Library Controls: TRU.AC-01, TRA.UD-01, DAT.LK-01
Notes: Lower stakes but generative — hallucination disclaimers required.
AIS10Multi-Agent Orchestration PlatformDeployer / Internal DeveloperProduction
Role: Deployer / Internal Developer
Status: Production
Owner: Head of ML Engineering
AI Act Risk Tier: Minimal
GPAI Status: Deployer of GPAI (Claude API) + agentic
Foundation Model: Anthropic (VND01) + MCP Tool Providers (VND07, VND08)
Description: Internal platform orchestrating Claude-based agents across internal workflows. Tool calls to MCP servers.
Linked Risks: AIR06, AIR08, AIR12, AIR20
Library Controls: LIF.AG-01, LIF.AG-02, LIF.AG-03, LIF.OP-01, TPA.AT-02, TPA.AT-04
Notes: Agentic system — under heightened scope per LIF.AG and TPA.AT controls.
AIS08In-House Fine-Tuned Domain ModelInternal DeveloperProduction
Role: Internal Developer
Status: Production
Owner: Head of ML Engineering
AI Act Risk Tier: Minimal
GPAI Status: Adapter (not GPAI)
Foundation Model: Open-Weight FM Provider (VND03), fine-tuned in-house
Description: Fine-tuned open-weight model for specific product-feature retrieval task. Trained on de-identified customer-tenant data.
Linked Risks: AIR03, AIR04, AIR13, AIR17
Library Controls: DAT.PR-01, DAT.PR-02, LIF.TR-01, LIF.VA-01, TRU.AC-01
Notes: Fine-tuned base model. License terms tracked under TPA Vendor entry VND03.
AIS09In-House Foundation Model R&DInternal DeveloperDevelopment
Role: Internal Developer
Status: Development
Owner: Head of AI Governance
AI Act Risk Tier: Minimal (research)
GPAI Status: GPAI candidate (training in progress)
Foundation Model: In-house
Description: Internal research and prototyping of foundation-model training and post-training techniques. Not yet production-deployed.
Linked Risks: AIR01, AIR03, AIR17, AIR21
Library Controls: GOV.LD-01, IMP.GP-01, IMP.GP-02, TPA.GP-01, RSK.AR-01, LIF.DV-01
Notes: Compute usage monitored for Art. 51 systemic-risk threshold. Output not in-product.
AIS11Bias & Fairness Evaluation PipelineInternal DeveloperProduction
Role: Internal Developer
Status: Production
Owner: Head of AI Governance
AI Act Risk Tier: N/A (evaluation tool)
GPAI Status: Internal tool (not deployed AI)
Foundation Model: —
Description: Internal evaluation tooling — runs fairness, bias, and accuracy probes against models pre-deployment.
Linked Risks: AIR04, AIR13
Library Controls: TRU.FA-01, TRU.FA-02, DAT.BI-01, LIF.VA-01, IMP.IA-01
Notes: Internal-only. Pairs with AI Evaluation Service vendor (VND09) for third-party validation.
AIS04Internal Sales CopilotDeployerProduction
Role: Deployer
Status: Production
Owner: Head of AI Governance
AI Act Risk Tier: Minimal
GPAI Status: Deployer of GPAI (Claude API)
Foundation Model: Anthropic (VND01)
Description: Internal-use assistant for sales team — call summaries, draft emails, pipeline triage.
Linked Risks: AIR11, AIR07
Library Controls: GOV.AU-01, GOV.AU-03, LIF.OP-01, TPA.DR-01
Notes: Sanctioned internal-use tool. Bound by AI Acceptable Use Policy.
AIS05Internal Support AssistantDeployerProduction
Role: Deployer
Status: Production
Owner: Head of AI Governance
AI Act Risk Tier: Minimal
GPAI Status: Deployer of GPAI (Claude API)
Foundation Model: Anthropic (VND01)
Description: Internal customer-support knowledge assistant — answers staff queries from internal docs.
Linked Risks: AIR07, AIR11
Library Controls: GOV.AU-01, DAT.LK-01, LIF.OP-01
Notes: Operates on internal-only data. PII access controlled.
AIS06Engineering Coding Assistant (Claude Code)DeployerProduction
Role: Deployer
Status: Production
Owner: Head of ML Engineering
AI Act Risk Tier: Minimal
GPAI Status: Deployer of GPAI
Foundation Model: Anthropic (VND01)
Description: Developer-facing AI coding assistant integrated into engineering workflow. Powered by Anthropic's Claude Code.
Linked Risks: AIR07, AIR17, AIR20
Library Controls: GOV.AU-01, LIF.DV-01, TPA.AT-02
Notes: Most-used internal AI tool by engineering. Governs source-code disclosure to vendor.
AIS07Document Summarisation ToolDeployerProduction
Role: Deployer
Status: Production
Owner: Head of AI Governance
AI Act Risk Tier: Minimal
GPAI Status: Deployer of GPAI (Claude API)
Foundation Model: Anthropic (VND01)
Description: Internal tool to summarise long documents (contracts, reports) for staff productivity.
Linked Risks: AIR05, AIR07
Library Controls: GOV.AU-01, DAT.LK-01, TRU.AC-01
Notes: Per-document classification enforced before submission.
AIS12AI-Assisted Code ReviewDeployerProduction
Role: Deployer
Status: Production
Owner: Head of ML Engineering
AI Act Risk Tier: Minimal
GPAI Status: Deployer of GPAI (Claude API)
Foundation Model: Anthropic (VND01)
Description: Automated code-review suggestions integrated into the engineering CI/CD path.
Linked Risks: AIR05, AIR07, AIR12
Library Controls: GOV.AU-01, LIF.DV-01, LIF.OP-01
Notes: Human-reviewed before merge — no auto-merge.
Vendors
AI Vendor Register — 12 third-party AI providers, infrastructure, and tooling consumed. Operationalises the TPA Domain (Third-Party AI). Each vendor cites verified Library Controls and links back to applicable Risks.
By Criticality
Total Vendors
12
Critical
2
High
6
Medium
4
Low
0
By Status
Active
10
Onboarding
2
Sunsetting
0
Retired
0
Vendor Detail 12
Sorted by Criticality (Critical first), then Vendor ID. Click any vendor to expand.
VND01AnthropicFoundation Model ProviderCriticalActive
Category: Foundation Model Provider
Criticality: Critical
Status: Active
Last Due Diligence: 2026-05-23
Next Review: 2026-11-19
Risk Linkage: AIR09, AIR10, AIR05, AIR06
Foundation Model Relationship: API consumer / Deployer of GPAI
AI Service Description
Claude API consumed for production agentic features and customer-facing AI capabilities.
Library Controls
TPA.DD-01, TPA.DD-02, TPA.CT-01, TPA.CT-02, TPA.DR-01, TPA.SC-01
VND04Cloud AI Infrastructure ProviderAI InfrastructureCriticalActive
Category: AI Infrastructure
Criticality: Critical
Status: Active
Last Due Diligence: 2026-05-08
Next Review: 2026-11-04
Risk Linkage: AIR09, AIR12, AIR21
Foundation Model Relationship: Infrastructure provider (no model)
AI Service Description
GPU compute and inference platform for in-house model training and serving.
Library Controls
TPA.DD-01, TPA.CT-01, TPA.SC-01, TPA.SC-03
VND02Foundation Model Provider BFoundation Model ProviderHighActive
Category: Foundation Model Provider
Criticality: High
Status: Active
Last Due Diligence: 2026-04-23
Next Review: 2026-10-20
Risk Linkage: AIR09, AIR10
Foundation Model Relationship: API consumer / Deployer of GPAI
AI Service Description
Alternative closed-weight LLM API for multi-vendor failover and benchmarking across production paths.
Library Controls
TPA.DD-01, TPA.DD-02, TPA.CT-01, TPA.DR-01, TPA.SC-01
VND03Open-Weight Foundation Model ProviderFoundation Model ProviderHighActive
Category: Foundation Model Provider
Criticality: High
Status: Active
Last Due Diligence: 2026-03-24
Next Review: 2026-12-19
Risk Linkage: AIR03, AIR10, AIR17
Foundation Model Relationship: License consumer / In-house fine-tune base
AI Service Description
Open-weight foundation model licensed for fine-tuning and self-hosted inference. Provider relationship for derivative model.
Library Controls
TPA.DD-01, TPA.CT-03, TPA.SC-01, TPA.SC-02, TPA.GP-01
VND05Vector Database VendorAI InfrastructureHighActive
Category: AI Infrastructure
Criticality: High
Status: Active
Last Due Diligence: 2026-04-08
Next Review: 2026-12-04
Risk Linkage: AIR07, AIR09
Foundation Model Relationship: Infrastructure provider (no model)
AI Service Description
Managed vector store used by RAG pipelines for semantic retrieval.
Library Controls
TPA.DD-01, TPA.CT-01, TPA.SC-01, DAT.LK-01
VND07MCP Tool Provider AAgentic Tool (MCP)HighActive
Category: Agentic Tool (MCP)
Criticality: High
Status: Active
Last Due Diligence: 2026-04-23
Next Review: 2026-10-20
Risk Linkage: AIR20, AIR07
Foundation Model Relationship: Tool provider consumed by agents
AI Service Description
Model Context Protocol server providing document and knowledge-base access to internal agents.
Library Controls
TPA.AT-01, TPA.AT-02, TPA.AT-03, TPA.AT-04, TPA.DD-01
VND10Data Labelling VendorData OperationsHighActive
Category: Data Operations
Criticality: High
Status: Active
Last Due Diligence: 2026-04-23
Next Review: 2026-11-19
Risk Linkage: AIR03, AIR13, AIR17
Foundation Model Relationship: Data services provider
AI Service Description
Human annotation and labelling services for training and evaluation datasets.
Library Controls
TPA.DD-01, TPA.CT-01, DAT.LA-01, DAT.LA-02, DAT.LA-03
VND11AI Observability PlatformMonitoring / TelemetryHighActive
Category: Monitoring / Telemetry
Criticality: High
Status: Active
Last Due Diligence: 2026-05-08
Next Review: 2026-11-04
Risk Linkage: AIR04, AIR22
Foundation Model Relationship: Monitoring tooling (no model)
AI Service Description
Production AI observability — model drift detection, prompt and output logging, performance metrics.
Library Controls
TPA.DD-01, TPA.CT-01, LIF.OP-01, TRA.LR-01
VND06Embeddings ProviderAI InfrastructureMediumActive
Category: AI Infrastructure
Criticality: Medium
Status: Active
Last Due Diligence: 2026-03-24
Next Review: 2026-12-19
Risk Linkage: AIR07, AIR13
Foundation Model Relationship: API consumer (component model)
AI Service Description
Embedding model API used for semantic search and similarity ranking.
Library Controls
TPA.DD-01, TPA.CT-01, TPA.DR-01, DAT.LK-01
VND08MCP Tool Provider BAgentic Tool (MCP)MediumOnboarding
Category: Agentic Tool (MCP)
Criticality: Medium
Status: Onboarding
Last Due Diligence: 2026-06-08
Next Review: 2026-09-20
Risk Linkage: AIR20
Foundation Model Relationship: Tool provider consumed by agents
AI Service Description
Model Context Protocol server providing workflow automation and data-system integration tools for agents.
Library Controls
TPA.AT-01, TPA.AT-02, TPA.AT-04, TPA.DD-01
VND09AI Evaluation ServiceAI Safety / Red TeamMediumActive
Category: AI Safety / Red Team
Criticality: Medium
Status: Active
Last Due Diligence: 2026-03-24
Next Review: 2026-12-19
Risk Linkage: AIR06, AIR13, AIR17
Foundation Model Relationship: Service provider (not an AI consumed in product)
AI Service Description
Third-party adversarial testing, bias evaluation, and pre-deployment safety review.
Library Controls
TPA.DD-01, TPA.CT-01, TPA.SC-02
VND12AI Content Provenance ServiceAI Safety / TrustMediumOnboarding
Category: AI Safety / Trust
Criticality: Medium
Status: Onboarding
Last Due Diligence: 2026-06-01
Next Review: 2026-09-20
Risk Linkage: AIR05, AIR18
Foundation Model Relationship: Service provider
AI Service Description
Content watermarking, provenance signing, and AI-generated content authenticity verification.
Library Controls
TPA.DD-01, TPA.CT-01, TRU.OI-01, TRU.OI-02
Audits
AI Management System Audit Register — internal and external audit programme. Anchored against ISO 42001 Cl. 9.2 (Internal Audit). External audits include Stage 1 and Stage 2 certification audits.
Total Audits
8
External
2
Internal
6
Scheduled
8
Audit Schedule 8
External audits listed first, then internal by date. Click any audit to expand.
AUD03ISO 42001 Stage 1 Audit (Readiness Review)External (Certification)2026-12-19Scheduled
Type: External (Certification)
Auditor: External Certification Body
Status: Scheduled
Audit Date: 2026-12-19
Scope: Documentation and readiness review by certification body
Library Controls: GOV.OV-01, GOV.OV-03, CON.SC-01, IMP.IR-01
Notes
Stage 1 (~Q4 2026 / early Q1 2027). Lead Auditor reviews documented information against ISO 42001.
AUD04ISO 42001 Stage 2 Audit (Certification Audit)External (Certification)2027-03-19Scheduled
Type: External (Certification)
Auditor: External Certification Body
Status: Scheduled
Audit Date: 2027-03-19
Scope: Operational effectiveness audit across all AIMS Domains
Library Controls: GOV.OV-01 .. GOV.OV-07, IMP.IR-01, RSK.MO-01, LIF.IR-01
Notes
Stage 2 (~Q2 2027). Operational evidence audit — issues certification on success.
AUD01AIMS Internal Audit — Q3 2026 cycleInternal2026-08-06Scheduled
Type: Internal
Auditor: Internal Audit function
Status: Scheduled
Audit Date: 2026-08-06
Scope: Full AIMS scope review — GOV, CON, RSK Domains
Library Controls: GOV.OV-01, GOV.OV-02, GOV.OV-03, IMP.IR-01
Notes
First full AIMS internal audit. Provides input to Stage 1 audit readiness.
AUD07GDPR / AI Personal-Data Processing AuditInternal2026-09-05Scheduled
Type: Internal
Auditor: DPO function
Status: Scheduled
Audit Date: 2026-09-05
Scope: AI systems processing personal data — lawful basis, Art. 22, DPIA coverage
Library Controls: DAT.LB-01, IMP.DA-01, HUM.PO-01, HUM.UA-01
Notes
Joint with PIMS audit. Confirms AI-specific GDPR obligations met.
AUD05AI Vendor Due Diligence Audit (annual)Internal2026-09-20Scheduled
Type: Internal
Auditor: Procurement + AI Governance
Status: Scheduled
Audit Date: 2026-09-20
Scope: Review of vendor DD records, contract status, ethical posture reviews
Library Controls: TPA.DD-01, TPA.DD-02, TPA.DD-03, TPA.CT-01
Notes
Annual cycle. Confirms all in-scope vendors have current DD and contracts.
AUD06AI Risk Management Effectiveness ReviewInternal2026-10-20Scheduled
Type: Internal
Auditor: Internal Audit function
Status: Scheduled
Audit Date: 2026-10-20
Scope: Effectiveness of AI risk identification, assessment, treatment
Library Controls: RSK.ME-01, RSK.ID-01, RSK.AS-01, RSK.TR-01, RSK.MO-01
Notes
Quarterly review. Output feeds Management Review.
AUD02AIMS Internal Audit — Q4 2026 cycleInternal2026-11-04Scheduled
Type: Internal
Auditor: Internal Audit function
Status: Scheduled
Audit Date: 2026-11-04
Scope: Full AIMS scope review — IMP, DAT, LIF, TRU, HUM, TRA, TPA Domains
Library Controls: GOV.OV-01, GOV.OV-02, IMP.IR-01, RSK.MO-01
Notes
Second cycle. Closes audit coverage of the Library before Stage 1.
AUD08AI Model Evaluation AuditInternal2026-11-19Scheduled
Type: Internal
Auditor: Internal Audit + ML Engineering
Status: Scheduled
Audit Date: 2026-11-19
Scope: Model validation, fairness, accuracy, explainability evaluations
Library Controls: LIF.VA-01, TRU.AC-01, TRU.FA-01, TRU.EX-01, IMP.IA-01
Notes
Reviews evaluation evidence per deployed model. Feeds Trust Domain assurance.
Training
AI Literacy and Competence Register — satisfies EU AI Act Article 4 (AI Literacy) and ISO 42001 Cl. 7.2 (Competence). 10 training programmes across mandatory and recommended audiences.
Total Programmes
10
Mandatory
8
At High Completion (>=90%)
0
Below 50% Completion
10
Training Programmes 10
Sorted Mandatory first, then by ID. Completion % is placeholder until tracking system feeds in.
TRN01AI Literacy — All Staff (EU AI Act Art. 4)All staffMandatory0%
Audience: All staff
Mandatory: Mandatory
Frequency: Annual
Next Run: 2026-08-21
Completion: 0%
Library Controls: GOV.CO-01, GOV.CO-02
Notes
Foundation course. Required by EU AI Act Art. 4 for all employees interacting with AI.
TRN02AI Acceptable Use InductionAll new hiresMandatory0%
Audience: All new hires
Mandatory: Mandatory
Frequency: On hire
Next Run: 2026-07-22
Completion: 0%
Library Controls: GOV.AU-01, GOV.AU-02, GOV.AU-03
Notes
Covers acceptable / unacceptable use, shadow-AI prohibition, sanctioned tool list.
TRN03AI Risk Management TrainingAIMS roles, Risk OwnersMandatory0%
Audience: AIMS roles, Risk Owners
Mandatory: Mandatory
Frequency: Annual
Next Run: 2026-09-20
Completion: 0%
Library Controls: GOV.CO-01, RSK.ME-01, RSK.AS-01
Notes
For staff with AIMS responsibilities. Covers risk methodology, scoring, treatment.
TRN04GDPR + AI ProcessingCustomer-facing teams, Data teamsMandatory0%
Audience: Customer-facing teams, Data teams
Mandatory: Mandatory
Frequency: Annual
Next Run: 2026-09-05
Completion: 0%
Library Controls: GOV.CO-01, DAT.LB-01, IMP.DA-01, HUM.UA-01
Notes
AI-specific GDPR obligations — Art. 22, DPIA triggers, lawful basis.
TRN05EU AI Act OverviewSenior leadership, Legal, SalesMandatory0%
Audience: Senior leadership, Legal, Sales
Mandatory: Mandatory
Frequency: Annual
Next Run: 2026-08-06
Completion: 0%
Library Controls: GOV.CO-01, CON.JU-01
Notes
Provider vs deployer obligations, risk tiers, GPAI obligations, timelines.
TRN06Prompt Safety + Secure AI DevelopmentDevelopers, ML EngineersMandatory0%
Audience: Developers, ML Engineers
Mandatory: Mandatory
Frequency: Annual
Next Run: 2026-08-21
Completion: 0%
Library Controls: GOV.CO-01, LIF.DV-01, TRU.RB-01, TRU.RB-02
Notes
Adversarial prompts, injection defences, secure development patterns.
TRN07AI Incident Response DrillIncident response team, On-callMandatory0%
Audience: Incident response team, On-call
Mandatory: Mandatory
Frequency: Semi-annual
Next Run: 2026-10-20
Completion: 0%
Library Controls: LIF.IR-01, LIF.IR-02, GOV.CO-01
Notes
Tabletop exercise covering Art. 73 reporting clock + escalation matrix.
TRN08Human Oversight CompetenceReviewers, ApproversMandatory0%
Audience: Reviewers, Approvers
Mandatory: Mandatory
Frequency: Annual
Next Run: 2026-09-20
Completion: 0%
Library Controls: HUM.CM-01, HUM.PO-01, HUM.CO-01
Notes
For roles approving AI decisions or overriding outputs. Per ISO 42001 + AI Act Art. 14.
TRN09Adversarial AI / Red-Team AwarenessSecurity team, ML EngineersRecommended0%
Audience: Security team, ML Engineers
Mandatory: Recommended
Frequency: Annual
Next Run: 2026-11-19
Completion: 0%
Library Controls: GOV.CO-01, RSK.AR-01, LIF.DV-01
Notes
Threat model literacy. Pairs with the AI Evaluation Service vendor engagement.
TRN10Foundation Model Vendor + Contract AwarenessProcurement, Legal, Vendor MgmtRecommended0%
Audience: Procurement, Legal, Vendor Mgmt
Mandatory: Recommended
Frequency: Annual
Next Run: 2026-10-05
Completion: 0%
Library Controls: GOV.CO-01, TPA.DD-01, TPA.CT-01, TPA.GP-01
Notes
AI-specific clauses — DPA, GPAI provider terms, deprecation notice, sub-processor stack.
Incidents
AI Incident Register — 5 placeholder incidents. Schema satisfies EU AI Act Article 73 (15-day serious-incident reporting) and ISO 42001 Cl. 10.2 (Nonconformity and corrective action). Linked to AI Inventory systems, parent Risks and Treatment Actions.
Severity Snapshot
Total Incidents
5
Critical
0
High
1
Medium
3
Open / Active
1
Art. 73 Reportable
0
By Status
Open
0
Investigating
0
Contained
1
Resolved
3
Closed
1
Incident Detail 5
Sorted Open first (descending severity), then Resolved / Closed. Click any incident to expand.
INC05Bias signal detected in pre-deployment fairness evaluationBias / FairnessMedium2026-06-04Contained
Category: Bias / Fairness
Severity: Medium
Status: Contained
Date Detected: 2026-06-04
Owner: Head of AI Governance
Art. 73 Reportable: No (pre-deployment, no customer exposure)
Reported Date: —
Reporting Authority: —
Linked Risk: AIR13
Affected AI Systems: AIS08 In-House Fine-Tuned Domain Model
Linked Actions: AIA24, AIA25
Library Controls touched: TRU.FA-01, TRU.FA-02, DAT.BI-01, LIF.VA-01
Root Cause
AIS11 Bias & Fairness Evaluation Pipeline flagged disparate performance across two cohort splits during pre-deployment validation.
Notes
Model deployment paused. Retraining underway with rebalanced dataset. AI Evaluation Service (VND09) engaged for independent fairness audit.
INC03Near-miss: vector store dev environment returned cross-tenant fragment in test queryData leakage (near-miss)High2026-06-11Resolved
Category: Data leakage (near-miss)
Severity: High
Status: Resolved
Date Detected: 2026-06-11
Owner: CISO
Art. 73 Reportable: No (internal test only, no customer exposure)
Reported Date: —
Reporting Authority: —
Linked Risk: AIR07
Affected AI Systems: AIS05 Internal Support Assistant, VND05 Vector Database Vendor
Linked Actions: AIA14, AIA15
Library Controls touched: DAT.LK-01, DAT.LK-02, TPA.SC-01
Root Cause
Tenant filter was not applied in a development namespace during a migration test. Caught by red-team probe before promotion.
Notes
No production exposure. Mandatory tenant-isolation test now in CI/CD gate. Vendor (VND05) notified of the issue; their response documented.
INC02Token cost spike — runaway tool-call loop in agentic platformCost runaway / OperationalMedium2026-05-28Resolved
Category: Cost runaway / Operational
Severity: Medium
Status: Resolved
Date Detected: 2026-05-28
Owner: Head of ML Engineering
Art. 73 Reportable: No
Reported Date: —
Reporting Authority: —
Linked Risk: AIR08, AIR12
Affected AI Systems: AIS10 Multi-Agent Orchestration Platform
Linked Actions: AIA16, AIA23
Library Controls touched: LIF.AG-01, LIF.AG-02, LIF.OP-01
Root Cause
Two agents passed sub-tasks back and forth without convergence — no max-iteration guard on that workflow.
Notes
~3x daily token spend on the affected workflow for ~6 hours before alert fired. Per-agent iteration cap + cost-spike alert deployed same day.
INC01Customer-facing assistant returned incorrect ISO clause referenceHallucinationLow2026-05-11Resolved
Category: Hallucination
Severity: Low
Status: Resolved
Date Detected: 2026-05-11
Owner: Head of Product (AI)
Art. 73 Reportable: No (no harm)
Reported Date: —
Reporting Authority: —
Linked Risk: AIR05
Affected AI Systems: AIS01 Customer-Facing AI Assistant
Linked Actions: AIA10, AIA11
Library Controls touched: TRU.AC-01, TRU.OI-01, LIF.OP-01
Root Cause
RAG retrieval missed the corrected source document — old version retrieved instead of revised text.
Notes
Customer caught the error in review. No customer-facing harm. Triggered re-index of source corpus + disclaimer wording update.
INC04Foundation model API degraded latency for 4 hoursVendor outageMedium2026-06-18Closed
Category: Vendor outage
Severity: Medium
Status: Closed
Date Detected: 2026-06-18
Owner: Head of Vendor Management
Art. 73 Reportable: No
Reported Date: —
Reporting Authority: —
Linked Risk: AIR09
Affected AI Systems: AIS01, AIS03, AIS04, AIS06, AIS07, AIS10, AIS12 (all Claude-API-consuming systems)
Linked Actions: AIA18
Library Controls touched: TPA.DD-01, TPA.CT-01, TRU.RE-01, LIF.OP-01
Root Cause
Upstream incident at Anthropic — confirmed via their status page. P95 latency went from ~2s to ~8s; no errors, no data loss.
Notes
Anthropic service degradation. Failover path to alternative model provider (VND02) was tested mid-incident — worked. Vendor RCA received and filed.
GRC Mapping
Framework cross-walk. Pivots the AIMS Control Library to show which Controls satisfy each Article, Clause, Subcategory or Principle across the regulatory and standards landscape.
Frameworks Mapped
13
Total References Cited
792
Controls with Mappings
301
Total Controls
301
Certification & Regulatory Posture
Per-standard status, issuing body, and next milestone with countdown. Edit the POSTURE_ROWS list in inject_grc_mapping_tab.py to maintain.
Standard
Type
Status
Certificate
Issuer
Issued
Expires
Next Milestone
Countdown
ISO/IEC 42001
Certification
In Progress
—
TBD certification body
—
—
Stage 1 Audit
2026-12-15
2026-12-15
173 days
EU AI Act
Regulation
In Progress
n/a
European Commission
2024-08-02 (in force)
n/a
Art. 50 + new prohibitions live
2026-12-02
2026-12-02
160 days
GDPR
Regulation
In Operation
n/a
National DPA
2018-05-25
n/a
Annual DPIA review cycle
2026-12-31
2026-12-31
189 days
NIS 2
Directive
In Operation
n/a
Member State CSIRT
2024-10-17 (transposed)
n/a
Annual reporting
2027-04-17
2027-04-17
296 days
ISO/IEC 27001
Adjacent ISMS cert
Active
IS 9876543
BSI
2024-09-15
2027-09-14
Year 2 Surveillance
2026-09-15
2026-09-15
82 days
Regulatory & Audit Deadline Calendar
Next 12 months. Edit CALENDAR list to maintain.
Date
Days
Event
Type
2026-08-02
38d
EU AI Act Art. 50 transparency obligations live
Regulatory
2026-09-15
82d
ISMS Year 2 Surveillance Audit
Certification
2026-10-31
128d
AIMS Internal Audit Q3 cycle (AUD01)
Internal Audit
2026-12-02
160d
EU AI Act new Art. 5 prohibitions + generative content marking deadline
Regulatory
2026-12-15
173d
ISO 42001 Stage 1 Audit (target)
Certification
2027-01-15
204d
AIMS Internal Audit Q4 cycle (AUD02)
Internal Audit
2027-03-15
263d
ISO 42001 Stage 2 Audit (target)
Certification
2027-08-02
403d
EU AI Act Member State sandbox deadline
Regulatory
Mappings by Framework
Click any framework to expand. Each Reference row lists the Controls (from AIMS Library) that satisfy it.
ISO 42001183 references · 301 unique Controls
Reference
Controls
Satisfying AIMS Controls
ISO/IEC 42001:2023 — A.10
6
IMP.GP-05TPA.PO-01TPA.SC-01TPA.SC-02TPA.SC-04TPA.AT-03
ISO/IEC 42001:2023 — A.10; A.10.2
3
TPA.DD-01TPA.DD-02TPA.DD-03
ISO/IEC 42001:2023 — A.10; A.10.3
5
TPA.DD-04TPA.CT-01TPA.CT-02TPA.CT-03TPA.CT-04
ISO/IEC 42001:2023 — A.10; A.6.2.6
1
TPA.DR-04
ISO/IEC 42001:2023 — A.10; A.6.2.8
1
LIF.DP-04
ISO/IEC 42001:2023 — A.10; A.7
1
TPA.DR-03
ISO/IEC 42001:2023 — A.10; A.7.4
1
TPA.CT-05
ISO/IEC 42001:2023 — A.10; A.8
3
TPA.GP-01TPA.GP-02TPA.GP-03
ISO/IEC 42001:2023 — A.10; A.8 (sourcing)
1
TPA.SC-03
ISO/IEC 42001:2023 — A.10; A.9
4
TPA.AT-01TPA.AT-02TPA.AT-04TPA.DR-02
ISO/IEC 42001:2023 — A.2.2; A.10
1
GOV.ET-03
ISO/IEC 42001:2023 — A.2.2; A.3.3
2
GOV.ET-02GOV.ET-04
ISO/IEC 42001:2023 — A.2.2; A.6.1.2
1
GOV.ET-01
ISO/IEC 42001:2023 — A.2.2; A.6.2; A.9.3
1
TRU.PO-01
ISO/IEC 42001:2023 — A.3.2
3
GOV.RR-04GOV.GF-02GOV.GF-03
ISO/IEC 42001:2023 — A.3.2; Cl. 9.2
1
GOV.GF-04
ISO/IEC 42001:2023 — A.3.3
1
GOV.RR-05
ISO/IEC 42001:2023 — A.4.3; A.7.3
1
DAT.IN-01
ISO/IEC 42001:2023 — A.4.3; A.7.3; A.7.5
1
DAT.IN-04
ISO/IEC 42001:2023 — A.4.6; A.9
2
HUM.CM-01HUM.CM-02
ISO/IEC 42001:2023 — A.4.6; Cl. 9.1
1
HUM.CM-03
ISO/IEC 42001:2023 — A.4; A.8; A.8.3; A.9
1
CON.IP-04
ISO/IEC 42001:2023 — A.4; A.9; A.9.4
1
GOV.AU-02
ISO/IEC 42001:2023 — A.5.3; A.5.4
1
CON.IP-02
ISO/IEC 42001:2023 — A.5.4; A.3.2
1
IMP.IR-01
ISO/IEC 42001:2023 — A.5.4; Cl. 9.2
1
IMP.IR-02
ISO/IEC 42001:2023 — A.5.4; Cl. 9.2; Cl. 10
1
IMP.IR-03
ISO/IEC 42001:2023 — A.5.4; Cl. 9.3
1
IMP.MO-03
ISO/IEC 42001:2023 — A.5; A.10
1
IMP.ME-02
ISO/IEC 42001:2023 — A.6.1
2
CON.IN-01CON.IN-03
ISO/IEC 42001:2023 — A.6.1.2; A.6.1.3; A.6.2.2; A.6.2.5
1
LIF.DE-03
ISO/IEC 42001:2023 — A.6.1.3; A.6.2.2; A.6.2.3
1
LIF.DE-01
ISO/IEC 42001:2023 — A.6.1; A.6.2
1
LIF.DE-05
ISO/IEC 42001:2023 — A.6.1; A.7
1
CON.IN-02
ISO/IEC 42001:2023 — A.6.1; Cl. 9.1
1
CON.IN-04
ISO/IEC 42001:2023 — A.6.2
2
LIF.VA-06LIF.DC-01
ISO/IEC 42001:2023 — A.6.2.2; A.6.2.3
1
LIF.DE-04
ISO/IEC 42001:2023 — A.6.2.2; A.6.2.4
1
LIF.DE-02
ISO/IEC 42001:2023 — A.6.2.4
1
LIF.DV-04
ISO/IEC 42001:2023 — A.6.2.4; A.4.4; A.4.5
2
LIF.DV-02LIF.TR-02
ISO/IEC 42001:2023 — A.6.2.4; A.6.2.5
2
LIF.DV-01LIF.DV-05
ISO/IEC 42001:2023 — A.6.2.4; A.7.4
1
LIF.TR-04
ISO/IEC 42001:2023 — A.6.2.4; A.7.5
1
LIF.TR-03
ISO/IEC 42001:2023 — A.6.2.5
1
LIF.AG-02
ISO/IEC 42001:2023 — A.6.2.5; A.10
2
LIF.AG-04TRU.OI-04
ISO/IEC 42001:2023 — A.6.2.5; A.6.2.6
1
TRU.SA-01
ISO/IEC 42001:2023 — A.6.2.5; A.6.2.8
1
LIF.VR-04
ISO/IEC 42001:2023 — A.6.2.5; A.7.3
2
LIF.VR-01LIF.VR-02
ISO/IEC 42001:2023 — A.6.2.5; A.7.5
1
TRU.OI-02
ISO/IEC 42001:2023 — A.6.2.5; A.8
2
TRU.OI-01TRU.OI-03
ISO/IEC 42001:2023 — A.6.2.5; A.9
3
LIF.AG-01LIF.AG-03TRU.SA-02
ISO/IEC 42001:2023 — A.6.2.5; A.9.2; A.10
1
TPA.DR-01
ISO/IEC 42001:2023 — A.6.2.6
4
LIF.OP-02LIF.OP-03TRU.RB-04TRU.SA-05
ISO/IEC 42001:2023 — A.6.2.6; A.10
2
LIF.DV-03LIF.IR-04
ISO/IEC 42001:2023 — A.6.2.6; A.4.5
2
TRU.RE-01TRU.RE-02
ISO/IEC 42001:2023 — A.6.2.6; A.6.2.5
1
LIF.OP-04
ISO/IEC 42001:2023 — A.6.2.6; A.6.2.7
6
TRU.AC-04TRU.FA-05TRU.RB-01TRU.SA-03TRA.AG-01TRA.AG-02
ISO/IEC 42001:2023 — A.6.2.6; A.6.2.8
1
LIF.OP-05
ISO/IEC 42001:2023 — A.6.2.6; A.8.3; A.9
1
LIF.IR-02
ISO/IEC 42001:2023 — A.6.2.6; A.9
2
LIF.IR-01LIF.AG-05
ISO/IEC 42001:2023 — A.6.2.6; Cl. 10
1
LIF.IR-03
ISO/IEC 42001:2023 — A.6.2.6; Cl. 10.2
1
LIF.IR-05
ISO/IEC 42001:2023 — A.6.2.6; Cl. 9.1
2
LIF.OP-01TRU.RE-03
ISO/IEC 42001:2023 — A.6.2.7
12
LIF.VA-01LIF.VA-02LIF.VA-03LIF.VA-04LIF.VA-05TRU.AC-01TRU.AC-02TRU.FA-01TRU.FA-02TRU.FA-03TRU.RB-02TRU.RB-03
ISO/IEC 42001:2023 — A.6.2.7; A.5.2
1
TRU.SA-04
ISO/IEC 42001:2023 — A.6.2.7; A.8
1
TRU.FA-04
ISO/IEC 42001:2023 — A.6.2.7; Cl. 9.1
1
TRU.AC-03
ISO/IEC 42001:2023 — A.6.2.8
3
LIF.DP-01LIF.DP-02TRU.EX-03
ISO/IEC 42001:2023 — A.6.2.8; A.6.2.7
1
TRU.EX-02
ISO/IEC 42001:2023 — A.6.2.8; A.8
2
TRU.EX-01TRU.EX-04
ISO/IEC 42001:2023 — A.6.2.8; A.8; A.8.2
2
TRA.MC-01TRA.IU-01
ISO/IEC 42001:2023 — A.6.2; A.10; A.10.4
1
LIF.DC-02
ISO/IEC 42001:2023 — A.6.2; A.5.2
1
IMP.GP-04
ISO/IEC 42001:2023 — A.6.2; A.6.2.7
1
TRU.PO-02
ISO/IEC 42001:2023 — A.6.2; A.7.5
1
LIF.DC-03
ISO/IEC 42001:2023 — A.6.2; A.8
1
IMP.GP-02
ISO/IEC 42001:2023 — A.6.2; Cl. 4.2
1
IMP.GP-03
ISO/IEC 42001:2023 — A.7.2
1
DAT.PO-01
ISO/IEC 42001:2023 — A.7.3
1
DAT.IN-02
ISO/IEC 42001:2023 — A.7.3; A.10
1
DAT.PR-03
ISO/IEC 42001:2023 — A.7.3; A.7.4
1
DAT.SY-02
ISO/IEC 42001:2023 — A.7.3; A.7.4; A.10
1
DAT.PR-01
ISO/IEC 42001:2023 — A.7.3; A.7.5
2
DAT.PR-02LIF.VR-03
ISO/IEC 42001:2023 — A.7.3; A.8
1
DAT.IN-03
ISO/IEC 42001:2023 — A.7.4
9
IMP.DA-02IMP.DA-03DAT.QU-02DAT.QU-03DAT.BI-01DAT.LB-01DAT.LB-04DAT.SY-01DAT.SY-03
ISO/IEC 42001:2023 — A.7.4; A.10
2
DAT.LB-05DAT.LA-03
ISO/IEC 42001:2023 — A.7.4; A.4.6
1
DAT.LA-02
ISO/IEC 42001:2023 — A.7.4; A.5.2
1
IMP.DA-01
ISO/IEC 42001:2023 — A.7.4; A.6.2
5
DAT.LK-01DAT.LK-02DAT.LK-03TRU.PE-01TRU.PE-02
ISO/IEC 42001:2023 — A.7.4; A.6.2.4
1
LIF.TR-01
ISO/IEC 42001:2023 — A.7.4; A.6.2.7
2
DAT.BI-02DAT.BI-03
ISO/IEC 42001:2023 — A.7.4; A.6.2.7; Cl. 9.1
1
DAT.BI-04
ISO/IEC 42001:2023 — A.7.4; A.6.2.8
1
DAT.LB-03
ISO/IEC 42001:2023 — A.7.4; A.7.6
2
DAT.QU-01DAT.LA-01
ISO/IEC 42001:2023 — A.7.4; A.8
1
DAT.LB-02
ISO/IEC 42001:2023 — A.7.4; Cl. 9.1
2
DAT.QU-04TRU.PE-03
ISO/IEC 42001:2023 — A.7.5
3
DAT.RE-01DAT.RE-02DAT.RE-03
ISO/IEC 42001:2023 — A.7; A.7.3; A.7.4
1
DAT.PO-02
ISO/IEC 42001:2023 — A.8
1
TRA.TD-02
ISO/IEC 42001:2023 — A.8; A.6.2.6
2
TRA.LR-02TRA.LR-03
ISO/IEC 42001:2023 — A.8; A.6.2.8
8
LIF.DP-03TRA.PO-01TRA.TD-01TRA.TD-03TRA.MC-02TRA.IU-02TRA.IU-03TRA.LR-01
ISO/IEC 42001:2023 — A.8; A.8.4
2
TRA.UD-02TRA.UD-03
ISO/IEC 42001:2023 — A.8; A.8.4; A.10.4
1
TRA.UD-04
ISO/IEC 42001:2023 — A.8; A.8.4; A.8.5
1
TRA.UD-01
ISO/IEC 42001:2023 — A.9
3
HUM.CO-01HUM.CO-03HUM.CO-04
ISO/IEC 42001:2023 — A.9; A.6.2
1
HUM.PO-01
ISO/IEC 42001:2023 — A.9; A.6.2.2
1
HUM.PO-02
ISO/IEC 42001:2023 — A.9; A.6.2.5
3
HUM.CO-02HUM.IN-01HUM.IN-04
ISO/IEC 42001:2023 — A.9; A.6.2.6
2
HUM.IN-02HUM.IN-03
ISO/IEC 42001:2023 — A.9; A.6.2.7
1
HUM.EF-01
ISO/IEC 42001:2023 — A.9; A.8
3
HUM.UA-01HUM.UA-02HUM.UA-03
ISO/IEC 42001:2023 — A.9; Cl. 10
1
HUM.UA-04
ISO/IEC 42001:2023 — A.9; Cl. 9.1
1
HUM.EF-02
ISO/IEC 42001:2023 — A.9; Cl. 9.1; A.4.6
1
HUM.EF-03
ISO/IEC 42001:2023 — Cl. 10; Cl. 10.1
1
GOV.OV-07
ISO/IEC 42001:2023 — Cl. 4.1
2
CON.OC-01CON.OC-02
ISO/IEC 42001:2023 — Cl. 4.1; A.10
1
CON.JU-01
ISO/IEC 42001:2023 — Cl. 4.1; A.5.2
1
CON.JU-02
ISO/IEC 42001:2023 — Cl. 4.1; A.6.2
2
CON.JU-03IMP.GP-01
ISO/IEC 42001:2023 — Cl. 4.1; A.7.4
1
CON.JU-04
ISO/IEC 42001:2023 — Cl. 4.1; Cl. 9.3
2
CON.OC-03CON.JU-05
ISO/IEC 42001:2023 — Cl. 4.2; A.5.3
2
CON.IP-01CON.IP-03
ISO/IEC 42001:2023 — Cl. 4.3
2
CON.SC-01CON.SC-02
ISO/IEC 42001:2023 — Cl. 4.3; Cl. 6.1; A.5.2; A.9.4
1
CON.JU-06
ISO/IEC 42001:2023 — Cl. 4.3; Cl. 9.3
1
CON.SC-03
ISO/IEC 42001:2023 — Cl. 4.4; Cl. 5.2; A.2.2
1
GOV.PO-01
ISO/IEC 42001:2023 — Cl. 5.1
2
GOV.ST-04GOV.LD-01
ISO/IEC 42001:2023 — Cl. 5.1(b); A.4.2
1
GOV.LD-03
ISO/IEC 42001:2023 — Cl. 5.1(f, g, h); Cl. 10
1
GOV.LD-04
ISO/IEC 42001:2023 — Cl. 5.1; A.10
1
GOV.ST-03
ISO/IEC 42001:2023 — Cl. 5.1; A.2.3
2
GOV.ST-01GOV.ST-02
ISO/IEC 42001:2023 — Cl. 5.1; A.3.2
1
GOV.GF-01
ISO/IEC 42001:2023 — Cl. 5.2; A.2.3
1
GOV.PO-02
ISO/IEC 42001:2023 — Cl. 5.2; Cl. 7.4; A.2.2
1
GOV.PO-03
ISO/IEC 42001:2023 — Cl. 5.2; Cl. 7.4; A.2.2; A.4.6; A.9
1
GOV.AU-01
ISO/IEC 42001:2023 — Cl. 5.2; Cl. 9.3; A.2.4
1
GOV.PO-04
ISO/IEC 42001:2023 — Cl. 5.3; A.3.2
3
GOV.RR-01GOV.RR-02GOV.RR-03
ISO/IEC 42001:2023 — Cl. 5.3; A.3.2; A.10
1
GOV.RR-06
ISO/IEC 42001:2023 — Cl. 6.1
1
GOV.RA-01
ISO/IEC 42001:2023 — Cl. 6.1.4; A.5.2; A.6.2; A.8
1
IMP.IA-03
ISO/IEC 42001:2023 — Cl. 6.1.4; A.5.3; A.5.4
1
IMP.IA-02
ISO/IEC 42001:2023 — Cl. 6.1.4; A.5; A.5.2
2
IMP.IA-05IMP.IA-06
ISO/IEC 42001:2023 — Cl. 6.1.4; Cl. 8.4; A.5.2; A.5.3; A.5.5
1
IMP.IA-01
ISO/IEC 42001:2023 — Cl. 6.1.4; Cl. 8.4; Cl. 9.3; A.5.2; A.5.4
1
IMP.IA-04
ISO/IEC 42001:2023 — Cl. 6.1; A.10
1
RSK.ID-03
ISO/IEC 42001:2023 — Cl. 6.1; A.5.2
5
RSK.ID-01RSK.ID-02RSK.AR-01RSK.AR-02RSK.AR-03
ISO/IEC 42001:2023 — Cl. 6.1; Cl. 6.1.2
1
RSK.AS-02
ISO/IEC 42001:2023 — Cl. 6.1; Cl. 6.1.2; A.5.2
2
RSK.ME-01RSK.ME-02
ISO/IEC 42001:2023 — Cl. 6.1; Cl. 6.1.2; A.5.2; A.10
1
RSK.ME-03
ISO/IEC 42001:2023 — Cl. 6.1; Cl. 6.1.2; Cl. 8.2; A.5.2
1
RSK.AS-01
ISO/IEC 42001:2023 — Cl. 6.1; Cl. 6.1.2; Cl. 8.2; Cl. 9.3
1
RSK.AS-03
ISO/IEC 42001:2023 — Cl. 6.1; Cl. 6.1.3; Cl. 8
1
RSK.TR-02
ISO/IEC 42001:2023 — Cl. 6.1; Cl. 6.1.3; Cl. 8.3; A.5.2
1
RSK.TR-01
ISO/IEC 42001:2023 — Cl. 6.1; Cl. 6.1.3; Cl. 9.1
1
RSK.TR-03
ISO/IEC 42001:2023 — Cl. 6.1; Cl. 6.1.4; A.5; A.5.2
1
IMP.ME-01
ISO/IEC 42001:2023 — Cl. 6.1; Cl. 8
1
GOV.RA-03
ISO/IEC 42001:2023 — Cl. 6.1; Cl. 8.1; Cl. 8.2; A.5.2
1
RSK.RG-01
ISO/IEC 42001:2023 — Cl. 6.1; Cl. 9.3
2
RSK.MO-02RSK.MO-03
ISO/IEC 42001:2023 — Cl. 6.2; A.2.2
1
GOV.OB-01
ISO/IEC 42001:2023 — Cl. 6.2; Cl. 9.1; Cl. 9.3
1
GOV.OB-02
ISO/IEC 42001:2023 — Cl. 6.3; Cl. 9.3; Cl. 10
1
GOV.OB-03
ISO/IEC 42001:2023 — Cl. 7.1; Cl. 5.1; A.4; A.4.2; A.4.4; A.4.5; A.4.6
1
GOV.LD-02
ISO/IEC 42001:2023 — Cl. 7.2; A.4.6
1
GOV.CO-01
ISO/IEC 42001:2023 — Cl. 7.2; Cl. 7.3
1
GOV.CO-03
ISO/IEC 42001:2023 — Cl. 7.2; Cl. 9.1
1
GOV.CO-04
ISO/IEC 42001:2023 — Cl. 7.3; A.4.6
1
GOV.CO-02
ISO/IEC 42001:2023 — Cl. 7.4
1
GOV.RA-02
ISO/IEC 42001:2023 — Cl. 7.4; A.8; A.8.5
1
GOV.DI-02
ISO/IEC 42001:2023 — Cl. 7.5; Cl. 7.5.2; Cl. 7.5.3; A.2.2
1
GOV.DI-01
ISO/IEC 42001:2023 — Cl. 8.1; A.6.1; A.10
1
LIF.PO-03
ISO/IEC 42001:2023 — Cl. 8.1; A.6.1; A.6.2
1
LIF.PO-01
ISO/IEC 42001:2023 — Cl. 8.1; A.6.2.2; A.6.2.3
1
LIF.PO-02
ISO/IEC 42001:2023 — Cl. 8.4; A.5.4; A.6.2
1
IMP.MO-01
ISO/IEC 42001:2023 — Cl. 8.4; Cl. 9.1; A.5.4
1
IMP.MO-02
ISO/IEC 42001:2023 — Cl. 9.1
5
GOV.OV-01GOV.OV-02GOV.OV-06RSK.RG-03RSK.MO-01
ISO/IEC 42001:2023 — Cl. 9.1; A.6.2
1
RSK.AR-04
ISO/IEC 42001:2023 — Cl. 9.1; A.6.2.6; A.9
1
GOV.AU-03
ISO/IEC 42001:2023 — Cl. 9.1; Cl. 9.3
2
GOV.OV-04RSK.RG-02
ISO/IEC 42001:2023 — Cl. 9.2; Cl. 9.2.2
1
GOV.OV-03
ISO/IEC 42001:2023 — Cl. 9.3
1
GOV.RA-04
ISO/IEC 42001:2023 — Cl. 9.3; A.2.4
1
GOV.ST-05
ISO/IEC 42001:2023 — Cl. 9.3; Cl. 10
7
RSK.ME-04IMP.ME-03DAT.PO-03TRU.PO-03HUM.PO-03TRA.PO-02TPA.PO-02
ISO/IEC 42001:2023 — Cl. 9.3; Cl. 9.3.2; Cl. 9.3.3
1
GOV.OV-05
NIST AI RMF208 references · 301 unique Controls
Reference
Controls
Satisfying AIMS Controls
NIST AI RMF — GOVERN 1.1
1
IMP.GP-03
NIST AI RMF — GOVERN 1.1; GOVERN 1.2
1
GOV.PO-01
NIST AI RMF — GOVERN 1.1; GOVERN 1.5
1
CON.JU-05
NIST AI RMF — GOVERN 1.1; GOVERN 2.1
1
IMP.GP-05
NIST AI RMF — GOVERN 1.1; GOVERN 6.1; MEASURE 2.10
1
DAT.LB-05
NIST AI RMF — GOVERN 1.1; MAP 1.1
2
CON.JU-03IMP.GP-01
NIST AI RMF — GOVERN 1.1; MAP 1.1; MAP 5.1
1
CON.JU-02
NIST AI RMF — GOVERN 1.1; MAP 3.5
1
DAT.LB-03
NIST AI RMF — GOVERN 1.1; MAP 4.1
1
CON.JU-01
NIST AI RMF — GOVERN 1.1; MAP 4.1; MAP 5.1
1
CON.JU-06
NIST AI RMF — GOVERN 1.1; MEASURE 2.10
4
CON.JU-04DAT.LB-01DAT.LB-02DAT.LB-04
NIST AI RMF — GOVERN 1.1; MEASURE 2.8
2
IMP.GP-02TPA.GP-03
NIST AI RMF — GOVERN 1.2; GOVERN 1.4
3
GOV.PO-02DAT.PO-01TRU.PO-01
NIST AI RMF — GOVERN 1.2; GOVERN 2.2; MAP 3.4
1
GOV.AU-01
NIST AI RMF — GOVERN 1.2; GOVERN 2.3
1
GOV.LD-03
NIST AI RMF — GOVERN 1.2; GOVERN 3.1
1
GOV.ET-01
NIST AI RMF — GOVERN 1.2; GOVERN 4.1
2
GOV.GF-03GOV.ET-02
NIST AI RMF — GOVERN 1.2; MANAGE 2.4
1
GOV.AU-02
NIST AI RMF — GOVERN 1.2; MAP 1.6
1
LIF.DE-03
NIST AI RMF — GOVERN 1.2; MEASURE 1.1
1
TRU.PO-02
NIST AI RMF — GOVERN 1.2; MEASURE 2.8
1
TRA.PO-01
NIST AI RMF — GOVERN 1.3; GOVERN 1.4
6
GOV.ST-01GOV.ST-04GOV.OB-01RSK.ME-01DAT.PO-02LIF.PO-01
NIST AI RMF — GOVERN 1.3; GOVERN 1.6
1
GOV.ST-02
NIST AI RMF — GOVERN 1.3; GOVERN 6.1
2
GOV.ST-03LIF.PO-03
NIST AI RMF — GOVERN 1.3; MAP 4.1
1
RSK.ME-03
NIST AI RMF — GOVERN 1.4
1
GOV.DI-01
NIST AI RMF — GOVERN 1.4; GOVERN 2.2
1
GOV.PO-03
NIST AI RMF — GOVERN 1.4; GOVERN 5.1
1
GOV.DI-02
NIST AI RMF — GOVERN 1.4; MANAGE 1.3
1
LIF.PO-02
NIST AI RMF — GOVERN 1.4; MEASURE 3.1
1
TRA.LR-01
NIST AI RMF — GOVERN 1.4; MEASURE 4.3
1
GOV.OB-02
NIST AI RMF — GOVERN 1.5
9
GOV.PO-04GOV.ST-05RSK.ME-04IMP.ME-03DAT.PO-03TRU.PO-03HUM.PO-03TRA.PO-02TPA.PO-02
NIST AI RMF — GOVERN 1.5; GOVERN 1.6
1
CON.SC-03
NIST AI RMF — GOVERN 1.5; GOVERN 1.7
1
GOV.OB-03
NIST AI RMF — GOVERN 1.5; GOVERN 2.3
1
GOV.OV-05
NIST AI RMF — GOVERN 1.5; MAP 1.5
1
GOV.RA-04
NIST AI RMF — GOVERN 1.5; MEASURE 1.3
1
GOV.OV-03
NIST AI RMF — GOVERN 1.6
1
CON.IN-01
NIST AI RMF — GOVERN 1.6; GOVERN 1.5
1
DAT.IN-04
NIST AI RMF — GOVERN 1.6; GOVERN 1.7
1
CON.IN-04
NIST AI RMF — GOVERN 1.6; MANAGE 2.1
1
GOV.LD-02
NIST AI RMF — GOVERN 1.6; MANAGE 4.2
1
LIF.VR-04
NIST AI RMF — GOVERN 1.6; MAP 1.4
2
CON.SC-01CON.SC-02
NIST AI RMF — GOVERN 1.6; MAP 2.1
5
CON.IN-02DAT.IN-01LIF.VR-01LIF.VR-02LIF.VR-03
NIST AI RMF — GOVERN 1.6; MAP 3.5
1
CON.IN-03
NIST AI RMF — GOVERN 1.6; MEASURE 2.10
1
DAT.IN-02
NIST AI RMF — GOVERN 1.7
1
LIF.DC-01
NIST AI RMF — GOVERN 1.7; MANAGE 4.3
1
LIF.DC-02
NIST AI RMF — GOVERN 1.7; MEASURE 2.10
1
LIF.DC-03
NIST AI RMF — GOVERN 2.1; GOVERN 2.3
3
GOV.RR-01GOV.RR-03GOV.GF-01
NIST AI RMF — GOVERN 2.1; GOVERN 3.2
2
GOV.RR-02GOV.RR-04
NIST AI RMF — GOVERN 2.1; GOVERN 4.1
1
GOV.GF-02
NIST AI RMF — GOVERN 2.1; GOVERN 6.1
1
GOV.RR-06
NIST AI RMF — GOVERN 2.2
2
GOV.CO-02GOV.CO-03
NIST AI RMF — GOVERN 2.2; GOVERN 3.2
2
GOV.CO-01GOV.CO-04
NIST AI RMF — GOVERN 2.2; MAP 1.2
1
DAT.LA-02
NIST AI RMF — GOVERN 2.2; MAP 3.4
3
HUM.CM-01HUM.CM-02HUM.CM-03
NIST AI RMF — GOVERN 2.3
1
GOV.LD-01
NIST AI RMF — GOVERN 2.3; GOVERN 4.1
1
GOV.LD-04
NIST AI RMF — GOVERN 2.3; MEASURE 3.1
2
GOV.OV-04RSK.RG-02
NIST AI RMF — GOVERN 3.1; GOVERN 1.2
1
DAT.LA-03
NIST AI RMF — GOVERN 4.1; GOVERN 4.3
1
GOV.ET-04
NIST AI RMF — GOVERN 4.3
1
GOV.RR-05
NIST AI RMF — GOVERN 5.2; MAP 5.2; MEASURE 3.3
1
CON.IP-04
NIST AI RMF — GOVERN 6.1
2
TPA.PO-01TPA.CT-03
NIST AI RMF — GOVERN 6.1; GOVERN 1.1
1
TPA.CT-05
NIST AI RMF — GOVERN 6.1; GOVERN 1.2
1
GOV.ET-03
NIST AI RMF — GOVERN 6.1; GOVERN 1.5
1
TPA.CT-04
NIST AI RMF — GOVERN 6.1; GOVERN 2.1
1
TPA.CT-02
NIST AI RMF — GOVERN 6.1; GOVERN 6.2
1
TPA.SC-04
NIST AI RMF — GOVERN 6.1; MANAGE 3.1
5
DAT.PR-03TPA.DD-01TPA.DD-04TPA.CT-01TPA.AT-04
NIST AI RMF — GOVERN 6.1; MANAGE 3.2
3
TPA.AT-01TPA.AT-02TPA.AT-03
NIST AI RMF — GOVERN 6.1; MAP 4.2
5
LIF.DV-03TPA.DD-02TPA.DD-03TPA.SC-01TPA.SC-02
NIST AI RMF — GOVERN 6.1; MEASURE 2.7
1
TPA.SC-03
NIST AI RMF — MANAGE 1.1; MAP 1.1
1
LIF.DE-05
NIST AI RMF — MANAGE 1.2; MANAGE 1.3
1
RSK.TR-01
NIST AI RMF — MANAGE 1.3; MANAGE 2.2
1
LIF.DP-02
NIST AI RMF — MANAGE 1.3; MEASURE 2.5
1
LIF.DP-01
NIST AI RMF — MANAGE 1.4
1
RSK.TR-02
NIST AI RMF — MANAGE 2.3; MANAGE 4.3
2
LIF.IR-01LIF.IR-02
NIST AI RMF — MANAGE 2.3; MANAGE 4.3; GOVERN 1.1
1
LIF.IR-05
NIST AI RMF — MANAGE 2.4; MANAGE 2.3
2
LIF.AG-05HUM.IN-03
NIST AI RMF — MANAGE 2.4; MANAGE 4.1
1
HUM.IN-02
NIST AI RMF — MANAGE 3.1; MEASURE 2.5
1
LIF.DP-04
NIST AI RMF — MANAGE 4.1; MANAGE 4.2
1
LIF.OP-05
NIST AI RMF — MANAGE 4.1; MANAGE 4.3
1
TPA.DR-04
NIST AI RMF — MANAGE 4.2; MANAGE 4.3
1
GOV.OV-07
NIST AI RMF — MANAGE 4.3; GOVERN 1.1
1
LIF.IR-04
NIST AI RMF — MANAGE 4.3; MANAGE 4.2
1
LIF.IR-03
NIST AI RMF — MAP 1.1; GOVERN 1.1
2
CON.IP-03TPA.DR-01
NIST AI RMF — MAP 1.1; GOVERN 1.5
1
CON.OC-03
NIST AI RMF — MAP 1.1; MAP 1.3
1
CON.OC-01
NIST AI RMF — MAP 1.1; MAP 3.3; MAP 5.1
1
IMP.IA-03
NIST AI RMF — MAP 1.2; GOVERN 5.1
1
CON.IP-01
NIST AI RMF — MAP 1.2; MAP 5.2
1
IMP.IA-02
NIST AI RMF — MAP 1.3; MAP 1.4
1
CON.OC-02
NIST AI RMF — MAP 1.5; GOVERN 1.4
1
GOV.RA-01
NIST AI RMF — MAP 1.5; GOVERN 2.2
1
GOV.RA-02
NIST AI RMF — MAP 1.5; MANAGE 1.2
1
GOV.RA-03
NIST AI RMF — MAP 1.6; MAP 1.1
1
LIF.DE-01
NIST AI RMF — MAP 2.1; MAP 1.6
1
LIF.DE-02
NIST AI RMF — MAP 2.1; MEASURE 2.13
1
LIF.TR-03
NIST AI RMF — MAP 2.1; MEASURE 2.5
1
LIF.TR-01
NIST AI RMF — MAP 2.1; MEASURE 2.6
1
LIF.TR-04
NIST AI RMF — MAP 2.1; MEASURE 2.7
1
LIF.TR-02
NIST AI RMF — MAP 2.3; MEASURE 2.5
2
DAT.SY-01DAT.LA-01
NIST AI RMF — MAP 3.1; MAP 3.2; MAP 5.1
1
IMP.IA-05
NIST AI RMF — MAP 3.4; MEASURE 4.1
2
HUM.EF-01HUM.EF-03
NIST AI RMF — MAP 3.4; MEASURE 4.3
1
HUM.EF-02
NIST AI RMF — MAP 3.5
2
HUM.PO-02HUM.CO-01
NIST AI RMF — MAP 3.5; GOVERN 1.1
1
HUM.CO-04
NIST AI RMF — MAP 3.5; GOVERN 1.2
1
HUM.PO-01
NIST AI RMF — MAP 3.5; GOVERN 2.2
1
TPA.DR-02
NIST AI RMF — MAP 3.5; MANAGE 2.4
3
HUM.CO-03HUM.IN-01HUM.IN-04
NIST AI RMF — MAP 3.5; MAP 1.6
1
LIF.AG-01
NIST AI RMF — MAP 3.5; MAP 3.4
1
HUM.CO-02
NIST AI RMF — MAP 3.5; MEASURE 2.6
1
LIF.AG-03
NIST AI RMF — MAP 4.1; GOVERN 6.1
1
DAT.PR-01
NIST AI RMF — MAP 4.1; MAP 4.2
1
RSK.ID-03
NIST AI RMF — MAP 4.1; MEASURE 2.8
1
DAT.PR-02
NIST AI RMF — MAP 5.1; GOVERN 1.3
2
RSK.ME-02IMP.ME-01
NIST AI RMF — MAP 5.1; GOVERN 1.5
3
RSK.ID-02RSK.AS-03IMP.IA-04
NIST AI RMF — MAP 5.1; GOVERN 4.2
1
IMP.IA-01
NIST AI RMF — MAP 5.1; MAP 4.1
2
RSK.ID-01IMP.ME-02
NIST AI RMF — MAP 5.1; MEASURE 1.1
2
RSK.AS-01RSK.AS-02
NIST AI RMF — MAP 5.1; MEASURE 2.11
1
DAT.BI-01
NIST AI RMF — MAP 5.1; MEASURE 2.7
1
RSK.AR-01
NIST AI RMF — MAP 5.2; MAP 1.2
1
CON.IP-02
NIST AI RMF — MAP 5.2; MEASURE 3.3
2
HUM.UA-01HUM.UA-03
NIST AI RMF — MEASURE 1.2; MANAGE 4.2
1
RSK.TR-03
NIST AI RMF — MEASURE 1.3
1
IMP.IR-02
NIST AI RMF — MEASURE 1.3; GOVERN 2.1
1
IMP.IR-01
NIST AI RMF — MEASURE 1.3; GOVERN 4.1
2
GOV.GF-04LIF.DE-04
NIST AI RMF — MEASURE 1.3; MANAGE 4.2
1
IMP.IR-03
NIST AI RMF — MEASURE 1.3; MEASURE 2.10
1
IMP.DA-03
NIST AI RMF — MEASURE 2.10
2
TRU.PE-01TRU.PE-02
NIST AI RMF — MEASURE 2.10; GOVERN 1.2
1
DAT.RE-01
NIST AI RMF — MEASURE 2.10; GOVERN 1.7
2
DAT.RE-02DAT.RE-03
NIST AI RMF — MEASURE 2.10; MAP 5.1
3
IMP.DA-01IMP.DA-02DAT.SY-03
NIST AI RMF — MEASURE 2.10; MEASURE 4.1
1
TRU.PE-03
NIST AI RMF — MEASURE 2.11
3
DAT.BI-02LIF.VA-03TRU.FA-02
NIST AI RMF — MEASURE 2.11; MANAGE 1.3
2
DAT.BI-03TRU.FA-03
NIST AI RMF — MEASURE 2.11; MANAGE 1.4
1
TRU.FA-04
NIST AI RMF — MEASURE 2.11; MANAGE 4.1
1
TRU.FA-05
NIST AI RMF — MEASURE 2.11; MAP 1.6
1
TRU.FA-01
NIST AI RMF — MEASURE 2.11; MEASURE 3.1
1
DAT.BI-04
NIST AI RMF — MEASURE 2.12
1
IMP.IA-06
NIST AI RMF — MEASURE 2.13; MEASURE 2.5
1
LIF.VA-05
NIST AI RMF — MEASURE 2.2
1
LIF.VA-06
NIST AI RMF — MEASURE 2.3; MEASURE 1.1
1
TRU.AC-01
NIST AI RMF — MEASURE 2.3; MEASURE 2.4
1
TRU.AC-03
NIST AI RMF — MEASURE 2.3; MEASURE 2.5
2
LIF.VA-01TRU.AC-02
NIST AI RMF — MEASURE 2.4; MANAGE 1.3
1
IMP.MO-01
NIST AI RMF — MEASURE 2.4; MANAGE 4.1
2
IMP.MO-02LIF.OP-02
NIST AI RMF — MEASURE 2.4; MEASURE 2.5
1
LIF.OP-01
NIST AI RMF — MEASURE 2.5; GOVERN 1.1
1
TPA.DR-03
NIST AI RMF — MEASURE 2.5; MANAGE 1.3
1
DAT.QU-03
NIST AI RMF — MEASURE 2.5; MEASURE 2.3
1
DAT.QU-01
NIST AI RMF — MEASURE 2.5; MEASURE 2.7
1
LIF.VA-02
NIST AI RMF — MEASURE 2.5; MEASURE 3.1
1
DAT.QU-02
NIST AI RMF — MEASURE 2.6
1
TRU.SA-01
NIST AI RMF — MEASURE 2.6; MANAGE 1.3
1
IMP.GP-04
NIST AI RMF — MEASURE 2.6; MANAGE 4.1
1
TRU.SA-05
NIST AI RMF — MEASURE 2.6; MAP 3.5
1
TRU.SA-02
NIST AI RMF — MEASURE 2.6; MAP 5.1
1
TRU.SA-04
NIST AI RMF — MEASURE 2.6; MEASURE 1.1
1
TRU.SA-03
NIST AI RMF — MEASURE 2.6; MEASURE 2.4
1
LIF.OP-04
NIST AI RMF — MEASURE 2.6; MEASURE 2.7
1
LIF.VA-04
NIST AI RMF — MEASURE 2.7
3
LIF.DV-02TRU.RB-01TRU.RE-02
NIST AI RMF — MEASURE 2.7; GOVERN 6.1
3
LIF.DV-01LIF.DV-05LIF.AG-04
NIST AI RMF — MEASURE 2.7; MANAGE 4.1
2
LIF.OP-03TRU.RB-04
NIST AI RMF — MEASURE 2.7; MAP 1.6
1
TRU.RE-01
NIST AI RMF — MEASURE 2.7; MAP 3.5
1
LIF.AG-02
NIST AI RMF — MEASURE 2.7; MAP 5.1
2
RSK.AR-02RSK.AR-03
NIST AI RMF — MEASURE 2.7; MEASURE 1.3
1
RSK.AR-04
NIST AI RMF — MEASURE 2.7; MEASURE 2.1
1
LIF.DV-04
NIST AI RMF — MEASURE 2.7; MEASURE 2.10
3
DAT.LK-01DAT.LK-02DAT.LK-03
NIST AI RMF — MEASURE 2.7; MEASURE 2.5
3
TRU.RB-02TRU.RB-03TRU.RE-03
NIST AI RMF — MEASURE 2.7; MEASURE 3.1; MANAGE 4.1
1
GOV.AU-03
NIST AI RMF — MEASURE 2.8
5
DAT.SY-02TRU.OI-02TRU.OI-04TRA.IU-02TRA.UD-02
NIST AI RMF — MEASURE 2.8; GOVERN 1.1
4
TRU.OI-01TRA.UD-03TRA.UD-04TPA.GP-01
NIST AI RMF — MEASURE 2.8; GOVERN 1.4
2
TRA.TD-01TRA.TD-02
NIST AI RMF — MEASURE 2.8; GOVERN 1.5
2
TRA.TD-03TRA.IU-03
NIST AI RMF — MEASURE 2.8; GOVERN 1.6
1
DAT.IN-03
NIST AI RMF — MEASURE 2.8; GOVERN 6.1
2
LIF.DP-03TPA.GP-02
NIST AI RMF — MEASURE 2.8; MAP 1.4
1
TRA.MC-02
NIST AI RMF — MEASURE 2.8; MAP 2.2
1
TRA.MC-01
NIST AI RMF — MEASURE 2.8; MAP 3.4
1
TRA.IU-01
NIST AI RMF — MEASURE 2.8; MAP 5.2
1
TRA.UD-01
NIST AI RMF — MEASURE 2.8; MEASURE 2.6
1
TRU.OI-03
NIST AI RMF — MEASURE 2.9
1
TRU.EX-02
NIST AI RMF — MEASURE 2.9; MAP 1.6
1
TRU.EX-01
NIST AI RMF — MEASURE 2.9; MEASURE 3.3
2
TRU.EX-04HUM.UA-02
NIST AI RMF — MEASURE 2.9; MEASURE 4.1
1
TRU.EX-03
NIST AI RMF — MEASURE 3.1; GOVERN 1.4
1
TRA.LR-02
NIST AI RMF — MEASURE 3.1; GOVERN 1.5
1
RSK.MO-02
NIST AI RMF — MEASURE 3.1; GOVERN 2.3
1
RSK.RG-03
NIST AI RMF — MEASURE 3.1; MAP 5.1
1
RSK.RG-01
NIST AI RMF — MEASURE 3.1; MEASURE 2.7
3
TRA.LR-03TRA.AG-01TRA.AG-02
NIST AI RMF — MEASURE 3.1; MEASURE 3.2
1
RSK.MO-01
NIST AI RMF — MEASURE 3.1; MEASURE 4.1
1
GOV.OV-01
NIST AI RMF — MEASURE 3.2; MANAGE 4.1
1
IMP.MO-03
NIST AI RMF — MEASURE 3.2; MEASURE 4.1
1
RSK.MO-03
NIST AI RMF — MEASURE 3.3; MANAGE 4.3
1
HUM.UA-04
NIST AI RMF — MEASURE 4.1; GOVERN 1.5
1
DAT.QU-04
NIST AI RMF — MEASURE 4.2; MEASURE 4.3; MANAGE 4.2
1
GOV.OV-02
NIST AI RMF — MEASURE 4.3
1
GOV.OV-06
NIST AI RMF — MEASURE 4.3; MANAGE 4.1
1
TRU.AC-04
EU AI Act183 references · 282 unique Controls
Reference
Controls
Satisfying AIMS Controls
EU AI Act — Art. 10
4
CON.JU-04DAT.PO-02DAT.IN-02DAT.SY-01
EU AI Act — Art. 10 (data governance interface)
1
DAT.LB-05
EU AI Act — Art. 10(2)(f); Art. 10(3); Art. 15
1
DAT.BI-01
EU AI Act — Art. 10(2)(g)
2
DAT.LA-01DAT.LA-02
EU AI Act — Art. 10(2); Art. 10(3); Art. 15
1
DAT.QU-01
EU AI Act — Art. 10(2); Art. 10(3); Art. 53(1)(d)
1
LIF.TR-01
EU AI Act — Art. 10(2); Art. 17(2)(g)
1
DAT.QU-04
EU AI Act — Art. 10(2); Art. 72
1
DAT.QU-02
EU AI Act — Art. 10(3); Art. 10(4)
1
DAT.QU-03
EU AI Act — Art. 10(3); Art. 15
6
DAT.BI-02DAT.BI-03LIF.VA-03TRU.FA-01TRU.FA-02TRU.FA-03
EU AI Act — Art. 10(3); Art. 15; Art. 17(2)(g)
1
DAT.BI-04
EU AI Act — Art. 10(5)
6
DAT.LB-01DAT.LB-04DAT.RE-01DAT.SY-03TRU.PE-01TRU.PE-02
EU AI Act — Art. 10(5); Art. 15
1
TRU.PE-03
EU AI Act — Art. 10; Art. 11; Art. 53(1)(d)
1
DAT.IN-01
EU AI Act — Art. 10; Art. 12
1
DAT.IN-04
EU AI Act — Art. 10; Art. 15
1
DAT.LK-01
EU AI Act — Art. 10; Art. 26(9)
3
IMP.DA-01IMP.DA-02IMP.DA-03
EU AI Act — Art. 10; Art. 50(2)
1
DAT.SY-02
EU AI Act — Art. 10; Art. 53
1
DAT.PO-01
EU AI Act — Art. 10; Art. 53(1)(c)
1
DAT.PR-01
EU AI Act — Art. 11(3); Art. 13(3)(d); Art. 14
1
TRA.IU-03
EU AI Act — Art. 11(3); Art. 17 (where applicable as part of QMS)
1
GOV.OB-03
EU AI Act — Art. 11(3); Art. 18
1
TRA.TD-03
EU AI Act — Art. 11; Annex IV; Art. 18
1
TRA.TD-01
EU AI Act — Art. 11; Annex IV; Art. 53(1)(a); Annex XI
1
TPA.SC-02
EU AI Act — Art. 11; Art. 12
1
LIF.VR-02
EU AI Act — Art. 11; Art. 12; Art. 53(1)(a)
1
LIF.VR-01
EU AI Act — Art. 11; Art. 13; Art. 50; Art. 53
1
TRA.PO-01
EU AI Act — Art. 11; Art. 16
1
LIF.DE-02
EU AI Act — Art. 11; Art. 26(6)
1
CON.IN-01
EU AI Act — Art. 11; Art. 53(1)(a); Annex XI
1
LIF.TR-03
EU AI Act — Art. 11; Art. 53(1)(a); Art. 53(1)(d)
1
LIF.VR-03
EU AI Act — Art. 12
2
DAT.RE-02DAT.RE-03
EU AI Act — Art. 12 (record retention applied as good practice)
1
LIF.DC-03
EU AI Act — Art. 12; Art. 17(2)
1
LIF.VR-04
EU AI Act — Art. 12; Art. 18; Art. 26(6)
1
TRA.LR-03
EU AI Act — Art. 12; Art. 18; Art. 26(6); Art. 72
1
TRA.AG-02
EU AI Act — Art. 12; Art. 19; Art. 26(5); Art. 26(6); Art. 72
1
TRA.LR-02
EU AI Act — Art. 12; Art. 26(5); Art. 26(6)
1
TRA.AG-01
EU AI Act — Art. 12; Art. 50
1
TRU.OI-02
EU AI Act — Art. 12; Art. 53(1)(a)
1
DAT.PR-02
EU AI Act — Art. 13(1); Art. 11; Annex IV
1
TRA.IU-02
EU AI Act — Art. 13(1); Art. 13(2); Art. 13(3)
1
TRA.IU-01
EU AI Act — Art. 13; Art. 11; Annex IV
1
TRA.MC-02
EU AI Act — Art. 13; Art. 14; Art. 86
2
TRU.EX-01TRU.EX-02
EU AI Act — Art. 13; Art. 15
1
TRU.FA-04
EU AI Act — Art. 13; Art. 26(11); Art. 50; Art. 86
1
GOV.DI-02
EU AI Act — Art. 13; Art. 26(11); Art. 86
1
TRU.EX-04
EU AI Act — Art. 13; Art. 26(6)
1
LIF.DP-03
EU AI Act — Art. 13; Art. 26(7)
1
LIF.DC-02
EU AI Act — Art. 13; Art. 53(1)(a); Annex IV
1
TRA.MC-01
EU AI Act — Art. 13; Art. 86
1
TRU.EX-03
EU AI Act — Art. 14
2
LIF.AG-03HUM.CO-03
EU AI Act — Art. 14(1); Art. 14(2); Art. 14(3)
1
HUM.PO-02
EU AI Act — Art. 14(1); Art. 14(4)
1
HUM.CO-01
EU AI Act — Art. 14(3); Art. 14(4)
1
HUM.CO-02
EU AI Act — Art. 14(4)(b)
1
HUM.EF-03
EU AI Act — Art. 14(4)(d); Art. 14(4)(e)
1
HUM.IN-01
EU AI Act — Art. 14(4)(d); Art. 26(11); Art. 85; Art. 86
1
HUM.UA-03
EU AI Act — Art. 14(4)(e); Art. 15
1
HUM.IN-03
EU AI Act — Art. 14(4); Art. 12
1
HUM.IN-04
EU AI Act — Art. 14(4); Art. 17(2)(g)
2
HUM.EF-01HUM.EF-02
EU AI Act — Art. 14(4); Art. 26(11); Art. 50(1); Art. 86
1
HUM.UA-01
EU AI Act — Art. 14(4); Art. 26(11); Art. 86
1
HUM.CO-04
EU AI Act — Art. 14(4); Art. 26(5)
1
HUM.IN-02
EU AI Act — Art. 14(4); Art. 86; Art. 73
1
HUM.UA-04
EU AI Act — Art. 14; Art. 15
4
LIF.AG-01LIF.AG-02LIF.AG-04TRU.SA-02
EU AI Act — Art. 14; Art. 15; Art. 72
1
LIF.AG-05
EU AI Act — Art. 14; Art. 26(2)
1
HUM.PO-01
EU AI Act — Art. 14; Art. 26(2); Art. 26(7)
1
TPA.DR-02
EU AI Act — Art. 15
16
DAT.LK-02DAT.LK-03LIF.DV-01LIF.DV-02LIF.DV-04LIF.DV-05LIF.VA-02TRU.AC-01TRU.AC-02TRU.RB-01TRU.RB-02TRU.RB-03TRU.SA-01TRU.RE-01TRU.RE-02TRU.RE-03
EU AI Act — Art. 15 (cybersecurity); Art. 25
1
TPA.SC-03
EU AI Act — Art. 15; Art. 17(2)
1
TRU.PO-01
EU AI Act — Art. 15; Art. 17(2)(d)
2
LIF.VA-01LIF.VA-05
EU AI Act — Art. 15; Art. 25
1
LIF.DV-03
EU AI Act — Art. 15; Art. 26(5); Art. 72
3
LIF.DP-02TRU.AC-03TRU.FA-05
EU AI Act — Art. 15; Art. 53(1)(a)
1
LIF.TR-02
EU AI Act — Art. 15; Art. 55
2
LIF.VA-04TRU.SA-03
EU AI Act — Art. 15; Art. 72
7
LIF.OP-02LIF.OP-03LIF.OP-04LIF.OP-05TRU.AC-04TRU.RB-04TRU.SA-05
EU AI Act — Art. 15; Art. 9(2)
1
TRU.PO-02
EU AI Act — Art. 16; Art. 22; Art. 23; Art. 24; Art. 26
1
GOV.RR-06
EU AI Act — Art. 16; Art. 26; Art. 53
1
LIF.PO-03
EU AI Act — Art. 17
1
GOV.LD-03
EU AI Act — Art. 17(2)
14
GOV.PO-04GOV.ST-05GOV.RA-04GOV.OV-05CON.OC-01CON.OC-03CON.SC-03CON.JU-05RSK.ME-04IMP.ME-03DAT.PO-03LIF.PO-01TRU.PO-03HUM.PO-03
EU AI Act — Art. 17(2) (where applicable as part of QMS)
1
GOV.OB-01
EU AI Act — Art. 17(2)(a)
1
GOV.PO-01
EU AI Act — Art. 17(2)(b)
1
GOV.RA-01
EU AI Act — Art. 17(2)(d)
1
LIF.DE-04
EU AI Act — Art. 17(2)(d); Annex XI Section 1 point 2(e)
1
GOV.LD-02
EU AI Act — Art. 17(2)(d); Art. 26(3)
1
LIF.PO-02
EU AI Act — Art. 17(2)(g)
5
GOV.OV-01GOV.OV-02GOV.OV-04GOV.OV-06RSK.RG-02
EU AI Act — Art. 17(2)(g); Art. 72
1
RSK.MO-01
EU AI Act — Art. 17(2)(h)
1
GOV.OV-03
EU AI Act — Art. 17(2)(j)
1
GOV.OV-07
EU AI Act — Art. 17(2); Art. 96
2
TRA.PO-02TPA.PO-02
EU AI Act — Art. 18 (where applicable); Art. 12; Art. 26(6)
1
GOV.DI-01
EU AI Act — Art. 18; Art. 21; Art. 70; Art. 88; Art. 91; Art. 92; Art. 93; Art. 94
1
TRA.LR-01
EU AI Act — Art. 2
1
CON.SC-02
EU AI Act — Art. 20; Art. 21; Art. 22; Art. 73; Art. 79
1
LIF.IR-05
EU AI Act — Art. 25
5
TPA.CT-02TPA.CT-04TPA.AT-02TPA.AT-03TPA.AT-04
EU AI Act — Art. 25(1)(c); Art. 26(1)
1
TPA.DR-01
EU AI Act — Art. 25; Art. 15
1
TPA.SC-04
EU AI Act — Art. 25; Art. 26
3
TPA.DD-01TPA.CT-05TPA.AT-01
EU AI Act — Art. 25; Art. 26; Art. 53
1
TPA.CT-01
EU AI Act — Art. 25; Art. 27
1
TPA.DD-02
EU AI Act — Art. 25; Art. 53(1)(a); Annex IV; Annex XI
1
TPA.SC-01
EU AI Act — Art. 25; Art. 53(1)(c)
1
TPA.CT-03
EU AI Act — Art. 25; Art. 53; Art. 26
3
DAT.PR-03TPA.PO-01TPA.GP-02
EU AI Act — Art. 25; Art. 53; Art. 56 (GPAI Code of Practice)
1
TPA.DD-03
EU AI Act — Art. 25; Art. 72 (post-market monitoring)
1
TPA.DD-04
EU AI Act — Art. 26
3
GOV.ST-03GOV.RR-03CON.IN-03
EU AI Act — Art. 26(1)
5
GOV.LD-01GOV.RR-01GOV.RR-02GOV.GF-01GOV.GF-02
EU AI Act — Art. 26(1); Art. 26(4); Art. 26(5)
1
LIF.DP-04
EU AI Act — Art. 26(11); Art. 86
1
TRA.UD-04
EU AI Act — Art. 26(3); Art. 17(2)
1
LIF.DP-01
EU AI Act — Art. 26(4)
1
TPA.DR-03
EU AI Act — Art. 26(5)
1
CON.IN-04
EU AI Act — Art. 26(5); Art. 55(1)(c); Art. 73
2
LIF.IR-01LIF.IR-02
EU AI Act — Art. 26(5); Art. 55; Art. 72
1
LIF.IR-03
EU AI Act — Art. 26(5); Art. 72
2
IMP.MO-02LIF.OP-01
EU AI Act — Art. 26(5); Art. 72; Art. 73; Art. 79
1
TPA.DR-04
EU AI Act — Art. 26(5); Art. 73
1
GOV.AU-03
EU AI Act — Art. 26(6); Art. 72
1
LIF.DC-01
EU AI Act — Art. 26(7); Art. 87
1
GOV.RR-05
EU AI Act — Art. 27
2
IMP.ME-01IMP.IA-02
EU AI Act — Art. 27; Art. 16; Art. 26
1
IMP.ME-02
EU AI Act — Art. 27; Art. 26(3)
1
IMP.MO-01
EU AI Act — Art. 27; Art. 9
2
CON.IP-02IMP.IA-01
EU AI Act — Art. 2; Art. 17(2)
1
CON.SC-01
EU AI Act — Art. 3(49); Art. 26(5); Art. 55(1)(c); Art. 73; Art. 89
1
LIF.IR-04
EU AI Act — Art. 3; Art. 16; Art. 22; Art. 23; Art. 24; Art. 25; Art. 26
1
CON.JU-01
EU AI Act — Art. 4
7
GOV.PO-03GOV.LD-04GOV.RA-02GOV.CO-01GOV.CO-02GOV.CO-03GOV.CO-04
EU AI Act — Art. 4; Art. 14(4)(a)
2
HUM.CM-01HUM.CM-03
EU AI Act — Art. 4; Art. 14(4)(a); Art. 14(4)(b)
1
HUM.CM-02
EU AI Act — Art. 4; Art. 17
1
CON.IP-03
EU AI Act — Art. 4; Art. 26
1
CON.IP-01
EU AI Act — Art. 4; Art. 5; Art. 26
1
GOV.AU-01
EU AI Act — Art. 50(1)
1
TRA.UD-01
EU AI Act — Art. 50(2); Art. 50(4)
1
TRU.OI-03
EU AI Act — Art. 50(2); Art. 50(4); Art. 50(7)
1
TRA.UD-02
EU AI Act — Art. 50(2); Art. 50(5)
1
TRU.OI-01
EU AI Act — Art. 50(3); Art. 5(1)(f); Art. 5(1)(g)
1
TRA.UD-03
EU AI Act — Art. 50; Art. 53(1)(b)
1
TRU.OI-04
EU AI Act — Art. 50; Art. 86
1
CON.IP-04
EU AI Act — Art. 51; Art. 50
1
GOV.ST-02
EU AI Act — Art. 51; Art. 52
1
IMP.GP-01
EU AI Act — Art. 51; Art. 52; Art. 53; Art. 55
1
CON.JU-03
EU AI Act — Art. 51; Art. 53
1
CON.IN-02
EU AI Act — Art. 52; Art. 94
1
IMP.GP-03
EU AI Act — Art. 53
1
GOV.ET-03
EU AI Act — Art. 53(1)(a); Annex XI Section 1 point 2(e)
1
IMP.IA-06
EU AI Act — Art. 53(1)(a); Art. 53(1)(b); Annex XII; Annex XI
1
TPA.GP-01
EU AI Act — Art. 53(1)(a); Art. 53(1)(b); Art. 53(1)(c); Art. 53(1)(d); Annex XI
1
TRA.TD-02
EU AI Act — Art. 53(1)(d); Annex XI
1
DAT.IN-03
EU AI Act — Art. 53; Annex XI; Annex XII
1
IMP.GP-02
EU AI Act — Art. 53; Art. 55
1
LIF.TR-04
EU AI Act — Art. 53; Art. 55; Art. 56; Art. 89; Art. 90; Art. 95; Annex XIII
1
TPA.GP-03
EU AI Act — Art. 54
1
IMP.GP-05
EU AI Act — Art. 55
2
RSK.AR-04TRU.SA-04
EU AI Act — Art. 55; Art. 90
1
IMP.GP-04
EU AI Act — Art. 5; Art. 26
1
GOV.AU-02
EU AI Act — Art. 5; Art. 6; Art. 50; Art. 80; Annex III
1
CON.JU-02
EU AI Act — Art. 5; Art. 96; Art. 99 (penalties context)
1
CON.JU-06
EU AI Act — Art. 72
2
RSK.MO-03IMP.MO-03
EU AI Act — Art. 86
1
DAT.LB-02
EU AI Act — Art. 86; Art. 14; Art. 26(11); Art. 50(3)
1
DAT.LB-03
EU AI Act — Art. 86; Art. 26(11)
1
HUM.UA-02
EU AI Act — Art. 9
3
GOV.RA-03RSK.ME-01RSK.ME-02
EU AI Act — Art. 9(2)
2
RSK.ID-01RSK.AS-01
EU AI Act — Art. 9(2)(b); Art. 13(3)(b); Art. 14(4)(e)
1
IMP.IA-03
EU AI Act — Art. 9(2)(c); Art. 72
1
RSK.AS-03
EU AI Act — Art. 9(2); Art. 13; Art. 14; Art. 15
1
LIF.DE-01
EU AI Act — Art. 9(2); Art. 14; Art. 15
1
LIF.DE-03
EU AI Act — Art. 9(2); Art. 27(1)(c); Art. 72
1
IMP.IA-04
EU AI Act — Art. 9(2); Art. 72
2
RSK.ID-02RSK.MO-02
EU AI Act — Art. 9(4)
1
RSK.RG-01
EU AI Act — Art. 9(4); Art. 9(5)
1
RSK.TR-01
EU AI Act — Art. 9(5)
1
RSK.TR-02
EU AI Act — Art. 9(7)
1
RSK.AS-02
EU AI Act — Art. 9(7); Art. 9(8)
1
RSK.TR-03
EU AI Act — Art. 9; Art. 16; Art. 26
1
RSK.ME-03
EU AI Act — Art. 9; Art. 16; Art. 26; Art. 53
1
RSK.ID-03
EU AI Act — Art. 9; Art. 27 (where applicable)
3
IMP.IA-05LIF.DE-05LIF.VA-06
OECD4 references · 55 unique Controls
Reference
Controls
Satisfying AIMS Controls
OECD AI Principles (OECD/LEGAL/0449)
41
GOV.PO-01GOV.PO-03GOV.ST-01GOV.ST-02GOV.ST-04GOV.LD-02GOV.RR-05GOV.GF-03GOV.ET-01GOV.ET-02GOV.ET-04GOV.AU-01GOV.OB-01GOV.OB-02GOV.CO-02GOV.DI-02CON.OC-01CON.IP-01CON.IP-02CON.IP-03CON.IP-04CON.JU-06RSK.ME-02IMP.ME-01IMP.IA-01IMP.IA-02IMP.IA-05IMP.IA-06DAT.LA-03LIF.DE-03LIF.DE-05TRU.PO-01TRU.FA-01HUM.PO-01HUM.UA-01TRA.PO-02TRA.UD-02TRA.UD-04TPA.PO-01TPA.GP-01TPA.GP-03
OECD AI Principles (OECD/LEGAL/0449) — Transparency
1
TRA.UD-01
OECD AI Principles (OECD/LEGAL/0449) — Transparency and explainability
1
TRA.PO-01
OECD Due Diligence Guidance for Responsible AI
19
GOV.GF-04GOV.ET-02GOV.ET-03GOV.ET-04IMP.ME-01IMP.IA-01IMP.IA-03IMP.IA-05IMP.MO-01IMP.MO-02IMP.MO-03IMP.IR-01IMP.IR-02DAT.PR-01DAT.LA-03LIF.DE-05LIF.VA-06HUM.UA-03HUM.UA-04
GDPR49 references · 55 unique Controls
Reference
Controls
Satisfying AIMS Controls
GDPR — Art. 12; Art. 13(2)(f); Art. 14(2)(g); Art. 15; Art. 22(3)
1
HUM.UA-02
GDPR — Art. 12; Art. 13; Art. 14
1
GOV.DI-02
GDPR — Art. 12; Art. 13; Art. 14; Art. 22
1
TRA.UD-04
GDPR — Art. 12; Art. 15; Art. 16; Art. 17; Art. 18; Art. 20; Art. 21
1
DAT.LB-02
GDPR — Art. 13(2)(f); Art. 14(2)(g); Art. 22(3)
1
TRU.EX-01
GDPR — Art. 13; Art. 14
1
TRA.UD-01
GDPR — Art. 13; Art. 14; Art. 22(3)
1
TRU.EX-04
GDPR — Art. 21
1
CON.IP-04
GDPR — Art. 22
1
HUM.CO-04
GDPR — Art. 22(3)
1
HUM.UA-01
GDPR — Art. 22(3); Art. 77
1
HUM.UA-03
GDPR — Art. 22; Art. 13(2)(f); Art. 14(2)(g)
1
DAT.LB-03
GDPR — Art. 25
1
LIF.DE-03
GDPR — Art. 25; Art. 32
2
TRU.PE-01TRU.PE-02
GDPR — Art. 25; Art. 32; Art. 35
1
TRU.PE-03
GDPR — Art. 28
1
TPA.CT-03
GDPR — Art. 28; Art. 14
1
DAT.PR-03
GDPR — Art. 30
1
DAT.IN-01
GDPR — Art. 31; Art. 35(2); Art. 36; Art. 38; Art. 39
1
IMP.DA-03
GDPR — Art. 33; Art. 34
2
LIF.IR-02TPA.DR-04
GDPR — Art. 35(7); Art. 22; Art. 25; Art. 32
1
IMP.DA-02
GDPR — Art. 35; Art. 35(3); Art. 35(4)
1
IMP.DA-01
GDPR — Art. 37; Art. 38
1
GOV.RR-02
GDPR — Art. 4(11); Art. 6(1)(a); Art. 7; Art. 8; Art. 9(2)(a)
1
DAT.LB-04
GDPR — Art. 4(5); Recital 26
1
DAT.SY-03
GDPR — Art. 4(7); Art. 4(8); Art. 13; Art. 14; Art. 26; Art. 28; Art. 31
1
TPA.CT-05
GDPR — Art. 44; Art. 45; Art. 46(2)(c); Art. 49; Art. 30
1
DAT.LB-05
GDPR — Art. 4; Art. 6; Art. 9; Art. 22; Art. 24; Art. 35; Art. 37
1
CON.JU-04
GDPR — Art. 5
1
DAT.PO-01
GDPR — Art. 5(1)(a)
2
DAT.PR-01DAT.BI-01
GDPR — Art. 5(1)(a); Art. 5(1)(f); Art. 32
1
GOV.AU-01
GDPR — Art. 5(1)(a); Art. 6; Art. 9; Art. 30
1
DAT.LB-01
GDPR — Art. 5(1)(b); Art. 5(1)(c); Art. 25
1
DAT.RE-01
GDPR — Art. 5(1)(c); Art. 30
1
TRA.LR-02
GDPR — Art. 5(1)(c); Art. 5(1)(d); Art. 6
1
TPA.DR-03
GDPR — Art. 5(1)(c); Art. 5(1)(e); Art. 32
1
TRA.AG-02
GDPR — Art. 5(1)(e); Art. 17
1
DAT.RE-02
GDPR — Art. 5(1)(e); Art. 17(1)
1
LIF.DC-03
GDPR — Art. 5(1)(e); Art. 17(1); Art. 32
1
DAT.RE-03
GDPR — Art. 5(1)(e); Art. 30
2
GOV.DI-01DAT.IN-04
GDPR — Art. 5(1)(e); Art. 32
1
TRA.LR-03
GDPR — Art. 5(1)(f); Art. 32
3
GOV.AU-02DAT.LK-02DAT.LK-03
GDPR — Art. 5(1)(f); Art. 32; Art. 33
1
GOV.AU-03
GDPR — Art. 5; Art. 25
1
DAT.PO-02
GDPR — Art. 5; Art. 32
1
DAT.LK-01
GDPR — Art. 5; Art. 9; Art. 25; Art. 30
1
DAT.IN-02
GDPR — Art. 6; Art. 7; Art. 9; Art. 89
1
LIF.VA-06
GDPR — Art. 82
1
HUM.UA-04
GDPR — Art. 9; Art. 13; Art. 14
1
TRA.UD-03
NIS 21 references · 1 unique Controls
Reference
Controls
Satisfying AIMS Controls
NIS2 (Directive (EU) 2022/2555) — Art. 23 (where applicable)
1
TPA.DR-04
ENISA2 references · 2 unique Controls
Reference
Controls
Satisfying AIMS Controls
ENISA Multilayer Framework for AI Cybersecurity
1
RSK.ID-01
ENISA Multilayer Framework for Good Cybersecurity Practices for AI
1
TPA.DD-03
UK NCSC4 references · 29 unique Controls
Reference
Controls
Satisfying AIMS Controls
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Deployment
5
LIF.DP-01LIF.DP-02LIF.DP-03LIF.IR-01LIF.IR-02
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Design
6
RSK.AR-01RSK.AR-02LIF.DE-01LIF.DE-02LIF.DE-03LIF.DE-04
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Development
9
LIF.DV-01LIF.DV-02LIF.DV-03LIF.DV-04LIF.DV-05TPA.SC-01TPA.SC-02TPA.SC-03TPA.SC-04
UK NCSC + CISA Guidelines for Secure AI System Development (2023) — Secure Operation and Maintenance
9
GOV.AU-02GOV.AU-03LIF.OP-01LIF.OP-02LIF.OP-03LIF.OP-04LIF.OP-05LIF.VR-04LIF.IR-03
ISO 238944 references · 5 unique Controls
Reference
Controls
Satisfying AIMS Controls
ISO/IEC 23894:2023 (TOC-only)
2
TRA.TD-01TRA.MC-01
ISO/IEC 23894:2023 — Cl. 6
1
RSK.ME-01
ISO/IEC 23894:2023 — Cl. 7
1
RSK.AS-01
ISO/IEC 23894:2023 — Cl. 8
1
RSK.TR-01
ISO 533837 references · 113 unique Controls
Reference
Controls
Satisfying AIMS Controls
ISO/IEC 5338:2023 — Cl. 5.3; Cl. 6.2.1
1
LIF.PO-01
ISO/IEC 5338:2023 — Cl. 6.1.1
7
LIF.DV-03TPA.DD-01TPA.DD-02TPA.DD-03TPA.DD-04TPA.CT-01TPA.SC-01
ISO/IEC 5338:2023 — Cl. 6.2.1
1
LIF.PO-03
ISO/IEC 5338:2023 — Cl. 6.2.2
4
GOV.LD-02GOV.AU-02LIF.DV-02LIF.TR-02
ISO/IEC 5338:2023 — Cl. 6.2.2; Cl. 6.4.15
1
LIF.AG-04
ISO/IEC 5338:2023 — Cl. 6.2.4
5
GOV.AU-01GOV.CO-01GOV.CO-02GOV.CO-03GOV.CO-04
ISO/IEC 5338:2023 — Cl. 6.2.6
1
GOV.OV-07
ISO/IEC 5338:2023 — Cl. 6.3.2
1
LIF.PO-02
ISO/IEC 5338:2023 — Cl. 6.3.4
23
RSK.ME-01RSK.ME-02RSK.ME-03RSK.ME-04RSK.ID-01RSK.ID-02RSK.ID-03RSK.AS-01RSK.AS-02RSK.AS-03RSK.TR-01RSK.TR-02RSK.TR-03RSK.RG-01RSK.RG-02RSK.RG-03RSK.AR-01RSK.AR-02RSK.AR-03RSK.AR-04RSK.MO-01RSK.MO-02RSK.MO-03
ISO/IEC 5338:2023 — Cl. 6.3.5
5
LIF.DV-05LIF.VR-01LIF.VR-02LIF.VR-03LIF.VR-04
ISO/IEC 5338:2023 — Cl. 6.3.6
1
LIF.TR-03
ISO/IEC 5338:2023 — Cl. 6.3.7
1
GOV.OV-01
ISO/IEC 5338:2023 — Cl. 6.3.8
1
GOV.OV-03
ISO/IEC 5338:2023 — Cl. 6.4.11
2
LIF.VA-02LIF.VA-04
ISO/IEC 5338:2023 — Cl. 6.4.11; Cl. 6.4.12
1
LIF.DP-04
ISO/IEC 5338:2023 — Cl. 6.4.11; Cl. 6.4.13
2
LIF.VA-01LIF.VA-05
ISO/IEC 5338:2023 — Cl. 6.4.12
3
LIF.DP-01LIF.DP-02LIF.DP-03
ISO/IEC 5338:2023 — Cl. 6.4.13
2
LIF.VA-03LIF.VA-06
ISO/IEC 5338:2023 — Cl. 6.4.14
2
LIF.OP-02LIF.OP-04
ISO/IEC 5338:2023 — Cl. 6.4.14; Cl. 6.4.16
1
LIF.OP-05
ISO/IEC 5338:2023 — Cl. 6.4.15
4
GOV.AU-03LIF.OP-03LIF.IR-01LIF.IR-04
ISO/IEC 5338:2023 — Cl. 6.4.15; Cl. 6.4.14
1
LIF.OP-01
ISO/IEC 5338:2023 — Cl. 6.4.15; Cl. 6.4.16
1
LIF.IR-02
ISO/IEC 5338:2023 — Cl. 6.4.15; Cl. 6.4.17
1
LIF.AG-05
ISO/IEC 5338:2023 — Cl. 6.4.16
1
LIF.IR-05
ISO/IEC 5338:2023 — Cl. 6.4.16; Cl. 6.2.6
1
LIF.IR-03
ISO/IEC 5338:2023 — Cl. 6.4.17
3
LIF.DC-01LIF.DC-02LIF.DC-03
ISO/IEC 5338:2023 — Cl. 6.4.1; Cl. 6.4.2
1
LIF.DE-05
ISO/IEC 5338:2023 — Cl. 6.4.3
1
LIF.DE-01
ISO/IEC 5338:2023 — Cl. 6.4.4; Cl. 6.4.15
1
LIF.AG-03
ISO/IEC 5338:2023 — Cl. 6.4.4; Cl. 6.4.5
2
LIF.DE-02LIF.AG-01
ISO/IEC 5338:2023 — Cl. 6.4.5
1
LIF.DE-03
ISO/IEC 5338:2023 — Cl. 6.4.5; Cl. 6.4.15
1
LIF.AG-02
ISO/IEC 5338:2023 — Cl. 6.4.6
1
LIF.DE-04
ISO/IEC 5338:2023 — Cl. 6.4.7; Cl. 6.4.8
1
LIF.TR-04
ISO/IEC 5338:2023 — Cl. 6.4.8
25
DAT.IN-01DAT.IN-02DAT.IN-03DAT.IN-04DAT.PR-01DAT.PR-02DAT.PR-03DAT.QU-01DAT.QU-02DAT.QU-03DAT.QU-04DAT.BI-01DAT.BI-02DAT.BI-03DAT.BI-04DAT.SY-01DAT.SY-02DAT.SY-03DAT.LA-01DAT.LA-02DAT.LA-03DAT.LK-01DAT.LK-02DAT.LK-03LIF.TR-01
ISO/IEC 5338:2023 — Cl. 6.4.9
2
LIF.DV-01LIF.DV-04
NIST SP 800-2182 references · 5 unique Controls
Reference
Controls
Satisfying AIMS Controls
NIST SP 800-218A
4
LIF.DV-02LIF.DV-03LIF.DV-04LIF.TR-02
NIST SP 800-218A (SSDF for AI)
1
LIF.DV-01
OWASP113 references · 160 unique Controls
Reference
Controls
Satisfying AIMS Controls
OWASP AI Exchange
1
GOV.CO-03
OWASP AI Testing Guide — 3.0 Framework
7
RSK.ID-01LIF.PO-01LIF.PO-02LIF.DE-01LIF.DE-04LIF.DP-01TRU.PO-02
OWASP AI Testing Guide — 3.2 AI Model Testing
1
LIF.VA-05
OWASP AI Testing Guide — AITG-APP-01 (Prompt Injection); AITG-MOD-01 (Evasion Attacks); AITG-MOD-03 (Poisoned Training Sets)
1
LIF.VA-04
OWASP AI Testing Guide — AITG-APP-05 (Unsafe Outputs); AITG-APP-12 (Toxic Output); AITG-MOD-07 (Goal Alignment)
1
TRU.SA-03
OWASP AI Testing Guide — AITG-APP-10 (Content Bias); AITG-DAT-03 (Dataset Diversity and Coverage)
2
LIF.VA-03TRU.FA-02
OWASP AI Testing Guide — AITG-APP-14 (Explainability and Interpretability)
2
TRU.EX-02TRU.EX-03
OWASP AI Testing Guide — AITG-INF-05 (Fine-tuning Poisoning)
1
LIF.VR-04
OWASP AI Testing Guide — AITG-MOD-01 (Evasion Attacks); AITG-APP-08 (Embedding Manipulation)
1
TRU.RB-03
OWASP AI Testing Guide — AITG-MOD-01 (Evasion Attacks); AITG-MOD-02 (Runtime Model Poisoning); AITG-MOD-03 (Poisoned Training Sets)
1
TRU.RB-01
OWASP AI Testing Guide — AITG-MOD-01 (Evasion Attacks); AITG-MOD-06 (Robustness to New Data); AITG-INF-02 (Resource Exhaustion)
1
LIF.VA-02
OWASP AI Testing Guide — AITG-MOD-02 (Runtime Model Poisoning); AITG-MOD-06 (Robustness to New Data)
3
LIF.OP-02LIF.OP-05TRU.AC-04
OWASP AI Testing Guide — AITG-MOD-06 (Robustness to New Data)
2
LIF.OP-01TRU.RB-02
OWASP AI Testing Guide — AITG-MOD-06 (Robustness to New Data); AITG-MOD-07 (Goal Alignment)
4
LIF.VA-01TRU.AC-01TRU.AC-02TRU.AC-03
OWASP AISVS — C1
8
DAT.QU-03DAT.QU-04DAT.BI-01DAT.BI-03DAT.SY-01DAT.SY-02DAT.LA-01DAT.LA-02
OWASP AISVS — C1 (Training Data Integrity)
4
DAT.PO-02DAT.QU-01LIF.TR-01LIF.VR-03
OWASP AISVS — C10
7
TPA.DD-03TPA.CT-01TPA.CT-02TPA.SC-02TPA.SC-03TPA.SC-04TPA.DR-01
OWASP AISVS — C10 (Supply Chain Security)
2
TPA.PO-01TPA.SC-01
OWASP AISVS — C10 (Supply Chain Security); C2 (Model Lifecycle Management)
1
TPA.DD-01
OWASP AISVS — C11
4
RSK.AR-01RSK.AR-04LIF.VA-04TRU.RB-02
OWASP AISVS — C11 (Adversarial Robustness)
1
LIF.VA-02
OWASP AISVS — C11 (Adversarial Robustness); C13 (Monitoring and Logging)
1
LIF.OP-03
OWASP AISVS — C11 (Adversarial Robustness); C2 (Input Validation)
1
TRU.RB-01
OWASP AISVS — C11; C1
1
RSK.AR-02
OWASP AISVS — C12
7
TRU.PE-02TRU.PE-03TRA.TD-03TRA.MC-02TRA.IU-01TRA.IU-02TRA.UD-03
OWASP AISVS — C12 (Communication, Documentation and Disclosure)
4
TRA.PO-01TRA.TD-01TRA.MC-01TRA.UD-01
OWASP AISVS — C12 (Privacy)
4
DAT.RE-01DAT.SY-03DAT.LK-02TRU.PE-01
OWASP AISVS — C12; C14 (Human Oversight)
2
TRA.IU-03TRA.UD-04
OWASP AISVS — C12; C8 (Model Behaviour, Output Control and Safety Alignment)
1
TRA.UD-02
OWASP AISVS — C13
5
LIF.IR-02LIF.IR-03TRU.AC-04TRU.RB-04TRA.LR-03
OWASP AISVS — C13 (Monitoring and Logging)
10
GOV.AU-03LIF.OP-01LIF.OP-02LIF.IR-01TRU.AC-03TRU.FA-05TRU.OI-02TRA.LR-01TRA.LR-02TPA.DR-04
OWASP AISVS — C13 (Monitoring and Logging); C14
1
HUM.IN-02
OWASP AISVS — C13 (Monitoring and Logging); C7 (Model Behavior)
1
TRU.SA-05
OWASP AISVS — C14
13
HUM.PO-02HUM.CO-02HUM.CO-04HUM.IN-03HUM.CM-01HUM.CM-02HUM.CM-03HUM.EF-01HUM.EF-02HUM.EF-03HUM.UA-01HUM.UA-02HUM.UA-03
OWASP AISVS — C14 (Human Oversight)
4
HUM.PO-01HUM.CO-01HUM.IN-01TPA.DR-02
OWASP AISVS — C1; C12 (Privacy)
3
DAT.IN-02DAT.BI-02DAT.LK-01
OWASP AISVS — C1; C13 (Monitoring and Logging)
1
DAT.QU-02
OWASP AISVS — C1; C3
1
LIF.TR-03
OWASP AISVS — C1; C3 (Model Lifecycle Management)
1
DAT.IN-04
OWASP AISVS — C1; C3 (Model Lifecycle); C8 (Embeddings / Vector DB)
1
DAT.PR-02
OWASP AISVS — C1; C6 (Supply Chain)
2
DAT.IN-03DAT.PR-01
OWASP AISVS — C1; C8 (Memory / Embeddings / Vector DB)
1
DAT.IN-01
OWASP AISVS — C2 (Input Validation); C11
1
TRU.RB-03
OWASP AISVS — C2 (Input Validation); C3; C9 (Orchestration and Agentic Action)
1
LIF.DV-04
OWASP AISVS — C3
4
LIF.DE-01LIF.DE-04LIF.DP-03LIF.DC-03
OWASP AISVS — C3 (Model Lifecycle Management)
7
LIF.PO-01LIF.DP-01LIF.DP-02LIF.OP-05LIF.VR-01LIF.VR-04LIF.DC-01
OWASP AISVS — C3 (Model Lifecycle Management); C6 (Supply Chain)
1
LIF.DV-05
OWASP AISVS — C3 (Model Lifecycle); C4 (Infrastructure); C6 (Supply Chain)
1
LIF.DV-01
OWASP AISVS — C3; C4 (Infrastructure)
1
LIF.DE-02
OWASP AISVS — C3; C6 (Supply Chain)
1
LIF.DP-04
OWASP AISVS — C3; C7 (Model Behavior)
3
LIF.PO-02LIF.TR-04LIF.VA-05
OWASP AISVS — C3; C7 (Model Behavior); C11 (Adversarial Robustness)
1
LIF.DE-03
OWASP AISVS — C4
1
TRU.RE-03
OWASP AISVS — C4 (Data Operations and Governance)
1
TPA.DR-03
OWASP AISVS — C4 (Infrastructure)
2
LIF.TR-02TRU.RE-02
OWASP AISVS — C4 (Infrastructure); C13
1
TRU.RE-01
OWASP AISVS — C4 (Infrastructure); C5 (Access Control and Identity)
1
LIF.DV-02
OWASP AISVS — C5 (Access Control and Identity); C12 (Privacy)
1
GOV.AU-02
OWASP AISVS — C5 (Access Control and Identity); C13 (Monitoring and Logging); C14
1
HUM.IN-04
OWASP AISVS — C5 (Access Control and Identity); C9 (Orchestration and Agentic Action)
1
TPA.AT-04
OWASP AISVS — C6 (Supply Chain)
2
DAT.PR-03LIF.DV-03
OWASP AISVS — C7
4
TRU.FA-02TRU.FA-03TRU.EX-02TRU.EX-03
OWASP AISVS — C7 (Model Behavior)
6
LIF.VA-01LIF.VA-03TRU.PO-02TRU.FA-01TRU.EX-01TRU.OI-01
OWASP AISVS — C7 (Model Behavior); C12 (Privacy); C13 (Monitoring and Logging)
1
LIF.OP-04
OWASP AISVS — C7 (Model Behavior); C2 (Input Validation)
1
TRU.SA-01
OWASP AISVS — C7 (Model Behavior); C9 (Orchestration and Agentic Action)
1
LIF.VR-02
OWASP AISVS — C7; C11
1
TRU.SA-03
OWASP AISVS — C7; C14 (Human Oversight)
1
TRU.EX-04
OWASP AISVS — C7; C9
1
RSK.ID-01
OWASP AISVS — C8 (Memory / Embeddings / Vector DB); C9 (Orchestration and Agentic Action); C12 (Privacy)
1
DAT.LK-03
OWASP AISVS — C8 (Memory / Embeddings / Vector DB); C9; C10 (MCP Security)
1
LIF.AG-04
OWASP AISVS — C9 (Orchestration and Agentic Action)
2
CON.IN-03LIF.AG-03
OWASP AISVS — C9 (Orchestration and Agentic Action); C10
2
TPA.AT-01TPA.AT-02
OWASP AISVS — C9 (Orchestration and Agentic Action); C13 (Monitoring and Logging)
1
TRA.AG-01
OWASP AISVS — C9 (Orchestration and Agentic Action); C14
1
HUM.CO-03
OWASP AISVS — C9 (Orchestration and Agentic Action); C14 (Human Oversight)
1
TRU.SA-02
OWASP AISVS — C9 (Orchestration and Agentic Action); C5 (Access Control)
1
LIF.AG-01
OWASP AISVS — C9; C10
1
TPA.AT-03
OWASP AISVS — C9; C11
1
RSK.AR-03
OWASP AISVS — C9; C11 (Adversarial Robustness)
1
LIF.AG-02
OWASP AISVS — C9; C13
1
TRA.AG-02
OWASP AISVS — C9; C14 (Human Oversight)
1
LIF.AG-05
OWASP Cheat Sheets (AI Agent Security; MCP Security)
2
LIF.AG-01LIF.AG-02
OWASP Cheat Sheets (AI Agent Security; RAG Security; MCP Security; Secure AI Model Ops; Secure Coding with AI)
1
LIF.DV-04
OWASP Cheat Sheets (MCP Security; AI Agent Security)
1
LIF.AG-04
OWASP GenAI Red Teaming Guide
5
RSK.AR-04IMP.GP-04LIF.VA-04TRU.SA-03TRU.SA-04
OWASP Multi-Agentic System Threat Modelling Guide
12
CON.IN-03RSK.AR-01RSK.AR-03DAT.LK-03LIF.AG-03LIF.AG-04LIF.AG-05TRU.SA-02HUM.CO-03TRA.AG-01TPA.AT-01TPA.AT-02
OWASP Top 10 LLM
7
RSK.AR-01RSK.AR-02RSK.AR-03LIF.DV-04LIF.OP-03LIF.IR-01TRU.SA-05
OWASP Top 10 LLM (LLM01 Prompt Injection; LLM07 Hidden Context Exposure)
1
LIF.VR-02
OWASP Top 10 LLM (LLM02 Sensitive Information Disclosure)
1
DAT.LK-02
OWASP Top 10 LLM (LLM02 Sensitive Information Disclosure; LLM09 Misinformation)
1
LIF.OP-04
OWASP Top 10 LLM (LLM03 Supply Chain)
3
LIF.DV-03TPA.SC-01TPA.SC-03
OWASP Top 10 LLM (LLM03 Supply Chain; LLM04 Data and Model Poisoning)
1
LIF.DV-05
OWASP Top 10 LLM (LLM03)
2
TPA.SC-02TPA.SC-04
OWASP Top 10 LLM (LLM05 Improper Output Handling; LLM09 Misinformation)
1
TRU.SA-01
OWASP Top 10 LLM (LLM06 Excessive Agency)
1
HUM.CO-02
OWASP Top 10 MCP
2
RSK.AR-03LIF.AG-04
OWASP Top 10 for Agentic Apps
5
CON.IN-03RSK.AR-01RSK.AR-03DAT.LK-03LIF.IR-01
OWASP Top 10 for Agentic Apps (ASI01 Agent Goal Hijack; ASI06 Memory and Context Poisoning)
1
TRU.SA-02
OWASP Top 10 for Agentic Apps (ASI01 Tool Manipulation; ASI02 Tool Misuse; ASI03 Privilege Compromise)
1
TPA.AT-02
OWASP Top 10 for Agentic Apps (ASI02 Tool Misuse and Exploitation)
1
LIF.AG-02
OWASP Top 10 for Agentic Apps (ASI02 Tool Misuse; ASI03 Privilege Compromise; ASI05 Cascading Hallucinations)
1
TPA.AT-04
OWASP Top 10 for Agentic Apps (ASI03 Identity and Privilege Abuse)
1
LIF.AG-01
OWASP Top 10 for Agentic Apps (ASI04 Agent Identification)
1
TRA.MC-02
OWASP Top 10 for Agentic Apps (ASI04 Agent Identification; ASI06 Memory and Context Poisoning; ASI09 Human-Agent Trust Exploitation)
1
TRA.AG-01
OWASP Top 10 for Agentic Apps (ASI04 Agent Identification; ASI09 Human-Agent Trust Exploitation; ASI10 Rogue Agents)
1
TPA.AT-01
OWASP Top 10 for Agentic Apps (ASI04; ASI06)
1
TRA.AG-02
OWASP Top 10 for Agentic Apps (ASI04; ASI09; ASI10)
1
TPA.AT-03
OWASP Top 10 for Agentic Apps (ASI06 Memory and Context Poisoning; ASI09)
1
HUM.IN-01
OWASP Top 10 for Agentic Apps (ASI07 Insecure Inter-Agent Communication; ASI08 Cascading Failures; ASI10 Rogue Agents)
1
LIF.AG-03
OWASP Top 10 for Agentic Apps (ASI09 Human-Agent Trust Exploitation)
1
HUM.CO-03
OWASP Top 10 for Agentic Apps (ASI09 Human-Agent Trust Exploitation; ASI10 Rogue Agents)
1
LIF.AG-05
OWASP Top 10 for Agentic Apps (ASI10 Rogue Agents)
1
HUM.IN-03
MITRE2 references · 8 unique Controls
Reference
Controls
Satisfying AIMS Controls
MITRE ATLAS
7
RSK.ID-01RSK.AR-01RSK.AR-02RSK.AR-03RSK.AR-04LIF.OP-03TRU.RB-01
MITRE ATLAS — AML.T0010 (ML Supply Chain Compromise)
1
TPA.SC-03
Board Snapshot
One-page executive view as of Q2 2026. Suitable for board packs and stakeholder updates. All figures derive from the live AIMS Control Library, Risks, Actions, ISO 42001 Doc Register and EU AI Act Obligation Register. Numbers refresh whenever the cascade re-runs.
Healthy (Gap ≤ 0.49)Watch (Gap 0.50–1.25)Attention (Gap > 1.25)
AIMS-Wide Maturity
Target
6.34
Current
5.98
Gap
0.36
Total Controls
301
At Target
298 (99%)
Below Target
3 (0%)
Domain Status at a Glance
Domain
Controls
Target
Current
Gap
At Target
Below Target
Top 5 Critical Risks
3 Critical + 10 High Inherent risks across 25 total. Click into the Risks tab for full register.
ID
Title
Owner
Inherent
→
Residual
Treatment
AIR11
Shadow AI usage by employees
CISO
Critical
→
Medium
Treat
AIR01
EU AI Act GPAI obligations non-compliance
Head of AI Governance
Critical
→
Medium
Treat
AIR03
Training data IP infringement claim
General Counsel
Critical
→
Medium
Treat
AIR04
Production model drift undetected
Head of ML Engineering
High
→
Medium
Treat
AIR05
Hallucinated outputs reach customer
Head of Product (AI)
High
→
Medium
Treat
ISO 42001 Stage 1 Audit Readiness
Stage 1 minimum dossier — 7 mandatory documents the Lead Auditor will require. Drives the certification readiness narrative.
Stage 1 Mandatory Docs
7
Approved / In Operation
0
Drafting / In Review
0
Not Started
7
EU AI Act Readiness
Article-level obligation status. Next regulatory milestone shown with countdown.
Articles Tracked
30
In Scope
14
Critical Gaps
13
Next Milestone
2 Aug 2026 — Art. 50 transparency live
Action Pipeline
Treatment workstream across the 25 Risks. 39 actions not yet started; 0 in progress.
Total Actions
39
Critical
8
High
17
Medium
14
Not Started
39
EU AI Act — Obligation Tracker
Article-level register against Regulation (EU) 2024/1689 as amended by the Digital Omnibus on AI (7 May 2026). Out-of-scope obligations greyed-out.
Total Obligations
30
In Scope
14
Out of Scope
16
In Operation
1
In Progress
8
Critical Gaps
13
Timeline — Application Dates
Hover any milestone for detail.
2 Aug 2024
Entry into force
2 Feb 2025
Art. 4 + Art. 5
2 Aug 2025
GPAI obligations
2 Aug 2026
Art. 50 transparency
2 Dec 2026
New prohibitions + gen marking
2 Aug 2027
Sandbox
2 Dec 2027
Annex III HRAIS
2 Aug 2028
Annex I HRAIS
Critical Gaps — Board Attention
13 in-scope obligations not yet In Operation.
Art. 52Procedure for GPAI systemic risk designationGPAI Provider2 Aug 2025YesNot started
Role: GPAI Provider
Effective: 2 Aug 2025
In Scope: Yes
Status: Not started
Owner: —
Linked Risk: —
AIMS Library Controls: —
Linked Doc: —
Summary entry only.
Arts. 57–63AI regulatory sandboxesMember States + Provider2 Aug 2027 (deferred by Omnibus)OptionalNot started
Role: Member States + Provider
Effective: 2 Aug 2027 (deferred by Omnibus)
In Scope: Optional
Status: Not started
Owner: —
Linked Risk: —
AIMS Library Controls: —
Linked Doc: —
Summary entry only.
Art. 85Right to lodge complaintPublic2 Aug 2026Yes (handle)Not started
Role: Public
Effective: 2 Aug 2026
In Scope: Yes (handle)
Status: Not started
Owner: —
Linked Risk: —
AIMS Library Controls: —
Linked Doc: —
Summary entry only.
Art. 86Right to explanation of individual decisionDeployer2 Aug 2026 (HR-conditional)ConditionalNot started
Role: Deployer
Effective: 2 Aug 2026 (HR-conditional)
In Scope: Conditional
Status: Not started
Owner: —
Linked Risk: —
AIMS Library Controls: —
Linked Doc: —
Summary entry only.
Art. 95Codes of conduct (non-HR)Provider + Deployer2 Aug 2025YesNot started
Role: Provider + Deployer
Effective: 2 Aug 2025
In Scope: Yes
Status: Not started
Owner: —
Linked Risk: —
AIMS Library Controls: —
Linked Doc: —
Summary entry only.
Art. 4AI LiteracyProvider + Deployer2 Feb 2025YesIn Progress
Role: Provider + Deployer
Effective: 2 Feb 2025
In Scope: Yes
Status: In Progress
Owner: Head of HR
Linked Risk: AIR19
AIMS Library Controls: GOV.CO-01, GOV.CO-02, HUM.CM-01
Linked Doc: ISO 42001 Doc 17
Obligation
Providers and deployers shall take measures to ensure, to their best extent, a sufficient level of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf, taking into account technical knowledge, experience, education and training, context of use, and the persons or groups of persons on which the AI systems are used.
Our position
Rolling out the AI Literacy training programme (TRN01) to all staff. TRN02 covers AI Acceptable Use induction for new hires.
Audit evidence
Training register completion records; training-content version; per-staff completion records.
---
Art. 5Prohibited AI PracticesCross-cutting2 Feb 2025 + 2 Dec 2026YesIn Progress
Role: Cross-cutting
Effective: 2 Feb 2025 + 2 Dec 2026
In Scope: Yes
Status: In Progress
Owner: General Counsel
Linked Risk: AIR16
AIMS Library Controls: CON.JU-06, GOV.LD-01, GOV.ET-02
Linked Doc: —
Obligation
Eight original prohibited practices (subliminal techniques, exploitation of vulnerabilities, social scoring, predictive policing based on profiling, untargeted scraping for facial recognition databases, emotion inference in workplace/education, biometric categorisation by sensitive attributes, real-time remote biometric identification in public for law enforcement). The May 2026 Digital Omnibus adds two further prohibitions effective 2 December 2026: (i) AI systems that generate or manipulate non-consensual intimate material, and (ii) AI systems used to generate or manipulate child sexual abuse material (CSAM).
Our position
Pre-deployment screen per CON.JU-06 ensures no system in our portfolio (provider or deployer) qualifies as a prohibited practice. New CSAM / non-consensual intimate material prohibitions documented in the AI Acceptable Use Policy (POL02) and product-team gating.
Audit evidence
AI Inventory tab — every entry tagged with Art. 5 screening outcome; AUP version.
---
Art. 50Transparency ObligationsProvider + Deployer2 Aug 2026 (live) + 2 Dec 2026 (generative marking)YesIn Progress
Role: Provider + Deployer
Effective: 2 Aug 2026 (live) + 2 Dec 2026 (generative marking)
In Scope: Yes
Status: In Progress
Owner: Head of AI Governance
Linked Risk: AIR05, AIR18
AIMS Library Controls: TRA.UD-01, TRA.UD-02, TRU.OI-01, TRU.OI-02
Linked Doc: ISO 42001 Doc 10 (Transparency Policy)
Obligation
Providers must ensure AI systems intended to interact directly with natural persons are designed so users know they are interacting with AI (unless obvious). Generative AI providers must mark outputs as artificially generated in machine-readable form. Deployers using AI to generate or manipulate image, audio or video content (deepfakes) must disclose AI generation. Deployers of emotion-recognition or biometric-categorisation systems must inform exposed individuals. The May 2026 Omnibus shortened the grace period for generative-content marking from 6 to 3 months — new deadline **2 December 2026**.
Our position
Customer-Facing AI Assistant (AIS01), AI-Powered Search & Recommendations (AIS02) and Customer Insights AI (AIS03) all subject to Art. 50. User-facing disclaimers, AI-interaction notices, and provenance signing (via VND12) on the build plan.
Audit evidence
Product screenshots showing AI disclosure; provenance signature samples; AUP changes signed off.
---
Art. 51GPAI Systemic Risk ClassificationGPAI Provider2 Aug 2025Yes (in-house GPAI R&D)In Progress
Role: GPAI Provider
Effective: 2 Aug 2025
In Scope: Yes (in-house GPAI R&D)
Status: In Progress
Owner: Head of AI Governance
Linked Risk: AIR21
AIMS Library Controls: TPA.GP-01, IMP.GP-01, IMP.GP-02
Linked Doc: —
Obligation
A GPAI model is presumed to pose systemic risk where the cumulative compute used for training exceeds 10²⁵ floating-point operations (FLOPs), or the Commission designates it. Providers must notify the Commission within 2 weeks of meeting the threshold.
Our position
Compute usage on AIS09 (in-house foundation model R&D) is tracked. We are well below the 10²⁵ threshold today. Designation procedure (Art. 52) drafted but not invoked.
Audit evidence
Training-compute log; Article 51 monitoring procedure; designation correspondence (none to date).
---
Art. 53Obligations of GPAI ProvidersGPAI Provider2 Aug 2025YesIn Progress
Role: GPAI Provider
Effective: 2 Aug 2025
In Scope: Yes
Status: In Progress
Owner: Head of AI Governance
Linked Risk: AIR01, AIR03
AIMS Library Controls: TPA.GP-01, IMP.GP-01, IMP.GP-02, TRA.TD-01, DAT.PR-01, CON.JU-01
Linked Doc: —
Obligation
GPAI providers must: (a) maintain technical documentation per Annex XI; (b) make information available to downstream providers per Annex XII; (c) implement a policy to comply with EU copyright law; (d) publish a sufficiently detailed summary of training-data content per a Commission-supplied template.
Our position
Drafting of AIS09 technical documentation in progress. Copyright compliance + TDM opt-out check gate planned (Action AIA07). Training-data summary publication path being designed.
Audit evidence
Technical doc package; downstream-provider info pack; copyright compliance policy; published training-data summary URL.
---
Art. 55GPAI Providers with Systemic RiskGPAI Provider2 Aug 2025Conditional (below threshold today)In Progress
Role: GPAI Provider
Effective: 2 Aug 2025
In Scope: Conditional (below threshold today)
Status: In Progress
Owner: Head of AI Governance
Linked Risk: AIR21
AIMS Library Controls: TPA.GP-01, IMP.GP-01, RSK.AR-01, GOV.IR-01
Linked Doc: —
Obligation
In addition to Art. 53, providers of GPAI models with systemic risk shall: (a) perform model evaluation including adversarial testing; (b) assess and mitigate systemic risks; (c) keep track of, document, and report serious incidents and corrective measures without undue delay; (d) ensure adequate cybersecurity protection for the model and physical infrastructure.
Our position
Programme designed and partially in place. Adversarial testing process (RSK.AR-01) is live; serious incident reporting per Art. 73 has an incident response playbook (POL12, AIA26). Will activate the full Art. 55 stack if compute threshold crossed.
Audit evidence
Evaluation reports; adversarial-test results; serious-incident log; cybersecurity controls evidence.
---
Art. 56GPAI Codes of PracticeGPAI Provider2 Aug 2025YesIn Progress
Role: GPAI Provider
Effective: 2 Aug 2025
In Scope: Yes
Status: In Progress
Owner: Head of AI Governance
Linked Risk: —
AIMS Library Controls: GOV.LD-01, TPA.GP-01
Linked Doc: —
Obligation
Provides voluntary codes of practice that, until harmonised standards are published, GPAI providers may rely on to demonstrate compliance with Arts. 53 and 55.
Our position
Monitoring the AI Office Code of Practice process. Decision pending on whether to adopt as the compliance pathway for AIS09.
---
Art. 73Serious Incident ReportingProvider (HR + GPAI)2 Aug 2026Yes (GPAI)In Progress
Role: Provider (HR + GPAI)
Effective: 2 Aug 2026
In Scope: Yes (GPAI)
Status: In Progress
Owner: CISO
Linked Risk: AIR14
AIMS Library Controls: LIF.IR-01, LIF.IR-02, IMP.MO-01, TRA.LR-01
Linked Doc: ISO 42001 Doc 24 (Incident Response)
Obligation
Providers must report serious incidents to the market surveillance authority of the Member State where the incident occurred. Reporting clock is 15 days from awareness (shorter for widespread infringement or fatal incidents).
Our position
AI incident response playbook (POL12) being drafted with the 15-day clock explicit. Incident severity classification + escalation matrix in scope of action AIA27.
Audit evidence
Incident response playbook; tabletop exercise records; any incident reports filed (none to date).
---
In-Scope Obligations 14
Art. 52Procedure for GPAI systemic risk designationGPAI Provider2 Aug 2025YesNot started
Role: GPAI Provider
Effective: 2 Aug 2025
In Scope: Yes
Status: Not started
Owner: —
Linked Risk: —
AIMS Library Controls: —
Linked Doc: —
Summary entry only.
Arts. 57–63AI regulatory sandboxesMember States + Provider2 Aug 2027 (deferred by Omnibus)OptionalNot started
Role: Member States + Provider
Effective: 2 Aug 2027 (deferred by Omnibus)
In Scope: Optional
Status: Not started
Owner: —
Linked Risk: —
AIMS Library Controls: —
Linked Doc: —
Summary entry only.
Art. 85Right to lodge complaintPublic2 Aug 2026Yes (handle)Not started
Role: Public
Effective: 2 Aug 2026
In Scope: Yes (handle)
Status: Not started
Owner: —
Linked Risk: —
AIMS Library Controls: —
Linked Doc: —
Summary entry only.
Art. 86Right to explanation of individual decisionDeployer2 Aug 2026 (HR-conditional)ConditionalNot started
Role: Deployer
Effective: 2 Aug 2026 (HR-conditional)
In Scope: Conditional
Status: Not started
Owner: —
Linked Risk: —
AIMS Library Controls: —
Linked Doc: —
Summary entry only.
Art. 95Codes of conduct (non-HR)Provider + Deployer2 Aug 2025YesNot started
Role: Provider + Deployer
Effective: 2 Aug 2025
In Scope: Yes
Status: Not started
Owner: —
Linked Risk: —
AIMS Library Controls: —
Linked Doc: —
Summary entry only.
Art. 4AI LiteracyProvider + Deployer2 Feb 2025YesIn Progress
Role: Provider + Deployer
Effective: 2 Feb 2025
In Scope: Yes
Status: In Progress
Owner: Head of HR
Linked Risk: AIR19
AIMS Library Controls: GOV.CO-01, GOV.CO-02, HUM.CM-01
Linked Doc: ISO 42001 Doc 17
Obligation
Providers and deployers shall take measures to ensure, to their best extent, a sufficient level of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf, taking into account technical knowledge, experience, education and training, context of use, and the persons or groups of persons on which the AI systems are used.
Our position
Rolling out the AI Literacy training programme (TRN01) to all staff. TRN02 covers AI Acceptable Use induction for new hires.
Audit evidence
Training register completion records; training-content version; per-staff completion records.
---
Art. 5Prohibited AI PracticesCross-cutting2 Feb 2025 + 2 Dec 2026YesIn Progress
Role: Cross-cutting
Effective: 2 Feb 2025 + 2 Dec 2026
In Scope: Yes
Status: In Progress
Owner: General Counsel
Linked Risk: AIR16
AIMS Library Controls: CON.JU-06, GOV.LD-01, GOV.ET-02
Linked Doc: —
Obligation
Eight original prohibited practices (subliminal techniques, exploitation of vulnerabilities, social scoring, predictive policing based on profiling, untargeted scraping for facial recognition databases, emotion inference in workplace/education, biometric categorisation by sensitive attributes, real-time remote biometric identification in public for law enforcement). The May 2026 Digital Omnibus adds two further prohibitions effective 2 December 2026: (i) AI systems that generate or manipulate non-consensual intimate material, and (ii) AI systems used to generate or manipulate child sexual abuse material (CSAM).
Our position
Pre-deployment screen per CON.JU-06 ensures no system in our portfolio (provider or deployer) qualifies as a prohibited practice. New CSAM / non-consensual intimate material prohibitions documented in the AI Acceptable Use Policy (POL02) and product-team gating.
Audit evidence
AI Inventory tab — every entry tagged with Art. 5 screening outcome; AUP version.
---
Art. 50Transparency ObligationsProvider + Deployer2 Aug 2026 (live) + 2 Dec 2026 (generative marking)YesIn Progress
Role: Provider + Deployer
Effective: 2 Aug 2026 (live) + 2 Dec 2026 (generative marking)
In Scope: Yes
Status: In Progress
Owner: Head of AI Governance
Linked Risk: AIR05, AIR18
AIMS Library Controls: TRA.UD-01, TRA.UD-02, TRU.OI-01, TRU.OI-02
Linked Doc: ISO 42001 Doc 10 (Transparency Policy)
Obligation
Providers must ensure AI systems intended to interact directly with natural persons are designed so users know they are interacting with AI (unless obvious). Generative AI providers must mark outputs as artificially generated in machine-readable form. Deployers using AI to generate or manipulate image, audio or video content (deepfakes) must disclose AI generation. Deployers of emotion-recognition or biometric-categorisation systems must inform exposed individuals. The May 2026 Omnibus shortened the grace period for generative-content marking from 6 to 3 months — new deadline **2 December 2026**.
Our position
Customer-Facing AI Assistant (AIS01), AI-Powered Search & Recommendations (AIS02) and Customer Insights AI (AIS03) all subject to Art. 50. User-facing disclaimers, AI-interaction notices, and provenance signing (via VND12) on the build plan.
Audit evidence
Product screenshots showing AI disclosure; provenance signature samples; AUP changes signed off.
---
Art. 51GPAI Systemic Risk ClassificationGPAI Provider2 Aug 2025Yes (in-house GPAI R&D)In Progress
Role: GPAI Provider
Effective: 2 Aug 2025
In Scope: Yes (in-house GPAI R&D)
Status: In Progress
Owner: Head of AI Governance
Linked Risk: AIR21
AIMS Library Controls: TPA.GP-01, IMP.GP-01, IMP.GP-02
Linked Doc: —
Obligation
A GPAI model is presumed to pose systemic risk where the cumulative compute used for training exceeds 10²⁵ floating-point operations (FLOPs), or the Commission designates it. Providers must notify the Commission within 2 weeks of meeting the threshold.
Our position
Compute usage on AIS09 (in-house foundation model R&D) is tracked. We are well below the 10²⁵ threshold today. Designation procedure (Art. 52) drafted but not invoked.
Audit evidence
Training-compute log; Article 51 monitoring procedure; designation correspondence (none to date).
---
Art. 53Obligations of GPAI ProvidersGPAI Provider2 Aug 2025YesIn Progress
Role: GPAI Provider
Effective: 2 Aug 2025
In Scope: Yes
Status: In Progress
Owner: Head of AI Governance
Linked Risk: AIR01, AIR03
AIMS Library Controls: TPA.GP-01, IMP.GP-01, IMP.GP-02, TRA.TD-01, DAT.PR-01, CON.JU-01
Linked Doc: —
Obligation
GPAI providers must: (a) maintain technical documentation per Annex XI; (b) make information available to downstream providers per Annex XII; (c) implement a policy to comply with EU copyright law; (d) publish a sufficiently detailed summary of training-data content per a Commission-supplied template.
Our position
Drafting of AIS09 technical documentation in progress. Copyright compliance + TDM opt-out check gate planned (Action AIA07). Training-data summary publication path being designed.
Audit evidence
Technical doc package; downstream-provider info pack; copyright compliance policy; published training-data summary URL.
---
Art. 55GPAI Providers with Systemic RiskGPAI Provider2 Aug 2025Conditional (below threshold today)In Progress
Role: GPAI Provider
Effective: 2 Aug 2025
In Scope: Conditional (below threshold today)
Status: In Progress
Owner: Head of AI Governance
Linked Risk: AIR21
AIMS Library Controls: TPA.GP-01, IMP.GP-01, RSK.AR-01, GOV.IR-01
Linked Doc: —
Obligation
In addition to Art. 53, providers of GPAI models with systemic risk shall: (a) perform model evaluation including adversarial testing; (b) assess and mitigate systemic risks; (c) keep track of, document, and report serious incidents and corrective measures without undue delay; (d) ensure adequate cybersecurity protection for the model and physical infrastructure.
Our position
Programme designed and partially in place. Adversarial testing process (RSK.AR-01) is live; serious incident reporting per Art. 73 has an incident response playbook (POL12, AIA26). Will activate the full Art. 55 stack if compute threshold crossed.
Audit evidence
Evaluation reports; adversarial-test results; serious-incident log; cybersecurity controls evidence.
---
Art. 56GPAI Codes of PracticeGPAI Provider2 Aug 2025YesIn Progress
Role: GPAI Provider
Effective: 2 Aug 2025
In Scope: Yes
Status: In Progress
Owner: Head of AI Governance
Linked Risk: —
AIMS Library Controls: GOV.LD-01, TPA.GP-01
Linked Doc: —
Obligation
Provides voluntary codes of practice that, until harmonised standards are published, GPAI providers may rely on to demonstrate compliance with Arts. 53 and 55.
Our position
Monitoring the AI Office Code of Practice process. Decision pending on whether to adopt as the compliance pathway for AIS09.
---
Art. 73Serious Incident ReportingProvider (HR + GPAI)2 Aug 2026Yes (GPAI)In Progress
Role: Provider (HR + GPAI)
Effective: 2 Aug 2026
In Scope: Yes (GPAI)
Status: In Progress
Owner: CISO
Linked Risk: AIR14
AIMS Library Controls: LIF.IR-01, LIF.IR-02, IMP.MO-01, TRA.LR-01
Linked Doc: ISO 42001 Doc 24 (Incident Response)
Obligation
Providers must report serious incidents to the market surveillance authority of the Member State where the incident occurred. Reporting clock is 15 days from awareness (shorter for widespread infringement or fatal incidents).
Our position
AI incident response playbook (POL12) being drafted with the 15-day clock explicit. Incident severity classification + escalation matrix in scope of action AIA27.
Audit evidence
Incident response playbook; tabletop exercise records; any incident reports filed (none to date).
---
Art. 99PenaltiesCross-cutting2 Aug 2025Yes (exposure)In Operation
Role: Cross-cutting
Effective: 2 Aug 2025
In Scope: Yes (exposure)
Status: In Operation
Owner: General Counsel
Linked Risk: —
AIMS Library Controls: —
Linked Doc: —
Obligation
Up to €35 m or 7% of worldwide turnover for Art. 5 prohibited-practice infringements; up to €15 m or 3% for other obligations; up to €7.5 m or 1% for incorrect information to authorities. For GPAI specifically, Art. 101 imposes administrative fines up to 3% of worldwide turnover or €15 m.
Our position
Exposure register maintained by Legal. Mitigation strategy is comprehensive Art. 4, 5, 50, 53, 73 compliance.
---
Out-of-Scope Obligations 16
Arts. 64–70Governance (AI Office, AI Board)EU institutions2 Aug 2025n/a (we engage)In Operation
Role: EU institutions
Effective: 2 Aug 2025
In Scope: n/a (we engage)
Status: In Operation
Owner: —
Linked Risk: —
AIMS Library Controls: —
Linked Doc: —
Rationale to add.
Arts. 74–79Market surveillanceMember States2 Aug 2026n/a (we cooperate)In Operation
Role: Member States
Effective: 2 Aug 2026
In Scope: n/a (we cooperate)
Status: In Operation
Owner: —
Linked Risk: —
AIMS Library Controls: —
Linked Doc: —
Rationale to add.
Art. 96Commission guidelinesCommissionOngoingn/a (we monitor)In Operation
Role: Commission
Effective: Ongoing
In Scope: n/a (we monitor)
Status: In Operation
Owner: —
Linked Risk: —
AIMS Library Controls: —
Linked Doc: —
Rationale to add.
Art. 113Entry into force / application datesn/aVariousn/aIn Operation
Role: n/a
Effective: Various
In Scope: n/a
Status: In Operation
Owner: —
Linked Risk: —
AIMS Library Controls: —
Linked Doc: —
Rationale to add.
Art. 6Classification of high-risk AIProvider2 Aug 2026No (no HR products)N/A out of scope
Role: Provider
Effective: 2 Aug 2026
In Scope: No (no HR products)
Status: N/A out of scope
Owner: —
Linked Risk: —
AIMS Library Controls: —
Linked Doc: —
Why Out of Scope
We don't operate AI systems in any of the use cases listed in Annex III (employment, education, law enforcement, migration, justice, critical infrastructure, biometrics, etc.).
Art. 7Annex III amendment mechanismn/a2 Aug 2026NoN/A out of scope
Role: n/a
Effective: 2 Aug 2026
In Scope: No
Status: N/A out of scope
Owner: —
Linked Risk: —
AIMS Library Controls: —
Linked Doc: —
Rationale to add.
Arts. 8–15Requirements for HRAISProvider2 Dec 2027 (Annex III)NoN/A out of scope
Role: Provider
Effective: 2 Dec 2027 (Annex III)
In Scope: No
Status: N/A out of scope
Owner: —
Linked Risk: —
AIMS Library Controls: —
Linked Doc: —
Why Out of Scope
These cascade from Art. 6 classification. No HRAIS → no requirements engagement.
Art. 16General obligations of HRAIS providersProvider2 Dec 2027NoN/A out of scope
Role: Provider
Effective: 2 Dec 2027
In Scope: No
Status: N/A out of scope
Owner: —
Linked Risk: —
AIMS Library Controls: —
Linked Doc: —
Rationale to add.
Arts. 17–22HRAIS QMS, docs, logs, registrationProvider2 Dec 2027NoN/A out of scope
Role: Provider
Effective: 2 Dec 2027
In Scope: No
Status: N/A out of scope
Owner: —
Linked Risk: —
AIMS Library Controls: —
Linked Doc: —
Rationale to add.
Arts. 23–25Importers, distributors, value chainProvider2 Dec 2027NoN/A out of scope
Role: Provider
Effective: 2 Dec 2027
In Scope: No
Status: N/A out of scope
Owner: —
Linked Risk: —
AIMS Library Controls: —
Linked Doc: —
Rationale to add.
Arts. 26–29Deployer obligations for HRAISDeployer2 Dec 2027NoN/A out of scope
Role: Deployer
Effective: 2 Dec 2027
In Scope: No
Status: N/A out of scope
Owner: —
Linked Risk: —
AIMS Library Controls: —
Linked Doc: —
Why Out of Scope
No HRAIS deployed internally.
Art. 29aFundamental rights impact assessmentDeployer (public bodies/HR)2 Dec 2027NoN/A out of scope
Role: Deployer (public bodies/HR)
Effective: 2 Dec 2027
In Scope: No
Status: N/A out of scope
Owner: —
Linked Risk: —
AIMS Library Controls: —
Linked Doc: —
Why Out of Scope
Triggered for public bodies + private HRAIS deployers — neither applies.
Arts. 41–49Conformity assessment, CE markingProvider2 Dec 2027 (Annex III) / 2 Aug 2028 (Annex I)NoN/A out of scope
Role: Provider
Effective: 2 Dec 2027 (Annex III) / 2 Aug 2028 (Annex I)
In Scope: No
Status: N/A out of scope
Owner: —
Linked Risk: —
AIMS Library Controls: —
Linked Doc: —
Why Out of Scope
HR-only.
Art. 54Authorised representatives of GPAI providersGPAI Provider (non-EU)2 Aug 2025No (EU-established)N/A out of scope
Role: GPAI Provider (non-EU)
Effective: 2 Aug 2025
In Scope: No (EU-established)
Status: N/A out of scope
Owner: —
Linked Risk: —
AIMS Library Controls: —
Linked Doc: —
Why Out of Scope
Triggered for non-EU established GPAI providers only. We are EU-established.
Art. 71EU database for HRAISProvider (HR)2 Aug 2026NoN/A out of scope
Role: Provider (HR)
Effective: 2 Aug 2026
In Scope: No
Status: N/A out of scope
Owner: —
Linked Risk: —
AIMS Library Controls: —
Linked Doc: —
Why Out of Scope
HR-only.
Art. 72Post-market monitoring (HRAIS)Provider (HR)2 Dec 2027NoN/A out of scope
Role: Provider (HR)
Effective: 2 Dec 2027
In Scope: No
Status: N/A out of scope
Owner: —
Linked Risk: —
AIMS Library Controls: —
Linked Doc: —
Why Out of Scope
HR-only.
Glossary
Acronyms and key terms used across the AIMS Framework. 64 entries, sorted alphabetically.
AI
Artificial Intelligence — systems that perform tasks typically requiring human intelligence.
AIMS
AI Management System — the documented set of policies, processes, roles, controls and records used to govern an organisation's use of AI. ISO/IEC 42001 specifies AIMS requirements.
AISVS
AI Security Verification Standard — OWASP.
API
Application Programming Interface — a specification by which one system invokes another.
AUP
Acceptable Use Policy.
CISA
Cybersecurity and Infrastructure Security Agency — US national cyber agency.
CISO
Chief Information Security Officer.
CON
Context — AIMS Domain.
CSA
Cloud Security Alliance — issuer of the AI Controls Matrix (AICM).
DAT
Data — AIMS Domain.
DPA
Data Processing Agreement (contract) or Data Protection Authority (regulator), depending on context.
DPIA
Data Protection Impact Assessment — GDPR Article 35 obligation.
DPO
Data Protection Officer — GDPR Article 37 role.
DSM Directive
EU Directive (EU) 2019/790 on copyright in the Digital Single Market. Article 4 text-and-data-mining opt-out is material to training-data lawfulness.
ENISA
European Union Agency for Cybersecurity.
EU
European Union.
EU AI Act
Regulation (EU) 2024/1689. Risk-tier-based EU regulation of AI systems and GPAI models.
FLOPS
Floating-Point Operations per Second — measure of model training/inference compute. Used by the EU AI Act Article 51 systemic-risk threshold (10²⁵ FLOPs).
GDPR
General Data Protection Regulation — Regulation (EU) 2016/679.
GOV
Govern — AIMS Domain.
GOVERN (RMF)
NIST AI RMF "Govern" function.
GPAI
General-Purpose AI — under the EU AI Act, an AI model that can perform a wide range of distinct tasks. Carries provider obligations under Articles 53–55; systemic-risk obligations under Article 51 above the FLOPS threshold.
GRC
Governance, Risk and Compliance.
HITL
Human in the Loop — design pattern requiring human review or approval before AI output is acted on.
HUM
Human — AIMS Domain.
IEC
International Electrotechnical Commission.
IMP
Impact — AIMS Domain.
IR
Incident Response.
ISO
International Organization for Standardization.
ISO/IEC 27001
Information Security Management System (ISMS) standard. Adjacent and informative to the AIMS.
ISO/IEC 42001
AI Management System standard. The certification target for this AIMS.
KPI
Key Performance Indicator.
KRI
Key Risk Indicator.
LIF
Lifecycle — AIMS Domain.
LLM
Large Language Model — a foundation-model class that processes and generates natural-language text.
MANAGE (RMF)
NIST AI RMF "Manage" function.
MAP (RMF)
NIST AI RMF "Map" function.
MCP
Model Context Protocol — open protocol for connecting AI models to external tools and data sources.
MEASURE (RMF)
NIST AI RMF "Measure" function.
MITRE
Issuer of ATT&CK and ATLAS adversarial knowledge bases.
ML
Machine Learning — a subfield of AI in which models learn patterns from data.
NCSC
National Cyber Security Centre — UK national cyber agency.
NIS 2
Directive (EU) 2022/2555 on network and information system security.
NIST
National Institute of Standards and Technology (US).
NIST AI RMF
NIST Artificial Intelligence Risk Management Framework. Functions: GOVERN, MAP, MEASURE, MANAGE.
OECD
Organisation for Economic Co-operation and Development. Issuer of the OECD AI Principles.
OWASP
Open Worldwide Application Security Project — issuer of AISVS, AI Exchange, Top 10 for Agentic Applications, and more.
PET
Privacy-Enhancing Technology — techniques (e.g., differential privacy, federated learning) that limit identifiability of personal data used in AI.
PII
Personally Identifiable Information.
PIMS
Privacy Information Management System — adjacent management system, ISO/IEC 27701.
RAG
Retrieval-Augmented Generation — pattern where a model retrieves relevant documents at inference time to ground its output.
RAII
Responsible AI Institute.
RSK
Risk — AIMS Domain.
SaaS
Software as a Service — software delivered to customers as a hosted service.
SBOM
Software Bill of Materials — inventory of components in a software product. Useful for AI supply chain integrity (TPA.SC).
SoA
Statement of Applicability — ISO/IEC 42001 Cl. 6.1.3 document listing Annex A controls applied or excluded with rationale.
SP
Special Publication — NIST publication series (e.g., SP 800-218 SSDF, SP 800-53r5).
TDM
Text and Data Mining. Subject of DSM Directive Article 4 opt-out.
TPA
Third-Party AI — AIMS Domain.
TRA
Transparency — AIMS Domain.
TRU
Trust — AIMS Domain.
UK
United Kingdom.
US
United States.
XAI
Explainable AI — methods and tooling that produce human-understandable rationales for model outputs.
References
Reference catalogue for the AIMS — 33 entries across 4 sections.
Reference Material for Control Mapping
Authoritative sources cited inside Control Mapping blocks.
ISO/IEC 42001:2023
Information technology — Artificial intelligence — Management system. Certification target.
ISO/IEC 23894:2023
Information technology — Artificial intelligence — Guidance on risk management.
NIST AI Risk Management Framework (AI RMF 1.0)
NIST AI 100-1 (January 2023). Functions: GOVERN, MAP, MEASURE, MANAGE.
EU AI Act
Regulation (EU) 2024/1689, as amended by Digital Omnibus (7 May 2026).
EU GDPR
Regulation (EU) 2016/679.
NIS 2 Directive
Directive (EU) 2022/2555.
OECD AI Principles (2024 update)
OECD/LEGAL/0449.
OWASP AI Exchange
Living community document.
OWASP AI Security Verification Standard (AISVS)
Verification requirements for AI system security.
OWASP Top 10 for Agentic AI Applications (2026)
Threat ranking specific to agentic AI systems.
NIST SP 800-218 (SSDF)
Secure Software Development Framework.
NIST SP 800-218A
Secure software development practices for generative AI / dual-use foundation models.
UK NCSC — Guidelines for Secure AI System Development
Joint NCSC / international agency guidelines.
CSA AI Controls Matrix (AICM)
Cloud Security Alliance AI control framework.
Additional References
Reference sources held in the AIMS Reference folder for drafting context only.
ISO/IEC 38507:2022
Governance implications of the use of AI.
ISO/IEC TR 27563:2023
Security and privacy aspects of use cases — assistive technology and AI.
ISO/IEC 5338:2023
AI system life cycle processes.
ENISA Multilayer Framework for Good Cybersecurity Practices for AI
Reference-only.
Berkeley GPAIS Foundation Model Risk Profile
Reference-only.
Anthropic Responsible Scaling Policy (RSP)
Held for context only.
Online Resources
Live sources to consult when revising Controls or staying current.
EU AI Office
European AI Board (Art. 65)
Member State coordination body.
Anthropic — Claude documentation
OWASP AI Exchange (live)
NIST AI RMF Resource Center
CNIL — AI guidance (France)
French DPA guidance on AI / GDPR interface.
ICO — AI guidance (UK)
UK ICO AI and data protection guidance.
Additional References — News & Analysis
Curated sources for monitoring AI regulation and enforcement.
EUR-Lex
IAPP — Privacy & AI news
Regulatory tracker.
FPF — Future of Privacy Forum
Policy analysis.
AlgorithmWatch
EU civil-society policy analysis.
AI Index Report (Stanford HAI)
Annual capability + policy benchmark.
OECD.AI Policy Observatory
Owners
Owner Console — per-owner accountability across Risks, Actions, Policies, AI Systems, Audits and ISO 42001 Documents. 14 distinct owners with 96 total accountabilities.
Owners
14
Total Accountabilities
96
Risks Owned
25
Actions Owned
39
Per-Owner Summary
Owner
Risks
Actions
Policies
AI Systems
Audits
Docs
Total
Head of AI Governance
6
8
6
5
0
0
25
CISO
6
11
3
0
0
0
20
Head of ML Engineering
4
6
1
4
0
0
15
General Counsel
3
6
0
0
0
0
9
Head of Product (AI)
1
2
0
3
0
0
6
Head of Vendor Management
2
2
1
0
0
0
5
DPO
1
2
1
0
0
0
4
Internal Audit function
0
0
0
0
3
0
3
Chief Marketing Officer
1
1
0
0
0
0
2
External Certification Body
0
0
0
0
2
0
2
Head of HR
1
1
0
0
0
0
2
DPO function
0
0
0
0
1
0
1
Internal Audit + ML Engineering
0
0
0
0
1
0
1
Procurement + AI Governance
0
0
0
0
1
0
1
Owner Detail 14
Sorted by total accountability count (highest first). Click any owner to expand the full list.
Head of AI Governance25 accountabilities · 6 risks, 8 actions, 6 policies, 5 AI systems, 0 audits, 0 docs
Risks
AIR01 EU AI Act GPAI obligations non-compliance
AIR13 Bias in customer-facing AI outputs
AIR18 Loss of model explainability
AIR21 GPAI systemic risk threshold trigger
AIR23 Inadequate human oversight on AI decisions
AIR25 AI vendor ethical / legal stance reversal
Actions
AIA01 Draft GPAI technical documentation per Art. 53
AIA02 Implement training-data summary publication process
AIA24 Bias measurement framework + quarterly fairness evaluations
AIA25 Diverse, representative evaluation test sets
AIA32 Publish model cards + system cards for all deployed models
AIA35 Compute threshold monitoring + Article 51 systemic-risk readiness review
AIA37 Document human-AI configuration + oversight patterns per system
AIA39 Annual vendor ethical / legal posture review process
Policies
POL01 AI Policy (top-level)
POL03 AI Ethics Code of Conduct
POL05 AI Risk Management Policy
POL08 Trustworthy AI Policy
POL09 Human Oversight Policy
POL10 AI Transparency Policy
AI Systems
AIS04 Internal Sales Copilot
AIS05 Internal Support Assistant
AIS07 Document Summarisation Tool
AIS09 In-House Foundation Model R&D
AIS11 Bias & Fairness Evaluation Pipeline
CISO20 accountabilities · 6 risks, 11 actions, 3 policies, 0 AI systems, 0 audits, 0 docs
Risks
AIR06 Prompt injection attack
AIR07 Sensitive data leakage in model output
AIR11 Shadow AI usage by employees
AIR14 Article 73 serious-incident reporting failure
AIR17 Fine-tuning data poisoning
AIR22 Audit reconstruction logging gap
Actions
AIA12 Implement input sanitisation + guardrail layer for production agents
AIA13 Adversarial / red-team testing in pre-deployment validation
AIA14 Deploy DLP rules on AI output channels
AIA15 PII filtering layer on training and fine-tuning data
AIA20 Publish AI Acceptable Use Policy
AIA21 DLP / proxy block on unsanctioned consumer AI services via ISMS
AIA22 Provide sanctioned AI alternatives + employee onboarding
AIA26 AI incident response playbook with Art. 73 15-day clock
AIA27 AI incident severity classification + escalation matrix
AIA31 Training-data integrity validation pipeline + signed datasets
AIA36 Comprehensive AI decision logging (input / prompt / model / output / timestamp)
Policies
POL02 AI Acceptable Use Policy
POL04 AI Risk Appetite Statement
POL12 AI Incident Response Policy
Head of ML Engineering15 accountabilities · 4 risks, 6 actions, 1 policies, 4 AI systems, 0 audits, 0 docs
Risks
AIR04 Production model drift undetected
AIR08 Multi-agent orchestration cascading failure
AIR12 Token cost runaway
AIR20 MCP tool misuse by agent
Actions
AIA08 Deploy drift detection in production model monitoring
AIA09 Quarterly model-performance review against accuracy baselines
AIA16 Document agent boundary + authorisation policy
AIA17 Per-agent failure isolation + chaos testing
AIA23 Token rate-limit per agent / per user + alert thresholds
AIA34 MCP tool allow-list + scope-of-authority review process
Policies
POL07 AI Lifecycle Policy
AI Systems
AIS06 Engineering Coding Assistant (Claude Code)
AIS08 In-House Fine-Tuned Domain Model
AIS10 Multi-Agent Orchestration Platform
AIS12 AI-Assisted Code Review
General Counsel9 accountabilities · 3 risks, 6 actions, 0 policies, 0 AI systems, 0 audits, 0 docs
Risks
AIR03 Training data IP infringement claim
AIR15 AI output warranty over-commitment
AIR16 Customer misuse in EU AI Act High-Risk use case
Actions
AIA03 Establish copyright compliance + TDM opt-out policy
AIA06 Document data provenance + lineage for all training datasets
AIA07 TDM opt-out check gate before data ingest
AIA28 Standardise AI output warranty + limitation language in customer contracts
AIA29 AUP / ToS clause restricting EU AI Act High-Risk use cases
AIA30 Use-case attestation in customer onboarding flow
Head of Product (AI)6 accountabilities · 1 risks, 2 actions, 0 policies, 3 AI systems, 0 audits, 0 docs
Risks
AIR05 Hallucinated outputs reach customer
Actions
AIA10 Implement output disclaimer + confidence signal in user-facing features
AIA11 Require human-in-loop for high-stakes generative outputs
AI Systems
AIS01 Customer-Facing AI Assistant
AIS02 AI-Powered Search & Recommendations
AIS03 Customer Insights AI
Head of Vendor Management5 accountabilities · 2 risks, 2 actions, 1 policies, 0 AI systems, 0 audits, 0 docs
Risks
AIR09 Foundation model vendor outage
AIR10 Foundation model deprecation forcing emergency replatform
Actions
AIA18 Multi-vendor failover capability for critical foundation model paths
AIA19 Vendor model-lifecycle tracking register + migration plan template
Policies
POL11 Third-Party AI Policy
DPO4 accountabilities · 1 risks, 2 actions, 1 policies, 0 AI systems, 0 audits, 0 docs
Risks
AIR02 GDPR Article 22 automated-decision violation
Actions
AIA04 Implement human-review path for automated decisions
AIA05 Lawful-basis register for AI-driven personal-data processing
Policies
POL06 AI Data Governance Policy
Internal Audit function3 accountabilities · 0 risks, 0 actions, 0 policies, 0 AI systems, 3 audits, 0 docs
Audits
AUD01 AIMS Internal Audit — Q3 2026 cycle
AUD02 AIMS Internal Audit — Q4 2026 cycle
AUD06 AI Risk Management Effectiveness Review
Chief Marketing Officer2 accountabilities · 1 risks, 1 actions, 0 policies, 0 AI systems, 0 audits, 0 docs
Risks
AIR24 Reputational damage from AI failure
Actions
AIA38 AI incident communications playbook + Board notification template
External Certification Body2 accountabilities · 0 risks, 0 actions, 0 policies, 0 AI systems, 2 audits, 0 docs
Audits
AUD03 ISO 42001 Stage 1 Audit (Readiness Review)
AUD04 ISO 42001 Stage 2 Audit (Certification Audit)
Head of HR2 accountabilities · 1 risks, 1 actions, 0 policies, 0 AI systems, 0 audits, 0 docs
Risks
AIR19 Article 4 AI literacy obligation gap
Actions
AIA33 Roll out AI literacy training programme (Art. 4 compliant)
DPO function1 accountabilities · 0 risks, 0 actions, 0 policies, 0 AI systems, 1 audits, 0 docs
Audits
AUD07 GDPR / AI Personal-Data Processing Audit
Internal Audit + ML Engineering1 accountabilities · 0 risks, 0 actions, 0 policies, 0 AI systems, 1 audits, 0 docs
Audits
AUD08 AI Model Evaluation Audit
Procurement + AI Governance1 accountabilities · 0 risks, 0 actions, 0 policies, 0 AI systems, 1 audits, 0 docs
Audits
AUD05 AI Vendor Due Diligence Audit (annual)