Hoe toon je back-ups én een hersteltest aan een klant?

Laatst gecontroleerd: 12 juli 2026

Kort antwoord

Een groen back-updashboard toont meestal dat een back-uptaak is uitgevoerd. Het bewijst niet automatisch dat:

• alle relevante systemen en gegevens binnen scope vallen;
• de gemaakte kopie bruikbaar en intact is;
• herstel binnen de afgesproken tijd lukt;
• de juiste versie kan worden teruggezet;
• de herstelprocedure bekend is;
• fouten daadwerkelijk worden opgevolgd.

Sterker klantbewijs combineert daarom back-upinrichting, duidelijke scope, recente taakresultaten, foutopvolging en een aantoonbare hersteltest.

De kern is eenvoudig:

Een back-up is pas echt bruikbaar als je weet wat je kunt terugzetten, hoe je dat doet en wat de laatste test heeft aangetoond.

Krijg je deze vraag in een securityvragenlijst? Bekijk dan ook welke bewijsstukken je veilig kunt meesturen of laat de concrete securityvragenlijst beoordelen.

Back-up, verificatie en hersteltest zijn niet hetzelfde

Gebruik deze begrippen niet door elkaar.

Het NCSC adviseert niet alleen monitoring van back-ups, maar ook periodiek werkelijk herstel te testen. Dat kan steekproefsgewijs voor bestanden of uitgebreider voor een volledig systeem. De passende omvang en frequentie hangen af van risico, klantafspraken, techniek en bedrijfsimpact.

Bepaal de scope voordat je bewijs verzamelt

Een klantvraag als “Do you have backups?” is te breed om zonder context te beantwoorden.

Leg minimaal vast:

• welke applicaties;
• welke databases;
• welke bestanden en gegevenscategorieën;
• welke SaaS-diensten;
• welke apparaten en servers;
• productie-, test- en ontwikkelomgevingen;
• configuraties en infrastructuurinstellingen;
• locaties en opslagvormen;
• welke data van de klant in scope valt;
• wie verantwoordelijk is;
• welke onderdelen bewust buiten scope zijn.

Een voorbeeld van een bruikbare scope:

Dit bewijs betreft de productiegegevens en configuraties van de geleverde SaaS-dienst. Lokale werkstations en persoonlijke archieven vallen buiten deze klantgerichte scope en worden via een afzonderlijk proces beheerd.

Let op SaaS: het feit dat een cloudleverancier zijn platform technisch beschikbaar houdt, betekent niet automatisch dat jouw organisatie een aparte herstelmogelijkheid heeft voor verwijderde of gewijzigde gegevens. Beschrijf alleen wat daadwerkelijk is ingericht.

Welke bewijsstukken kunnen bruikbaar zijn?

Gebruik bewijs bij voorkeur in lagen:

1. een korte managementsamenvatting;
2. een scope- en dekkingsmatrix;
3. recente taak- en foutinformatie;
4. een hersteltestverslag;
5. open punten en roadmap.

Wat hoort in een hersteltestverslag?

Een klant hoeft niet je volledige technische draaiboek te ontvangen. Een deelbaar testverslag kan compact zijn, maar moet voldoende context bevatten.

Neem minimaal op:

• datum van de test;
• doel van de test;
• systeem, applicatie of dataset;
• testscope;
• gebruikte back-updatum of herstelpunt;
• herstelomgeving;
• uitvoerder en verantwoordelijke;
• gebruikte procedure;
• resultaat;
• gemeten duur;
• controle of de data bruikbaar en intact was;
• afwijkingen en fouten;
• open punten;
• eigenaar van verbeteracties;
• vervolgstap;
• geplande volgende test of besluitmoment.

Een eenvoudige tabel werkt goed:

Noem alleen een resultaat dat echt is gemeten. “De restore zou ongeveer twee uur duren” is geen testuitkomst.

RPO en RTO praktisch uitgelegd

Recovery Point Objective (RPO)

RPO gaat over hoeveel gegevensverlies je maximaal als doel accepteert, uitgedrukt in tijd.

Voorbeeld:

• back-up elke nacht;
• incident om 16:00;
• laatste bruikbare kopie van 03:00;
• mogelijk gegevensverlies: ongeveer dertien uur.

Dat is een analyse van het gekozen herstelpunt, niet automatisch een formeel goedgekeurde RPO.

Recovery Time Objective (RTO)

RTO gaat over de gewenste tijd waarbinnen een proces, systeem of dienst na verstoring moet kunnen herstellen.

Een RTO is een doelstelling. Een gemeten hersteltijd uit een test is een feitelijke testuitkomst. Verwar deze niet.

Gebruik richting een klant bijvoorbeeld:

Voor deze dienst is een hersteldoelstelling vastgelegd. De laatste beperkte hersteltest duurde [gemeten duur] en dekte [scope]. Een volledige uitwijktest is niet uitgevoerd en wordt daarom niet geclaimd.

Noem geen theoretische RPO of RTO alleen omdat een template erom vraagt. Waarden moeten passen bij risico, contract, techniek en werkelijk geteste mogelijkheden.

Wat moet je niet delen?

Scherm minimaal af:

• volledige klantdata;
• echte persoonsgegevens uit een herstelde dataset;
• credentials en herstelaccounts;
• storage keys en tokens;
• private endpoints;
• volledige infrastructuurdiagrammen;
• exacte opslaglocaties wanneer die niet nodig zijn;
• interne IP-adressen;
• ongeredigeerde bestandslijsten;
• volledige foutlogs;
• technische kwetsbaarheden zonder noodzaak;
• namen van andere klanten;
• gegevens van medewerkers;
• malware- of incidentdetails die nieuwe risico’s veroorzaken.

Gebruik voor hersteltests bij voorkeur:

• synthetische testdata;
• geanonimiseerde data;
• een beperkte steekproef;
• een afgeschermde testomgeving;
• screenshots waarin inhoudelijke gegevens niet leesbaar zijn.

Wat als nog nooit een echte hersteltest is uitgevoerd?

Zeg dan niet dat back-ups “regelmatig getest” worden wanneer alleen de back-uptaak of integriteitscontrole is bekeken.

Gebruik deze structuur:

1. Feitelijke status: welke back-ups bestaan?
2. Scope: welke systemen vallen eronder?
3. Beschikbaar bewijs: welke taak- en configuratierapportage bestaat?
4. Beperking: er is nog geen gedocumenteerde hersteltest.
5. Tijdelijke risicobeperking: monitoring, verificatie of leverancierscontrole.
6. Geplande test: doel en afgebakende scope.
7. Eigenaar: wie voert uit en keurt goed?
8. Streefdatum: realistisch en intern gedragen.
9. Toekomstig bewijs: welk verslag wordt na afloop vastgelegd?

Voorbeeldantwoord: back-up aanwezig, hersteltest ontbreekt

Voor de in scope opgenomen systemen zijn geautomatiseerde back-ups ingericht en worden taakresultaten gecontroleerd. Er is nog geen recent, formeel hersteltestverslag beschikbaar. Daarom claimen wij niet dat volledig herstel al aantoonbaar is getest. Een afgebakende hersteltest wordt gepland; datum, scope, resultaat en verbeterpunten worden daarna vastgelegd.

Voorbeeldantwoord: gedeeltelijke dekking

Back-ups zijn ingericht voor de productiegegevens en de primaire configuraties. Twee ondersteunende systemen vallen nog niet onder dezelfde centrale rapportage. Deze beperking is als open punt geregistreerd en wordt meegenomen in de uitbreiding van de back-upscope.

Voorbeeldantwoord: klantvraag is te breed

Kunt u aangeven of u bewijs verwacht voor de geleverde dienst, voor klantdata of voor onze volledige interne IT-omgeving? Wij kunnen vervolgens de toepasselijke scope, recente taakresultaten en beschikbare hersteltestinformatie aanleveren.

Lees bij een onvolledige situatie ook hoe je een gedeeltelijk antwoord onderbouwt.

Hoe vaak moet je een hersteltest uitvoeren?

Er bestaat geen universele frequentie die voor iedere organisatie, ieder systeem en ieder klantcontract passend is.

Bepaal de frequentie op basis van:

• kritikaliteit van het proces;
• snelheid waarmee data verandert;
• gevolgen van uitval;
• contractuele afspraken;
• wijzigingen in applicatie of infrastructuur;
• eerdere testbevindingen;
• wettelijke bewaareisen;
• leveranciersafhankelijkheid;
• beschikbare herstelomgeving;
• risico op ransomware of misbruik.

Test daarnaast opnieuw na ingrijpende veranderingen, zoals een migratie, nieuwe back-upsoftware, gewijzigde encryptie, een andere opslaglocatie of een grote architectuurwijziging.

Praktische checklist vóór verzending

• De klantvraag en bedoelde scope zijn duidelijk.
• De dekkingsmatrix is actueel.
• Recente succesvolle én mislukte taken zijn beoordeeld.
• Foutopvolging is aantoonbaar.
• Retentie en herstelpunten zijn correct beschreven.
• Er is onderscheid tussen verificatie en echt herstel.
• Het testverslag bevat datum, scope, resultaat en afwijkingen.
• RPO/RTO worden alleen genoemd als ze echt zijn vastgesteld.
• Testdata en screenshots bevatten geen gevoelige informatie.
• Open punten hebben eigenaar en vervolgstap.
• De klantversie is intern gecontroleerd.

Wanneer is technische of juridische hulp nodig?

Betrek je IT-partner wanneer niet duidelijk is welke gegevens werkelijk worden geback-upt, hoe encryptie en toegangsbeheer zijn ingericht of hoe een veilige hersteltest kan worden uitgevoerd.

Laat contractuele herstelgaranties, aansprakelijkheid, vaste responstijden of sectorspecifieke bewaarplichten apart beoordelen. Een technische test bewijst niet automatisch dat een contractuele of wettelijke verplichting volledig is ingevuld.

Bronnen en actuele informatie

Geraadpleegd op 12 juli 2026:

• NCSC — Een back-up strategie opstellen: https://www.ncsc.nl/back-up/een-back-up-strategie-opstellen
• NCSC — Basisprincipe 5: Bereid je voor op incidenten: https://www.ncsc.nl/basisprincipes/basisprincipe-5-bereid-je-voor-op-incidenten
• NCSC — Verdiepende maatregelen voor toeleveranciers: https://www.ncsc.nl/cyberbeveiligingswet-nis2/verdiepende-maatregelen-voor-toeleveranciers
• NCSC — Toeleveranciers van Cbw-organisaties: https://www.ncsc.nl/cyberbeveiligingswet-nis2/toeleveranciers-van-cbw-organisaties

Hulp nodig bij back-up- of herstelbewijs?

Vraagt een klant om back-up- of herstelbewijs? Laat controleren wat je werkelijk kunt aantonen en welke open punten je moet benoemen.

Laat je concrete securityvragenlijst beoordelen

Moet je dezelfde onderbouwing vaker gebruiken? Leg scope, testverslagen en open punten dan gecontroleerd vast in een Cybersecurity Bewijsmap.