Forretningskontinuitet holder organisationens kritiske aktiviteter kørende under en afbrydelse. Disaster Recovery (katastrofeberedskab) gendanner den teknologi, som disse aktiviteter er afhængige af. De er ikke konkurrerende tilgange, og de er ikke det samme dokument. Kontinuitet er en forretningsdisciplin, der bestemmer, hvad der skal fortsætte, og hvordan. Recovery er en teknisk disciplin, der genopbygger systemer i en defineret rækkefølge for at nå forretningssættet.
- Forskellige ejere: kontinuitet ligger normalt hos driften eller risikoen, genopretning hos IT.
- Forskellige udløsere: kontinuitet aktiveres ved forretningsmæssig påvirkning, genopretning ved tekniske fejl.
- Forskellige definitioner af succes: arbejde fortsætter versus systemer genoprettet.
- Et fælles sæt tal, begge taget fra den samme analyse af forretningsmæssig påvirkning.
- Fejlene sker i samlingen mellem dem, ikke inden i nogen af dem.
Hvordan er forretningskontinuitet og katastrofeberedskab egentlig forskellige?
Når man spørger de fleste om forretningskontinuitet versus katastrofegendannelse, kommer svaret tilbage som omfang: kontinuitet er bredt, genopretning er teknisk. Det er sandt, og det er ikke til megen nytte, når man skal beslutte, hvem der skriver hvad. Den mere nyttige adskillelse er efter, hvad hver disciplin er ansvarlig for, og hvor den får sine instruktioner fra.
En kontinuitetsplan starter med aktiviteter. Den spørger, hvilke ting organisationen gør, som ikke kan stoppes, hvor længe hver enkelt ting kan afbrydes, før skaden bliver alvorlig, og hvilken alternativ arbejdsmetode der vil være gældende i mellemtiden. Dens output er et sæt beslutninger om prioritet og løsning.
En genopretningsplan starter med systemerne. Den spørger, hvad der skal tilbage, i hvilken rækkefølge, for at nå de tidsrammer, der er aftalt for kontinuitet. Dens output er en runbook. Det bredere billede af, hvordan begge dele indgår i en enkelt funktion, er beskrevet under forretningskontinuitet.
| Forretningskontinuitet | opsving Disaster | |
|---|---|---|
| Hvem ejer det | Drift, risiko eller en dedikeret kontinuitetsleder med ledelsessponsorering. | IT eller infrastruktur, ofte det samme team, der driver platformen i det daglige. |
| Hvad udløser det | Forretningsmæssig påvirkning når en tærskel, uanset årsagen, inklusive årsager uden teknisk komponent. | En teknisk fejl eller tab af et system, et websted eller et datasæt. |
| Hvad betyder genvundet | Kritiske aktiviteter leveres til kunderne igen, ad enhver acceptabel rute. | De navngivne systemer kører, er tilgængelige og verificerede i forhold til deres dataintegritetskontroller. |
| Hvor målene kommer fra | Analysen af forretningsmæssige konsekvenser, underskrevet af de personer, der er ansvarlige for hver aktivitet. | Arvet fra kontinuitet. Genopretning sætter ikke sine egne mål. |
| Hvad revisorer beder om | Dokumentation for øvelser, der involverer virksomheden, og at prioriteterne afspejler den nuværende drift. | Dokumentation for gendannelsestests med resultater, og at sikkerhedskopier faktisk kan gendannes. |
| Hvad det koster at tage fejl | Arbejdet stopper, selvom systemerne er i orden, fordi ingen har aftalt den manuelle rute. | Systemerne vender tilbage i en rækkefølge, der lader den kritiske aktivitet vente længst. |
Hvem ejer hver plan, og hvorfor skaber det problemer?
Opdelt ejerskab er fornuftigt. De personer, der ved, hvilke kundeforpligtelser der er vigtige, er ikke dem, der kender gendannelsessekvensen for en databaseklynge. Problemet er ikke opdelingen, det er, at de to sider ofte skriver isoleret og kun opdager uoverensstemmelsen under en hændelse.
Tre mønstre dukker op gentagne gange. Det første er en genopretningsplan med mål, som ingen i branchen er enige om, normalt sat ud fra, hvad infrastrukturen komfortabelt kan opnå, snarere end ud fra, hvad aktiviteten har brug for. Det andet er en kontinuitetsplan, der forudsætter en manuel løsning, som stille og roligt afhænger af det samme system, der har fejlet. Det tredje er det mest almindelige: begge planer eksisterer, begge er teknisk forsvarlige, og ingen af dem angiver, hvem der rapporterer en hændelse, eller hvem der beslutter, at normal drift er genoptaget.
Løsningen er ikke en fusion. Det er en defineret grænseflade: fælles mål taget fra analysen af forretningsmæssige konsekvenser , én myndighed til at påberåbe sig og træde tilbage, og en fælles øvelse mindst én gang om året, hvor begge sider er til stede.
Der er et større billede bag dette.
Denne side dækker én del af forretningsrobusthed. Real Resilience — IO's ramme for at forbinde sikkerhed, privatliv og AI-styring — er der, hvor det fulde billede kommer sammen.
Hvor overlader den ene til den anden?
De fleste obduktioner af hændelser, der sætter skylden på en plan, beskriver i virkeligheden en overdragelse, der aldrig blev defineret. Kontinuitet og genopretning løber parallelt, ikke i rækkefølge, og de berører fire punkter: beslutningen om at aktivere, valget af, hvad virksomheden gør, mens systemerne er nede, det øjeblik, hvor teknologien erklæres brugbar igen, og bekræftelsen af, at virksomheden virkelig er tilbage i stedet for blot at være forbundet.
Bemærk, hvor sekvensen starter. Detektion er næsten altid teknisk, hvilket er grunden til, at så mange organisationer behandler hele hændelsen som et IT-anliggende og involverer virksomheden for sent. Når kontinuitetsbeslutningen er nødvendig, er det nyttige vindue for en ren løsning ofte allerede lukket.
Hvad sker der i de første 24 timer?
Begge planer er aktive på én gang og udfører forskelligt arbejde. At angive dette eksplicit er den mest værdifulde side i begge dokumenter, fordi det fjerner pausen, hvor alle venter på at se, hvem der går først.
| Stage | Kontinuitet gør det | Genopretningen er i gang |
|---|---|---|
| Første time | Fastlæggelse af hvilke aktiviteter der er berørt, og bekræftelse af, hvem der har bemyndigelse til at påberåbe sig. | Diagnosticering af omfang, isolering af fejlen og bekræftelse af, om backups er intakte. |
| Timer to til fire | Fremhæv den alternative arbejdsmetode og fortæl det til personale og kunder. | Beslutning om, hvorvidt der skal repareres på stedet eller foretages failover, og start af gendannelsen. |
| Timer fire til tolv | Holder løsningen tilgængelig for folk og holder styr på, hvad der akkumuleres ugjort. | Gendannelse i afhængighedsrækkefølge og verificering af data, når hvert lag vender tilbage. |
| Timer fra tolv til fireogtyve | Håndtering af træthed, overdragelser og den voksende efterslæbning, som løsningen ikke kan absorbere. | Tilbagebringelse af de resterende applikationer og test af dem mod rigtige transaktioner. |
| Ud over fireogtyve timer | Beslut hvornår man skal træde tilbage, og afvikle efterslæbet i prioriteret rækkefølge. | Bekræftelse af fuld service, afstemning af data skrevet under løsningen. |
Den sidste række er der, hvor de fleste planer stopper, og de fleste virkelige hændelser ikke gør. Arbejde udført manuelt skal afstemmes i systemerne bagefter, og en efterslæbning, der ryddes i den forkerte rækkefølge, kan forårsage en anden forstyrrelse.
Har du brug for begge dele, eller kan ét dokument dække det?
Små organisationer har ofte ét enkelt dokument, og for en virkelig lille operation kan det fungere. Testen er ikke størrelse, men om de to målgrupper hver især kan finde det, de har brug for under pres. En ingeniør, der gendanner en database klokken tre om morgenen, bør ikke læse om kundekommunikation, og en driftsleder, der starter en manuel proces, bør ikke bladre gennem failover-kommandoer. Hvad selve kontinuitetsdokumentet skal indeholde, og hvor hvert afsnit får sit indhold, er beskrevet i forretningskontinuitetsplanen.
Hold dem adskilt, når en af målgrupperne har brug for mere end en side eller to, og sørg for at de krydsrefererer. Det, der aldrig må duplikeres, er tallene. Hvis tidsrammen for genopretning fremgår af begge dokumenter, og de ikke stemmer overens, vil planerne modsige hinanden præcis, når det betyder mest. Sæt målene én gang, i konsekvensanalysen, og referer til dem alle andre steder. Detaljerne i det tekniske dokument er dækket under katastrofeberedskabsplanen , og scenarieniveauet under begge står i dine beredskabsplaner.
Hvis din interesse her er specifik for det enkelte rammeværk, er sammenligningen med en SOC 2-revision dækket separat i afsnittet om, hvad SOC 2 kræver af kontinuitet og genopretning.
Hvilke standarder dækker hver enkelt?
Opdelingen fremgår af selve standarderne, hvilket er et nyttigt tjek af omfanget. ISO 22301 specificerer et ledelsessystem til forretningskontinuitet: det er certificerbart, og det handler om den organisatoriske kapacitet. ISO/IEC 27031 dækker informations- og kommunikationsteknologiens beredskab til forretningskontinuitet, hvilket er genopretningslaget. ISO 27001 forbinder dem gennem bilag A, hvor kontrol 5.29 omhandler informationssikkerhed under afbrydelser, og kontrol 5.30 omhandler IKT-beredskab.
At arbejde efter disse standarder forener ikke de to discipliner, men det tvinger grænsefladen til at eksistere. Et ledelsessystem skal vise, at den tekniske parathed tjener forretningsprioriteterne, hvilket netop er den samling, der fejler, når ingen bliver bedt om at demonstrere den.
ISO 27001 gjort nemt
Et forspring på 81% fra dag ét
Vi har gjort det hårde arbejde for dig, hvilket giver dig en 81% forspring fra det øjeblik, du logger på. Alt du skal gøre er at udfylde de tomme felter.
Hvordan passer parret ind i virksomhedens robusthed?
Kontinuitet og genopretning besvarer begge det samme spørgsmål: hvad sker der, når noget går i stykker. Modstandsdygtighed besvarer et bredere spørgsmål. Det er evnen til at absorbere forandringer af enhver art, inklusive forstyrrelser, du aldrig skrev en plan for, og forpligtelser, der ikke eksisterede, da du skrev dem. Begge planer er komponenter af den snarere end erstatninger for den.
Resilience Loop kører informationssikkerhed i henhold til ISO 27001 , databeskyttelse i henhold til ISO 27701 og AI-styring i henhold til ISO 42001 som ét forbundet system. Kontinuitet og gendannelse ligger over de samme kontroller som en yderligere linse. Det er afgørende i sin helhed: adgangsstyring, backup og leverandørkontroller, som en gendannelsesrunbook afhænger af, er de samme, som kontinuitetsløsningen afhænger af, så vedligeholdelsen af dem tjener begge. Hvordan det hele hænger sammen, er beskrevet i Business Resilience Framework.
Det forklarer også, hvorfor et nedbrud kan blive et privatlivsanliggende inden for få timer. Gendannelse af et system fra en ældre sikkerhedskopi kan gendanne data, som en person har bedt dig om at slette, og en løsning, der flytter kundedata til et regneark, skaber en behandlingsrute, som ingen har vurderet. At behandle gendannelse som rent teknisk er, hvordan disse konsekvenser bliver overset.
Hvordan beviser du, at begge virker?
Ingen tester, om du ejer to dokumenter. Kunder, revisorer og regulerede klienter stiller et sværere spørgsmål: vis mig, at begge fungerer, at de stemmer overens med hinanden, og at de afspejler, hvordan du opererer nu.
Det betyder de nuværende mål med dokumentation for, hvem der har godkendt dem, en genoprettelsestest med resultater i stedet for en planlagt dato, en forretningsøvelse med navngivne deltagere, resultaterne fra begge og de afsluttede korrigerende handlinger. Den fælles øvelse er den, der oftest mangler, og det er det eneste bevis, der overhovedet taler for overdragelsen. Tilgangen er beskrevet i, hvordan man dokumenterer resiliens , og Resiliens-scoren giver dig en basislinje.
Hvorfor vælge ISMS.online for kontinuitet og genopretning?
Samspillet mellem disse to planer er lige så meget et problem med registrering som et problem med planlægning. ISMS.online sørger for, at begge sider arbejder fra samme kilde.
- Ét sæt målGenopretningstidsrammerne findes ét sted og understøtter begge planer, så de ikke kan glide fra hinanden.
- Planer knyttet til de kontroller, de er afhængige afBackup-, adgangs- og leverandørkontrollerne bag hver plan er synlige, så et hul i den ene viser sig i den anden.
- Indbyggede træningsregistreringerPlanlæg tekniske gendannelsestests og forretningsøvelser sammen, indfang resultater og spor handlinger i det samme system.
- Ét kontrolsæt, alle frameworks: kortlæg én gang og genbrug på tværs af ISO 22301, ISO 27001, ISO 27701 og ISO 42001 i stedet for at opretholde parallelle sæt.
- Beviser på forlangende: vis en aktuel plan med en testhistorik, ikke et dokument og en garanti.
- Ejerskab, der holderNavngivne ejere, stedfortrædere og gennemgangsdatoer på begge sider af overdragelsen.
- Bygget til britiske og regulerede markeder: designet til organisationer, der skal bevise modstandsdygtighed for at vinde og holde kontrakter.
Se hvordan det hænger sammen på platformen for forretningsrobusthed , eller book en demo.
Ofte Stillede Spørgsmål
Er katastrofeberedskab en del af forretningskontinuitet.
Ja, i den forstand at genopretning tjener de mål, der er sat for kontinuitet. Forretningskontinuitet er den bredere disciplin, der dækker alle kritiske aktiviteter og enhver årsag til forstyrrelser, inklusive dem uden et teknisk element. Katastrofeberedskab er den teknologiske komponent i det. Genopretning arver sine mål fra kontinuitet i stedet for at sætte sine egne, hvilket er grunden til, at en genopretningsplan, der er skrevet uden en forretningsmæssig konsekvensanalyse, har en tendens til at beskytte de forkerte systemer først.
Kan vi have en katastrofeberedskabsplan uden en plan for forretningskontinuitet?
Det kan du, og det gør mange organisationer, men så gætter du på dine egne prioriteter. Uden en fælles opfattelse af, hvilke aktiviteter der er vigtige, og hvor længe hver enkelt kan afbrydes, fastsættes gendannelsesordren af teknisk bekvemmelighed. Den giver heller ingen løsning på forstyrrelser, der ikke er tekniske, såsom tab af et sted, en nøgleleverandør eller de personer, der driver en kritisk proces.
Hvem skal eje hver plan?
Kontinuitet hører hjemme hos forretningen, normalt driften eller risikoen, med en ledende sponsor, der kan forpligte sig til prioriteter. Genopretning hører hjemme hos IT eller infrastruktur. Den vigtige del er ikke rapporteringslinjen, men grænsefladen: én navngiven myndighed til at påberåbe sig og træde tilbage, ét fælles sæt af genopretningsmål og en fælles øvelse, hvor begge sider er til stede.
Bruger de to planer den samme RTO?
De bør bruge de samme tal, taget fra én kilde. Målet for genopretningstid for en aktivitet er fastsat i forretningskonsekvensanalysen, og den tekniske plan er designet til at opfylde det, idet der tages højde for, at et system, der er tilbage, ikke er det samme som den aktivitet, der kan leveres. Hvis de to dokumenter hver især indeholder deres egen version af tallet, vil de i sidste ende være uenige, og uenigheden vil dukke op under en hændelse.
Hvor ofte skal vi træne dem sammen?
Mindst årligt og efter enhver ændring, der påvirker overdragelsen: et nyt kritisk system, en anden hostingaftale, en omorganisering, der flytter ejerskab, eller en reel hændelse. Separate tekniske gendannelsestests kan køres oftere og bør. Den fælles øvelse er den, der tester grænsefladen, så et program med hyppige tekniske tests og ingen fælles øvelse efterlader det mest sandsynlige fejlpunkt uundersøgt.
