AI Management System standard mapped to SWT3 witness procedures. Clause-by-clause coverage for AIMS certification, internal audits, and management reviews.
Who this is for: Organizations pursuing ISO/IEC 42001 certification, internal auditors evaluating AI management system controls, certification body auditors (BSI, RvA, ANAB) conducting Stage 1/Stage 2 assessments, and compliance teams using 42001 as a baseline for EU AI Act high-risk system governance.
Certification active. ISO/IEC 42001:2023 is the first international standard for AI Management Systems. Certifications issued by BSI (UK), RvA (Netherlands), ANAB (US), and others. Major adopters include SAP, Microsoft, and Cornerstone OnDemand. EU AI Act high-risk system requirements (effective December 2, 2027) align closely with 42001 clauses, making early certification a strategic advantage.
ISO/IEC 42001 specifies requirements for establishing, implementing, maintaining, and continually improving an AI Management System (AIMS) within an organization. It follows the Harmonized Structure (HS) common to ISO management system standards (ISO 27001, ISO 9001, ISO 14001), making it integrable with existing management systems.
The standard is organized into management system clauses (4-10) plus two normative annexes:
| Clause | Title | Core Requirement |
|---|---|---|
| 4 | Context of the Organization | Understand AI-specific internal/external issues, interested parties, and scope of the AIMS |
| 5 | Leadership | Top management commitment to AI policy, roles, responsibilities, and authorities |
| 6 | Planning | AI risk assessment, AI objectives, treatment plans, and change management |
| 7 | Support | Competence, awareness, communication, and documented information for AI systems |
| 8 | Operation | AI system lifecycle management, impact assessments, data management, third-party relationships |
| 9 | Performance Evaluation | Monitoring, measurement, internal audit, and management review of AIMS effectiveness |
| 10 | Improvement | Nonconformity management, corrective actions, and continual improvement |
| Annex A | AI Controls | 39 controls across 4 themes: AI policies (A.2-A.4), AI engineering (A.5-A.7), AI operations (A.8-A.9), interested parties (A.10) |
| Annex B | Implementation Guidance | Informative guidance on implementing Annex A controls |
ISO/IEC 42001 defines what an organization must do to govern AI responsibly. SWT3 provides cryptographic evidence that those controls are active, producing timestamped, fingerprinted witness anchors for each control execution. The relationship:
During a certification audit, the auditor asks "show me evidence that this control is operating." SWT3 anchors are that evidence -- each one is independently verifiable via its SHA-256 fingerprint, with no access to the originating platform required.
Each ISO 42001 clause maps to SWT3 procedures that generate evidence of clause implementation. Coverage levels: Full = direct procedure match, Partial = procedure covers part of clause, Indirect = procedure provides supporting evidence.
| 42001 Clause | Requirement | SWT3 Procedure(s) | Coverage |
|---|---|---|---|
| 4.1 | Understanding the organization and its context | AI-GOV.6 Risk management scope | Partial |
| 4.2 | Understanding needs of interested parties | AI-GOV.1 Policy attestation | Indirect |
| 4.3 | Scope of the AIMS | AI-GOV.6 Risk management scope | Partial |
| 5.1 | Leadership and commitment | AI-GOV.1 Policy attestation | Partial |
| 5.2 | AI policy | AI-GOV.1 Acceptable use policy | Full |
| 5.3 | Roles, responsibilities, authorities | AI-HITL.1 Human oversight roles | Partial |
| 6.1 | Actions to address risks and opportunities | AI-RISK.1 Risk identificationAI-IMPACT.1 Impact assessment | Full |
| 6.2 | AI objectives and planning | AI-GOV.6 Risk management scope | Partial |
| 7.1 | Resources | AI-HW.1 Hardware attestation | Indirect |
| 7.2 | Competence | AI-HITL.1 Human oversight qualifications | Partial |
| 7.4 | Communication | AI-TRANS.1 Transparency disclosure | Partial |
| 7.5 | Documented information | AI-AUDIT.1 Audit log integrityAI-LOG.1 Logging pipeline | Full |
| 8.2 | AI risk assessment | AI-RISK.1 Risk identificationAI-SAFE.1 Safe state verification | Full |
| 8.3 | AI risk treatment | AI-GRD.1 Guardrail attestationAI-GRD.2 Output filtering | Full |
| 8.4 | AI system impact assessment | AI-IMPACT.1 Societal impactAI-DPIA.1 Data protection impact | Full |
| 8.5 | AI system lifecycle | AI-MDL.1 Model integrityAI-MDL.2 Version trackingAI-INF.1 Inference provenance | Full |
| 8.6 | Data for AI systems | AI-DATA.1 Data provenanceAI-RAG.1 Retrieval provenance | Full |
| 8.7 | Third-party and customer relationships | AI-CHAIN.1 Supply chain attestationAI-TRUST.1 Trust verification | Full |
| 9.1 | Monitoring, measurement, analysis | AI-DRIFT.1 Model drift detectionAI-PERF.1 Performance monitoring | Full |
| 9.2 | Internal audit | AI-AUDIT.1 Audit log integrityAI-AUDIT.2 External timestamp | Full |
| 9.3 | Management review | AI-GOV.1 Policy attestation | Partial |
| 10.1 | Nonconformity and corrective action | AI-INCIDENT.1 Incident detectionAI-IR.1 Incident response | Full |
| 10.2 | Continual improvement | AI-DRIFT.1 Drift detectionAI-MDL.2 Version tracking | Partial |
Annex A contains 39 AI-specific controls organized into 4 thematic groups. Each control maps to one or more SWT3 procedures.
| Control | Title | SWT3 Procedure | Evidence |
|---|---|---|---|
| A.2.2 | AI policy | AI-GOV.1 | Policy version, compliance status, review date |
| A.2.3 | Internal use policies | AI-GOV.1 | Acceptable use attestation with scope |
| A.3.2 | AI roles and responsibilities | AI-HITL.1 | Reviewer identity, role, authorization level |
| A.3.3 | Reporting AI concerns | AI-VIO.1 | Report channel, category, acknowledgment |
| A.4.3 | AI system inventory | AI-SBOM.1 | System count, inventory hash, format |
| A.4.5 | Engaging interested parties | AI-TRANS.1 | Disclosure method, content hash, recipients |
| Control | Title | SWT3 Procedure | Evidence |
|---|---|---|---|
| A.5.2 | AI system requirements | AI-GOV.6 | Scope boundary, requirements hash, review date |
| A.5.3 | AI system design and development | AI-MDL.1 | Model identifier, weight hash, version |
| A.5.4 | Data for AI systems | AI-DATA.1 | Data source, record count, collection method |
| A.5.5 | AI model development | AI-MDL.5 | Architecture, weight file hash, framework |
| A.5.6 | AI verification and validation | AI-REDTEAM.1 | Test scope, findings count, severity distribution |
| A.6.2 | Data quality management | AI-DATA.1 + AI-RAG.2 | Data provenance + relevance scoring |
| A.7.2 | Transparency and explainability | AI-EXPL.1 | Explanation method, confidence, factors cited |
| A.7.3 | Controllability and human oversight | AI-HITL.1 | Reviewer identity, override decision, rationale |
| A.7.4 | Fairness | AI-FAIR.1 | Protected attribute, disparity ratio, threshold |
| A.7.5 | Safety | AI-SAFE.1 | Risk scenario, mitigation status, safe state |
| A.7.6 | Security and resilience | AI-SEC.1 | Security control, test result, coverage |
| A.7.7 | Privacy | AI-DPIA.1 | Assessment scope, risk rating, authority |
| Control | Title | SWT3 Procedure | Evidence |
|---|---|---|---|
| A.8.2 | Recording and monitoring AI system | AI-LOG.1 + AI-AUDIT.1 | Log pipeline attestation + integrity hash |
| A.8.3 | AI performance management | AI-DRIFT.1 + AI-PERF.1 | Drift detection + performance metrics |
| A.8.4 | AI system change management | AI-MDL.2 | Previous version, current version, change summary |
| A.8.5 | AI system retirement | AI-REV.1 | Revocation target, reason code, authority |
| A.9.2 | AI system documentation | AI-SBOM.1 | Component count, SBOM hash, format |
| A.9.3 | Release management | AI-MDL.2 + AI-MDL.1 | Version tracking + integrity verification |
| Control | Title | SWT3 Procedure | Evidence |
|---|---|---|---|
| A.10.2 | Impact on individuals | AI-IMPACT.1 + AI-FAIR.1 | Impact assessment + fairness evaluation |
| A.10.3 | Notification of affected parties | AI-EXPL.1 + AI-TRANS.1 | Explanation + disclosure attestation |
| A.10.4 | Ability to opt out | AI-HITL.1 | Human override / opt-out mechanism verification |
| A.10.5 | Third-party relationships | AI-CHAIN.1 + AI-TRUST.1 | Supply chain attestation + trust verification |
42001 requires (Clause 6.1, 8.2): Organizations must determine AI-specific risks and opportunities, conduct AI risk assessments, and establish risk treatment plans. Risk assessments must consider the AI system's intended use, reasonably foreseeable misuse, and impact on affected stakeholders.
How SWT3 addresses it: The witness_risk() call captures the risk category identified, the assessed severity, and the current mitigation status. Each risk assessment cycle produces anchors that create a longitudinal record of how the organization's risk landscape evolves. Auditors can verify assessment frequency, risk categorization consistency, and treatment progress.
AI-RISK.1 anchors should cover all AI systems in the AIMS scope. Factor A identifies the risk category (technical, ethical, societal, operational). Factor B shows severity. Factor C shows mitigation status (accepted, mitigated, transferred, avoided). Pair with AI-IMPACT.1 anchors for clause 8.4 (impact assessment) evidence. Risk assessments should be refreshed at the interval specified in the organization's risk management procedure.
42001 requires (A.7.4): Organizations must implement measures to address fairness in AI systems, including identifying and managing potential biases. Fairness criteria must be defined relative to the AI system's context of use.
How SWT3 addresses it: The witness_fairness() call records the protected attribute evaluated, the measured disparity ratio, and the threshold applied. This creates evidence that the organization has defined fairness criteria and is actively measuring against them.
AI-FAIR.1 anchors should cover all protected attributes relevant to the AI system's deployment context. Factor B (disparity ratio) against Factor C (threshold) shows whether the system meets the organization's fairness criteria. During a Stage 2 audit, the auditor will verify that thresholds are documented in the risk treatment plan and that measurements are periodic.
42001 requires (Clause 9.1, A.8.3): Organizations must monitor, measure, and analyze the performance of their AIMS and AI systems. Monitoring must detect changes that could affect AI system behavior or trustworthiness.
How SWT3 addresses it: The witness_drift() call records the metric being tracked, the current measured value, and the baseline value. Drift anchors create an automated, continuous monitoring record that proves the organization is actively tracking AI system behavior against established baselines.
AI-DRIFT.1 anchors prove continuous monitoring is active. Factor A identifies the metric (accuracy, latency, token usage, output distribution). Factor B is the current value. Factor C is the baseline. Anchors should appear at regular intervals defined in the monitoring procedure. Sudden value changes in Factor B with unchanged Factor C may trigger a management review (clause 9.3) or corrective action (clause 10.1).
42001 requires (Clause 9.2): Organizations must conduct internal audits at planned intervals to confirm the AIMS conforms to requirements and is effectively implemented. Audit results must be reported to relevant management.
How SWT3 addresses it: AI-AUDIT.1 anchors attest to audit log integrity (Factor B: integrity hash, Factor C: retention period). AI-AUDIT.2 anchors provide RFC 3161 external timestamps from an independent TSA, proving when audit evidence existed. Together, they create a tamper-evident internal audit trail that a certification body can independently verify.
AI-AUDIT.1 anchors prove audit logs are intact. AI-AUDIT.2 anchors prove temporal authenticity via an independent TSA. During a Stage 2 audit, the auditor will verify: (1) audit frequency matches the planned interval, (2) audit scope covers all AIMS processes, (3) nonconformities found in audits have corresponding AI-INCIDENT.1 anchors, and (4) corrective actions have AI-IR.1 anchors showing resolution.
42001 requires (A.8.5): Organizations must establish procedures for the retirement or decommissioning of AI systems, including handling of associated data and models.
How SWT3 addresses it: The revoke() call mints an AI-REV.1 anchor targeting the fingerprint of the system being retired. The anchor records the revocation target, reason code (one of 7 standardized codes), and the authority who ordered the retirement. Once minted, the public verifier flags all subsequent verification requests for the retired system's anchors with a revocation notice.
AI-REV.1 anchors prove a controlled retirement process. Factor A identifies the revoked system. Factor B contains the reason code (model_recall, policy_violation, regulatory_order, etc.). Factor C identifies the responsible authority. The public verifier at /verify/ will display the revocation status when any anchor for the retired system is checked.
ISO/IEC 42001 certification does not automatically satisfy EU AI Act obligations, but significant overlap exists. Organizations pursuing both can use the same SWT3 evidence chain:
| ISO 42001 Clause | EU AI Act Article | SWT3 Procedure |
|---|---|---|
| 6.1 / 8.2 (Risk assessment) | Art. 9 (Risk management system) | AI-RISK.1 |
| 8.4 (Impact assessment) | Art. 27 (FRIA) | AI-IMPACT.1 + AI-DPIA.1 |
| 8.6 (Data for AI systems) | Art. 10 (Data governance) | AI-DATA.1 |
| 7.5 (Documented information) | Art. 11 (Technical documentation) | AI-AUDIT.1 |
| A.8.2 (Recording and monitoring) | Art. 12 (Record-keeping) | AI-LOG.1 |
| A.7.2 (Transparency) | Art. 13 (Transparency and information) | AI-EXPL.1 + AI-TRANS.1 |
| A.7.3 (Human oversight) | Art. 14 (Human oversight) | AI-HITL.1 |
| A.7.5 (Safety) | Art. 15 (Accuracy, robustness, security) | AI-SAFE.1 + AI-SEC.1 |
| 9.1 (Monitoring) | Art. 72 (Post-market monitoring) | AI-DRIFT.1 |
Organizations certified to 42001 with SWT3 evidence will have a substantial head start on EU AI Act high-risk compliance when obligations take effect December 2, 2027.
| Auditor Question | Where to Look |
|---|---|
| Is an AI policy established and communicated? | AI-GOV.1 anchors. Factor A shows policy version. Factor B shows compliance status. Factor C shows most recent review date. Anchors should refresh at the management review cycle. |
| Has an AI risk assessment been conducted? | AI-RISK.1 + AI-IMPACT.1 anchors. Factor A identifies risk categories. Factor B shows severity. Coverage should span all AI systems in scope per clause 4.3. |
| Are AI systems monitored for performance drift? | AI-DRIFT.1 anchors at regular intervals. Factor B (current value) vs Factor C (baseline) shows trend. Gaps in monitoring intervals indicate potential nonconformity with clause 9.1. |
| Is fairness being measured? | AI-FAIR.1 anchors covering each protected attribute. Factor B (disparity ratio) against Factor C (threshold) shows whether criteria are met. Anchors should align with the monitoring frequency in the risk treatment plan. |
| Have internal audits been conducted? | AI-AUDIT.1 + AI-AUDIT.2 anchors at planned intervals. Factor C in AI-AUDIT.1 shows retention period. AI-AUDIT.2 provides independent temporal proof via RFC 3161 tokens. |
| Are third-party AI relationships governed? | AI-CHAIN.1 + AI-TRUST.1 anchors. Factor A identifies the third party. Factor B shows attestation status. Trust Mesh verification via AI-TRUST.1 proves mutual verification occurred. |
| Is there a system retirement process? | AI-REV.1 anchors for decommissioned systems. Factor B shows reason code. The public verifier flags all anchors for retired systems. |
| Are nonconformities tracked to resolution? | AI-INCIDENT.1 (detection) paired with AI-IR.1 (response) anchors. The delta between timestamps shows time-to-resolution. Factor C in AI-IR.1 confirms corrective action was taken. |
Full SDK documentation: sovereign.tenova.io/docs
Create a free account: sovereign.tenova.io/signup