Sovereign by design architectuurprincipes zijn de verzameling van ontwerpbeslissingen die samen garanderen dat een systeem structureel buiten de rechtsmacht van niet-gewenste jurisdicties blijft, ongeacht hoe het later wordt geconfigureerd of uitgebreid. Het concept bouwt voort op privacy-by-design (AVG artikel 25) en security-by-design, maar voegt een derde dimensie toe: juridische en technische onafhankelijkheid als intrinsieke systeemeigenschap.
Van privacy-by-design naar sovereign by design: wat verandert er?
Privacy-by-design, zoals verankerd in AVG artikel 25, verplicht verwerkingsverantwoordelijken om gegevensbescherming in te bouwen in de architectuur. Sovereign by design erkent dat dit niet voldoende is wanneer de infrastructuur zelf buiten de Europese rechtssfeer valt.
Wojciech Wiewiórowski, Europese Toezichthouder voor Gegevensbescherming (EDPS), stelde in zijn opinies over clouddiensten: “Privacy by design is niet voldoende wanneer de infrastructuur zelf buiten de rechtsmacht van de betrokkene valt. Soevereiniteit begint bij de architectuurkeuze, niet bij de privacyverklaring.”
Waar privacy-by-design vraagt “verwerken we zo min mogelijk persoonsgegevens?”, vraagt sovereign by design ook: “heeft een vreemde mogendheid structureel toegangsrecht tot onze systemen of data, en zo ja, sluit de architectuur dat uit?” De antwoorden op deze vragen moeten al vaststaan vóórdat een product wordt geselecteerd, een contract wordt ondertekend of een eerste API-koppeling wordt gebouwd.
Technische patronen die een sovereign-by-design systeem definiëren
Sovereign by design is herkenbaar aan een combinatie van concrete technische kenmerken. Vier patronen zijn bepalend en sluiten direct aan op het CADA-soevereiniteitskader (Control, Auditability, Data locality, Autonomy).
Lokaal sleutelbeheer
Encryptie is alleen soeverein wanneer de encryptiesleutels uitsluitend door de eigen organisatie worden beheerd, op eigen infrastructuur of in een door de organisatie gecontroleerde hardware security module (HSM). Zodra een cloudaanbieder de sleutels beheert of toegang heeft tot de sleutelkluizen, kan die aanbieder onder druk van de US CLOUD Act of soortgelijke wetgeving worden gedwongen tot toegangsverlening. Breng-eigen-sleutel-constructies (BYOK) bij hyperscalers lossen dit slechts gedeeltelijk op: de sleutelinfrastructuur draait nog steeds op niet-soevereine hardware.
Geen externe telemetrie als standaard
Veel commerciële softwareproducten sturen gebruiksstatistieken, foutmeldingen en systeemdata naar servers van de leverancier. Dit is een structurele datavloeistroom buiten de eigen organisatiegrenzen. De OWASP Security Design Principles benoemen “least privilege” en “minimise attack surface” als basisprincipes; sovereign by design voegt hieraan toe dat telemetrie naar niet-Europese servers zelf een aanvalsoppervlak vormt voor jurisdictionele toegang.
Auditeerbare logging met tamper-evidence
Soevereiniteit vereist aantoonbaarheid. Logbestanden moeten onveranderlijk zijn, lokaal worden opgeslagen en onafhankelijk van de leverancier kunnen worden geëxporteerd. Dit sluit aan op NIS-2 artikel 21, dat risicobeheersingsmaatregelen vereist inclusief “monitoring, auditing en testing”. Wanneer logdata alleen beschikbaar is via een portaal van de leverancier, verdwijnt de soevereiniteit over het bewijs van eigen handelen.
Open standaarden en uitstapbaarheid
Propriëtaire dataformaten en API’s creëren structurele leveranciersafhankelijkheid. Sovereign-by-design systemen gebruiken open standaarden (zoals OpenID Connect, CalDAV, CardDAV, S/MIME) zodat data zonder conversieverlies naar een andere aanbieder of naar eigen infrastructuur kan worden verplaatst. De ENISA Cloud Security Guide for SMEs benadrukt portabiliteit als een kernelement van cloudrisicobeheersing.
Sovereign by design versus compliance-achteraf: een structureel verschil
Compliance-achteraf is de praktijk waarbij een niet-soeverein systeem wordt voorzien van een nalevingsoverlaag: een verwerkersovereenkomst, een privacyverklaring, een aanvullende encryptielaag of een juridisch advies over jurisdictierisico. Dit pakt de symptomen aan zonder de oorzaak weg te nemen.
| Kenmerk | Sovereign by design | Compliance-achteraf |
|---|---|---|
| Moment van soevereiniteitsbeslissing | Vóór architectuurkeuze en leveranciersselectie | Na implementatie, bij audit of incident |
| Juridische blootstelling CLOUD Act | Structureel uitgesloten door infrastructuurkeuze | Aanwezig; gedeeltelijk verzacht via contracten |
| Sleutelbeheer | Volledig bij de organisatie | Vaak bij de aanbieder of gedeeld |
| Telemetrie | Standaard uitgeschakeld of afwezig | Standaard aan; soms configureerbaar |
| Aantoonbaarheid bij toezichthouder | Technisch aantoonbaar via architectuurdocumentatie | Afhankelijk van leveranciersverklaringen |
Organisaties die soevereiniteit als overlaag toevoegen aan bestaande Microsoft 365- of Google Workspace-omgevingen lopen het risico dat zij bij een rechterlijk bevel gericht aan de Amerikaanse moederonderneming geen effectieve bescherming hebben, ongeacht de contractuele afspraken met de Europese dochter. Dit is bevestigd in de juridische analyse rondom het Schrems II-arrest van het Hof van Justitie van de EU (2020).
Meer dan 70% van de Europese cloudomzet gaat naar hyperscalers die onder de US CLOUD Act vallen (ENISA Threat Landscape 2023). Dit betekent dat de meerderheid van Europese organisaties structureel een jurisdictioneel risico draagt dat niet via een verwerkersovereenkomst weggecontracteerd kan worden.
Sovereign by design in de SDLC en aanbesteding
Soevereiniteitseisen moeten worden ingebed in het systeemontwikkelingsproces (SDLC) en in aanbestedingsdocumenten, niet pas worden getoetst bij acceptatietests. Dit vraagt om specifieke criteria in drie fasen.
Eisen in de aanbestedingsfase
Aanbestedende organisaties in de publieke sector, de juridische sector en gereguleerde branches kunnen in hun Programma van Eisen CADA-criteria opnemen als knock-outcriteria: een aanbieder die niet kan aantonen dat sleutelbeheer volledig bij de klant ligt, dat telemetrie standaard uitgeschakeld is en dat data uitsluitend op Europees of Swiss grondgebied wordt verwerkt, voldoet niet aan de basisvereiste. Dit is een concrete toepassing van het CADA-soevereiniteitskader in een aanbestedingscontext.
Eisen in de ontwerpfase (design gate)
In Agile of waterval SDLC-trajecten kan een sovereign-by-design gate worden ingebouwd als verplicht reviewmoment vóór de architectuurfase. Bij dit reviewmoment worden minimaal de volgende vragen beantwoord: Welke externe verbindingen maakt het systeem standaard? Wie bezit de encryptiesleutels? Welke wet- en regelgeving heeft voorrangsrecht op data in het systeem? Welke auditlogs worden lokaal opgeslagen?
ENISA registreerde in 2022 en 2023 meer dan 1000 significante incidenten in sectoren die onder NIS-regelgeving vallen (ENISA NIS Investments Report 2023). Een groot deel van die incidenten betrof toeleveringsketen-aanvallen waarbij de kwetsbaarheid lag bij externe systemen die al in de ontwerpfase toegang hadden gekregen.
De Cyber Resilience Act en secure-by-default als inkoopcriterium
De Cyber Resilience Act (CRA), van kracht in 2024, introduceert in artikel 13 de verplichting voor fabrikanten van producten met digitale elementen om “beveiligde standaardinstellingen” te leveren. ENISA omschrijft dit principe als volgt: “Secure-by-default betekent dat veilige instellingen de standaard zijn, niet een optie die de gebruiker zelf moet activeren. Hetzelfde principe geldt voor soevereiniteit: het moet de standaard zijn, niet een add-on.”
Voor inkopende organisaties betekent CRA artikel 13 dat zij bij leveranciers kunnen en moeten eisen dat telemetrie naar externe servers standaard uitgeschakeld is, dat externe beheeraccess alleen op expliciete uitnodiging beschikbaar is en dat beveiligingsupdates worden geleverd zonder de soevereiniteitsarchitectuur te doorbreken. Dit sluit aan op NIS-2 artikel 21, dat toeleveringsketenveiligheid expliciet als risicobeheersingsmaatregel benoemt.
Een sovereign-by-design checklist voor DPIA en NIS-2
IT-beslissers en compliance officers kunnen de volgende checklist inzetten bij zowel GDPR Data Protection Impact Assessments (DPIA, verplicht op grond van AVG artikel 35) als NIS-2 risicobeheersingsbeoordelingen. De checklist integreert de vereisten van beide kaders met de CADA-criteria.
1. Jurisdictierisicoanalyse: Identificeer onder welke nationale wetgeving de aanbieder valt. Is de aanbieder onderworpen aan de US CLOUD Act, de Chinese Cyberveiligheidswet of vergelijkbare extraterritoriale toegangswetten? Documenteer dit als verwerkt risico in de DPIA.
2. Sleutelbeheerbeoordeling: Beheert de eigen organisatie alle encryptiesleutels, inclusief de sleutels voor back-ups en archief? Zijn HSM-locaties in Europese jurisdictie of op eigen locatie? Dit is aantoonbaarheid voor NIS-2 artikel 21 lid 2 sub h (cryptografie).
3. Telemetrieaudit: Welke data verlaat de eigen infrastructuur richting de leverancier? Is dit gedocumenteerd als gegevensoverdracht in de verwerkingenregistratie? Is opt-out technisch gegarandeerd of alleen contractueel?
4. Logintegriteitscontrole: Zijn logbestanden onveranderlijk opgeslagen op infrastructuur buiten bereik van de applicatielaag? Kunnen ze onafhankelijk van de leverancier worden geëxporteerd voor toezichthoudersinzage?
5. Portabiliteitstest: Kan alle data in een open, gedocumenteerd formaat worden geëxporteerd? Is er een exit-plan dat uitvoerbaar is zonder medewerking van de huidige leverancier?
6. CRA-conformiteitverificatie: Voldoet het product aan CRA artikel 13 (secure-by-default)? Is de leverancier aantoonbaar verantwoordelijk voor beveiligingsupdates gedurende de verwachte levensduur?
In 2023 bevatte 91% van de onderzochte ransomware-aanvallen een datalekkagecomponent naast encryptie (Verizon Data Breach Investigations Report 2023). Dit onderstreept dat soevereiniteitsarchitectuur niet alleen over toegangsbeheer gaat, maar ook over het beperken van de aanvalsoppervlakte voor data-exfiltratie via externe systemen en telemetriekanalen.
FAQ: Sovereign by design in de praktijk
Wat is het verschil tussen sovereign by design en privacy by design?
Privacy by design (AVG artikel 25) richt zich op het minimaliseren van persoonsgegevensverwerking en het inbouwen van gegevensbeschermingsmaatregelen. Sovereign by design gaat verder: het sluit ook uit dat een systeem structureel afhankelijk is van jurisdicties buiten de EU, door eisen te stellen aan sleutelbeheer, telemetrie, leveranciersbinding en toepasselijke wetgeving. Soevereiniteit omvat privacy maar is breder.
Waarom is compliance-achteraf onvoldoende bij cloudmigraties naar niet-Europese aanbieders?
Wanneer een systeem al is gebouwd op infrastructuur die onder de US CLOUD Act of Patriot Act valt, zijn de fundamentele afhankelijkheden technisch en contractueel verankerd. Encryptielagen of verwerkersovereenkomsten veranderen de juridische jurisdictie van de aanbieder niet. Sovereign by design vereist dat de architectuurbeslissing om buiten niet-Europese jurisdicties te blijven al vóór de eerste code of het eerste contract wordt genomen.
Hoe sluit sovereign by design aan op NIS-2 artikel 21?
NIS-2 artikel 21 verplicht essentiële en belangrijke entiteiten tot risicobeheersingsmaatregelen, waaronder beveiliging van de toeleveringsketen en toegangscontrole. Een sovereign-by-design systeem maakt aantoonbaar dat leveranciersbinding, externe telemetrie en buitenlandse rechtstoegang als risico’s zijn geïdentificeerd en structureel zijn gemitigeerd, niet achteraf gedocumenteerd.
Wat schrijft de Cyber Resilience Act voor over secure-by-default bij sovereign inkoop?
Artikel 13 van de Cyber Resilience Act verplicht fabrikanten van producten met digitale elementen om beveiligde standaardinstellingen te leveren. Voor sovereign inkoop betekent dit dat aanbestedende organisaties kunnen eisen dat telemetrie standaard uitgeschakeld is, dat lokaal sleutelbeheer de standaardmodus is en dat externe terugkoppeling naar leverancierssystemen opt-in is in plaats van opt-out.
Hoe verwerk ik sovereign-by-design criteria in een DPIA?
Een DPIA op grond van AVG artikel 35 moet de risico’s van verwerking beschrijven en maatregelen benoemen. Sovereign-by-design criteria voegen hieraan toe: een jurisdictierisicoanalyse, een sleutelbeheerbeoordeling en een telemetrieaudit. Deze elementen sluiten aan bij de DPIA-methodologie die de Autoriteit Persoonsgegevens publiceert en maken de soevereiniteitsmaatregel aantoonbaar voor de toezichthouder.
