BIO 8.01 ISO A.5.19

Dataresidency- En Locatievereisten Voor Cloudgegevens

📅 2025-11-26
‱
⏱ 18 minuten lezen
‱
🔮 Must-Have

đŸ’Œ Management Samenvatting

Voor Nederlandse overheidsorganisaties is de fysieke en logische locatie van gegevens in de cloud een strategische randvoorwaarde. Dataresidentie bepaalt niet alleen waar bestanden, e‑mail, logbestanden en back‑ups technisch worden opgeslagen, maar ook welk juridisch regime van toepassing is, welke bevoegde autoriteiten toegang kunnen vorderen en welke waarborgen gelden voor toezicht en handhaving. Een heldere set dataresidency‑vereisten is daarmee onmisbaar voor een veilige en rechtmatig ingerichte inzet van Microsoft 365 en Azure binnen de publieke sector.

Aanbeveling
IMPLEMENT
Risico zonder
High
Risk Score
8/10
Implementatie
140u (tech: 60u)
Van toepassing op:
✓ M365
✓ Azure
✓ Publieke Sector
✓ Overheidsorganisaties

Zonder expliciet beleid en concrete eisen rond dataresidentie ontstaat er een onoverzichtelijke mix van opslaglocaties, replicatiemechanismen en diensten die buiten de Europese Economische Ruimte (EER) of buiten overeengekomen datagebieden kunnen vallen. Dit kan leiden tot schending van contractuele afspraken, conflicten met de AVG, de Archiefwet en sectorale regelgeving, en een verhoogd risico op toegang door buitenlandse autoriteiten. Daarnaast worden steeds vaker eisen gesteld vanuit aanbestedingen, ketenpartners en toezichthouders om aan te tonen waar data zich daadwerkelijk bevindt, hoe fail‑over en back‑up zijn geregeld en welke technische en organisatorische maatregelen zijn genomen om data binnen afgesproken regio's te houden. Zonder structuur en tooling is het voor bestuurders en CISO’s vrijwel onmogelijk om hierover een betrouwbaar en actueel beeld te hebben.

PowerShell Modules Vereist
Primary API: Microsoft 365 en Azure beheerportalen, Security & Compliance PowerShell
Connection: Connect-ExchangeOnline, Connect-IPPSSession
Required Modules: ExchangeOnlineManagement

Implementatie

Dit artikel beschrijft hoe Nederlandse publieke organisaties een samenhangend raamwerk voor dataresidentie ontwerpen, implementeren en monitoren in Microsoft 365 en Azure. We behandelen eerst de juridische en normatieve context, waaronder AVG, NIS2, BIO en afspraken rond digitale soevereiniteit. Vervolgens werken we uit hoe u data‑classificatie, tenant‑locatie, workload‑specifieke opslag (Exchange Online, SharePoint, OneDrive, Teams) en Azure‑resources vertaalt naar concrete locatie-eisen. Daarna tonen we hoe u met configuratie‑richtlijnen, provisioning‑templates en PowerShell‑scripts de naleving van deze eisen bewaakt. Het gekoppelde PowerShell‑script ondersteunt u bij het inventariseren van de belangrijkste gegevenslocaties, het rapporteren van bevindingen en het opstellen van een verbeterplan dat aansluit op de Nederlandse Baseline voor Veilige Cloud.

Dataresidentie is geen puur technisch vraagstuk, maar een kruispunt van juridische verplichtingen, beleidskeuzes en architectuurprincipes. Voor Nederlandse overheidsorganisaties vormt de Algemene Verordening Gegevensbescherming (AVG) het fundament: persoonsgegevens mogen de Europese Economische Ruimte alleen verlaten wanneer passende waarborgen zijn geregeld, zoals standaardcontractbepalingen of een adequaatheidsbesluit. Daarnaast gelden sectorspecifieke eisen, bijvoorbeeld in de zorg, het onderwijs of de financiële sector, waarbij expliciet wordt voorgeschreven dat bepaalde gegevens binnen nationale grenzen of binnen de EER moeten blijven. Voor vitale aanbieders en aangewezen entiteiten onder NIS2 komen daar aanvullende verplichtingen bij rond risicobeheer, continuïteit en inzicht in de keten, die rechtstreeks raken aan de locatie van data en de bijbehorende verwerkingsactiviteiten.

De Baseline Informatiebeveiliging Overheid (BIO) schrijft niet letterlijk voor in welk land data zich moet bevinden, maar legt wel nadruk op beheersmaatregelen rondom uitbesteding, continuïteit, beschikbaarheid, integriteit en vertrouwelijkheid. In de praktijk betekent dit dat overheidsorganisaties moeten kunnen aantonen welke clouddienstverlener welke data verwerkt, waar die data primair en secundair wordt opgeslagen, welke jurisdicties van toepassing zijn en hoe toegang door derde partijen wordt beperkt en gelogd. Tegelijkertijd spelen beleidsdocumenten rond digitale soevereiniteit een steeds grotere rol: zij benadrukken de wens om afhankelijkheden van niet‑Europese leveranciers beheersbaar te houden, escalation paths contractueel vast te leggen en de inzet van datacenters binnen de EU of specifiek binnen Europa Region opties – zoals de EU Data Boundary van Microsoft – te maximaliseren.

Naast wet- en regelgeving zijn er ook governance‑kaders en architectuurprincipes die richting geven aan dataresidentie. Enterprise‑architecturen binnen de overheid hanteren vaak principes als ‘gegevens worden zo dicht mogelijk bij de bron opgeslagen’, ‘cloud‑diensten worden uitsluitend afgenomen als dataresidentie‑ en soevereiniteitsvereisten transparant zijn’ en ‘kritieke data wordt bij voorkeur binnen EU‑datacenters beheerd’. Deze principes moeten expliciet worden vertaald naar eisen aan Microsoft 365 en Azure: welke workloads mogen alleen in EU‑datacenters draaien, welke data valt onder striktere sectorale regels, en in welke uitzonderingsgevallen is opslag buiten de EU toch toegestaan mits aanvullende waarborgen zijn getroffen. Door deze vertaling vast te leggen in beleidsdocumenten Ă©n contracten ontstaat een toetsingskader dat kan worden gebruikt bij aanbestedingen, contractmanagement en periodieke herbeoordeling van cloud‑diensten.

Ontwerpprincipes voor dataresidentie in Microsoft 365 en Azure

Een robuuste aanpak van dataresidentie begint met heldere ontwerpprincipes die zowel door bestuur, architectuur als beheer worden gedragen. Het eerste principe is transparantie: organisaties moeten exact weten waar hun kerngegevens zich bevinden, hoe replicatie en back‑ups zijn ingericht en welke diensten mogelijk tijdelijk of structureel buiten de beoogde regio schrijven. Dit vraagt om een combinatie van documentatie, tooling van de leverancier en eigen inventarisaties. Het tweede principe is ‘geografische segmentatie’: gevoelige en mission‑critical gegevens worden zoveel mogelijk geconcentreerd in expliciet gekozen regio’s, bijvoorbeeld West‑Europa of de EU Data Boundary, terwijl minder gevoelige workloads eventueel in bredere regio‑clusters kunnen worden geplaatst. Het derde principe is dat dataresidentie altijd in samenhang met continuïteit en beschikbaarheid wordt beoordeeld: fail‑over naar een tweede regio is vaak noodzakelijk voor weerbaarheid, maar moet wel binnen aanvaardbare juridische en beleidsmatige kaders vallen.

Voor Microsoft 365 betekent dit dat bij de initiĂ«le tenantkeuze en bij latere uitbreidingen expliciet wordt gekeken naar de beschikbare datacenters en opslaglocaties voor Exchange Online, SharePoint Online, OneDrive en Teams. Veel Nederlandse overheidsorganisaties beschikken al over een tenant die in een Europese regio is aangemaakt, maar dat garandeert niet automatisch dat alle aanvullende services – zoals Copilot, Viva, Purview of Defender‑componenten – uitsluitend binnen dezelfde regio draaien. Een volwassen ontwerp houdt daarom rekening met de roadmap van Microsoft, de manier waarop nieuwe functionaliteit uitrolt over regio’s en de mogelijkheid om bepaalde preview‑features uit te schakelen zolang dataresidentie‑implicaties nog onduidelijk zijn. Daarnaast is het zinvol om per gegevensklasse (bijvoorbeeld ‘publiek’, ‘intern’, ‘vertrouwelijk’ en ‘zeer vertrouwelijk’) vast te leggen welke geografische zones zijn toegestaan en hoe uitzonderingen moeten worden aangevraagd en gedocumenteerd.

Binnen Azure gaat het ontwerp een stap verder, omdat organisaties hier zelf verantwoordelijk zijn voor het kiezen van resourcegroepen, regio’s en redundantie‑opties. Een goed uitgewerkt dataresidentieontwerp definieert welke regio’s zijn toegestaan voor productie, test en ontwikkeling, hoe cross‑region replicatie wordt ingericht en hoe wordt omgegaan met globale diensten zoals Azure Active Directory (nu Microsoft Entra ID), DNS of content delivery netwerken. Voor sommige scenario’s kan het nodig zijn om aparte landing zones of subscriptions op te zetten voor workloads met strengere dataresidentie‑eisen, bijvoorbeeld systemen die bijzondere persoonsgegevens verwerken of kritieke procesdata van vitale infrastructuur. Door deze keuzes vast te leggen in architectuurdocumenten, referentiemodellen en blauwdrukken voor nieuwe workloads, ontstaat een consistente lijn die in de hele organisatie wordt toegepast. Het gekoppelde PowerShell‑script kan vervolgens worden gebruikt om periodiek steekproefsgewijs te controleren of workloads inderdaad in de overeengekomen regio’s draaien en om afwijkingen te signaleren.

Implementatie van dataresidentie-eisen in Microsoft 365

De implementatie van dataresidentie‑eisen in Microsoft 365 start met een inventarisatie van bestaande workloads en opslaglocaties. Voor Exchange Online gaat het onder meer om mailboxdatabases, archiefmailboxen en eDiscovery‑opslag. Voor SharePoint en OneDrive spelen sites, documentbibliotheken en back‑uparchitecturen een rol. Teams combineert meerdere componenten: chatberichten worden opgeslagen in Exchange‑mailboxen, bestanden in SharePoint of OneDrive, terwijl vergaderopnames in Stream of OneDrive terecht kunnen komen. Een projectteam dat dataresidentie wil borgen, moet deze keten in kaart brengen en vastleggen welke onderdelen onder welke locatie‑eisen vallen. Daarbij is het verstandig om nauw samen te werken met de leverancier of implementatiepartner om exact te begrijpen welke datacenters in gebruik zijn, hoe fail‑over werkt en welke aanvullende services (zoals zoekindexen of analysetools) mogelijk in andere regio’s worden gehost.

Vervolgens moeten de dataresidentie‑eisen worden vertaald naar concrete configuraties en processen. Dit begint bij het vastleggen van de tenantlocatie en het documenteren van alle relevante Microsoft‑documentatie die de datastromen beschrijft. Op basis daarvan kan een organisatie besluiten om bepaalde functionaliteit alleen gefaseerd in te voeren of tijdelijk uit te schakelen zolang de dataresidentie‑impact niet acceptabel is. Daarnaast is het cruciaal om provisioning‑processen voor Teams, SharePoint‑sites en andere samenwerkingsomgevingen te standaardiseren. Door te werken met goedgekeurde templates, inclusief vooraf ingestelde gevoeligheidslabels, bewaartermijnen en toegangspatronen, wordt voorkomen dat data ongecontroleerd terechtkomt in omgevingen die later moeten worden gemigreerd. Ook contractmanagement speelt een belangrijke rol: verwerkersovereenkomsten, Data Protection Addenda en servicebeschrijvingen moeten expliciet verwijzen naar dataresidentie‑afspraken en de manier waarop de leverancier rapporteert over wijzigingen in datacenterlocaties.

Ten slotte vraagt implementatie om goede communicatie naar gebruikers en proceseigenaren. Veel medewerkers gaan er vanzelfsprekend van uit dat data ‘gewoon in Nederland’ staat, terwijl in werkelijkheid sprake is van een complexe multi‑region architectuur. Door helder uit te leggen welke keuzes de organisatie maakt, waarom bepaalde diensten nog niet beschikbaar zijn of waarom sommige samenwerkingen via specifieke Teams‑omgevingen moeten verlopen, wordt draagvlak gecreĂ«erd voor de beperkingen die uit dataresidentie voortkomen. Het projectteam kan hierbij gebruikmaken van praktische hulpmiddelen zoals infographics, handleidingen en FAQ‑pagina’s waarin wordt uitgelegd waar e‑mail, documenten en vergaderopnames worden opgeslagen en welke spelregels gelden voor het delen van gegevens met externe partijen. Het gekoppelde PowerShell‑script kan worden ingezet om periodiek een overzicht te genereren van mailboxen, sites en Teams‑omgevingen, inclusief indicatieve regio‑informatie, zodat beheerders concrete cijfers hebben om met bestuurders en auditors te delen.

Monitoring van dataresidentie en rapportage

Gebruik PowerShell-script data-residency-requirements.ps1 (functie Invoke-Monitoring) – Voert een inventarisatie uit van kerncomponenten in Microsoft 365 en geeft een samenvattend overzicht van geïdentificeerde gegevenslocaties en mogelijke afwijkingen ten opzichte van het beoogde datagebied..

Monitoring van dataresidentie is geen eenmalige controle maar een doorlopend proces. Configuraties veranderen, nieuwe diensten worden geactiveerd en gebruikers creĂ«ren voortdurend nieuwe Teams, sites en dataopslaglocaties. Zonder structurele monitoring kan een organisatie niet met zekerheid stellen dat zij nog steeds voldoet aan de oorspronkelijke dataresidentie‑eisen. Een praktische aanpak is om periodiek – bijvoorbeeld per kwartaal – een geautomatiseerde inventarisatie uit te voeren van een representatieve set mailboxen, SharePoint‑sites en Teams‑omgevingen. Daarbij wordt gekeken naar tenant‑eigenschappen, regio‑instellingen, gebruikte services en eventuele aanwijzingen dat data buiten de beoogde regio wordt gerepliceerd. De resultaten worden vastgelegd in een gestandaardiseerd rapport dat door CISO, CIO en privacy‑officer kan worden gebruikt om trends te volgen en gerichte vragen te stellen aan leveranciers en interne beheerteams.

Het gekoppelde PowerShell‑script is ontworpen om deze monitoringsstap te ondersteunen. In een veilige debugmodus kan het script lokaal worden uitgevoerd zonder verbinding met Microsoft 365, waardoor ontwikkelaars en auditors de logica en outputstructuur kunnen testen. In productieomgeving maakt het script verbinding met de Microsoft 365‑tenant via ExchangeOnlineManagement en, waar nodig, het Security & Compliance‑endpoint. Het script verzamelt informatie over een beperkt aantal mailboxen en basale tenantinstellingen, en bouwt op basis daarvan een object op met eigenschappen zoals IsCompliant, DetectedRegions, Findings en Recommendations. Dit object kan rechtstreeks worden gebruikt in dashboards of worden geĂ«xporteerd naar JSON voor verdere analyse. Door dit script op te nemen in een reguliere beheer- of auditcyclus ontstaat een herhaalbare werkwijze waarmee organisaties kunnen aantonen dat zij dataresidentie niet alleen op papier hebben geregeld, maar ook feitelijk monitoren.

Remediatie en structurele borging van dataresidentie

Gebruik PowerShell-script data-residency-requirements.ps1 (functie Invoke-Remediation) – Biedt beheerders gerichte aanbevelingen en voorbeeldcmdlets om geconstateerde afwijkingen in dataresidentie aan te pakken en te documenteren..

Wanneer monitoring laat zien dat bepaalde workloads of datasets niet meer voldoen aan de afgesproken dataresidentie‑eisen, is gerichte remediatie vereist. Dit kan variĂ«ren van relatief eenvoudige maatregelen – zoals het herconfigureren van standaardopslaglocaties voor vergaderopnames – tot complexe migraties van volledige Teams‑omgevingen, SharePoint‑sites of zelfs gehele tenants naar een andere regio. Een effectief remediatieproces begint met prioritering: welke afwijkingen leveren het grootste juridische, reputatie‑ of continuĂŻteitsrisico op en moeten dus als eerste worden aangepakt? Vervolgens wordt per afwijking bepaald of deze via configuratiewijzigingen, migratie‑tools of contractuele aanpassingen kan worden opgelost. Het is belangrijk om hierbij altijd een change‑managementproces te volgen, inclusief impactanalyse, testscenario’s en rollback‑plannen, omdat wijzigingen in datalocatie directe gevolgen kunnen hebben voor prestaties, integraties en gebruikerservaring.

Structurele borging betekent dat de organisatie leert van iedere remediatie‑actie. Als uit monitoring blijkt dat bepaalde teams of afdelingen consequent workloads in ongewenste regio’s aanmaken, is dat een signaal dat de onderliggende provisioning‑processen, templates of richtlijnen niet voldoende zijn. In dat geval moeten niet alleen de individuele afwijkingen worden opgelost, maar ook de bronoorzaak: bijvoorbeeld door goedgekeurde blauwdrukken verplicht te stellen, selfservice‑mogelijkheden voor bepaalde services te beperken of aanvullende controles in te bouwen in het aanvraagproces voor nieuwe omgevingen. Daarnaast is het essentieel om remediatie‑acties en beslissingen zorgvuldig te documenteren, zodat auditors en toezichthouders kunnen zien hoe de organisatie omgaat met geconstateerde tekortkomingen. Het gekoppelde PowerShell‑script ondersteunt dit door bij niet‑compliance niet automatisch ingrijpende wijzigingen door te voeren, maar beheerders duidelijke aanbevelingen en voorbeeldcmdlets te geven die zij binnen het reguliere changeproces kunnen gebruiken. Zo blijft de uiteindelijke verantwoordelijkheid waar die hoort: bij de organisatie zelf, terwijl tooling helpt om de uitvoering beheersbaar en reproduceerbaar te maken.

Compliance & Frameworks

Automation

Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).

PowerShell
<# .SYNOPSIS Controle van dataresidentie-vereisten voor Microsoft 365 kerngegevens .DESCRIPTION Voert een lichte inventarisatie uit van kernonderdelen in Microsoft 365 om inzicht te geven in dataresidentie-aspecten, zoals tenantconfiguratie en een beperkte set mailboxen. In DebugMode wordt uitsluitend met voorbeelddata gewerkt zodat het script veilig lokaal getest kan worden zonder verbinding met Microsoft 365. .NOTES Filename: data-residency-requirements.ps1 Author: Nederlandse Baseline voor Veilige Cloud Created: 2025-11-26 Version: 1.0 Related JSON: content/compliance/data-residency-requirements.json Category: compliance Workload: m365, azure .LINK https://github.com/m365-tenant-best-practise .EXAMPLE .\data-residency-requirements.ps1 -Monitoring -DebugMode Voert een lokale debug-run uit zonder verbinding te maken met Microsoft 365 en toont voorbeeldresultaten voor rapportage en dashboarding. .EXAMPLE .\data-residency-requirements.ps1 -Monitoring Maakt verbinding met Microsoft 365 (ExchangeOnline) en haalt een beperkte set informatie op over tenantconfiguratie en mailboxen voor dataresidentie-analyse. .EXAMPLE .\data-residency-requirements.ps1 -Remediation -WhatIf Toont aanbevelingen en voorbeeldcmdlets voor remediatie van dataresidentie, zonder daadwerkelijk wijzigingen door te voeren. #> #Requires -Version 5.1 #Requires -Modules ExchangeOnlineManagement [CmdletBinding()] param( [Parameter(HelpMessage = "Voer monitoring uit en genereer een rapportage-object")] [switch]$Monitoring, [Parameter(HelpMessage = "Toon gerichte aanbevelingen en voorbeeldcmdlets voor remediatie")] [switch]$Remediation, [Parameter(HelpMessage = "Toon welke acties zouden worden uitgevoerd zonder wijzigingen aan te brengen")] [switch]$WhatIf, [Parameter(HelpMessage = "Voer een veilige lokale test uit zonder verbinding met Microsoft 365")] [switch]$DebugMode, [Parameter(HelpMessage = "Plaatshouder voor toekomstig rollback-scenario")] [switch]$Revert ) $ErrorActionPreference = 'Stop' Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "Dataresidentie vereisten (Microsoft 365)" -ForegroundColor Cyan Write-Host "Nederlandse Baseline voor Veilige Cloud" -ForegroundColor Cyan Write-Host "========================================`n" -ForegroundColor Cyan function Connect-RequiredServices { <# .SYNOPSIS Maakt verbinding met benodigde Microsoft 365 services. .DESCRIPTION Verbindt met Exchange Online omdat mailboxen en gerelateerde opslag een belangrijke indicator zijn voor dataresidentie. #> [CmdletBinding()] param() Write-Host "Verbinding maken met Exchange Online..." -ForegroundColor Gray Connect-ExchangeOnline -ShowBanner:$false -ErrorAction Stop | Out-Null } function Test-Compliance { <# .SYNOPSIS Bepaalt de globale compliance-status rond dataresidentie. .DESCRIPTION Wrapper rond Invoke-Monitoring die uitsluitend de kernstatus retourneert. .OUTPUTS PSCustomObject met IsCompliant, DetectedRegions en Findings. #> [CmdletBinding()] param() return Invoke-Monitoring } function Invoke-Monitoring { <# .SYNOPSIS Voert een lichte inventarisatie uit voor dataresidentie. .DESCRIPTION Haalt in productie een beperkte set tenant- en mailboxgegevens op en bouwt een rapportage-object op met indicatieve regio-informatie en aanbevelingen. In DebugMode worden voorbeeldwaarden gebruikt zodat het script zonder cloudverbinding getest kan worden. .OUTPUTS PSCustomObject met: - ScriptName - IsCompliant - Timestamp - DetectedRegions - SampleMailboxes - Findings - Recommendations #> [CmdletBinding()] param() $result = [PSCustomObject]@{ ScriptName = "data-residency-requirements.ps1" IsCompliant = $false Timestamp = Get-Date DetectedRegions = @() SampleMailboxes = @() Findings = @() Recommendations = @() } try { if ($DebugMode) { Write-Host "DebugMode ingeschakeld: er wordt geen verbinding gemaakt met Microsoft 365." -ForegroundColor Yellow Write-Host "Er worden voorbeeldwaarden gebruikt voor DetectedRegions en SampleMailboxes.`n" -ForegroundColor Yellow $result.DetectedRegions = @("EU", "West-Europe") $result.SampleMailboxes = @( [PSCustomObject]@{ DisplayName = "Voorbeeld Gebruiker 1"; WorkloadHint = "Exchange Online (EU)" }, [PSCustomObject]@{ DisplayName = "Voorbeeld Gebruiker 2"; WorkloadHint = "Exchange Online (EU)" } ) $result.Findings += "DebugMode: voorbeeldinventarisatie uitgevoerd. Gebruik productie-run voor echte dataresidentie-analyse." $result.Recommendations += "Plan een periodieke productie-run (bijv. per kwartaal) en archiveer de rapportages als audit-bewijs." $result.IsCompliant = $true } else { Connect-RequiredServices Write-Host "Ophalen van een beperkte set mailboxen voor indicatieve regio-informatie..." -ForegroundColor Gray $mailboxes = Get-Mailbox -ResultSize 10 -ErrorAction SilentlyContinue if ($mailboxes -and $mailboxes.Count -gt 0) { $sample = $mailboxes | Select-Object -First 5 -Property DisplayName,PrimarySmtpAddress,Database $result.SampleMailboxes = $sample # Gebruik de mailboxdatabase als grove indicator voor regio (afhankelijk van Microsoft-implementatie) $regions = $sample | Where-Object { $_.Database } | ForEach-Object { $_.Database } | Sort-Object -Unique if ($regions) { $result.DetectedRegions = $regions $result.Findings += "Er zijn Ă©Ă©n of meer mailboxdatabases gedetecteerd. Gebruik Microsoft-documentatie om deze te mappen op feitelijke datacenterregio's." } else { $result.Findings += "Mailboxdatabases konden niet worden afgeleid. Raadpleeg handmatig de data location-documentatie in het Microsoft 365-beheercentrum." } } else { $result.Findings += "Er konden geen mailboxen worden opgehaald. Controleer permissies en Exchange Online-connectie." } if (-not $result.DetectedRegions -or $result.DetectedRegions.Count -eq 0) { $result.Recommendations += "Documenteer de verwachte dataresidentie (bijv. EU Data Boundary) en verifieer deze via het Microsoft 365-beheercentrum en leverancierdocumentatie." } $result.Recommendations += "Leg de resultaten van deze inventarisatie vast in het centrale compliance-dossier voor dataresidentie." # Voor deze monitor hanteren we een pragmatische compliance-definitie: # zolang er een inventarisatie kan worden uitgevoerd en resultaten worden vastgelegd, # wordt IsCompliant op 'true' gezet; inhoudelijke beoordeling gebeurt door CISO/architect. $result.IsCompliant = $true } Write-Host "`nSamenvatting dataresidentie-inventarisatie:" -ForegroundColor Cyan Write-Host (" Gedetecteerde regio-indicatoren : {0}" -f ($result.DetectedRegions -join ", ")) -ForegroundColor White Write-Host (" Aantal voorbeeldmailboxen : {0}" -f $result.SampleMailboxes.Count) -ForegroundColor White if ($result.Findings.Count -gt 0) { Write-Host "`nBevindingen:" -ForegroundColor Yellow foreach ($finding in $result.Findings) { Write-Host " - $finding" -ForegroundColor Yellow } } if ($result.Recommendations.Count -gt 0) { Write-Host "`nAanbevelingen:" -ForegroundColor Green foreach ($rec in $result.Recommendations) { Write-Host " - $rec" -ForegroundColor Green } } return $result } catch { Write-Host "`n[FAIL] Fout tijdens monitoring: $_" -ForegroundColor Red throw } } function Invoke-Remediation { <# .SYNOPSIS Geeft gerichte aanbevelingen voor verbeteringen rond dataresidentie. .DESCRIPTION Voert zelf geen grootschalige migraties uit, maar biedt beheerders concrete aandachtspunten en voorbeeldcmdlets die binnen reguliere changeprocessen kunnen worden gebruikt om dataresidentie te verbeteren. #> [CmdletBinding()] param() try { if ($DebugMode) { Write-Host "DebugMode: remediatiestappen worden alleen als tekst getoond, er worden geen verbindingen gemaakt." -ForegroundColor Yellow } else { Connect-RequiredServices } Write-Host "`nRemediatie-advies voor dataresidentie:" -ForegroundColor Cyan Write-Host "`n1. Documenteer huidige dataresidentie" -ForegroundColor White Write-Host " - Verzamel tenantlocatie, gebruikte Microsoft 365-diensten en relevante Microsoft-documentatie." -ForegroundColor Gray Write-Host "`n2. Beperk ongecontroleerde tenant-functies" -ForegroundColor White Write-Host " - Schakel preview-functies uit die mogelijk in andere regio's draaien totdat de impact is beoordeeld." -ForegroundColor Gray Write-Host "`n3. Gebruik goedgekeurde templates voor Teams en sites" -ForegroundColor White Write-Host " - Standaardiseer provisioning zodat gevoelige data in gecontroleerde omgevingen blijft." -ForegroundColor Gray Write-Host "`n4. Voorbeeldcmdlets (indicatief, pas aan op eigen beleid):" -ForegroundColor White Write-Host " - Voorbeeld: Exporteer een overzicht van mailboxen ter ondersteuning van dataresidentie-analyse:" -ForegroundColor Gray Write-Host " Get-Mailbox -ResultSize 100 | Select-Object DisplayName,PrimarySmtpAddress,Database | Export-Csv '.\\mailbox-dataresidency-export.csv' -NoTypeInformation" -ForegroundColor DarkGray if ($WhatIf) { Write-Host "`nWhatIf: er zijn geen wijzigingen uitgevoerd; bovenstaande cmdlets zijn voorbeelden voor gebruik in change-scripts." -ForegroundColor Yellow } else { Write-Host "`nLet op: voer feitelijke wijzigingen alleen uit na goedkeuring via het change-managementproces en testen in acceptatie." -ForegroundColor Yellow } } catch { Write-Host "`n[FAIL] Fout tijdens remediatie-ondersteuning: $_" -ForegroundColor Red throw } } function Invoke-Revert { <# .SYNOPSIS Plaatshouder voor toekomstig rollback-scenario. .DESCRIPTION Dit script voert geen automatische rollback of migratie uit; rollback van dataresidentie-gerelateerde configuraties vereist een apart traject. #> [CmdletBinding()] param() Write-Host "`nEr is geen automatische rollback-functionaliteit geĂŻmplementeerd voor dataresidentie-configuraties." -ForegroundColor Yellow Write-Host "Beheer migraties en configuratiewijzigingen altijd via uw reguliere change-proces." -ForegroundColor Yellow } try { if ($Revert) { Invoke-Revert } elseif ($Remediation) { Invoke-Remediation } elseif ($Monitoring) { $monitorResult = Invoke-Monitoring if ($monitorResult.IsCompliant) { exit 0 } else { exit 1 } } else { Write-Host "Beschikbare parameters:" -ForegroundColor Yellow Write-Host " -Monitoring : Voer een lichte dataresidentie-inventarisatie uit" -ForegroundColor Gray Write-Host " -Remediation : Toon remediatie-advies en voorbeeldcmdlets" -ForegroundColor Gray Write-Host " -DebugMode : Test lokaal zonder cloudverbinding" -ForegroundColor Gray Write-Host " -WhatIf : Toon remediatievoorbeelden zonder uitvoer" -ForegroundColor Gray Write-Host " -Revert : Toon informatie over rollback (geen auto-rollback)" -ForegroundColor Gray Write-Host "`nVoorbeeld: .\data-residency-requirements.ps1 -Monitoring -DebugMode" -ForegroundColor Cyan } } catch { Write-Error "Scriptuitvoering is mislukt: $_" exit 2 } finally { Write-Host "`n========================================`n" -ForegroundColor Cyan } # Exitcodes: # 0 = Compliant # 1 = Niet compliant # 2 = Fout tijdens uitvoering

Risico zonder implementatie

Risico zonder implementatie
High: Zonder expliciete dataresidentie‑eisen en structurele monitoring is niet aantoonbaar waar kerngegevens zich bevinden en onder welke jurisdicties zij vallen. Dit vergroot het risico op juridische non‑compliance, onverwachte toegang door buitenlandse autoriteiten en complexe, kostbare migratietrajecten achteraf.

Management Samenvatting

Definieer duidelijke dataresidentie‑eisen voor Microsoft 365 en Azure, vertaal deze naar concrete ontwerpprincipes en configuraties, en monitor periodiek of workloads daadwerkelijk binnen de beoogde regio’s draaien. Gebruik het bijbehorende PowerShell‑script om kerngegevenslocaties te inventariseren en een onderbouwd verbeterplan op te stellen.