Terug naar de blog
5 oktober 2026

Backup retentiebeleid opstellen: zo bepaal je de juiste bewaartermijnen

IT en data-eigenaren stellen bewaartermijnen vast

Een goed backup retentiebeleid definieert retentietermijnen per dataclass, legt de onderbouwing vast en test restores periodiek. Dat betekent: geen vaste bewaartermijn voor alles, maar een onderbouwde keuze per type data, vastgelegd in beleid en verwerkingsregister. Zorg daarnaast voor heldere afspraken met je cloudleveranciers en een vast testritme. De Autoriteit Persoonsgegevens, het NCSC en ISO 27001 geven je daarvoor het kader.

Kort samengevat:

  • Een retentiebeleid moet per dataclass de wettelijke en zakelijke bewaartermijnen onderbouwen en vastleggen in beleid en verwerkingsregister.
  • Native retentie-instellingen in SaaS-platformen zoals Microsoft 365 zijn vaak beperkter dan organisaties verwachten, waardoor een externe back-up essentieel is.
  • Gelaagde opslag, waaronder WORM en archivering, verlaagt kosten en verhoogt veiligheid, vooral tegen ransomware-aanvallen, als het beleid goed is geïmplementeerd.
  • Periodieke restore-tests en het vastleggen van testresultaten bewijzen dat back-ups daadwerkelijk werken en data bruikbaar is voor de organisatie.
  • Retentiebeleid is een gezamenlijke verantwoordelijkheid van bestuur en IT, die samen de risico’s op kosten en compliance effectief beheersen.
Astia
Houd je IT veilig en beheersbaar
ASTIA IT beheert werkplekken, netwerken en telefonie, zodat je team veilig en zorgeloos kan doorwerken zonder technische zorgen.
Bezoek ASTIA IT

Inhoudsopgave

AVG en wettelijke kaders: hoe bepaal en documenteer je bewaartermijnen

De AVG werkt met het beginsel van opslagbeperking: er bestaat geen vaste bewaartermijn, maar je moet zelf een passende termijn kiezen en die onderbouwen. Volgens de Autoriteit Persoonsgegevens leg je die keuze vast in je beleid en je verwerkingsregister, zodat je bij controle kunt aantonen waarom je voor die termijn hebt gekozen.

Je wettelijke verplichtingen lopen vaak uiteen, zoals wanneer je fiscale bewaarplicht in acht neemt volgens de retentieregels voor belastingdocumenten. Fiscale bewaarplicht, archiefregels en sectorspecifieke eisen kunnen elkaar tegenspreken: in dat geval geldt de langste verplichte termijn, tenzij een expliciete wettelijke uitzondering van toepassing is.

Leg in je beleid in ieder geval dit vast:

  • De exacte retentietermijn per dataclass, met de wettelijke of zakelijke reden erachter.
  • De verantwoordelijke functionaris die de termijn heeft goedgekeurd en periodiek herbeoordeelt.
  • De termijnen zoals vermeld in je privacyverklaring, zodat beleid en externe communicatie overeenkomen.

Microsoft 365 en SaaS: shared responsibility en de grenzen van native retentie

Bij clouddiensten zoals Microsoft 365 geldt het shared responsibility model: de leverancier beheert het platform, maar jij blijft verantwoordelijk voor je eigen data en de bewaartermijnen daarvan. Native retentie-instellingen zijn vaak beperkter dan organisaties verwachten, zeker bij verwijderde of losgekoppelde accounts.

SaaS-platform en organisatorische verantwoordelijkheid zijn gescheiden

Een paar risicoscenario’s komen regelmatig terug: een medewerker verlaat de organisatie en het account wordt na een standaardperiode automatisch opgeschoond, of gesynchroniseerde bestanden verdwijnen zonder dat iemand het opmerkt. Bij een geschil of controle sta je dan zonder bewijsmateriaal.

Daarom is het verstandig om:

  • Een externe back-upoplossing naast de native SaaS-retentie in te zetten.
  • Automatisering, bijvoorbeeld via PowerShell-scripts, te gebruiken om retentiedata te controleren en te rapporteren.
  • Contractclausules met je leverancier of verwerker op te nemen over bewaartermijnen, locatie en teruggave van data.

Zo ontwerp je een retentiestrategie per dataclassificatie

Een werkbare retentiestrategie volgt een vaste volgorde. PwC beschrijft een aanpak in vijf stappen, die zich goed laat vertalen naar de praktijk van IT-beslissers:

  1. Inventariseer welke data je hebt en waar die staat.
  2. Classificeer elke dataset naar gevoeligheid en verwerkingsdoel.
  3. Toets elke dataset aan wettelijke verplichtingen en zakelijke noodzaak.
  4. Ken per dataclass een definitieve retentietermijn toe en leg die vast.
  5. Implementeer de termijn technisch en verifieer periodiek of het beleid nog klopt.

In de praktijk werk je met categorieën zoals operationele data (kortlopend, gericht op dagelijks herstel), auditdata (middellang, voor controledoeleinden), juridische data (vastgesteld door wetgeving) en archiefdata (langdurig, voor bewijsvoering). Elke categorie vraagt een eigen rationale.

Koppel je keuzes ook aan je hersteldoelen. Hoe korter je RPO en RTO, hoe vaker je moet back-uppen en hoe belangrijker snelle toegang tot recente versies wordt, wat weer invloed heeft op welke opslagtier je kiest.

Pro-tip: Begin met je meest gevoelige dataclass. Als die goed gedocumenteerd is, kopieer je de structuur voor de rest.

Technische opslagtiers: gelaagde retentie, WORM en archivering

Niet alle data hoort in dezelfde opslaglaag. Gelaagde retentie combineert snel toegankelijke opslag voor recente back-ups met goedkopere archieflagen voor oudere data, wat volgens de Digital Trust Center direct invloed heeft op je opslagkosten: hoe verder je terug moet kunnen, hoe meer opslag en budget dat vraagt.

WORM-opslag (write once, read many) maakt back-ups onveranderbaar: eenmaal geschreven, kan niemand de data meer wijzigen of verwijderen binnen de ingestelde periode. Dat is iets anders dan archivering, die vooral draait om langdurige bewaring voor bewijsvoering, niet om onveranderbaarheid.

Voor ransomware-weerbaarheid is een combinatie van maatregelen verstandig:

  • Offline of immutable kopieën die buiten het bereik van een aanval blijven.
  • Versleuteling van back-updata, zowel onderweg als in rust.
  • Strikte toegangscontrole, zodat alleen geautoriseerde personen restores kunnen uitvoeren.

Lees ook hoe de 3-2-1 back-upregel deze lagen in de praktijk combineert.

Organisatie en documentatie: wie is verantwoordelijk en wat leg je vast

Beleid zonder eigenaarschap blijft dode letter. Wijs een systeemeigenaar aan per dataset, bepaal wie restores mag autoriseren en richt een escalatiemodel in voor als iets misgaat buiten kantooruren.

Bij verwerkersovereenkomsten met je cloud- of back-upleverancier zijn een paar punten onmisbaar:

  • Waar de data fysiek wordt opgeslagen en of dat binnen de Europese Economische Ruimte blijft.
  • Welke versleuteling wordt toegepast, zowel bij opslag als transport.
  • Welke auditrechten je hebt om de naleving van afspraken te controleren.
  • Hoe en binnen welke termijn je je data kunt terugkrijgen bij einde contract.

Documenteer daarnaast je technische restore-handleidingen, zodat herstel niet afhankelijk is van één persoon. Audit-trails en retention-logs laten zien wanneer welke data is bewaard, gewijzigd of verwijderd, wat onmisbaar is bij een controle of een datalek.

Testen en verifiëren: hoe bewijs je dat je back-ups echt werken

Een retentiebeleid is pas waardevol als restores ook daadwerkelijk werken. Het NCSC adviseert om restore-tests in realistische scenario’s uit te voeren en niet alleen te controleren of een technische terugzet lukt, maar ook of de herstelde data bruikbaar is voor de organisatie.

Een praktisch testplan ziet er zo uit:

  1. Voer minstens ieder kwartaal een restore-oefening uit voor kritieke systemen.
  2. Controleer niet alleen de technische terugzet, maar ook de integriteit en bruikbaarheid van de data.
  3. Betrek de data-eigenaar bij de acceptatietest en leg de resultaten vast.

Bewaar testlogs, incidentrapporten en restore-resultaten: dit is precies het bewijsmateriaal dat auditors en de Autoriteit Persoonsgegevens verwachten bij een controle.

Pro-tip: Plan je restore-test nooit alleen met IT. Een data-eigenaar die de uitkomst beoordeelt, voorkomt dat een “geslaagde” test toch onbruikbare data oplevert.

Praktische implementatie voor het MKB: een stappenplan dat werkt

We zien dat een retentiebeleid pas houdt stand als het simpel en navolgbaar is. Een werkbare checklist voor het MKB bevat:

  • Een actuele inventaris van alle datasets en waar die staan.
  • Een retentieschema per dataclass met onderbouwing en einddatum.
  • Contractclausules met elke leverancier over locatie, encryptie en teruggave van data.
  • Een vastgelegd restore-plan met verantwoordelijke personen.
  • Een testlogboek waarin elke restore-oefening en de uitkomst staat genoteerd.

Een helder rollenmodel voorkomt verwarring: één systeemeigenaar per dataset, één persoon die restores mag autoriseren, en een vastgelegd escalatiepad als een incident buiten kantooruren plaatsvindt. Zo blijft de verantwoordelijkheid duidelijk, ook als mensen wisselen van functie of de organisatie groeit.

Waarom retentiebeleid een bestuurs- en IT-opgave samen is

Retentiebeleid raakt juridische risico’s, opslagkosten en herstelvermogen tegelijk, dus het hoort niet alleen bij IT te liggen. Zonder bestuurlijke betrokkenheid krijgt documentatie vaak te weinig prioriteit, terwijl boetes en reputatieschade wel op bestuursniveau landen.

Overbewaring kost geld en vergroot je aansprakelijkheid bij een datalek, want hoe meer data je bewaart, hoe groter de impact als die uitlekt. Een scherp, onderbouwd retentiebeleid is dus geen formaliteit maar een kostenbeheersings- en risicomaatregel ineen.

— Mick

Hoe ASTIA je helpt met een werkend retentiebeleid

We merken dat veel MKB-bedrijven hun retentiebeleid wel op papier hebben staan, maar het nooit technisch hebben doorgevoerd of getest. Als onderdeel van onze IT uitbesteden-dienstverlening nemen we die uitvoering uit handen: van inventarisatie tot restore-test, zodat jij niet zelf tussen leveranciers hoeft te schakelen.

Astia

Een eerste intake bij ons levert direct drie concrete dingen op:

  • Een overzicht van je huidige datasets en bewaartermijnen.
  • Een retentieschema per dataclass, afgestemd op jouw wettelijke verplichtingen.
  • Een eerste restore-test, zodat je weet of je back-ups ook echt werken.

Benieuwd wat dat voor jouw organisatie betekent? Bekijk onze aanpak rond back-up en disaster recovery en plan een vrijblijvend gesprek.

Veelgestelden vragen

Wat is het grootste nadeel van een back-up in de cloud?

Het grootste risico is dat native retentie-instellingen van cloudleveranciers vaak korter of beperkter zijn dan organisaties verwachten, vooral bij verwijderde accounts. Daardoor kun je zonder aanvullende afspraken of een externe back-upoplossing data kwijtraken die je eigenlijk had moeten bewaren.

Hoe vaak moet je een back-up maken?

Dat hangt af van hoeveel dataverlies je organisatie kan accepteren, oftewel je RPO. Kritieke systemen back-up je doorgaans dagelijks of vaker, terwijl minder kritieke data met een lagere frequentie toekan.

Hoe kom ik bij mijn backup?

Je komt bij je back-up via het restoreproces dat in je back-upbeleid staat beschreven, meestal via de beheerconsole van je back-upleverancier of IT-afdeling. Het NCSC adviseert om dit proces vooraf te testen, zodat je weet dat herstel ook werkt wanneer het nodig is.

Wat gebeurt er als je een backup maakt?

Bij het maken van een back-up wordt een kopie van je data op een apart medium of locatie vastgelegd, los van het origineel. Die kopie dient als herstelpunt bij dataverlies, terwijl archivering juist bedoeld is voor langdurige bewaring en bewijsvoering.

Bronnen

Aanbevelingen