Door Cronos Amsterdam · Gepubliceerd op
Waarom het onderscheid ertoe doet
In gesprekken over cloud worden ‘data in de EU’ en ‘soeverein’ vaak als synoniemen gebruikt. Dat leidt tot schijnzekerheid. Een workload kan netjes in Frankfurt of Amsterdam draaien en toch beheerd worden door een team buiten Europa, met sleutels die de aanbieder zelf beheert, en met een architectuur die zo leunt op eigen diensten van één platform dat overstappen in de praktijk jaren kost.
Andersom hoeft niet elke workload maximaal soeverein te zijn. Een publieke marketingsite heeft andere eisen dan een patiëntendossier of een betalingssysteem. Het doel van onderstaande checklist is dus niet om overal het strengste antwoord te kiezen, maar om per workload bewust en navolgbaar te beslissen.
Zes dimensies die je apart moet beoordelen
Behandel soevereiniteit niet als één ja/nee-vraag. Splits het op in zes dimensies en leg per dimensie vast wat de eis is, hoe die wordt ingevuld en welk restrisico je accepteert. Zo wordt een abstract begrip een set controleerbare ontwerpkeuzes die je kunt uitleggen aan een CISO, een auditor of de board.
Hoe je de checklist gebruikt
- Classificeer eerst je workloads en data: wat is kritiek, wat is gevoelig, wat is publiek?
- Bepaal per klasse welke dimensies een harde eis zijn, welke een wens en welke niet relevant.
- Toets je huidige en beoogde aanbieders per dimensie, op basis van contractuele afspraken en technische inrichting, niet alleen marketingteksten.
- Leg de afweging vast, inclusief kosten en functionaliteit die je eventueel inlevert.
- Laat de juridische interpretatie toetsen door je eigen juristen of adviseurs; de checklist levert de technische onderbouwing.
Beslischecklist per workload
Stel deze vragen per workload of dataklasse. Een ‘weet ik niet’ is ook een uitkomst: dan weet je waar je onderzoek nodig hebt.
- 1. Datalocatie — In welke regio's staan primaire data, back-ups, logs en replica's? Gaan supportgegevens of telemetrie ergens anders heen?
- 2. Jurisdictie — Onder welk recht valt de aanbieder en zijn moederbedrijf? Welke partijen kunnen op grond van wetgeving toegang vorderen, en hoe wordt je daarover geïnformeerd?
- 3. Beheerderstoegang — Wie kan bij je omgeving, vanaf waar, onder welke voorwaarden? Wordt beheerderstoegang gelogd en kun je die logs zelf inzien?
- 4. Sleutelbeheer — Wie genereert, bewaart en roteert de encryptiesleutels? Kun je sleutels buiten de aanbieder beheren als de dataklasse dat vraagt?
- 5. Afhankelijkheden — Welke diensten zijn specifiek voor één platform? Welke software, identity-provider of beheertooling ligt buiten je directe controle?
- 6. Exit — Kun je data en workloads in een open formaat exporteren? Is er een getest exitplan met doorlooptijd, kosten en verantwoordelijken?
Grenzen van deze checklist
- Deze gids is geen juridisch advies. Of een inrichting voldoet aan NIS2, DORA, de AVG of sectorale regels, vraagt juridische toetsing.
- Een Europese aanbieder kiezen lost niet automatisch alle dimensies op; beheerderstoegang, sleutelbeheer en exit blijven ontwerpkeuzes.
- Meer soevereiniteit kan betekenen dat je minder kant-en-klare managed services gebruikt. Dat vraagt bewuste keuzes in ontwerp en beheer.
Verder lezen
Bronnen
Deze gids is in eigen woorden geschreven. Voor achtergrond verwijzen we naar de volgende primaire bronnen.