Hoe weet je welke data het eerst hersteld moet worden na uitval?

Welke data herstel je eerst na uitval? De bedrijfskundige aanpak die echt werkt.

Netwerkingenieur bestudeert triageboard met prioriteitslabels naast gloeiende serverhardware in donker datacenter.

De data die het eerst hersteld moet worden na uitval, is de data die direct nodig is om je kernprocessen draaiende te houden. Denk aan de systemen en informatie zonder welke je organisatie niet kan factureren, produceren, communiceren of leveren. De herstelvolgorde van data is daarmee geen technische keuze, maar een bedrijfskundige.

Welke systemen dat precies zijn, verschilt per organisatie. Maar de manier waarop je die keuze maakt, is voor elke organisatie gelijk: je begint bij de bedrijfsprocessen, niet bij de techniek. De secties hieronder lopen stap voor stap door hoe je die keuze maakt en hoe je weet of je aanpak in de praktijk ook écht werkt.

Welke systemen en data zijn écht kritiek voor je bedrijfsvoering?

Kritieke systemen en data zijn die onderdelen van je IT-omgeving zonder welke je primaire bedrijfsprocessen tot stilstand komen. Denk aan je ERP-systeem, je orderbeheer, je klantenbestand, je financiële administratie of je productieaansturing. Als één van die systemen wegvalt en je kunt niet meer leveren, factureren of communiceren, dan is dat systeem kritiek.

Een veelgemaakte fout is om de lijst met “kritieke systemen” samen te stellen op basis van wat technisch het meest complex is, of wat het meeste kost. Maar de juiste vraag is: wat moet er minimaal beschikbaar zijn om als organisatie operationeel te blijven?

Dat inzicht staat centraal in het concept van de Minimum Viable Company: de minimale set aan systemen, applicaties en processen die je nodig hebt om te blijven functioneren. Door die set expliciet te benoemen, weet je precies welke data als eerste hersteld moet worden en welke systemen later kunnen volgen.

Nuttige vragen om kritieke data te identificeren:

Welke processen mogen absoluut geen dag stilliggen?
Welke data heb je nodig om klanten te bedienen of producten te leveren?
Welke systemen zijn afhankelijk van andere systemen?
Waar liggen contractuele of wettelijke verplichtingen rondom beschikbaarheid?

Hoe bepaal je de herstelvolgorde van data na een incident?

De herstelvolgorde van data na een incident bepaal je door systemen en datasets te rangschikken op basis van hun impact op de bedrijfsvoering. Systemen die direct nodig zijn voor primaire processen krijgen de hoogste prioriteit. Systemen die ondersteunend zijn of later in het proces een rol spelen, komen daarna.

In de praktijk werkt dat als volgt: je maakt een overzicht van alle systemen en koppelt daar een prioriteitsniveau aan. Niveau één zijn de systemen die direct hersteld moeten worden, niveau twee volgt zodra de kern stabiel staat, niveau drie kan wachten tot de acute fase voorbij is.

Daarbij is de volgorde van herstel ook technisch relevant. Sommige applicaties zijn afhankelijk van een database of authenticatiesysteem. Als je die afhankelijkheden niet meeneemt in je herstelplan, herstel je misschien een applicatie die vervolgens niet werkt omdat een onderliggende service nog niet beschikbaar is.

Een gestructureerd cyber resilience platform helpt bij het inzichtelijk maken van die afhankelijkheden en het automatiseren van herstelstappen in de juiste volgorde.

Wat is het verschil tussen RTO en RPO bij dataherstel?

RTO staat voor Recovery Time Objective: de maximale tijd die je accepteert voordat een systeem of dienst weer beschikbaar is. RPO staat voor Recovery Point Objective: de maximale hoeveelheid data die je bereid bent te verliezen, uitgedrukt in tijd. Als je RPO vier uur is, betekent dat dat je back-ups maximaal vier uur oud mogen zijn op het moment van herstel.

Beide begrippen zijn essentieel bij het bepalen van dataherstelprioriteiten, maar ze beantwoorden een andere vraag. RTO gaat over de snelheid van herstel. RPO gaat over hoeveel dataverlies acceptabel is.

Voor kritieke systemen wil je zowel een lage RTO als een lage RPO. Dat betekent dat je back-ups frequent gemaakt worden én dat je snel kunt herstellen. Voor minder kritieke systemen kun je hogere waarden accepteren, wat ook ruimte geeft om kosten en inspanning te beheersen.

Het is verstandig om voor elk systeem in je omgeving de RTO en RPO expliciet te definiëren. Dat dwingt je om na te denken over wat écht kritiek is, en het geeft je herstelteam concrete doelstellingen om naartoe te werken.

Welke rol speelt een business impact analysis bij herstelprioritering?

Een business impact analysis (BIA) is de methodiek waarmee je in kaart brengt wat de gevolgen zijn van uitval van specifieke systemen of processen. De BIA vormt de inhoudelijke basis voor je herstelprioritering: zonder dit inzicht weet je niet welke systemen écht kritiek zijn en welke RTO en RPO per systeem realistisch zijn.

Een BIA kijkt naar meerdere dimensies van impact: operationele verstoring, financiële schade, reputatieschade, contractuele verplichtingen en compliance-eisen. Door die impact per systeem te kwantificeren, kun je een gefundeerde keuze maken over herstelprioriteiten en investeringen in herstelcapaciteit.

In de praktijk wordt een BIA vaak uitgevoerd als onderdeel van een breder traject rondom bedrijfscontinuïteit of disaster recovery planning. De uitkomst is een gerangschikte lijst van processen en systemen, aangevuld met concrete RTO- en RPO-waarden. Dat document vormt vervolgens de leidraad voor je herstelstrategie en back-upbeleid.

Een BIA is geen eenmalige exercitie. Elke keer dat je organisatie groeit, nieuwe systemen introduceert of processen wijzigt, is het verstandig om de analyse opnieuw te doorlopen.

Hoe test je of je herstelprioritering in de praktijk werkt?

Je test je herstelprioritering door regelmatig herstelscenario’s te simuleren en te meten of je binnen de gestelde RTO en RPO kunt herstellen. Zonder testen weet je niet of je plan klopt, of de back-ups bruikbaar zijn en of je team weet wat het moet doen.

Testen kan op verschillende niveaus:

Tabletop oefening: Je loopt met het team een uitvalscenario door op papier. Wie doet wat? In welke volgorde? Waar zitten de onduidelijkheden?
Technische hersteltest: Je herstelt een specifiek systeem of dataset daadwerkelijk vanuit de back-up, in een geïsoleerde omgeving, en meet de tijd en het dataverlies.
Volledige failovertest: Je simuleert een volledige uitval van een kritiek systeem en voert het herstelproces uit zoals je dat in een echte situatie zou doen.

De uitkomst van elke test geeft je concrete verbeterpunten: back-ups die niet volledig bleken, afhankelijkheden die over het hoofd waren gezien, of herstelstappen die onduidelijk waren gedocumenteerd. Jaarlijks testen is een minimum; voor kritieke systemen is halfjaarlijks of kwartaaltests beter.

Vergeet ook de identiteitslaag niet. Als accounts en toegangsrechten niet tijdig hersteld worden, kun je een systeem technisch terugzetten maar er alsnog niet in. Herstel van identiteiten en toegang is een onderdeel dat in herstelplannen regelmatig over het hoofd wordt gezien.

Hoe OpenSight helpt bij dataherstel en herstelprioritering

Wij helpen organisaties om van een abstracte herstelstrategie naar een concreet en getest herstelplan te komen. Dat begint bij het in kaart brengen van kritieke systemen en processen, het bepalen van realistische RTO- en RPO-waarden en het uitvoeren van een business impact analysis die aansluit bij de bedrijfsdoelstellingen van de organisatie.

Vanuit die basis bouwen we samen aan een herstelstrategie die ook in de praktijk werkt: met de juiste technologie, heldere procedures en periodieke tests die bevestigen dat het plan uitvoerbaar is. We werken daarbij met bewezen technologiepartners en houden rekening met de specifieke omgeving van de organisatie, of het nu gaat om Microsoft 365, cloudomgevingen, compliance en recovery voor Microsoft 365 of hybride infrastructuren.

Wil je weten hoe jouw organisatie er op dit moment voorstaat? Vraag een risk assessment aan en we kijken samen waar de prioriteiten liggen.