Critical Assessor Notice SWT3 witness anchors are a technical evidence source, comparable to penetration test reports, SOC 2 reports, or automated test results. They do not replace the assessor's independent judgment, professional expertise, or regulatory authority. Your assessment body retains full responsibility for all assessment determinations. SWT3 evidence supplements your assessment methodology; it does not substitute for it.

1. Purpose

This guide helps assessment bodies document SWT3 witness evidence verification as a repeatable procedure within their quality management system. It applies to Notified Bodies (NBs) under the EU AI Act, CMMC C3PAOs, ISO 42001 certification bodies (CBs), bank examiners conducting SR 11-7 reviews, and any accredited assessment organization that encounters SWT3 evidence.

If your organization uses SWT3 evidence in conformity assessments, your QMS must document:

Your national accreditation body (NAB) or NANDO auditor will expect to see this documentation during surveillance assessments. This guide provides a template you can adapt to your existing QMS structure.

2. Scope and Applicability

Organization TypeAccreditation StandardApplicability
EU AI Act Notified BodyISO/IEC 17065 (product certification)Art. 43 conformity assessment of high-risk AI systems.
CMMC C3PAOISO/IEC 17020 (inspection bodies)CMMC Level 2+ assessments with AI system components.
ISO 42001 Certification BodyISO/IEC 17021-1 (management system certification)AIMS certification audits (Stage 1 and Stage 2).
Bank Examiner (SR 11-7 / SR 26-2)OCC/Federal Reserve examination proceduresModel risk management reviews for AI/ML models.
Internal Audit FunctionsISO 19011 (auditing management systems)Internal assessments using SWT3 evidence.
QMS Clause References This guide uses ISO/IEC 17065 clause numbering (Clause 6.1, 6.2, 7.4, 7.6, 8.2, 8.4) as the primary reference. If your organization operates under ISO/IEC 17021-1 (CBs), ISO/IEC 17020 (C3PAOs), or ISO 19011 (internal audit), map the clause references to your standard's equivalent requirements. The concepts (evaluation, competence, records, retention) are consistent across all accreditation standards.

3. QMS Procedure Template

The following is a sample documented procedure. Adapt the structure, numbering, and format to match your existing QMS documentation conventions.

Procedure: Verification of Cryptographic Witness Evidence

Procedure ID:
[Your QMS numbering, e.g., QMS-P-XXX]
Revision:
1.0
Effective Date:
[Date]
Author:
[Quality Manager name]
Approved By:
[Technical Director name]
Review Cycle:
Annual (or upon protocol version change)

3.1 Purpose

To establish a repeatable, documented method for verifying and incorporating SWT3 cryptographic witness evidence into conformity assessments conducted by [Organization Name].

3.2 Scope

This procedure applies to all conformity assessments where the provider under assessment presents SWT3 witness anchors as evidence of operational controls. It covers anchor verification, evidence sufficiency determination, and record retention.

3.3 Definitions

TermDefinition
SWT3 Witness AnchorA cryptographic attestation record containing a SHA-256 fingerprint, procedure identifier, three evidence factors, a clearing level, and an epoch timestamp. Defined in the SWT3 Protocol Specification.
UCT ProcedureA standardized control identifier from the Unified Control Taxonomy registry (e.g., AI-GRD.1). The public registry is at swt3.ai/registry.
Clearing LevelThe metadata visibility tier (0=Analytics, 1=Standard, 2=Sensitive, 3=Classified). Higher levels reduce metadata in the anchor to protect operational security.
Audit PortalThe web-based evidence workbench accessed via a time-limited share link from the provider.

3.4 Inputs

3.5 Procedure Steps

1

Receive and Validate Share Link

Confirm the share link is valid, unexpired, and scoped to the assessment requirements. Record the token scope (basic or full), scoped articles (if any), expiry date, and issuing organization in the assessment file.

2

Review Control Matrix

Navigate the audit portal control matrix. For each procedure in the assessment scope, record: procedure ID, verdict (PASS/FAIL/INHERITED), last witnessed date, and SWT3 anchor token. Confirm that evidence falls within the assessment window.

3

Verify Anchor Integrity (Minimum Sample)

Select a minimum of 3 anchors (or 10% of anchors in scope, whichever is greater) for independent verification. For each selected anchor:

  1. Copy the full anchor token from the portal.
  2. Verify via the public verifier at sovereign.tenova.io/verify. Record result (VALID/REVOKED/NOT FOUND).
  3. For at least one anchor per assessment, perform SHA-256 fingerprint recomputation using the formula published in the SWT3 Protocol Specification. Use the assessor's own cryptographic tooling (e.g., OpenSSL, Python hashlib), not the provider's software.

Record all verification results in the Evidence Verification Log (Section 3.9).

4

Map Procedures to Assessment Requirements

Cross-reference each SWT3 procedure to the specific article, requirement, or practice being assessed. Use the crosswalk mapping provided in the audit portal or the public UCT Registry. Record the mapping in the assessment work papers.

5

Determine Evidence Sufficiency

For each assessment requirement, determine whether SWT3 evidence is:

  • Sufficient alone: The SWT3 anchor(s) fully address the requirement (typically TEST-method objectives).
  • Supplementary: SWT3 evidence addresses part of the requirement; additional evidence needed (INTERVIEW, DOCUMENT_REVIEW).
  • Not applicable: The requirement cannot be addressed by automated evidence (e.g., organizational governance, personnel training, physical security).

Document the sufficiency determination for each requirement in the assessment work papers.

6

Document Findings

Record assessment findings using the portal's findings register or the assessment body's own documentation system. For each finding, cite the specific SWT3 anchor(s) reviewed and the verification result. Follow the citation format described in Section 5 of this guide.

7

Generate and Review Report

Export the conformity report from the portal (or use the assessment body's own report template). Include the Evidence Verification Log as an annex. Submit for peer review per the assessment body's existing QMS peer review procedure.

3.6 Outputs

3.7 Records

All records generated by this procedure shall be retained per the assessment body's existing record retention policy, subject to the minimums in Section 7 of this guide.

4. Personnel Competence Requirements

Assessors using SWT3 evidence must demonstrate the following competences. These can be incorporated into your existing competence matrix (ISO/IEC 17065 Clause 7.4 or ISO/IEC 17021-1 Clause 7.2).

Competence AreaRequired KnowledgeVerification Method
Cryptographic Fundamentals Conceptual understanding of SHA-256 hashing, fingerprint verification, and tamper detection. Ability to use a cryptographic tool (e.g., OpenSSL, sha256sum) to compute a hash. Practical demonstration
SWT3 Protocol Understanding of anchor format (tier, provider, UCT, procedure, verdict, epoch, fingerprint), clearing levels (0-3), and the UCT procedure taxonomy. Review of SWT3 Specification + practical verification exercise
Framework Mapping Ability to map UCT procedure IDs to the specific assessment framework (EU AI Act articles, ISO 42001 clauses, NIST 800-53 controls, CMMC practices). Existing framework competence + crosswalk review
Evidence Sufficiency Judgment to determine when cryptographic evidence is sufficient alone vs. when supplementary evidence (interview, document review) is required. Existing assessment competence
Audit Portal Navigation Ability to navigate the audit portal, filter controls, enter findings, and generate reports. Review of Audit Portal Walkthrough
Onboarding Recommendation For assessors new to SWT3, we recommend completing the Assessor Onboarding Kit (self-paced, approximately 30 minutes) before their first assessment using SWT3 evidence. This includes a hands-on anchor verification exercise.

5. Handling Discrepancies

When the assessor's independent findings differ from SWT3 verdicts, the assessor's determination takes precedence. SWT3 is evidence, not a determination. Document discrepancies as follows:

ScenarioPossible CauseRequired Action
SWT3 says PASS, assessor finds non-conformity Different assessment scope (SWT3 tested one aspect, assessor tested another), different time period (anchor from before a regression), attestation-based control (self-declared by provider), or SWT3 procedure covers a subset of the requirement Document the discrepancy in findings. Cite both the PASS anchor and the basis for the non-conformity finding. Your finding stands. The PASS anchor provides temporal context for when the control was last verified.
SWT3 says FAIL, assessor finds conformity Provider remediated after the FAIL anchor was minted, or the FAIL relates to a different scope than the assessed requirement Verify that more recent evidence (a subsequent PASS anchor or documented remediation) exists. If so, cite the timeline: FAIL on [date], remediated on [date], PASS on [date]. If no subsequent evidence exists, investigate further before accepting conformity.
Anchor verification returns NOT FOUND Anchor was minted in local/offline mode, anchor format is malformed, or the provider's tenant has been deprovisioned Do not accept unverifiable anchors as evidence. Document the verification failure. Request alternative evidence from the provider.
Anchor verification returns REVOKED Provider issued a revocation (AI-REV.1) for the anchor. Reasons include model recall, policy violation, data contamination, consent withdrawal, regulatory order, or error correction. The revoked anchor is not valid evidence. Check if a replacement anchor exists. Document the revocation and its reason code in your findings.

6. Responsibility and Liability

Assessment Body Retains Full Responsibility The use of SWT3 evidence does not transfer assessment responsibility to the evidence provider (Tenable Nova LLC or any other party). Your assessment body is responsible for:

SWT3 witness anchors are analogous to other technical evidence sources your assessment body already uses:

Evidence TypeHow You Treat ItSWT3 Analogy
Penetration test report Review methodology, verify scope, evaluate findings. You do not re-run the pen test. Review anchor format, verify fingerprint, evaluate procedure coverage. You do not re-run the witness pipeline.
SOC 2 Type II report Review the auditor's opinion, verify the reporting period, check for exceptions. Review the verdict, verify the assessment window (epoch timestamps), check for FAIL or REVOKED anchors.
Automated test results (CI/CD) Review test coverage, verify test environment matches production, spot-check results. Review procedure coverage, verify clearing level matches deployment tier, spot-check via independent recomputation.

If an SWT3 anchor is later found to be incorrect (e.g., a PASS was issued for a control that was not actually operational), the assessment body's independent verification step (Section 3, Step 3) is the control that should have caught the discrepancy. This is consistent with how assessment bodies handle any third-party evidence source.

7. Record Retention

Retain all SWT3-related assessment records per your existing QMS retention policy. The following minimums are recommended:

Record TypeMinimum RetentionISO/IEC 17065 Clause
Evidence Verification Log Two certification cycles or 6 years, whichever is longer Clause 8.4
Anchor tokens cited in findings Same as assessment report retention Clause 8.2
Share link metadata (scope, expiry, issuer) Same as assessment report retention Clause 8.2
Sufficiency determination records Same as assessment report retention Clause 6.1
Discrepancy documentation Same as assessment report retention Clause 6.2
Anchor Permanence SWT3 anchors are immutable once minted. The fingerprint can be re-verified at any point in the future using the public verifier or by recomputing the SHA-256 hash. You do not need to archive the anchor data separately; the anchor token string itself is self-contained evidence. However, retain the verification results (your verification log) as proof of when and how you verified each anchor.

8. Management Review

Include the SWT3 verification procedure in your annual management review cycle (ISO/IEC 17065 Clause 8.6 or ISO/IEC 17021-1 Clause 9.3). Review the following:

Document management review outcomes and any corrective actions in your QMS records.

9. Initial Validation (Recommended)

Before incorporating SWT3 evidence into live assessments, we recommend a parallel validation exercise:

  1. Select one assessment engagement where the provider uses SWT3 evidence.
  2. Conduct the assessment twice: once using SWT3 evidence as supplementary evidence (per this procedure), and once using only traditional methods (document review, interviews, testing).
  3. Compare outcomes. The assessment determination should not change based on the presence or absence of SWT3 evidence. SWT3 should accelerate evidence collection, not alter conclusions.
  4. Document the comparison in your QMS as validation evidence for the new procedure.

If the parallel assessment produces different outcomes, investigate before proceeding. Possible causes: SWT3 evidence covered scope that traditional methods missed (or vice versa), temporal differences in evidence collection, or misalignment between UCT procedures and assessment requirements.

Expected Result The parallel validation should confirm that SWT3 evidence does not change your assessment determination -- it accelerates evidence collection and provides cryptographic proof of operational controls. If it changes the outcome, you have identified either a gap in your traditional methodology or a scope misalignment that should be resolved before production use.

10. Presenting SWT3 Usage to Your Accreditation Body

When your NAB or NANDO auditor reviews your QMS and encounters SWT3 evidence usage, they will likely ask:

Auditor QuestionYour Answer
"What is this evidence source?" SWT3 is a cryptographic witness protocol that produces tamper-evident records of operational control status. It is a technical evidence source comparable to automated test results or penetration test reports.
"Is this a delegation of assessment?" No. SWT3 produces evidence. Our assessors evaluate that evidence independently, verify anchor integrity, determine sufficiency, and make all assessment determinations per our documented procedure [QMS-P-XXX].
"How do you verify it?" Two methods: (1) public verifier at sovereign.tenova.io/verify (no account required), and (2) independent SHA-256 fingerprint recomputation using our own tools. Both are documented in our procedure and recorded in the Evidence Verification Log.
"Is this repeatable?" Yes. The fingerprint formula is published, open-source, and deterministic. Any assessor can independently verify any anchor at any time. The SWT3 Protocol Specification is publicly available at swt3.ai/spec.
"Has interoperability been demonstrated?" Yes. The fingerprint formula is implemented in 7 independent SDK implementations (Python, TypeScript, Rust, C#, Ruby, Swift, Go) and verified against a shared set of test vectors. All implementations produce identical fingerprints for identical inputs. The test vector suite covers 13 fingerprint scenarios, 2 signing scenarios, and 5 hash scenarios. Any implementation that passes the test vectors is interoperable.
"SWT3 evidence is continuous, but our assessments are point-in-time. How do we handle that?" Define an assessment window (start date, end date) in your assessment plan. Only consider anchors with epoch timestamps within that window. Document the window in your report. See Section 12 of this guide for detailed temporal scope guidance.
"What if the evidence provider goes away?" The anchor token itself contains all information needed for verification (procedure, factors, timestamp, fingerprint). The fingerprint formula is public. Even without the provider's infrastructure, the mathematical proof is independently verifiable. Historical anchors remain valid.
"How is assessor competence maintained?" SWT3-specific competences are documented in our competence matrix [reference Section 4 of this guide]. Assessors complete the SWT3 Assessor Onboarding Kit before their first engagement. Competence is reviewed during annual management review.

11. Interoperability Evidence

A technical evidence standard must be independently reproducible. The SWT3 fingerprint formula is implemented in 7 independent SDK implementations across different languages and runtimes:

LanguagePackageRegistry
Pythonswt3-aiPyPI
TypeScript@tenova/swt3-ainpm
Rustswt3-aicrates.io
C#swt3-aiNuGet
Rubyswt3-aiRubyGems
Swiftswt3-aiSwift Package Index
Goswt3-ai-goGo Modules

All implementations are verified against a shared test vector suite (13 fingerprint scenarios, 2 signing scenarios, 5 hash scenarios). Any implementation that passes the test vectors produces identical fingerprints for identical inputs. This means:

For Your NAB Auditor The test vectors are publicly available at swt3.ai/vectors. Your auditor can verify interoperability by downloading two different SDK implementations and confirming they produce identical output for each test vector. The protocol specification at swt3.ai/spec documents the formula.

12. Temporal Scope Guidance

SWT3 produces continuous evidence. Assessment methodologies (ISO/IEC 17065, NIST 800-53A, CMMC) are built around point-in-time or periodic assessments. This section provides formal guidance on reconciling the two.

12.1 Defining the Assessment Window

Before beginning the assessment, define the assessment window in your assessment plan:

ParameterDefinitionExample
Window Start The earliest date from which SWT3 evidence will be considered. 2026-08-01
Window End The latest date from which SWT3 evidence will be considered. Typically the date of the final portal review. 2026-10-08
Minimum Coverage The minimum number of days within the window during which at least one anchor must exist for a procedure to be considered "continuously monitored." 80% of window days (e.g., 56 of 70 days)

12.2 Evaluating Temporal Evidence

When reviewing SWT3 evidence within your assessment window:

12.3 Citing Temporal Evidence in Reports

When citing SWT3 evidence in your assessment report, always include:

  1. The assessment window (start and end dates) in the report header or methodology section.
  2. The witness date of each cited anchor (convert the epoch timestamp to a human-readable date).
  3. The total number of anchors reviewed within the window for each procedure.
  4. Any gaps in coverage and the provider's explanation.
Mapping to ISO/IEC 17065 Clause 6.1.2 requires the evaluation to be "planned, structured, and documented." Defining the assessment window in your plan and documenting temporal coverage in your report satisfies this requirement. The continuous nature of SWT3 evidence does not conflict with point-in-time assessment methodology; it provides denser evidence within the defined assessment period.

13. Anchor Citation Format for Assessment Reports

When citing SWT3 anchors in assessment reports, use the following format consistently:

Procedure: AI-GRD.1 (Guardrail Enforcement) Anchor: SWT3-E-VULTR-AI-AIGRD1-PASS-1791532800-a7c3e91f02b4 Verified: VALID (recomputed, 2026-10-09) Witnessed: 2026-10-05

For a complete worked example showing this citation format in context, see the Worked Assessment Report Example.