Audience
NBs, C3PAOs, ISSOs
Coverage
5 Frameworks
Legend
FULL PARTIAL CUSTOMER
| What the Assessor Asks | Which Axiom Artifact Answers | Endpoint |
|---|
| Show me your System Security Plan | OSCAL SSP (123 controls, implementation narratives) | GET /api/v1/ssp/export |
| What are your open vulnerabilities? | POA&M with auto-lifecycle, CVE scan, milestones | GET /api/v1/poam/export |
| Show me your assessment results | OSCAL AR (2,304 objectives, observations, findings) | GET /api/v1/ar/export |
| How do you monitor continuously? | Posture trend (90-day snapshots, 4-hour scan cadence) | GET /api/v1/posture-trend |
| Prove these logs haven't been tampered with | Daily Merkle rollup with proof paths | GET /api/v1/merkle/proof |
| What's your remediation roadmap? | Gap-to-Green report (9 sections, prioritized) | GET /api/v1/gap-to-green |
| Show me the AI model audit trail | AI Witness ledger (per-model, per-procedure) | GET /api/v1/ai-witness/export |
| Verify a specific compliance anchor | Public anchor verifier (client-side SHA-256) | GET /verify |
| Give me the complete evidence package | OSCAL Bundle (SSP + POA&M + AR + cross-validation) | GET /api/v1/bundle/export |
| Show me your executive compliance posture | Executive Summary (score gauge, KPIs, family breakdown) | GET /api/v1/executive-summary |
| Section | Requirement | Coverage | Axiom Artifact | Customer Supplement |
|---|
| 1 | General description of the AI system |
PARTIAL |
OSCAL SSP (system characteristics, authorization boundary, hardware/software inventory) |
User interface description, instructions for use |
| 2 | Elements and development process |
PARTIAL |
AI Witness ledger (test logs with timestamps, data provenance via AI-DATA.1, adapter lineage via AI-MDL.6, cybersecurity via AI-SEC.1). Merkle rollups (signed test reports). |
Design logic, architectural rationale, trade-offs, data cleaning methodologies |
| 3 | Monitoring, functioning, and control |
PARTIAL |
AI Witness ledger (confidence scoring via AI-EXPL.2, drift tracking via AI-MDL.3, human oversight via AI-HITL.1/AI-HITL.2) |
Foreseeable unintended outcomes, sources of risk, human oversight design rationale |
| 4 | Appropriateness of performance metrics |
CUSTOMER |
None. Axiom records metrics (factor_a/b/c) but cannot justify why those metrics are appropriate. |
Written justification of metric selection per use case (template available) |
| 5 | Risk management system (Art. 9) |
PARTIAL |
OSCAL SSP (control implementations), Gap-to-Green (prioritized remediation), POA&M (risk tracking) |
Risk management policy document, foreseeable misuse scenarios, risk acceptance statements |
| 6 | Relevant changes by the provider |
PARTIAL |
AI Witness ledger (AI-MDL.2 model version, AI-MDL.6 adapter stack). Assessment Results (dynamic updates). |
Human explanation of why changes were implemented |
| 7 | Harmonised standards applied |
PARTIAL |
Framework Crosswalk Engine (NIST, EU AI Act, CMMC mappings). OSCAL SSP (standards references). |
Justification for standards not applied in full, alternative solutions description |
| 8 | EU declaration of conformity |
CUSTOMER |
None. Axiom provides the evidence package; the declaration is a formal legal document the provider must sign. |
Formal declaration signed by provider's legal authority |
| Sub-paragraph | Requirement | Coverage | Axiom Artifact | Customer Supplement |
|---|
| 9(1) | Establish and maintain continuous risk management |
PARTIAL |
Posture trend (90-day continuous data), continuous verdicts (4-hour scan cadence) |
Written risk management policy defining strategy, roles, responsibilities |
| 9(2)(a-c) | Identify risks, foreseeable misuse, post-market evaluation |
PARTIAL |
CVE scanning with milestone remediation, posture trend (continuous post-market monitoring) |
Qualitative societal/health/fundamental rights risk assessment, foreseeable misuse documentation |
| 9(2)(d), 9(4) | Adopt targeted risk management measures |
PARTIAL |
POA&M auto-lifecycle (targeted mitigation tracked to closure), continuous verdicts (guardrail enforcement via AI-GRD.1, AI-SEC.1) |
Design rationale for why specific mitigations were chosen over alternatives |
| 9(3), 9(5) | Residual risk acceptable, user information |
PARTIAL |
Gap analysis with prioritized remediation roadmap |
Risk acceptance statement signed by leadership. Instructions for use / training materials for deployers. |
| 9(6-7) | Test to ensure consistent performance |
PARTIAL |
Continuous verdicts (4-hour scans acting as ongoing test logs) |
Formal test plans and methodologies. Real-world testing consent forms if Art. 60 applies. |
| 9(8) | Test against prior defined metrics and thresholds |
FULL |
SWT3 factor matrix: factor_a = threshold, factor_b = observed, factor_c = delta. Every anchor is a threshold test. |
-- |
| 9(9) | Consideration of vulnerable groups |
CUSTOMER |
AI-FAIR.1 captures bias measurements, but cannot assess cognitive/physical impact on vulnerable populations. |
Fundamental Rights Impact Assessment specifically analyzing impacts on minors and vulnerable groups |
| Sub-requirement | Coverage | Axiom Evidence | Notes |
|---|
| 12(1): Automatic recording of events |
FULL |
Every SWT3 anchor is an automatic log entry with millisecond-precision timestamp. Merkle rollup provides tamper-evident lifetime proof. |
-- |
| 12(2)(a): Identifying risks and modifications |
FULL |
AI-MDL.2 (model version), AI-MDL.6 (adapter stack), AI-RAG.1 (context sources), AI-CHAIN.1 (agent handoffs). Verdict PASS/FAIL captures risk situations. |
-- |
| 12(2)(b): Post-market monitoring |
FULL |
AI-MDL.3 (model drift), AI-FAIR.1 (bias measurement), AI-SKILL.1 (capability tracking). factor_a/b/c provide continuous metrics. |
-- |
| 12(2)(c): Monitoring system operation |
FULL |
AI-INF.2 (latency), AI-INF.3 (volume), AI-TRUST.2 (inter-system boundaries). Ledger stores ai_latency_ms, token counts. |
-- |
| 12(3)(a): Period of each use (biometrics) |
FULL |
timestamp_ms (start) + ai_latency_ms (duration) = complete use period. |
-- |
| 12(3)(b): Reference database checked |
FULL |
AI-RAG.1 (corpus identifiers), AI-SKILL.2 (memory sources). Stored in structured evidence fields. |
-- |
| 12(3)(c): Input data leading to match |
PARTIAL |
ai_prompt_hash stored (SHA-256). Raw input available only at Clearing Level 0. |
Biometric systems must operate at Clearing Level 0 to retain raw input data per this requirement. |
| 12(3)(d): Natural persons in verification |
FULL |
AI-HITL.3 (Reviewer Identity Binding) captures the identity of the natural person who performed verification. |
-- |
| Element | Requirement | Coverage | Axiom Artifact | Customer Supplement |
|---|
| (a) | Strategy for regulatory compliance and modifications |
PARTIAL |
Policy documents (compliance/planning families). Executive summary reports. |
Product-specific regulatory strategy document |
| (b) | Design, design control, design verification |
PARTIAL |
Policy documents (System Acquisition/SDLC). 2,304 assessment objectives (design verification criteria). |
Architectural diagrams, design logic, UX rationale |
| (c) | Development, quality control, quality assurance |
CUSTOMER |
Policy framework documents only. |
Developer handbooks, peer-review standards, QA operational manuals |
| (d) | Examination, test, validation procedures |
PARTIAL |
2,304 assessment objectives (standardized test procedures). CVE vulnerability management (automated security testing). |
AI-specific functional test plans (accuracy, bias, real-world performance) |
| (e) | Technical specifications and standards |
PARTIAL |
Policy documents. Assessment objectives (mapped to NIST/CMMC standards). |
Justification for standards not applied in full |
| (f) | Data management (collection, labeling, storage) |
PARTIAL |
Policy documents (Media Protection, Information Integrity). SWT3 witnesses data provenance (AI-DATA.1/2) and retrieval (AI-RAG.1). |
Data collection methodologies, annotation/labeling instructions, data cleaning processes |
| (g) | Risk management system (Art. 9) |
PARTIAL |
POA&M auto-lifecycle. CVE vulnerability management with SLA milestones. |
Overarching risk management plan (societal, psychological, fundamental rights risks) |
| (h) | Post-market monitoring system (Art. 72) |
PARTIAL |
CVE scanning (continuous post-market environment monitoring). POA&M lifecycle (post-market remediation tracking). |
Formal post-market monitoring plan document |
| (i) | Reporting serious incidents (Art. 73) |
PARTIAL |
Incident Response policy documents. Audit events table (platform incidents). AI-VIO.1 (violation reporting), AI-SEC.1 (adversarial alerts). |
Manual regulatory notification workflow: who notifies authorities, within what deadlines |
| (j) | Communication with authorities and customers |
CUSTOMER |
Executive summary reports (exportable compliance status). |
Communication strategy, designated liaison personnel |
| (k) | Record-keeping |
PARTIAL |
Audit events table (login, export, attest, key lifecycle). Sovereign witness ledger (all compliance events). Daily Merkle rollups. |
Procedures for non-technical corporate records (training certificates, vendor contracts) |
| (l) | Resource management |
CUSTOMER |
Policy documents (Supply Chain Risk Management). |
Corporate budgets, staffing org charts, supply chain logistics |
SWT3 v6.0 introduces lifecycle chains: multi-anchor sequences linked by a shared cycle ID. Three new procedures provide structured evidence across multiple frameworks.
The Axiom auditor portal streamlines the conformity assessment but does not fully satisfy Annex VII procedural requirements. An NB will still require interaction modes outside the portal.
| NB Requirement | Coverage | Axiom Provides | What the NB Still Needs |
|---|
| Technical documentation review |
FULL |
Token-based auditor portal: control checklist, evidence chain, assessment objectives, findings, monitoring dashboard, full export package. |
-- |
| Physical / virtual site visits (Annex VII 5.2) |
CUSTOMER |
N/A |
Provider must grant access to development/testing premises. |
| Independent test execution (Annex VII 4.4) |
CUSTOMER |
N/A |
Provider must provide API access or compute environment for NB's own test vectors. |
| Raw data and model access (Annex VII 4.3, 4.5) |
CUSTOMER |
Clearing Levels 1-3 strip raw data by design. |
Separate secure data room or API for NB access to training/validation datasets and model weights. |
| Qualitative interviews (Annex IV rationale) |
CUSTOMER |
N/A |
NB interviews with management, engineering, compliance staff to assess design rationale and trade-offs. |
| Control | Requirement | Coverage | Axiom Artifact |
|---|
| AU-2 | Event Logging |
FULL |
Audit event log (admin actions) + witness ledger (system events). Every anchor is a distinct logged event. |
| AU-3 | Content of Audit Records |
FULL |
Fingerprint formula captures: what (procedure_id), when (timestamp_ms), outcome (factor_c, verdict), identity (tenant_id, agent_id). audit_events captures: user, IP, action, details. |
| AU-4 | Audit Log Storage Capacity |
FULL |
PostgreSQL backend with scalable storage. Batch ingestion up to 500 anchors per request. |
| AU-5 | Response to Logging Failures |
FULL |
SDK dead-letter queue (5,000 cap) with exponential backoff retry. Error advisory system (SI-11) with AXM-XXXX reference codes. |
| AU-6 | Audit Review, Analysis, Reporting |
FULL |
Deterministic adjudicator (automated review). Dashboard: Sovereign Score, 30-day posture trends, drift tracking, filterable ledger. |
| AU-7 | Audit Reduction and Report Generation |
FULL |
OSCAL exports, Gap-to-Green report, executive summary. Reduces raw ledger into actionable reports without altering original anchors. |
| AU-8 | Time Stamps |
FULL |
Millisecond-precision Unix timestamp (timestamp_ms) cryptographically bound into every fingerprint. |
| AU-9 | Protection of Audit Information |
FULL |
Daily Merkle rollups (tamper-evident). HMAC-SHA256 payload signing. Row Level Security (tenant isolation). AES-256-GCM key encryption at rest. |
| AU-10 | Non-repudiation |
FULL |
HMAC-SHA256 payload signatures validated against tenant's registered signing key. |
| AU-11 | Audit Record Retention |
FULL |
Tier-based retention (OPEN=90 days, Pro/Enclave=extended). Clearing engine resolves GDPR erasure vs. retention: raw data purged, mathematical anchor retained indefinitely. |
| AU-12 | Audit Record Generation |
FULL |
SWT3 SDKs deployed in customer infrastructure generate records. Configurable procedure selection via Universal Control Taxonomy. |
| Requirement | Coverage | Axiom Artifact | Customer Supplement |
|---|
| Automated scan execution |
FULL |
123 technical controls scanned every 4 hours. POA&M auto-open on FAIL, auto-close on PASS. |
-- |
| Posture reporting and trend analysis |
FULL |
Posture trend API (daily snapshots, 90 days). Sovereign Score. Executive summary. |
-- |
| ConMon strategy document |
CUSTOMER |
Axiom executes the monitoring. The strategy document is organizational. |
Written ConMon strategy: risk tolerance, metrics selection, monitoring frequencies per control, alignment with mission. |
| Manual assessment triggers (PE, PS, AT families) |
CUSTOMER |
N/A. Axiom monitors software/infrastructure. Physical, personnel, and training controls require manual assessment. |
Manual assessment schedule and triggers for non-technical controls. |
| Requirement | Coverage | Axiom Artifact | Customer Supplement |
|---|
| Audit/telemetry integrity |
FULL |
Merkle rollups (domain-separated hashing), HMAC-SHA256 signing, OSCAL export hashes. |
-- |
| AI model integrity |
FULL |
AI-MDL.1 (model hash verification), AI-MDL.5 (weight file SHA-256). |
-- |
| SI-7(1): General file integrity monitoring (OS files) |
CUSTOMER |
Axiom monitors AI model weights, not host OS files. |
Deploy AIDE, OSSEC, or Tripwire for OS-level FIM. |
| SI-7(5): Automated response to violations |
PARTIAL |
Trust Mesh can deny handshakes to untrusted agents (AI-TRUST.1). SDK is non-blocking by design. |
Host-based automated response tools for OS-level integrity violations. |
| SI-7(9-10): Boot-time integrity |
CUSTOMER |
N/A. Axiom initializes after OS boot. |
UEFI Secure Boot, TPM attestation. |
A C3PAO evaluates 110 practices across 14 domains. Each practice requires three evidence types:
| Evidence Type | What the C3PAO Needs | Axiom Artifact | Coverage |
|---|
| (a) Implementation Statement |
How the control is implemented |
OSCAL SSP (123 control narratives), human summaries with DISA STIG references, C3PAO HTML SSP export |
FULL for technical controls. CUSTOMER for non-technical controls (physical, personnel). |
| (b) Evidence of Operation |
Proof the control is running |
Continuous verdicts (4-hour scans), millisecond timestamps, daily Merkle rollups |
FULL |
| (c) Evidence of Effectiveness |
Proof the control works correctly |
factor_a (threshold) vs factor_b (observed) vs factor_c (delta). CSV POA&M tracks remediation to closure. |
FULL |
| C3PAO Expects | Coverage | Axiom Provides | Customer Supplement |
|---|
| Clear description of weakness |
FULL |
Human summaries with DISA STIG references. DISA fix text from parsed STIG cache. |
-- |
| Milestones with dates |
FULL |
Auto-calculated: CAT I = 30d, CAT II = 60d, CAT III = 90d. Overdue flag. |
-- |
| Responsible party assignment |
PARTIAL |
responsible_party field on POA&M items (admin-assignable). |
Organization must assign specific owners to each open item. |
| Resource / cost estimates |
PARTIAL |
estimated_cost field on POA&M items (admin-assignable). |
Organization must populate cost estimates per item. |
| Risk acceptance justification |
FULL |
ao_justification field (text), risk_accepted_by (identity), risk_accepted_at (timestamp). IATT/IATO authorization gated. |
-- |
| Status tracking |
FULL |
Auto-lifecycle: FAIL opens item, PASS closes with closure anchor. days_open, days_to_remediate computed. OSCAL JSON + CSV exports. |
-- |
Axiom has 2,304 assessment objectives seeded from NIST 800-53A Rev 5. Coverage: 638 FULL (28%), 660 PARTIAL (29%), 1,006 NONE (44%). The NONE objectives are primarily INTERVIEW-method (executive intent, design rationale) and non-technical EXAMINE/TEST (physical security, personnel screening) that require human interaction.
Across EU AI Act (Art. 12), NIST 800-53 (AU-9/SI-7), and CMMC Level 2, assessors need confidence that evidence has not been tampered with.
| Integrity Mechanism | What It Proves | Regulatory Mapping |
|---|
| SWT3 Fingerprint (SHA-256) |
Anchor content is authentic: tenant + procedure + factors + timestamp are cryptographically bound |
AU-3 (Content), AU-10 (Non-repudiation), Art. 12(1) (Automatic logging) |
| HMAC-SHA256 Payload Signing |
Anchor originated from the registered SDK instance, not an impostor |
AU-9(3) (Cryptographic protection), Art. 15(4) (Cybersecurity) |
| Daily Merkle Rollups |
No anchor was added, removed, or modified after the daily commitment |
AU-9 (Protection), SI-7(6) (Cryptographic integrity detection) |
| OSCAL Export Hash (X-Axiom-Export-Hash) |
Exported document integrity: SSP/POA&M/AR contents match the hash at time of generation |
AU-9 (Protection), CMMC practice AU.L2-3.3.1 |
| Audit Events Logging |
Every export, attestation, login, and key action is recorded with user, IP, timestamp |
AU-12 (Generation), Art. 12(1) (Automatic logging) |