How FoundryDB Compliance Evidence Packets Work, End to End
An auditor reviewing your data layer does not want a screenshot. A screenshot is a picture of a number at a moment, detached from the system that produced it, trivially edited, and impossible to verify after the fact. What an auditor actually wants is evidence: a record of what a control did, backed by an observed value, that can be checked against a source of trust without taking anyone's word for it.
That is what a FoundryDB compliance evidence packet is. It is a per-organization document, generated from real platform data, that maps the infrastructure controls we operate to the framework you are being measured against (SOC 2, GDPR Article 30 ROPA, DORA, or the EU AI Act). It is cryptographically signed, stored immutably, and rendered as both machine-verifiable JSON and a human-readable PDF. Anyone holding our published public key can confirm a packet came from the platform and was not altered, with no shared secret and no need to trust the channel it arrived through. This post walks through how that works, from operational data to a signature an auditor can check in their browser.
One framing matters before the mechanics, and we will repeat it because it is load-bearing: a packet is evidence that supports your compliance program. It is not a certificate that using FoundryDB makes you compliant. The platform attests only to the infrastructure controls it actually operates. It does not certify your compliance with SOC 2, GDPR, DORA, or the EU AI Act, and nothing in this post is legal advice. Compliance is your program. The packet is the part of it we can prove on your behalf.
From operational data to a signed packet
A packet is not assembled by hand and it does not store pre-baked answers. Every time you generate one, the platform reads the current operational state of your services and builds the document fresh.
The flow has a few distinct stages, and each one is deliberate.
Evidence collection from real platform data. The generator pulls from the systems that actually run your services: high-availability topology and measured failover recovery times from real events, backup and point-in-time-recovery timestamps (last successful, last verified), the zones and regions a service runs in, encryption ciphers in use, audit-log records, and change history. These are observed values, not targets typed into a form. If a service failed over in 41 seconds last week, that is the number the packet carries.
The framework mapper. The collected evidence is framework-agnostic. A single mapping layer then projects it onto whichever framework you asked for. The same underlying backup timestamp supports a SOC 2 availability control, a DORA backup-and-PITR control, and a GDPR security-of-processing line, each phrased in that framework's vocabulary. Adding a framework means adding a mapper, not re-instrumenting the platform, which is how DORA and the EU AI Act joined SOC 2 and GDPR without touching the collection or signing layers.
The honesty model. This is the part we are most deliberate about. Most compliance artifacts are a wall of green checks, and that is precisely what makes them useless: a check next to a control your vendor never observed teaches the reader to stop reading. Every line in a FoundryDB packet instead carries one of three honest statuses:
attested, when the platform directly observes the control, always backed by a concrete value: a measured recovery time, a real backup timestamp, the actual zone list, the cipher name. Never a bare green check.not_attestable, when the control is real and relevant but the platform cannot see it (your contractual RTO target, your penetration-testing cadence).out_of_scope, when the obligation belongs to you rather than to your infrastructure provider (your AI system's risk classification, your Annex IV technical documentation).
An auditor reading that learns two true things at once: what we actually do, and where the line sits. That is more defensible under questioning than a perfect score, and it is the feature, not a disclaimer.
Signing. Once the document is built, the platform signs it with a detached Ed25519 signature. The signing key never leaves OpenBao, held under sovereign EU control, and the signature covers the exact bytes of the report as returned. This is the differentiator worth stating plainly: the chain of trust on your evidence does not route through a non-EU control plane, and the key material backing it lives under EU residency.
Immutable storage and dual rendering. The signed packet is written to an append-only store, so last quarter's packet and this quarter's are both authentic and both retrievable later. The platform renders two artifacts from the one signed payload: the JSON (for machine verification) and a PDF (for humans). Because both derive from the same signed bytes, the readable document and the verifiable one never drift apart.
Public verification with no shared secret. The public half of the signing key is published at a well-known URL. Anyone, your auditor included, can verify a packet against it, either with the compliance-verify CLI or by pasting the file into the in-browser tool, which fetches the key and checks the signature locally in the page. There is no API token to share, no account to create, and no need to trust the email the file arrived in.
Keys rotate, old packets still verify
A signing key is not forever. Keys get rotated on a schedule, after personnel changes, or as a matter of hygiene. The hard problem with rotation is that naively swapping a key invalidates every document the old key ever signed. A packet you issued to an auditor last quarter must still verify next year, even after the key that signed it has been retired.
FoundryDB solves this with a rotatable signing-key set rather than a single key. Rotation does two things at once: it mints a new active key (which signs all new packets from that moment) and it marks the previous key retired. The critical detail is what happens to a retired key: it stops signing, but its public half stays published. It is never deleted from the well-known endpoint.
Every packet records the key_id of the key that signed it. Verification is therefore a lookup, not a guess: a verifier reads the packet's key_id, finds the matching public key in the published set (active or retired), and checks the signature against that specific key. A packet signed by a key retired two rotations ago verifies exactly as well today as the day it was issued, because its key is still on the published list. Rotation moves the platform forward without orphaning a single document already in an auditor's hands.
Subscriptions, pricing, and the bundle
Generating evidence packets is a paid capability, and the gate sits at the point of generation rather than bolted on after the fact.
Per-framework subscriptions gate generation. Each framework is its own subscription. Ask to generate a SOC 2 packet without a SOC 2 subscription and the API returns 402 Payment Required. Subscribe, and generation succeeds. Platform admins bypass the gate so support and verification work is never blocked, but for normal organizations the subscription is the switch that turns a framework on. The quarterly auto-generation worker honors the same rule: it only produces packets for frameworks you are subscribed to.
The prices. Subscriptions are billed per framework, per month:
- SOC 2: EUR 199
- GDPR Article 30 ROPA: EUR 99
- DORA: EUR 299
- EU AI Act: EUR 249
The all-frameworks bundle. If you need more than one, the bundle is EUR 599 per month and covers all four frameworks. When the bundle is active it gates generation for every framework, and it is metered in place of the individual lines, so you are never double-charged: the bundle line takes precedence and the per-framework lines do not also accrue. Subscribe to the bundle and all four frameworks are simply enabled.
How metering works. Compliance subscriptions meter hourly into your billing period, drawn against prepaid credit, the same mechanism the rest of the platform uses for add-on usage. A EUR 299 DORA subscription accrues at roughly EUR 0.41 per hour across the period rather than as a lump charge, and the cost appears as its own itemized line so you can see exactly what compliance is costing you.
Try it
If your organization is subscribed to a framework (or the bundle), one call generates a signed packet:
curl -u $API_KEY:$API_SECRET \
-X POST \
-H "Content-Type: application/json" \
-d '{"framework":"soc2"}' \
https://api.foundrydb.com/organizations/$ORG_ID/compliance-reports
Swap soc2 for gdpr, dora, or eu_ai_act to generate the others. You get back the signed JSON, and the matching PDF is available from the same packet record. If you are not subscribed, the call returns 402 and tells you which framework needs a subscription.
Then verify it without trusting us. Either run the CLI:
fdb compliance verify ./soc2-packet.json
# -> signature valid, key_id <active-or-retired-id>, signed <timestamp>
Or paste the file into the in-browser verification tool, which fetches the published key set and checks the signature locally. Both resolve the packet's key_id against the published keys at:
https://api.foundrydb.com/.well-known/compliance-signing-keys
Active and retired keys both live there, which is why a freshly generated packet and one signed before the last rotation both verify cleanly.
A closing note, because it carries weight: these packets are evidence that supports your SOC 2, GDPR, DORA, and EU AI Act programs. They are not a declaration that using FoundryDB makes you compliant with any of those frameworks, and nothing here is legal advice. The platform attests only to the infrastructure controls it operates, marks everything else not_attestable or out_of_scope in plain language, and leaves your program where it belongs: with you. The part we can prove, we sign, under an EU-sovereign key, so your auditor can check it for themselves.