Zo maakt SEAL je cloudsoevereiniteit meetbaar

Waarom is SEAL nu relevant?

Nieuwe regelgeving zoals DORA en NIS2, de opkomst van AI en toenemende geopolitieke onzekerheid zorgen ervoor dat organisaties kritischer kijken naar hun afhankelijkheid van cloudproviders. Het SEAL-framework helpt om die afhankelijkheden inzichtelijk te maken en beter onderbouwde keuzes te maken over cloudsoevereiniteit.

De (verborgen) kosten bij onvoldoende soevereiniteit

Een gebrek aan cloudsoevereiniteit leidt zelden direct tot een incident. Veel vaker uit het zich in hogere kosten, minder flexibiliteit en toenemende afhankelijkheid van leveranciers.

• Langere migraties - Sterke afhankelijkheden van één platform maken overstappen complexer en tijdrovender.
• Vendor lock-in - Minder keuzevrijheid en een zwakkere onderhandelingspositie richting leveranciers.
• Compliance-risico's - Beperkt inzicht in datalocaties, jurisdicties en leveranciersketens kan compliance bemoeilijken.
• Beperkingen bij aanbestedingen - Soevereiniteitseisen spelen een steeds grotere rol in selectie- en aanbestedingstrajecten.
• Hogere exitkosten - Zonder afspraken over dataportabiliteit en migratie kunnen overstappen duur uitvallen.

SEAL maakt soevereiniteit meetbaar

Het SEAL-framework biedt een gestructureerde manier om cloudsoevereiniteit te beoordelen. Het kijkt verder dan alleen de locatie van data en beoordeelt onder meer eigenaarschap, wetgeving, technologische afhankelijkheden en de overdraagbaarheid van workloads. Elke doelstelling krijgt een eigen SEAL-niveau. Voldoet een clouddienst op één onderdeel niet aan het vereiste niveau, dan compenseren sterke scores op andere onderdelen dat niet. Daarom moet je cloudsoevereiniteit als één geheel benaderen, waarin juridische, operationele, technologische en organisatorische factoren samen de uitkomst bepalen.

Vijf SEAL-niveaus voor cloudsoevereiniteit 

Het framework kent vijf niveaus, van SEAL-0 tot SEAL-4. Ze beschrijven hoeveel praktische soevereiniteit en weerbaarheid een cloud-dienst biedt:

SEAL-0: Geen soevereiniteit

De dienst, technologie of operatie staat onder zeggenschap van partijen buiten de EU en valt onder niet-EU-rechtsgebieden. 

SEAL-1: Jurisdictionele soevereiniteit 

EU-recht is formeel van toepassing, maar de praktische afdwingbaarheid is beperkt. De dienst, technologie of operatie blijft exclusief onder controle van niet-EU-partijen.

SEAL-2: Datasoevereiniteit 

EU-recht is van toepassing en afdwingbaar en controle over data is geregeld. Er blijven echter materiële niet-EU-afhankelijkheden bestaan en niet-EU-partijen kunnen indirecte controle uitoefenen.

SEAL-3: Digitale weerbaarheid

EU-recht is van toepassing en afdwingbaar. EU-partijen hebben betekenisvolle, maar nog geen volledige invloed. De controle van niet-EU-partijen is marginaal.

SEAL-4: Volledige digitale soevereiniteit 

De technologie en operatie staan onder EU-controle, vallen onder EU-jurisdictie en zijn vrij van kritieke afhankelijkheden van buiten de EU. 

Het juiste streefniveau hangt af van je workloads en risicoprofiel. Een publieke website en een systeem met gereguleerde of bedrijfskritische data hoeven niet hetzelfde niveau te hebben. 

Acht doelstellingen die je soevereiniteit bepalen 

SEAL beoordeelt een cloud dienst aan de hand van acht doelstellingen. Samen maken ze afhankelijkheden zichtbaar die in een gesprek over alleen de locatie van data buiten beeld blijven. 

1. Strategische soevereiniteit 

Wie heeft uiteindelijk zeggenschap over de provider en diens beslissingen? Deze doelstelling kijkt naar eigendom, governance, financiering en continuïteit wanneer een belangrijke technologiepartner zijn ondersteuning beëindigt. 

Vragen die je kunt stellen: 

• Waar ligt de doorslaggevende beslissingsbevoegdheid? 

• Wie is eigenaar van de provider en wie financiert deze? 

• Kan de dienst doorgaan als een strategische leverancier stopt met ondersteunen? 

2. Juridische en jurisdictionele soevereiniteit 

Welke wetgeving is van toepassing op de dienst, de contracten en de toegang tot data? Opslag in Europa sluit blootstelling aan wetgeving van buiten de EU - zoals de US Cloud Act - niet automatisch uit. 

Vragen die je kunt stellen: 

• Welke jurisdictie geldt voor het contract? 

• Kan een buitenlandse autoriteit de provider verplichten data te verstrekken? 

• Zijn procedures voor toegang en verstrekking transparant? 

3. Data- en AI-soevereiniteit 

Wie beheert de data, encryptiesleutels en AI-workloads? Deze doelstelling omvat datalocatie, toegang, logging, cryptografische controle en het gebruik van data in AI-diensten. 

Vragen die je kunt stellen: 

• Waar worden data verwerkt en opgeslagen? 

• Wie bezit en beheert de encryptiesleutels? 

• Kunnen alle toegangsverzoeken en wijzigingen worden gecontroleerd? 

• Mogen data worden gebruikt om een AI-model te trainen of uit te voeren? 

4. Operationele soevereiniteit 

Kunnen Europese teams de dienst uitvoeren, onderhouden en herstellen zonder afhankelijk te zijn van ondersteuning van buiten de EU? 

Vragen die je kunt stellen: 

• Waar bevinden de support- en operationele teams zich? 

• Kan de dienst doorgaan zonder interventie op afstand van buiten de EU? 

• Zijn de vereiste kennis en documentatie in Europa beschikbaar? 

• Kunnen workloads verplaatst worden?

5. Soevereiniteit van de toeleveringsketen 

Een cloud-dienst is afhankelijk van hardware, firmware, software en onderaannemers. Deze doelstelling beoordeelt of die keten transparant en beheersbaar is. 

Vragen die je kunt stellen: 

• Waar komen kritieke componenten vandaan? 

• Welke leveranciers kunnen de dienst wijzigen of onderbreken? 

• Zijn onderaannemers zichtbaar? 

• Heb je auditrechten in de hele toeleveringsketen? 

6. Technologische soevereiniteit 

Kun je de technologie inspecteren, integreren, migreren en vervangen? Open standaarden, gedocumenteerde interfaces en exportmogelijkheden verkleinen de afhankelijkheid van één platform. 

Vragen die je kunt stellen: 

• Gebruikt de dienst open standaarden en uitwisselbare API’s? 

• Kunnen workloads en data in bruikbare formaten worden geëxporteerd? 

• Is de architectuur gedocumenteerd? 

• Wat gebeurt er wanneer licenties, prijzen of productbeleid veranderen? 

7. Soevereiniteit over security en compliance 

Beveiligingsmaatregelen moeten aantoonbaar zijn. Deze doelstelling omvat certificeringen, incidentrespons, auditbaarheid en het vermogen om kwetsbaarheden te beheren zonder dat een externe partij de controle overneemt. 

Vragen die je kunt stellen: 

• Welke certificeringen en onafhankelijke audits zijn van toepassing? 

• Waar worden securityactiviteiten uitgevoerd? 

• Wie beheert incidentrespons en patching? 

• Hoe wordt bewijs voor compliance beschikbaar gesteld? 

8. Ecologische duurzaamheid 

Het framework betrekt ook de langetermijnweerbaarheid rond energiegebruik, energieafhankelijkheid en schaarse grondstoffen bij de beoordeling. Daarbij kijkt het onder meer naar energie-efficiëntie, energiebronnen, circulariteit en transparante rapportage over uitstoot en watergebruik.

De zwakste schakel telt het zwaarst

Stel dat een cloud-dienst goed scoort op datalocatie, Europese operatie, security en duurzaamheid. Als het kernplatform afhankelijk is van gesloten technologie die je niet kunt inspecteren, vervangen of zelfstandig gebruiken, blijft technologische soevereiniteit de beperkende factor. 

Dat geldt ook voor andere combinaties: 

• Europese hosting neemt blootstelling aan buitenlandse jurisdictie niet weg. 

• Sterke contracten lossen een ondoorzichtige toeleveringsketen niet op. 

• Open technologie compenseert geen zwakke toegangsmaatregelen. 

• Een veilig cloudplatform helpt niet als workloads niet kunnen worden geëxporteerd. 

• Een Europese provider kan nog steeds afhankelijk zijn van kritieke niet-Europese componenten. 

SEAL voorkomt dat een tekort op een cruciale doelstelling volledig wordt gecompenseerd door andere onderdelen. Voor iedere doelstelling kan namelijk een minimumniveau gelden. Daarnaast berekent het framework een afzonderlijke, gewogen Sovereignty Score voor de onderlinge vergelijking van clouddiensten.

Gebruik SEAL om keuzes voor workloads te maken 

SEAL is niet bedoeld om iedere workload in de meest beperkende omgeving te plaatsen. Het biedt een gemeenschappelijk beoordelingsmodel om vast te stellen welk soevereiniteitsniveau elke workload nodig heeft. 

• Publieke en schaalbare workloads: klantgerichte websites, digitale diensten en tijdelijke workloads kunnen profiteren van het bereik en de elasticiteit van een public cloud. De keuze hangt af van de betrokken data en de gevolgen van veranderingen in de dienst of bij de leverancier.
• Gevoelige of gereguleerde workloads: overheidssystemen, defensie, vitale infrastructuur, financiële gegevens, gezondheidsinformatie, intellectueel eigendom en burgerdata kunnen strengere juridische, operationele en datagerichte controles vereisen. 
• Bedrijfskritische workloads: applicaties die essentiële processen ondersteunen, hebben meer nodig dan veilige dataopslag. Je hebt ook continuïteitsplannen, voorspelbare connectiviteit, transparantie over leveranciers en geteste migratiemogelijkheden nodig. 
• AI-workloads: AI roept extra vragen op over trainingsdata, modeltoegang, verwerkingslocaties, accelerators, softwarecomponenten en exportbeperkingen. Beoordeel de volledige pipeline en niet alleen de hostinglocatie. 

Een hybride cloudarchitectuur kan deze verschillen ondersteunen, mits elke workload bewust wordt geplaatst en kan worden verplaatst wanneer de eisen veranderen. 

Begin bij je zwakste afhankelijkheid 

Een bruikbare beoordeling van soevereiniteit begint met bewijs, niet met het label van een provider. Breng je kritieke workloads in kaart en beoordeel elke workload aan de hand van de acht SEAL-doelstellingen. Leg vast welke maatregelen je kunt verifiëren, welke afhankelijkheden je accepteert en waar bewijs ontbreekt. Bepaal daarna welk minimumniveau bij die workload past. 

Begin met deze vragen: 

• Welke workloads hebben de grootste impact op klanten, compliance of continuïteit? 

• Welk minimaal SEAL-niveau heeft elke workload nodig? 

• Welke doelstelling krijgt momenteel het laagste niveau? 

• Welke afhankelijkheid veroorzaakt dat resultaat? 

• Kun je de afhankelijkheid verkleinen via de architectuur, contracten of een andere leverancier? 

• Heb je getest of data en workloads kunnen worden verplaatst? 

• Wie beoordeelt de uitkomst opnieuw wanneer technologie of leveranciers veranderen?