Bedrijfscontinuïteit: zo blijft u draaien bij een incident

Bedrijfscontinuïteit is het vermogen van uw organisatie om haar belangrijkste processen te laten doorlopen tijdens een verstoring. Valt een proces toch stil, dan herstelt u het binnen een vooraf afgesproken tijd. De aanpak daarachter heet business continuity management, kortweg BCM.

Het gaat daarbij niet om het voorspellen van rampen. Een verstoring kan een cyberaanval zijn, maar net zo goed een stroomstoring, een uitgevallen cloudleverancier of een pand dat tijdelijk niet bruikbaar is. Bedrijfscontinuïteit gaat over wat u dan doet, wie besluit en in welke volgorde u herstelt.

In dit artikel leest u hoe u bepaalt wat niet mag stilvallen, hoe u een bedrijfscontinuïteitsplan opbouwt en waarom oefenen het meeste oplevert. Ook ziet u wat de Cyberbeveiligingswet en ISO 22301 vragen.

Wat bedrijfscontinuïteit is, en wat niet

Bedrijfscontinuïteit wordt vaak verward met verwante begrippen. Ze horen bij elkaar, maar hebben elk een eigen rol.

• Bedrijfscontinuïteit. Het geheel: zorgen dat de organisatie haar belangrijkste diensten blijft leveren, ook als systemen, mensen of panden uitvallen.
• Disaster recovery. Het herstellen van IT-systemen en gegevens na een uitval. Een onderdeel van bedrijfscontinuïteit, niet hetzelfde.
• Incidentrespons. Het onderzoeken en indammen van een beveiligingsincident, zoals een besmette laptop of een overgenomen account.
• Crisisbeheer. Besluiten nemen en communiceren als een verstoring de hele organisatie raakt.

Het onderscheid is meer dan woordkeus. Wie alleen aan disaster recovery werkt, heeft na een uitval misschien de servers terug. Maar dan weet nog niemand welke klantorders voorgaan, of hoe de telefoon wordt opgenomen terwijl de systemen plat liggen.

De business impact analyse: wat mag niet stilvallen

Alles begint met een business impact analyse (BIA). Daarin bepaalt u per proces wat het kost als het stilvalt, en hoe dat oploopt naarmate de uitval langer duurt. Het NCSC zet de BIA in zijn stappenplan voor een bedrijfscontinuïteitsplan direct na de risicoanalyse.

Kijk daarbij breder dan geld. Een uitgevallen planningssysteem in de thuiszorg raakt cliënten, een stilstaande productielijn raakt leverafspraken en een onbereikbaar klantportaal raakt vertrouwen. Die gevolgen tellen allemaal mee.

De uitkomst is een rangorde. Een handvol processen blijkt kritiek, een groter deel kan een paar dagen wachten, en sommige processen kunnen langer stilliggen dan u had gedacht. Die rangorde bepaalt waar u investeert.

Leg bij elk kritiek proces ook vast waar het van afhankelijk is: systemen, leveranciers, mensen met specifieke kennis en locaties. Daar zit vaak de verrassing, bijvoorbeeld een cloudpakket waar drie afdelingen op leunen zonder dat iemand dat wist.

RTO en RPO: hoe snel terug en hoeveel verlies

Uit de BIA volgen twee doelen per proces of systeem.

• RTO, recovery time objective. De maximale tijd die het herstel mag duren voordat de gevolgen onaanvaardbaar worden. Bijvoorbeeld: het orderportaal moet binnen vier uur weer werken.
• RPO, recovery point objective. Hoeveel gegevens u maximaal mag kwijtraken, uitgedrukt in tijd. Een RPO van een uur betekent dat u hooguit het werk van het laatste uur opnieuw moet doen.

Beide doelen hebben een prijs. Een RTO van minuten vraagt dubbel uitgevoerde systemen, een RTO van een dag laat ruimte voor herstel uit een back-up. Het gesprek over RTO en RPO is daarom een gesprek tussen directie en IT, en niet iets wat IT alleen invult.

Een veelgemaakte fout is RTO en RPO afspreken zonder te testen of ze haalbaar zijn. Pas bij een hersteltest blijkt of vier uur echt vier uur is.

Het bedrijfscontinuïteitsplan: wat erin hoort

Het bedrijfscontinuïteitsplan beschrijft hoe u de kritieke processen uit de BIA overeind houdt en herstelt. Houd het kort genoeg om onder druk te gebruiken. Een plan van tachtig pagina’s leest niemand tijdens een storing.

• Wanneer het plan ingaat. Welke situaties het plan activeren en wie dat besluit.
• Rollen en bereikbaarheid. Wie in het crisisteam zit, wie wie vervangt en hoe u elkaar bereikt als e-mail niet werkt.
• Prioriteiten. De volgorde van herstel, afgeleid uit de BIA, met de RTO en RPO per proces.
• Noodprocedures. Hoe het werk handmatig of op een andere plek doorgaat, zoals orders op papier of een uitwijkwerkplek.
• Communicatie. Wat u wanneer meldt aan medewerkers, klanten, leveranciers en eventueel toezichthouders.
• Contactgegevens. Leveranciers, verzekeraar, IT-dienstverleners en interne sleutelpersonen.

Bewaar het plan ook buiten uw eigen systemen. Ligt het netwerk plat, dan ligt een plan op de netwerkschijf ook plat. Een geprinte versie of een kopie in een aparte omgeving voorkomt dat.

Voor beveiligingsincidenten hoort er een apart draaiboek naast het plan, zie het incident response plan. Het continuïteitsplan regelt het doorwerken, het incidentplan het onderzoeken en indammen.

Disaster recovery en back-ups

Disaster recovery is het technische deel: hoe brengt u systemen en gegevens terug? De basis zijn back-ups, en daar gaat het in de praktijk regelmatig mis. Meestal niet omdat er geen back-up is, maar omdat het herstel nooit is geprobeerd.

Drie vragen helpen. Staat er minstens één kopie los van uw netwerk, zodat een aanval die kopie niet kan versleutelen? Heeft u het herstel recent getest, met een stopwatch erbij? En weet u wat uw cloudleveranciers wel en niet voor u veiligstellen?

Die laatste vraag wordt vaak overgeslagen. Bij veel clouddiensten zorgt de leverancier dat de dienst beschikbaar blijft. Het terugzetten van verwijderde of versleutelde gegevens is dan vaak uw eigen verantwoordelijkheid. Lees de voorwaarden en leg vast wie wat doet.

De crisisorganisatie: wie besluit wat

Een verstoring vraagt snelle besluiten met onvolledige informatie. Leg daarom vooraf vast wie in het crisisteam zit, wie de leiding heeft en welk mandaat het team krijgt. Moet de directeur bij elke uitgave bereikbaar zijn, of heeft het team een eigen budget?

Zorg ook voor een vaste rolverdeling: iemand die besluit, iemand die het technische herstel coördineert, iemand die communiceert en iemand die alles vastlegt. Dat logboek heeft u later nodig voor de evaluatie, en soms voor een melding.

Bij een cyberincident komt er een meldplicht bij. Organisaties onder de Cyberbeveiligingswet melden significante incidenten binnen vaste termijnen, zie de NIS2 meldplicht. Wat u in de eerste uren doet, leest u in gehackt, wat nu.

Testen en oefenen: daar wordt het plan echt

Een plan dat nooit is geoefend, is een aanname. Oefenen hoeft niet groot te beginnen, en drie vormen vullen elkaar aan.

• Tabletop-oefening. Het crisisteam loopt aan tafel een scenario door. Weinig voorbereiding, veel inzicht in wie wat besluit.
• Hersteltest. IT zet een systeem of een set gegevens echt terug en meet hoe lang dat duurt. Zo toetst u uw RTO en RPO.
• Volledige oefening. Een realistisch scenario met meerdere afdelingen tegelijk. Zinvol zodra de eerste twee vormen goed lopen.

Oefen minstens jaarlijks en na elke grote wijziging, zoals een nieuwe leverancier of een verhuizing. Verwerk de lessen direct in het plan, anders oefent u volgend jaar dezelfde fouten.

Bedrijfscontinuïteit in de Cyberbeveiligingswet en ISO 22301

Valt u onder de Cyberbeveiligingswet, de Nederlandse invulling van NIS2, dan is bedrijfscontinuïteit geen keuze. Artikel 9 van het Cyberbeveiligingsbesluit vraagt vastgesteld continuïteitsbeleid, procedures voor herstel en het periodiek controleren van back-ups. Ook een schriftelijk continuïteitsplan, een herstelplan en een plan voor crisisbeheer zijn verplicht, en die test u periodiek. Het plan voor crisisbeheer moet u bovendien beoefenen.

Meer over de zorgplicht uit de Cyberbeveiligingswet staat in de NIS2 zorgplicht. Voor de financiële sector stelt DORA eigen eisen aan de continuïteit van ICT.

Wilt u bedrijfscontinuïteit systematisch inrichten, dan is ISO 22301 de internationale norm voor een managementsysteem voor bedrijfscontinuïteit. De norm is bedoeld voor organisaties van elke omvang, en certificering is mogelijk. Zie ISO 22301.

Veelgestelde vragen over bedrijfscontinuïteit

Wat is het verschil tussen een bedrijfscontinuïteitsplan en een calamiteitenplan?

Een calamiteitenplan gaat over de eerste minuten: ontruimen, hulpdiensten bellen en mensen in veiligheid brengen. Een bedrijfscontinuïteitsplan gaat over wat daarna komt: hoe de organisatie blijft leveren en herstelt. U heeft ze allebei nodig.

Is een bedrijfscontinuïteitsplan verplicht?

Voor organisaties onder de Cyberbeveiligingswet wel: het Cyberbeveiligingsbesluit vraagt een schriftelijk continuïteitsplan dat periodiek wordt getest. Voor andere organisaties is het niet wettelijk verplicht. Klanten kunnen er wel naar vragen in contracten of leveranciersbeoordelingen.

Wat is het verschil tussen RTO en RPO?

De RTO is hoe snel een proces of systeem weer moet werken. De RPO is hoeveel gegevens u maximaal mag verliezen, uitgedrukt in tijd. Samen bepalen ze welke back-up- en uitwijkvoorzieningen u nodig heeft.

Hoe vaak moet je een continuïteitsplan testen?

De wet spreekt van periodiek testen en noemt geen vaste frequentie. Ons advies is minstens één oefening per jaar. Test daarnaast na elke grote wijziging, zoals een nieuwe leverancier, een migratie of een verhuizing.

Wie is verantwoordelijk voor bedrijfscontinuïteit?

De directie, want zij bepaalt welke uitval aanvaardbaar is. De uitvoering ligt vaak bij een continuïteitscoördinator, de IT-manager of de CISO. Daarnaast heeft elk kritiek proces een eigenaar in de lijn.