Je kunt controleren of je back-ups werken door ze regelmatig te testen via een hersteltest: zet een back-up terug in een geïsoleerde omgeving en verifieer of de herstelde data compleet en bruikbaar is. Alleen een succesvolle hersteltest bewijst dat een back-up daadwerkelijk werkt. Het bestaan van een back-up is geen garantie voor herstel.
Dit geldt voor elke organisatie die afhankelijk is van digitale systemen, van kleine ICT-bedrijven tot zorgorganisaties. Back-upverificatie is bovendien een expliciete vereiste binnen normen als ISO 27001 en NEN-7510. In dit artikel beantwoorden we de meest gestelde vragen over back-up controleren, testen en rapporteren.
Waarom is het testen van back-ups niet hetzelfde als het maken ervan?
Een back-up maken betekent dat data gekopieerd wordt naar een ander opslagmedium of locatie. Een back-up testen betekent dat je verifieert of die data ook daadwerkelijk teruggeplaatst kan worden en bruikbaar is. Zonder hersteltest weet je niet of je back-up werkt, alleen dat hij bestaat.
Dit onderscheid is cruciaal. In de praktijk blijkt dat back-ups om uiteenlopende redenen kunnen falen zonder dat dit direct zichtbaar is. De back-upjob geeft een groen vinkje, maar de data is corrupt, onvolledig of niet leesbaar in het formaat dat nodig is voor herstel. Pas bij een daadwerkelijke calamiteit, precies het moment waarop je de back-up nodig hebt, ontdek je dat er iets mis is gegaan.
Denk aan het verschil tussen een brandblusser ophangen en controleren of hij ook werkt. Het ophangen geeft een gevoel van veiligheid, maar alleen een test bewijst dat de beveiliging functioneert. Hetzelfde principe geldt voor back-upverificatie: het proces is pas compleet als herstel is aangetoond, niet alleen opslag.
Hoe voer je een hersteltest uit voor back-ups?
Een hersteltest voer je uit door een back-up terug te zetten in een geïsoleerde testomgeving, te controleren of de data volledig en integer is, en te verifiëren of systemen en applicaties normaal functioneren na het herstel. Doe dit altijd buiten de productieomgeving om risico op verstoring te vermijden.
Een gestructureerde hersteltest volgt deze stappen:
- Kies een representatieve back-up: test niet alleen de meest recente back-up, maar ook oudere versies om te controleren of de retentie correct werkt.
- Herstel in een geïsoleerde omgeving: gebruik een testserver, een virtuele machine of een aparte cloudomgeving die losstaat van productie.
- Verifieer de volledigheid van de data: controleer of alle verwachte bestanden, databases en configuraties aanwezig zijn.
- Test de functionaliteit: start applicaties op, voer basisfuncties uit en controleer of de herstelde omgeving zich gedraagt zoals verwacht.
- Meet de hersteltijd: noteer hoe lang het herstel duurde en vergelijk dit met de Recovery Time Objective (RTO) van je organisatie.
- Documenteer de uitkomst: leg vast wat getest is, wat het resultaat was en welke afwijkingen zijn geconstateerd.
Een hersteltest hoeft niet altijd een volledig systeemherstel te zijn. Voor grote omgevingen kun je ook werken met steekproefsgewijs bestandsherstel of databaseherstel op tabelleniveau, zolang de test maar aantoont dat de back-up bruikbaar is.
Wat zijn de meest voorkomende oorzaken van een falende back-up?
De meest voorkomende oorzaken van een falende back-up zijn opslagproblemen, onjuiste configuratie, onvolledige back-upscope, softwarefouten en het ontbreken van verificatie na het maken van de back-up. Veel van deze oorzaken zijn pas zichtbaar bij een herstelpoging.
Hieronder staan de meest voorkomende problemen uitgewerkt:
- Opslagmedium vol of defect: back-upjobs mislukken stil wanneer de doelschijf of opslaglocatie vol is, zonder dat beheerders een melding ontvangen.
- Verkeerde scope: niet alle kritieke systemen, databases of mappen zijn opgenomen in de back-upconfiguratie. Nieuwe systemen worden regelmatig vergeten.
- Versleuteling of compressie zonder sleutelbeheer: back-ups zijn versleuteld, maar de sleutels zijn niet beschikbaar of verlopen op het moment van herstel.
- Softwarefouten of versie-incompatibiliteit: een update van de back-upsoftware of het besturingssysteem kan herstelprocedures breken.
- Geen offsite of offline kopie: bij ransomware worden ook gekoppelde back-upschijven versleuteld. Zonder een airgapped of offsite kopie is herstel onmogelijk.
- Gebrek aan monitoring: back-upjobs worden niet actief gemonitord, waardoor mislukte jobs wekenlang onopgemerkt blijven.
Het goede nieuws is dat de meeste van deze oorzaken te voorkomen zijn met een combinatie van automatische monitoring, periodieke hersteltests en een gedocumenteerde back-upstrategie die regelmatig wordt geëvalueerd.
Welke back-upgegevens moet je vastleggen en rapporteren?
Je moet minimaal vastleggen: welke systemen geback-upt zijn, wanneer de back-up heeft plaatsgevonden, of de back-upjob succesvol was, hoe groot de back-up is, en wat de uitkomst was van de meest recente hersteltest. Deze gegevens vormen de basis voor aantoonbare back-upbeheersing.
Voor organisaties die werken onder een norm als ISO 27001 of NEN-7510 is documentatie geen bijzaak, maar een vereiste. Goede rapportage maakt het mogelijk om trends te signaleren, afwijkingen tijdig op te pakken en bij een audit aan te tonen dat back-ups structureel worden beheerd.
Een compleet back-uplogboek bevat idealiter:
- Datum en tijdstip van de back-upjob
- Naam van het systeem of de applicatie
- Resultaat van de job (geslaagd, mislukt, gedeeltelijk)
- Omvang van de back-up en eventuele afwijkingen ten opzichte van vorige runs
- Locatie van de back-up (lokaal, offsite, cloud)
- Datum en resultaat van de laatste hersteltest
- Naam van de verantwoordelijke medewerker
Rapporteer dit minimaal maandelijks aan de systeembeheerder of Security Officer, en zorg dat uitzonderingen direct worden geëscaleerd.
Hoe vaak moeten back-ups getest worden volgens ISO 27001?
ISO 27001 schrijft geen vaste testfrequentie voor, maar vereist wel dat back-upherstel periodiek wordt getest en gedocumenteerd als onderdeel van de beheersmaatregel voor back-ups (bijlage A, maatregel 8.13). De frequentie moet aansluiten bij het risicoprofiel van de organisatie en de kritiekheid van de systemen.
In de praktijk hanteren veel organisaties de volgende richtlijn:
- Kritieke systemen (zoals ERP, patiëntendossiers, financiële administratie): minimaal elk kwartaal testen
- Minder kritieke systemen: minimaal één keer per jaar
- Na grote wijzigingen (migratie, update, nieuwe infrastructuur): altijd een hersteltest uitvoeren
De norm kijkt niet alleen naar de frequentie, maar ook naar de kwaliteit van de test en de documentatie ervan. Een jaarlijkse hersteltest die goed gedocumenteerd is en aantoonbaar succesvol was, weegt zwaarder dan vier kwartaaltests waarvan geen resultaten zijn vastgelegd.
Organisaties die ook onder NIS2 vallen, moeten rekening houden met aanvullende eisen rondom bedrijfscontinuïteit en incidentherstel. Meer over de relatie tussen back-upbeheer en NIS2-compliance is te vinden via de normpagina.
Welke tools helpen bij het automatisch controleren van back-ups?
Tools voor automatische back-upcontrole zijn onder andere back-upbeheerplatformen met ingebouwde monitoring en rapportage, cloudback-upoplossingen met verificatiefuncties, en SIEM-systemen die back-uplogboeken analyseren op afwijkingen. De juiste tool hangt af van de infrastructuur en het type back-upoplossing dat je gebruikt.
Veel gebruikte categorieën zijn:
- Back-upsoftware met monitoring: oplossingen zoals Veeam, Acronis of Nakivo bieden ingebouwde dashboards die de status van back-upjobs bewaken en meldingen sturen bij fouten.
- Cloudback-updiensten: platforms als Azure Backup, AWS Backup of Google Cloud Backup bieden automatische verificatie en herstelrapportage als onderdeel van de dienst.
- Centraal logbeheer: door back-uplogs te centraliseren in een SIEM of logmanagementtool kun je patronen detecteren, zoals herhaalde mislukkingen of ontbrekende jobs.
- Automatische hersteltests: sommige enterprise back-upoplossingen ondersteunen sandbox-herstel, waarbij een back-up automatisch wordt teruggezet in een virtuele omgeving en basiscontroles worden uitgevoerd zonder menselijke tussenkomst.
Automatisering vervangt de menselijke controle niet volledig. Stel altijd in dat mislukte jobs een melding sturen naar een verantwoordelijke medewerker, en zorg dat iemand ook daadwerkelijk op die meldingen reageert. Een tool die meldingen stuurt naar een onbeheerd e-mailadres biedt geen echte controle.
Hoe Kwinzo helpt met informatiebeveiliging en back-upbeheer
Back-upbeheer is één onderdeel van een bredere aanpak van informatiebeveiliging. Wij helpen organisaties in zorg, ICT en onderwijs om niet alleen te voldoen aan normen als ISO 27001 en NEN-7510, maar om informatiebeveiliging echt werkend te maken in de dagelijkse praktijk. Dat betekent concrete afspraken over back-ups, hersteltests en documentatie, afgestemd op de specifieke situatie van jouw organisatie.
Wat wij concreet bieden:
- Begeleiding bij het opstellen en implementeren van een back-upbeleid dat voldoet aan ISO 27001 en andere toepasselijke normen
- Ondersteuning bij het documenteren van back-upprocessen en hersteltestresultaten voor auditdoeleinden
- Interne audits waarbij back-upbeheer als onderdeel van het ISMS wordt getoetst door een onafhankelijke consultant
- Maandelijkse kennissessies voor Security Officers, ook over onderwerpen als bedrijfscontinuïteit en back-upverificatie
- Praktische hulpmiddelen via onze eigen ISMS-tool, inclusief templates voor back-upregistratie en rapportage
Informatiebeveiliging hoeft geen papieren exercitie te zijn. Neem contact op via kwinzo.nl/contact voor een vrijblijvend gesprek over hoe wij jouw organisatie kunnen ondersteunen.