Document SWT3 cryptographic evidence verification as a repeatable procedure in your quality management system. For Notified Bodies, C3PAOs, certification bodies, and accredited assessment organizations.
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.
| Organization Type | Accreditation Standard | Applicability |
|---|---|---|
| EU AI Act Notified Body | ISO/IEC 17065 (product certification) | Art. 43 conformity assessment of high-risk AI systems. |
| CMMC C3PAO | ISO/IEC 17020 (inspection bodies) | CMMC Level 2+ assessments with AI system components. |
| ISO 42001 Certification Body | ISO/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 procedures | Model risk management reviews for AI/ML models. |
| Internal Audit Functions | ISO 19011 (auditing management systems) | Internal assessments using SWT3 evidence. |
The following is a sample documented procedure. Adapt the structure, numbering, and format to match your existing QMS documentation conventions.
To establish a repeatable, documented method for verifying and incorporating SWT3 cryptographic witness evidence into conformity assessments conducted by [Organization Name].
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.
| Term | Definition |
|---|---|
| SWT3 Witness Anchor | A 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 Procedure | A standardized control identifier from the Unified Control Taxonomy registry (e.g., AI-GRD.1). The public registry is at swt3.ai/registry. |
| Clearing Level | The metadata visibility tier (0=Analytics, 1=Standard, 2=Sensitive, 3=Classified). Higher levels reduce metadata in the anchor to protect operational security. |
| Audit Portal | The web-based evidence workbench accessed via a time-limited share link from the provider. |
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.
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.
Select a minimum of 3 anchors (or 10% of anchors in scope, whichever is greater) for independent verification. For each selected anchor:
sovereign.tenova.io/verify. Record result (VALID/REVOKED/NOT FOUND).Record all verification results in the Evidence Verification Log (Section 3.9).
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.
For each assessment requirement, determine whether SWT3 evidence is:
Document the sufficiency determination for each requirement in the assessment work papers.
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.
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.
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.
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 Area | Required Knowledge | Verification 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 |
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:
| Scenario | Possible Cause | Required 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. |
SWT3 witness anchors are analogous to other technical evidence sources your assessment body already uses:
| Evidence Type | How You Treat It | SWT3 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.
Retain all SWT3-related assessment records per your existing QMS retention policy. The following minimums are recommended:
| Record Type | Minimum Retention | ISO/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 |
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.
Before incorporating SWT3 evidence into live assessments, we recommend a parallel validation exercise:
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.
When your NAB or NANDO auditor reviews your QMS and encounters SWT3 evidence usage, they will likely ask:
| Auditor Question | Your 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. |
A technical evidence standard must be independently reproducible. The SWT3 fingerprint formula is implemented in 7 independent SDK implementations across different languages and runtimes:
| Language | Package | Registry |
|---|---|---|
| Python | swt3-ai | PyPI |
| TypeScript | @tenova/swt3-ai | npm |
| Rust | swt3-ai | crates.io |
| C# | swt3-ai | NuGet |
| Ruby | swt3-ai | RubyGems |
| Swift | swt3-ai | Swift Package Index |
| Go | swt3-ai-go | Go 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:
sha256sum, Python hashlib).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.
Before beginning the assessment, define the assessment window in your assessment plan:
| Parameter | Definition | Example |
|---|---|---|
| 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) |
When reviewing SWT3 evidence within your assessment window:
When citing SWT3 evidence in your assessment report, always include:
When citing SWT3 anchors in assessment reports, use the following format consistently:
For a complete worked example showing this citation format in context, see the Worked Assessment Report Example.