Het bedrijfscontinuïteitsplan, geschreven uit een paar antwoorden

# Bedrijfscontinuïteitsplan: [bedrijf]

Beheerder: [de beheerder van het plan] · Goedgekeurd door: [de directie]

Geschreven op  met de gratis pagina op getstandardos.com tegen de maatregelen van bijlage A van ISO/IEC 27001:2022 over informatiebeveiliging tijdens een verstoring, ICT-gereedheid voor bedrijfscontinuïteit, back-up van informatie en redundantie van informatieverwerkende voorzieningen. De formulering is die van StandardOS.

## 1. Doel en reikwijdte

Dit plan zegt wat [bedrijf] doet als een dienst waarvan het afhangt stilvalt, zodat het bedrijf zijn toezeggingen aan klanten nakomt, zijn informatie tijdens het herstel beveiligd houdt en terug is binnen de tijd die het naar eigen besluit kan dragen. Het dekt de hieronder genoemde diensten, de mensen die ze draaien, de gegevens die ze bevatten en de leveranciers waarop ze rusten.

De gedekte diensten: [aan te vullen, de producten en interne systemen waar het bedrijf niet zonder kan].

## 2. Hersteldoelen

Hersteltijd: elke gedekte dienst is hersteld binnen 24 uur na het afkondigen van de verstoring.

Herstelpunt: van geen enkele gedekte dienst gaat meer dan 24 uur aan gegevens verloren.

De twee cijfers zijn het besluit van het bedrijf, niet de belofte van de aanbieder; een gedekte dienst waarvan de aanbieder ze niet kan halen, wordt vermeld met de leemte en de maatregel die haar dicht, of de cijfers worden door de goedkeurder gewijzigd.

## 3. Rollen

[de beheerder van het plan] beheert dit plan, houdt het actueel en leidt de oefening. [de verstoringsleider] leidt een verstoring: kondigt haar af, beslist de volgorde van het herstel, keurt elke afwijking van de beveiligingsregels goed en kondigt de terugkeer naar normaal af.

Plaatsvervangend leider: [aan te vullen]. Wie het noodkanaal het eerst bereikt als de leider niet binnen dertig minuten bereikbaar is, treedt op als leider tot de leider of de plaatsvervanger het overneemt.

## 4. De scenario's die het plan dekt

Het plan is geschreven voor vijf manieren waarop een dienst stilvalt; een verstoring die bij geen ervan past, wordt behandeld met dezelfde rollen, hetzelfde kanaal en dezelfde doelen.

- de cloudaanbieder of de regio waarin het product draait is niet beschikbaar;
- de gegevens zijn versleuteld, verwijderd of beschadigd, door ransomware, door een fout of door een slechte uitrol;
- het kantoor, zijn netwerk of de mensen die er werken zijn niet beschikbaar;
- een kritieke leverancier levert niet meer, wordt gehackt of beëindigt het contract zonder aankondiging;
- de identiteitsaanbieder of de beheerdersaccounts zijn verloren of vergrendeld.

## 5. Een verstoring afkondigen en het eerste uur

Wie een gedekte dienst ziet uitvallen voorbij een gewoon incident, meldt dit aan [de verstoringsleider], die de verstoring afkondigt, het scenario benoemt en een logboek opent met het tijdstip van de afkondiging. Vanaf dat moment geldt dit plan, en het incidentresponsplan loopt ernaast door voor de beveiligingskant.

Het kanaal als de gewone middelen uitvallen: [het noodkanaal, aan te vullen]. De contactgegevens ervan worden bewaard waar ze zonder de systemen van het bedrijf te lezen zijn, en bij elke oefening nagekeken.

In het eerste uur stelt de leider vast wie beschikbaar is, welke diensten geraakt zijn, laat de klanten via het statuskanaal weten dat het bedrijf op de hoogte is en wanneer de volgende update komt, en start het herstel in de volgorde die de volgende secties bepalen.

## 6. Beveiliging tijdens de verstoring

De toegangsregels, de meerfactorauthenticatie en de logging blijven tijdens een verstoring van kracht. Een afwijking daarvan, zoals een noodaccount, een gedeeld wachtwoord of een herstel naar een nieuwe omgeving zonder de gebruikelijke beoordeling, wordt goedgekeurd door [de verstoringsleider], met de reden in het logboek geschreven, en teruggedraaid zodra de dienst terug is.

Back-ups en kopieën die tijdens het herstel worden gemaakt, worden beschermd als de originelen, en elk herstel gebeurt vanaf een kopie die niet kan worden gewijzigd door dezelfde gebeurtenis die de verstoring veroorzaakte.

## 7. Back-ups, redundantie en de volgorde van herstel

Van elke gedekte dienst wordt ten minste elke 24 uur een back-up gemaakt, naar een plaats die de eigen inloggegevens van de dienst niet kunnen verwijderen, en een herstel vanaf de back-up wordt bij elke oefening getest.

Het product draait in één cloudregio. Herstel binnen 24 uur rust op de redundantie van de aanbieder binnen die regio en op het vermogen de dienst in een andere regio opnieuw op te bouwen uit de back-ups en de infrastructuurcode, wat de oefening test.

De volgorde van herstel: eerst identiteiten en toegang, zodat mensen kunnen werken; dan de diensten waarvoor klanten betalen; dan de interne diensten; dan al het overige. Een dienst wordt hersteld naar de laatste back-up binnen het herstelpunt, en de gegevens tussen die back-up en de verstoring worden opnieuw ingevoerd of, waar dat kan, van de kant van de klanten teruggehaald.

## 8. Leveranciers, klanten en autoriteiten

Voor elke kritieke leverancier legt het leveranciersregister zijn continuïteitstoezegging vast en het contact dat tijdens een verstoring wordt gebruikt; een leverancier die zelf de verstoring is, wordt behandeld volgens de afscheidsregels van het leveranciersbeleid.

Klanten worden via het statuskanaal geïnformeerd bij de afkondiging, bij elke verandering en bij de terugkeer naar normaal, in gewone woorden en zonder speculatie over de oorzaak. Waar de verstoring ook een beveiligingsincident is, gelden de meldtermijnen van het incidentresponsplan, en de leider en de leider van het incidentplan beslissen samen wat naar wie gaat.

## 9. Terugkeer naar normaal en de beoordeling achteraf

[de verstoringsleider] kondigt de terugkeer naar normaal af wanneer elke gedekte dienst binnen zijn doelen terug is en de afwijkingen van de beveiligingsregels zijn teruggedraaid. Binnen tien werkdagen houdt de leider een beoordeling met de betrokkenen, leest het logboek, legt vast wat werkte, wat niet en wat verandert, en de veranderingen gaan in dit plan, het incidentresponsplan of het risicoregister.

## 10. Het plan oefenen

Het plan wordt eenmaal per jaar geoefend, geleid door [de beheerder van het plan]: één scenario wordt doorlopen met de mensen die zouden handelen, één herstel wordt gedaan vanaf een back-up, het noodkanaal wordt gebruikt, en de tijd die elke stap kostte wordt tegen de doelen opgeschreven.

Een oefening die een doel mist, is geen mislukking van de oefening; het is de bevinding waarvoor het plan bestaat, en zij wordt een actie met een eigenaar en een datum.

## 11. Registraties

Dit plan, de oefenregistraties, de verstoringslogboeken, de beoordelingen na elke verstoring en de hersteltests worden bewaard als het bewijs van het bedrijf dat het klaar is, en zijn wat de interne audit en de certificatie-audit lezen.

Goedgekeurd door [de directie] op [datum]; beheerd door [de beheerder van het plan]; beoordeeld ten minste eenmaal per jaar, na elke oefening en na elke verstoring.

Dit plan is geschreven uit de gegeven antwoorden. Het is geen certificatieadvies; de certificatie-instelling leest het plan op zijn doelen en rollen en vraagt dan naar de oefening en de hersteltest die ze bewijzen, en de registratie die zij aanvaardt, is die welke het bedrijf bijhoudt.