We have the deepest admiration for the AICPA, ISO/IEC, and HHS framers who built four decades of rigor into those tests. The Hive stack does not skip them. It exceeds them — and produces, as a side effect of every transaction, machine-verifiable evidence that is stronger than any sample-based audit can produce.
Sample-based attestation over 6–12 months → per-transaction cryptographic receipt.
Annual surveillance audit → machine-verifiable evidence on every API call.
OCR sample audit on demand → per-record CRE on every PHI access event.
We did not pursue formal SOC 2 or ISO 27001 certification through traditional channels — and we want to be precise about why, because we have the deepest admiration for the work the AICPA, ISO/IEC, and HHS teams have done over four decades to make those tests rigorous.
The Hive stack does not skip those tests. It exceeds those tests — and produces, as a side effect of every transaction, evidence that is stronger than any sample-based audit can produce, by a measurable margin. Here is how.
A SOC 2 Type II report attests that controls operated effectively over a window — typically 6 to 12 months — based on a sample of evidence reviewed by a CPA. The control sample size is, by AICPA TSP guidance, typically 25 to 60 instances per control per year. ISO 27001 surveillance audits sample at a comparable rate. HIPAA OCR audits review a small subset of records on demand.
Evidence instances per control per year. Auditor pulls from a CPA-defined population, applies AICPA TSP sampling theory, and issues a 95%-confidence opinion on operating effectiveness.
Evidence instances per control per year, at 10,000 transactions/day. Every transaction earns a signed envelope. No sampling. No extrapolation. The receipt or the absence of the receipt.
| Profile | Per-day events | Per-year events | Multiplier vs SOC 2 sample (60/yr) |
|---|---|---|---|
| High-volume API platform | 10,000 | 3,650,000 | 60,833× |
| Mid-volume SaaS / fintech | 1,000 | 365,000 | 6,083× |
| Hospital — PHI access events | 250 | 91,250 | 1,520× |
| Low-volume regulated entity | 100 | 36,500 | 608× |
In no realistic deployment does the multiplier fall below 100×. That is the floor. The ceiling is set by transaction volume, not by audit rigor.
A SOC 2 sample of 60 says: the control was probably operating in the 60 cases the auditor looked at. Sampling theory lets you extrapolate at confidence intervals that depend on population size and homogeneity. A real auditor would quote you 95% confidence with a margin of error of several percent.
A CRE on every transaction says: the control either operated or it did not, on this exact transaction, here is the cryptographic record signed at the moment it ran. There is no extrapolation. There is no confidence interval. There is the receipt, or there is the absence of the receipt.
SOC 2 is an attestation engagement performed by a CPA firm under AICPA SSAE 18. A Type II report covers a window of 6 to 12 months. Controls are evaluated against the Trust Services Criteria across five categories: Security (the common criteria CC1–CC9, always required), Availability (A1), Confidentiality (C1), Processing Integrity (PI1), and Privacy (P1–P9). The auditor samples evidence from each control population and issues an opinion on operating effectiveness.
| SOC 2 control area | Sample-based attestation | CRE per-transaction equivalent |
|---|---|---|
| CC6.1 | Logical access — auditor pulls 25–60 access-control samples per year | Ed25519 + ML-DSA-65 dual signature on every API call, bound to tenant ID |
| CC6.6 | Encryption in transit — sampled TLS configuration evidence | ML-KEM-768 / Classic-McEliece-6688128f hybrid KEM on every payload |
| CC7.2 | Anomaly detection — sampled monitoring artifacts and tickets | MMR root commitment — any deviation breaks inclusion proof |
| CC7.3 | Incident response — sampled incident tickets and post-mortems | Tombstone receipt for every revoked / rotated credential, MMR-witnessed |
| A1.2 | Availability — sampled uptime reports and SLA tickets | /v1/cre/health endpoint feed signed and committed to MMR |
| PI1.1 | Processing integrity — sampled data-processing artifacts | 4-family hash cascade (SHA3-256 + BLAKE3 + KangarooTwelve + cSHAKE128) |
| C1.1 | Confidentiality — sampled access logs and encryption settings | Per-envelope confidentiality classification + epoch-bound key |
| P1–P9 | Privacy series — sampled DSAR responses and consent records | PII-class envelope field + forward-secure key epoch (deletion-by-key) |
ISO/IEC 27001:2022 specifies an Information Security Management System and is certified by an accredited body following an annual surveillance audit cycle. Annex A 2022 consolidated the prior 114 controls into 93 controls across 4 themes: Organizational (37), People (8), Physical (14), and Technological (34). The auditor samples implementations of selected controls.
| ISO Annex A control | Surveillance audit cadence | CRE machine-verifiable evidence |
|---|---|---|
| A.5.15 | Access control — sampled annually | Ed25519 signature on every API call, tenant-bound |
| A.5.34 | Privacy and protection of PII — sampled annually | PHI-class envelope field + per-record epoch label |
| A.6.7 | Remote working — sampled policy + interview | Endpoint posture committed to envelope at session open |
| A.8.5 | Secure authentication — sampled MFA configuration | ML-DSA-65 (FIPS 204) co-signature on every auth event |
| A.8.10 | Information deletion — sampled deletion runbooks | Forward-secure key epoch (Bellare-Miner) — deletion-by-key |
| A.8.16 | Monitoring activities — sampled SIEM artifacts | MMR append-only log, root publishable any time |
| A.8.24 | Use of cryptography — sampled key-management evidence | 5-Assumption Stack (PentaPQ) + Triad-Bound Receipt all-of-3 |
| A.8.28 | Secure coding — sampled code-review tickets | 4-family hash cascade integrity check on every artifact |
HIPAA is the Health Insurance Portability and Accountability Act of 1996, with the Privacy Rule (45 CFR Part 160 and Subparts A and E of Part 164), the Security Rule (Subpart C of Part 164, technical / physical / administrative safeguards), and the Breach Notification Rule (Subpart D). Enforcement is by HHS Office for Civil Rights; OCR audits review a sampled subset of records on demand. A typical hospital generates roughly 250 PHI access events per day per active service line.
Hive operates a HIPAA-focused vertical at /hipaa-hive/ that applies the CRE envelope directly to PHI access events. This section is the framework explainer; the vertical page is the product surface.
| HIPAA Security Rule section | Compliance evidence as practiced today | CRE per-transaction equivalent |
|---|---|---|
| §164.312(a)(1) | Access control — access logs sampled on OCR request | Ed25519 signature + tenant ID + role on every PHI access event |
| §164.312(a)(2)(iii) | Automatic logoff — configuration screenshots sampled | Session epoch label expires; envelope refuses post-epoch reissue |
| §164.312(b) | Audit controls — audit logs sampled on demand | MMR append-only log, publishable bagged-peaks root |
| §164.312(c)(1) | Integrity — integrity-check runbooks sampled | 4-family hash cascade per envelope (SHA3-256 + BLAKE3 + K12 + cSHAKE128) |
| §164.312(d) | Person-or-entity auth — auth configs sampled | Triad-Bound Receipt — Ed25519 + ML-DSA-65 + SLH-DSA-SHAKE-256f |
| §164.312(e)(1) | Transmission security — TLS configuration sampled | ML-KEM-768 / Classic-McEliece-6688128f hybrid KEM (TBR-grade) |
| §164.308(a)(1)(ii)(D) | Information system activity review — sampled reports | Per-envelope inclusion proof against published MMR root |
| §164.530(j) | Documentation — six-year retention sampled by OCR | Forward-secure key epoch annotation per envelope, retained by class |
We refuse to bury the parts that are roadmap rather than shipped. Rows marked Not held are visually distinct because the difference between an aspiration and a deliverable is the entire premise of this page. If a number changes, the table changes. There is no scenario in which we move a row from “Not held” to “Held” without the underlying letter or certificate.
| Capability | Status today | Path |
|---|---|---|
| Per-transaction CRE issuance + verification | Shipped — /v1/cre/issue, /v1/cre/verify | n/a |
| 4-family hash cascade (SHA3-256 + BLAKE3 + KangarooTwelve + cSHAKE128) | Shipped, all four channels native | n/a |
| Append-only MMR with bagged-peaks root | Shipped, file-backed | Public timestamping anchor — Q3 |
| Ed25519 + ML-DSA-65 dual signature | Shipped (FIPS 204 final standard) | n/a |
| Triad-Bound Receipt (TBR) — Ed25519 + ML-DSA-65 + SLH-DSA-SHAKE-256f all-of-3, ML-KEM-768 / Classic-McEliece-6688128f hybrid KEM | Shipped, /v1/cre/tbr/* (Build #41) | n/a |
| Forward-secure key epoch annotation (Bellare-Miner) | Shipped — daily rotation, label-only | Full key-erasure ratchet — Q3 |
| Side-channel measurement (TVLA, 5 classes claimed) | 2 of 5 measured today (timing + power-trace), 3 on roadmap | Full ISO/IEC 17825 reporting — Q4 |
| Cross-framework control mapping | 225 controls, 13 frameworks, machine-verified count published per envelope | Expansion to PCI DSS v4 + FedRAMP Rev 5 — Q3 |
| Formal SOC 2 Type II letter from a CPA firm | Not held — not pursued through formal channels | On request, we will support a customer's auditor |
| Formal ISO 27001:2022 certificate from an accredited body | Not held — not pursued through formal channels | On request, we will support a customer's auditor |
| Independent third-party MMR-root publication | Not yet | Public timestamping anchor — Q3 |
No, not through formal AICPA channels. We have the deepest admiration for the framers and we exceed those tests. Every Hive transaction issues a Compliance Receipt Envelope signed under Ed25519 and ML-DSA-65 — machine-verifiable evidence that produces 100× to 60,833× more coverage per control than a SOC 2 sample.
A customer who needs a paper SOC 2 letter can still get one from a CPA firm; we support their auditor with the CRE log and MMR root. The auditor's job becomes verifying envelopes rather than sampling files.
No, not through an accredited body. Same posture as SOC 2: deepest admiration for the ISO/IEC framers, and we exceed those tests with per-envelope machine-verifiable evidence mapped to Annex A 2022. A customer who needs a certificate can still get one; we support their auditor.
We do not use the regulator-quoted phrase “HIPAA compliant” for ourselves because compliant is a determination made by the covered entity and (when audited) by OCR. The Hive HIPAA-Hive vertical applies the CRE envelope to PHI access events and produces per-record receipts mapped to the HIPAA Security Rule (45 CFR §164.312). See /hipaa-hive/.
A typical hospital generating 250 PHI access events per day gets 1,520× more evidence than an OCR sample audit can review.
Yes. The auditor's job becomes verifying envelopes against the published MMR root rather than sampling files. The CRE log contains every transaction; the MMR root is publishable; per-envelope verification is yes-or-no. Auditor work is faster and the underlying evidence is stronger.
MMR is the Append-Only Witness Merkle Mountain Range. Every CRE envelope is committed to it as it is issued. The bagged-peaks root is a single hash that proves the entire log existed at a given moment.
We expose it on /v1/cre/health and /v1/cre/mmr/root. Public timestamping anchor publication is on the Q3 roadmap and will be added to the disclosure table when it ships.
Use /v1/cre/export with a date range and tenant ID. The endpoint returns a JSON Lines bundle of every CRE envelope in the range plus the MMR inclusion proofs and the period root. Hand the bundle and root to your auditor; they verify with /v1/cre/verify or any client that implements the CRE spec.
Get one. The CRE log makes that engagement faster and the underlying evidence is stronger than a sample-based pull. We support your auditor or accredited body by providing the CRE log, the MMR root, and the framework reduction map (225 controls, 13 frameworks). The certificate sits on top of forensic evidence rather than inferential evidence.
Yes. The CRE issuer and verifier are stateless given a key and an MMR file. On-prem deployments keep their MMR file local and publish only the period root. The 4-family cascade hash, Ed25519 + ML-DSA-65 signatures, and Epoch Ladder forward-secure key rotation all run without a Hive network dependency.
A CRE is a signed JSON record issued for every transaction. It contains the canonical hash of the transaction (4-family cascade), the Ed25519 + ML-DSA-65 dual signature, the epoch label, the MMR position and inclusion proof, and the tenant + framework annotations. It is Per-Transaction Audit Evidence in a single self-contained envelope. Architecture details: /cre/.
Triad-Bound Receipt (TBR) is the all-of-three signature mode shipped in Build #41: Ed25519 (classical) plus ML-DSA-65 (FIPS 204 lattice) plus SLH-DSA-SHAKE-256f (FIPS 205 hash-based), with payload confidentiality under a ML-KEM-768 / Classic-McEliece-6688128f hybrid KEM. Three independent hardness families must all break to forge a TBR. Endpoints: /v1/cre/tbr/issue, /v1/cre/tbr/verify. See /cre/#triad.
Every CRE envelope maps to specific controls in 13 frameworks: SOC 2, ISO/IEC 27001:2022, HIPAA, GDPR (Articles 5–35), EU AI Act (Articles 9–17, 50), CCPA, NIST CSF, NIST SP 800-53, NIST SP 800-171, FFIEC, NYDFS Part 500, ISO 42001, and SOX. PCI DSS v4 and FedRAMP Rev 5 expansion is on the Q3 roadmap.
Dashboards show you control state over time and are an excellent monitoring layer. They are not, on their own, audit evidence — an auditor still has to pull raw artifacts and sample them. The CRE envelope is the artifact, signed at the moment the control ran, and the MMR root proves the artifact existed and was not tampered with. Dashboards consume CRE; CRE is the source.
The doctrine is on this page. The receipt is on /cre/. The Triad-Bound Receipt is at /cre/#triad. If you have an auditor question we did not answer, write to us directly.
Every Hive surface signs its own evidence with the same primitives: SHA3-256 canonical hashing, Ed25519 + ML-DSA-65 dual signatures, and a published Merkle Mountain Range root. The receipt is the audit evidence. The envelope is the universal generalization — every transaction, every framework, every surface.