Verksamhetskontinuitet håller organisationens kritiska aktiviteter igång under en störning. Katastrofåterställning återställer den teknik som dessa aktiviteter är beroende av. De är inte konkurrerande metoder och de är inte samma dokument. Kontinuitet är en affärsdisciplin som avgör vad som måste fortsätta och hur. Återställning är en teknisk disciplin som återuppbygger system i en definierad ordning, för att nå verksamhetens mål.
- Olika ägare: kontinuitet ligger vanligtvis hos driften eller risken, återhämtning hos IT.
- Olika utlösare: kontinuitet aktiveras vid påverkan på verksamheten, återhämtning vid tekniskt fel.
- Olika definitioner av framgång: arbete som fortsätter kontra system som återställts.
- En gemensam uppsättning siffror, båda hämtade från samma analys av affärskonsekvenser.
- Misslyckandena sker i skarven mellan dem, inte inuti någon av dem.
Hur skiljer sig affärskontinuitet och katastrofåterställning egentligen åt?
Frågar man de flesta om affärskontinuitet kontra katastrofåterställning kommer svaret tillbaka som omfattning: kontinuitet är brett, återställning är tekniskt. Det är sant, och det är inte särskilt användbart när man ska bestämma vem som skriver vad. Den mer användbara uppdelningen är efter vad varje disciplin är ansvarig för och var den får sina instruktioner.
En kontinuitetsplan utgår från aktiviteter. Den frågar vilka saker organisationen gör som inte kan stoppas, hur länge varje sak kan avbrytas innan skadan blir allvarlig, och vilket alternativt arbetssätt som gäller under tiden. Dess resultat är en uppsättning beslut om prioritering och lösning.
En återhämtningsplan utgår från systemen. Den frågar vad som måste komma tillbaka, i vilken ordning, för att uppnå de tidsramar som åtagits för kontinuitet. Dess resultat är en runbook. Den bredare bilden av hur båda fungerar inom en och samma funktion beskrivs under affärskontinuitet.
| Kontinuitet i verksamheten | Katastrofåterställning | |
|---|---|---|
| Vem äger den | Drift, risk eller en dedikerad kontinuitetsansvarig, med chefssponsring. | IT eller infrastruktur, ofta samma team som driver plattformen dagligen. |
| Vad som utlöser det | Affärspåverkan som når en tröskel, oavsett orsak, inklusive orsaker utan teknisk komponent. | Ett tekniskt fel eller förlust av ett system, en webbplats eller en datamängd. |
| Vad återhämtad betyder | Kritiska aktiviteter levereras till kunder igen, via alla acceptabla vägar. | De namngivna systemen är igång, nåbara och verifierade mot sina dataintegritetskontroller. |
| Varifrån målen kommer | Affärskonsekvensanalysen, undertecknad av de personer som ansvarar för varje aktivitet. | Ärvt från kontinuitet. Återhämtning sätter inte sina egna mål. |
| Vad revisorerna begär | Bevis på övningar som involverar verksamheten, och att prioriteringarna återspeglar den nuvarande verksamheten. | Bevis på återställningstester med resultat, och att säkerhetskopior faktiskt är återställningsbara. |
| Vad det kostar att göra fel | Arbetet avbryts trots att systemen är i ordning, eftersom ingen godkände den manuella rutten. | Systemen återkommer i en ordning som gör att den kritiska aktiviteten väntar längst. |
Vem äger varje plan, och varför orsakar det problem?
Delat ägande är klokt. De personer som vet vilka kundåtaganden som är viktiga är inte de som känner till återställningssekvensen för ett databaskluster. Problemet är inte uppdelningen, det är att de två sidorna ofta skriver isolerat och bara upptäcker missmatchningen under en incident.
Tre mönster dyker upp gång på gång. Det första är en återhämtningsplan med mål som ingen i verksamheten enats om, vanligtvis satta utifrån vad infrastrukturen bekvämt kan uppnå snarare än utifrån vad verksamheten behöver. Det andra är en kontinuitetsplan som förutsätter en manuell lösning som i tysthet är beroende av samma system som har fallerat. Det tredje är det vanligaste: båda planerna finns, båda är tekniskt sunda, och ingen av dem säger vem som deklarerar en incident eller vem som bestämmer att normal drift har återupptagits.
Lösningen är inte en sammanslagning. Det är ett definierat gränssnitt: gemensamma mål hämtade från affärskonsekvensanalysen , en befogenhet att åberopa och avgå, och en gemensam övning minst en gång om året där båda sidor är med.
Det finns en större bild bakom detta.
Den här sidan täcker en del av företags motståndskraft. Real Resilience – IO:s ramverk för att koppla samman säkerhet, integritet och AI-styrning – är där hela bilden kommer samman.
Var lämnar den ena över till den andra?
De flesta obduktioner av incidenter som skyller på en plan beskriver egentligen en överlämning som aldrig definierades. Kontinuitet och återhämtning löper parallellt, inte i sekvens, och de berörs vid fyra punkter: beslutet att åberopa, valet av vad verksamheten gör medan systemen är nere, det ögonblick då tekniken förklaras användbar igen och bekräftelsen att verksamheten verkligen är tillbaka snarare än bara uppkopplad.
Observera var sekvensen börjar. Detektering är nästan alltid tekniskt, vilket är anledningen till att så många organisationer behandlar hela händelsen som en IT-fråga och involverar verksamheten för sent. När kontinuitetsbeslutet behövs har det användbara fönstret för en ren lösning ofta redan stängts.
Vad händer under de första 24 timmarna?
Båda planerna är aktiva samtidigt och utför olika uppgifter. Att ange detta explicit är den enskilt mest värdefulla sidan i båda dokumenten, eftersom den tar bort pausen där alla väntar på att se vem som går först.
| Etapp | Kontinuitet gör det | Återhämtningen pågår |
|---|---|---|
| Första timmen | Fastställande av vilka verksamheter som berörs och bekräftelse av vem som har befogenhet att åberopa dessa. | Diagnostisera omfattning, isolera felet och bekräfta om säkerhetskopiorna är intakta. |
| Timmar två till fyra | Stå upp för det alternativa arbetssättet och berätta för personal och kunder. | Besluta om man ska reparera på plats eller redundansöverta, och påbörja återställningen. |
| Timmar fyra till tolv | Hålla lösningen försedd med personal och spåra vad som ackumuleras som ogjort. | Återställer i beroendeordning och verifierar data när varje lager återkommer. |
| Timmar tolv till tjugofyra | Hantering av trötthet, överlämningar och den växande eftersläpningen som lösningen inte kan absorbera. | Återställa de återstående applikationerna och testa dem mot verkliga transaktioner. |
| Över tjugofyra timmar | Att bestämma när man ska avgå och sedan åtgärda eftersläpningen i prioritetsordning. | Bekräftar fullständig service, avstämning av data som skrivits under lösningen. |
Den sista raden är där de flesta planer stannar och de flesta verkliga incidenter inte gör det. Arbete som utförs manuellt måste stämmas av i systemen i efterhand, och en eftersläpning som rensas i fel ordning kan orsaka en andra störning i sig själv.
Behöver du båda, eller kan ett dokument täcka det?
Små organisationer hanterar ofta ett enda dokument, och för en verkligt liten verksamhet kan det fungera. Testet är inte storlek, utan om de två målgrupperna var och en kan hitta det de behöver under press. En ingenjör som återställer en databas klockan tre på morgonen bör inte läsa om kundkommunikation, och en driftschef som startar en manuell process bör inte bläddra igenom redundanskommandon. Vad själva kontinuitetsdokumentet bör innehålla, och var varje avsnitt får sitt innehåll, anges i kontinuitetsplanen.
Håll dem separerade när någon av målgrupperna behöver mer än en eller två sidor, och håll dem korsrefererade. Det som aldrig får dupliceras är siffrorna. Om återställningstidsramen visas i båda dokumenten och de inte stämmer överens, kommer planerna att motsäga varandra precis när det spelar som mest roll. Sätt målen en gång, i konsekvensanalysen, och referera till dem överallt annars. Detaljerna i det tekniska dokumentet täcks av katastrofåterställningsplanen , och scenarionivån under båda finns i dina beredskapsplaner.
Om ditt intresse här är ramverksspecifikt, behandlas jämförelsen med en SOC 2-revision separat i vad SOC 2 kräver av kontinuitet och återhämtning.
Vilka standarder täcker var och en?
Uppdelningen syns i själva standarderna, vilket är en användbar kontroll av omfattningen. ISO 22301 specificerar ett ledningssystem för affärskontinuitet: det är certifierbart och handlar om den organisatoriska förmågan. ISO/IEC 27031 täcker informations- och kommunikationsteknikens beredskap för affärskontinuitet, vilket är återställningslagret. ISO 27001 kopplar samman dem genom bilaga A, där kontroll 5.29 behandlar informationssäkerhet vid störningar och kontroll 5.30 behandlar IKT-beredskap.
Att arbeta enligt dessa standarder sammanfogar inte de två disciplinerna, men det tvingar fram gränssnittet. Ett ledningssystem måste visa att den tekniska beredskapen tjänar verksamhetens prioriteringar, vilket är just den söm som brister när ingen ombeds att demonstrera den.
ISO 27001 på ett enkelt sätt
Ett försprång på 81 % från dag ett
Vi har gjort det hårda arbetet åt dig, vilket ger dig ett försprång på 81 % från det ögonblick du loggar in. Allt du behöver göra är att fylla i tomrummen.
Hur passar paret in i affärsmässig motståndskraft?
Kontinuitet och återhämtning besvarar båda samma fråga: vad händer när något går sönder. Motståndskraft besvarar en bredare fråga. Det är förmågan att absorbera förändringar av alla slag, inklusive störningar du aldrig skrev en plan för och skyldigheter som inte fanns när du skrev dem. Båda planerna är komponenter i den snarare än ersättningar för den.
Resilience Loop hanterar informationssäkerhet enligt ISO 27001 , dataskydd enligt ISO 27701 och AI-styrning enligt ISO 42001 som ett sammankopplat system. Kontinuitet och återställning styrs av samma kontroller som en ytterligare lins. Det är avgörande i grunden: åtkomsthanteringen, säkerhetskopieringen och leverantörskontrollerna som en återställnings-runbook är beroende av är samma som kontinuitetslösningen är beroende av, så att underhålla dem tjänar båda. Hur hela uppsättningen passar ihop beskrivs i ramverket för affärsresiliens.
Det förklarar också varför ett avbrott kan bli en integritetsfråga inom några timmar. Att återställa ett system från en äldre säkerhetskopia kan återställa data som en person bett dig radera, och en lösning som flyttar kundregister till ett kalkylblad skapar en bearbetningsväg som ingen har bedömt. Att behandla återställning som rent tekniskt är anledningen till att dessa konsekvenser missas.
Hur bevisar du att båda fungerar?
Ingen testar om du äger två dokument. Kunder, revisorer och reglerade kunder ställer en svårare fråga: visa mig att båda fungerar, att de överensstämmer med varandra och att de återspeglar hur du arbetar nu.
Det innebär de nuvarande målen med bevis på vem som godkände dem, ett återställningstest med resultat snarare än ett schemalagt datum, en verksamhetsövning med namngivna deltagare, resultaten från båda och de korrigerande åtgärder som avslutats. Den gemensamma övningen är den som oftast saknas, och det är det enda beviset som talar för överlämningen överhuvudtaget. Tillvägagångssättet anges i hur man bevisar motståndskraft , och motståndskraftspoängen ger dig en baslinje.
Varför välja ISMS.online för kontinuitet och återhämtning?
Fogen mellan dessa två planer är lika mycket ett problem med registrering som ett problem med planering. ISMS.online ser till att båda sidor arbetar från samma källa.
- En uppsättning målÅterhämtningstidsramarna finns på ett ställe och matar båda planerna, så de kan inte glida isär.
- Planer kopplade till de kontroller de förlitar sig påSäkerhetskopierings-, åtkomst- och leverantörskontrollerna bakom varje plan är synliga, så en lucka i den ena syns i den andra.
- Inbyggda träningsloggarSchemalägg tekniska återställningstester och affärsövningar tillsammans, samla in resultat och spåra åtgärder i samma system.
- En kontrolluppsättning, varje ramverkmappa en gång och återanvänd i ISO 22301, ISO 27001, ISO 27701 och ISO 42001 istället för att bibehålla parallella uppsättningar.
- Bevis på begäran: visa en aktuell plan med testhistorik, inte ett dokument och en försäkran.
- Ägarskap som hållernamngivna ägare, ställföreträdare och granskningsdatum på båda sidor av överlämnandet.
- Byggd för brittiska och reglerade marknaderUtformad för organisationer som måste bevisa motståndskraft för att vinna och behålla kontrakt.
Se hur det passar ihop på plattformen för företagsresiliens , eller boka en demo.
Vanliga frågor
Är katastrofåterställning en del av affärskontinuiteten?
Ja, i den meningen att återställning tjänar de mål som ställs upp för kontinuitet. Verksamhetskontinuitet är den bredare disciplin som täcker alla kritiska aktiviteter och alla orsaker till störningar, inklusive de utan tekniska element. Katastrofåterställning är den tekniska komponenten i den. Återställning ärver sina mål från kontinuitet snarare än att sätta sina egna, vilket är anledningen till att en återhämtningsplan som skrivs utan en affärskonsekvensanalys tenderar att skydda fel system först.
Kan vi ha en katastrofåterställningsplan utan en kontinuitetsplan för verksamheten?
Det kan du, och många organisationer gör det, men då gissar du över dina egna prioriteringar. Utan en överenskommen syn på vilka aktiviteter som är viktiga och hur länge varje aktivitet kan avbrytas, sätts återställningsordningen av teknisk bekvämlighet. Den lämnar inte heller något svar på störningar som inte är tekniska, såsom att förlora en anläggning, en nyckelleverantör eller de personer som driver en kritisk process.
Vem ska äga varje plan?
Kontinuitet hör hemma i verksamheten, vanligtvis driften eller risken, med en chef som kan åta sig prioriteringar. Återhämtning hör hemma i IT eller infrastruktur. Den viktiga delen är inte rapporteringslinjen utan gränssnittet: en namngiven auktoritet att åberopa och dra sig tillbaka, en gemensam uppsättning återhämtningsmål och en gemensam övning där båda sidor är närvarande.
Använder de två planerna samma RTO?
De bör använda samma siffror, hämtade från en källa. Återställningstiden för en aktivitet anges i affärskonsekvensanalysen och den tekniska planen är utformad för att uppfylla den, med hänsyn till att ett system som är tillbaka inte är detsamma som att aktiviteten är leveransbar. Om de två dokumenten har sin egen version av siffran kommer de så småningom att skilja sig åt, och oenigheten kommer att uppstå under en incident.
Hur ofta ska vi träna dem tillsammans?
Minst årligen, och efter varje förändring som påverkar överlämningen: ett nytt kritiskt system, ett annat hostingarrangemang, en omorganisation som flyttar ägarskap eller en verklig incident. Separata tekniska återställningstester kan köras oftare och bör göra det. Den gemensamma övningen är den som testar gränssnittet, så ett program med frekventa tekniska tester och ingen gemensam övning lämnar den mest sannolika felpunkten outforskad.
