Elk bedrijf draait op een paar dingen die niet mogen uitvallen: servers, een code-omgeving, e-mail, mensen met de juiste kennis. Bedrijfscontinuïteit gaat over de vraag wat je doet als een van die dingen er even niet is, en vooral over het uitzoeken daarvan vóórdat het gebeurt. Dan hoef je tijdens de storing niet ook nog te bedenken hoe je moet reageren.
Kernpunt: continuïteit regel je vóór de storing, niet tijdens.
Wat is een BIA? BIA staat voor business impact analysis. In gewone woorden: voor elke activiteit of dienst die we echt nodig hebben, bepaal je hoe erg het is als hij wegvalt en hoe snel hij weer moet werken. Daarvoor stel je per dienst een paar vragen:
| Term | Vraag |
|---|---|
| MTD (maximum tolerable downtime) | Hoe lang mag het maximaal uit de lucht zijn voordat de schade serieus wordt? |
| RTO (recovery time objective) | Hoe snel willen we hem weer terug hebben? |
| RPO (recovery point objective) | Hoeveel recente gegevens mogen we hooguit kwijtraken? |
Daarnaast bepaal je wie, welke gegevens, welke infrastructuur en welke externe partijen nodig zijn om het weer draaiend te krijgen.
De streeftijd voor herstel zit bewust onder de maximaal toegestane tijd. Hoe groter de schade als we die grens overschrijden, hoe meer marge we nemen. De schade beoordelen we op dezelfde manier als in ons risicomanagement: financieel, contractueel, juridisch, operationeel en voor onze reputatie.
De analyse zit in het assetregister. We hebben geen apart document voor de BIA. Wie een asset beheert die een essentiële dienst ondersteunt, vult in ons assetregister de continuïteitsvelden in: hoe kritiek is het, wat is het risiconiveau, wat zijn MTD, RTO en RPO (als gegevensverlies speelt) en welke aannames of herstelnotities horen erbij. Een korte onderbouwing helpt, bijvoorbeeld waarom een bepaald verlies acceptabel is. De eigenaar van de asset is meteen de sleutelpersoon voor herstel, en de leverancier en toegangsvorm staan al in het register.
De Security Officer bewaakt de structuur en controleert minstens jaarlijks, en na grote wijzigingen of incidenten, of alle kritieke assets recent zijn bekeken en of de waarden nog realistisch zijn. Het register is ook wat je erbij pakt tijdens een storing, om te zien wat is geraakt, hoe kritiek dat is en welke afhankelijkheden meespelen.
Het continuïteitsplan. Het plan beschrijft per kritieke dienst een alternatief, zodat de doelen haalbaar blijven. Zo is onze software niet vastgebonden aan één hostingpartij en staat het opzetten van een server beschreven. Valt het platform voor onze code of uitrol weg, dan kunnen we in een noodgeval handmatig uitrollen, maar we stellen andere wijzigingen dan liever uit, omdat dat extra risico geeft. Voor e-mail hebben we een reserveroute. Zulke plannen zijn eerlijk over beperkingen: een omschakeling kost tijd en goedkeuring van een nieuwe dienst ook.
Wanneer het plan van kracht wordt. Een storing is altijd eerst een incident en volgt dus onze incidentprocedure. Het continuïteitsplan komt erbij als:
- een incident een kritieke activiteit raakt of de herstelstreeftijd dreigt te overschrijden;
- een kritieke leverancier een grote storing heeft;
- het kantoor niet bruikbaar is en thuiswerken niet genoeg is;
- een ernstig beveiligingsincident beschikbaarheid of integriteit van kritieke systemen raakt.
Dan maken we een impactinschatting aan de hand van het register. We activeren het plan als de uitvaltijd waarschijnlijk te lang wordt, meerdere kritieke diensten tegelijk uitvallen, de schade ernstig kan zijn of de directie erom vraagt. Het incident krijgt dan een aparte markering en iedereen hoort dat we in die modus zitten.
Herstellen, zonder beveiliging in te leveren. We bevestigen de prioriteiten uit de BIA, kiezen per dienst een strategie en leggen vast wie wat doet. Daarbij kiezen we uit:
- terugvallen op een reserve;
- herstellen uit een back-up;
- opnieuw opbouwen elders;
- een omweg gebruiken;
- niet-kritieke processen tijdelijk stilleggen.
Eerst zorgen we dat niemand gevaar loopt en dat een getroffen systeem wordt afgeschermd, met behoud van logs. Tijdens een noodsituatie blijven de beveiligingsregels gelden. Klantgegevens komen niet in privé-tools, toegangsbeheer en meervoudige authenticatie blijven aan en logging, versleuteling of inlog gaan alleen uit met expliciete toestemming van de Security Officer en met vastlegging als bewust genomen risico.
Intern en naar klanten communiceren we feitelijk en op tijd, zonder gevoelige details onnodig te delen, en binnen onze wettelijke en contractuele verplichtingen.
Afsluiten en leren. De Security Officer verklaart het einde zodra de kritieke diensten weer binnen de grenzen draaien en de rest via de gewone incidentafhandeling kan. Tijdelijke infrastructuur en tijdelijke toegangsrechten worden dan opgeruimd. Kort daarna volgt een evaluatie van de tijdlijn, de maatregelen en de communicatie.
Minstens eenmaal per jaar oefenen we het plan, als gesprek aan tafel, als simulatie of als echte technische herstelproef. Zo weten we dat het werkt voordat we het nodig hebben. Wat een evaluatie of oefening oplevert, verwerken we volgens ons artikel over continu verbeteren: voor continuïteit betekent dat dat bijvoorbeeld de BIA-waarden, het plan of afspraken met leveranciers worden aangepast, en dat elke aanpassing een eigenaar krijgt.