Bedrijfscontinuïteit zorgt ervoor dat de cruciale activiteiten van de organisatie blijven draaien tijdens een verstoring. Rampenherstel herstelt de technologie waarvan die activiteiten afhankelijk zijn. Het zijn geen concurrerende benaderingen en het is niet hetzelfde document. Continuïteit is een bedrijfsdiscipline die bepaalt wat er moet blijven draaien en hoe. Herstel is een technische discipline die systemen in een vooraf bepaalde volgorde herbouwt, volgens de door het bedrijf gestelde doelen.
- Verschillende verantwoordelijkheden: continuïteit valt meestal onder de verantwoordelijkheid van operations of risicobeheer, herstel onder die van IT.
- Verschillende triggers: continuïteit wordt geactiveerd bij impact op de bedrijfsvoering, herstel bij technische storingen.
- Verschillende definities van succes: het werk wordt voortgezet versus de systemen worden hersteld.
- Eén gedeelde set cijfers, beide afkomstig uit dezelfde bedrijfsimpactanalyse.
- De breuken ontstaan op de naad tussen beide, niet binnenin één van beide.
Wat is nu precies het verschil tussen bedrijfscontinuïteit en rampenherstel?
Vraag de meeste mensen naar het verschil tussen bedrijfscontinuïteit en rampenherstel, en het antwoord zal neerkomen op de reikwijdte: continuïteit is breed, herstel is technisch. Dat klopt, maar het is niet erg nuttig als je bepaalt wie wat schrijft. Een nuttigere scheiding is gebaseerd op de verantwoordelijkheden van elke discipline en waar die haar instructies vandaan haalt.
Een continuïteitsplan begint bij de activiteiten. Het stelt de vraag welke activiteiten de organisatie uitvoert die niet kunnen worden stopgezet, hoe lang elke activiteit kan worden onderbroken voordat de schade ernstig wordt, en welke alternatieve werkwijze in de tussentijd van toepassing is. Het resultaat is een reeks beslissingen over prioriteit en alternatieve oplossingen.
Een herstelplan begint bij de systemen. Het stelt de vraag wat er moet terugkeren en in welke volgorde, om de toegezegde continuïteitstermijnen te halen. Het resultaat is een draaiboek. Het bredere plaatje van hoe beide binnen één geheel passen, wordt uiteengezet onder bedrijfscontinuïteit.
| Bedrijfscontinuïteit | ramp herstel | |
|---|---|---|
| Wie is de eigenaar? | Een leidinggevende op het gebied van operationele zaken, risicobeheer of bedrijfscontinuïteit, met steun van het management. | IT of infrastructuur, vaak hetzelfde team dat het platform dagelijks beheert. |
| Wat is de aanleiding? | De impact op de bedrijfsvoering bereikt een drempelwaarde, ongeacht de oorzaak, ook oorzaken zonder technische component. | Een technische storing of verlies van een systeem, site of dataset. |
| Wat betekent 'hersteld'? | Essentiële diensten worden weer via alle mogelijke kanalen aan klanten geleverd. | De genoemde systemen zijn operationeel, bereikbaar en geverifieerd op basis van hun gegevensintegriteitscontroles. |
| Waar komen de doelstellingen vandaan? | De bedrijfsimpactanalyse, goedgekeurd door de personen die verantwoordelijk zijn voor elke activiteit. | Overgenomen van continuïteit. Herstel stelt geen eigen doelen. |
| Wat auditors vragen | Bewijs van oefeningen waarbij het bedrijf betrokken is, en dat de prioriteiten de huidige bedrijfsvoering weerspiegelen. | Bewijs van hersteltests met resultaten, en dat back-ups daadwerkelijk herstelbaar zijn. |
| Wat het kost om een fout te maken | Het werk ligt stil, ook al functioneren de systemen naar behoren, omdat niemand het eens is geworden over de handmatige werkwijze. | De systemen worden in een volgorde hersteld waarbij de kritieke activiteit het langst moet wachten. |
Wie is de eigenaar van elk plan, en waarom leidt dat tot problemen?
Gesplitst eigenaarschap is verstandig. De mensen die weten welke klantverplichtingen belangrijk zijn, zijn niet degenen die de herstelprocedure voor een databasecluster kennen. Het probleem is niet de splitsing zelf, maar dat de twee partijen vaak geïsoleerd van elkaar werken en de discrepantie pas ontdekken tijdens een incident.
Drie patronen komen steeds terug. Het eerste is een herstelplan met doelstellingen waar niemand binnen het bedrijf het over eens was, meestal gebaseerd op wat de infrastructuur comfortabel aankan in plaats van wat de activiteit vereist. Het tweede is een continuïteitsplan dat uitgaat van een handmatige noodoplossing die stilletjes afhankelijk is van hetzelfde systeem dat is uitgevallen. Het derde is het meest voorkomende: beide plannen bestaan, beide zijn technisch deugdelijk, en geen van beide zegt wie een incident afkondigt of wie besluit dat de normale dienstverlening is hervat.
De oplossing is geen fusie. Het is een duidelijk omschreven interface: gedeelde doelstellingen afgeleid van de bedrijfsimpactanalyse , één bevoegd gezag om beslissingen te nemen en weer in te trekken, en minstens één keer per jaar een gezamenlijke oefening waarbij beide partijen aanwezig zijn.
Er zit een groter geheel achter.
Deze pagina behandelt een onderdeel van bedrijfsveerkracht. Real Resilience – het raamwerk van IO voor het verbinden van beveiliging, privacy en AI-governance – is waar het volledige plaatje samenkomt.
Waar geeft de een het stokje over aan de ander?
De meeste analyses achteraf die een plan de schuld geven, beschrijven in werkelijkheid een overdracht die nooit is gedefinieerd. Continuïteit en herstel verlopen parallel, niet na elkaar, en raken elkaar op vier punten: de beslissing om het proces te starten, de keuze wat het bedrijf doet terwijl de systemen uitvallen, het moment waarop de technologie weer bruikbaar wordt verklaard, en de bevestiging dat het bedrijf daadwerkelijk weer operationeel is en niet slechts tijdelijk verbonden.
Let op waar de sequentie begint. Detectie is bijna altijd technisch van aard, waardoor veel organisaties de hele gebeurtenis als een IT-kwestie beschouwen en de business er te laat bij betrekken. Tegen de tijd dat de beslissing over de continuïteit genomen moet worden, is de mogelijkheid voor een schone workaround vaak al verdwenen.
Wat gebeurt er in de eerste 24 uur?
Beide plannen zijn tegelijkertijd actief en voeren verschillende taken uit. Het expliciet vastleggen hiervan is de meest waardevolle pagina in beide documenten, omdat het de wachttijd wegneemt waarin iedereen afwacht wie er als eerste aan de slag gaat.
| Stadium | Continuïteit is het volgende: | Het herstel verloopt voorspoedig. |
|---|---|---|
| Eerste uur | Vaststellen welke activiteiten worden beïnvloed en bevestigen wie bevoegd is om deze maatregelen in te roepen. | Het probleem diagnosticeren, de oorzaak van de storing vaststellen en controleren of de back-ups intact zijn. |
| Uren twee tot vier | Het alternatieve werkmodel naar voren brengen en dit aan medewerkers en klanten vertellen. | Beslissen of de reparatie ter plaatse moet worden uitgevoerd of dat er een failover moet plaatsvinden, en vervolgens het herstelproces starten. |
| Uur vier tot twaalf | Zorg ervoor dat er voldoende mensen beschikbaar zijn voor de noodoplossing en houd bij welke taken zich nog opstapelen. | De gegevens worden hersteld in de volgorde van afhankelijkheden en geverifieerd zodra elke laag is hersteld. |
| Uur twaalf tot vierentwintig | Het beheersen van vermoeidheid, overdrachten en de groeiende achterstand die de tijdelijke oplossing niet kan opvangen. | De resterende applicaties weer in gebruik nemen en testen aan de hand van echte transacties. |
| Meer dan vierentwintig uur | Beslissen wanneer het werk stil ligt en vervolgens de achterstand in prioriteitsvolgorde wegwerken. | Volledige service bevestigen en gegevens die tijdens de tijdelijke oplossing zijn vastgelegd, controleren. |
De laatste rij is waar de meeste plannen stoppen, terwijl de meeste daadwerkelijke incidenten daar niet plaatsvinden. Handmatig uitgevoerd werk moet achteraf in de systemen worden verwerkt, en een achterstand die in de verkeerde volgorde wordt weggewerkt, kan een tweede verstoring veroorzaken.
Heb je beide documenten nodig, of volstaat één document?
Kleine organisaties hanteren vaak slechts één document, en voor een echt kleine organisatie kan dat prima werken. De vraag is niet of het document groot genoeg is, maar of de twee doelgroepen er onder druk in kunnen vinden wat ze nodig hebben. Een engineer die om drie uur 's ochtends een database herstelt, hoeft niet te lezen over klantcommunicatie, en een operations manager die een handmatig proces opzet, hoeft niet door failover-commando's te bladeren. Wat het continuïteitsdocument zelf moet bevatten en waar elke sectie zijn inhoud vandaan haalt, wordt beschreven in het bedrijfscontinuïteitsplan.
Houd ze gescheiden zodra een van beide doelgroepen meer dan een of twee pagina's nodig heeft, en verwijs er regelmatig naar. Wat nooit gedupliceerd mag worden, zijn de cijfers. Als de hersteltermijn in beide documenten voorkomt en ze verschillen, zullen de plannen elkaar tegenspreken, juist op het moment dat het er het meest toe doet. Stel de doelstellingen één keer vast, in de impactanalyse, en verwijs er overal naar. De details van het technische document worden behandeld in het rampenherstelplan , en het scenario-niveau daaronder valt onder uw noodplannen.
Als uw interesse hier specifiek betrekking heeft op het framework, wordt de vergelijking met een SOC 2-audit afzonderlijk behandeld in het gedeelte over de vereisten van SOC 2 met betrekking tot continuïteit en herstel.
Welke normen zijn op elk van deze van toepassing?
De tweedeling komt tot uiting in de normen zelf, wat een nuttige controle is op de reikwijdte. ISO 22301 specificeert een managementsysteem voor bedrijfscontinuïteit: het is certificeerbaar en het gaat over de organisatorische capaciteit. ISO/IEC 27031 behandelt de gereedheid van informatie- en communicatietechnologie voor bedrijfscontinuïteit, oftewel de herstellaag. ISO 27001 verbindt ze via Annex A, waar controle 5.29 betrekking heeft op informatiebeveiliging tijdens verstoringen en controle 5.30 op ICT-gereedheid.
Het werken volgens die standaarden zorgt er niet voor dat de twee disciplines samensmelten, maar het dwingt wel tot het bestaan van een interface. Een managementsysteem moet aantonen dat de technische gereedheid de zakelijke prioriteiten dient, en dat is precies de schakel die wankelt wanneer niemand wordt gevraagd om dat aan te tonen.
ISO 27001 eenvoudig gemaakt
Een voorsprong van 81% vanaf dag één
Wij hebben het harde werk voor u gedaan, waardoor u vanaf het moment dat u inlogt een voorsprong van 81% heeft. U hoeft alleen nog maar de lege plekken in te vullen.
Hoe past dit duo in het kader van bedrijfsveerkracht?
Continuïteit en herstel beantwoorden beide dezelfde vraag: wat gebeurt er als er iets kapotgaat? Veerkracht beantwoordt een bredere vraag. Het is het vermogen om veranderingen van welke aard dan ook op te vangen, inclusief verstoringen waarvoor je nooit een plan hebt opgesteld en verplichtingen die nog niet bestonden toen je ze opstelde. Beide plannen zijn onderdelen van veerkracht, geen vervanging ervan.
De Resilience Loop beheert informatiebeveiliging volgens ISO 27001 , gegevensprivacy volgens ISO 27701 en AI-governance volgens ISO 42001 als één samenhangend systeem. Continuïteit en herstel worden vanuit dezelfde controles beheerd, maar dan als een extra perspectief. Dat is cruciaal: het toegangsbeheer, de back-up- en leverancierscontroles waarop een herstelplan is gebaseerd, zijn dezelfde als waarop de continuïteitsoplossing is gebaseerd. Door deze controles één keer te onderhouden, worden beide doelen bereikt. Hoe het geheel in elkaar past, wordt beschreven in het raamwerk voor bedrijfscontinuïteit.
Het verklaart ook waarom een storing binnen enkele uren een privacykwestie kan worden. Het herstellen van een systeem vanuit een oudere back-up kan gegevens terugplaatsen die iemand juist wilde laten verwijderen, en een tijdelijke oplossing waarbij klantgegevens naar een spreadsheet worden verplaatst, creëert een verwerkingsroute die niemand heeft overwogen. Door herstel puur als een technische kwestie te beschouwen, worden deze gevolgen over het hoofd gezien.
Hoe bewijs je dat beide werken?
Niemand controleert of u twee documenten bezit. Klanten, auditors en opdrachtgevers stellen een lastigere vraag: laat me zien dat beide documenten werken, dat ze met elkaar overeenkomen en dat ze uw huidige bedrijfsvoering weerspiegelen.
Dat betekent de huidige doelstellingen met bewijs van wie ze heeft goedgekeurd, een hersteltest met resultaten in plaats van een geplande datum, een bedrijfsoefening met benoemde deelnemers, de bevindingen van beide, en de afgeronde corrigerende maatregelen. De gezamenlijke oefening ontbreekt het vaakst en is het enige bewijs dat de overdracht überhaupt aantoont. De aanpak wordt uiteengezet in hoe veerkracht kan worden aangetoond , en de veerkrachtscore geeft een basislijn.
Waarom kiezen voor ISMS.online voor bedrijfscontinuïteit en herstel?
De kloof tussen deze twee plannen is zowel een probleem op het gebied van de administratie als van de planning zelf. ISMS.online zorgt ervoor dat beide partijen vanuit dezelfde bron werken.
- Eén reeks doelstellingenDe hersteltermijnen bevinden zich op één plek en voeden beide plannen, zodat ze niet uit elkaar kunnen lopen.
- Plannen gekoppeld aan de controlemechanismen waarop ze gebaseerd zijn.De back-up-, toegangs- en leverancierscontroles achter elk plan zijn zichtbaar, waardoor een tekortkoming in het ene plan ook in het andere aan het licht komt.
- Trainingsgegevens ingebouwdPlan technische hersteltests en bedrijfsoefeningen samen in, leg bevindingen vast en volg acties op in hetzelfde systeem.
- Eén set besturingselementen, elk framework: eenmalig in kaart brengen en hergebruiken voor ISO 22301, ISO 27001, ISO 27701 en ISO 42001 in plaats van parallelle sets te onderhouden.
- Bewijs op aanvraag: toon een actueel plan met een testgeschiedenis, niet een document en een garantieverklaring.
- Eigendom dat bezit: genoemde eigenaren, plaatsvervangers en beoordelingsdata aan beide zijden van de overdracht.
- Ontwikkeld voor de Britse en gereguleerde markten.: ontworpen voor organisaties die veerkracht moeten tonen om contracten te winnen en te behouden.
Bekijk hoe alles samenhangt op het platform voor bedrijfscontinuïteit , of vraag een demo aan.
Veelgestelde vragen
Is rampenherstel onderdeel van bedrijfscontinuïteit?
Ja, in die zin dat herstel de doelstellingen van bedrijfscontinuïteit dient. Bedrijfscontinuïteit is de bredere discipline die alle kritieke activiteiten en elke oorzaak van verstoring omvat, inclusief die zonder technisch element. Rampenherstel is de technologische component daarbinnen. Herstel ontleent zijn doelstellingen aan continuïteit in plaats van zijn eigen doelstellingen te stellen. Daarom heeft een herstelplan dat is opgesteld zonder een analyse van de bedrijfsimpact de neiging om eerst de verkeerde systemen te beschermen.
Kunnen we een rampenherstelplan hebben zonder een bedrijfscontinuïteitsplan?
Dat kan, en veel organisaties doen dat ook, maar dan moet je wel gissen naar je eigen prioriteiten. Zonder een gezamenlijke visie op welke activiteiten belangrijk zijn en hoe lang elke activiteit onderbroken mag worden, wordt de volgorde van herstel bepaald door technische overwegingen. Het biedt ook geen antwoord op verstoringen die niet technisch van aard zijn, zoals het uitvallen van een locatie, een belangrijke leverancier of de mensen die een cruciaal proces uitvoeren.
Wie moet de eigenaar van elk plan zijn?
Continuïteit hoort bij de bedrijfsafdeling, meestal de operationele afdeling of risicobeheer, met een leidinggevende die prioriteiten kan stellen. Herstel hoort bij IT of infrastructuur. Het belangrijkste is niet de hiërarchische lijn, maar de interface: één aangewezen autoriteit om herstelmaatregelen te nemen en weer op te heffen, één gezamenlijke set hersteldoelstellingen en een gezamenlijke oefening waarbij beide partijen aanwezig zijn.
Gebruiken beide plannen dezelfde RTO?
Ze zouden dezelfde cijfers moeten gebruiken, afkomstig uit één bron. De hersteltijd voor een activiteit wordt vastgesteld in de business impact-analyse en het technische plan is ontworpen om daaraan te voldoen, rekening houdend met het feit dat een systeem weer operationeel is niet hetzelfde is als de activiteit opleverbaar is. Als beide documenten hun eigen versie van het cijfer bevatten, zullen ze uiteindelijk van elkaar verschillen, en die onenigheid zal aan het licht komen tijdens een incident.
Hoe vaak moeten we ze samen oefenen?
Minimaal jaarlijks, en na elke wijziging die de overdracht beïnvloedt: een nieuw kritiek systeem, een andere hostingconfiguratie, een reorganisatie waarbij het eigenaarschap verandert, of een daadwerkelijk incident. Afzonderlijke technische hersteltests kunnen vaker worden uitgevoerd en zouden dat ook moeten. De gezamenlijke oefening test de interface, dus een programma met frequente technische tests zonder gezamenlijke oefening laat het meest waarschijnlijke faalpunt ongetest.
