Bedrijfscontinuïteitsplan (BCP): stappenplan in 8 stappen voor 2026

Een bedrijfscontinuïteitsplan (BCP) is het gedocumenteerde geheel van strategieën, middelen en procedures waarmee een organisatie haar essentiële activiteiten kan blijven leveren, op een vooraf afgesproken niveau, tijdens en na een ernstige verstoring: een brand, een cyberaanval, het uitvallen van een leverancier, massale afwezigheid van personeel. Het beantwoordt één eenvoudige vraag: als we morgenochtend X verliezen, wat doen we dan, wie doet het en hoe snel?

De meeste bedrijfscontinuïteitsplannen falen om een reden die niets te maken heeft met hoe goed ze geschreven zijn: ze staan los van de realiteit die ze moeten beschermen. Een wachtdienstlijst die achttien maanden verouderd is, een RTO van 4 uur die nooit iemand heeft getest, een cloudleverancier die ontbreekt in de afhankelijkheidskaart… Deze gids overloopt de methode in 8 stappen volgens ISO 22301, wat NIS2 en DORA in 2026 vereisen, en vooral hoe u van een BCP een levend systeem maakt in plaats van een map in de kast.

De versie in 30 seconden

• Een BCP houdt de bedrijfsvoering draaiende; een IT-herstelplan (DRP) herstart de IT. Het DRP maakt deel uit van het BCP, het vervangt het niet.
• Alles begint met de BIA: zonder RTO's en RPO's die onderbouwd zijn door de bedrijfsimpact, zijn continuïteitsstrategieën giswerk.
• Denk in termen van onbeschikbaarheid (data, IT, derden, mensen, gebouwen) in plaats van dreigingen: oorzaken veranderen, gevolgen niet.
• NIS2 (artikel 21) en DORA (artikel 11) maken van continuïteit een wettelijke verplichting, en DORA eist dat plannen minstens één keer per jaar worden getest.
• Een plan dat nooit is geoefend, is slechts een hypothese.

Wat is een bedrijfscontinuïteitsplan?

ISO 22301 definieert een bedrijfscontinuïteitsplan als gedocumenteerde informatie die een organisatie begeleidt om te reageren op een verstoring en de levering van haar producten en diensten te hervatten, te herstellen en te normaliseren, in overeenstemming met haar bedrijfscontinuïteitsdoelstellingen. In de praktijk streeft een BCP drie doelen na, in deze volgorde:

1. Mensen beschermen: medewerkers, klanten, bezoekers.
2. Prioritaire activiteiten draaiende houden op een aanvaardbaar minimumniveau tijdens de verstoring (de MBCO, minimum business continuity objective).
3. Gecontroleerd terugkeren naar normaal, zonder tijdens het herstel een tweede crisis te veroorzaken.

Een BCP is geen verzekeringspolis (een verzekering betaalt uit, ze houdt de activiteiten niet draaiende), geen IT-herstelplan (dat dekt slechts een deel van het probleem) en geen document van 300 pagina's in een lade. Het is een vermogen: beslissingen die in alle rust zijn genomen, middelen die vooraf zijn klaargezet en mensen die hebben geoefend.

De internationale referentie is ISO 22301:2019, een certificeerbare norm waarvan clausule 8.4 de bedrijfscontinuïteitsplannen en -procedures behandelt. Professionals steunen ook op de Good Practice Guidelines van het Business Continuity Institute en op nationale richtlijnen zoals de Franse SGDSN-gids.

BCP vs DRP vs crisisbeheerplan: wat is het verschil?

Dit is de meest voorkomende verwarring, en een dure: veel organisaties denken dat ze een BCP hebben, terwijl ze enkel een IT-herstelplan hebben.

Het BCP is de overkoepelende paraplu: het steunt op het DRP en het IT-continuïteitsplan voor de systemen, op het crisisbeheerplan voor de beslissingen en op het communicatieplan voor de berichtgeving. Als u enkel het DRP hebt, weet u hoe u uw servers herstelt, maar weet niemand hoe er gefactureerd, verzonden of klanten geantwoord moet worden gedurende de 48 uur die het herstel duurt. Voor de technische kant, zie onze gids voor het IT-herstelplan.

Is een bedrijfscontinuïteitsplan verplicht in 2026?

Voor een groeiend aantal organisaties wel. De belangrijkste bronnen van verplichtingen in Europa:

• NIS2: artikel 21 verplicht essentiële en belangrijke entiteiten om risicobeheersmaatregelen te nemen die uitdrukkelijk "bedrijfscontinuïteit, zoals back-upbeheer en herstel na een calamiteit, en crisisbeheer" omvatten. Boetes kunnen oplopen tot €10 miljoen of 2% van de wereldwijde omzet voor een essentiële entiteit. De omzetting is in meerdere lidstaten nog onvolledig (Frankrijk had zijn wet half oktober 2026 nog niet definitief aangenomen), maar die vertraging beschermt weinigen: grote klanten vragen dit bewijs nu al op in leveranciersvragenlijsten. Zie NIS2: essentiële vs belangrijke entiteiten.
• DORA (financiële sector, van toepassing sinds 17 januari 2025): artikel 11 vereist een ICT-bedrijfscontinuïteitsbeleid, respons- en herstelplannen, en het testen van die plannen minstens jaarlijks. Artikel 12 behandelt back-ups, artikel 14 crisiscommunicatie. Zie onze DORA-gids 2026 en, voor ICT-dienstverleners, de gids voor het DORA-informatieregister.
• Verzekeringen: Solvency II (artikel 41) verplicht verzekeraars om noodplannen op te stellen.
• AVG: artikel 32 vereist het vermogen om na een incident de beschikbaarheid van en toegang tot persoonsgegevens tijdig te herstellen.
• ISO 22301: vrijwillig, maar steeds vaker vereist in aanbestedingen en door cyberverzekeraars.

Zelfs zonder wettelijke verplichting is continuïteit een commerciële kwestie geworden: de dag dat een grote klant vraagt "wat is uw RTO voor de dienst die u ons levert?", hebt u een antwoord nodig dat u kunt aantonen.

De 8 stappen om een bedrijfscontinuïteitsplan op te bouwen

De onderstaande methode volgt de logica van ISO 22301 (clausules 4 tot 10). Ze werkt zowel voor een bedrijf met 50 medewerkers als voor een multinationale groep: enkel de diepgang verschilt.

Stap 1 — Afbakenen: sponsor, toepassingsgebied en beleid

Een BCP zonder sponsor in de directie sneuvelt bij de eerste budgettaire afweging. ISO 22301 maakt leiderschap tot een uitdrukkelijke vereiste (clausule 5).

• Stel een sponsor uit de directie aan en een bedrijfscontinuïteitsverantwoordelijke, met een aanspreekpunt in elk bedrijfsonderdeel.
• Bepaal het toepassingsgebied: welke producten en diensten, welke entiteiten, welke locaties. Begin voor een eerste versie met twee of drie kritieke diensten in plaats van de hele organisatie.
• Schrijf een continuïteitsbeleid van één à twee pagina's: doelstellingen, toepassingsgebied, rollen, frequentie van herziening en testen.
• Leg uw drempels van onaanvaardbare impact vast: vanaf welk niveau van verlies, vertraging voor klanten of overtreding van regelgeving wordt een impact ondraaglijk?

Resultaat: een afbakeningsnota goedgekeurd door het management, en een bedrijfscontinuïteitsbeleid.

Stap 2 — Activiteiten en hun afhankelijkheden in kaart brengen

Identificeer voor elke activiteit binnen het toepassingsgebied alles wat ze nodig heeft om te functioneren:

• sleutelpersonen en vaardigheden (inclusief degene die niemand anders kan overnemen);
• applicaties en IT-diensten, en de data die ze verwerken;
• leveranciers en onderaannemers, inclusief SaaS-aanbieders en vierde partijen;
• locaties, uitrusting en voorraden;
• stroomopwaartse en stroomafwaartse processen waarvan ze afhangt of die ze voedt.

Dit is de meest onderschatte stap, en de stap waarbij spreadsheets op hun grenzen stuiten: één applicatie ondersteunt tien processen, één leverancier host drie applicaties. Een afhankelijkheid die hier wordt gemist, wordt op de dag zelf een blinde vlek. Op 19 juli 2024 legde een foutieve update van beveiligingsleverancier CrowdStrike volgens Microsoft zo'n 8,5 miljoen Windows-toestellen plat: luchtvaartmaatschappijen, ziekenhuizen en banken ontdekten binnen enkele uren dat een component die niemand als kritiek had geïdentificeerd alles kon stilleggen.

Stap 3 — De bedrijfsimpactanalyse (BIA) uitvoeren

De BIA meet wat een onderbreking van elke activiteit kost in de tijd: na 4 uur, 24 uur, 72 uur, een week, een maand. Beoordeel de impact over meerdere dimensies (financieel, klanten, regelgeving, reputatie, gezondheid en veiligheid) en leid daaruit de indicatoren af die de rest van het plan sturen:

Twee regels voorkomen de meeste fouten. Ten eerste: bevraag de business, niet de IT: de verantwoordelijke facturatie weet wat drie dagen zonder facturatie kost. Ten tweede: vergelijk de RTO's van de business met het technische herstelvermogen: een applicatie waarvan het herstel 72 uur duurt, kan geen proces met een RTO van 4 uur ondersteunen. Die kloof is de waardevolste vaststelling van elke BIA. Los ze op; verberg ze niet.

Verder lezen: onze BIA-gids in 7 stappen, RTO vs RPO uitgelegd, het gratis BIA-sjabloon en de RTO/RPO-calculator.

Stap 4 — Risico's beoordelen en scenario's selecteren

Twee complementaire benaderingen, die samen worden toegepast.

Per onbeschikbaarheid. Wat de oorzaak ook is, een organisatie kan altijd maar vijf dingen verliezen. Door te redeneren vanuit deze gevolgen, in plaats van vanuit een eindeloze lijst dreigingen, garandeert u dat er geen respons ontbreekt:

Per scenario. Gebruik vervolgens uw risicobeoordeling (ISO 31000, ISO 27005, EBIOS RM) om een handvol ernstige maar plausibele scenario's met hoog risico te selecteren, die vaak meerdere onbeschikbaarheden combineren: ransomware treft zowel IT als data; een overstroming treft gebouwen, mensen en lokale leveranciers.

De controle is eenvoudig: elke kritieke activiteit heeft een respons nodig voor elke onbeschikbaarheid, en elk geselecteerd scenario moet door het plan worden gedekt.

Stap 5 — Continuïteitsstrategieën kiezen

Som voor elke onbeschikbaarheid de opties op, begroot ze en behoud degene die uw RTO's halen tegen de meest redelijke kost (ISO 22301, clausule 8.3):

• Gebouwen: uitwijklocatie, telewerk, wederzijdse overeenkomsten, werk verplaatsen naar een andere locatie.
• Mensen: kruisopleiding, aangewezen vervangers, gedocumenteerde kritieke knowhow, tijdelijk personeel.
• IT-systemen: redundantie, DR, cloud-failover, manuele procedures in degradatiemodus.
• Data: 3-2-1-regel met een onveranderlijke of offline kopie, en regelmatige hersteltests (een back-up die u nooit hebt teruggezet, is geen back-up).
• Derden: dubbele sourcing, buffervoorraad, contractuele clausules (serviceniveaus, omkeerbaarheid, het eigen continuïteitsplan van de leverancier), en exitstrategieën voor kritieke leveranciers, wat DORA verplicht voor ICT-diensten.

Gouden regel: hoe korter de RTO, hoe duurder de strategie. Elke keuze moet onderbouwd worden door de BIA, niet door een technische voorkeur. De herstelkostenschatter helpt om de afweging te objectiveren.

Stap 6 — Plannen schrijven die echt bruikbaar zijn

Een doeltreffend BCP is kort en leesbaar onder stress. Aanbevolen structuur:

1. Doel, toepassingsgebied, eigenaar, versie en datum van de laatste herziening.
2. Activeringscriteria en alarmniveaus: wie mag het plan activeren, op basis van welke signalen?
3. Crisisorganisatie: rollen, titularissen en vervangers.
4. Contactenlijst: interne teams, kritieke leveranciers, overheden, verzekeraar, met nummers die bereikbaar zijn buiten de IT van het bedrijf.
5. Procedures per onbeschikbaarheid en per activiteit: geordende acties, benodigde middelen, tijdsdoelstelling.
6. Degradatiemodi en noodoplossingen.
7. Terugkeer naar normaal: voorwaarden, volgorde, controles.
8. Bijlagen: inventarissen, actiekaarten van één pagina per rol.

Twee controles op gezond verstand. Het plan moet uitvoerbaar zijn door een vervanger die om 3 uur 's nachts wordt gewekt: werkwoorden, checklists, geen lappen tekst. En het moet bereikbaar blijven wanneer de IT plat ligt: een BCP dat enkel op het intranet staat dat net offline ging, is nutteloos. Bewaar offline en gedrukte exemplaren bij sleutelpersonen.

Gratis sjablonen: bedrijfscontinuïteitsplan, IT-herstelplan, crisiscommunicatieplan.

Stap 7 — Alarmering en crisisbeheer organiseren

Het BCP zegt wat er moet gebeuren; het crisisbeheer beslist wanneer, en in welke volgorde.

• Een crisiscel op twee niveaus: strategisch (directie, afwegingen, externe communicatie) en operationeel (uitvoering van de acties). Essentiële rollen: leider, notulist die het incidentlogboek bijhoudt, communicatie, juridische zaken, HR, IT, vertegenwoordigers van de business.
• Een geteste alarmeringsketen: wachtdienstrooster, belboom, meerkanaalsmeldingen, en een terugvalkanaal voor het geval de bedrijfsmail zelf gecompromitteerd is.
• Een incidentlogboek met tijdstempels: elke beslissing, actie en ontvangen informatie. Het dient om de respons te sturen, de evaluatie na het incident op te stellen en de toezichthouder te antwoorden.
• Vooraf voorbereide meldingsverplichtingen: NIS2 vereist een vroegtijdige waarschuwing binnen 24 uur, een melding binnen 72 uur en een eindverslag binnen één maand; DORA legt vergelijkbare of zelfs kortere termijnen op voor ernstige ICT-incidenten. Bereid de sjablonen nu voor. Zie NIS2-incidentmelding: 24 u, 72 u, 1 maand.
• Vooraf opgestelde berichten voor personeel, klanten, partners en media.

Om de besluitvorming te structureren, zie ons artikel over het crisisbeheerplan en het RAPID-kader.

Stap 8 — Testen, oefenen, verbeteren

Dit is de stap die van een document een vermogen maakt. ISO 22301 (clausule 8.5) vereist een oefenprogramma met geplande intervallen en na significante wijzigingen; DORA vereist dat ICT-bedrijfscontinuïteitsplannen minstens jaarlijks worden getest. Bouw geleidelijk op:

Elke oefening moet leiden tot een evaluatie na de oefening: vastgestelde tekortkomingen, corrigerende acties met een eigenaar en een termijn, aanpassingen aan het plan, gevolgd door een managementbeoordeling (clausule 9.3). De meest veelzeggende indicator voor een directiecomité is de kloof tussen de beoogde RTO en de effectief gemeten hersteltijd.

Inspiratie nodig? Zie onze 10 scenario's voor crisisoefeningen.

Waarom zoveel bedrijfscontinuïteitsplannen falen op de dag zelf

Evaluaties na incidenten lijken allemaal op elkaar. Zes oorzaken komen telkens terug:

1. Het plan slaapt. Niemand is eigenaar en het werd sinds de laatste reorganisatie niet meer herzien. Oplossing: één eigenaar per plan, en herzieningen die worden uitgelokt door wijzigingen (nieuwe applicatie, nieuwe leverancier, verhuis), niet enkel door de kalender.
2. Afhankelijkheden zijn onzichtbaar. De SaaS-aanbieder, de vierde partij, de enige expert. Oplossing: breng de verbanden proces ↔ applicatie ↔ leverancier één keer in kaart en hergebruik ze overal.
3. RTO's zijn louter verklaringen. Aangekondigd, nooit gemeten. Oplossing: test, en volg de kloof tussen doelstelling en werkelijk vermogen op.
4. Het plan is onbereikbaar. Opgeslagen op het systeem dat net uitviel. Oplossing: offline kopieën, gedrukte versies, een contactenlijst buiten de IT van het bedrijf.
5. Het plan is onleesbaar. Tweehonderd pagina's die niemand opent tijdens een crisis. Oplossing: actiekaarten van één pagina per rol.
6. Er is geen bewijs voor de auditor. Er vonden oefeningen plaats, maar niets bewijst het. Oplossing: houd een historiek bij van versies, goedkeuringen, oefeningen en corrigerende acties.

Wat deze zes tekortkomingen gemeen hebben: het BCP wordt behandeld als een document, terwijl het in werkelijkheid een volwaardig informatiesysteem is, een afhankelijkheidsgraaf die elke week verandert. Een plan dat standhoudt, is een plan waarin elk element (activiteit, applicatie, leverancier, risico, procedure, oefening) met de andere verbonden is en samen ermee wordt bijgewerkt.

Spreadsheets, Word of bedrijfscontinuïteitssoftware?

Een spreadsheet en een tekstverwerker volstaan voor een eerste versie in een kleine organisatie met één locatie en weinig IT-afhankelijkheden. Daarbuiten overstijgen de kosten om ze actueel te houden al snel de kosten van een gespecialiseerde tool:

Verder lezen: spreadsheet vs ResiPlan, onze koopgids voor BCM-SaaS voor kmo's en de vergelijking van bedrijfscontinuïteitssoftware 2026.

Wat ResiPlan concreet doet

ResiPlan werd ontworpen rond het idee dat deze gids verdedigt: één datamodel, van de BIA tot een getest plan en auditklaar bewijs.

• Verbonden BIA: processen vooraf ingevuld voor uw sector, berekening van RTO en MTPD, campagnes naar proceseigenaars met een goedkeuringsworkflow en versiegeschiedenis.
• Plannen vooraf ingevuld vanuit de BIA: 8 soorten plannen (bedrijfscontinuïteit, bedrijfsherstel, IT-herstel, incidentrespons, noodrespons, crisisbeheer, crisiscommunicatie, leveranciersweerbaarheid). Voor vijf ervan wordt een eerste ontwerp gegenereerd door AI, dat vervolgens door uw team wordt nagelezen en goedgekeurd.
• Gekoppelde afhankelijkheden: proces ↔ IT-dienst ↔ leverancier ↔ risico, met controle van de dekking van de 5 onbeschikbaarheden en de scenario's met hoog risico ten opzichte van uw strategieën.
• Oefeningen en evaluaties: tafeloefeningen, waarbij vaststellingen worden omgezet in corrigerende acties die tot afsluiting worden opgevolgd.
• Bewijs: ISO 22301 clausules 4 tot 10, NIS2 artikel 21 en DORA in kaart gebracht, een downloadbaar bewijspakket, export naar Word en PDF.
• Voor consultants: één werkruimte per klant om meerdere continuïteitsopdrachten vanuit één interface te beheren.

Bedrijfsgegevens worden gehost in de Europese Unie. Een eerlijke kanttekening: software maakt niemand "conform" en certificeert niemand. ResiPlan structureert, verbindt en documenteert het werk dat uw teams leveren. Gratis proefperiode van 7 dagen, zonder kredietkaart.

Checklist: is uw bedrijfscontinuïteitsplan klaar?

• Een sponsor uit de directie en een bedrijfscontinuïteitsverantwoordelijke zijn aangesteld.
• Het continuïteitsbeleid is geschreven, goedgekeurd en gedateerd.
• Kritieke activiteiten zijn geïdentificeerd en hun afhankelijkheden in kaart gebracht (mensen, applicaties, data, leveranciers, locaties).
• Een BIA heeft voor elke kritieke activiteit de MTPD, RTO, RPO en MBCO vastgelegd.
• De kloven tussen business-RTO's en technisch vermogen zijn geïdentificeerd en aangepakt.
• Elke kritieke activiteit heeft een respons voor elk van de 5 onbeschikbaarheden.
• De scenario's met hoog risico uit de risicobeoordeling zijn gedekt.
• De gekozen strategieën zijn begroot en onderbouwd door de BIA.
• Kritieke leveranciers hebben contractuele continuïteitsverbintenissen en er is een terugvaloptie.
• Het plan benoemt titularissen en vervangers voor elke rol.
• De crisiscontactenlijst is actueel en bereikbaar buiten de IT van het bedrijf.
• Meldingssjablonen (NIS2, DORA, AVG) en crisisberichten zijn klaar.
• Kritieke back-ups zijn de voorbije 12 maanden met succes teruggezet.
• De voorbije 12 maanden vond een oefening plaats en de corrigerende acties worden opgevolgd.
• Het management heeft het programma binnen het jaar beoordeeld.

Voor een uitgebreidere beoordeling: ISO 22301-checklist, NIS2-zelfevaluatie, DORA-readinesschecklist.

FAQ

Wat is het verschil tussen een BCP en een DRP?

Een BCP heeft tot doel essentiële activiteiten draaiende te houden tijdens een verstoring, over de hele organisatie heen (bedrijfsonderdelen, mensen, gebouwen, leveranciers, IT). Een DRP heeft tot doel opnieuw op te starten na een uitval, hoofdzakelijk van IT-systemen. Het DRP is één onderdeel van het BCP.

Hoe lang duurt het om een bedrijfscontinuïteitsplan op te bouwen?

Voor een bedrijf met 50 tot 250 medewerkers dat start met twee of drie kritieke diensten, rekent u op ongeveer 6 tot 12 weken voor een eerste geoefende versie. Voor een groep met meerdere locaties enkele maanden. Het schrijven is zelden de bottleneck: de beschikbaarheid van de businessteams voor de BIA wel.

Wie moet het bedrijfscontinuïteitsplan schrijven?

De bedrijfscontinuïteitsverantwoordelijke coördineert, maar de bedrijfsonderdelen schrijven hun eigen procedures: enkel zij weten hoe ze in degradatiemodus moeten werken. IT schrijft het DRP en het management keurt het beleid en de afwegingen goed. Een plan dat enkel door een consultant is geschreven, zonder de teams, zal niet worden gevolgd. Voor consultants, zie hoe u bedrijfscontinuïteitsopdrachten opschaalt.

Hoe vaak moet een bedrijfscontinuïteitsplan worden getest?

Minstens één keer per jaar voor een betekenisvolle oefening (een verplichting voor ICT-bedrijfscontinuïteitsplannen onder DORA), en na elke grote wijziging: een nieuwe kritieke applicatie, een nieuwe leverancier, een verhuis, een reorganisatie.

Is een bedrijfscontinuïteitsplan verplicht voor kmo's?

Dat is het voor kmo's die onder NIS2 (essentiële of belangrijke entiteiten) of DORA vallen, en voor bepaalde gereglementeerde activiteiten. Voor alle anderen wordt het de facto een vereiste van klanten, verzekeraars en overheidsopdrachten.

Hebt u een ISO 22301-certificering nodig?

Nee, certificering is vrijwillig. Maar de structuur van de norm volgen zorgt ervoor dat uw BCP dekt wat auditors, toezichthouders en grote klanten verwachten, en maakt een latere certificering eenvoudig als die een commerciële troef wordt: zie ISO 22301-certificering: stappen, doorlooptijd en kosten.

Wat moet een bedrijfscontinuïteitsplan minimaal bevatten?

Een toepassingsgebied en een eigenaar, activeringscriteria, een crisisorganisatie met vervangers, een contactenlijst die bereikbaar is buiten de IT van het bedrijf, procedures per kritieke activiteit en per onbeschikbaarheid, degradatiemodi, een procedure voor de terugkeer naar normaal, en een verslag van de laatste oefening.

Verder lezen

• IT-herstelplan: volledige gids
• Crisiscel: rollen, structuur en activering
• ISO 22301 in 10 stappen: een conform BCMS invoeren
• BIA-gids in 7 stappen, met een gratis sjabloon
• ISO 22301 vs ISO 27001: verschillen en overlap
• DORA vs NIS2: welke regelgeving is op u van toepassing?
• Generator voor bedrijfscontinuïteitsplannen

Een bedrijfscontinuïteitsplan is pas iets waard op de dag dat het wordt gebruikt. Tot dan komt de kwaliteit ervan neer op één ding: zijn vermogen om waarheidsgetrouw te blijven terwijl de organisatie rondom verandert.