DORA day one.

What actually came into force

DORA is not a single new obligation. It is a consolidation of expectations that supervisors across the EU had been asking for on a piecemeal basis since 2018. Article 2 names the financial entities in scope. Articles 5 to 14 cover ICT risk management. Articles 17 to 23 cover incident reporting. Articles 28 to 44 cover ICT third-party risk — the chapter that turned every CMS contract into a procurement project this winter.

Two operational facts mattered most on day one. First, the third-party register became a mandatory artefact, not a Confluence page. Second, the contract with every critical ICT provider had to include the clauses spelled out in Article 30 — exit rights, audit rights, sub-processor disclosure, security incident notification windows, location of data processing.

What the supervisors asked for in week one

The Banque Nationale de Belgique sent a templated questionnaire. The CSSF in Luxembourg asked for the third-party register and the audit-rights clause from each critical ICT contract. The BaFin asked for the same plus a residency declaration. None of the three asked for technical evidence on day one. They asked for paper.

The teams that fared best had the paper assembled before the question arrived. The teams that fared worst spent the week extracting clauses from twelve different vendor MSAs and discovering that three of those vendors had no exit clause at all.

What this exposed about the existing CMS landscape

Most B2B SaaS contracts written before 2024 do not contain the Article 30 clauses. That is not negligence — DORA was not in force when those contracts were signed, and the standard enterprise MSA template did not include them. The result, in January, was a wave of contract amendments going out from regulated buyers to vendors. Some vendors signed quickly. Some pushed back on the audit-rights clause. A few said the exit-rights clause was not commercially viable for them.

The vendors that pushed back were not refusing to comply with regulation. They were refusing to make a contractual commitment they had not architected for. A vendor that cannot guarantee data export within 90 days because their schema lives in a proprietary format cannot honestly sign that clause. A vendor that uses a US sub-processor for content search cannot honestly say where the data is processed at all times.

What we built differently

We started Estøkad in late 2025 with the Article 30 clauses on the wall as design constraints, not as a checklist. The exit plan exports schemas as TypeScript, content as JSON, assets as a tar archive, the audit log as JSONL — within 90 days of termination, enforceable, no escape hatch. The third-party register is a first-class control-plane object that the customer reads through the API and that the DORA evidence pack assembles in seconds.

The audit-rights clause is the one we spend the most time discussing with prospects. Our answer is structural: every action lands in an append-only audit chain with hash-linked rows; daily Merkle roots are signed by the regional KMS; the chain head is published to the workspace JWKS. The customer's auditor — or the customer's supervisor — verifies the chain end-to-end without our involvement and without trusting our word.

What we expect to change next

The first round of DORA enforcement actions will land in late 2025 or 2026. The reasonable expectation is that supervisors will start by asking critical providers for incident-response evidence, then move to residency proofs, then to sub-processor change notifications. Vendors that treated DORA as a sales bullet will discover that the evidence is not assembled. Vendors that treated it as architecture will discover that the evidence is a download.

Pricing and roadmap at /pricing and /roadmap. Compliance posture at /trust.