--- mpf: '0.7' title: Soevereiniteit — ESFI Docs url: https://docs.esfi.eu/nl/topics/sovereignty/ mpf-url: https://docs.esfi.eu/nl/topics/sovereignty/index.mpf organization: European Strategy & Future Infrastructure domain: docs.esfi.eu lang: nl updated: '2026-11-03' author: ESFI provenance: human source-hash: 87320cc075eee32508590ba210eb083c11a71e4d9843335013b7fbb1093f7618 toc: - level: 1 text: Soevereiniteit id: soevereiniteit - level: 2 text: Het object van soevereiniteit is afhankelijkheid id: het-object-van-soevereiniteit-is-afhankelijkheid - level: 2 text: Controle heeft meer dan één laag id: controle-heeft-meer-dan-één-laag - level: 2 text: Eigendom en controle zijn verschillend id: eigendom-en-controle-zijn-verschillend - level: 2 text: Een lijst van alternatieven is geen exit id: een-lijst-van-alternatieven-is-geen-exit - level: 2 text: Soevereiniteit vereist het vermogen om te oordelen id: soevereiniteit-vereist-het-vermogen-om-te-oordelen - level: 2 text: Niet elk bewijs zegt hetzelfde id: niet-elk-bewijs-zegt-hetzelfde - level: 2 text: Soevereiniteit is geen autarkie id: soevereiniteit-is-geen-autarkie - level: 2 text: Hoe we er samen aan werken id: hoe-we-er-samen-aan-werken - level: 2 text: Waar we voorzichtig zijn id: waar-we-voorzichtig-zijn - level: 2 text: Verder lezen id: verder-lezen - level: 2 text: Wijzigingen in deze positie id: wijzigingen-in-deze-positie - level: 2 text: Op deze pagina id: op-deze-pagina spec-origin: esfi.eu content-origin: docs.esfi.eu content-id: esfi:page:topics-sovereignty content-parity: html: true human-visible-source: true hidden-sections: false summary: Kunt u het veranderen wanneer dat nodig is? index: true confidence: probable content-type: analysis companion-footer: ESFI — civilization infrastructure · https://esfi.eu companion-contact: mailto:hermes@esfi.eu preferred-representation: mpf companion-scope: cite: true summarize: true train: true index: true relay: true language-variants: en: https://docs.esfi.eu/topics/sovereignty/index.mpf fr: https://docs.esfi.eu/fr/topics/sovereignty/index.mpf nl: https://docs.esfi.eu/nl/topics/sovereignty/index.mpf de: https://docs.esfi.eu/de/topics/sovereignty/index.mpf hr: https://docs.esfi.eu/hr/topics/sovereignty/index.mpf mpf-id: 081860ca33ceaefff092b9d1e97753122e3b0ee53734ac84d54f47ee5588f3fb --- Taal ✕ /nl/topics/sovereignty/index.mpf[bestand openen ↗](/nl/topics/sovereignty/index.mpf)[specificatie ↗](/nl/standards/mpf/0.7)✕ laden… # Soevereiniteit {#soevereiniteit} **Kunt u het veranderen wanneer dat nodig is?** Veel organisaties waarmee we spreken hebben gedaan wat het soevereiniteitsdebat van hen vroeg. Ze brachten diensten onder bij Europese aanbieders, kozen datacenters binnen de Unie en namen de juiste clausules in hun contracten op. En toen ze iets essentieels moesten veranderen, ontdekten ze dat ze dat niet konden. De identiteitsdienst hing nog steeds af van een externe control plane. Het supportpad liep door een andere jurisdictie. De enige mensen die het systeem konden herconfigureren werkten voor de leverancier. Daar begint meestal de echte vraag over soevereiniteit. Wij gebruiken soevereiniteit als engineeringbegrip, niet als label. De vraag is niet of een dienst een Europese vlag draagt. De vraag is of een instelling de afhankelijkheden onder een essentiële functie kan zien, begrijpt wie ze controleert en nog steeds kan handelen wanneer één ervan moet veranderen. Een systeem kan in Europa worden gehost en afhankelijk blijven van beslissingen die elders worden genomen. Een component kan van buiten Europa komen en toch deel uitmaken van een architectuur waarvan toegang, sleutels, operatie en vervangingspad stevig onder institutionele controle staan. Geografie is bewijs. Het is niet het antwoord. Onze positie is smaller en, denken wij, bruikbaarder. **Soevereiniteit is een operationele eigenschap van een systeem, niet een eigenschap van een leverancier.** Ze bestaat waar afhankelijkheid zichtbaar genoeg is om te besturen, begrensd genoeg om te veranderen en goed genoeg begrepen om de instelling claims erover te laten beoordelen. * * * ## Het object van soevereiniteit is afhankelijkheid {#het-object-van-soevereiniteit-is-afhankelijkheid} Wanneer soevereiniteit als eigenschap van leveranciers wordt besproken, verandert het gesprek in lijsten: goedgekeurde leveranciers, voorkeursjurisdicties, gecertificeerde clouds. Lijsten zijn nuttig voor inkoop. Ze vertellen een instelling zelden of zij kan handelen. Wij beginnen ergens anders: bij de essentiële functie en de afhankelijkheden eronder. De eenheid die we onderzoeken is de relatie tussen een functie en datgene waarop zij steunt. De praktische vragen zijn eenvoudig te stellen en vaak moeilijk te beantwoorden: - Waar is deze functie werkelijk van afhankelijk? - Wie kan die afhankelijkheid veranderen, opschorten of beperken? - Onder welke jurisdictie en contractuele voorwaarden werkt zij? - Welk deel ervan controleert de instelling, technisch en fysiek? - Wat gebeurt er met de functie als de leverancier, de route of de juridische situatie verandert? - Kan de afhankelijkheid worden geïsoleerd, vervangen of onder een ander operationeel model worden gebracht? Een soevereiniteitsclaim wordt pas bruikbaar wanneer de antwoorden een beslissing kunnen veranderen. Kunnen ze dat niet, dan is de claim decoratie. Wij zijn comfortabel met één antwoord dat veel beoordelingen vermijden: **onbekend.** Wanneer een afhankelijkheid niet met bewijs kan worden onderbouwd, laten we haar onopgelost en zeggen we dat. Onbekend is een aanvaardbaar antwoord. Veronderstelde controle niet. ## Controle heeft meer dan één laag {#controle-heeft-meer-dan-één-laag} Er bestaat niet één soevereiniteitslaag. Een digitale functie rust op meerdere systemen die verschillende eigenaars, jurisdicties en failure modes kunnen hebben. We vinden het nuttig vijf soorten controle te onderscheiden, omdat instellingen vaak de ene veiligstellen terwijl ze een andere verliezen. **Fysiek.** Digitale systemen draaien op glasvezelroutes, stroom, gebouwen en routingnodes. Een goed bestuurde applicatie op een onderlaag die de instelling niet kan zien of beïnvloeden blijft blootgesteld aan beslissingen die elders worden genomen. Juridische toegang tot infrastructuur en effectieve operationele toegang zijn niet hetzelfde: een recht om toegang te vragen kan nog steeds afhangen van procedures die door iemand anders worden gecontroleerd. **Operationeel.** Wie kan het systeem daadwerkelijk uitvoeren? Wie kan deployen, toegang intrekken, de sleutels houden, service herstellen en routing veranderen? Een dienst kan op de juiste plek worden gehost en toch voor elke betekenisvolle handeling afhankelijk zijn van een externe beheerder, identity provider of managed platform. **Juridisch.** Locatie levert bewijs maar beslist de jurisdictie niet. Juridische blootstelling hangt af van de operator, de eigenaar, het moederbedrijf, de contractpartij en het recht dat elke relatie beheerst. Een domeinsuffix of kantooradres is een signaal, geen conclusie. **Supply chain.** Hardware, firmware, software-updates, package registries en specialistisch onderhoud zijn allemaal controlepunten. In juli 2024 verstoorde een foutieve update van één beveiligingsleverancier wereldwijd systemen bij luchtvaartmaatschappijen, ziekenhuizen en publieke diensten, ongeacht waar die systemen werden gehost. Eén laag verplaatsen terwijl een niet-onderzocht controlepunt eronder blijft bestaan creëert geen soevereiniteit. **Informatie.** Instellingen zijn ook afhankelijk van hoe hun informatie wordt gepubliceerd en geïnterpreteerd. Als publieke informatie alleen kan worden begrepen via een proprietary platform of door giswerk van een modelaanbieder, is een deel van de publicatiegrens van de instelling naar buiten verplaatst. Hier raakt soevereiniteit aan ons werk rond [AI-readiness](/nl/topics/ai-readiness). Europese regelgeving weerspiegelt deze gelaagde visie steeds sterker. NIS2 verplicht essentiële en belangrijke entiteiten de beveiliging van hun supply chains aan te pakken, niet alleen die van hun eigen systemen. De logica is dezelfde: controle is slechts zo sterk als de minst onderzochte laag onder de functie. ## Eigendom en controle zijn verschillend {#eigendom-en-controle-zijn-verschillend} Het is natuurlijk om soevereiniteit gelijk te stellen aan eigendom. Als we het bezitten, controleren we het. In de praktijk lopen die twee voortdurend uiteen. Een organisatie kan haar infrastructuur bezitten en toch afhankelijk zijn van één leverancier voor beheer, één proprietary platform voor configuratie, één extern team voor herstel of één upstreamroute voor connectiviteit. Eigendom geeft een titel. Het geeft niet het vermogen om te handelen. Het omgekeerde is ook waar. Infrastructuur gebruiken die iemand anders bezit, neemt controle niet automatisch weg. Een bestuurde relatie kan echte controle geven als toegang, bevoegdheid, jurisdictie, beveiliging, continuïteit en exit expliciet en afdwingbaar zijn. Dat is belangrijk omdat het een realistischer pad opent. Geen instelling kan elke kabel, server en component bezitten waarop zij steunt. Zij kan wel de voorwaarden definiëren waaronder een afhankelijkheid aanvaardbaar is en ervoor zorgen dat die voorwaarden controleerbaar zijn. De vraag is niet “wie bezit alles?” De vraag is: **welke rechten en capaciteiten maken controle reëel voor de functie die we moeten beschermen?** ## Een lijst van alternatieven is geen exit {#een-lijst-van-alternatieven-is-geen-exit} Een veelgehoorde geruststelling in discussies over soevereiniteit is dat alternatieven bestaan. Er zijn andere clouds, andere aanbieders, andere producten. De afhankelijkheid is dus geen probleem. Een alternatief op de markt is geen exit. Een afhankelijkheid is pas substitueerbaar wanneer de instelling kan beschrijven hoe de essentiële functie naar een andere operationele situatie zou verhuizen zonder capaciteit, data, identiteit, beveiliging of herstelvermogen te verliezen. Dat betekent meestal begrijpen: - hoe data vertrekken en aankomen, en in welke vorm; - hoe identiteit en toegang veranderen; - op welke protocollen en interfaces de functie steunt; - hoe sleutels en certificaten verhuizen; - welke procedures en vaardigheden moeten veranderen; - welke contractuele of juridische beperkingen gelden; - hoe lang oude en nieuwe systemen parallel moeten draaien, en hoe rollback werkt. De Data Act is begonnen een deel hiervan voor clouddiensten aan te pakken door verplichtingen vast te leggen die overstappen tussen aanbieders eenvoudiger maken. Dat is een betekenisvolle stap. Op zichzelf maakt dat nog geen specifieke instelling in staat om over te stappen. **Substitutie is geen eigenschap van de markt. Het is een eigenschap van het gedeployde systeem.** Onze sterkste soevereiniteitstest volgt hieruit: kan de architectuur doelbewust veranderen zonder de functie te verliezen die zij moet beschermen? ## Soevereiniteit vereist het vermogen om te oordelen {#soevereiniteit-vereist-het-vermogen-om-te-oordelen} Elke beoordeling van soevereiniteit rust uiteindelijk op claims. Een leverancier verklaart waar data worden verwerkt. Een contract stelt wie toegang heeft. Een certificaat bevestigt een standaard. Een migratieplan belooft dat overstappen mogelijk is. Sommige van die claims zijn goed onderbouwd en andere niet. Het verschil is alleen zichtbaar voor iemand die ze kan beoordelen. Daarom behandelen we oordeelsvermogen als een voorwaarde voor soevereiniteit, niet als een optionele extra. Een instelling die niet kan beoordelen wat leveranciers haar over controle vertellen, heeft geen controle. Zij vertrouwt. Dat vertrouwen kan gerechtvaardigd zijn, maar het is iets anders. Oordeelsvermogen is hier geen document of checklist. Het is een toestand die de instelling moet bereiken en behouden: mensen die de afhankelijkheden goed genoeg begrijpen om de juiste vragen te stellen, een ontwijkend antwoord herkennen en weten welk bewijs de zaak zou beslissen. Het geldt ook voor de systemen die een instelling gebruikt. Een monitoring- of inkoopsysteem dat een declaratie niet van een geverifieerd feit kan onderscheiden, geeft die verwarring door aan iedereen die ervan afhankelijk is. Hier raakt soevereiniteit aan ons werk rond [Capaciteitsoverdracht](/nl/topics/capability-transfer). Formeel eigendom zonder het vermogen een systeem te beoordelen en te veranderen is een zwakke vorm van controle. Elke belangrijke beslissing loopt nog steeds via het begrip van iemand anders. ## Niet elk bewijs zegt hetzelfde {#niet-elk-bewijs-zegt-hetzelfde} Een soevereiniteitsclaim beoordelen begint met weten wat elke soort bewijs wel en niet kan aantonen. Een request dat in een browser wordt waargenomen kan laten zien dat een pagina contact maakt met een derde partij. Het kan niet laten zien waar de backend draait. Een DNS-record kan laten zien dat een provider gemachtigd is om namens een organisatie e-mail te versturen. Het kan niet laten zien dat dezelfde provider haar applicaties host. Een verklaring van een leverancier laat zien wat de leverancier verklaart. Ze laat niet zien waar een specifieke workload op een specifiek moment van afhankelijk is. Een eigendomsrecord stelt juridische titel vast. Het stelt geen operationele onafhankelijkheid vast. Dit zijn geen zwaktes van het bewijs. Het zijn de grenzen ervan. De fout is signalen van verschillende soorten samen te voegen tot één soevereiniteitsscore die verbergt wat elk ervan werkelijk bewijst. Wij houden ze gescheiden. Eén signaal blijft één signaal. Onafhankelijke signalen die overeenkomen versterken een bevinding. Een conclusie moet de soort bewijs dragen waarop zij steunt en de onbekenden die eronder blijven. ## Soevereiniteit is geen autarkie {#soevereiniteit-is-geen-autarkie} Soevereiniteit wordt soms gehoord als oproep om alles intern te bouwen of elke buitenlandse afhankelijkheid uit te sluiten. Zo zien wij het niet, en we denken niet dat het zou werken. Complexe infrastructuur wordt door onderlinge afhankelijkheid gebouwd. De taak is weten welke afhankelijkheden aanvaardbaar zijn, welke strategisch zijn, welke sterker bewijs nodig hebben, welke een exitpad nodig hebben en welke controle concentreren op een manier die een instelling niet zou moeten accepteren. Een goede soevereiniteitsarchitectuur kan externe leveranciers bevatten, ook niet-Europese. Wat zij niet kan bevatten zijn kritieke afhankelijkheden die niemand in kaart heeft gebracht, niemand kan besturen en niemand weet te vervangen. Dat is het verschil tussen interdependentie en afhankelijkheid zonder controle. ## Hoe we er samen aan werken {#hoe-we-er-samen-aan-werken} Onze aanpak van soevereiniteit volgt dezelfde volgorde als de rest van ons werk. **Breng de afhankelijkheid in kaart.** Identificeer voordat u alternatieven voorstelt waarop de functie steunt over fysieke, operationele, juridische, supply-chain- en informatielagen heen, en waar controle geconcentreerd is. **Definieer de controlegrens.** Bepaal samen met de instelling welke afhankelijkheden aanvaardbaar zijn, welke voorwaarden nodig hebben en welke voor deze functie niet aanvaardbaar zijn. Druk die voorwaarden uit in termen die controleerbaar zijn. **Bouw het alternatief waar de grens niet aanvaardbaar is.** Niet alles tegelijk. Eerst de strategische functies, met een migratiepad dat werkelijk is uitgewerkt in plaats van verondersteld. **Laat bewijs en oordeelsvermogen achter.** De instelling moet eindigen met een dossier dat zij kan onderhouden en mensen die de volgende claim zelf kunnen beoordelen. Wij passen dezelfde discipline op onszelf toe. De infrastructuur die we exploiteren en de open formaten die we publiceren maken deel uit van hoe we testen of deze manier van werken in de praktijk standhoudt. We kunnen anderen niet geloofwaardig vragen hun afhankelijkheden zichtbaar te maken terwijl we onze eigen operationele stack als black box behandelen. Wanneer we samen met een partner naar een afhankelijkheid kijken, leggen we doorgaans deze vragen vast: | Vraag | Wat ze zichtbaar maakt | | --- | --- | | Welke essentiële functie ondersteunt deze afhankelijkheid? | Waarom ze überhaupt belangrijk is. | | Wat is precies nodig: systeem, operator, route, platform, autoriteit? | Het werkelijke object van de afhankelijkheid. | | Hoe weten we dat de relatie bestaat? | De soort bewijs en de grenzen ervan. | | Wie kan haar beheren, veranderen, opschorten of herstellen? | Waar controle werkelijk ligt. | | Welke juridische relaties gelden, en welke zijn onopgelost? | Juridische blootstelling. | | Wat gebeurt er met de functie als ze verdwijnt? | Het gevolg van verlies. | | Kan ze worden geïsoleerd of vervangen, en wat moet mee verhuizen? | De echte substitutiegrens. | | Wat blijft ongeverifieerd? | De eerlijke grens van de beoordeling. | ## Waar we voorzichtig zijn {#waar-we-voorzichtig-zijn} We houden ons aan enkele toezeggingen over wat we claimen. We noemen een afhankelijkheid alleen gecontroleerd voor zover het bewijs controle over de relevante functie ondersteunt. We leiden jurisdictie niet af uit een domeinnaam of hostingadres en behandelen een verklaring van een leverancier niet als bewijs van hoe een systeem draait. We noemen een afhankelijkheid niet vervangbaar omdat er een alternatief op de markt bestaat. Alleen een migratiepad dat werkelijk is uitgewerkt verdient dat woord. We verbergen onopgeloste afhankelijkheden niet achter één score. Waar iets onbekend is, zeggen we dat. En we presenteren soevereiniteit niet als isolatie. Ons doel is smaller: het praktische vermogen om te weten waar afhankelijkheid zit, te beslissen welke afhankelijkheid aanvaardbaar is en te handelen wanneer dat niet zo is. * * * ## Verder lezen {#verder-lezen} - [Richtlijn (EU) 2022/2555 (NIS2)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj), over maatregelen voor een hoog gemeenschappelijk niveau van cyberbeveiliging in de Unie. - [Verordening (EU) 2023/2854 (Data Act)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj), met onder meer bepalingen over overstappen tussen dataverwerkingsdiensten. **Gerelateerde thema’s:** [Capaciteitsoverdracht](/nl/topics/capability-transfer) · [Veerkracht](/nl/topics/resilience) · [AI-readiness](/nl/topics/ai-readiness) * * * ## Wijzigingen in deze positie {#wijzigingen-in-deze-positie} - 24 september 2026 — Voor het eerst gepubliceerd. Materiële wijzigingen worden hier met datum vermeld. Correcties van formulering of links worden niet opgenomen. ## Op deze pagina {#op-deze-pagina} ESFI — civilization infrastructure · https://esfi.eu