4 posts tagged with "gdpr"

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.

Every app needs login. Almost nobody wants to build it. So you grab a hosted identity service, ship in an afternoon, and quietly sign a deal nobody prints on the pricing page: your users now live in someone else's database, in someone else's region. Their emails. Their sessions. Their second-factor secrets. All of it sitting inside a control plane you do not run and cannot see into. With Auth0, Clerk, or Cognito, that is the trade. Convenient SDK on top, your users hostage underneath.

FoundryDB App Auth flips it. We run the login service for you: a standard OIDC issuer with hosted, themeable login pages, zero UI to build. But the people signing in stay yours. Their identities, sessions, refresh tokens, and MFA secrets land in a schema inside your own PostgreSQL database, in your region. Our control plane never sees a single one. We run the login. You keep the users.

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.