4 posts tagged with "compliance"

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.

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.

Every vendor security questionnaire asks the same questions. Where is the data stored? Is it encrypted at rest? Is it encrypted in transit? When was the last backup? How long do you keep audit logs? Answering them usually means a human logging into a console, taking screenshots, copying values into a spreadsheet, and hoping nobody changed anything between the screenshot and the audit.

The compliance report endpoint replaces that ritual with a single API call. It returns a JSON document describing your data posture across every service in your organization, and it attaches an HMAC-SHA256 signature over that document. An auditor can recompute the signature with a verification key and prove the report came from the platform and was not edited on the way to their desk.

When we started building FoundryDB, one of the first decisions was where to run the infrastructure. The answer shaped everything that followed: we chose to build exclusively on European cloud providers, starting with UpCloud, a Finnish infrastructure company operating under EU law.

This was not a marketing decision. It was a legal and architectural one. If you store customer data in databases, the jurisdiction of the infrastructure underneath those databases determines what legal regime governs access to that data. For many organizations in Europe, this distinction is no longer optional.