Six Compliance Frameworks, One Provenance Chain

The structural insight

Most compliance tools are framework-first. They build one module for SOX, another for HIPAA, another for CMMC. Each module has its own data model, its own reports, its own pricing tier. The result is a compliance platform that is really six separate products behind one login screen.

Signal Provenance works the other way. The product is one thing: a hash-chained ledger that records every file change with actor attribution, timestamps, and cryptographic integrity. That ledger happens to satisfy the evidence requirements of six different compliance frameworks because those frameworks all ask the same structural question: can you prove what happened to your data?

This is not a marketing claim. It is an architectural consequence. When you hash-chain every file mutation with a timestamp, a prior-state hash, and an actor, you have built the evidence layer that regulators require. The mapping from ledger entry to framework control is a report format, not a feature.

How the mapping works

Each framework has specific controls. Each control asks for specific evidence. Here is how the same provenance chain answers different regulators:

FDA 21 CFR Part 11: Electronic records, electronic signatures

Part 11 requires that electronic records be tamper-evident, that changes be attributed to specific individuals, and that records be available for FDA inspection. The provenance chain provides exactly this: every file state is hashed, every change is attributed, and the chain can be exported as a compliance report on demand.

The electronic signature requirements (11.100, 11.200) are satisfied by a two-factor signature system: password verification via scrypt hashing plus TOTP (RFC 6238) time-based one-time passwords. Every signature is witnessed to the same Aletheia ledger. No external signing service required.

SOX 404: Internal controls over financial reporting

SOX 404 requires evidence that controls over financial data are designed effectively and operating as designed. The provenance chain provides the evidence layer: every change to a financial document is recorded with who changed it, when, and what the prior state was. The seven-year retention requirement is met by default because the chain is append-only and runs on the client's own storage.

CMMC / NIST 800-171: Controlled unclassified information

CMMC requires audit events for CUI access and modification (AU-2, AU-3), audit review and analysis (AU-6), protection of audit information (AU-9), and audit record retention (AU-12). The provenance chain satisfies all five AU controls. It generates audit events automatically on every file change. It protects audit records cryptographically (the chain cannot be modified without detection). It retains records indefinitely. And because it runs on the client's own hardware, CUI never leaves the controlled environment.

ISO 27001 / SOC 2: Information security management

ISO 27001 Annex A controls for logging (A.8.15), information transfer (A.8.24), and configuration management (A.8.9) all require evidence of what changed, when, and by whom. SOC 2 Trust Services Criteria for Security, Processing Integrity, and Confidentiality require the same evidence. The provenance chain produces it continuously without any additional configuration per framework.

HIPAA: Protected health information

HIPAA 164.312 requires access controls, audit controls, integrity controls, and transmission security for electronic PHI. The provenance chain covers the audit and integrity requirements. Access controls are handled by the RBAC layer with role-based permissions, time-bounded emergency access (break-glass), and automatic session idle timeout. Every access event is witnessed to the ledger.

EU AI Act: High-risk AI system transparency

The EU AI Act requires logging of AI system operation (Art. 12), technical documentation (Art. 11), human oversight provisions (Art. 14), risk management (Art. 9), and quality management record-keeping (Art. 17(1)(f)). For organizations using AI to process documents, the provenance chain provides the required logging layer: every file that AI touches is tracked with its prior state, the change event, and the resulting state. The chain itself constitutes technical documentation of the data flow. Enforcement begins August 2, 2026.

Why one chain covers six frameworks

The answer is that compliance frameworks are not as different as the compliance industry needs them to be. Strip away the framework-specific terminology and every one of these regulations asks the same four questions:

1. What happened to the data?
2. Who did it?
3. Can you prove it was not tampered with after the fact?
4. Can you show me on demand?

A hash-chained provenance ledger answers all four by construction. The chain records what happened. Actor attribution records who. Cryptographic linking proves integrity. The compliance export produces the on-demand report. The only thing that changes between frameworks is which columns appear in the report and which control numbers are cited in the headers.

The compliance export

Signal Provenance generates a single compliance report that maps ledger evidence to all six frameworks simultaneously. The report includes:

• Chain verification status (VALID or BROKEN, with the specific break point if broken)
• Per-framework control mapping showing which chain properties satisfy which regulatory controls
• File inventory with hash, last-modified timestamp, and actor attribution
• Links to dedicated per-framework coverage pages with control-by-control evidence detail

The report ships as JSON (machine-readable, for downstream systems) and PDF (human-readable, for auditors). Both formats are generated from the same data. Both are themselves witnessed to the ledger, so the compliance report has its own provenance chain.

What the alternatives look like

The typical enterprise approach to multi-framework compliance is to buy a GRC platform (Vanta, Drata, Secureframe, or an enterprise suite from ServiceNow or Archer). These platforms prove that controls exist. They do not prove what the data looked like. They answer "do you have a policy?" not "can you prove what happened to this specific file on this specific date?"

Signal Provenance is the evidence layer underneath the policy layer. If you already use a GRC platform, the provenance chain gives it something to point to. If you do not, the provenance chain is the minimum viable compliance evidence for file-based operations.

Detailed coverage pages

Each framework has a dedicated coverage page with control-by-control mapping. These pages show exactly which ledger properties satisfy which regulatory controls, and where coverage is complete, strong, partial, or not applicable.