Beleid back-up en recovery

Onderdeel van Beleidsset informatiebeveiliging op BIO 2.0, op maat gemaakt met contextvragen · Markdown-bron

Word nodig? Kies dit stuk in de generator en download het daar, zonder of met je eigen antwoorden.

In het kort. Over het maken, beschermen en terugzetten van back-ups, met ransomware als leidend scenario. Behandelt back-upplannen en het back-upregister, hersteleisen per systeem, een onveranderbare kopie, gescheiden opslag op meerdere plekken en het jaarlijks testen van herstel.

Onderwerpen. 3. Back-upplannen en scenario's; 4. Hersteleisen; 5. Bescherming van de back-up; 6. Gescheiden opslag; 7. Herstel en testen.

Zonder profiel: tekst die van een contextvraag afhangt, staat in een kader met de vraag erboven.

1. Doel en reikwijdte#

Dit beleid werkt het strategisch informatiebeveiligingsbeleid uit voor het maken, bewaren, beschermen en terugzetten van back-ups. Het legt vast welke hersteleisen gelden, hoe de back-up beschermd is tegen een aanvaller met beheerrechten, waar de kopieën staan en hoe het terugzetten wordt getest, zodat de organisatie na verlies, vernietiging of versleuteling van gegevens haar processen binnen de afgesproken tijd hervat. Het gaat over ISO-beheersmaatregel 8.13.

Voor wie. Het beleid is primair bedoeld voor de beheerorganisatie die de back-up uitvoert of bij leveranciers regisseert, voor functioneel beheer van clouddiensten en voor de proces- en systeemeigenaren die de hersteleisen vaststellen. Het geldt ook voor leveranciers die back-up en herstel voor de organisatie verzorgen.

Waarop. Alle informatie waarvan de organisatie eigenaar is, waar die ook staat: in een eigen omgeving, bij een hostingpartij of in een SaaS-dienst. Het gaat om gegevens en om wat nodig is om systemen te herstellen: configuraties, instellingen van netwerk en applicaties, en de inrichting van clouddiensten. Is back-up of herstel uitbesteed, dan gelden de eisen uit dit beleid als minimumeis voor die partij. De organisatie legt dat vast in het contract en toetst de naleving met een onafhankelijke verklaring, zoals een ISO 27001-certificaat of een ISAE 3402- of ISAE 3000-rapport; het vastleggen loopt via het beleid informatiebeveiliging bij inkoop, het toetsen via het beleid contractbeheer.

Buiten dit beleid vallen de archivering van overheidsinformatie (een back-up is geen archief; de bewaarplicht staat in het archiefbeleid), de uitwijk en de keuze welke systemen kritiek zijn (continuïteitsbeleid), het sleutelbeheer voor de versleuteling (beleid cryptografie) en de fysieke beveiliging van opslaglocaties (beleid fysieke toegang en beveiliging).

2. Uitgangspunten#

1. De organisatie is eigenaar van haar gegevens, ook als een leverancier ze verwerkt. Zij zorgt dat er een back-up is die bij het impactniveau van het proces past, of zij die nu zelf maakt of laat maken. #
2. Ransomware is het scenario waarop de back-up is ingericht: een aanvaller met beheerrechten op de productieomgeving kan de back-up niet wissen of versleutelen. #
3. Een back-up waarvan het terugzetten niet is getest, geldt niet als back-up. #
4. Hoe hoger het impactniveau van een systeem, hoe korter de hersteltijd en hoe strikter de scheiding van de kopieën. #
5. Termijnen en frequenties in dit beleid die niet uit een wet of uit de BIO 2.0 komen, zijn standaardwaarden. De organisatie past ze aan op haar eigen risicoafweging en legt de keuze vast bij de vaststelling van dit beleid. #

3. Back-upplannen en scenario's#

1. Dit beleid en de back-upplannen per omgeving leggen samen vast wat wordt bewaard, hoe vaak, hoe lang, waar en hoe het is beschermd. [eigenaar back-upplannen] stelt de plannen op, de systeemeigenaar keurt ze goed en zij worden jaarlijks en na elke grote wijziging herzien. [8.13.01] #
2. De back-up is ten minste ingericht op deze scenario's: een aanval met ransomware of wiperware op de eigen omgeving, een grote verstoring van een datacenter, gegevensverlies in een SaaS-dienst en het per ongeluk of bewust verwijderen van veel gegevens door een gebruiker. Het back-upplan beschrijft per scenario hoe het herstel verloopt. [8.13.01] #
3. [lijneigenaar back-up] houdt een back-upregister bij met per systeem en per SaaS-dienst: het back-upplan, de hersteleisen, de locaties van de kopieën, de onveranderbare kopie en de datum van de laatste hersteltest. [8.13.01] #

4. Hersteleisen#

1. Per systeem of gegevensverzameling stelt de proceseigenaar het maximale gegevensverlies (RPO) en de maximale hersteltijd (RTO) vast, met een vastgelegde risicoafweging. De proceseigenaar legt ook het detailniveau van herstel vast (bijvoorbeeld één bericht, een mailbox of een hele omgeving) en de bewaartermijn van de back-ups. [8.13.02] #
2. Zolang er voor een systeem geen afweging is, geldt een standaardregime: ten hoogste 24 uur gegevensverlies en een hersteltijd van ten hoogste [standaard hersteltijd]. De eigenaar van de back-upplannen rapporteert jaarlijks welke systemen nog op het standaardregime draaien. [8.13.02] #
3. De hersteltijd van een systeem met impactniveau kritiek of hoger is korter dan de maximale uitvalsduur van het proces, want na het terugzetten volgen nog controle, koppelingen en communicatie. De proceseigenaar legt de marge vast in het back-upplan. [8.13.02] #

Alleen als: Hoe is je crisis- en continuïteitsorganisatie geregeld? «Een BCM-functie met continuïteitsplannen en een BIA»

4. De hersteleisen voor kritieke systemen komen uit de BIA en het overzicht van kritieke systemen uit het continuïteitsbeleid. Wijkt een back-upplan daarvan af, dan beslist de proceseigenaar en legt die het besluit vast. [8.13.02] #

Alleen als: Hoe is je crisis- en continuïteitsorganisatie geregeld? «Geen» of «Een crisisteam, zonder BCM-functie»

5. Er is geen BIA. De proceseigenaar stelt de hersteleisen vast met de CISO en de systeemeigenaar, op basis van het impactniveau van de gegevens en het overzicht van kritieke systemen, en legt ze vast in het back-upplan. [8.13.02] #

5. Bescherming van de back-up#

1. Ten minste één kopie van de back-up is binnen de bewaartermijn niet te wijzigen of te wissen (onveranderbaar of offline), ook niet met de beheerrechten van de productieomgeving. De beheerorganisatie toont dat bij elke hersteltest aan. [8.13.01] #
2. Back-ups zijn versleuteld volgens het beleid cryptografie. De sleutels staan gescheiden van de back-up, in een beheerde sleutelkluis, en zijn ook beschikbaar als de productieomgeving niet werkt. [8.13.01] #
3. Beheer van de back-upomgeving gaat met aparte, persoonsgebonden accounts met MFA, die niet in het gewone domein of de gewone tenant zitten. Verwijderen of verkorten van bewaartermijnen vraagt goedkeuring van een tweede persoon en wordt gelogd. [8.13.01] #
4. De beheerorganisatie controleert elke werkdag of alle back-uptaken zijn geslaagd. Een mislukte taak is dezelfde of de volgende werkdag hersteld, of gemeld aan de systeemeigenaar met de reden. De controle en de afhandeling staan in het logboek. [8.13.01] #
5. Bewaartermijnen passen bij het doel en bij de wet. Gegevens die volgens de archief- of privacyregels vernietigd moeten zijn, verwijdert de beheerorganisatie uit de back-up aan het eind van de bewaartermijn en legt dat vast. [8.13.01] #

6. Gescheiden opslag#

1. Back-ups van systemen met impactniveau kritiek of hoger staan op ten minste twee plekken, waarvan één zo gescheiden van de productieomgeving dat een incident op de ene plek (brand, stroomuitval, een aanval op het netwerk of de beheeromgeving) de andere niet raakt. Een vuistregel is 3-2-1: drie kopieën, op twee soorten opslag, één daarvan op een andere locatie. Het back-upregister noemt de locaties. [8.13.03] #

Alleen als: Waar draaien je systemen? «Eigen datacenter of serverruimte»

2. Bij een eigen datacenter staat de gescheiden kopie op een andere fysieke locatie of bij een externe opslagdienst, met een eigen beheeromgeving. Media die worden vervoerd, zijn versleuteld en de beheerorganisatie houdt een logboek bij van waar ze zijn. [8.13.03] #

Alleen als: Waar draaien je systemen? «Hostingpartij (IaaS, gedeeld datacenter)»

3. Bij een hostingpartij is een gespiegeld tweede datacenter niet genoeg, omdat dat de kwetsbaarheden van het eerste deelt. Het contract regelt daarnaast een kopie bij een andere partij of in een gescheiden omgeving, waar de organisatie zelf bij kan. De contracteigenaar controleert dat jaarlijks. [8.13.03] #

Alleen als: Waar draaien je systemen? «Vooral SaaS en publieke cloud»

4. Voor elke SaaS-dienst die een kritiek proces ondersteunt, legt functioneel beheer in het back-upregister vast hoe de leverancier back-ups maakt, waar ze staan en hoe lang ze bewaard worden. Biedt de leverancier geen gescheiden kopie, of kan de organisatie er niet zelf bij, dan exporteert de organisatie de gegevens periodiek naar eigen opslag of neemt zij een back-updienst van een andere partij af. [8.13.03] #

Alleen als: Hoe ziet je werkplek eruit? «Cloudwerkplek (bijvoorbeeld Microsoft 365)» of «Hybride: cloud naast een virtuele of lokale werkplek»

5. De cloudwerkplek (mail, bestanden, samenwerkruimtes) heeft een eigen back-up buiten de tenant. De ingebouwde prullenbak en het versiebeheer van de aanbieder gelden niet als back-up. De back-up omvat ook de inrichting die nodig is voor herstel, zoals groepen, rechten en beleidsinstellingen, voor zover de aanbieder dat mogelijk maakt. Functioneel beheer controleert elk kwartaal dat de back-up alle actieve onderdelen dekt. [8.13.03] #

7. Herstel en testen#

1. Herstel uit een back-up gebeurt na toestemming van de systeemeigenaar. Bij een groot incident of ransomware beslist de proceseigenaar over de opties, op advies van de beheerorganisatie en de CISO. De beheerorganisatie logt elke hersteloperatie met aanvrager, tijdstip en resultaat. [8.13.04] #
2. De beheerorganisatie test de herstelprocedure van elk systeem met impactniveau kritiek of hoger elk jaar en na elke grote wijziging, zoals een migratie of een nieuwe back-upvoorziening. De test zet echte gegevens terug, controleert of ze volledig en bruikbaar zijn en meet de benodigde tijd tegen de hersteltijd. De uitkomst staat in een testverslag. [8.13.04] #
3. Ten minste één test per jaar gaat uit van het ransomwarescenario: herstel uit de onveranderbare kopie, in een schone omgeving, zonder gebruik van de beheeraccounts van productie. [8.13.04] #
4. Haalt een test de hersteltijd niet, dan past de systeemeigenaar binnen drie maanden het back-upplan of de voorziening aan, of accepteert de proceseigenaar het risico vastgelegd. [8.13.04, 8.13.02] #

Alleen als: Wie beheert je IT? «Eigen beheer»

5. De eigen beheerorganisatie voert de tests uit en legt ze vast in een testverslag met tijden, bevindingen en opvolging. [8.13.04] #

Alleen als: Wie beheert je IT? «Regie: eigen organisatie stuurt, beheer is uitbesteed» of «Volledig uitbesteed»

6. Back-up en herstel liggen bij de beheerpartij. Het contract verplicht die partij om de tests uit te voeren met de organisatie erbij, de verslagen te leveren en ook kopieën te maken en te testen van onderdelen die bij andere leveranciers liggen, of dat expliciet uit te sluiten. De regieorganisatie houdt in het back-upregister bij welke leverancier welk deel van de back-up doet. [8.13.04] #

8. Rollen en verantwoordelijkheden#

9. Naleving en controle#

Controleraamwerk. De naleving van dit beleid wordt met de volgende controles aangetoond. De uitkomst en het bewijs worden vastgelegd in [registratie van controles]; afwijkingen gaan als bevinding naar het risicoregister.

Afwijkingen. Afwijken van een eis kan alleen op basis van een gedocumenteerde risicoafweging. De systeemeigenaar dient het verzoek in bij de CISO, met de reden, de compenserende maatregelen en de looptijd. De afwijking geldt pas na acceptatie van het risico door [risico-eigenaar] en staat in het risicoregister; afwijkingen worden ten minste jaarlijks opnieuw beoordeeld.

Niet naleven. Het niet naleven van dit beleid wordt behandeld als beveiligingsincident en kan leiden tot het intrekken van toegangsrechten of tot maatregelen volgens de rechtspositieregeling of het contract.

10. Samenhang#

Dit beleid valt onder het strategisch informatiebeveiligingsbeleid. Het hangt samen met het continuïteitsbeleid (kritieke systemen, BIA en uitwijk), het beleid informatieclassificatie (impactniveau als maat voor de hersteleisen), het beleid informatiebeveiliging bij inkoop en contractbeheer (afspraken met en verklaringen van leveranciers), het beleid cryptografie (versleuteling en sleutelbeheer), het beleid logische toegangsbeveiliging (beheeraccounts), het beleid fysieke toegang en beveiliging (opslaglocaties), het beleid beveiligingsincidenten (herstel na ransomware) en het archiefbeleid (bewaartermijnen).

Bijlage A: BIO 2.0-maatregelen#

De maatregelen van dit domein (4, waarvan 4 overheidsmaatregelen), waar dit stuk ze invult en welke controle ze aantoont. Nummers volgens BIO2 v1.3 definitief - 9 januari 2026; de tekst van de maatregel staat bij het CIP. Waar de BIO 2.0 geen overheidsmaatregel kent, geldt de ISO 27002-beheersmaatregel.

Bijlage B: Afkortingen#

Nog in te vullen#

• eigenaar back-upplannen: de functie die de back-upplannen opstelt, bijvoorbeeld de informatiemanager
• lijneigenaar back-up: de manager die back-up en herstel uitvoert of bij leveranciers regisseert
• standaard hersteltijd: bijvoorbeeld 16 werkuren
• registratie van controles
• risico-eigenaar: de manager die restrisico's accepteert
• eigenaar van dit beleid: de manager die dit beleid uitvoert en laat naleven
• vaststeller: wie het beleid vaststelt, bijvoorbeeld de directie of het bestuur