L1 BIO 12.03 ISO A.8.13 CIS 7.3

Disaster Recovery Testing Voor Azure Workloads

📅 2025-11-26
•
⏱️ 10 minuten lezen
•
🔴 Must-Have

💼 Management Samenvatting

Disaster Recovery Testing in Azure gaat verder dan het incidenteel terugzetten van een back-up: het is een gestructureerd programma van herstelproeven waarmee organisaties aantonen dat kritieke workloads binnen acceptabele tijden kunnen worden hersteld na een grote verstoring. Door periodiek realistische tests uit te voeren, wordt duidelijk of configuraties, procedures, mensen en afhankelijkheden daadwerkelijk werken zoals beschreven in het business continuity plan.

Aanbeveling
IMPLENTEER EEN STRUCTUREEL DISASTER RECOVERY TESTPROGRAMMA VOOR ALLE KRITIEKE AZURE-WORKLOADS.
Risico zonder
High
Risk Score
8/10
Implementatie
48u (tech: 32u)
Van toepassing op:
✓ Azure
✓ Hybride omgevingen

Veel organisaties investeren aanzienlijk in back-upoplossingen en Azure Site Recovery, maar testen slechts zelden of de gekozen strategie in de praktijk standhoudt. Tijdens een echte calamiteit blijkt dan dat herstelpunten corrupt zijn, runbooks onvolledig zijn, afhankelijkheden zoals DNS, identiteitsvoorzieningen of netwerkconnectiviteit ontbreken, of dat sleutelfiguren niet weten welke stappen zij moeten nemen. Voor Nederlandse overheidsorganisaties is dit onacceptabel: uitval van kritieke ketens zoals burgerregistratie, uitkeringen, vergunningverlening of noodhulp kan direct maatschappelijke schade veroorzaken en het vertrouwen van burgers ernstig aantasten. Daarnaast vereisen kaders als de BIO, NIS2 en sectorale toezichthouders dat continuïteit niet alleen op papier is geregeld, maar aantoonbaar is getoetst met periodieke scenario-oefeningen en technische herstelproeven. Zonder structurele Disaster Recovery Testing ontbreekt objectief bewijs dat RPO- en RTO-doelstellingen haalbaar zijn, waardoor bestuurders beslissen op basis van aannames in plaats van feiten.

PowerShell Modules Vereist
Primary API: Azure API
Connection: Connect-AzAccount
Required Modules: Az.Accounts, Az.RecoveryServices, Az.Compute

Implementatie

Dit artikel beschrijft hoe u een professioneel Disaster Recovery testprogramma opzet voor Azure-workloads binnen de context van de Nederlandse Baseline voor Veilige Cloud. U leert hoe u kritieke diensten identificeert, passende scenario's definieert en een herhaalbare testkalender opbouwt waarin zowel back-upherstel als failover via Azure Site Recovery aan bod komen. Vervolgens wordt uitgelegd hoe u in Azure Recovery Services-kluizen, back-up jobs en herstelrapportages gebruikt om aan te tonen dat herstelpunten bruikbaar zijn en dat ingestelde RPO- en RTO-doelen daadwerkelijk worden gehaald. Tot slot wordt ingegaan op de organisatorische inbedding: wie is eigenaar van welke stappen, hoe borgt u dat leerpunten uit tests worden doorvertaald naar verbetermaatregelen, en hoe levert u auditbaar bewijs aan CISO, interne audit en externe toezichthouders. Het bijbehorende PowerShell-script ondersteunt beheerteams bij het inventariseren van beschermde workloads en het rapporteren van de recente hersteltests, zodat technische realiteit en bestuurlijke rapportages nauw op elkaar aansluiten.

Vereisten

Een volwassen programma voor Disaster Recovery Testing begint met heldere randvoorwaarden. Technisch gezien is een consistente inzet van Azure Backup en, waar nodig, Azure Site Recovery onmisbaar. Alle productie- en bedrijfskritische workloads die onder het business continuity plan vallen, moeten zijn gekoppeld aan een Recovery Services-kluis met een vastgesteld beleid voor back-upfrequentie en retentie. Zonder deze basis kunnen hersteltests alleen ad-hoc plaatsvinden, wat resulteert in incidentele successen in plaats van structureel vertrouwen. Tegelijkertijd moeten de architectuurprincipes voor deze workloads expliciet zijn vastgelegd: welke componenten zijn noodzakelijk voor minimale dienstverlening, welke afhankelijkheden bestaan er met on-premises systemen, identity-platforms, DNS, sleutelkluizen en netwerkverbindingen, en welke data-classificatie geldt per applicatie. Deze inventarisatie vormt de blauwdruk voor elk testscenario en bepaalt uiteindelijk of een test realistisch is. Naast technische fundamenten zijn governance en eigenaarschap even belangrijk. Iedere kritieke dienst moet een aangewezen proceseigenaar hebben die eindverantwoordelijk is voor de continuïteit en formeel akkoord geeft op de gekozen RPO- en RTO-eisen. Deze eisen moeten zijn vastgelegd in het business continuity plan en aansluiten bij bestuurlijke risicoacceptatie. Zonder expliciete goedkeuring ontstaat het risico dat IT-teams impliciet strengere of juist te soepele doelstellingen nastreven, met onduidelijkheid en discussies tijdens incidenten als gevolg. Voor de uitvoering van tests is een multidisciplinair team nodig met vertegenwoordigers uit infrastructuur, applicatiebeheer, security, netwerk, identity en, waar relevant, leveranciers. Dit team moet beschikken over duidelijke runbooks, contactgegevens en escalatiepaden zodat tijdens een oefening geen tijd verloren gaat aan basisorganisatie. Ook tooling en omgevingen verdienen aandacht. Organisaties hebben minimaal één representatieve test- of acceptatieomgeving nodig waarin herstelproeven kunnen worden uitgevoerd zonder directe impact op productie. Voor sommige scenario's is het noodzakelijk om testherstel in een tijdelijke geïsoleerde omgeving uit te voeren, bijvoorbeeld een apart subnet of een gescheiden resource group, om ongewenste toegang tot productiedata of externe koppelingen te voorkomen. Verder moeten logging en monitoring al vóór de eerste test op orde zijn, zodat doorlooptijden, fouten en succespercentages objectief kunnen worden gemeten. Zonder betrouwbare telemetrie blijft een oefening steken op kwalitatieve indrukken in plaats van harde cijfers. Ten slotte is er een organisatorische vereiste: het bestuur moet bereid zijn tijd, budget en aandacht vrij te maken voor structurele tests. Disaster Recovery Testing kost capaciteit van specialisten, veroorzaakt soms tijdelijke verstoringen in testomgevingen en kan leiden tot aanvullende investeringen in architectuur, licenties of procesverbeteringen. Deze kosten moeten expliciet worden afgewogen tegen de potentiële schade van langdurige uitval of dataverlies. In de Nederlandse publieke sector, waar continuïteit van dienstverlening en rechtszekerheid centraal staan, is die businesscase doorgaans overtuigend, mits duidelijk wordt gemaakt welke scenario's worden voorkomen en welke wettelijke verplichtingen worden ingevuld door een actief testprogramma.

Implementatie

Gebruik PowerShell-script disaster-recovery-testing.ps1 (functie Invoke-Implementation) – Ondersteunt het voorbereiden en registreren van Disaster Recovery tests voor Azure-workloads op basis van Recovery Services-kluizen..

De implementatie van een herhaalbaar Disaster Recovery testprogramma in Azure verloopt gefaseerd. In de voorbereidingsfase worden workloads geselecteerd op basis van hun kriticiteit en dataclassificatie. Begin met een beperkte set kernsystemen, zoals identity, kernregistraties en primaire lijnapplicaties, zodat de organisatie ervaring kan opdoen zonder zichzelf te overbelasten. Voor elk systeem wordt een minimale dienstomvang gedefinieerd: welke functies moeten beschikbaar zijn om wettelijke verplichtingen, publieke dienstverlening of veiligheidstaken te kunnen uitvoeren. Dit voorkomt dat tests uitmonden in perfectionistische trajecten waarin alleen een volledig herstelde omgeving als succesvol wordt gezien. Vervolgens worden concrete testscripts en runbooks opgesteld. Voor back-upgebaseerde scenario's beschrijven deze runbooks stap voor stap hoe een herstel uit een Recovery Services-kluis wordt uitgevoerd, welke configuraties moeten worden hersteld (schijven, configuratiebestanden, sleutelreferenties), welke afhankelijkheden moeten worden geactiveerd (DNS, netwerkregels, identiteitsvoorzieningen) en hoe wordt gecontroleerd dat de applicatie functioneel werkt. Voor Site Recovery-scenario's bevat het runbook onder meer de indeling in herstelplannen, de volgorde waarin componenten worden opgestart, de rol van netwerksegmenten en de manier waarop terugschakeling naar de primaire locatie wordt geregeld. Elk runbook vermeldt expliciet welke logboekregels, dashboards en rapportages zijn vereist om achteraf objectief te kunnen aantonen dat de test geslaagd is. Tijdens de uitvoeringsfase worden de geplande tests gecontroleerd en stap voor stap doorlopen. Voor een test op basis van Azure Backup wordt bijvoorbeeld eerst een representatieve momentopname geselecteerd, daarna wordt een herstel uitgevoerd naar een geïsoleerde resource group met eigen netwerksegment. Samen met de proceseigenaar wordt gecontroleerd of kernfunctionaliteit beschikbaar is, of gebruikers kunnen inloggen, of gegevens volledig en correct zijn en of rapportages en koppelingen functioneren zoals verwacht. Alle bevindingen, inclusief doorlooptijden, fouten en tijdelijke workarounds, worden vastgelegd in een standaard sjabloon. Voor Site Recovery-tests wordt op vergelijkbare wijze een geplande failover uitgevoerd, bij voorkeur buiten kantooruren of in een dedicated testomgeving, en na afronding vindt een gecontroleerde failback plaats. Tot slot volgt de evaluatiefase. Hierin worden de testresultaten besproken in een multidisciplinair overleg waarin zowel technische als organisatorische aspecten aan bod komen. Relevante vragen zijn onder meer: zijn de beoogde RPO- en RTO-doelen gehaald, welke knelpunten traden op, welke documentatie bleek verouderd, en welke afhankelijkheden bleken kwetsbaarder dan gedacht. De uitkomsten worden vertaald naar concrete acties, zoals aanpassing van architectuur, uitbreiding van monitoring, verbetering van runbooks of aanvullende training voor beheerders. Deze acties krijgen een eigenaar, deadline en prioriteit en worden opgenomen in het reguliere verbeterportfolio. Door deze cyclus minimaal jaarlijks per kritieke dienst te doorlopen, ontwikkelt de organisatie een aantoonbaar volwassen niveau van veerkracht in lijn met de Nederlandse Baseline voor Veilige Cloud.

Monitoring

Gebruik PowerShell-script disaster-recovery-testing.ps1 (functie Invoke-Monitoring) – Rapporteert op basis van Recovery Services-kluizen welke workloads recent zijn getest via herstel- of failoveracties..

Monitoring van Disaster Recovery Testing richt zich niet alleen op de beschikbaarheid van back-ups en replicatie, maar vooral op de vraag of herstelproeven regelmatig worden uitgevoerd en gedocumenteerd. In Azure vormt de combinatie van Recovery Services-kluizen, back-up jobs, hersteljobs en eventueel Site Recovery-rapportages de technische basis voor deze monitoring. Door deze gegevens systematisch te analyseren, kan worden vastgesteld hoeveel workloads daadwerkelijk in de afgelopen maanden zijn getest, welke kluizen achterlopen en welke applicaties mogelijk ten onrechte buiten het testprogramma vallen. Het bijbehorende PowerShell-script kan bijvoorbeeld per kluis rapporteren hoeveel virtuele machines beschermd zijn en hoeveel daarvan in de afgelopen periode een geslaagde testrestore of testfailover hebben doorlopen. Deze cijfers worden vervolgens gebruikt om managementrapportages op te bouwen en concrete verbeteracties te sturen. Naast technische indicatoren moeten ook procesindicatoren worden gemonitord. Denk aan het aantal uitgevoerde tests ten opzichte van de planning in de jaaragenda, de doorlooptijd tussen geconstateerde bevindingen en afgeronde verbeteracties, en het aantal scenario's waarin ketenafhankelijkheden expliciet zijn meegenomen. Door deze indicatoren periodiek te bespreken in een governanceoverleg tussen CISO, proceseigenaren en IT-management, ontstaat een continue verbeterlus. Belangrijk is dat monitoringresultaten niet alleen in technische teams blijven, maar in een begrijpelijke vorm worden teruggekoppeld naar bestuurders, bijvoorbeeld via kwartaalrapportages of dashboards waarin voor elke kritieke dienst de status van Disaster Recovery Testing wordt aangeduid. Tenslotte speelt monitoring een rol als vroegtijdig waarschuwingssysteem. Wanneer uit rapportages blijkt dat bepaalde kluizen of applicaties herhaaldelijk geen geldige herstelproeven ondergaan, is dat een signaal dat de organisatie bij een echte calamiteit mogelijk onvoorbereid is. In zo'n geval moet een duidelijke escalatiestroom in werking treden, waarbij de verantwoordelijke proceseigenaar, het CISO-office en indien nodig het directieteam worden geïnformeerd. Door deze signalering expliciet te verankeren in het risk management proces en het ISMS, wordt voorkomen dat structurele tekortkomingen jarenlang onopgemerkt blijven.

Compliance en Auditing

Disaster Recovery Testing is een directe invulling van diverse compliance- en auditvereisten voor Nederlandse overheidsorganisaties. De Baseline Informatiebeveiliging Overheid (BIO) benadrukt in meerdere maatregelen dat organisaties passende voorzieningen voor back-up en herstel moeten treffen en dat deze voorzieningen periodiek moeten worden getest. Zonder aantoonbare tests is het onmogelijk om te bewijzen dat continuïteitsmaatregelen in de praktijk werken. In de context van NIS2, met name artikel 21, wordt van essentiële en belangrijke entiteiten verwacht dat zij maatregelen treffen om de continuïteit van hun diensten te waarborgen, inclusief regelmatige oefeningen en evaluaties van hun respons- en herstelcapaciteit. Disaster Recovery Testing in Azure levert precies dat bewijs: objectieve data over hoe snel systemen na een verstoring weer beschikbaar zijn en welke data maximaal verloren gaat. Ook internationale normen zoals ISO 27001 en sectorale toetsingskaders zoals ENSIA en DigiD-beveiligingseisen verwijzen expliciet naar het testen van back-up- en herstelprocedures. Auditors vragen niet alleen naar beleidsdocumenten, maar willen concrete testverslagen, logbestanden, meetwaarden en verbeterplannen zien. Door Azure-rapportages uit Recovery Services-kluizen, logbestanden van hersteljobs en PowerShell-rapportages te combineren met formele evaluatieverslagen, ontstaat een volledig auditspoor. Dit spoor laat zien welke systemen wanneer zijn getest, welke scenario's zijn geoefend, welke bevindingen zijn gedaan en hoe deze zijn opgevolgd. Het ontbreken van dergelijke bewijslast leidt in de praktijk tot bevindingen met hoge prioriteit, omdat het wijst op onvoldoende grip op de feitelijke herstelcapaciteit. Daarnaast speelt Disaster Recovery Testing een rol in de verantwoording richting burgers en bestuur. Wanneer een gemeente, ministerie of uitvoeringsinstantie te maken krijgt met een groot incident, zullen media, volksvertegenwoordigers en toezichthouders vragen of de organisatie redelijke maatregelen heeft genomen om uitval te voorkomen en snel te herstellen. Door te kunnen aantonen dat er een structureel testprogramma bestaat, met gedocumenteerde resultaten en verbetercycli, laat de organisatie zien dat zij de verantwoordelijkheid voor continuïteit serieus neemt. Dit versterkt niet alleen de juridische positie bij eventuele onderzoeken, maar draagt ook bij aan vertrouwen in de digitale overheid. Binnen de Nederlandse Baseline voor Veilige Cloud is een volwassen Disaster Recovery testprogramma daarom geen luxe, maar een essentieel onderdeel van aantoonbare naleving en goed openbaar bestuur.

Remediatie

Gebruik PowerShell-script disaster-recovery-testing.ps1 (functie Invoke-Remediation) – Helpt bij het identificeren van workloads zonder recente hersteltests en ondersteunt het plannen van gerichte remediatie-acties..

Wanneer uit monitoring of audits blijkt dat bepaalde workloads geen recente Disaster Recovery tests hebben ondergaan, is snelle en gestructureerde remediatie noodzakelijk. De eerste stap bestaat uit het analyseren van de achterstand: gaat het om incidentele omissies bij individuele systemen, of wijst het patroon op structurele tekortkomingen in processen, tooling of governance. Op basis hiervan wordt een prioriteitenlijst opgesteld, waarbij systemen met hoge impact op publieke dienstverlening, veiligheid of juridische verplichtingen als eerste worden opgepakt. Voor deze systemen wordt een versnelde test gepland, bij voorkeur in een gecontroleerde omgeving, zodat de organisatie binnen korte tijd weer over actueel herstelbewijs beschikt. Het bijbehorende PowerShell-script kan helpen om snel inzicht te geven in welke Recovery Services-kluizen en workloads de grootste achterstand hebben, zodat remediatie-inspanningen doelgericht kunnen worden ingezet. Parallel aan deze technische acties moeten de onderliggende oorzaken worden aangepakt. Dit kan variëren van onvoldoende capaciteit of mandaat bij beheerteams, via ontbrekende of verouderde runbooks, tot een cultuur waarin continuïteitstesten als verstorend of optioneel worden gezien. Effectieve remediatie omvat daarom vaak ook proceswijzigingen: het formaliseren van een jaarlijkse testkalender, het opnemen van Disaster Recovery Testing als vaste agendapunt in change- en risicocommissies, het koppelen van testresultaten aan prestatie-indicatoren voor leveranciers en interne teams, en het expliciet beleggen van eigenaarschap bij proceseigenaren. Alle uitgevoerde remediatie-acties en nieuwe testresultaten worden vastgelegd in het ISMS, zodat auditors en bestuurders kunnen zien welke verbeterstappen zijn gezet en welke risico's zijn teruggebracht. Op die manier wordt een tijdelijke achterstand in Disaster Recovery Testing omgezet in een kans om het continuïteitsmanagement structureel te versterken.

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
<# ================================================================================ AZURE POWERSHELL SCRIPT - Nederlandse Baseline voor Veilige Cloud ================================================================================ .SYNOPSIS Disaster Recovery Testing Monitoring .DESCRIPTION Controleert op basis van Azure Recovery Services-kluizen of workloads recent zijn getest via herstel- of failoveracties en genereert een samenvattend rapport voor continuïteits- en auditdoeleinden. .NOTES Filename: disaster-recovery-testing.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 NBVC Debug: Gebruik de omgevingsvariabele NBVC_LOCAL_DEBUG=1 om lokale testen uit te voeren zonder verbinding te maken met Azure-API's. #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.RecoveryServices [CmdletBinding()] param( [Parameter(HelpMessage = "Controleert de status van Disaster Recovery tests")] [switch]$Monitoring, [Parameter(HelpMessage = "Ondersteunt het voorbereiden en plannen van DR-tests")] [switch]$Implementation, [Parameter(HelpMessage = "Voert controle uit en markeert workloads zonder recente tests")] [switch]$Remediation, [Parameter(HelpMessage = "Preview wijzigingen (alleen voor toekomstige uitbreidingen)")] [switch]$WhatIf ) $ErrorActionPreference = 'Stop' $PolicyName = "Azure Disaster Recovery Testing" function Get-IsLocalDebug { param() return [bool]($env:NBVC_LOCAL_DEBUG -eq '1') } function Connect-RequiredServices { if (Get-IsLocalDebug) { Write-Verbose "NBVC_LOCAL_DEBUG is actief - Azure verbinding wordt overgeslagen." return } try { if (-not (Get-Module -ListAvailable -Name Az.Accounts)) { throw "Het PowerShell-module 'Az.Accounts' is niet beschikbaar. Installeer dit module voordat u het script in productie gebruikt." } $ctx = Get-AzContext -ErrorAction SilentlyContinue if (-not $ctx) { Write-Host "Verbinding maken met Azure (Connect-AzAccount)..." -ForegroundColor Yellow Connect-AzAccount -ErrorAction Stop | Out-Null } else { Write-Verbose "Bestaande Azure context gevonden: $($ctx.Name)" } } catch { throw "Kon niet verbinden met Azure: $($_.Exception.Message)" } } function Get-DrTestStatus { <# .SYNOPSIS Haalt samenvattende informatie op over recente hersteltests. .OUTPUTS PSCustomObject met aantallen workloads en recente tests. #> [CmdletBinding()] param( [int]$DaysLookback = 180 ) if (Get-IsLocalDebug) { # Gesimuleerde gegevens voor lokale debug en CI-tests return [PSCustomObject]@{ Timestamp = Get-Date LookbackDays = $DaysLookback TotalProtectedItems = 10 ItemsWithRecentRestore = 7 Vaults = @( [PSCustomObject]@{ VaultName = "nbvc-demo-vault" ProtectedItems = 10 ItemsWithRecentRestore = 7 LastRestoreJobTime = (Get-Date).AddDays(-14) } ) } } Connect-RequiredServices $vaults = Get-AzRecoveryServicesVault -ErrorAction SilentlyContinue if (-not $vaults) { Write-Verbose "Geen Recovery Services-kluizen gevonden in deze context." return [PSCustomObject]@{ Timestamp = Get-Date LookbackDays = $DaysLookback TotalProtectedItems = 0 ItemsWithRecentRestore = 0 Vaults = @() } } $since = (Get-Date).AddDays(-1 * $DaysLookback) $vaultSummaries = @() $totalProtected = 0 $totalWithRestore = 0 foreach ($vault in $vaults) { try { Set-AzRecoveryServicesVaultContext -Vault $vault -ErrorAction Stop $items = Get-AzRecoveryServicesBackupItem -ErrorAction SilentlyContinue $protectedCount = ($items | Where-Object { $_.WorkloadType -ne $null }).Count $totalProtected += $protectedCount $jobs = Get-AzRecoveryServicesBackupJob -From $since -To (Get-Date) -ErrorAction SilentlyContinue $restoreJobs = $jobs | Where-Object { $_.Operation -match "Restore" -and $_.Status -eq "Completed" } $lastRestore = $null if ($restoreJobs) { $lastRestore = ($restoreJobs | Sort-Object -Property EndTime -Descending | Select-Object -First 1).EndTime } # Vereenvoudigde aanname: als er in de lookback-periode hersteljobs zijn, zijn er workloads getest $testedItems = if ($restoreJobs) { [Math]::Min($protectedCount, $restoreJobs.Count) } else { 0 } $totalWithRestore += $testedItems $vaultSummaries += [PSCustomObject]@{ VaultName = $vault.Name ResourceGroupName = $vault.ResourceGroupName ProtectedItems = $protectedCount ItemsWithRecentRestore = $testedItems LastRestoreJobTime = $lastRestore } } catch { Write-Verbose "Fout bij uitlezen van kluis '$($vault.Name)': $($_.Exception.Message)" } } return [PSCustomObject]@{ Timestamp = Get-Date LookbackDays = $DaysLookback TotalProtectedItems = $totalProtected ItemsWithRecentRestore = $totalWithRestore Vaults = $vaultSummaries } } function Invoke-Monitoring { <# .SYNOPSIS Toont een overzicht van recente Disaster Recovery tests. #> [CmdletBinding()] param( [int]$DaysLookback = 180 ) Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName - Monitoring" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan $summary = Get-DrTestStatus -DaysLookback $DaysLookback $total = $summary.TotalProtectedItems $tested = $summary.ItemsWithRecentRestore $percentage = if ($total -gt 0) { [Math]::Round(($tested / $total) * 100, 2) } else { 0 } Write-Host "Periode (dagen): $($summary.LookbackDays)" -ForegroundColor White Write-Host "Totaal beschermde items: $total" -ForegroundColor White Write-Host "Items met recente test: $tested ($percentage`%)" -ForegroundColor $(if ($percentage -ge 75) { "Green" } elseif ($percentage -ge 40) { "Yellow" } else { "Red" }) foreach ($v in $summary.Vaults) { $p = if ($v.ProtectedItems -gt 0) { [Math]::Round(($v.ItemsWithRecentRestore / $v.ProtectedItems) * 100, 2) } else { 0 } Write-Host "`nKluizenaam: $($v.VaultName)" -ForegroundColor Cyan Write-Host " Resourcegroep: $($v.ResourceGroupName)" -ForegroundColor Gray Write-Host " Beschermde items: $($v.ProtectedItems)" -ForegroundColor White Write-Host " Items met test: $($v.ItemsWithRecentRestore) ($p`%)" -ForegroundColor White if ($v.LastRestoreJobTime) { Write-Host " Laatste hersteljob: $($v.LastRestoreJobTime)" -ForegroundColor Gray } else { Write-Host " Laatste hersteljob: geen herstel binnen de gekozen periode" -ForegroundColor Yellow } } if ($percentage -ge 75) { Write-Host "`nResultaat: veel workloads zijn recent getest; blijf de planning volgen en documenteer alle bevindingen in het ISMS." -ForegroundColor Green } elseif ($percentage -ge 40) { Write-Host "`nResultaat: slechts een deel van de workloads is recent getest; plan extra herstelproeven voor kritieke systemen." -ForegroundColor Yellow } else { Write-Host "`nResultaat: weinig tot geen workloads zijn recent getest; dit vormt een significant continuïteitsrisico. Plan op korte termijn gerichte Disaster Recovery tests." -ForegroundColor Red } return $summary } function Invoke-Implementation { <# .SYNOPSIS Ondersteunt het voorbereiden van een gestructureerd DR-testprogramma. .DESCRIPTION Deze functie voert geen destructieve wijzigingen uit, maar genereert een overzicht dat gebruikt kan worden als basis voor de testkalender. #> [CmdletBinding()] param() Write-Host "`n[INFO] Implementation-modus voert een uitgebreide monitoring uit als basis voor de DR-testkalender." -ForegroundColor Cyan $summary = Invoke-Monitoring -DaysLookback 365 Write-Host "`nGebruik dit overzicht om per kluis en workload vast te leggen welke systemen prioriteit hebben voor de volgende hersteltests." -ForegroundColor Cyan return $summary } function Invoke-Remediation { <# .SYNOPSIS Identificeert workloads zonder recente tests en ondersteunt remediatie. .DESCRIPTION Deze functie markeert kluizen en workloads met achterstallige tests en geeft aanbevelingen, maar brengt geen wijzigingen aan in Azure. #> [CmdletBinding()] param( [int]$DaysLookback = 365 ) Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName - Remediatie analyse" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan $summary = Get-DrTestStatus -DaysLookback $DaysLookback $backlogVaults = $summary.Vaults | Where-Object { $_.ProtectedItems -gt 0 -and $_.ItemsWithRecentRestore -eq 0 } if (-not $backlogVaults) { Write-Host "Alle gevonden kluizen hebben ten minste enkele workloads met recente hersteltests binnen $DaysLookback dagen." -ForegroundColor Green return $summary } Write-Host "De volgende kluizen bevatten beschermde workloads zonder recente hersteltests:" -ForegroundColor Yellow foreach ($v in $backlogVaults) { Write-Host " - $($v.VaultName) (RG: $($v.ResourceGroupName), items: $($v.ProtectedItems))" -ForegroundColor Yellow } Write-Host "`nAanbevolen vervolgstappen:" -ForegroundColor Cyan Write-Host " 1. Bepaal per kluis welke workloads bedrijfskritisch zijn en leg RPO- en RTO-doelen vast indien dit nog niet is gebeurd." -ForegroundColor White Write-Host " 2. Plan per kritieke workload minimaal één herstelproef in de komende 3 tot 6 maanden." -ForegroundColor White Write-Host " 3. Werk runbooks bij op basis van de testresultaten en registreer alle bevindingen in het ISMS." -ForegroundColor White Write-Host " 4. Bespreek de voortgang in het security- en continuïteitsoverleg totdat alle achterstanden zijn weggewerkt." -ForegroundColor White return $summary } try { Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName" -ForegroundColor Cyan Write-Host "Nederlandse Baseline voor Veilige Cloud" -ForegroundColor Cyan Write-Host "========================================`n" -ForegroundColor Cyan if ($Monitoring) { Invoke-Monitoring | Out-Null } elseif ($Implementation) { Invoke-Implementation | Out-Null } elseif ($Remediation) { Invoke-Remediation | Out-Null } else { # Standaard: korte monitoring-uitvoer Invoke-Monitoring -DaysLookback 90 | Out-Null } } catch { Write-Error ("Fout tijdens uitvoering van {0}: {1}" -f $PolicyName, $_) exit 1 } finally { Write-Host "`n========================================`n" -ForegroundColor Cyan }

Risico zonder implementatie

Risico zonder implementatie
High: Zonder periodiek geteste herstelprocedures blijft onduidelijk of kritieke Azure-workloads binnen acceptabele tijd kunnen worden hersteld na een grote verstoring. Dit vergroot het risico op langdurige uitval, verlies van essentiële gegevens, niet-naleving van BIO, NIS2 en ISO 27001, en ernstige reputatieschade wanneer publieke diensten of wettelijke processen stilvallen.

Management Samenvatting

Disaster Recovery Testing in Azure vertaalt back-up- en replicatieconfiguraties naar aantoonbaar herstelvermogen. Richt een jaarlijks testprogramma in, gebruik Recovery Services-kluizen en scripts om resultaten te meten, en koppel bevindingen rechtstreeks aan verbetermaatregelen. Daarmee voldoet de organisatie aan de Nederlandse Baseline voor Veilige Cloud en kan zij bestuur en toezichthouders overtuigend laten zien dat continuïteit daadwerkelijk is geborgd.