Een back-up die alles bewaart, lijkt veilig. Tot iemand vraagt waarom persoonsgegevens van ex-medewerkers, oude klanten of verwijderde dossiers nog jaren in uw systemen zitten. Precies daar raken GDPR en back-up beleid elkaar. Niet als papieren oefening, maar als praktische vraag: hoe zorgt u voor herstel bij incidenten zonder uw privacyverplichtingen uit het oog te verliezen?

Voor veel kmo’s zit het risico niet in een ontbrekende back-up, maar in een back-upstrategie die technisch wel werkt en juridisch slecht onderbouwd is. Dat leidt tot onduidelijkheid bij dataverzoeken, problemen na een datalek en discussies over bewaartermijnen. Een goed beleid voorkomt dat. Het zorgt ervoor dat uw organisatie snel kan herstellen, terwijl ook duidelijk is welke persoonsgegevens waar staan, hoelang ze blijven bestaan en wie erbij kan.

Wat GDPR en back-up beleid in de praktijk betekenen

De AVG, in Nederland vaak GDPR genoemd, verbiedt back-ups niet. Integendeel, beschikbaarheid en herstelbaarheid van gegevens horen juist bij goed beveiligingsbeleid. De fout ontstaat meestal wanneer organisaties back-ups behandelen als een technisch eiland waar andere regels niet gelden. Dat klopt niet.

Persoonsgegevens in back-ups vallen gewoon onder de AVG. Dat betekent dat u moet kunnen uitleggen waarom u die gegevens bewaart, hoe u ze beveiligt, wie toegang heeft en hoe lang ze nodig zijn. Ook moet u rekening houden met rechten van betrokkenen, zoals verwijdering of beperking van verwerking. Daarbij geldt wel een belangrijk nuancepunt: een back-up is bedoeld voor herstel, niet als archief of werkdatabase.

Dat verschil is cruciaal. Als een back-up alleen wordt gebruikt bij calamiteiten en niet toegankelijk is voor dagelijks gebruik, dan gelden er in de praktijk andere organisatorische maatregelen dan voor live data. Maar dat ontslaat u niet van verantwoordelijkheid. U moet nog steeds aantonen dat uw aanpak proportioneel en doordacht is.

Waarom een standaard back-upregeling vaak tekortschiet

Veel organisaties hebben wel een back-upoplossing, maar geen echt beleid. Er draait software, er is opslag in de cloud of op locatie, en men gaat ervan uit dat het dus geregeld is. Alleen: techniek zonder afspraken levert blinde vlekken op.

Een klassiek voorbeeld is de automatische back-up van complete servers, mailboxen en bestanden, zonder onderscheid tussen actieve en verouderde data. Daardoor blijven persoonsgegevens langer bewaard dan nodig. Een tweede probleem is toegang. Als te veel medewerkers back-ups kunnen benaderen of terugzetten, vergroot dat het risico op misbruik of fouten. Een derde punt is documentatie. Bij audits, incidenten of vragen van klanten blijkt dan vaak dat niemand exact weet wat er in back-ups zit en hoe verwijderverzoeken worden afgehandeld.

Daar komt nog iets bij. Veel bedrijven combineren lokale back-ups, cloudback-ups en kopieën bij externe leveranciers. Op zich is dat verstandig voor continuïteit, maar het maakt verantwoordelijkheid complexer. Zeker wanneer data buiten de primaire omgeving wordt opgeslagen, moet duidelijk zijn welke verwerker betrokken is, welke beveiligingsafspraken gelden en of opslaglocaties passen binnen uw compliancekader.

GDPR en back-up beleid: de kernvragen die u moet beantwoorden

Een werkbaar beleid begint niet bij software, maar bij keuzes. U moet in gewone taal antwoord hebben op een paar basisvragen.

De eerste is welke persoonsgegevens in de back-up terechtkomen. Niet elk systeem heeft hetzelfde risicoprofiel. Een kopie van een fileserver met HR-documenten vraagt iets anders dan een back-up van een printserver. Daarna volgt de vraag waarom u back-ups bewaart en hoe lang. Die termijn moet aansluiten op herstelbehoefte, niet op gewoonte.

Vervolgens kijkt u naar toegang en versleuteling. Wie mag een restore starten? Wie kan data inzien? Is de back-up versleuteld tijdens opslag en transport? En net zo belangrijk: test u het herstelproces regelmatig, zodat u weet dat uw back-up niet alleen bestaat, maar ook bruikbaar is?

Tot slot moet u bepalen hoe u omgaat met verwijderde persoonsgegevens die nog in back-ups aanwezig zijn. In veel gevallen hoeft u niet elke back-up direct open te breken om één record te wissen, zeker niet als de back-up alleen voor noodherstel dient en er maatregelen zijn om die data niet opnieuw actief te maken. Maar dat moet wel aantoonbaar geregeld zijn. Herstel mag niet betekenen dat eerder verwijderde persoonsgegevens zomaar weer in productie terugkomen zonder controle.

Bewaartermijnen: kort genoeg voor privacy, lang genoeg voor herstel

Hier gaat het vaak mis. Bedrijven kiezen een bewaartermijn voor back-ups omdat die standaard in het pakket staat, niet omdat die inhoudelijk klopt. Soms is dat 30 dagen, soms 90, soms een jaar. De juiste termijn hangt af van uw hersteldoel, uw sector en het type data.

Voor operationele continuïteit is een beperkte retentie vaak voldoende. Denk aan bescherming tegen menselijke fouten, systeemstoringen of ransomware. Daarvoor is het meestal niet nodig om identieke persoonsgegevens eindeloos mee te slepen. Langere bewaartermijnen kunnen verdedigbaar zijn, maar alleen als daar een duidelijke reden voor is, bijvoorbeeld voor forensisch onderzoek, contractuele eisen of sectorspecifieke verplichtingen.

Belangrijk is dat u back-up niet verwart met archivering. Archivering heeft een ander doel, andere toegangsregels en vaak ook een andere wettelijke grondslag. Wie dat onderscheid niet maakt, loopt het risico dat oude persoonsgegevens via back-ups blijven circuleren zonder geldige noodzaak.

Verwijderverzoeken en het recht op wissen

Een veelgestelde vraag is of persoonsgegevens direct uit alle back-ups verwijderd moeten worden zodra iemand daarom vraagt. Het korte antwoord is: niet altijd, maar u moet het wel serieus en zorgvuldig organiseren.

Als back-ups geïsoleerd zijn, alleen bij incidenten worden gebruikt en niet doorzoekbaar zijn voor dagelijkse verwerking, dan is directe verwijdering uit elke back-upkopie vaak niet redelijk uitvoerbaar. De AVG laat ruimte voor technische haalbaarheid en proportionaliteit. Wat wel nodig is, is een procedure die voorkomt dat die gegevens na een restore opnieuw actief blijven zonder reden.

Dat betekent concreet dat u na herstel moet kunnen synchroniseren of opnieuw verwijderen wat eerder rechtsgeldig was gewist. Ook moet u kunnen uitleggen waarom onmiddellijke verwijdering uit back-ups technisch of organisatorisch onevenredig zou zijn. Zonder die onderbouwing staat u zwak.

Beveiliging van back-ups is meer dan een extra kopie

Back-ups zijn een geliefd doelwit. Niet alleen voor cybercriminelen die herstel willen saboteren, maar ook voor aanvallers die juist veel data in één keer zoeken. Een back-up bevat vaak complete datasets, inclusief persoonsgegevens, financiële informatie en interne documenten. Daarom moet beveiliging hier minstens zo streng zijn als in de productieomgeving.

Versleuteling is de basis, maar niet voldoende. U wilt ook strikte toegangscontrole, logging, multifactor-authenticatie voor beheerders en een scheiding tussen productie en back-upomgeving. Immutable opslag kan nuttig zijn tegen ransomware, maar het lost privacyvragen niet vanzelf op. Ook een onveranderbare back-up moet passen binnen uw bewaarbeleid.

Verder is testen essentieel. Een niet-geteste back-up is een aanname. En een restore zonder controle kan oude, foutieve of verwijderde persoonsgegevens terugzetten. Juist daarom hoort bij een goed GDPR en back-up beleid ook een herstelprocedure met validatie, niet alleen een technische restoreknop.

Hoe u een praktisch beleid opstelt

Begin klein, maar wel concreet. Breng eerst in kaart welke systemen persoonsgegevens bevatten en welke daarvan in back-upschema’s zitten. Koppel daar per systeem een hersteldoel, retentietermijn en verantwoordelijke aan. Zo voorkomt u dat één generieke regel alles bepaalt.

Leg daarna vast wat het doel van elke back-up is. Is het snelle operationele recovery, bescherming tegen ransomware, wettelijke continuïteit of langetermijnbewaring? Als dat doel niet helder is, wordt ook de bewaartermijn willekeurig.

Beschrijf vervolgens hoe u omgaat met toegangsrechten, encryptie, opslaglocaties en leveranciers. Werk ook een procedure uit voor datalekken, verwijderverzoeken en restores. Dat hoeft geen juridisch boekwerk te zijn. Een helder, uitvoerbaar document is waardevoller dan een dik beleid dat niemand gebruikt.

Voor veel organisaties is dit het moment waarop technische en juridische verantwoordelijkheid samenkomen. IT weet hoe back-ups werken, management bepaalt risicoacceptatie en privacyverantwoordelijken bewaken de kaders. Pas als die drie op elkaar aansluiten, werkt het beleid echt.

Wanneer het verstandig is om uw aanpak te herzien

Als uw bedrijf snel is gegroeid, meerdere cloudplatformen gebruikt of ooit back-ups heeft ingericht en daarna nooit meer heeft geëvalueerd, is herziening meestal geen overbodige luxe. Dat geldt ook na een migratie, overname, ransomware-incident of wijziging in bewaarplichten.

In de praktijk zien we vaak dat bedrijven veel meer data back-uppen dan ze denken, met te brede rechten en te weinig onderscheid tussen kritieke systemen en randdata. Dat maakt herstel trager, compliance lastiger en risico’s groter. Een gerichte herziening levert dan niet alleen juridische duidelijkheid op, maar vaak ook lagere opslagkosten en sneller herstel.

Wie dit goed wil aanpakken, doet er verstandig aan om techniek, continuïteit en privacy niet los van elkaar te behandelen. Daar zit precies de winst: minder ruis, minder risico en sneller handelen als het echt nodig is. Een back-upbeleid moet niet alleen veilig zijn op papier, maar vooral kloppen op de dag dat uw organisatie ervan afhankelijk is.