Hoe houd je een IT-herstelplan actueel bij veranderende systemen?

Verouderd IT-herstelplan? Ontdek wanneer, hoe en door wie je plan actueel houdt bij veranderende systemen.

Opengeslagen IT-herstelmap op modern bureau met sticky notes, laptop met systeemdiagrammen en kalender met revisiedata.

Een IT-herstelplan blijft alleen bruikbaar als je het actief bijhoudt. De vuistregel is dat je het plan minstens één keer per jaar formeel herziet, maar in de praktijk vraagt elke significante systeemwijziging om een directe update. Hoe je dat gestructureerd aanpakt, welke wijzigingen de meeste impact hebben en wie daarvoor verantwoordelijk is, lees je hieronder.

Hoe vaak moet je een IT-herstelplan herzien?

Een IT-herstelplan moet minimaal één keer per jaar worden herzien, aangevuld met een update na elke grote systeemwijziging, migratie of organisatorische verandering. Een jaarlijkse cyclus is een goed basisritme, maar in organisaties met een dynamische IT-omgeving is dat lang niet altijd voldoende om het plan actueel te houden.

In de praktijk zijn er twee soorten herzieningen die je naast elkaar organiseert. De eerste is een periodieke review, die je inplant als vast moment in het jaar, bij voorkeur gekoppeld aan een ander planningsmoment zoals de jaarlijkse IT-audit of budgetcyclus. De tweede is een event-driven update, die je uitvoert zodra er iets verandert in de systemen, infrastructuur of bedrijfsprocessen die in het plan zijn opgenomen.

Organisaties die werken met cloudplatforms, SaaS-applicaties of hybride omgevingen merken dat hun IT-landschap sneller verandert dan vroeger. In dat geval is een halfjaarlijkse formele review realistischer dan een jaarlijkse. Het plan bijwerken na elke sprint of release is doorgaans niet haalbaar, maar een kwartaalcheck op de meest kritieke onderdelen wel.

Welke systeemwijzigingen maken je herstelplan direct verouderd?

Niet elke wijziging maakt je herstelplan direct onbruikbaar, maar sommige veranderingen hebben zoveel impact op herstelprocessen dat een directe update noodzakelijk is. Denk aan migraties naar de cloud, nieuwe back-uparchitecturen, wijzigingen in kritieke applicaties of aanpassingen in identiteitsbeheer.

De wijzigingen die het grootste effect hebben op de bruikbaarheid van een herstelplan zijn:

Migratie van on-premise systemen naar een cloudplatform of hybride omgeving
Vervanging of uitbreiding van back-upoplossingen en opslaglocaties
Wijzigingen in kritieke bedrijfsapplicaties, inclusief nieuwe SaaS-tools
Aanpassingen in identiteits- en toegangsbeheer, zoals een nieuwe directory of MFA-implementatie
Organisatorische veranderingen zoals fusies, overnames of het uitbesteden van IT-functies
Nieuwe of gewijzigde koppelingen tussen systemen en externe partijen

Wat deze wijzigingen gemeen hebben, is dat ze de herstelketen beïnvloeden. Als een systeem dat eerder on-premise stond nu in de cloud draait, veranderen de herstelstappen, de verantwoordelijkheden en de verwachte hersteltijd. Een plan dat nog uitgaat van de oude situatie geeft je team verkeerde instructies op het moment dat het er echt toe doet.

Bij OpenSight brengen we bij het inrichten van een cyber resilience platform altijd eerst in kaart welke systemen en applicaties écht kritiek zijn voor de bedrijfsvoering. Dat is ook het startpunt voor een goed onderhoudbaar herstelplan.

Hoe koppel je wijzigingsbeheer aan je IT-herstelplan?

Je koppelt wijzigingsbeheer aan je IT-herstelplan door herstelplan-impact op te nemen als vast onderdeel van je change management proces. Elke wijziging die door de change advisory board of het IT-team wordt goedgekeurd, moet worden beoordeeld op de vraag of het herstelplan aanpassing vereist.

In de praktijk werkt dit het beste met een eenvoudige impactcheck als standaardstap in je wijzigingsprocedure. Stel bij elke change request de vraag: raakt deze wijziging aan een systeem, applicatie of proces dat is opgenomen in het herstelplan? Is het antwoord ja, dan wordt een update van het plan automatisch onderdeel van de implementatietaak, niet iets dat achteraf wordt opgepakt.

Een handige manier om dit te organiseren is door in je IT-documentatie een expliciete koppeling te leggen tussen de componentenlijst in het herstelplan en de assets in je CMDB of asset management systeem. Zo zie je direct welke wijzigingen relevant zijn en hoef je niet bij elke change handmatig te beoordelen of het plan geraakt wordt.

Voor organisaties die werken met GRC-tooling biedt dit extra voordeel: je kunt de koppeling tussen wijzigingsbeheer en herstelplanning formaliseren als een beheersmaatregel binnen je risicomanagement. Dat maakt het ook zichtbaar voor auditors en compliance-verantwoordelijken.

Wie is verantwoordelijk voor het bijhouden van een IT-herstelplan?

De verantwoordelijkheid voor het bijhouden van een IT-herstelplan ligt bij een aangewezen eigenaar, meestal de IT-manager, CISO of een functioneel equivalent. Zonder een benoemde eigenaar raakt het onderhoud van het plan structureel achter, ongeacht hoe goed de initiële opzet was.

In de meeste organisaties is de praktische uitvoering een gedeelde verantwoordelijkheid. De planeigenaar bewaakt het proces en de actualiteit van het document. Systeembeheerders en applicatiebeheerders zijn verantwoordelijk voor de technische details van hun eigen onderdelen. De directie of het management is verantwoordelijk voor de kaders: welke systemen zijn bedrijfskritiek, wat zijn acceptabele hersteltijden en welke middelen zijn beschikbaar?

Voor organisaties zonder een fulltime CISO of security manager is een externe CISO of CTO een praktische manier om dit eigenaarschap te beleggen zonder dat het intern een losse verantwoordelijkheid wordt die niemand echt oppakt.

Hoe test je of een bijgewerkt herstelplan nog werkt?

Je test een bijgewerkt IT-herstelplan door regelmatig herstelscenario’s te simuleren, variërend van een papieren walkthrough tot een volledige technische hersteltest. Alleen testen geeft je zekerheid dat de stappen in het plan nog kloppen met de werkelijke situatie van je systemen.

Er zijn drie niveaus van testen die je kunt inzetten, oplopend in intensiteit:

Tabeltoets (tabletop exercise): Het team bespreekt stap voor stap wat er zou gebeuren bij een herstelscenario, zonder systemen daadwerkelijk te herstellen. Dit is laagdrempelig en geschikt om gaten in het plan te ontdekken.
Gedeeltelijke hersteltest: Je herstelt een specifiek systeem of dataset in een testomgeving om te controleren of de back-up werkt en de herstelprocedure klopt. Dit geeft technische zekerheid zonder impact op de productieomgeving.
Volledige hersteltest: Je simuleert een volledig uitvalscenario en herstelt de kritieke systemen zoals dat in een echte situatie zou gaan. Dit is de meest betrouwbare test, maar vraagt ook de meeste voorbereiding en capaciteit.

Na elke test documenteer je de bevindingen en verwerk je verbeterpunten direct in het plan. Een test die geen actiepunten oplevert, is zelden een teken dat alles perfect is. Het is vaker een teken dat de test niet diepgaand genoeg was.

Het concept van de Minimum Viable Company is hierbij een nuttig kader: focus je hersteltest op de minimale set systemen en processen die je organisatie nodig heeft om operationeel te blijven. Dat maakt testen haalbaar en gericht.

Wat is het verschil tussen een IT-herstelplan en een business continuity plan?

Een IT-herstelplan richt zich op het technisch herstellen van systemen en data na een verstoring. Een business continuity plan (BCP) richt zich op het operationeel houden van de gehele organisatie tijdens en na een verstoring, inclusief mensen, processen, communicatie en alternatieve werkwijzen. Het IT-herstelplan is daarmee een onderdeel van het bredere BCP.

Het onderscheid wordt duidelijk als je kijkt naar wat elk plan regelt. Het IT-herstelplan beantwoordt vragen als: hoe snel kunnen we dit systeem herstellen, wie voert de herstelstappen uit en waar staan de back-ups? Het BCP beantwoordt vragen als: hoe blijven onze klanten bediend, hoe communiceren we intern en extern, en welke processen kunnen tijdelijk anders worden uitgevoerd?

In de praktijk zien we bij veel organisaties dat het IT-herstelplan redelijk is uitgewerkt, maar dat het BCP ontbreekt of op papier bestaat zonder dat het is afgestemd op de actuele situatie. Dat is een gemiste kans, omdat de waarde van een goed IT-herstelplan pas volledig tot zijn recht komt als het is ingebed in een bredere continuïteitsstrategie.

Voor organisaties die werken met Microsoft 365 en cloudgebaseerde werkplekken is het ook relevant om te kijken naar herstel en compliance binnen Microsoft 365 als specifiek onderdeel van zowel het IT-herstelplan als het bredere BCP.

Hoe OpenSight helpt bij het actueel houden van je IT-herstelplan

Wij helpen organisaties om hun IT-herstelplan niet als een eenmalig document te behandelen, maar als een levend onderdeel van hun bredere continuïteitsstrategie. Dat begint met het in kaart brengen van de kritieke systemen en processen, het koppelen van herstelplanning aan wijzigingsbeheer en het inrichten van een testcyclus die haalbaar is voor de organisatie.

Onze aanpak combineert strategisch advies met praktische uitvoering. We helpen bij het definiëren van hersteldoelstellingen, het beoordelen van de huidige back-up- en herstelarchitectuur en het afstemmen van IT-herstelplanning op de bredere bedrijfscontinuïteit. Daarbij kijken we altijd naar de combinatie van mensen, processen en technologie, niet alleen naar de technische kant.

Wil je weten hoe jouw organisatie er nu voor staat? Vraag een risk assessment aan en we kijken samen waar de grootste verbeterkansen liggen.