IT-continuïteitsplan voor ISO 22301: opzet en voorbeeld

Een IT-continuïteitsplan beschrijft hoe je je IT-systemen herstelt als ze uitvallen, per systeem, met vaste hersteltijden en een vaste volgorde. Het is het IT-deel van het bedrijfscontinuiteitsplan en voedt de business impact analyse. Binnen ISO 22301 hoort het bij de continuïteitsstrategie en de procedures die je moet kunnen laten zien aan een auditor.

Eén IT-continuïteitsplan voor het hele bedrijf werkt meestal niet. Het werkt beter als je per kritiek systeem een korte, uitvoerbare pagina hebt.

Wat is het verschil met een bedrijfscontinuiteitsplan?

Het bedrijfscontinuiteitsplan gaat over de hele organisatie: mensen, locaties, leveranciers en communicatie. Het IT-continuïteitsplan gaat alleen over de technische kant. Het bevat de stappen die een technicus uitvoert, zoals het terugzetten van een database of het omschakelen naar een tweede datacentrum.

Plan	Vraag die het beantwoordt	Wie gebruikt het
Bedrijfscontinuiteitsplan	Hoe blijven we als bedrijf werken?	Management en proceseigenaren
IT-continuïteitsplan	Hoe krijgen we het systeem terug?	IT-beheer en on-call engineers

Disaster recovery, het technisch herstel van systemen, is onderdeel van het IT-continuïteitsplan. Het onderscheid tussen die begrippen staat uitgelegd op ISO 22301 voor IT-bedrijven.

Wat staat er in een IT-continuïteitsplan?

Een bruikbaar plan heeft per systeem dezelfde vaste onderdelen. Zo kan iemand die het systeem niet kent het toch uitvoeren.

Onderdeel	Inhoud	Voorbeeld voor een klantportaal
Systeem en eigenaar	Naam, functie, eigenaar in de organisatie	Klantportaal, eigenaar: hoofd klantenservice
Afhankelijkheden	Welke systemen en leveranciers het nodig heeft	Database, authenticatiedienst, CDN (content delivery network)
MTPD, RTO en RPO	Maximale uitval (MTPD), hersteltijd (RTO) en dataverlies (RPO)	MTPD 24 uur, RTO 4 uur, RPO 1 uur
Herstelstappen	Stap voor stap wat je doet	Database terugzetten vanaf de laatste back-up
Alternatief	Wat je tijdelijk doet	Klanten bellen met een noodnummer
Contactpersonen	Wie je belt, ook buiten kantooruren	Technisch contact en leverancier
Testdatum	Wanneer je het laatst getest hebt	Failover-test (omschakelen naar de standby), maart, resultaat goed

MTPD staat voor maximum tolerable period of disruption, de maximale verstoringsduur. RTO (recovery time objective) is de hersteltijd en RPO (recovery point objective) het dataverlies. Je vult ze niet op gevoel in. Ze komen uit de BIA. Lees bij RTO en RPO uitgelegd hoe je het dataverlies bepaalt.

Voorbeeld van een uitgewerkt systeem

Stel: een softwarebedrijf heeft een klantportaal. De BIA heeft bepaald dat het portaal binnen vier uur terug moet zijn, en dat maximaal één uur aan gegevens verloren mag gaan.

Het plan bevat dan onder meer:

Bij uitval meldt de on-call engineer het incident binnen vijftien minuten in het incidentkanaal.
De engineer controleert of de primaire database beschikbaar is. Is dat niet zo, dan schakelt hij over naar de standby in het tweede datacentrum.
De engineer zet de laatste back-up van maximaal één uur oud terug. Dat bepaalt de RPO.
Het supportteam zet een statuspagina aan en stuurt klanten een bericht.
Na herstel controleert de engineer of de data compleet is en noteert hij het moment waarop het portaal weer werkte. Dat moment is het bewijs voor de RTO.

Let op: dit voorbeeld is fictief. Je bepaalt de hersteltijden zelf, op basis van je eigen BIA en je eigen technische mogelijkheden.

Hoe je het plan opzet

Werk in volgorde van belang. Begin met het systeem dat de meeste schade veroorzaakt bij uitval.

Maak een lijst van alle IT-systemen die een kritiek proces ondersteunen. Gebruik daarvoor de BIA.
Ken per systeem de MTPD, RTO en RPO toe, en laat het management die goedkeuren.
Schrijf per systeem een herstelprocedure van één à twee pagina’s.
Zorg dat minstens één persoon de procedure kan uitvoeren zonder de bedenker.
Test de procedure en leg het resultaat vast.

Veelgemaakte fouten

Fout	Gevolg bij een echte storing	Betere aanpak
Eén algemeen plan voor alle systemen	Niemand weet welk systeem eerst moet	Per systeem een eigen pagina
RTO en RPO zijn niet met de BIA afgestemd	Herstel is technisch niet haalbaar binnen de afspraak	Haal de getallen uit de BIA
Back-ups die nooit zijn teruggezet	Pas bij de echte storing blijkt de back-up onbruikbaar	Zet minstens eens per jaar een back-up terug
Plan staat op een gedeelde schijf die uitvalt	Niemand kan het plan lezen	Print of bewaar een kopie buiten het netwerk

Checklist voor één systeem

Gebruik deze lijst voordat je een systeempagina als klaar beschouwt:

Staat de eigenaar en de vervanger erin genoemd?
Komen MTPD, RTO en RPO exact overeen met de BIA?
Staat elke stap in de volgorde waarin een technicus hem uitvoert?
Staat erin hoe je de back-up controleert, en wanneer je dat voor het laatst deed?
Staat er een tijdelijk alternatief voor gebruikers?
Weet de on-call engineer waar het plan staat als het netwerk uitvalt?
Is het plan in het laatste jaar minstens één keer getest?

Als één van die vragen met nee wordt beantwoord, is het plan nog niet bruikbaar.

Wat auditors controleren

Een auditor kijkt niet alleen of het plan bestaat. Hij vraagt of het klopt met de BIA, of het recent getest is, en of de uitkomsten zijn verwerkt. Bewijs bestaat uit een oefenverslag, een hersteltijdmeting en een actielijst met verbeteringen. Die aanpak past bij oefenen en testen.

Veelgestelde vragen

Moet ik een IT-continuïteitsplan los van het bedrijfscontinuiteitsplan maken? Dat hoeft niet. Het kan een bijlage zijn. Belangrijk is dat de IT-stappen herleidbaar zijn naar de BIA.

Hoe vaak moet het plan worden bijgewerkt? Bij elke grote wijziging in systemen en minimaal jaarlijks. Zie ook de auditeisen.

Is dit hetzelfde als een ISO 27001-continuïteitsplan? Er is overlap, maar de ISO 27001-kant gaat meer over informatiebeveiliging. Lees het verschil bij ISO 22301 vs ISO 27001.

Meer begrippen en antwoorden vind je bij de veelgestelde vragen over ISO 22301.