Azure Backup Policies Geconfigureerd Voor Gecontroleerde Retentie En Herstel

Het ontbreken van gestandaardiseerde backup policies leidt tot inconsistente bescherming waarbij sommige workloads overmatig worden geback-upt met onnodige kosten, terwijl andere kritieke systemen onderbeschermd blijven met onvoldoende frequentie of te korte retentieperiodes. Zonder formele policies ontstaat er geen duidelijkheid over welke RPO en RTO waarden worden nagestreefd, waardoor business continuity plannen niet aansluiten op de technische realiteit en bestuurders valse verwachtingen hebben over herstelmogelijkheden na een incident. Het ontbreken van policies maakt het bovendien onmogelijk om op schaal nieuwe resources automatisch te beschermen via Azure Policy of infrastructure-as-code, waardoor beheerders handmatig moeten ingrijpen bij elke nieuwe deployment en de kans op vergeten resources toeneemt. Compliance-eisen zoals BIO, ISO 27001, AVG en NIS2 vereisen aantoonbare en gedocumenteerde backup procedures; zonder policies kunnen auditors niet verifiëren dat alle kritieke data adequaat wordt beschermd en dat retentieperiodes aansluiten bij wettelijke verplichtingen. In het geval van een incident of auditonderzoek ontbreekt het bewijs dat backups intentioneel zijn geconfigureerd volgens een goedgekeurd beleid, wat kan leiden tot bestuurlijke aansprakelijkheid en reputatieschade. Door gestructureerde policies in te richten ontstaat duidelijkheid, herhaalbaarheid en aantoonbaarheid die essentieel zijn voor een volwassen informatiebeveiligingsmanagement.

Implementatie

Azure Backup policies zijn herbruikbare configuratietemplates die de volledige lifecycle van backup-operaties definiëren: de frequentie waarmee herstelpunten worden gemaakt, de retentieperiodes voor dagelijkse, wekelijkse, maandelijkse en jaarlijkse snapshots, en de consistentieniveaus die worden gegarandeerd zoals crash-consistent, application-consistent of file-system-consistent. Policies kunnen worden toegepast op verschillende workload types zoals Azure Virtual Machines, SQL-databases, SAP HANA databases of Azure File Shares, waarbij elke workload type specifieke parameters heeft zoals VSS-integratie voor Windows VM's, SQL-native backup opties voor databases, of netwerkbandbreedtebeperkingen voor grote file shares. Het configureren van policies begint met het definiëren van back-upschema's die aansluiten bij de Recovery Point Objective van de workload, waarbij productieomgevingen doorgaans dagelijkse back-ups vereisen terwijl testomgevingen voldoende hebben aan wekelijkse momentopnamen. Retentie-instellingen moeten worden afgestemd op zowel business requirements als compliance-verplichtingen, waarbij sommige branches zoals gezondheidszorg of financiën langere bewaartermijnen vereisen voor auditdoeleinden. Policies kunnen worden geconfigureerd via het Azure-portaal, Azure CLI, PowerShell of ARM-templates, waardoor ze naadloos passen in infrastructure-as-code workflows en version control. Advanced policy features zoals instant restore, soft delete en immutability kunnen per policy worden geactiveerd om extra bescherming te bieden tegen ransomware-aanvallen die specifiek gericht zijn op het verwijderen van backups. Policies worden gekoppeld aan Recovery Services Vaults en kunnen worden toegewezen aan individuele resources of resourcegroepen, waardoor flexibele en schaalbare bescherming mogelijk is voor organisaties met honderden of duizenden workloads.

Vereisten

Voor het succesvol configureren van Azure Backup policies moeten verschillende technische en organisatorische vereisten worden vervuld voordat de daadwerkelijke policy-definitie kan beginnen. De primaire vereiste is de aanwezigheid van een Recovery Services Vault die als container fungeert voor alle backup policies en de bijbehorende herstelpunten. Deze vault moet worden geconfigureerd met de juiste opslagredundantie-optie zoals Geo-Redundant Storage voor kritieke workloads, waarbij het belangrijk is om te realiseren dat deze keuze later niet meer kan worden gewijzigd zonder alle bestaande backups te verliezen. De vault moet zich bevinden in een regio die past bij de resources die worden beschermd, rekening houdend met datasoevereiniteit-vereisten zoals AVG-verplichtingen die eisen dat data binnen de Europese Unie blijft. Organisaties moeten beschikken over Contributor-rechten op zowel de vault als de resources die worden beschermd, terwijl auditors Reader-rechten nodig hebben om compliance te verifiëren zonder configuratiewijzigingen te kunnen doorvoeren. Het is essentieel dat identity- en accessmanagement correct is geconfigureerd met role-based access control zodat alleen geautoriseerde personen policies kunnen aanpassen, wat voorkomt dat onbedoelde wijzigingen leiden tot verminderde bescherming of onnodige kosten.

Business continuity planning vormt de basis voor effectieve backup policies doordat het Recovery Point Objective en Recovery Time Objective per workload moet worden vastgelegd voordat technische configuratie kan plaatsvinden. Deze doelstellingen bepalen respectievelijk hoeveel gegevensverlies acceptabel is bij een incident en hoeveel tijd er maximaal mag zitten tussen een incident en volledige herstel van de service. Voor productieomgevingen met kritieke dienstverlening zoals zaaksystemen, basisregistraties of patiëntportalen is doorgaans een dagelijkse backup met RPO van maximaal 24 uur noodzakelijk, terwijl voor test- en ontwikkelomgevingen een wekelijkse backup met RPO van 7 dagen vaak volstaat. Het is belangrijk om deze waarden formeel te laten goedkeuren door proceseigenaren en deze vast te leggen in het Business Continuity Plan, zodat er geen discussie ontstaat tijdens een crisis over wat acceptabel is. Organisaties moeten bovendien per workload vastleggen welke dataklasse van toepassing is volgens het dataclassificatie-register, waarbij vertrouwelijke of geheime data langere retentieperiodes vereisen en mogelijk extra beveiligingsmaatregelen zoals immutability of customer-managed keys.

Compliance-vereisten vormen een kritieke driver voor backup policy configuratie omdat verschillende normenkaders specifieke eisen stellen aan retentieperiodes, testfrequenties en bewijsvoering. De Baseline Informatiebeveiliging Overheid schrijft in BIO 12.03 voor dat reservekopieën periodiek, gecontroleerd en beveiligd moeten worden opgeslagen, waarbij organisaties moeten kunnen aantonen dat backups daadwerkelijk functioneren. ISO 27001 control A.8.13 verlangt dat backup procedures zijn gedocumenteerd, getest en regelmatig worden herzien, waarbij verantwoordelijkheden duidelijk moeten zijn verdeeld. De AVG artikel 32 eist technische en organisatorische maatregelen voor beschikbaarheid en veerkracht, waarbij backup policies moeten aantonen dat persoonsgegevens kunnen worden hersteld na een incident. De aankomende NIS2-richtlijn artikel 21 verplicht aanbieders van essentiële en belangrijke diensten om maatregelen te treffen die continuïteit garanderen, inclusief herstelvermogen na cyberincidenten. Sectorale normen zoals de Archiefwet vereisen bovendien dat bepaalde categorieën overheidsdata minimaal 20 jaar worden bewaard voor archiefdoeleinden. Organisaties moeten daarom per datatype vastleggen welke compliance-vereisten van toepassing zijn en deze vertalen naar concrete policy-parameters zoals retentieperiodes en testfrequenties.

Kostenplanning is essentieel voor duurzame backup policies omdat opslag- en instance-kosten exponentieel kunnen groeien bij langere retentieperiodes of hogere backup-frequenties. Opslagkosten bedragen ongeveer €0,05 per GB per maand voor Locally Redundant Storage en €0,10 per GB per maand voor Geo-Redundant Storage, terwijl beschermde instanties tussen €5 en €10 per instantie per maand kosten afhankelijk van het workload type. Voor een middelgrote organisatie met 100 virtuele machines met gemiddeld 200 GB aan backup data per VM en een retentieperiode van 90 dagen, resulteren de maandelijkse kosten in ongeveer €1.000 tot €1.500 voor opslag plus €500 tot €1.000 voor beschermde instanties, waarbij deze bedragen kunnen verdubbelen bij gebruik van GRS of bij langere retentieperiodes. Het is belangrijk om deze kosten op te nemen in IT-budgetten en regelmatig te monitoren om onverwachte kostenstijgingen te voorkomen die kunnen optreden wanneer backup-grootten sneller groeien dan verwacht of wanneer nieuwe resources worden toegevoegd. Organisaties moeten overwegen om incrementele backups te gebruiken waar mogelijk en retentieperiodes te optimaliseren op basis van werkelijke compliance- en business-behoeften, zodat kosten worden geminimaliseerd zonder dat bescherming wordt gecompromitteerd.

Documentatie en governance vormen de basis voor aantoonbare compliance en effectief policy management. Elke backup policy moet worden gedocumenteerd met duidelijke naamgevingsconventies, beschrijvingen van de business rationale, gekoppelde compliance-vereisten en goedgekeurde RPO en RTO waarden. Het is belangrijk om policies te versiebeheren en wijzigingshistorie bij te houden, zodat auditors kunnen verifiëren wanneer en waarom configuraties zijn aangepast. Organisaties moeten een formeel goedkeuringsproces inrichten waarbij nieuwe of gewijzigde policies worden gereviewd door security officers, compliance officers en business stakeholders voordat ze in productie worden genomen. Policies moeten worden gekoppeld aan het risicoregister en het dataclassificatie-register, zodat duidelijk is welke risks worden gemitigeerd en welke dataklassen worden beschermd. Het is essentieel om exception procedures te definiëren voor situaties waarin resources niet kunnen voldoen aan standaard policies, waarbij uitzonderingen schriftelijk moeten worden goedgekeurd en regelmatig moeten worden herzien. Daarnaast moeten organisaties een policy lifecycle management proces inrichten waarbij policies minimaal jaarlijks worden geëvalueerd op effectiviteit, kosten en compliance-relevantie, zodat verouderde configuraties worden opgeschoond en nieuwe requirements worden geïmplementeerd.

Implementatie

Gebruik PowerShell-script backup-policies-configured.ps1 (functie Invoke-Implementation) – Gebruik dit PowerShell-script om op schaal backup policies te creëren, configureren en toewijzen aan resources binnen meerdere Recovery Services Vaults met uniforme logging en foutafhandeling..

De implementatie van Azure Backup policies begint met het analyseren van business requirements en compliance-vereisten om te bepalen welke policy-templates nodig zijn voor verschillende workload types en dataklassen. Organisaties moeten eerst een inventarisatie maken van alle workloads die bescherming vereisen, waarbij per workload wordt vastgelegd welke RPO en RTO waarden van toepassing zijn, welke compliance-vereisten gelden en wat de verwachte data growth is. Deze inventarisatie vormt de basis voor het ontwerpen van policy-templates die herbruikbaar zijn voor vergelijkbare workloads, bijvoorbeeld een template voor kritieke productie-VM's met dagelijkse backups en 90 dagen retentie, een template voor test-VM's met wekelijkse backups en 30 dagen retentie, of een template voor databases met transaction log backups naast volledige backups. Het is belangrijk om policy-namen duidelijk en beschrijvend te maken volgens een naamgevingsconventie zoals Production-Daily-90Days of Test-Weekly-30Days, zodat beheerders direct kunnen zien welke bescherming wordt geboden zonder de volledige configuratie te hoeven openen.

STAP 1 bestaat uit het creëren van policy-templates via het Azure-portaal of PowerShell, waarbij de back-upschema's worden gedefinieerd die aansluiten bij de Recovery Point Objective van de workload. Voor productieomgevingen wordt doorgaans een dagelijks schema aanbevolen waarbij backups worden uitgevoerd buiten kantooruren om de impact op productiesystemen te minimaliseren, bijvoorbeeld om 02:00 uur lokale tijd wanneer gebruikers niet actief zijn en systeembelasting laag is. Testomgevingen kunnen volstaan met wekelijkse backups op bijvoorbeeld zondagavond, terwijl ontwikkelomgevingen mogelijk alleen behoefte hebben aan maandelijkse backups voor archiveringsdoeleinden. Het is belangrijk om rekening te houden met timezone-instellingen en lokale werkpatronen, zodat backups niet plaatsvinden tijdens piekbelasting of geplande onderhoudsvensters. Voor kritieke workloads met hoge change rates kan overwogen worden om meerdere dagelijkse backups te configureren, bijvoorbeeld om 02:00 en 14:00, waarbij de kostenafweging moet worden gemaakt tegen de waarde van meer frequente herstelpunten. Azure Backup ondersteunt flexibele schema's waarbij per dag maximaal één backup kan worden gepland voor VM's en SQL-databases, terwijl voor Azure File Shares meerdere dagelijkse backups mogelijk zijn.

STAP 2 richt zich op het configureren van retentie-instellingen die balanceren tussen compliance-vereisten, business needs en kostenoptimalisatie. Retentie kan worden ingesteld voor verschillende granulariteiten: dagelijkse herstelpunten met typische retentieperiodes van 7 tot 30 dagen voor snelle restore naar recente states, wekelijkse herstelpunten met retentie van 4 tot 12 weken voor maandelijkse recovery-scenario's, maandelijkse herstelpunten met retentie van 6 tot 12 maanden voor kwartaal- en jaar-evaluaties, en jaarlijkse herstelpunten met retentie tot 10 jaar voor langetermijnarchivering en compliance-doeleinden. Voor Nederlandse overheidsorganisaties is het belangrijk om rekening te houden met de Archiefwet die vereist dat bepaalde categorieën data minimaal 20 jaar worden bewaard, waarbij jaarlijkse retentie moet worden geconfigureerd voor minimaal 20 jaar voor archief-relevante workloads. Het is essentieel om retentie-instellingen te documenteren en te koppelen aan specifieke compliance-vereisten, zodat auditors kunnen verifiëren dat policies voldoen aan wettelijke verplichtingen. Organisaties moeten overwegen om incrementele backups te gebruiken in combinatie met retentie, waarbij alleen gewijzigde data wordt opgeslagen na de initiële volledige backup, wat de opslagkosten aanzienlijk reduceert terwijl volledige herstel mogelijk blijft.

STAP 3 omvat het toepassen van policies op resources via het Azure-portaal, PowerShell of Azure Policy voor automatische toewijzing. Policies kunnen worden gekoppeld aan individuele resources, resourcegroepen of via Azure Policy worden toegewezen aan alle nieuwe resources die voldoen aan bepaalde criteria zoals tags of resource types. Het is aanbevolen om Azure Policy te gebruiken voor automatische policy-toewijzing aan nieuwe resources, zodat nieuwe VM's of databases automatisch worden beschermd zonder handmatige interventie, wat voorkomt dat resources per ongeluk buiten de backup-strategie vallen. Policies kunnen worden toegepast via de Recovery Services Vault interface waar beheerders resources kunnen selecteren en de gewenste policy kunnen toewijzen, of via PowerShell waarbij bulk-operations mogelijk zijn voor honderden resources tegelijk. Het is belangrijk om na policy-toewijzing te verifiëren dat de eerste backup succesvol is uitgevoerd en dat de policy daadwerkelijk actief is, wat kan worden gecontroleerd via het Backup Items overzicht in de vault of via PowerShell-scripts. Voor bestaande resources die al een andere policy hebben, moet zorgvuldig worden overwogen of policy-migratie nodig is en wat de impact is op bestaande recovery points, waarbij mogelijk een transitieperiode nodig is waarin beide policies actief blijven.

STAP 4 valideert dat policies correct zijn geconfigureerd en dat resources daadwerkelijk worden beschermd volgens de bedoelde settings. Beheerders moeten per policy verifiëren dat het back-upschema correct is ingesteld door de geplande backup-tijden te controleren en te bevestigen dat deze aansluiten bij de afgesproken RPO. Retentie-instellingen moeten worden gevalideerd door te controleren of dagelijkse, wekelijkse, maandelijkse en jaarlijkse retentie correct zijn geconfigureerd en of deze voldoen aan compliance-vereisten. Het is belangrijk om te verifiëren dat policies daadwerkelijk zijn toegepast op resources door het Backup Items overzicht te raadplegen, waarbij elke resource moet worden vermeld met de gekoppelde policy en de status van de laatste backup. Organisaties moeten PowerShell-scripts of Azure Automation runbooks inzetten voor geautomatiseerde validatie, waarbij dagelijks wordt gecontroleerd of alle verwachte resources een actieve policy hebben en of backups succesvol worden uitgevoerd. Eventuele afwijkingen moeten direct worden onderzocht en gecorrigeerd, waarbij logging plaatsvindt in het ITSM-systeem voor audit-doeleinden. Daarnaast moeten beheerders periodiek testen of recovery daadwerkelijk mogelijk is vanaf de geconfigureerde recovery points, zodat niet alleen de configuratie maar ook de functionaliteit wordt gevalideerd.

Monitoring

Gebruik PowerShell-script backup-policies-configured.ps1 (functie Invoke-Monitoring) – Automatiseer dagelijkse controles op policy-configuratie, policy-toewijzingen en compliance-status, en integreer de resultaten met SIEM- of ITSM-workflows voor proactief beheer..

1. Controleer dagelijks via het Azure-portaal of PowerShell of alle policies correct zijn geconfigureerd en of er geen onbedoelde wijzigingen hebben plaatsgevonden die kunnen leiden tot verminderde bescherming of verhoogde kosten. Monitor policy-parameters zoals backup-schema's, retentie-instellingen en consistentieniveaus om te verifiëren dat deze overeenkomen met de goedgekeurde configuratie. Stel waarschuwingen in via Azure Monitor die automatisch een melding genereren wanneer policies worden gewijzigd, zodat beheerders direct kunnen ingrijpen bij ongeautoriseerde aanpassingen. Documenteer alle policy-wijzigingen in een changelog inclusief datum, tijd, gebruiker, oude en nieuwe waarden, en de business rationale, zodat auditors kunnen verifiëren dat wijzigingen intentioneel en goedgekeurd zijn. Koppel policy-monitoring aan het configuration management proces zodat wijzigingen worden geregistreerd in het CMDB en impact-analyses kunnen worden uitgevoerd.
2. Valideer wekelijks of alle resources die volgens het assetregister backup-bescherming zouden moeten hebben, daadwerkelijk een actieve policy hebben toegewezen. Gebruik Azure Resource Graph queries of PowerShell-scripts om een inventarisatie te maken van alle resources en vergelijk deze met de lijst van resources die backup-bescherming hebben, waarbij afwijkingen direct worden onderzocht en gecorrigeerd. Voor nieuwe resources die automatisch via Azure Policy een backup policy zouden moeten krijgen, verifieer dat dit proces daadwerkelijk werkt door testresources te deployen en te controleren of de policy-toewijzing automatisch plaatsvindt. Monitor policy-toewijzingen via Azure Activity Logs om te detecteren wanneer resources worden toegevoegd of verwijderd uit backup-bescherming, waarbij onverwachte wijzigingen direct worden onderzocht. Publiceer wekelijkse rapportages naar management waarin wordt getoond hoeveel resources worden beschermd, hoeveel resources nog niet zijn toegewezen, en wat de trends zijn over de afgelopen periode.
3. Evalueer maandelijks of retentie-instellingen nog steeds aansluiten bij compliance-vereisten en business needs, aangezien deze kunnen veranderen door nieuwe wetgeving, gewijzigde risicoprofielen of lessons learned uit incidenten. Controleer of nieuwe compliance-vereisten zoals NIS2 of gewijzigde sectorale normen leiden tot aanpassingen in retentieperiodes, waarbij policies worden bijgewerkt en goedgekeurd voordat ze in productie worden genomen. Analyseer backup-opslagkosten per policy om te identificeren of bepaalde policies disproportioneel veel kosten genereren, wat kan wijzen op onnodig lange retentieperiodes of ongebruikelijk grote backup-volumes. Vergelijk actuele retentie-instellingen met de documentatie in het Business Continuity Plan en compliance-register, waarbij afwijkingen worden gedocumenteerd en gejustificeerd of policies worden aangepast om weer compliant te zijn. Overweeg om jaarlijkse retentie-instellingen te evalueren op basis van werkelijke restore-requests, waarbij policies worden geoptimaliseerd als blijkt dat herstelpunten ouder dan een bepaalde periode nooit worden gebruikt.
4. Test kwartaalgewijze of policies daadwerkelijk functioneren zoals bedoeld door restore-operaties uit te voeren vanuit verschillende recovery points en te verifiëren dat data correct kan worden hersteld binnen de afgesproken RTO. Voer restore-tests uit voor verschillende workload types zoals VM's, databases en file shares, waarbij wordt getest of application-consistent backups daadwerkelijk leiden tot werkende applicaties na restore. Documenteer testresultaten inclusief doorlooptijden, eventuele problemen en verbeteracties, waarbij deze informatie wordt gebruikt om policies te optimaliseren of aanvullende configuraties toe te voegen. Valideer dat backup-schema's correct worden gevolgd door te controleren of backups daadwerkelijk plaatsvinden op de geplande tijden en of er geen gemiste backups zijn geweest die kunnen wijzen op configuratieproblemen of resource-problemen. Vergelijk de theoretische RPO en RTO waarden uit policies met de werkelijke hersteltijden uit tests, waarbij significante afwijkingen leiden tot aanpassingen in policies of aanvullende maatregelen om de gewenste doelen te behalen.
5. Monitor backup-kosten per policy en resource om trends te identificeren en onverwachte kostenstijgingen tijdig te signaleren, waarbij kosten worden geanalyseerd op basis van opslagverbruik, instance-kosten en mogelijke datatransfer-kosten. Stel budget-alerts in via Azure Cost Management die automatisch waarschuwen wanneer backup-kosten bepaalde drempelwaarden overschrijden, zodat finance-teams en beheerders tijdig kunnen bijsturen. Analyseer kosten per dataklasse en workload-type om te identificeren of bepaalde categorieën resources disproportioneel veel kosten, wat kan leiden tot heroverweging van retentie-instellingen of policy-optimalisatie. Vergelijk werkelijke kosten met begrote bedragen en documenteer significante afwijkingen met uitleg, waarbij structurele kostenoverschrijdingen leiden tot policy-herziening of budgetaanpassing. Rapporteer maandelijks naar management over backup-kosten inclusief trends, voorspellingen en aanbevelingen voor kostenoptimalisatie, waarbij duidelijk wordt gemaakt welke kosten noodzakelijk zijn voor compliance en welke mogelijk kunnen worden geoptimaliseerd zonder risico voor bescherming.
6. Gebruik Azure Policy compliance-rapportages om realtime te meten of nieuwe of gewijzigde resources automatisch de juiste backup policies krijgen toegewezen en of deze voldoen aan organisatorische standaarden. Configureer Azure Policy initiatieven die automatisch backup policies toewijzen aan nieuwe resources op basis van tags, resource types of andere criteria, waarbij compliance wordt gemonitord via het Azure Policy dashboard. Stel compliance-alerts in die waarschuwen wanneer resources niet-compliant zijn met backup-vereisten, zodat beheerders direct kunnen ingrijpen voordat resources langdurig onbeschermd blijven. Integreer Azure Policy compliance-data met SIEM-systemen of ITSM-platforms zodat backup-compliance wordt meegenomen in overall security posture monitoring en incident response workflows. Evalueer periodiek of Azure Policy regels nog steeds effectief zijn en of ze moeten worden aangepast op basis van nieuwe workload types, veranderende organisatorische vereisten of lessons learned uit audits.
7. Documenteer en rapporteer policy-compliance status naar auditors en toezichthouders door periodiek overzichten te genereren waarin wordt getoond welke policies actief zijn, welke resources worden beschermd, welke retentie-instellingen zijn geconfigureerd en hoe deze aansluiten bij compliance-vereisten. Maak gebruik van Azure Backup rapportages en PowerShell-scripts om gestructureerde compliance-rapporten te genereren die direct kunnen worden gebruikt voor audit-doeleinden, waarbij alle relevante informatie zoals policy-configuraties, backup-status, restore-test resultaten en kostenoverzichten worden meegenomen. Leg een audit-trail bij van alle policy-wijzigingen inclusief goedkeuringen, zodat auditors kunnen verifiëren dat wijzigingen intentioneel en geautoriseerd zijn. Houd een mapping bij tussen compliance-vereisten zoals BIO 12.03, ISO 27001 A.8.13 en NIS2 artikel 21 en de specifieke policy-parameters die deze eisen adresseren, zodat auditors direct kunnen zien hoe policies bijdragen aan compliance. Plan halfjaarlijkse gesprekken met auditors en toezichthouders om verwachtingen af te stemmen en te laten zien hoe policies worden gebruikt om compliance te waarborgen, waarbij feedback wordt meegenomen in policy-verbeteringen.

Compliance en Auditing

Azure Backup policies zijn geen optionele configuratie maar een harde compliance-vereiste binnen vrijwel alle relevante normenkaders die eisen dat organisaties aantoonbaar kunnen bewijzen dat backup-procedures zijn gedefinieerd, geconfigureerd en getest. De Baseline Informatiebeveiliging Overheid schrijft in BIO 12.03 voor dat reservekopieën periodiek, gecontroleerd en beveiligd moeten worden opgeslagen, waarbij policies de formele definitie vormen van wat 'periodiek' en 'gecontroleerd' betekent in de praktijk. ISO 27001:2022 control A.8.13 benadrukt dat organisaties niet alleen backups moeten maken, maar ook de procedures moeten documenteren en regelmatig moeten testen, waarbij policies de technische vertaling zijn van deze procedures. De AVG artikel 32 eist technische en organisatorische maatregelen voor beschikbaarheid en veerkracht, waarbij backup policies moeten aantonen dat persoonsgegevens kunnen worden hersteld na een incident binnen acceptabele tijd. De aankomende NIS2-richtlijn artikel 21 verplicht aanbieders van essentiële en belangrijke diensten om maatregelen te treffen die continuïteit garanderen, waarbij backup policies een essentieel onderdeel zijn van het bewijs dat organisaties beschikken over adequaat herstelvermogen. Sectorale normen zoals de Archiefwet vereisen dat bepaalde categorieën overheidsdata minimaal 20 jaar worden bewaard, waarbij backup policies met jaarlijkse retentie van 20+ jaar moeten worden geconfigureerd voor archief-relevante workloads. In audits vragen toezichthouders standaard naar policy-documentatie, policy-configuraties, bewijs van policy-toewijzingen aan resources en testresultaten die aantonen dat policies daadwerkelijk functioneren. Een organisatie die geen gestructureerde backup policies heeft of die policies niet kan aantonen aan auditors, loopt risico op aanwijzingen, dwangsommen of zelfs intrekking van vergunningen en subsidies. Het is daarom essentieel dat policies worden gedocumenteerd met duidelijke business rationale, gekoppeld worden aan compliance-vereisten, worden versiebeheerd en worden gereviewd en goedgekeurd door het informatiebeveiligingsberaad. Policies moeten worden gekoppeld aan het risicoregister zodat duidelijk is welke risico's worden gemitigeerd, en aan het dataclassificatie-register zodat duidelijk is welke dataklassen worden beschermd. Audit-evidence moet minimaal zeven jaar worden bewaard inclusief policy-versies, wijzigingshistorie, goedkeuringen, testresultaten en compliance-rapporten. Organisaties moeten overwegen om policy-compliance te monitoren via Azure Policy en de resultaten te rapporteren in het ISMS, zodat bestuurders realtime inzicht hebben in de status van backup-bescherming. Door backup policies op deze manier te benaderen wordt voldoen aan compliance-vereisten geen losstaand project maar een integraal onderdeel van de operationele beveiligingspraktijk.

Remediatie

Gebruik PowerShell-script backup-policies-configured.ps1 (functie Invoke-Remediation) – Dit script creëert ontbrekende backup policies, wijst policies toe aan resources die nog geen bescherming hebben, en corrigeert policy-configuraties die niet voldoen aan compliance-vereisten of organisatorische standaarden. Het remediation-proces voert een volledige audit uit van alle resources, identificeert welke resources backup-bescherming vereisen op basis van tags, resource types of expliciete lijsten, en zorgt ervoor dat de juiste policies worden toegewezen volgens organisatorische standaarden. Voor resources die al een policy hebben maar waarbij de configuratie niet voldoet aan vereisten, worden policies aangepast of nieuwe policies gecreëerd en toegewezen. Het script valideert dat policies correct zijn geconfigureerd met de juiste backup-schema's, retentie-instellingen en consistentieniveaus, en corrigeert eventuele afwijkingen automatisch. Na policy-toewijzing wordt een initiële backup getriggerd om te verifiëren dat de configuratie werkt, waarbij resultaten worden gelogd voor audit-doeleinden. Het script ondersteunt dry-run modus voor veilige evaluatie van wijzigingen voordat ze worden doorgevoerd, en integreert met Azure Monitor voor alerting bij kritieke wijzigingen. Alle remediation-acties worden gedocumenteerd inclusief tijdstempels, betrokken resources, oude en nieuwe configuraties, en business rationale, zodat auditors kunnen verifiëren dat wijzigingen intentioneel en goedgekeurd zijn..

Compliance & Frameworks

• CIS M365: Control 7.3 (L1) - Zorg ervoor dat Azure Backup policies zijn geconfigureerd voor alle kritieke resources
• BIO: 12.03.01 - Reservekopieën - Backup policies voor gecontroleerde en periodieke backups
• ISO 27001:2022: A.8.13 - Information backup - Documented backup policies and procedures
• NIS2: Artikel - Bedrijfscontinuïteit - Backup policies voor herstelvermogen na cyberincidenten

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 Backup policies definiëren backup-schema's, retentie-instellingen en consistentieniveaus voor gecontroleerde en herbruikbare bescherming. Met gestandaardiseerde policies wordt voldaan aan BIO 12.03, ISO 27001 A.8.13, AVG artikel 32 en NIS2 artikel 21, terwijl kosten worden geoptimaliseerd en nieuwe resources automatisch worden beschermd. Plan policies op basis van RPO/RTO waarden, configureer retentie volgens compliance-vereisten, en monitor policy-compliance via Azure Policy.

• Implementatietijd: 10 uur
• FTE required: 0.08 FTE