Business continuity plan voor een softwarebedrijf: wat erin moet

Een business continuity plan legt vast hoe je binnen een afgesproken tijd weer levert wat klanten van je afnemen, als een incident, een uitval of het wegvallen van een leverancier je normale werk stillegt. Voor een softwarebedrijf draait het om twee getallen per dienst: hoe snel die weer moet werken (RTO) en hoeveel data je daarbij mag verliezen (RPO). De rest van het bedrijfscontinuïteitsplan regelt hoe je die getallen haalt.

Continuïteitsplan, herstelplan en incidentresponsplan

De drie worden vaak door elkaar gebruikt, maar ze doen iets anders:

• Het incidentresponsplan beschrijft hoe je een incident herkent, beoordeelt en indamt.
• Het herstelplan (disaster recovery plan) beschrijft technisch hoe je systemen en data terugzet.
• Het business continuity plan zit erboven: welke diensten eerst terug moeten, binnen welke tijd, wie beslist en hoe je doorwerkt terwijl het herstel loopt.

Een klein bedrijf kan ze in één document combineren, zolang die drie vragen elk een eigen antwoord krijgen.

Wat erin moet

Het NCSC noemt als kern van een BCP de scope en doelen, criteria voor het activeren en afschalen, een incidentresponsplan met rollen, een communicatiestrategie en plannen voor back-up en redundantie. Voor een SaaS- of hostingbedrijf komt dat neer op:

1. Scope en doelen. Welke diensten, klanten en locaties het plan dekt.
2. Activatie. Wanneer het plan ingaat, wie dat besluit en wanneer je weer terugschaalt naar normaal.
3. Uitkomsten van de bedrijfsimpactanalyse. Per dienst de RTO, de RPO en het minimale niveau waarop je tijdelijk kunt doorwerken.
4. Scenario's en strategieën. Per scenario de uitwijk of herstelaanpak.
5. Rollen en besluitvorming. Wie leidt, wie beslist over maatregelen die klanten raken, wie vervangt wie.
6. Communicatie. Klanten, medewerkers, leveranciers en toezichthouders.
7. Leveranciersafhankelijkheden. Welke externe diensten je nodig hebt en wat je doet als die wegvallen.
8. Back-up, redundantie en herstelprocedures. Verwijzingen naar het technische herstelplan.
9. Testen en onderhoud. Hoe en wanneer je het plan oefent en herziet.

De bedrijfsimpactanalyse en RTO/RPO

Een continuïteitsplan begint met een bedrijfsimpactanalyse (BIA). Je brengt je processen en diensten in kaart, bepaalt welke afhankelijk zijn van IT, en schat per dienst wat een uitval kost, in geld, klantvertrouwen en contractuele afspraken. Het NCSC omschrijft de RTO als de streeftijd waarbinnen een functie, proces of dienst weer operationeel moet zijn, en de RPO als het tijdsinterval waarover je maximaal data mag verliezen.

Een voorbeeld van de uitkomst voor een SaaS-bedrijf. De waarden zijn illustratief; de juiste getallen volgen uit je eigen BIA en je contracten.

Controleer daarna of je back-upfrequentie, je redundantie en je beschikbaarheidsafspraken met klanten bij die getallen passen. Een RPO van 15 minuten met een nachtelijke back-up is een belofte die je niet kunt houden.

Scenario's

Beschrijf niet elke denkbare ramp, maar de verstoringen die je diensten echt raken. Voor een softwarebedrijf zijn dat meestal:

• uitval van de cloudregio of het datacenter waarin het platform draait;
• ransomware of een andere aanval die systemen of back-ups onbruikbaar maakt;
• uitval van een sleutelleverancier, zoals identiteitsbeheer, DNS, e-mail of betaalverkeer;
• het wegvallen van een persoon die als enige een systeem kent;
• een datalek, bij jezelf of bij een leverancier.

Leveranciersafhankelijkheden

Een SaaS-bedrijf is voor zijn continuïteit grotendeels afhankelijk van anderen. Maak een lijst van externe diensten waar je productie op draait, met per leverancier de beschikbaarheidsafspraak, de contactroute bij storingen en wat je doet als die leverancier een dag wegvalt. Let op verborgen afhankelijkheden: een statuspagina of een incidentkanaal dat bij dezelfde provider draait als je platform, valt tegelijk uit.

Communicatie

Leg vooraf vast wie namens de organisatie communiceert en via welke kanalen, en bereid berichten voor klanten voor. Neem de wettelijke termijnen op die voor jou kunnen gelden. Een datalek met persoonsgegevens kan binnen 72 uur een melding bij de Autoriteit Persoonsgegevens vragen. Valt je organisatie onder de Cyberbeveiligingswet, dan geldt bij een significant incident een vroegtijdige waarschuwing binnen 24 uur, een melding binnen 72 uur en een eindverslag binnen een maand. Ben je verwerker voor je klanten, zorg dan dat zij snel genoeg van je horen om hun eigen meldplicht te kunnen beoordelen.

Testen en onderhouden

Een continuïteitsplan dat nooit is geoefend, is een aanname. Test op twee niveaus: technisch, door back-ups daadwerkelijk terug te zetten en een failover uit te voeren, en organisatorisch, met een tabletop-oefening waarin het team een scenario doorloopt. Het NCSC adviseert maatregelen periodiek, bijvoorbeeld jaarlijks, op effectiviteit te toetsen en het plan te herzien als organisatie, systemen of dreiging veranderen.

Aansluiting op ISO 27001

ISO 27001 vraagt niet om een document met de naam business continuity plan, maar een aantal Annex A-maatregelen komt er in de praktijk op uit. In eigen woorden:

Het plan hangt samen met incidentbeheer (5.24 tot en met 5.26) en met leveranciersbeheer (5.19 tot en met 5.23). ISO 22301 is een aparte norm voor een managementsysteem voor bedrijfscontinuïteit. Die kun je als referentie gebruiken, maar voor ISO 27001 is hij niet nodig. Onder de Cyberbeveiligingswet valt bedrijfscontinuïteit, met back-upbeheer, herstelplannen en crisisbeheer, onder de zorgplicht.

Het plan gebruiken

Een continuïteitsplan bewijst zijn waarde pas als mensen ermee kunnen werken. Houd het kort genoeg om tijdens een storing te lezen, zet contactgegevens en beslisbevoegdheden bovenaan, en bewaar een kopie buiten de systemen die kunnen uitvallen. De gratis tabletop-module van Trustbird gebruikt onder meer een geüpload continuïteitsplan als basis voor de scenario's, zodat je ziet of het plan in een oefening standhoudt.