Evidence Packets for DORA and the EU AI Act: The Data Your Auditor Asks For, Signed

When an EU financial entity onboards a new cloud provider, the questionnaire arrives with a different vocabulary than the usual security review. It asks for your Register-of-Information entry. It asks for measured recovery times, not a promise that failover exists. It asks who the cloud sub-processor is, what region the data sits in, and how an incident would be recorded. The EU AI Act adds its own column: if you run AI infrastructure, where does the inference happen, what is logged, and what model inventory backs it.

Answering those questions used to mean a human assembling screenshots into a deck and hoping nobody changed a value between the screenshot and the audit. Today we are shipping the next phase of signed compliance evidence: per-organization, cryptographically signed evidence packets for DORA and the EU AI Act, alongside the SOC 2 and GDPR Article 30 ROPA packets we already produce. One API call returns the signed JSON and a clean PDF. Your auditor verifies it themselves against a key we publish.

One Call, Two New Frameworks

The endpoint is the same one that already serves SOC 2 and GDPR. You pick the framework in the request body.

# DORA operational-resilience and ICT third-party evidence
curl -u $API_KEY:$API_SECRET \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"framework":"dora"}' \
  https://api.foundrydb.com/organizations/$ORG_ID/compliance-reports

# EU AI Act infrastructure controls for the AI services we operate
curl -u $API_KEY:$API_SECRET \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"framework":"eu_ai_act"}' \
  https://api.foundrydb.com/organizations/$ORG_ID/compliance-reports

You get back a signed JSON document and a downloadable PDF rendered from the same data. Both are also generated automatically every quarter, so last quarter's packet and this quarter's packet are both authentic and both verifiable. Nothing to schedule, nothing to screenshot.

What the DORA Packet Gives You

DORA (the Digital Operational Resilience Act) puts obligations on EU financial entities and on the ICT providers they depend on. FoundryDB is one of those providers. The DORA packet is built to be the evidence your operational-resilience program needs about us, plus the structured Register-of-Information entry for FoundryDB as an ICT third party.

For each service in your organization, the packet records the operational-resilience facts with concrete observed values:

• High availability and failover, including measured recovery times from real failover events rather than a target on a slide.
• Backups, point-in-time recovery, and backup verification, with timestamps for the last successful and last verified backup.
• Incident records tied to the service, so an auditor can see what happened and when.
• Change management, the record of configuration and version changes the platform applied.
• EU data residency, the zones and regions the service runs in.
• The cloud sub-processor identity, naming the infrastructure that sits beneath us.

That last set rolls up into a Register-of-Information entry you can drop straight into your own register, with FoundryDB identified as the ICT service provider, the function we support, and the sub-processor behind us.

What the packet does not do is invent your numbers. Your contractual RTO and RPO targets, your threat-led penetration testing (TLPT), and your own resilience-testing program are obligations that live with you, not with us. The packet marks those lines not_attestable or out_of_scope and says so plainly, because we cannot observe them from the platform.

What the EU AI Act Packet Gives You

If you use the AI infrastructure FoundryDB operates (the embedding pipelines and vector storage behind retrieval and search), the EU AI Act packet documents the infrastructure-side controls for exactly that surface:

• Data residency and encryption for the data flowing through the AI pipeline and the vectors at rest.
• Audit logging of AI-infrastructure operations, so there is a record of what ran.
• An AI service and model inventory, the models and AI services the platform operates on your behalf.
• Operator controls over that infrastructure.
• Infrastructure cybersecurity, the network and access posture underneath.

And again, the honest boundary: the EU AI Act's heavy obligations sit with the provider or deployer of the AI system, which is you, not your database vendor. The classification of your AI system (is it high-risk?), your risk management process, and the Annex IV technical documentation are yours to produce. The packet marks them out_of_scope rather than pretending a managed vector store satisfies them.

The Honesty Model Is the Feature

Most compliance artifacts are a wall of green checks. That is the problem with them: a green check next to a control your vendor never actually observed is worse than no check at all, because it teaches the reader to stop reading.

Every line in a FoundryDB evidence packet carries one of three states:

• attested when the platform directly observes the control, always backed by a concrete value: a measured failover recovery time, a real backup timestamp, the actual zone list, the cipher in use.
• not_attestable when the control is real and relevant but the platform cannot observe it (your RTO target, your penetration-test cadence).
• out_of_scope when the obligation belongs to you, not to your infrastructure provider (your AI system's risk classification, your Annex IV docs).

Here is the shape of a DORA packet, trimmed for clarity:

{
  "report": {
    "framework": "dora",
    "organization_id": "9a1b2c3d-4e5f-6a7b-8c9d-0e1f2a3b4c5d",
    "generated_at": "2026-06-21T10:30:00Z",
    "ict_provider": {
      "name": "FoundryDB",
      "function": "managed database and AI data infrastructure",
      "cloud_sub_processor": "UpCloud (EU)"
    },
    "controls": [
      {
        "id": "dora.ha_failover",
        "title": "High availability and automated failover",
        "status": "attested",
        "observed": {
          "service": "orders-prod",
          "node_count": 3,
          "last_failover_recovery_seconds": 41,
          "eu_residency": true
        }
      },
      {
        "id": "dora.backup_pitr",
        "title": "Backups, PITR, and backup verification",
        "status": "attested",
        "observed": {
          "last_backup_at": "2026-06-21T02:00:14Z",
          "last_verified_at": "2026-06-21T03:11:52Z",
          "pitr_enabled": true,
          "backup_encryption": "AES-256-GCM"
        }
      },
      {
        "id": "dora.rto_rpo_targets",
        "title": "Contractual RTO and RPO targets",
        "status": "not_attestable",
        "note": "Recovery targets are defined by the customer's resilience program, not observable from the platform."
      },
      {
        "id": "dora.tlpt",
        "title": "Threat-led penetration testing",
        "status": "out_of_scope",
        "note": "TLPT is an obligation of the financial entity, not the ICT provider."
      }
    ]
  },
  "signature": {
    "algorithm": "Ed25519",
    "key_id": "fdb-compliance-2026",
    "value": "9f86d081884c7d659a2feaa0c55ad015..."
  }
}

An auditor reading that learns two true things at once: what we actually do, and where the line is. That is more useful than a perfect score, and it is more defensible under questioning.

Verify It Without Trusting Us

The packet is signed with Ed25519, and the public half of the signing key is published at a well-known URL:

https://api.foundrydb.com/.well-known/compliance-signing-keys

The signature covers the exact bytes of the report object as returned. Anyone who holds the public key can confirm the document came from the platform and was not edited on its way to their desk. You do not have to trust the email it arrived in or the spreadsheet someone pasted it into.

Two ways to verify:

# CLI: verify a downloaded packet against the published key
fdb compliance verify ./dora-packet.json
# -> signature valid, key_id fdb-compliance-2026, signed 2026-06-21T10:30:00Z

Or paste the file into the in-browser verification tool, which fetches the published key and checks the signature locally in the page. The PDF carries the same signed payload, so the human-readable document and the machine-verifiable one never drift apart.

Why European Sovereignty Is the Anchor

The reason these packets hold up is the same reason customers come to FoundryDB in the first place. The data runs in EU zones (Stockholm, Helsinki, Frankfurt, and others), so the residency lines are attested with real zones rather than asterisked. The signing key is generated and held under sovereign control, so the chain of trust on the evidence does not route through a non-EU control plane. For a DORA Register-of-Information entry or an EU AI Act infrastructure record, that European footing is the difference between evidence that survives review and evidence that raises a follow-up question.

A note, because it matters: these packets are evidence that supports your DORA and EU AI Act programs. They are not a declaration that using FoundryDB makes you "DORA compliant" or "EU AI Act compliant," and nothing here is legal advice. Compliance is your program; the packet is the part of it we can prove on your behalf.

What's Next

DORA and EU AI Act evidence packets are available now for every FoundryDB organization, alongside SOC 2 and GDPR Article 30. To put one in front of your next reviewer:

• Generate a packet with POST /organizations/{orgId}/compliance-reports and a framework of dora or eu_ai_act
• Verify the signature with the compliance-verify CLI or the in-browser tool against the published Ed25519 key
• Drop the DORA Register-of-Information entry straight into your own register, with FoundryDB named as the ICT provider
• Read the Security overview for how residency, encryption, HA, and audit logging are enforced underneath every attested line

If you are not yet on FoundryDB, sign up and have your first database running on European infrastructure in under five minutes.