Delfen
All articlesDigital Sovereignty

Digital sovereignty is a mapping problem, not a vendor problem

Five Dutch regulators just told organizations to build real freedom to switch IT vendors. One of the five already measured how far off that is — and found that a compliance policy on paper and a contract that actually enforces it are not the same thing.

Jacques Domenie·13 July 2026·6 min read

Five Dutch regulators — ACM, AFM, AP, DNB, and RDI — published a joint report on 10 July arguing that Dutch and European organizations need real freedom to switch IT vendors, not just the theoretical kind. One of the five authors had already measured exactly how far off that is. In a DORA compliance survey De Nederlandsche Bank ran across the financial sector in May 2025, nearly 95% of institutions reported they'd updated their outsourcing policy. Only 34% had actually brought their ICT contracts into line with DORA's requirements. The policy got written. The architecture didn't follow.

What the report actually asks for

Read precisely, this is a position paper, not a new law — it states directly that it creates no new obligations for the organizations its five authors supervise. What it does is call on government to act as a launch customer for European digital services, on public authorities and businesses to weight digital autonomy in procurement decisions, on companies to collaborate sector-by-sector (the Mededingingswet, the report notes, gives ample room for this), and on smaller IT providers to build viable European alternatives together. Worth being precise about that distinction before citing this anywhere: recommendation, not requirement — for now.

Nobody named the discipline

The report calls for open standards, interoperability, and switching capability. It never says how an organization is supposed to know what it depends on in the first place. That's not a gap unique to this report — it's a gap in the standard everyone cites on portability. ISO/IEC 19941, the actual international standard for cloud interoperability and portability, says it outright in its own introduction: declaring interoperability or portability without a detailed analysis of what specifically is to be ported "is meaningless." The standard requires that analysis as a precondition. It doesn't specify the method.

The method exists — it's just scattered and rarely named. Ardoq's dependency mapping and LeanIX's technology risk intelligence both do a version of this commercially — worth the license once you're maintaining this live across a few hundred applications, not worth buying for a single one-time exercise — but the underlying grammar predates either product: ArchiMate's Serving and Realization relationships trace exactly this chain — business capability to application service to technology service to the specific vendor's node — telling you precisely what breaks if one link disappears. The framework even ships a Technology Usage Viewpoint built for stakeholders "concerned with dependencies, performance and scalability." Simon Wardley's mapping technique goes further, plotting each dependency against how commoditized, how replaceable, it actually is. None of this is exotic. It's underused.

What "good" actually looks like

DORA doesn't leave exit plans vague. Article 28(8) requires them "comprehensive, documented... sufficiently tested and reviewed periodically." The regulatory technical standard under it (Delegated Regulation 2024/1773, Article 10) demands they be "realistic, feasible, based on plausible scenarios and reasonable assumptions." The ECB's own supervisory guide draws the sharpest line against box-ticking: "it is good practice for the feasibility of each exit plan to be independently verified" — reviewed by someone who didn't write it. That's the actual difference between DNB's 95% and its 34%: a document that exists, and a document somebody tested.

When nobody mapped it

Queensland Health's 2007 payroll system, built on an IBM contract, is the sharpest cautionary tale on record for what happens when an organization never tests whether it's actually locked in. The original whole-of-government contract was worth AU$98 million. The state's own Commission of Inquiry later estimated the ongoing cost would reach roughly AU$1.2 billion over the following eight years — with tens of thousands of staff exposed to the risk of pay errors along the way. The state's own minister told the inquiry, under oath, that he believed removing IBM would be too risky to attempt. The Commission's finding: that belief was never rigorously tested. Nobody had actually mapped whether the state could switch. They assumed it couldn't, and the assumption was projected to cost over a billion dollars.

AI makes this sharper — and the report never mentions it

Worth naming plainly: the "Towards Digital Autonomy" report doesn't discuss AI once, in either language version. That's the regulators' scope choice, not an oversight to correct — but the logic they apply to cloud concentration applies with more force to AI, and I want to spell out why: this next part is my own extension of their argument, not a claim the five regulators made. Cloud's top three providers hold 63% of enterprise spend. AI's top three hold 88%. Cloud infrastructure deprecates on multi-year cycles — Windows Server gets a decade's notice. Anthropic's own model-deprecation policy commits to a 60-day minimum notice; OpenAI's runs closer to six months for a GA model. A prompt tuned for one model can silently misbehave on another, because model behavior isn't a commodity the way compute is.

Kong AI Gateway and similar gateways solve the syntax problem — one API shape instead of three — but Kong's own engineering blog admits what they don't solve: "fine-tuned models are inherently provider-specific." Embeddings are worse: a vector only has meaning inside the model that created it, and re-embedding a real corpus can run into six figures. A gateway is a good, worthwhile tool for exactly what it does — it abstracts the API call. It was never going to abstract the dependency underneath it.

The Dutch government's own International AI Strategy, sent to parliament on 3 July — a week before the digital-autonomy report — names this directly: concentration of market power around AI infrastructure and models "could disrupt the international economy." Two Dutch government documents, a week apart, making the same argument about two different layers of the same stack, without citing each other.

The test

Here's the falsifiable test I'd apply: ask whoever owns your cloud or AI vendor relationships one question — if the primary provider became unusable tomorrow, a price shock, a service failure, a legal order neither of you controls, how long would switching actually take, and has anyone tested that number, or just assumed it? If the honest answer is "we've never tried," the sovereignty the regulators are asking for doesn't exist yet. It's a policy document waiting for the mapping work DNB's own survey shows most organizations still haven't done.

Building that dependency map starts small: one ArchiMate Technology Usage Viewpoint for your single largest vendor by spend, traced from business capability down to that vendor's specific node. That's not a policy document — it's exactly the kind of architecture-first work worth doing before the vendor conversation turns adversarial, not after. That's a conversation worth having early.

Sources & further reading

Continue reading

Get the next article in your inbox.

One deep-dive per week. Free. No pitch. Unsubscribe anytime.

Subscribe to the Delfen Briefing →
← Back to all articles