estøkad
← Blog

Why Estøkad exists.

Three forces are converging in EU regulated tech procurement. The existing CMS options were built for a different buyer profile in a different jurisdiction. Estøkad is what you build when those constraints come first.

Force one — DORA reaching enforcement

The Digital Operational Resilience Act applies in scope from 17 January 2025. From that date, financial entities listed in Article 2 — credit institutions, payment firms, e-money institutions, investment firms, insurance carriers, plus their critical ICT third-party providers — must demonstrate continuous operational resilience to their supervisor.

The supervisor doesn't care that your CMS is "cloud-native" or "API-first." The supervisor cares whether you can produce, on demand: your ICT risk register, your third-party register, your incident log, your business-continuity test results, your exit plan, and a residency-proof for the period under question. If your CMS doesn't make any of those a download, your engineering team builds the assembly process under deadline.

We saw a generation of platforms that gave up on this. Compliance was something their professional-services arm sold separately. The CMS was for engineers, the compliance pack was for consultants, and the regulator was someone else's problem.

Force two — residency moving from preference to requirement

For most of the last decade, "EU residency" was procurement-team preference. AWS Frankfurt, GCP Frankfurt, or any of the EU pops on Cloudflare satisfied the box on the form. Buyers nodded and signed.

That posture is changing. Belgian banking customers want their data in Brussels. Swiss customers want it in Zurich. The Luxembourg supervisor wants to see your customer's data in Luxembourg. "EU region" is no longer a satisfying answer when the question is "which country."

The catalyst is jurisdictional rather than technical. The Cloud Act exists. So does Schrems II. So does the Digital Markets Act. The combination has made it materially harder to argue that "US-headquartered vendor with EU hosting" is the same as "EU-domiciled vendor." If the parent company can be subpoenaed under US law, the data isn't fully under EU jurisdiction. Most customers can live with that risk; regulated ones increasingly can't.

Force three — the existing options were built elsewhere

Contentful is headquartered in Berlin but ultimately owned in San Francisco. Storyblok is Austrian-owned and EU-domiciled, which matters — but their hosting is Frankfurt-only with no per-country guarantees. Sanity is San-Francisco- headquartered with EU regions. Each is a fine product if jurisdiction is not a procurement constraint.

What changes when jurisdiction is the constraint? Different things move to the centre of the architecture. The audit chain becomes structural rather than a plugin. Per-country residency becomes a deployment topology, not a region label. The exit plan becomes a contractual right rather than a sales objection. The editorial workflow gets four-eyes approvals built-in rather than bolted on. The DORA evidence pack gets generated from the audit chain in seconds, rather than assembled from a Confluence page over weeks.

You can't add these to an existing platform. The architecture has to start from the constraint. That's why Estøkad exists — not because the world needed another CMS, but because the world needed a CMS where the regulator's questions were the design centre rather than the appendix.

What this means for the customer

Concretely:

The audit chain is hash-linked. Tampering with a row breaks every subsequent row. Daily Merkle roots are signed by the regional KMS key and published to the workspace JWKS. Customers verify the chain end-to-end with any standard JWT library; the regulator does the same.

Per-country residency is a deployment topology. eu-bru-1 is a standalone Postgres + Object Storage + queue stack in Brussels. There is no replication to other regions. Customers paying for Belgium residency get their data in Brussels and only Brussels.

The DORA evidence pack assembles in seconds. The third-party register is the control-plane sub-processor table joined to the customer's declared downstream processors. The incident log is the audit chain filtered on incident.*. The residency proofs are the signed daily attestations for the period under question. None of this is a Confluence page maintained by a consulting partner.

The exit plan exports schemas as TypeScript, content as JSON, assets as a tar archive, and the audit log as JSONL. Within 90 days of termination. Contractual right, not sales objection.

Why we're building this from Estonia

Samarkand Industries OÜ is registered in Tallinn, taxed in Estonia, and operated inside the Estonian — and therefore EU — jurisdictional perimeter. Estonia has the combination of EU jurisdiction, mature digital-government infrastructure, and a pragmatic stance toward distributed engineering teams that we couldn't find elsewhere on the continent at our scale.

The legal entity is Estonian. The supervisory authority is AKI. The competent court is Harju County Court. None of those choices are arbitrary; they're the structural facts that hold the "EU jurisdiction" commitment together.

What comes next

The roadmap lives at /roadmap; current shipments at /changelog. The reasonable expectation is that the first regulated customer ships in production by the end of Q3 2026. The pricing page is public, the modules are public, the comparison pages are public. Talk to us when you're ready.