Governance van cloudregio’s voor GDPR, NIS2 en DORA

Om 08:17 op een dinsdagochtend ontvangt Maria, de CISO van een snelgroeiende Europese fintech, het bericht waar iedere gereguleerde cloudklant uiteindelijk voor vreest.

Het inkoopteam stuurt een korte leveranciersmelding door:

“Onze provider voor cloudanalytics verplaatst EU-klanttelemetrie om prestatieredenen naar een nieuwe regio. De provider stelt dat er geen beveiligingsimpact is. Kunnen we dit goedkeuren?”

Voordat Maria kan reageren, komt er een tweede melding binnen van de primaire cloudserviceprovider (CSP). Over 90 dagen zal de provider zijn “global support model” optimaliseren door Tier 2-supporttickets via een nieuwe subverwerker te routeren. Een snelle beoordeling laat zien dat de subverwerker is gevestigd in een land zonder GDPR-adequaatheidsbesluit.

Om 09:00 hebben juridische zaken, privacy, weerbaarheid, inkoop, cloud engineering en compliance voor financiële regelgeving zich in de thread gevoegd. De functionaris voor gegevensbescherming (DPO) vraagt of een Transfer Impact Assessment nodig is. De weerbaarheidsmanager vraagt of de nieuwe regio gevolgen heeft voor het herstelplan van een kritieke dienst. De verantwoordelijke voor compliance met financiële regelgeving vraagt of de provider voorkomt in het DORA-register voor ICT-derden. Het cloudteam controleert het productiegegevensvlak en ziet dat het probleem breder is dan analytics. Back-ups, operationele logbestanden, supporttickets, data-lake-exporten, break-glass-toegang en toegang door onderaannemers kunnen allemaal binnen de reikwijdte vallen.

Dit is het echte governanceprobleem in de cloud in 2026.

De meeste organisaties hebben een cloudbeleid. Veel organisaties hebben een leveranciersregister. Sommige hebben een GDPR-doorgiftebeoordeling. Minder organisaties kunnen de lastigere auditvraag met bewijsmateriaal beantwoorden:

Waar bevinden gereguleerde gegevens en kritieke ICT-verwerking zich exact, wie kan er vanaf waar bij, wat gebeurt er tijdens failover en welke contractuele beheersmaatregel voorkomt dat de provider dit antwoord zonder goedkeuring wijzigt?

Dat is governance van cloudregio’s. Het is geen afzonderlijk juridisch afvinkpunt. Het is een levend stelsel van beheersmaatregelen over ISO/IEC 27001:2022, cloud- en leveranciersbeheersmaatregelen uit ISO/IEC 27002:2022, GDPR-verantwoordingsplicht, NIS2-dienstweerbaarheid en DORA-toezicht op ICT-derden.

Gegevensresidentie is nu een operationele beheersmaatregel

Jarenlang werd “EU-only hosting” behandeld als een clausule in een verwerkersovereenkomst. Dat is niet langer voldoende. Een modern programma voor gegevensresidentie in de cloud en governance van cloudregio’s moet ten minste zes operationele lagen omvatten:

1. Primaire productie-regio’s voor opslag en compute.
2. Regio’s voor back-up, archivering en herstel na verstoringen.
3. Locaties voor logging, monitoring, SIEM en observability-data.
4. Supporttoegang, inclusief beheer op afstand en break-glass-toegang.
5. Subverwerkers en onderaannemers, inclusief managed services en marketplacecomponenten.
6. Gegevensdoorgiftepaden tussen omgevingen, API’s, analyticsplatforms en tools voor klantsupport.

GDPR maakt dit onvermijdelijk omdat persoonsgegevens ook online identificatoren, IP-adressen, klantaccount-ID’s, gebruikersregistraties, apparaatidentificatoren, operationele metadata en supportregistraties kunnen omvatten. Verwerking is eveneens breed gedefinieerd en omvat opslag, toegang, gebruik, openbaarmaking, wissing en vernietiging. “Wij sturen alleen logbestanden” is geen veilige uitzondering als die logbestanden identificatoren bevatten.

GDPR Artikel 5 omvat ook het beginsel van verantwoordingsplicht. Verwerkingsverantwoordelijken moeten niet alleen voldoen aan de beginselen van rechtmatigheid, behoorlijkheid, transparantie, doelbinding, gegevensminimalisatie, opslagbeperking, integriteit en vertrouwelijkheid. Zij moeten naleving ook kunnen aantonen. Governance van cloudregio’s is een van de manieren waarop die aantoonbaarheid concreet wordt.

NIS2 verschuift het vraagstuk van privacy naar weerbaarheid. Op grond van Artikel 21 moeten essentiële en belangrijke entiteiten passende technische, operationele en organisatorische maatregelen implementeren om risico’s voor netwerk- en informatiesystemen te beheren die worden gebruikt voor bedrijfsvoering of dienstverlening. De genoemde maatregelen omvatten beveiliging van de toeleveringsketen, bedrijfscontinuïteit, back-upbeheer, herstel na verstoringen, crisismanagement, toegangscontrole, beheer van bedrijfsmiddelen, encryptie en beoordeling van de doeltreffendheid. Als een besluit over een cloudregio de beschikbaarheid of het herstel van een dienst binnen de reikwijdte beïnvloedt, is dit niet alleen een kwestie van gegevensbescherming. Het is een weerbaarheidskwestie.

Voor financiële entiteiten verhoogt DORA de lat verder. DORA is van toepassing vanaf 17 januari 2025 en stelt eisen aan ICT-risicobeheer, incidentrapportage, het testen van digitale operationele weerbaarheid, ICT-risicobeheer voor derde partijen en contractuele regelingen. Artikel 28 vereist dat financiële entiteiten ICT-risico’s van derde partijen beheren als integraal onderdeel van het ICT-risicobeheerkader, registers van contractuele regelingen bijhouden, concentratierisico beoordelen en exitplannen opstellen voor kritieke of belangrijke functies. Artikel 30 vereist contractuele duidelijkheid over locaties voor dienstverlening en gegevensverwerking, auditrechten en toegangsrechten, ondersteuning bij incidenten, onderaanneming, herstel, teruggave en exittransitie.

DORA fungeert als sectorspecifiek regime voor financiële entiteiten, terwijl NIS2 relevant blijft voor de bredere toeleveringsketen, vooral voor aanbieders van cloudcomputingdiensten, datacenterproviders en managedserviceproviders (MSP’s). Eén niet-beoordeelde subverwerker kan daardoor een domino-effect veroorzaken over financiële weerbaarheid, beveiliging van de toeleveringsketen en privacyverplichtingen.

Eenvoudig gezegd: als een gereguleerde organisatie niet kan beheersen waar haar cloudverwerking plaatsvindt, kan zij ICT-risico’s van derde partijen niet geloofwaardig beheersen.

Gebruik ISO 27001 als anker voor het managementsysteem

ISO/IEC 27001:2022 biedt de structuur om verwarring over residentie om te zetten in een beheerst managementsysteem.

Clausules 4.1 tot en met 4.4 vereisen dat de organisatie het ISMS in zijn context definieert, inclusief interne en externe kwesties, eisen van belanghebbenden, wettelijke, regelgevende en contractuele verplichtingen, interfaces en afhankelijkheden met andere organisaties. Voor governance van cloudregio’s moet het ISMS-toepassingsgebied expliciet clouddiensten, uitbestede ICT-verwerking, afhankelijkheden van kritieke diensten en gereguleerde gegevensstromen omvatten.

Clausules 5.1 tot en met 5.3 maken leiderschap verantwoordelijk. Het topmanagement moet het informatiebeveiligingsbeleid en de doelstellingen afstemmen op de strategische richting, middelen beschikbaar stellen, verantwoordelijkheden toewijzen en ervoor zorgen dat over ISMS-prestaties wordt gerapporteerd. Hier wordt cloudresidentie een management- en governanceonderwerp, vooral voor NIS2-entiteiten waar bestuursorganen risicobeheersmaatregelen voor cyberbeveiliging moeten goedkeuren en daarop toezicht moeten houden, en voor financiële entiteiten onder DORA waar het bestuursorgaan verantwoordelijk is voor ICT-risicogovernance.

Clausules 6.1.1 tot en met 6.1.3 leveren de risicomotor. De organisatie heeft een herhaalbaar risicobeoordelingsproces nodig, risico-eigenaren, criteria voor impact en waarschijnlijkheid, behandelopties, geselecteerde beheersmaatregelen, een Verklaring van toepasselijkheid en acceptatie van restrisico. Een wijziging van cloudregio mag niet via een informele e-mail worden goedgekeurd. Deze moet een risicobeoordeling of wijzigingsbeoordeling activeren wanneer gereguleerde gegevens, kritieke functies, leveranciers of continuïteitsaannames worden geraakt.

Clausule 8.1 zet planning om in operationele beheersing. Processen moeten worden geïmplementeerd, beheerst, gedocumenteerd en gecontroleerd gewijzigd, en worden uitgebreid naar extern geleverde producten en diensten die relevant zijn voor het ISMS. Clausules 8.2 en 8.3 vereisen herbeoordeling en behandeling op geplande intervallen of wanneer significante wijzigingen plaatsvinden. Migratie naar een andere cloudregio, back-upreplicatie, een nieuw loggingplatform of een wijziging van supportsubverwerker zijn allemaal kandidaten voor herbeoordeling.

De set beheersmaatregelen van ISO/IEC 27002:2022 biedt vervolgens de praktische familie van beheersmaatregelen. De meest relevante beheersmaatregelen zijn:

• 5.9 Inventaris van informatie en andere gerelateerde bedrijfsmiddelen.
• 5.14 Informatieoverdracht.
• 5.15 Toegangscontrole.
• 5.19 Informatiebeveiliging in leveranciersrelaties.
• 5.20 Informatiebeveiliging opnemen in leveranciersovereenkomsten.
• 5.22 Monitoring, beoordeling en wijzigingsbeheer van leveranciersdiensten.
• 5.23 Informatiebeveiliging voor het gebruik van clouddiensten.
• 5.29 Informatiebeveiliging tijdens verstoring.
• 5.30 ICT-gereedheid voor bedrijfscontinuïteit.
• 5.31 Wettelijke, statutaire, regelgevende en contractuele eisen.
• 5.34 Privacy en bescherming van persoonlijk identificeerbare informatie (PII).
• 5.36 Naleving van beleid, regels en normen voor informatiebeveiliging.
• 8.11 Datamaskering.
• 8.12 Preventie van gegevenslekken.
• 8.13 Informatieback-up.
• 8.15 Logging.
• 8.16 Monitoringactiviteiten.
• 8.20 Netwerkbeveiliging.
• 8.24 Gebruik van cryptografie.
• 8.25 Veilige ontwikkelingslevenscyclus.
• 8.27 Veilige systeemarchitectuur en engineeringprincipes.
• 8.32 Wijzigingsbeheer.

Clarysec’s Zenith Controls: The Cross-Compliance Guide Zenith Controls behandelt ISO/IEC 27002:2022-beheersmaatregel 5.23, Informatiebeveiliging voor het gebruik van clouddiensten, als een preventieve beheersmaatregel ter ondersteuning van vertrouwelijkheid, integriteit en beschikbaarheid, met operationele capaciteit in beveiliging van leveranciersrelaties en beveiligingsdomeinen voor governance, ecosysteem en bescherming. De gids koppelt 5.23 aan 5.19 leveranciersrelaties, 5.14 informatieoverdracht, 5.9 inventaris van bedrijfsmiddelen, 8.11 en 8.12 datamaskering en preventie van gegevenslekken, 8.20 netwerkbeveiliging en 8.25 veilige ontwikkelingslevenscyclus.

Een belangrijke observatie uit Zenith Controls is:

“Cloudserviceproviders (CSP’s) functioneren als kritieke leveranciers, waardoor alle beheersmaatregelen voor leveranciersselectie, contractering en risicobeheer onder 5.19 van toepassing zijn. 5.23 gaat echter verder door cloudspecifieke risico’s te adresseren, zoals multitenancy, transparantie over gegevenslocatie en modellen voor gedeelde verantwoordelijkheid.”

Die zin vat de governanceverschuiving samen. Een cloudprovider is niet zomaar een leverancier. Het is vaak de plaats waar gereguleerde verwerking plaatsvindt.

De verborgen residentievalkuilen: back-ups, logbestanden, support en subverwerkers

De meeste fouten rond gegevensresidentie beginnen niet bij de productiedatabase. Ze beginnen bij ondersteunende systemen die nooit correct zijn meegenomen in de beoordeling van gegevensstromen.

Back-ups zijn het klassieke voorbeeld. Een SaaS-platform kan in Frankfurt of Dublin draaien, terwijl automatische back-ups elders worden gerepliceerd om redenen van weerbaarheid of kosten. Als de back-up persoonsgegevens, klantregistraties, authenticatielogbestanden of gereguleerde transactiehistorie bevat, doet de back-upregio ertoe. Onder NIS2 Artikel 21 maken back-upbeheer en herstel na verstoringen deel uit van de beveiligingsbaseline. Onder DORA vereisen continuïteit van kritieke of belangrijke functies en geteste exitstrategieën kennis van herstellocaties en herstelafhankelijkheden.

Logbestanden vormen een ander zwak punt. Beveiligingsteams centraliseren telemetrie in SIEM-, observability- en data-lake-diensten. Die logbestanden kunnen IP-adressen, gebruikersidentificatoren, beheerdershandelingen, betaalmetadata, mislukte authenticatiepogingen, klantaccount-ID’s of supporttracegegevens bevatten. Als logbestanden naar een wereldwijde monitoringdienst gaan, kan de organisatie onbewust een grensoverschrijdende doorgifte hebben gecreëerd.

Clarysec’s Logging and Monitoring Policy-sme Logging and Monitoring Policy - SME adresseert leveranciersbewijsmateriaal rechtstreeks:

“Contracten moeten providers verplichten logbestanden ten minste 12 maanden te bewaren en op verzoek toegang te verlenen”

Dit citaat komt uit de sectie “Governancevereisten”, beleidsclausule 5.5.1.3. Voor governance van gegevensresidentie moet dezelfde contractbeoordeling bevestigen waar die logbestanden worden bewaard, wie er toegang toe heeft en of logbewijsmateriaal beschikbaar is tijdens een incidentonderzoek of verzoek van een toezichthouder.

Supporttoegang is subtieler. Een provider kan gegevens in de EU hosten, terwijl support engineers buiten de EU toegang hebben tot klantomgevingen, database-snapshots, diagnosepakketten of ticketbijlagen. Of dit aanvaardbaar is, hangt af van de betrokken gegevens, het doorgiftemechanisme, de rol, contractuele waarborgen, toegangscontrole en logging. De architectuur kan regionaal zijn, terwijl het menselijke toegangsmodel wereldwijd is.

Subverwerkers vormen de laatste blinde vlek. Uw directe leverancier kan afhankelijk zijn van cloudinfrastructuur, content delivery networks, beheerde databanken, ticketingplatforms, analyticsdiensten, offshore supportteams of beveiligingsleveranciers. DORA Artikel 29 vereist beoordeling van onderaannemingsrisico’s, providers uit derde landen, beperkingen bij gegevensherstel, naleving van gegevensbescherming en complexe ketens van onderaanneming. NIS2 Artikel 21 vereist dat entiteiten rekening houden met de cyberbeveiligingspraktijken van directe leveranciers en dienstverleners. GDPR vereist dat verwerkers subverwerkers zodanig beheren dat het vermogen van de verwerkingsverantwoordelijke om te voldoen behouden blijft.

Clarysec’s Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME maakt dit praktisch:

“Wanneer leveranciers verplicht zijn gegevens buiten de bedrijfslocatie op te slaan, moet de organisatie zekerheid verkrijgen over gegevensbescherming, fysieke beveiliging en de geografische opslaglocatie (bijvoorbeeld EU-only hosting waar GDPR dit vereist).”

Dit komt uit de sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.2.4. Hetzelfde beleid vereist ook:

“Beperkingen op verdere onderaanneming zonder goedkeuring”

Dit citaat komt uit de sectie “Governancevereisten”, beleidsclausule 5.3.5. Samen zetten deze clausules residentie om in een workflow voor leveranciersmanagement, niet in een inkoopvoorkeur.

Zet beleid om in afdwingbare governance van cloudregio’s

Governance van cloudregio’s moet afdwingbaar, beoordeelbaar en auditeerbaar zijn.

Voor mkb-organisaties zet de Cloud Usage Policy-sme Cloud Usage Policy - SME de baseline:

“Gegevensresidentie en privacypraktijken moeten voldoen aan toepasselijke wettelijke eisen (bijvoorbeeld GDPR)”

Dit komt uit de sectie “Governancevereisten”, beleidsclausule 5.2.3. Hetzelfde beleid vereist dat registraties voor cloudgovernance het volgende bevatten:

“Het land of de regio waar gegevens worden opgeslagen”

Dit citaat komt uit de sectie “Governancevereisten”, beleidsclausule 5.3.4.

Voor grotere organisaties is de Cloud Usage Policy Cloud Usage Policy explicieter over contractuele afdwinging:

“Eisen voor gegevensresidentie moeten contractueel worden afgedwongen (bijvoorbeeld EU-only opslag voor gegevens waarop GDPR van toepassing is).”

Dit komt uit de sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.6.2. Het beleid stelt ook:

“Grensoverschrijdende gegevensdoorgiften moeten voldoen aan GDPR Hoofdstuk V en, waar van toepassing, DORA Artikel 28.”

Dit komt uit de sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.6.3.

De enterpriseversie vraagt ook aandacht voor:

“Waarborgen voor gegevensresidentie en gegevenseigenaarschap”

Dit citaat komt uit de sectie “Rollen en verantwoordelijkheden”, beleidsclausule 4.5.1.2.

De Third party and supplier security policy Third party and supplier security policy voegt de contractlaag toe door te eisen:

“Vereisten voor gegevensverwerking, inclusief opslaglocatie, toegangscontrole en clausules voor teruggave of vernietiging”

Dit citaat komt uit de sectie “Governancevereisten”, beleidsclausule 5.3.2.

Tot slot identificeert de Legal and Regulatory Compliance Policy Legal and Regulatory Compliance Policy wijzigingen die een nalevingsbeoordeling moeten activeren, waaronder:

“Wijzigingen in gegevensdoorgiftemechanismen, subverwerkers of grensoverschrijdende gegevensstromen”

Dit komt uit de sectie “Governancevereisten”, beleidsclausule 5.3.1.1.

Deze documenten mogen niet als afzonderlijke bestanden functioneren. In een volwassen ISMS vormen ze één operationeel model: cloudinventaris, register van gegevensstromen, leveranciersregister, contractmatrix, risicobeoordeling, doorgiftebeoordeling, wijzigingsgoedkeuring en auditbewijspakket.

Bouw een register voor governance van cloudregio’s

Een praktisch register zet cloudresidentie om van aanname naar bewijsmateriaal. Begin met één kritieke klantgerichte dienst, vooral een dienst die waarschijnlijk binnen de reikwijdte valt van NIS2, due diligence onder DORA door klanten of GDPR-toetsing.

Verbind het register vervolgens met de implementatie.

In Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint richt de fase Beheersmaatregelen in de praktijk, stap 23, zich op organisatorische beheersmaatregelen 5.19 tot en met 5.37, inclusief leveranciersovereenkomsten en governance van clouddiensten. De Blueprint waarschuwt dat leveranciersovereenkomsten meer moeten dekken dan generieke vertrouwelijkheid:

“In veel sectoren definiëren leveranciersovereenkomsten ook gegevenseigenaarschap en jurisdictie. Waar worden gegevens verwerkt? Wie behoudt zeggenschap? Zijn er beperkingen op doorgifte? Zijn er cloudspecifieke beheersmaatregelen (zoals gegevenssegmentatie, sleuteleigenaarschap of geografische beperkingen)? Deze elementen zijn niet alleen juridisch; het zijn operationele beveiligingskwesties, vooral in gereguleerde sectoren.”

Dezelfde fase en stap behandelen wijzigingsbeheer bij leveranciers:

“De meeste leveranciersrelaties beginnen met goede bedoelingen. Een grondige beoordeling, duidelijke verwachtingen, ondertekende overeenkomsten (zie 5.20), misschien zelfs een beveiligingschecklist. Maar wat gebeurt er een jaar later, wanneer de leverancier voorstelt uw gegevens naar een nieuwe cloudregio te verplaatsen?”

Dat is Maria’s dinsdagochtendprobleem. Het register geeft de CISO een manier om te antwoorden voordat de verplaatsing wordt goedgekeurd.

De Zenith Blueprint verduidelijkt ook de governancebetekenis van cloudbeheersmaatregel 5.23:

“Een verkeerd geconfigureerde opslagbucket, een publiek toegankelijk dashboard of buitensporige machtigingen in een cloud-IAM-configuratie: dit zijn geen cloudstoringen. Het zijn governancefouten.”

In de fase Beheersmaatregelen in de praktijk, stap 22, behandelt de Blueprint informatieoverdracht en stelt:

“Als persoonsgegevens grensoverschrijdend worden doorgegeven, moet de methode voldoen aan privacy- en wettelijke verplichtingen, niet alleen aan interne voorkeuren.”

Die regel is belangrijk voor cloudteams. Encryptie, veilige API’s en private connectiviteit zijn noodzakelijk, maar vervangen juridische en regelgevende governance van doorgifte niet.

Voer de eerste bewijsworkshop van 90 minuten uit

Begin niet met het in kaart brengen van de hele organisatie. Start met één kritieke dienst en voer een gerichte workshop uit met cloud engineering, inkoop, juridische zaken, privacy, weerbaarheid en Security Operations.

Maak eerst een lijst van elk cloud- of leverancierscomponent dat de dienst opslaat, verwerkt, verzendt, back-upt, monitort of ondersteunt. Neem ook kleinere systemen mee, zoals uptime monitoring, ticketbijlagen, foutregistratie, tools voor schermdeling met support en diagnose-exporten.

Markeer vervolgens elke gegevenscategorie. Als het team zegt “alleen metadata”, toets die aanname. Metadata kunnen nog steeds persoonsgegevens of vertrouwelijke klantgegevens zijn.

Verifieer daarna de regio op basis van bewijsmateriaal. Gebruik cloudconsoleconfiguratie, back-upbeleid, SIEM-tenancy-instellingen, bijlagen bij de verwerkersovereenkomst, subverwerkerslijsten, contractuele voorwaarden, documentatie over supporttoegang en CSP-auditrapportages. Vertrouw niet alleen op verkooptoezeggingen.

Leg vervolgens hiaten vast in het ISMS-risicoregister. Voorbeelden zijn: “back-upreplicatieregio niet contractueel beperkt”, “supporttoegang vanuit derde land mist gedocumenteerde goedkeuringsworkflow”, “SIEM-logbestanden wereldwijd bewaard”, “subverwerkerslijst identificeert hostingregio niet” of “DORA-register maakt geen onderscheid naar afhankelijkheid van kritieke of belangrijke functies”.

Bepaal daarna de behandeling. Behandelingen kunnen bestaan uit contractwijziging, regiolock, klantmelding, encryptie met door de klant beheerde sleutels, tokenisatie, logminimalisatie, goedkeuring van een nieuwe leverancier, actualisering van de exitstrategie of acceptatie van restrisico door de risico-eigenaar.

Bewaar ten slotte het bewijsmateriaal. Auditors vragen niet alleen wat u hebt besloten. Zij vragen hoe u weet dat het is geïmplementeerd.

Koppel één bewijzenset aan ISO, GDPR, NIS2, DORA en NIST CSF 2.0

Een sterk programma voor governance van cloudregio’s voorkomt dubbel nalevingswerk. Hetzelfde bewijsmateriaal kan meerdere verplichtingen ondersteunen als het correct is gestructureerd.

NIST CSF 2.0 is nuttig als integrerende laag. De GOVERN-functie sluit aan op wettelijke, regelgevende, contractuele en privacyverplichtingen, risicobereidheid, verantwoordingsplicht, beleid en toezicht. De GV.SC-categorie voor de toeleveringsketen sluit goed aan op DORA-verwachtingen voor ICT-derden, NIS2-eisen voor de toeleveringsketen en ISO-leveranciersbeheersmaatregelen.

COBIT 2019 en een ISACA-auditperspectief toetsen vaak dezelfde feiten via governancedoelstellingen: eigenaarschap, beslissingsrechten, risico-optimalisatie, leveranciersprestaties, realisatie van voordelen en assurance. Een beoordelaar met een COBIT-benadering begint mogelijk niet met “welke cloudregio is geconfigureerd?” maar met “wie heeft de bevoegdheid om een regiowijziging goed te keuren, hoe wordt risico geëscaleerd en hoe weet het management dat cloudleveranciers binnen de tolerantie blijven?”

Daarom legt het Clarysec-model eigenaren, goedkeuringspunten, contractueel bewijsmateriaal en managementrapportage vast, niet alleen technische instellingen.

Bereid u voor op de vragen van de auditor

Governance van cloudregio’s is een perfect voorbeeld van hoe verschillende auditors vanuit verschillende invalshoeken naar dezelfde beheersmaatregel kijken.

Een ISO/IEC 27001:2022-auditor begint met toepassingsgebied, eisen van belanghebbenden, risicobeoordeling en de Verklaring van toepasselijkheid. Hij of zij vraagt of wettelijke, regelgevende en contractuele eisen zijn geïdentificeerd, of cloud- en leveranciersbeheersmaatregelen zijn opgenomen, of risico’s zijn beoordeeld, of beheersmaatregelen zijn geïmplementeerd en of bewijsmateriaal wordt bewaard. De auditor kan één clouddienst selecteren en vragen om onboardingbeoordeling, contractuele clausules, regioconfiguratie, monitoringbeoordeling en wijzigingsgoedkeuring.

Een gegevensbeschermingsautoriteit of GDPR-beoordelaar richt zich op persoonsgegevens. Deze vraagt welke persoonsgegevens worden verwerkt, waar ze worden opgeslagen, vanaf waar er toegang toe is, welke verwerkers en subverwerkers betrokken zijn, of doorgiftemechanismen zijn gedocumenteerd, of een Transfer Impact Assessment nodig is en of passende technische en organisatorische maatregelen zijn getroffen. Logbestanden, supportgegevens en back-ups krijgen vaak aandacht omdat organisaties deze onderschatten.

Een NIS2-auditor of bevoegde autoriteit richt zich op diensten binnen de reikwijdte. Deze kijkt naar managementverantwoordelijkheid onder Artikel 20, risicobeheersmaatregelen onder Artikel 21, continuïteit, back-upbeheer, herstel na verstoringen, incidentafhandeling, beveiliging van de toeleveringsketen, toegangscontrole, beheer van bedrijfsmiddelen en beoordeling van doeltreffendheid.

Een DORA-toezichthouder of intern auditteam zoekt naar ICT-risicogovernance, toezicht door het bestuursorgaan, het informatieregister voor ICT-regelingen met derde partijen, mapping van kritieke of belangrijke functies, concentratierisico, onderaannemingsrisico, locaties voor gegevensverwerking, auditrechten, ondersteuning bij incidentrapportage, continuïteitstesten en exitplannen. DORA is duidelijk: uitbesteding draagt de verantwoordingsplicht niet over.

Zenith Controls helpt beveiligingsleiders zich voor te bereiden op deze auditstijlen doordat het relaties tussen beheersmaatregelen kruislings verwijst. Voor ISO/IEC 27002:2022-beheersmaatregel 5.20, Informatiebeveiliging opnemen in leveranciersovereenkomsten, koppelt Zenith Controls deze aan 5.19 leveranciersrelaties, 5.14 informatieoverdracht, 5.22 leveranciersmonitoring, 5.11 teruggave van bedrijfsmiddelen en 5.36 naleving van beleid, regels en normen. Voor beheersmaatregel 5.22, Monitoring, beoordeling en wijzigingsbeheer van leveranciersdiensten, koppelt het doorlopend leverancierstoezicht aan 5.29 beveiliging tijdens verstoring, 8.8 beheer van technische kwetsbaarheden, 5.15 toegangscontrole, 8.27 veilige systeemarchitectuur en engineeringprincipes en 5.36 naleving.

Dat integrale beeld van beheersmaatregelen is belangrijk omdat een regiowijziging nooit alleen een regiowijziging is. Zij kan leveranciersrisico, doorgifterisico, toegangsrisico, continuïteitsrisico, bewijsmateriaal voor incidentrespons en contractuele naleving wijzigen.

Gebruik deze CISO-checklist voor 2026 voordat u een cloudwijziging goedkeurt

Gebruik deze checklist voordat u een nieuwe cloudregio, grensoverschrijdend verwerkingspad, back-uplocatie, loggingplatform, supportmodel of kritieke wijziging van ICT-leverancier goedkeurt.

Als het antwoord op een vraag “we nemen aan” is, is de beheersmaatregel niet volwassen genoeg voor gereguleerde activiteiten.

De remediatieroadmap

Het remediatiepad is praktisch wanneer het in het ISMS is verankerd.

1. Bevestig dat het ISMS-toepassingsgebied clouddiensten, kritieke ICT-afhankelijkheden en gereguleerde gegevensverwerking omvat.
2. Bouw het register voor governance van cloudregio’s voor prioritaire diensten.
3. Koppel elke dienst aan gegevenscategorieën, regio’s, back-uplocaties, supporttoegang en subverwerkers.
4. Beoordeel leveranciersovereenkomsten op clausules voor opslaglocatie, doorgifte, audit, incidenten, onderaanneming, teruggave en vernietiging.
5. Werk het risicoregister bij voor hiaten, concentratierisico’s en ongedocumenteerde doorgiften.
6. Stem waar van toepassing het DORA ICT-register voor derde partijen en de NIS2-mapping van dienstafhankelijkheden op elkaar af.
7. Valideer technische afdwinging, inclusief regiolocks, back-upbeleid, logginginstellingen, encryptie, toegangscontrole en sleutelbeheer.
8. Stel een auditbewijspakket op met schermafbeeldingen, contracten, risicoregistraties, goedkeuringen, notulen en testresultaten.
9. Stel een wijzigingstrigger vast voor nieuwe regio’s, subverwerkers, doorgiftemechanismen of kritieke wijzigingen in leveranciersdiensten.
10. Rapporteer cloudresidentierisico, uitzonderingen en besluiten over restrisico aan het management.

Dit is geen theoretische naleving. Het is het verschil tussen een cloudomgeving die audittoetsing kan doorstaan en een omgeving die afhankelijk is van mondelinge toezeggingen.

De businesscase: soevereiniteit, weerbaarheid en vertrouwen

Bestuurders zien governance van gegevensresidentie soms als een beperking van cloudwendbaarheid. In de praktijk vergroot volwassen regiogovernance de wendbaarheid omdat teams de regels kennen voordat zij inkopen, bouwen of migreren.

Een productteam kan sneller lanceren wanneer goedgekeurde regio’s duidelijk zijn. Inkoop kan sneller onderhandelen wanneer verplichte clausules al zijn gedefinieerd. Juridische zaken kan doorgiften sneller beoordelen wanneer gegevensstromen zijn gedocumenteerd. Security Operations kan sneller onderzoeken wanneer loglocaties en toegangsrechten bekend zijn. Het bestuur kan sneller risicobesluiten nemen wanneer concentratierisico, continuïteitsimpact en acceptatie van restrisico zichtbaar zijn.

Voor klanten, vooral gereguleerde klanten, wordt dit een vertrouwenssignaal. Een SaaS-provider die kan uitleggen waar gegevens zich bevinden, hoe back-ups worden beheerst, hoe supporttoegang wordt gecontroleerd, hoe subverwerkers worden goedgekeurd en hoe regiowijzigingen worden beoordeeld, presteert beter dan een provider die alleen zegt: “wij gebruiken een toonaangevende cloudprovider”.

In 2026 is dat onderscheid belangrijk. NIS2 heeft cyberbeveiligingsgovernance naar essentiële en belangrijke entiteiten in de hele EU gebracht. DORA heeft toezicht op ICT-derden tot een formele discipline in de financiële sector gemaakt. GDPR-verantwoordingsplicht blijft centraal. ISO/IEC 27001:2022 biedt het managementsysteem dat dit bij elkaar houdt.

Volgende stappen met Clarysec

Als uw organisatie niet kan beantwoorden waar gereguleerde gegevens en kritieke ICT-verwerking zich bevinden over productie, back-ups, logbestanden, supporttoegang en onderaannemers heen, is dit het moment om het hiaat te sluiten.

Clarysec kan u helpen een bewijspakket voor governance van cloudregio’s op te bouwen met:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint voor gefaseerde ISO-implementatie en gereedheid voor audits.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls voor het mappen van ISO/IEC 27002:2022-cloud- en leveranciersbeheersmaatregelen naar operationeel bewijsmateriaal en verwachtingen over meerdere raamwerken heen.
• Cloud Usage Policy Cloud Usage Policy en Cloud Usage Policy-sme Cloud Usage Policy - SME voor eisen rond gegevensresidentie in de cloud.
• Third party and supplier security policy Third party and supplier security policy en Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME voor leverancierscontracten, onderaanneming en zekerheid over geografische opslag.
• Logging and Monitoring Policy-sme Logging and Monitoring Policy - SME voor logretentie en bewijsmateriaal van providers.
• Legal and Regulatory Compliance Policy Legal and Regulatory Compliance Policy voor triggers voor nalevingsbeoordelingen rond doorgiftemechanismen, subverwerkers en grensoverschrijdende gegevensstromen.

Begin met één kritieke dienst, één cloudprovider en één register. Binnen enkele workshops kunt u van aannames naar bewijsmateriaal gaan, en van gefragmenteerde naleving naar beheerste cloudweerbaarheid.

Download de Clarysec-toolkit, vraag een demo aan of boek een beoordeling van governance van cloudregio’s om uw toezeggingen over cloudresidentie om te zetten in auditgereed bewijsmateriaal.