Azure Site Recovery Geconfigureerd Voor Disaster Recovery

Zonder een goed geconfigureerd Azure Site Recovery-systeem lopen organisaties het risico op langdurige dienstuitval bij regionale calamiteiten, datacenterstoringen, cyberaanvallen of natuurrampen. Wanneer een primaire regio volledig uitvalt door bijvoorbeeld een ransomware-aanval die alle systemen versleutelt, een datacenterbrand die fysieke hardware vernietigt, of een natuurramp die de volledige infrastructuur onbereikbaar maakt, kunnen organisaties zonder Site Recovery dagen of weken nodig hebben om systemen handmatig te herstellen vanaf backups. Dit leidt niet alleen tot bestuurlijke verantwoordelijkheid en mogelijke boetes van toezichthouders, maar ook tot verlies van vertrouwen bij burgers en reputatieschade die jaren kan aanhouden. Voor Nederlandse overheidsorganisaties die essentiële diensten leveren zoals zaaksystemen, basisregistraties of patiëntportalen, kan dit leiden tot het volledig stilvallen van dienstverlening waarbij burgers geen toegang hebben tot kritieke services. Bovendien verlangen wettelijke kaders zoals de BIO-paragraaf 12.03, ISO 27001 control A.8.13, AVG artikel 32 en de aankomende NIS2-richtlijn dat organisaties aantoonbaar in staat zijn om beschikbaarheid en integriteit snel te herstellen na een incident. Zonder een functionerend Site Recovery-systeem mislukt iedere audit op deze onderdelen, wat kan resulteren in aanwijzingen, dwangsommen of zelfs intrekking van vergunningen. Denk aan scenario's waarbij een kritieke mGBA-omgeving of een zaaksysteem van een gemeente wordt getroffen door een zero-day exploit die alle primaire systemen compromitteert: zonder Site Recovery moet de dienstverlening mogelijk worden stilgelegd en ontstaat een kettingreactie richting burgerzaken, vergunningverlening en toezicht. Door geautomatiseerde replicatie en regelmatige failover-tests op te nemen in de reguliere releasekalender bouwt men een cultuur op waarin veerkracht net zo belangrijk is als functionaliteit.

Implementatie

Een solide Azure Site Recovery-configuratie start met het ontwerpen van een Recovery Services-kluis die fungeert als centrale orchestrator voor alle replicatie-operaties, waarbij de kluis zich bevindt in de doelsite-regio en is geconfigureerd met de juiste opslagredundantie en encryptie-instellingen. Vervolgens wordt een replicatiebeleid gedefinieerd dat bepaalt hoe vaak replicatie plaatsvindt, welke crash-consistentie of app-consistentie wordt gegarandeerd, en welke retentie-instellingen van toepassing zijn voor recovery points. Daarna worden virtuele machines geconfigureerd voor replicatie door de Site Recovery-agent te installeren, replicatie-instellingen te definiëren zoals doelsite, opslagaccount en netwerkconfiguratie, en de initiële replicatie te starten die alle data naar de secundaire locatie kopieert. Tot slot worden netwerkconfiguraties aangepast zodat failover-VM's automatisch in het juiste virtuele netwerk worden geplaatst met de juiste IP-adressen, worden failover-plannen gedefinieerd voor multi-VM applicaties, en worden regelmatige test failovers uitgevoerd om te verifiëren dat herstel daadwerkelijk werkt. Organisaties die volwassen willen werken, leggen deze stappen vast in hun changeproces, automatiseren controles met PowerShell of Azure Automation, en publiceren rapportages in hun service management-portaal, zodat bestuurders realtime inzicht hebben in de staat van hun disaster recovery-capaciteiten. Hierdoor ontstaat een sluitende keten van preventie, detectie en herstel die naadloos aansluit op de Nederlandse Baseline voor Veilige Cloud.

• Open het Azure-portaal, navigeer naar het gedeelte Resource maken en kies Recovery Services-kluis zodat de dienst automatisch de juiste resource providers registreert voor Site Recovery-functionaliteit.
• Gebruik een consistente naam zoals SiteRecoveryVault-WestEurope-prod zodat dashboards, scripts en auditrapporten de resource onmiddellijk kunnen herkennen.
• Selecteer de doelsite-regio waar failover-VM's zullen worden opgestart; dit is doorgaans de gekoppelde regio van de primaire regio voor optimale beschikbaarheid en compliance met datasoevereiniteit-vereisten.
• Kies voor geo-redundante opslag wanneer kritieke workloads worden beschermd, zodat replicatiedata synchroon wordt gerepliceerd naar de paired region en regionale calamiteiten kunnen worden opgevangen zonder extra configuratie.
• Configureer versleuteling met door de klant beheerde sleutels (CMK) indien vereist door het dataclassificatiebeleid, zodat de organisatie volledige controle heeft over de encryptiesleutels en voldoet aan strikte compliance-eisen.
• Koppel de kluis aan een Log Analytics-werkruimte zodat replicatie-events, failover-operaties en compliance-status kunnen worden gemonitord en geanalyseerd.
• Voltooi het aanmaken van de kluis en wacht totdat de deployment-succesmelding verschijnt; documenteer aansluitend de resource-id en beheerderstoewijzingen in het change record.
• Open binnen de Recovery Services-kluis het onderdeel Site Recovery infrastructure en kies Replication policies zodat de wizard de juiste parameters beschikbaar maakt.
• Selecteer het juiste resourcetype (bijvoorbeeld Azure-to-Azure, VMware-to-Azure, Hyper-V-to-Azure) zodat de specifieke replicatie-opties automatisch worden geconfigureerd.
• Geef het beleid een duidelijke naam, bijvoorbeeld Azure-to-Azure-15min-RPO-prod, zodat het direct duidelijk is welk replicatieprofiel wordt toegepast en voor welke omgeving het bedoeld is.
• Configureer de replicatiefrequentie op basis van de RPO-vereisten: 30 seconden voor kritieke workloads met zeer lage RPO, 5 minuten voor standaard productieomgevingen, of 15 minuten voor minder kritieke systemen. Lagere frequenties zorgen voor betere RPO maar verhogen de netwerk- en opslagkosten.
• Kies crash-consistentie voor algemene workloads of app-consistentie voor databases en applicaties die transactionele integriteit vereisen. App-consistentie zorgt voor data-integriteit maar veroorzaakt extra overhead en kan de replicatiefrequentie beïnvloeden.
• Definieer retentie voor recovery points zodat meerdere herstelopties beschikbaar zijn; configureer minimaal 24 uur retentie voor dagelijkse recovery-scenario's en overweeg langere retentie voor compliance-doeleinden.
• Activeer multi-VM consistency indien applicaties meerdere VM's omvatten, zodat alle VM's samen worden gerepliceerd en failover synchroon plaatsvindt voor consistente applicatiestatus.
• Sla het beleid op en documenteer de versie en goedkeuringsdatum zodat audits kunnen verifiëren dat de instelling intentioneel is gekozen.
• Open de gewenste virtuele machine in het Azure-portaal of via Azure CLI en navigeer naar het onderdeel Operations > Disaster recovery zodat de replicatiestatus in één oogopslag zichtbaar is.
• Activeer de replicatiefunctie, selecteer de eerder ingerichte Recovery Services-kluis en controleer dat de juiste regio en abonnement worden weergegeven zodat er geen kruissubscriptie wordt gebruikt.
• Kies de doelsite-regio, het doelopslagaccount en het doelnetwerk zodat failover-VM's automatisch in de juiste omgeving worden geplaatst met de juiste netwerkconfiguratie.
• Koppel het replicatiebeleid dat eerder is geconfigureerd en verifieer de replicatiefrequentie, consistentie-instellingen en retentie-informatie voordat je bevestigt.
• Start de initiële replicatie en monitor deze taak totdat er een geslaagde status verschijnt; noteer eventuele waarschuwingen over netwerkbandbreedte, opslagcapaciteit of agent-status.
• Controleer in het overzicht Replicated items of de VM expliciet wordt vermeld, inclusief het gekoppelde beleid, de replicatiestatus en de laatste replicatietijd, en herhaal dit voor elke productie-VM.
• Gebruik het PowerShell-script of Azure Policy-rapportages om wekelijks te bevestigen dat nieuwe VM's automatisch in het replicatiebeleid zijn opgenomen en dat verwijderde workloads netjes uit de configuratie zijn verwijderd.
• Kies een test failover-scenario en selecteer een recovery point met de juiste consistentieklasse zodat zeker is dat de data aansluit bij het testscenario.
• Bepaal of de organisatie een volledige applicatie wil testen, specifieke componenten wil valideren of een netwerkconfiguratie wil verifiëren; leg de risico's van iedere optie vooraf vast.
• Voer de test failover uit naar een geïsoleerd testnetwerk, voer vervolgens functionele tests uit samen met applicatie-eigenaren en verwijder de test-VM's zodra alle resultaten zijn gedocumenteerd.
• Leg iedere stap vast in een runbook inclusief schermopnamen, PowerShell-commando's en verwachte doorlooptijden zodat het crisisteam dit kan volgen zonder extra uitleg.
• Plan minimaal per kwartaal een scenario-gestuurde test waarbij ook afhankelijkheden zoals databases, identiteitsproviders en externe services worden meegenomen; rapporteer bevindingen aan het CISO-office.

Vereisten

1. Een actief Azure-abonnement met toegang tot beide regio's die betrokken zijn bij replicatie is noodzakelijk, waarbij de primaire regio de bronomgeving bevat en de secundaire regio de doelsite vormt voor failover-scenario's. Het abonnement moet voldoende quota hebben voor compute, storage en netwerkresources in beide regio's, zodat bij een failover alle workloads kunnen worden opgestart zonder resourcebeperkingen. Leg in het abonnement een beheerder van dienst vast en zorg dat change- en incidentprocessen bekend zijn met het bestaan van de Site Recovery-configuratie. Documenteer bovendien welke resourcegroepen en workloads onderdeel zijn van het replicatiebereik, zodat audits eenvoudig kunnen controleren of de juiste scope wordt beschermd, en stem dit overzicht af met het assetregister en het Business Continuity Plan.
2. Een Recovery Services-kluis in de doelsite-regio moet vooraf worden ingericht met de juiste opslagredundantie, versleuteling en identity- en accessmanagement-instellingen zodat alle replicatie-operaties kunnen worden geaccepteerd zonder aanvullende configuratiewijzigingen. Beschrijf in het dataclassificatie-register waarom voor LRS, ZRS of GRS is gekozen en laat security officers meekijken naar de gebruikte encryptiesleutels. Koppel de kluis aan Log Analytics zodat beheerders real-time zicht houden op replicatiestatus, failover-events en policy-afwijkingen. De kluis moet worden geconfigureerd met customer-managed keys indien vereist door compliance-vereisten, waarbij Key Vault-integratie correct moet zijn ingesteld.
3. Functionele en technische beheerders hebben Contributor- of hoger rechten nodig op zowel de bron- als doelresources en de Recovery Services-kluis, aangevuld met Reader-rollen voor auditors, zodat configuraties kunnen worden gewijzigd terwijl scheiding van functies behouden blijft. Richt privileged access workstations in voor deze handelingen en log alle beheeracties via Azure Activity Logs en Defender for Cloud. Maak gebruik van just-in-time toegangsverlening zodat langdurige permanente rechten worden voorkomen. Voor on-premises naar Azure replicatie zijn bovendien rechten nodig op de on-premises vCenter of Hyper-V hosts waar de bron-VM's draaien.
4. Er moet een formeel goedgekeurd disaster recovery-plan bestaan waarin RTO- en RPO-waarden per workload zijn beschreven, failover-procedures zijn gedocumenteerd, rollen en verantwoordelijkheden zijn vastgelegd, en testfrequenties zijn bepaald. Het plan hoort onderdeel uit te maken van het Business Continuity Plan en moet minimaal jaarlijks worden herzien of direct na een incident. Gebruik een beslisboom voor uitzonderingen zodat afwijkingen altijd schriftelijk worden goedgekeurd. Het plan moet ook netwerkarchitectuur beschrijven, inclusief IP-adresbereiken voor failover-scenario's en DNS-configuraties die moeten worden aangepast bij een failover.
5. Netwerkconfiguratie moet vooraf zijn ontworpen voor beide regio's, waarbij virtuele netwerken, subnetten, netwerkbeveiligingsgroepen en route tables zijn voorbereid in de doelsite-regio zodat failover-VM's direct kunnen worden opgestart met de juiste netwerkconnectiviteit. IP-adresbereiken moeten uniek zijn tussen regio's of er moet een mechanisme zijn voor IP-adreswijziging tijdens failover. Documenteer welke netwerkresources worden gebruikt en hoe deze worden beheerd tijdens normale operaties versus failover-scenario's. Overweeg het gebruik van Azure Site Recovery netwerk mapping voor automatische netwerkconfiguratie tijdens failover.
6. Financiële dekking is nodig voor opslag, compute en netwerkverkeer kosten in beide regio's; reken op circa €0,10 per GB per maand aan replicatie-opslag, aangevuld met compute-kosten voor failover-VM's en data transfer-kosten voor continue replicatie, zodat budgethouders niet verrast worden door groei in workloads. Neem deze bedragen op in meerjarenramingen en koppel ze aan cloudkostenbeheer zodat afdelingen tijdig bijsturen. Houd rekening met kosten voor test failovers waarbij tijdelijke resources worden opgestart voor validatie-doeleinden.
7. Het architectuurteam moet per workload vastleggen hoeveel gegevensverlies acceptabel is (Recovery Point Objective) en hoe snel een systeem terug online moet zijn (Recovery Time Objective), zodat replicatie-instellingen en failover-procedures aansluiten op bedrijfscontinuïteitsdoelstellingen. Laat deze waarden bevestigen door de proceseigenaar en leg ze vast in het Business Continuity Plan zodat er geen discussie ontstaat tijdens een incident. Voor kritieke workloads met lage RPO-waarden moet app-consistentie worden geconfigureerd, wat extra overhead veroorzaakt maar zorgt voor data-integriteit.
8. Organisaties hebben een gedocumenteerd testplan nodig waarin minimaal per kwartaal een representatieve failover wordt gepland, inclusief rollen, testscenario's en evaluatiecriteria, zodat management bewijs krijgt dat disaster recovery werkelijk werkt. Gebruik een lessons-learned-sjabloon en koppel verbetermaatregelen aan werkorders of user stories. Neem ook ketentesten op waarin afhankelijkheden zoals databases, identiteitsproviders en externe services worden gecontroleerd. Test zowel geplande failovers voor onderhoud als niet-geplande failovers voor calamiteitsscenario's.
9. Monitoring- en meldingsmechanismen moeten vooraf worden gekoppeld aan het SOC of de 24/7-operators; elke replicatiefout, RPO-overschrijding of failover-event moet automatisch een waarschuwing genereren die opgevolgd wordt binnen de afgesproken service levels. Definieer duidelijke escalatieroutes en meet de reactietijd zodat bestuurders kunnen vertrouwen op snelle interventies. Documenteer daarnaast welke meldingen direct rapportageplichtig zijn richting toezichthouders. Configureer Azure Monitor alerts voor replicatie health, RPO compliance en failover readiness.

Implementatie

Gebruik PowerShell-script disaster-recovery-configured.ps1 (functie Invoke-Implementation) – Gebruik dit PowerShell-script om op schaal Recovery Services-kluizen, replicatiebeleid en VM-replicatieconfiguraties uit te rollen binnen meerdere abonnementen met uniforme logging en foutafhandeling..

STAP 1 beschrijft het zorgvuldig inrichten van een Recovery Services-kluis die als centrale orchestrator fungeert voor alle Site Recovery-operaties. Kies een duidelijke naamgevingsconventie, bepaal of lokale redundantie volstaat of dat geo-redundante opslag noodzakelijk is, en documenteer de gekozen regio zodat iedere beheerder direct ziet voor welke workloads de kluis bedoeld is. De kluis moet worden geconfigureerd met customer-managed keys indien vereist door compliance-vereisten, waarbij Key Vault-integratie correct moet zijn ingesteld.

1. Open het Azure-portaal, navigeer naar het gedeelte Resource maken en kies Recovery Services-kluis zodat de dienst automatisch de juiste resource providers registreert voor Site Recovery-functionaliteit.
2. Gebruik een consistente naam zoals SiteRecoveryVault-WestEurope-prod zodat dashboards, scripts en auditrapporten de resource onmiddellijk kunnen herkennen.
3. Selecteer de doelsite-regio waar failover-VM's zullen worden opgestart; dit is doorgaans de gekoppelde regio van de primaire regio voor optimale beschikbaarheid en compliance met datasoevereiniteit-vereisten.
4. Kies voor geo-redundante opslag wanneer kritieke workloads worden beschermd, zodat replicatiedata synchroon wordt gerepliceerd naar de paired region en regionale calamiteiten kunnen worden opgevangen zonder extra configuratie.
5. Configureer versleuteling met door de klant beheerde sleutels (CMK) indien vereist door het dataclassificatiebeleid, zodat de organisatie volledige controle heeft over de encryptiesleutels en voldoet aan strikte compliance-eisen.
6. Koppel de kluis aan een Log Analytics-werkruimte zodat replicatie-events, failover-operaties en compliance-status kunnen worden gemonitord en geanalyseerd.
7. Voltooi het aanmaken van de kluis en wacht totdat de deployment-succesmelding verschijnt; documenteer aansluitend de resource-id en beheerderstoewijzingen in het change record.

STAP 2 bestaat uit het opstellen van een replicatiebeleid dat de frequentie, consistentie en retentie van replicatie bepaalt. Dit beleid vormt de contractuele afspraak tussen beveiliging, operations en de applicatie-eigenaar en moet aantoonbaar aansluiten bij de afgesproken RPO en RTO.

1. Open binnen de Recovery Services-kluis het onderdeel Site Recovery infrastructure en kies Replication policies zodat de wizard de juiste parameters beschikbaar maakt.
2. Selecteer het juiste resourcetype (bijvoorbeeld Azure-to-Azure, VMware-to-Azure, Hyper-V-to-Azure) zodat de specifieke replicatie-opties automatisch worden geconfigureerd.
3. Geef het beleid een duidelijke naam, bijvoorbeeld Azure-to-Azure-15min-RPO-prod, zodat het direct duidelijk is welk replicatieprofiel wordt toegepast en voor welke omgeving het bedoeld is.
4. Configureer de replicatiefrequentie op basis van de RPO-vereisten: 30 seconden voor kritieke workloads met zeer lage RPO, 5 minuten voor standaard productieomgevingen, of 15 minuten voor minder kritieke systemen. Lagere frequenties zorgen voor betere RPO maar verhogen de netwerk- en opslagkosten.
5. Kies crash-consistentie voor algemene workloads of app-consistentie voor databases en applicaties die transactionele integriteit vereisen. App-consistentie zorgt voor data-integriteit maar veroorzaakt extra overhead en kan de replicatiefrequentie beïnvloeden.
6. Definieer retentie voor recovery points zodat meerdere herstelopties beschikbaar zijn; configureer minimaal 24 uur retentie voor dagelijkse recovery-scenario's en overweeg langere retentie voor compliance-doeleinden.
7. Activeer multi-VM consistency indien applicaties meerdere VM's omvatten, zodat alle VM's samen worden gerepliceerd en failover synchroon plaatsvindt voor consistente applicatiestatus.
8. Sla het beleid op en documenteer de versie en goedkeuringsdatum zodat audits kunnen verifiëren dat de instelling intentioneel is gekozen.

STAP 3 richt zich op het daadwerkelijk configureren van replicatie voor virtuele machines. Dit omvat zowel portaalhandelingen als automatische controles via scripts, zodat geen enkele productie-VM per ongeluk buiten de replicatiestrategie valt.

Gebruik PowerShell-script disaster-recovery-configured.ps1 (functie Invoke-Monitoring) – Het script biedt een geautomatiseerde controle op replicatiestatus, RPO-compliance en failover-readiness per VM en publiceert de resultaten naar het monitoringdashboard..

1. Open de gewenste virtuele machine in het Azure-portaal of via Azure CLI en navigeer naar het onderdeel Operations > Disaster recovery zodat de replicatiestatus in één oogopslag zichtbaar is.
2. Activeer de replicatiefunctie, selecteer de eerder ingerichte Recovery Services-kluis en controleer dat de juiste regio en abonnement worden weergegeven zodat er geen kruissubscriptie wordt gebruikt.
3. Kies de doelsite-regio, het doelopslagaccount en het doelnetwerk zodat failover-VM's automatisch in de juiste omgeving worden geplaatst met de juiste netwerkconfiguratie.
4. Koppel het replicatiebeleid dat eerder is geconfigureerd en verifieer de replicatiefrequentie, consistentie-instellingen en retentie-informatie voordat je bevestigt.
5. Start de initiële replicatie en monitor deze taak totdat er een geslaagde status verschijnt; noteer eventuele waarschuwingen over netwerkbandbreedte, opslagcapaciteit of agent-status.
6. Controleer in het overzicht Replicated items of de VM expliciet wordt vermeld, inclusief het gekoppelde beleid, de replicatiestatus en de laatste replicatietijd, en herhaal dit voor elke productie-VM.
7. Gebruik het PowerShell-script of Azure Policy-rapportages om wekelijks te bevestigen dat nieuwe VM's automatisch in het replicatiebeleid zijn opgenomen en dat verwijderde workloads netjes uit de configuratie zijn verwijderd.

STAP 4 valideert dat replicatie niet alleen actief is, maar ook daadwerkelijk werkt door regelmatige test failovers uit te voeren. Zonder periodieke tests blijft replicatie een papieren zekerheid en worden fouten in netwerkconfiguraties, OS-drivers of applicatiedata vaak pas ontdekt tijdens een crisis.

1. Kies een test failover-scenario en selecteer een recovery point met de juiste consistentieklasse zodat zeker is dat de data aansluit bij het testscenario.
2. Bepaal of de organisatie een volledige applicatie wil testen, specifieke componenten wil valideren of een netwerkconfiguratie wil verifiëren; leg de risico's van iedere optie vooraf vast.
3. Voer de test failover uit naar een geïsoleerd testnetwerk, voer vervolgens functionele tests uit samen met applicatie-eigenaren en verwijder de test-VM's zodra alle resultaten zijn gedocumenteerd.
4. Leg iedere stap vast in een runbook inclusief schermopnamen, PowerShell-commando's en verwachte doorlooptijden zodat het crisisteam dit kan volgen zonder extra uitleg.
5. Plan minimaal per kwartaal een scenario-gestuurde test waarbij ook afhankelijkheden zoals databases, identiteitsproviders en externe services worden meegenomen; rapporteer bevindingen aan het CISO-office.

monitoring

Gebruik PowerShell-script disaster-recovery-configured.ps1 (functie Invoke-Monitoring) – Automatiseer dagelijkse controles en integreer de resultaten met SIEM- of ITSM-workflows zodat afwijkingen in replicatiestatus altijd een opvolgtaak genereren..

1. Controleer dagelijks in het dashboard van de Recovery Services-kluis of alle geconfigureerde VM's succesvol repliceren en onderzoek afwijkingen direct zodat RPO-doelstellingen nooit worden overschreden. Registreer elke bevinding in het ITSM-systeem en sluit deze pas wanneer de volgende replicatiecyclus bewezen succesvol is uitgevoerd. Documenteer de oorzaak-analyse en deel deze met ontwikkelteams zodat structurele fouten al tijdens de releaseplanning worden opgelost. Gebruik tagging om kritieke systemen prioriteit te geven wanneer meerdere incidenten tegelijk optreden en leg per incident vast welke lessons learned zijn toegepast.
2. Stel waarschuwingen in via Azure Monitor, e-mail en Microsoft Teams zodat de piketdienst onmiddellijk een melding ontvangt bij replicatiefouten, RPO-overschrijdingen of failover-events en verbind opvolgacties aan duidelijke runbooks. Test de meldingen maandelijks door een gecontroleerde fout te simuleren en verifieer dat alle communicatiestromen werken. Verbreed de alerting met webhook-integraties richting SIEM of SOAR zodat automatisering direct herstelacties kan starten. Evalueer per kwartaal de drempelwaarden en zorg dat deze aansluiten bij veranderende workloads en RPO-vereisten.
3. Gebruik wekelijks het overzicht Replicated items of een geautomatiseerd PowerShell-rapport om te bevestigen dat iedere productie-VM daadwerkelijk aan een replicatiebeleid is gekoppeld en corrigeer afwijkingen voordat nieuwe releases live gaan. Combineer dit met Azure Resource Graph zodat ook shadow-IT resources zichtbaar worden. Publiceer de resultaten in een gedeeld dashboard zodat productowners inzicht hebben in de naleving van hun applicaties. Neem afwijkingen op in het risicoregister totdat aantoonbaar herstel is uitgevoerd.
4. Controleer maandelijks of replicatie-instellingen overeenkomen met de afgesproken RPO- en RTO-waarden en of recovery points volgens planning beschikbaar blijven zodat datahygiëne en compliance aantoonbaar geborgd blijven. Documenteer eventuele afwijkingen inclusief compensatiemaatregelen en zorg dat de CISO deze aftekent. Houd een overzicht bij van alle uitzonderingen inclusief einddatum en verantwoordelijke zodat tijdelijke maatregelen niet permanent blijven bestaan. Werk dit overzicht bij in het ISMS zodat auditors een directe referentie hebben.
5. Monitor het opslagverbruik van replicatiedata en vergelijk dit met begrotingen; significante groei kan wijzen op foutieve policies of ongewenste dataretentie en moet daarom direct worden besproken met finance en capacity management. Visualiseer trends in Power BI zodat besluitvorming over lifecyclemanagement wordt ondersteund. Stel drempelwaarden in die automatisch een kostendossier openen wanneer het verbruik een afgesproken percentage overschrijdt. Neem hier ook voorspellingen in op zodat toekomstige investeringen tijdig kunnen worden aangevraagd.
6. Plan ieder kwartaal een integraal failover-scenario waarbij techniek, documentatie en communicatie worden getest; leg bevindingen vast en voer verbeteringen direct door in beleid en scripts. Betrek naast IT ook proceseigenaren, communicatieadviseurs en crisiscoördinatoren om de volledige keten te oefenen. Wissel scenario's af, bijvoorbeeld regionale uitval, ransomware of datacenterstoring, zodat teams flexibel blijven. Rapporteer doorlooptijden en herstelpercentages aan het directieteam.
7. Gebruik Azure Policy en Microsoft Defender for Cloud-aanbevelingen om realtime te meten of nieuwe of gewijzigde VM's voldoen aan de verplichte replicatiestandaard en lever rapportages aan het auditteam. Koppel deze inzichten aan het risicoregister en bespreek structurele afwijkingen in het beveiligingsoverleg. Vertaal de bevindingen naar concrete verbeteracties met eigenaar, deadline en meetmethode. Zorg dat audittrail-gegevens minimaal zeven jaar beschikbaar blijven voor forensisch onderzoek en controleer jaarlijks of de rapportage-indeling nog aansluit bij auditwensen.

Compliance en Auditing

Azure Site Recovery-configuraties zijn geen optionele luxe maar een harde compliance-eis binnen vrijwel alle relevante normenkaders. De CIS Azure Foundations Benchmark schrijft in control 7.3 voor dat organisaties disaster recovery-capaciteiten moeten hebben, waarbij Azure Site Recovery een bewezen oplossing vormt voor VM-replicatie en failover. De Baseline Informatiebeveiliging Overheid (BIO) concretiseert dit in hoofdstuk 12.03 door te eisen dat organisaties maatregelen treffen voor bedrijfscontinuïteit en herstel na incidenten, waarbij replicatie naar een secundaire locatie expliciet wordt genoemd als best practice. ISO 27001:2022 control A.8.13 benadrukt bovendien dat organisaties niet alleen backups moeten maken, maar ook procedures moeten hebben voor snel herstel, waarbij Site Recovery de technische implementatie vormt van deze vereisten. De aankomende NIS2-richtlijn, artikel 21, verplicht aanbieders van essentiële en belangrijke diensten om maatregelen te treffen die de continuïteit garanderen, waarbij herstelvermogen na cyberincidenten expliciet wordt genoemd en waarbij replicatie naar een secundaire regio een bewezen aanpak vormt. Ook de AVG (artikel 32) eist dat verwerkingsverantwoordelijken technische en organisatorische maatregelen treffen om de beschikbaarheid en veerkracht van systemen te borgen; zonder functionerende replicatie is snel herstel van persoonsgegevens onmogelijk en voldoet men niet aan deze bepaling. Sectorale normen zoals ENSIA, DigiD-beveiligingseisen en Norea IT-auditstandaarden verwijzen expliciet naar gedocumenteerde disaster recovery-procedures en regelmatige tests. In audits vragen toezichthouders standaard naar replicatiestatus, failover-testverslagen, RPO- en RTO-metingen en overzichten van beschermde workloads. Een organisatie die deze bewijslast niet paraat heeft, loopt risico op aanwijzingen, dwangsommen of zelfs intrekking van vergunningen en subsidies. Aangezien de Nederlandse publieke sector steeds meer afhankelijk is van digitale dienstverlening, kan het niet aantonen van functionerende Azure Site Recovery-configuraties leiden tot bestuurlijke maatregelen, politieke verantwoordelijkheid en verlies van vertrouwen bij burgers. Het inrichten, testen en monitoren van Azure Site Recovery is daarmee een onmisbare bouwsteen om naleving van wet- en regelgeving te waarborgen. Zorg daarom dat ieder replicatiebeleid wordt goedgekeurd door het informatiebeveiligingsberaad, dat uitzonderingen schriftelijk worden vastgelegd en dat evidence minimaal zeven jaar wordt bewaard. Combineer technische logging met verklaringen van proceseigenaren, zodat auditors zowel harde cijfers als managementcommitment zien. Leg per failover-test vast welke scenario's zijn geoefend, welke KPI's zijn gehaald en welke verbeteracties zijn geformuleerd, zodat trendanalyse over meerdere jaren mogelijk wordt. Maak gebruik van Azure Policy compliance-rapporten en exporteer deze naar het ISMS, zodat auditteams real-time inzicht hebben in de status van workloads. Beschrijf in de auditkalender welke datasets wanneer worden aangeleverd en wijs een eigenaar per rapport aan zodat deadlines nooit worden gemist. Houd daarnaast een mapping bij tussen iedere control en de specifieke Azure-resources waarop deze van toepassing is, zodat nieuwe collega's snel begrijpen waar bewijs te vinden is. Plan halfjaarlijkse gesprekken met de interne auditdienst en externe toezichthouders om verwachtingen af te stemmen en te laten zien welke verbeteringen zijn doorgevoerd. Werk tenslotte met control dashboards waarin per eis een status, risiconiveau en verantwoordelijke wordt getoond, zodat bestuurders continu inzicht houden. Voeg indien nodig aanvullende contractuele clausules toe in leveranciersovereenkomsten zodat ook ketenpartners aantoonbaar dezelfde normen volgen en leg deze afspraken vast in het inkoopbeleid. Leg dit geheel vast in het jaarverslag zodat bestuurders publiekelijk verantwoording afleggen. Alleen zo kan men aantonen dat de Nederlandse Baseline voor Veilige Cloud daadwerkelijk in de praktijk wordt gebracht en dat continuïteit en rechtszekerheid aantoonbaar zijn geborgd.

Remediatie

Gebruik PowerShell-script disaster-recovery-configured.ps1 (functie Invoke-Remediation) – Dit script heractiveert ontbrekende replicatie, koppelt VM's opnieuw aan het juiste replicatiebeleid en initieert direct een nieuwe replicatiecyclus zodat naleving snel wordt hersteld. Het remediation-proces voert in één run een volledige ketencontrole uit: detectie van niet-beschermde VM's op basis van tag- of resourcegroepselectie, validatie van rolrechten, herconfiguratie van Recovery Services-kluizen en het opnieuw toewijzen van het juiste replicatieprofiel. Vervolgens wordt de Site Recovery-agent geïnstalleerd of herstart, worden pending replicaties opgeschoond en wordt een nieuwe replicatiecyclus gestart zodat er direct een vers recovery point beschikbaar is voor audits. Het script schrijft uitgebreide logging weg naar zowel het scherm als een Log Analytics-werkruimte, inclusief tijdstempels, betrokken resources, toegepaste policies en eventuele fouten, waardoor forensische traceerbaarheid gewaarborgd blijft. Voor productieomgevingen kan een dry-run vlag worden gebruikt die alleen rapportages genereert; hiermee kunnen beheerders de impact vooraf beoordelen en noodzakelijke onderhoudsvensters plannen. Indien er afhankelijkheden zijn, zoals Key Vault-referenties of privé-eindpunten, controleert de logica automatisch of deze bereikbaar zijn voordat er wijzigingen worden doorgevoerd. Na afloop ontvangt het SOC een samenvattende melding via webhook of e-mail zodat opvolgacties en ticketregistratie direct kunnen plaatsvinden. Het script voorziet bovendien in ingebouwde validatie van RPO- en RTO-parameters, zodat alleen beleid wordt toegepast dat voldoet aan de afgesproken eisen uit de Nederlandse Baseline voor Veilige Cloud. Herstelacties worden standaard voorzien van een change-identificatie die kan worden teruggeleid naar het CAB-dossier, waardoor governance geborgd blijft. Daarnaast worden alle aangebrachte wijzigingen gespiegeld naar een configuration management database zodat asset-, eigenaar- en impactinformatie automatisch wordt bijgewerkt. Bij fouten kan het script per resource een rollback uitvoeren waarbij de vorige configuratie wordt teruggezet en een incidentmelding wordt aangemaakt voor nadere analyse. Met parameterbestanden kunnen organisaties verschillende omgevingen (bijvoorbeeld OT, ontwikkel of productie) met één scriptversie herstellen terwijl specifieke policies, vaults en netwerkrestricties behouden blijven. Dankzij ingebouwde integratie met Azure Monitor kunnen herstelacties metrics publiceren zoals duur van de initiële replicatie, aantal herstelde resources en resterende afwijkingen, wat helpt bij managementrapportages. Het script ondersteunt tevens staged deployments waarbij eerst een subset van resources wordt hersteld en pas na succesvolle validatie de volledige scope wordt geactiveerd. Authenticatie verloopt via beheerde identiteiten of workloadidentiteiten, waardoor geheimen niet lokaal hoeven te worden opgeslagen en het script voldoet aan zero-trustprincipes. Daarnaast bevat het playbook een self-test modus die de belangrijkste functies doorloopt en de resultaten tegen de schema.json-validatieset houdt, zodat updates van het script eenvoudig gecontroleerd kunnen worden voordat het in productie gebruikt wordt. Voor kritieke workloads biedt het een optionele integratie met het change management-portaal waarbij automatisch een reviewtaak voor de applicatie-eigenaar wordt aangemaakt, inclusief bewijs van de uitgevoerde replicatiecycli. Tot slot kan het script een overzichtsrapport genereren met alle aangepaste resources, gekoppelde policies en nieuwe recovery points, zodat auditors in één document de volledige remedial scope kunnen beoordelen. Desgewenst kan het rapport automatisch aan het ISMS of het ENSIA-portaal worden toegevoegd zodat bewijs direct beschikbaar is voor inspecties. In combinatie met de documentatie bij het script vormt dit een volledig draaiboek voor herstel van niet-conforme replicatiesituaties binnen de context van de Nederlandse Baseline voor Veilige Cloud..

Compliance & Frameworks

• CIS M365: Control 7.3 (L1) - Zorg ervoor dat disaster recovery-capaciteiten zijn geconfigureerd voor kritieke workloads
• BIO: 12.03.01 - Bedrijfscontinuïteit - Disaster recovery verplicht voor kritieke systemen
• ISO 27001:2022: A.8.13 - Information backup - Disaster recovery procedures
• NIS2: Artikel - bedrijfscontinuïteit en disaster recovery

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).

Risico zonder implementatie

Management Samenvatting

Azure Site Recovery levert geautomatiseerde VM-replicatie naar een secundaire regio met beleidsgestuurde RPO, app-consistentie en geautomatiseerde failover. Met een investering van enkele tientallen euro's per VM per maand wordt voldaan aan CIS 7.3, BIO 12.03, ISO 27001 A.8.13, AVG artikel 32 en NIS2. Configureer replicatie voor kritieke workloads, voer kwartaalgewijze failover-tests uit en koppel monitoring aan het SOC om continuïteit te garanderen.

• Implementatietijd: 12 uur
• FTE required: 0.1 FTE