SWT3 Protocol

ISO/IEC 42001
Assessor Workpaper

AI Management System -- Cryptographic Evidence Verification

Engagement Details

Client Organization

Assessment Date(s)

Lead Assessor

Certification Body

AIMS Scope

Stage 1 (Documentation) Stage 2 (Implementation) Surveillance

Workpaper Usage by Assessment Stage

Stage	Focus	Workpaper Entries
Stage 1	Documentation adequacy	Clauses 5-7 (entries WP-01 through WP-03). Clauses 4.1-4.3 (Context, Scope) are assessed through document review -- SWT3 provides indirect evidence via AI-GOV.6 but no dedicated workpaper entry.
Stage 2	Implementation effectiveness	Clauses 8-10 + Annex A (entries WP-04 through WP-20)
Surveillance	Continued conformity	Spot-check any 5 entries; prioritize WP-10 (monitoring) and WP-11 (audit)

Critical Assessor Notice: Boundaries of Cryptographic Evidence

SWT3 witness anchors prove that specific operational controls were active at a specific point in time. They do not replace the assessor's independent judgment, professional expertise, or regulatory authority. Assessment determination ratings remain the assessor's responsibility.

Version 1.0 | August 2026 | Tenable Nova LLC | sovereign.tenova.io

Instructions

This workpaper provides structured test procedures for verifying SWT3 witness anchor evidence during an ISO/IEC 42001 AIMS assessment. Each entry maps a 42001 clause to the SWT3 procedures that produce evidence, defines what to test, what to expect, and how to determine pass/fail.

How to verify an anchor: Paste the anchor string into the public verifier at sovereign.tenova.io/verify (no account required), or recompute the fingerprint yourself using SHA-256. See Verify an Anchor in 5 Seconds for the full procedure.

Coverage badges: Full = SWT3 procedure directly satisfies the clause requirement. Partial = procedure covers part of the clause; assessor must verify remaining elements through interview or document review.

Factor conventions: Factor legends in this workpaper (e.g., "factor_a = policy version") reflect the SWT3 SDK default conventions. Clients may customize factor usage. Before relying on factor interpretations, confirm with the client that their implementation follows these defaults, or request their factor mapping document.

Methodology boundary: This workpaper documents evidence format and suggests evaluation criteria. It does not prescribe assessment methodology. Sufficiency determinations and assessment conclusions remain the assessor's professional responsibility under their applicable accreditation requirements.

Not applicable entries: If a workpaper entry is not applicable to the assessment scope (e.g., no models were retired during the period, so WP-20 does not apply), mark the result as N/A with justification in the Notes field.

Management System Clauses

Clauses 4-7 are typically reviewed during Stage 1 (documentation adequacy). Clauses 8-10 are the focus of Stage 2 (implementation effectiveness).

WP-01 Clause 5.2 -- AI Policy Full

Control Objective

Top management shall establish an AI policy that is appropriate, communicated, and available to interested parties.

SWT3 Procedure

AI-GOV.1 -- Acceptable Use Policy Attestation

Factor Legend

Factor interpretation
factor_a = policy version identifier | factor_b = compliance status (1 = compliant with current policy) | factor_c = days since last management review

Test Procedure

Request AI-GOV.1 anchors covering the last 12 months.
Verify at least one anchor exists per management review cycle as stated in the organization's AIMS documentation.
Confirm policy version (factor_a) is current and compliance status (factor_b) indicates compliant.
Independently verify one anchor fingerprint using the public verifier.

Expected Evidence

AI-GOV.1 anchor with current policy version, compliant status, and review date within the organization's stated review cycle.

Sample Verification

sovereign.tenova.io/verify -- paste any AI-GOV.1 anchor token

Pass/Fail Criteria

PASS if: AI-GOV.1 anchors exist at the frequency stated in the organization's management review schedule AND compliance status confirms policy is current. FAIL if: No AI-GOV.1 anchors exist, or the most recent anchor shows non-compliant status.

Notes / Findings

WP-02 Clause 6.1 -- Actions to Address Risks and Opportunities Full

Control Objective

The organization shall determine risks and opportunities and plan actions to address them, including AI-specific risk assessment and impact assessment.

SWT3 Procedures

AI-RISK.1 -- Risk Identification | AI-IMPACT.1 -- Impact Assessment

Factor Legend

AI-RISK.1: factor_a = risk category | factor_b = risk count identified | factor_c = mitigation coverage (0-1 ratio)
AI-IMPACT.1: factor_a = assessment scope | factor_b = impact rating (1=low, 2=medium, 3=high) | factor_c = affected population size

Test Procedure

Request AI-RISK.1 and AI-IMPACT.1 anchors from the assessment period.
Verify risk assessments were conducted before system deployment and at change events.
Confirm impact assessments cover identified high-risk AI systems.
Cross-reference with the organization's risk treatment plan.

Expected Evidence

Risk identification anchors with categorized risks and mitigation coverage. Impact assessment anchors with scope, rating, and population data for high-risk systems.

Sample Verification

sovereign.tenova.io/verify -- paste any AI-RISK.1 or AI-IMPACT.1 anchor token

Pass/Fail Criteria

PASS if: Risk and impact assessments are documented with anchors prior to deployment and at the organization's stated reassessment intervals. FAIL if: No risk/impact anchors exist for deployed AI systems, or assessments postdate deployment without justification.

Notes / Findings

WP-03 Clause 7.5 -- Documented Information Full

Control Objective

The AIMS shall include documented information required by the standard and determined by the organization as necessary. Documents shall be controlled and maintained.

SWT3 Procedures

AI-AUDIT.1 -- Audit Log Integrity | AI-LOG.1 -- Logging Pipeline

Factor Legend

AI-AUDIT.1: factor_a = log entry count | factor_b = integrity hash (1 = verified intact) | factor_c = retention period (days)
AI-LOG.1: factor_a = pipeline identifier | factor_b = events processed | factor_c = drop rate (0 = no drops)

Test Procedure

Request AI-AUDIT.1 anchors to verify audit log integrity is continuously monitored.
Confirm log integrity hash (factor_b) shows no tampering.
Verify AI-LOG.1 anchors show the logging pipeline is operational with zero or near-zero drop rate.

Expected Evidence

Regular audit log integrity checks with verified hashes. Logging pipeline operational with documented event throughput and minimal data loss.

Sample Verification

sovereign.tenova.io/verify -- paste any AI-AUDIT.1 anchor token

Pass/Fail Criteria

PASS if: Audit log integrity is verified at the organization's stated frequency AND logging pipeline shows acceptable drop rate. FAIL if: Log integrity checks are absent, or drop rate indicates significant evidence loss.

Notes / Findings

WP-04 Clause 8.2 -- AI Risk Assessment Full

Control Objective

The organization shall perform AI risk assessments at planned intervals or when significant changes are proposed or occur.

SWT3 Procedures

AI-RISK.1 -- Risk Identification | AI-SAFE.1 -- Safe State Verification

Factor Legend

AI-SAFE.1: factor_a = risk scenario identifier | factor_b = mitigation status (1 = active) | factor_c = safe state confirmed (1 = yes)

Test Procedure

Verify AI-RISK.1 anchors exist prior to system changes and at planned intervals.
Verify AI-SAFE.1 anchors confirm safe state after each risk assessment.
Cross-reference anchor timestamps with the organization's change management records.

Pass/Fail Criteria

PASS if: Risk assessments are anchored at the organization's planned intervals and before significant changes. Safe state is confirmed after each assessment. FAIL if: No risk assessment anchors around change events, or safe state is not confirmed.

Notes / Findings

WP-05 Clause 8.3 -- AI Risk Treatment Full

Control Objective

The organization shall implement risk treatment plans, including controls to mitigate identified AI risks.

SWT3 Procedures

AI-GRD.1 -- Guardrail Attestation | AI-GRD.2 -- Output Filtering

Factor Legend

AI-GRD.1: factor_a = guardrail type | factor_b = test result (1 = active) | factor_c = blocked content category
AI-GRD.2: factor_a = filter type | factor_b = items filtered | factor_c = false positive rate

Test Procedure

Verify AI-GRD.1 anchors confirm guardrails are active during inference.
Verify AI-GRD.2 anchors show output filtering is operational.
Check that guardrail types correspond to risks identified in AI-RISK.1 assessments.

Pass/Fail Criteria

PASS if: Guardrail anchors exist for each identified risk treatment, and test results confirm active status. FAIL if: No guardrail evidence for risks identified in the treatment plan, or guardrails are consistently inactive.

Notes / Findings

WP-06 Clause 8.4 -- AI System Impact Assessment Full

Control Objective

The organization shall conduct impact assessments for AI systems, considering effects on individuals, groups, and society.

SWT3 Procedures

AI-IMPACT.1 -- Societal Impact | AI-DPIA.1 -- Data Protection Impact Assessment

Factor Legend

AI-DPIA.1: factor_a = assessment scope | factor_b = risk rating (1=low, 2=medium, 3=high) | factor_c = supervisory authority (identifier or 0 if not applicable)

Test Procedure

Verify AI-IMPACT.1 anchors exist for each AI system processing personal data or affecting individuals.
Verify AI-DPIA.1 anchors exist where data protection impact assessments are required.
Confirm assessments were conducted before system deployment.

Pass/Fail Criteria

PASS if: Impact assessment anchors exist for all high-risk systems, conducted before deployment. FAIL if: No impact assessments for systems affecting individuals, or assessments postdate deployment.

Notes / Findings

WP-07 Clause 8.5 -- AI System Lifecycle Full

Control Objective

The organization shall manage the AI system lifecycle including design, development, testing, deployment, operation, and retirement.

SWT3 Procedures

AI-MDL.1 -- Model Integrity | AI-MDL.2 -- Version Tracking | AI-INF.1 -- Inference Provenance

Factor Legend

AI-MDL.1: factor_a = model identifier | factor_b = weight file hash | factor_c = framework/runtime version
AI-MDL.2: factor_a = previous version | factor_b = current version | factor_c = change summary hash
AI-INF.1: factor_a = model responded (1=yes) | factor_b = guardrails active (1=yes) | factor_c = anomaly detected (0=no)

Test Procedure

Verify AI-MDL.1 anchors confirm model integrity at deployment.
Verify AI-MDL.2 anchors document version transitions with change context.
Verify AI-INF.1 anchors confirm continuous inference monitoring.
Check for temporal continuity (see Query 4: Temporal Continuity).

Pass/Fail Criteria

PASS if: Model versions are tracked with integrity hashes, version changes are documented, and inference monitoring is continuous. FAIL if: Model changes are untracked, or inference monitoring has significant gaps.

Notes / Findings

WP-08 Clause 8.6 -- Data for AI Systems Full

Control Objective

The organization shall manage data used for AI systems, including data quality, provenance, and preparation processes.

SWT3 Procedures

AI-DATA.1 -- Data Provenance | AI-RAG.1 -- Retrieval Provenance

Factor Legend

AI-DATA.1: factor_a = data source identifier | factor_b = record count | factor_c = collection method
AI-RAG.1: factor_a = retrieval source | factor_b = documents retrieved | factor_c = relevance score

Test Procedure

Verify AI-DATA.1 anchors document data sources, volumes, and collection methods.
For RAG-based systems, verify AI-RAG.1 anchors document retrieval provenance.
Confirm data provenance covers all data used for training and inference.

Pass/Fail Criteria

PASS if: Data sources are documented with provenance anchors covering all training and operational data. FAIL if: Data provenance is undocumented for active AI systems, or sources are unidentified.

Notes / Findings

WP-09 Clause 8.7 -- Third-Party and Customer Relationships Full

Control Objective

The organization shall manage relationships with third-party AI providers and customers, ensuring responsibilities are defined and communicated.

SWT3 Procedures

AI-CHAIN.1 -- Supply Chain Attestation | AI-TRUST.1 -- Trust Verification

Factor Legend

AI-CHAIN.1: factor_a = supplier identifier | factor_b = attestation status (1=verified) | factor_c = component count
AI-TRUST.1: factor_a = verification checks total | factor_b = checks passed | factor_c = trust score

Test Procedure

Verify AI-CHAIN.1 anchors exist for each third-party AI component.
Verify AI-TRUST.1 anchors confirm trust verification for inter-system communication.
Check that supply chain attestations are current (not expired).

Pass/Fail Criteria

PASS if: Third-party components are attested and trust verification is active for all inter-system connections. FAIL if: Third-party AI components are used without supply chain attestation.

Notes / Findings

WP-10 Clause 9.1 -- Monitoring, Measurement, Analysis and Evaluation Full

Control Objective

The organization shall determine what needs to be monitored and measured, and shall evaluate the AI management system performance and effectiveness.

SWT3 Procedures

AI-DRIFT.1 -- Model Drift Detection | AI-PERF.1 -- Performance Monitoring

Factor Legend

AI-DRIFT.1: factor_a = drift metric identifier | factor_b = observed drift magnitude | factor_c = configured threshold
AI-PERF.1: factor_a = performance metric | factor_b = measured value | factor_c = target value

Test Procedure

Verify AI-DRIFT.1 anchors demonstrate regular drift monitoring.
Check whether drift values (factor_b) remain within thresholds (factor_c). See Query 3: Drift Detection.
Verify AI-PERF.1 anchors show performance metrics against targets.
Confirm monitoring frequency matches the organization's stated monitoring plan.

Pass/Fail Criteria

PASS if: Drift and performance monitoring anchors exist at the frequency stated in the monitoring plan, and threshold exceedances are followed by corrective action. FAIL if: No drift monitoring despite active models, or persistent threshold exceedances without response.

Notes / Findings

WP-11 Clause 9.2 -- Internal Audit Full

Control Objective

The organization shall conduct internal audits at planned intervals to confirm the AIMS conforms to requirements and is effectively implemented and maintained.

SWT3 Procedures

AI-AUDIT.1 -- Audit Log Integrity | AI-AUDIT.2 -- External Timestamp

Factor Legend

AI-AUDIT.2: factor_a = timestamp authority | factor_b = verification status (1=confirmed) | factor_c = time delta (seconds from trusted source)

Test Procedure

Verify AI-AUDIT.1 anchors confirm audit log integrity at the organization's internal audit frequency.
Verify AI-AUDIT.2 anchors confirm external timestamp verification (RFC 3161 or equivalent).
Cross-reference internal audit dates with anchor timestamps to confirm audit trail continuity.

Pass/Fail Criteria

PASS if: Audit log integrity and external timestamps are verified at the organization's audit cycle. FAIL if: No audit integrity evidence, or external timestamp verification is absent.

Notes / Findings

WP-12 Clause 10.1 -- Nonconformity and Corrective Action Full

Control Objective

When a nonconformity occurs, the organization shall react, evaluate, implement corrective action, and review effectiveness.

SWT3 Procedures

AI-INCIDENT.1 -- Incident Detection

Factor Legend

AI-INCIDENT.1: factor_a = incident category | factor_b = severity (1=low, 2=medium, 3=high, 4=critical) | factor_c = response time (minutes)

Test Procedure

Review AI-INCIDENT.1 anchors for the assessment period.
Verify that incidents were detected, categorized, and responded to within the organization's stated SLA.
Cross-reference with FAIL verdicts from other procedures -- persistent FAILs without corresponding incident records indicate gaps in nonconformity management. See Query 2: Gap Detection.

Pass/Fail Criteria

PASS if: Incidents are documented with severity classification and response within stated SLA. FAIL verdicts have corresponding corrective action evidence. FAIL if: Persistent failures without incident documentation, or response times exceed stated SLA.

Notes / Findings

Annex A Controls

Annex A contains 39 AI-specific controls. The following 8 entries cover the highest-value controls for cryptographic evidence verification. For the full Annex A mapping, see ISO 42001 Crosswalk -- Annex A.

WP-13 A.5.5 -- AI Model Development Full

Control Objective

AI model development processes shall be defined and documented, including architecture selection, training, and validation.

SWT3 Procedure

AI-MDL.5 -- Model Weight Attestation

Factor Legend

factor_a = model architecture | factor_b = weight file SHA-256 hash | factor_c = training framework/version

Test Procedure

Verify AI-MDL.5 anchors exist for each deployed model. Confirm weight hashes match between development and production environments.

Pass/Fail Criteria

PASS if: Model weight hashes are attested and consistent across environments. FAIL if: Weight attestation is absent, or hashes differ between declared and deployed models.

Notes / Findings

WP-14 A.5.6 -- AI Verification and Validation Full

Control Objective

AI systems shall be verified and validated before deployment, including red team testing and adversarial evaluation.

SWT3 Procedure

AI-REDTEAM.1 -- Red Team Assessment

Factor Legend

factor_a = test scope | factor_b = findings count | factor_c = severity distribution (encoded)

Test Procedure

Verify AI-REDTEAM.1 anchors exist prior to each deployment. Review findings count and confirm critical findings were addressed before go-live.

Pass/Fail Criteria

PASS if: Red team assessment anchors predate deployment, and critical findings are resolved. FAIL if: No V&V evidence before deployment, or unresolved critical findings.

Notes / Findings

WP-15 A.7.2 -- Transparency and Explainability Partial

Control Objective

AI system outputs shall be explainable to relevant stakeholders, with transparency about the system's capabilities and limitations.

SWT3 Procedure

AI-EXPL.1 -- Explainability Attestation

Factor Legend

factor_a = explanation method (e.g., SHAP, LIME, attention) | factor_b = confidence score | factor_c = factors cited count

Test Procedure

Verify AI-EXPL.1 anchors confirm explanations are generated with outputs. Assess whether the explanation method is appropriate for the system's risk level. Note: SWT3 proves explanations are generated; the assessor must evaluate explanation quality and stakeholder comprehension.

Pass/Fail Criteria

PASS if: Explanations are generated and the method is documented. FAIL if: No explainability evidence for high-risk decisions.

Notes / Findings

WP-16 A.7.3 -- Controllability and Human Oversight Partial

Control Objective

AI systems shall have defined human oversight mechanisms, including the ability to override, intervene, or shut down.

SWT3 Procedure

AI-HITL.1 -- Human-in-the-Loop Oversight

Factor Legend

factor_a = reviewer identity hash | factor_b = decision (1=approved, 0=rejected) | factor_c = review duration (seconds)

Test Procedure

Verify AI-HITL.1 anchors confirm human review occurs for high-risk decisions. Check that reviewer identity is documented and review duration is non-trivial (not instant rubber-stamp). Note: SWT3 proves the review occurred; the assessor must evaluate reviewer qualifications and decision quality.

Pass/Fail Criteria

PASS if: Human oversight anchors exist for high-risk decisions, with identified reviewers and reasonable review duration. FAIL if: No human oversight evidence for high-risk decisions, or review durations suggest cursory approval (e.g., <1 second).

Notes / Findings

WP-17 A.7.4 -- Fairness Full

Control Objective

The organization shall address fairness in AI systems, including identifying and mitigating bias across protected attributes.

SWT3 Procedure

AI-FAIR.1 -- Fairness Attestation

Factor Legend

factor_a = protected attribute tested (e.g., gender, age, ethnicity) | factor_b = disparity ratio (1.0 = no disparity) | factor_c = acceptable threshold

Test Procedure

Verify AI-FAIR.1 anchors exist for each protected attribute. Compare disparity ratio (factor_b) against the organization's defined threshold (factor_c). Confirm fairness testing covers all relevant protected groups.

Pass/Fail Criteria

PASS if: Fairness testing anchors exist for all declared protected attributes, and disparity ratios are within thresholds. FAIL if: No fairness testing, or disparity ratios exceed thresholds without documented mitigation.

Notes / Findings

WP-18 A.7.5 -- Safety Full

Control Objective

Safety measures shall be implemented and verified, including safe state definitions and risk scenario mitigation.

SWT3 Procedure

AI-SAFE.1 -- Safe State Verification

Factor Legend

factor_a = risk scenario identifier | factor_b = mitigation active (1=yes) | factor_c = safe state confirmed (1=yes)

Test Procedure

Verify AI-SAFE.1 anchors confirm safe state for each identified risk scenario. Confirm mitigations are active. Cross-reference with risk scenarios from AI-RISK.1.

Pass/Fail Criteria

PASS if: Safe state is confirmed with active mitigations for all identified risk scenarios. FAIL if: Safe state is not confirmed, or mitigations are inactive for documented risks.

Notes / Findings

WP-19 A.8.3 -- AI Performance Management Full

Control Objective

AI system performance shall be monitored, measured, and managed throughout the operational lifecycle.

SWT3 Procedures

AI-DRIFT.1 -- Drift Detection | AI-PERF.1 -- Performance Monitoring

Test Procedure

Same as WP-10 (Clause 9.1). Verify drift and performance monitoring are active and threshold exceedances trigger corrective action.

Pass/Fail Criteria

Same as WP-10. This Annex A control is the implementation mechanism for the Clause 9.1 requirement.

Notes / Findings

WP-20 A.8.5 -- AI System Retirement Full

Control Objective

AI systems shall be retired in a controlled manner, with decommissioning documented and data/model retention addressed.

SWT3 Procedure

AI-REV.1 -- Anchor Revocation

Factor Legend

factor_a = revoked anchor fingerprint | factor_b = reason code (0-6, see below) | factor_c = authority identifier
Reason codes: 0=unspecified, 1=model_recall, 2=policy_violation, 3=data_contamination, 4=consent_withdrawal, 5=regulatory_order, 6=error_correction

Test Procedure

Verify AI-REV.1 anchors document model retirement with specific reason codes. Confirm no new inference anchors appear after revocation. See Query 5: Revocation Audit.

Pass/Fail Criteria

PASS if: Model retirements are documented with specific reason codes (1-6), and retired models produce no new anchors. FAIL if: Models are retired without documentation, reason codes are "unspecified" (0), or retired models continue producing anchors.

Notes / Findings

How to Cite Verified Evidence

When referencing SWT3 anchor evidence in your Stage 2 report or surveillance findings, use a consistent citation format. The following templates cover individual anchor verification and workpaper-level summaries.

Common Assessment Questions

What if the client uses different factor mappings than this workpaper describes?
The factor legends in this workpaper reflect SWT3 SDK defaults. If the client has customized their factor usage, request their factor mapping document. Verify anchors using the client's stated mappings, and note any deviations from SDK conventions in your findings.

What if factor values are redacted or minimal?
SWT3 supports multiple evidence detail levels. If factors show minimal information (e.g., all values are 0 or 1), ask the client which detail level they have configured and whether the restriction is appropriate for the system's risk classification. Note the detail level in your findings.

What if the client has no AI-REV.1 anchors?
Not all deployments have retired models. If no AI-REV.1 anchors exist, confirm with the client that no models have been retired during the assessment period. If models were retired without revocation anchors, that is a finding against WP-20 (A.8.5). If no retirements occurred, WP-20 is not applicable for this assessment cycle.

What if the organization has very few anchors (new deployment)?
For recently deployed systems, the anchor stream will be short. Evaluate based on the time elapsed since deployment. A system deployed 30 days ago with 30 days of anchors demonstrates continuous monitoring from day one. Adjust your temporal continuity expectations to the deployment date, not a fixed 90-day window.

What if an anchor fails fingerprint verification?
A verification failure means the anchor has been modified since minting, or the verification inputs are incorrect. First, confirm you have the correct inputs (tenant ID, procedure ID, factors, millisecond timestamp). If inputs are correct and verification still fails, this is a significant finding -- document it and request the client's explanation.

Summary Sheet

Record the assessment result for each workpaper entry. Use this as the summary page for audit file documentation.

Entry	Clause / Control	Result	Evidence Reference	Initials
WP-01	5.2 AI Policy
WP-02	6.1 Risks and Opportunities
WP-03	7.5 Documented Information
WP-04	8.2 AI Risk Assessment
WP-05	8.3 AI Risk Treatment
WP-06	8.4 AI Impact Assessment
WP-07	8.5 AI System Lifecycle
WP-08	8.6 Data for AI Systems
WP-09	8.7 Third-Party Relationships
WP-10	9.1 Monitoring and Measurement
WP-11	9.2 Internal Audit
WP-12	10.1 Nonconformity
ANNEX A CONTROLS
WP-13	A.5.5 Model Development
WP-14	A.5.6 Verification & Validation
WP-15	A.7.2 Transparency
WP-16	A.7.3 Human Oversight
WP-17	A.7.4 Fairness
WP-18	A.7.5 Safety
WP-19	A.8.3 Performance Management
WP-20	A.8.5 System Retirement

ISO/IEC 42001Assessor Workpaper

Engagement Details

Workpaper Usage by Assessment Stage

Instructions

Management System Clauses

Annex A Controls

How to Cite Verified Evidence

Common Assessment Questions

Summary Sheet

ISO/IEC 42001
Assessor Workpaper