Continuïteitsplan

Het document dat beschrijft hoe u doorgaat als een kritiek proces uitvalt: wat er dan gebeurt, wie wat doet, en binnen welke tijd u weer draait.

Wat erin hoort

• welke processen kritiek zijn en hoe lang uitval acceptabel is per proces
• hoeveel gegevensverlies u accepteert per proces
• de scenario's waar u zich op voorbereidt
• wie het crisisteam vormt en hoe zij bereikbaar zijn
• hoe u terugvalt op een alternatieve werkwijze
• hoe u communiceert met medewerkers, klanten en toezichthouder
• wanneer het plan beproefd wordt

Wie stelt het vast

Vaststelling gebeurt door het bestuur, want het bevat keuzes over acceptabele schade. Zonder datum en zonder vaststeller heeft een document geen status, en dan telt het bij een controle niet mee als bewijs.

Hoe vaak herzien

Herzien: jaarlijks, en na elke oefening of echt incident. Zet de volgende herzieningsdatum in het document zelf, dan is het bij een controle meteen duidelijk of het actueel is.

Hoe lang moet het zijn

vier tot acht pagina's, met per scenario een korte handelingsvolgorde.

Fouten die er het vaakst in zitten

• Hersteltijden die uit de lucht komen in plaats van uit een test.
• Het plan is geschreven maar nooit geoefend, dus niemand kent zijn rol.
• Alleen ICT-scenario's, terwijl uitval van een leverancier of een locatie even waarschijnlijk is.

Per proces twee getallen

Het hele plan hangt aan twee getallen per kritiek proces. Zet ze in een tabel voordat u iets anders schrijft:

Die getallen bepalen alles: hoe vaak u back-upt, of u een uitwijkomgeving nodig heeft, en hoeveel u daaraan mag uitgeven. Ze horen door het bestuur vastgesteld te worden, want het zijn keuzes over acceptabele schade en niet over techniek.

Herstellen duurt langer dan het systeem terugzetten

De meest gemaakte denkfout in continuïteitsplannen: de hersteltijd wordt gelijkgesteld aan de tijd die het kost om systemen weer aan de praat te krijgen. In werkelijkheid begint daarna het inhalen van de achterstand die tijdens de uitval is ontstaan, en dat duurt vaak langer dan het technisch herstel zelf.

Neem die inhaaltijd expliciet op in uw plan. Twee dagen uitval kan een week nawerking hebben, en dat is de periode waarin uw klanten het merken.

Oefen op een dinsdagochtend

Een oefening hoeft geen dag te kosten. Neem een uur, kies één scenario en loop de handelingsvolgorde door met de mensen die het zouden moeten doen. Wat u zoekt zijn de gaten: een sleutel die niemand heeft, een leverancier die geen 24-uursnummer heeft, een aanname die niet klopt. Die vindt u binnen dat uur.

Verhouding tot de Cyberbeveiligingswet

Kern van maatregel 3, inclusief de eis van crisisbeheer. De wet vraagt niet om een bepaald document, maar om aantoonbare maatregelen. Dit document is de gebruikelijke manier om dat aan te tonen.

Verhouding tot ISO 27001

Bijlage A bevat continuïteitsmaatregelen. NIS2 legt meer nadruk op het daadwerkelijk halen van de hersteltijden. Zie de ISO 27001-checklist voor het volledige overzicht.

Waarom dit plan niet bij ICT hoort te liggen

Het continuïteitsplan wordt vaak opgesteld door dezelfde persoon die ook de systemen beheert, en dat is een risico op zich. De keuzes in dit plan, hoeveel uitval acceptabel is en hoeveel gegevensverlies aanvaardbaar is, zijn geen technische keuzes maar bedrijfsbeslissingen met financiële gevolgen. Die horen bij het bestuur te liggen, ook als een ICT-verantwoordelijke het document opstelt.

Een werkbare verdeling: de ICT-verantwoordelijke of operationeel manager haalt de informatie op en schrijft het concept, het bestuur beoordeelt de getallen per proces en zet zijn handtekening, en diezelfde ICT-verantwoordelijke onderhoudt het plan daarna en agendeert de jaarlijkse update. Zonder die laatste stap ligt een prima plan na twee jaar te verouderen zonder dat iemand dat merkt.

Verschil met het back-upbeleid

Het back-upbeleid wordt vaak als vervanging van het continuïteitsplan gezien, omdat beide over herstel gaan. Het back-upbeleid regelt de techniek van het terugzetten. Het continuïteitsplan regelt de organisatie eromheen: wie doet wat tijdens de uitval zelf, hoe communiceert u naar klanten, en hoe wordt de achterstand na herstel ingehaald. Een organisatie kan een uitstekend back-upbeleid hebben en toch geen idee wie er maandagochtend de telefoon opneemt als het systeem nog een dag plat ligt.

Veelgestelde vragen

Kan ik hiervoor een sjabloon gebruiken?

Als startpunt voor de structuur wel. De inhoud moet over uw organisatie gaan, anders valt het bij de eerste controle door de mand. Een auditor vraagt een medewerker naar iets wat erin staat; kent niemand het, dan is dat een bevinding.

Is dit document wettelijk verplicht?

De Cyberbeveiligingswet schrijft geen documenten voor, maar wel dat u passende maatregelen neemt en kunt aantonen. In de praktijk is vastleggen de enige manier om dat aan te tonen.

Wat is het verschil met een incidentresponsplan?

Het incidentresponsplan gaat over het afhandelen van een beveiligingsincident. Het continuïteitsplan gaat over doorgaan met uw dienstverlening, ook bij oorzaken die niets met beveiliging te maken hebben.

Moet ik voor elk scenario een plan maken?

Nee. Werk met een handvol scenario's die de belangrijkste soorten uitval afdekken: systemen, locatie, mensen, leverancier.

Wie moet het continuïteitsplan uiteindelijk goedkeuren?

Het bestuur, omdat de kern van het plan bestaat uit keuzes over acceptabele schade, en dat is een bestuursbeslissing.

Kan de ICT-afdeling het plan zelf beheren?

Het opstellen en actueel houden mag daar liggen. De inhoudelijke keuzes en de jaarlijkse goedkeuring horen bij het bestuur te blijven.

Wat als het bestuur en ICT het niet eens zijn over de hersteltijd?

Leg dan het kostenplaatje naast elkaar: een kortere hersteltijd kost meestal geld aan uitwijkvoorzieningen. Gebruik de rekentool voor een eerste indicatie. Die afweging hoort bij het bestuur, niet bij de techniek.