Hoe u DORA-conforme operationele weerbaarheid bereikt zonder afhankelijkheid van Amerikaanse cloudproviders
De Digital Operational Resilience Act (DORA, Verordening EU 2022/2554) is vanaf 17 januari 2025 van kracht en stelt uniforme vereisten voor ICT-beveiliging binnen de Europese financiële sector. DORA structureert zijn vereisten rond vijf pijlers: ICT-risicobeheer, incidentmanagement en rapportage, testen van digitale operationele weerbaarheid, derde partij ICT-risicobeheer en het delen van cyberdreigingsinformatie. Elke pijler gaat ervan uit dat financiële instellingen daadwerkelijk controle houden over hun ICT-infrastructuur en de data die zij verwerken.
Die aanname vormt een fundamenteel probleem voor Europese financiële instellingen die afhankelijk zijn van Amerikaanse cloudproviders. Wanneer de kritieke data-uitwisselingsplatforms van een bank worden beheerd door aanbieders die onder de CLOUD Act en FISA Section 702 vallen, is de operationele weerbaarheid van de instelling afhankelijk van een buitenlands juridisch regime waarover zij geen controle heeft. Een Amerikaans verzoek tot data-inzage activeert niet het incident response-proces van de bank. Het omzeilt deze volledig. De provider voldoet aan het verzoek zonder de bank te informeren, waardoor de bank de datasoevereiniteit die het DORA-weerbaarheidskader impliciet vereist, niet kan aantonen.
Deze gids analyseert elke DORA-pijler vanuit het perspectief van afhankelijkheid van Amerikaanse cloudproviders en legt uit hoe Europese financiële instellingen echte operationele weerbaarheid kunnen bereiken via soevereine architectuur die het buitenlandse toegangsrisico elimineert in plaats van beheert.
Samenvatting
Belangrijkste idee: DORA’s vijf pijlers vereisen dat Europese financiële instellingen operationele weerbaarheid aantonen op het gebied van ICT-risicobeheer, incidentafhandeling, weerbaarheidstesten, toezicht op derden en informatie-uitwisseling. Elke pijler wordt ondermijnd wanneer kritieke dataplatforms worden beheerd door aanbieders die onder buitenlandse overheidswetgeving vallen. DORA-conforme weerbaarheid vereist een soevereine architectuur: klantgestuurde encryptie, single-tenant Europese inzet en operationele onafhankelijkheid van de infrastructuur van Amerikaanse providers.
Waarom dit belangrijk is: DORA-sancties kunnen oplopen tot 10% van de jaarlijkse omzet voor financiële instellingen en tot €5 miljoen voor kritieke ICT-aanbieders. In november 2025 hebben de Europese toezichthouders 19 ICT-dienstverleners als kritisch aangemerkt, waaronder AWS, Microsoft Azure en Google Cloud, waardoor zij onder direct EU-toezicht vallen. BaFin verwacht de eerste DORA-nalevingsbevindingen eind 2025. Instellingen waarvan de weerbaarheid afhankelijk is van providers die zij niet volledig kunnen overzien, lopen zowel het risico op sancties als het operationele risico dat DORA juist wil voorkomen.
5 Belangrijkste Inzichten
- DORA’s ICT-risicobeheerpijler vereist controle die je niet kunt uitbesteden aan een Amerikaanse provider. Financiële instellingen moeten ICT-risico’s identificeren, beschermen, detecteren, erop reageren en ervan herstellen. Wanneer de provider de encryptiesleutels beheert en onder buitenlandse toegangswetgeving valt, blijft er een restrisico over dat niet alleen via contracten kan worden beperkt.
- Incidentrapportage gaat uit van volledige zichtbaarheid op data-toegangsgebeurtenissen. DORA vereist classificatie en rapportage van grote ICT-incidenten binnen strikte termijnen. Als een Amerikaanse provider voldoet aan een overheidsverzoek zonder de bank te informeren, kan de bank niet rapporteren over wat zij niet ziet.
- Weerbaarheidstesten moeten scenario’s met buitenlandse overheidsinmenging omvatten. DORA schrijft kwetsbaarheidsanalyses, penetratietesten en scenario-gebaseerde oefeningen voor. Instellingen moeten CLOUD Act-verzoeken opnemen als testscenario voor elk kritisch platform dat door een Amerikaanse provider wordt beheerd.
- Derde partij risicobeheer vereist beoordeling van de rechtsbevoegdheid van de provider, niet alleen van beveiligingscertificeringen. DORA vereist expliciet toezicht op ICT-derden, inclusief risicoanalyses die rekening houden met de juridische blootstelling van de provider aan buitenlandse overheidsverzoeken.
- Soevereine architectuur elimineert afhankelijkheid in plaats van deze te beheren. Klantgestuurde encryptiesleutels, single-tenant Europese inzet en beleidsmatige dataresidentie verwijderen het buitenlandse toegangsrisico op architectuurniveau en voldoen zo aan alle vijf DORA-pijlers tegelijk.
DORA’s Vijf Pijlers en het Probleem van Afhankelijkheid van Amerikaanse Providers
Pijler 1: ICT-risicobeheer
DORA Artikel 6 vereist dat financiële instellingen een uitgebreid ICT-risicobeheerraamwerk opzetten voor identificatie, bescherming, detectie, reactie en herstel. Het raamwerk moet interne en externe risico’s omvatten, inclusief die van derde partijen, met governance tot op bestuursniveau.
Voor Duitse banken stelt het BaFin BAIT-raamwerk (van kracht tot eind 2026 voor overgangsinstellingen) al langer IT-risicobeheer verplicht. DORA Artikel 6(4) introduceert een aparte ICT-risicocontroletaak met onafhankelijkheidseisen die volgens BaFin lijken op, maar niet identiek zijn aan, de bestaande BAIT-informatiebeveiligingsfunctionaris.
De kernuitdaging is deze: een ICT-risicobeheerraamwerk dat “Amerikaanse overheidsdata-toegang via cloudprovider” als risico identificeert, maar dit accepteert vanwege Standaard Contractuele Clausules of het EU-VS Data Privacy Framework, bouwt weerbaarheid op juridisch drijfzand. SCC’s en het DPF zijn juridische overdrachtsmechanismen, geen technische beschermingen. Ze voorkomen een CLOUD Act-verzoek niet. DORA vereist dat financiële instellingen maatregelen nemen die ICT-risico’s daadwerkelijk beheersen, niet alleen documenteren. Is het risico architectonisch, dan moet de oplossing dat ook zijn.
Pijler 2: Incidentmanagement en rapportage
DORA verplicht gestructureerde processen voor het detecteren, classificeren en rapporteren van grote ICT-incidenten. De rapportagetijdlijn van de EBA vereist een eerste melding binnen 4 uur na classificatie, een tussentijds rapport binnen 72 uur en een eindrapport binnen een maand. Belangrijke incidenten moeten worden gemeld aan de nationale bevoegde autoriteiten.
Deze pijler gaat uit van volledige zichtbaarheid op gebeurtenissen die de data van de instelling raken. Wanneer een Amerikaanse provider een National Security Letter of FISA-bevel ontvangt om data te overhandigen, mag de provider de klant vaak wettelijk niet informeren. De financiële instelling heeft dan geen zicht op het toegangsmoment en kan het incident dus niet classificeren of rapporteren. Dit creëert een structureel gat in het incidentmanagement dat niet door procesverbetering kan worden opgelost, omdat het gat in de relatie met de provider zelf zit.
Soevereine architectuur lost dit op door ervoor te zorgen dat de provider geen toegang heeft tot ontsleutelde data, ongeacht juridische verzoeken. Wanneer de instelling de encryptiesleutels beheert in een eigen HSM, levert een overheidsverzoek aan de provider alleen ciphertext op. De audit logging van de instelling registreert alle legitieme toegang, waarmee de volledige zichtbaarheid ontstaat die DORA vereist voor incidentrapportage.
Pijler 3: Testen van digitale operationele weerbaarheid
DORA vereist regelmatige tests van operationele weerbaarheid, waaronder kwetsbaarheidsanalyses, penetratietesten en scenario-oefeningen. Kritieke entiteiten kunnen verplicht zijn tot Advanced Threat-Led Penetration Testing (TLPT) volgens het TIBER-EU-raamwerk.
Weerbaarheidstesten die scenario’s met buitenlandse overheidsinmenging uitsluiten, geven een incompleet beeld voor elke instelling die Amerikaanse cloudservices gebruikt. Een volledig testprogramma moet het scenario modelleren waarin een kritieke dataplatformprovider wordt gedwongen klantdata te overhandigen, en beoordelen of de architectuur van de instelling datalekken voorkomt, of monitoringsystemen de poging detecteren en of incidentprocedures correct worden geactiveerd.
Met klantgestuurde encryptie is de uitkomst helder: de provider kan geen leesbare data leveren. Het scenario wordt een validatie van architectonische controles in plaats van een blootstelling aan onbeheersbaar risico.
Pijler 4: Derde partij ICT-risicobeheer
DORA’s vereisten voor risicobeheer van derde partijen behoren tot de meest verstrekkende bepalingen. Financiële instellingen moeten risico’s van ICT-providers beoordelen en continu monitoren, contracten voorzien van beveiligingsbepalingen, auditrechten, beëindigingsrechten, exitstrategieën en incidentmeldingsprocedures. De Europese toezichthouders hebben in november 2025 19 aanbieders als kritieke ICT-derden aangemerkt (CTPP’s), waaronder AWS, Microsoft Azure, Google Cloud en anderen, die nu onder direct EU-toezicht vallen.
DORA Artikel 28(3) vereist dat financiële instellingen een Register of Information bijhouden met alle contractuele afspraken met ICT-derden. BaFin verplichtte Duitse instellingen hun eerste registers uiterlijk 11 april 2025 in te dienen. Dit register moet niet alleen het bestaan van de relatie vastleggen, maar ook de aard van de diensten, datalocaties en risicoclassificaties.
Voor instellingen die Amerikaanse platforms gebruiken voor gevoelige data-uitwisseling, moet de derde partij risicoanalyse eerlijk de rechtsbevoegdheid van de provider beoordelen. De EBA heeft aangegeven dat alleen vertrouwen op certificeringen als ISO 27001 onvoldoende is voor risicobeoordeling. De analyse moet ingaan op de vraag of de provider wettelijk kan worden gedwongen klantdata te overhandigen en of de architectuur van de instelling leesbare data in dat scenario voorkomt.
DORA vereist ook werkbare exitstrategieën. Financiële instellingen moeten aantonen dat zij kunnen overstappen van elke ICT-provider zonder operationele verstoring. Deze eis adresseert direct het leveranciersafhankelijkheidsrisico dat ontstaat bij concentratie van kritieke functies bij een klein aantal Amerikaanse hyperscale providers. Instellingen moeten beoordelen of hun huidige architectuur migratie ondersteunt en of alternatieve aanbieders gelijkwaardige functionaliteit kunnen leveren onder Europese rechtsbevoegdheid.
Pijler 5: Delen van cyberdreigingsinformatie
DORA moedigt financiële instellingen aan deel te nemen aan Threat Intelligence-deling. Deelname is niet verplicht, maar instellingen moeten toezichthouders informeren over hun informatie-uitwisselingsactiviteiten. Effectieve uitwisseling vereist inzicht in het eigen dreigingslandschap. Een instelling zonder zicht op mogelijke overheidsinmenging via haar cloudproviders heeft een onvolledig dreigingsmodel. Soevereine architectuur verduidelijkt het landschap door buitenlandse toegangsambiguïteit te elimineren, waardoor de instelling zich kan richten op echte externe cyberdreigingen.
Hoe Soevereine Architectuur eruitziet onder DORA
DORA-conforme operationele weerbaarheid zonder afhankelijkheid van Amerikaanse cloudproviders vereist drie architectonische capaciteiten die aansluiten bij het GTM-principe dat datasoevereiniteit een technische architectuur is, geen contractuele clausule.
Klantgestuurde encryptiesleutels
De instelling genereert en bewaart encryptiesleutels in een eigen hardware security module, op locatie of in een door de instelling beheerd Europees datacenter. Het cloudplatform verwerkt versleutelde data maar heeft nooit toegang tot de ontsleutelsleutels. Dit verschilt fundamenteel van Bring Your Own Key (BYOK)-regelingen waarbij de provider toegang houdt tot sleutelmaterialen. De test is eenvoudig: als de provider een juridisch verzoek ontvangt, kan deze dan ontsleutelde data leveren? Zo ja, voldoet het encryptiemodel niet aan de DORA-risicobeheervereisten voor kritieke functies.
Single-tenant Europese inzet
Multi-tenant platforms bedienen duizenden klanten vanaf gedeelde infrastructuur, geoptimaliseerd voor het wereldwijde bereik van de provider. Single-tenant inzet op toegewijde Europese infrastructuur bedient één klant vanaf geïsoleerde systemen, waarbij toegangscontrole wordt geregeld door Europese wetgeving. In combinatie met klantgestuurde encryptie elimineert single-tenant inzet zowel het logische toegangspad (encryptiesleutels) als het fysieke toegangspad (gedeelde infrastructuur) die afhankelijkheid van de provider creëren.
Operationele onafhankelijkheid en exitmogelijkheid
DORA vereist werkbare exitstrategieën voor alle ICT-derde partij afspraken die kritieke functies ondersteunen. Dit betekent dat financiële instellingen platforms nodig hebben die zijn gebouwd op standaardprotocollen en data-portabiliteit en operationele onafhankelijkheid ondersteunen. De architectuur moet de instelling in staat stellen om on-premises, in een Europese private cloud of in door de provider gehoste Europese infrastructuur te draaien, met de flexibiliteit om tussen opties te migreren zonder dataverlies of operationele verstoring. Dit adresseert DORA’s concentratierisico en de verwachting van BaFin dat uitbestede functies kunnen worden gerepatrieerd.
DORA-pijlerafstemming: Afhankelijkheid van Amerikaanse providers versus soevereine architectuur
| DORA-pijler | Risico bij afhankelijkheid van Amerikaanse providers | Reactie van soevereine architectuur |
|---|---|---|
| ICT-risicobeheer | Restrisico op buitenlandse toegang kan niet contractueel worden beperkt | Risico geëlimineerd op architectuurniveau; provider heeft geen toegang tot data |
| Incidentmanagement | Overheidsverzoeken kunnen zichtbaarheid en rapportage van de instelling omzeilen | Volledige audittrail; alle toegang zichtbaar voor de instelling |
| Weerbaarheidstesten | Buitenlands toegangsscenario toont onbeheersbaar risico | Buitenlands toegangsscenario valideert architectonische controles |
| Derde partij risico | Rechtsbevoegdheid provider creëert structurele afhankelijkheid | Klantgestuurde sleutels en single-tenant inzet elimineren afhankelijkheid |
| Informatie-uitwisseling | Onvolledig dreigingsmodel door ambiguïteit op providerniveau | Helder dreigingslandschap; focus op echte externe dreigingen |
Implementatie: Overstappen naar DORA-conforme soevereine architectuur
Fase 1: Breng kritieke ICT-afhankelijkheden in kaart
Gebruik het DORA Register of Information als uitgangspunt. Identificeer elke ICT-derde partij die kritieke of belangrijke functies ondersteunt en beoordeel de rechtsbevoegdheid, het encryptiemodel en de sleutelbeheerarchitectuur van elke provider. Documenteer voor elke Amerikaanse dienst of de provider onder welke omstandigheden toegang heeft tot ontsleutelde klantdata, inclusief juridische dwang. Deze beoordeling vloeit direct in het ICT-risicobeheerraamwerk en voldoet aan de verwachting van BaFin voor eerlijke risicoanalyse.
Fase 2: Prioriteer op basis van regelgevingsrisico
Niet alle ICT-diensten brengen evenveel DORA-risico met zich mee. Geef prioriteit aan diensten die de meest gevoelige data verwerken: klantfinanciële gegevens, beheerde bestandsoverdracht voor toezichthoudende rapportages, interne auditcommunicatie, grensoverschrijdende transactiegegevens en bestuurscorrespondentie. Dit zijn de functies waarbij een buitenlands data-toegangsevenement het grootste regelgevende, reputatie- en operationele risico oplevert.
Fase 3: Implementeer soevereine architectuur
Migreer prioritaire functies naar platforms met klantgestuurde encryptie, single-tenant Europese inzet en beleidsmatige dataresidentie met geofencing. Valideer via onafhankelijke tests dat de provider geen toegang heeft tot ontsleutelde data. Stel uitgebreide audit logging in ter ondersteuning van DORA’s incidentrapportagetijdlijnen en monitoringverplichtingen. Stel incidentresponsprocedures op die rekening houden met de mogelijkheden van de nieuwe architectuur.
Fase 4: Toon naleving aan met bewijs
DORA-naleving wordt aangetoond met bewijs, niet met beweringen. Bewaar documentatie van de generatie van encryptiesleutels in de HSM van de instelling, single-tenant inzetconfiguratie, geofencing-handhaving en volledige audittrails. Bereid dit bewijspakket voor op BaFin-inspecties, ECB-toezichtsbeoordelingen en de periodieke weerbaarheidstesten die DORA vereist. Soevereiniteit die je kunt aantonen, is soevereiniteit die beschermt.
Operationele weerbaarheid vereist operationele soevereiniteit
DORA’s vijf pijlers beschrijven hoe operationele weerbaarheid eruitziet. Maar weerbaarheid kan niet bestaan waar geen controle is. Wanneer de kritieke dataplatforms van een financiële instelling worden beheerd door aanbieders die onder buitenlandse overheidswetgeving vallen, bevat het weerbaarheidsraamwerk van de instelling een structureel gat dat geen enkele contractuele bepaling, certificering of procesverbetering kan dichten.
Soevereine architectuur, gebaseerd op klantgestuurde encryptie, single-tenant Europese inzet en echte operationele onafhankelijkheid, sluit dat gat door de afhankelijkheid te elimineren in plaats van te beheren. Europese financiële instellingen die deze architectuur implementeren, voldoen niet alleen aan DORA. Zij bouwen de zero trust weerbaarheidsinfrastructuur waar Europese toezichthouders op aansturen.
Kiteworks helpt Europese financiële instellingen DORA-conforme operationele weerbaarheid te bereiken
Het Kiteworks Private Data Network levert een soevereine architectuur die speciaal is ontworpen voor het vijfpijlerkader van DORA. Kiteworks werkt met een klantgestuurd encryptiemodel waarbij de instelling de encryptiesleutels genereert en bewaart in de eigen HSM. Kiteworks heeft geen toegang tot ontsleutelde inhoud en kan niet voldoen aan buitenlandse overheidsverzoeken om leesbare data te leveren, omdat het de sleutels niet bezit.
Kiteworks wordt ingezet als single-tenant instance op toegewijde Europese infrastructuur, waaronder on-premises, private cloud en hardened virtual appliance-opties, waardoor instellingen de inzetflexibiliteit en exitmogelijkheid krijgen die DORA vereist. Ingebouwde geofencing handhaaft dataresidentie op platformniveau. Uitgebreide audit logging ondersteunt de incidentrapportagetijdlijnen van DORA en levert het continue monitoringsbewijs dat toezichthouders verwachten. Kiteworks ondersteunt DORA-naleving over alle vijf pijlers via een geïntegreerde aanpak van ICT-risicobeheer voor gevoelige content.
Het platform verenigt beveiligde bestandsoverdracht, e-mailbescherming, beheerde bestandsoverdracht en webformulieren onder één governance-framework, waardoor financiële instellingen de derde partij risicovereisten van DORA over alle data-uitwisselingskanalen kunnen adresseren met één architectuur, één set controles en één toezichts-bewijspakket.
Wil je meer weten over het bereiken van DORA-conforme operationele weerbaarheid zonder afhankelijkheid van Amerikaanse cloudproviders? Plan vandaag nog een persoonlijke demo.
Veelgestelde vragen
Nee. DORA verbiedt het gebruik van Amerikaanse ICT-aanbieders niet, maar vereist wel dat instellingen de risico’s van deze relaties beheersen. De verordening schrijft een grondige risicoanalyse voor, contractuele beheersmaatregelen inclusief exitstrategieën en continue monitoring voor alle ICT-derde partij afspraken. Voor Amerikaanse diensten die kritieke functies ondersteunen, moet de risicoanalyse de blootstelling aan CLOUD Act en FISA 702 beoordelen. Instellingen kunnen Amerikaanse providers blijven gebruiken als zij architectonische controles implementeren, zoals klantgestuurde encryptiesleutels, die het vermogen van de provider om toegang te krijgen tot ontsleutelde data elimineren en zo het buitenlandse toegangsrisico op technisch niveau neutraliseren.
Financiële instellingen riskeren boetes tot 10% van de jaarlijkse omzet of €10 miljoen bij ernstige overtredingen, terwijl individuele bestuurders tot €1 miljoen boete kunnen krijgen. DORA-sancties gelden vanaf de ingangsdatum van 17 januari 2025 zonder overgangsperiode. Bevoegde autoriteiten kunnen inspecties uitvoeren, eisen dat niet-conforme praktijken worden gestaakt en openbare verklaringen publiceren waarin de niet-conforme entiteit wordt genoemd. Naast financiële sancties lopen instellingen reputatieschade en mogelijk verlies van klantvertrouwen op. BaFin heeft aangegeven het toezicht op uitbesteding in 2025 te intensiveren en verwacht de eerste nalevingsbevindingen eind 2025, waardoor snelle implementatie van soevereine architectuur prioriteit krijgt.
De ESA-aanwijzing van 19 kritieke aanbieders in november 2025 brengt hen onder direct EU-toezicht, maar vermindert de eigen nalevingsverplichtingen van banken niet. Banken moeten nog steeds onafhankelijke risicoanalyses uitvoeren, contractuele beheersmaatregelen nemen en exitstrategieën implementeren voor deze providers. De aanwijzing betekent dat toezichthouders nu zowel het risicobeheer van de bank als de operaties van de provider beoordelen. Banken moeten dit zien als verscherpt toezicht op hun derde partij risicobeheer, niet als een goedkeuring van deze providers. Implementatie van klantgestuurde encryptie en single-tenant inzet toont aan dat de bank de specifieke risico’s van deze aanbieders adresseert.
Duitse banken moeten zich richten op drie prioriteiten: het afronden van het DORA Register of Information, contractuele naleving van ICT-afspraken en het documenteren van architectonische risicobeperkingen. BaFin eiste de eerste registerinzendingen uiterlijk 11 april 2025 en heeft aangegeven dat contractaanpassingen voor ICT-derde partijen direct prioriteit hebben. BaFin verwacht een risicogebaseerde tijdlijn voor naleving waarbij instellingen voortgang aantonen. Banken moeten hun encryptiesleutelbeheerarchitectuur, dataresidentiecontroles en gegevensbeheerframeworks documenteren als bewijs van echt risicobeheer. Voor instellingen die overstappen van BAIT naar DORA biedt het gap-analyse document van BaFin een praktisch vergelijk van bestaande en nieuwe ICT-risicobeheervereisten.
Soevereine cloudaanbiedingen pakken sommige afhankelijkheidsrisico’s aan, maar zijn vaak gebaseerd op samenwerking met Amerikaanse hyperscale providers, waardoor Amerikaanse technologieafhankelijkheden in de onderliggende infrastructuur kunnen blijven bestaan. DORA vereist dat instellingen de volledige toeleveringsketen beoordelen, inclusief sub-outsourcing. Een soevereine cloud gebaseerd op Microsoft Azure-technologie kan nog steeds Amerikaanse code-afhankelijkheden en operationele raakvlakken bevatten. Instellingen moeten beoordelen of het soevereine aanbod echte onafhankelijkheid, klantgestuurde encryptiesleutels en volledige operationele controle biedt, of dat soevereiniteit gepaard gaat met minder functionaliteit en hogere kosten. De kernvraag blijft of een partij in de keten toegang kan krijgen tot ontsleutelde data onder buitenlandse juridische dwang, ongeacht de branding van de dienst. Instellingen die alternatieven evalueren, moeten dezelfde zero trust gegevensuitwisselingscriteria toepassen op soevereine cloudoplossingen als op elke andere provider.
Aanvullende bronnen
- Blog Post
Datasoevereiniteit: een best practice of wettelijke vereiste? - eBook
Datasoevereiniteit en GDPR - Blog Post
Voorkom deze valkuilen rond datasoevereiniteit - Blog Post
Datasoevereiniteit beste practices - Blog Post
Datasoevereiniteit en GDPR [Inzicht in databeveiliging]