Audience
NBs, C3PAOs, ISSOs
Coverage
3 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 observations JSONB. |
-- |
| 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 |
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) |