Forretningskontinuitet holder organisasjonens kritiske aktiviteter i gang under en forstyrrelse. Katastrofegjenoppretting gjenoppretter teknologien disse aktivitetene er avhengige av. De er ikke konkurrerende tilnærminger, og de er ikke det samme dokumentet. Kontinuitet er en forretningsdisiplin som bestemmer hva som må fortsette og hvordan. Gjenoppretting er en teknisk disiplin som gjenoppbygger systemer i en definert rekkefølge, for å nå forretningssettet.
- Forskjellige eiere: kontinuitet ligger vanligvis hos driften eller risikoen, gjenoppretting hos IT.
- Ulike utløsere: kontinuitet aktiveres ved forretningspåvirkning, gjenoppretting ved teknisk feil.
- Ulike definisjoner av suksess: arbeidet fortsetter kontra systemer gjenopprettet.
- Ett delt sett med tall, begge hentet fra den samme analysen av forretningsmessige konsekvenser.
- Feilene skjer i skjøten mellom dem, ikke inni noen av dem.
Hvordan er egentlig forskjellen mellom forretningskontinuitet og katastrofegjenoppretting?
Når man spør folk flest om forretningskontinuitet kontra katastrofegjenoppretting, kommer svaret tilbake som omfang: kontinuitet er bredt, gjenoppretting er teknisk. Det er sant, og det er ikke så nyttig når man skal bestemme hvem som skriver hva. Det mer nyttige skillet er etter hva hver disiplin er ansvarlig for og hvor den får instruksjonene sine.
En kontinuitetsplan starter med aktiviteter. Den spør hvilke ting organisasjonen gjør som ikke kan stoppes, hvor lenge hver av dem kan avbrytes før skaden blir alvorlig, og hvilken alternativ arbeidsmåte som vil holde i mellomtiden. Resultatet er et sett med beslutninger om prioritering og midlertidig løsning.
En gjenopprettingsplan starter med systemene. Den spør hva som må komme tilbake, i hvilken rekkefølge, for å nå tidsrammene for kontinuitet som er forpliktet til. Resultatet er en runbook. Det større bildet av hvordan begge deler sitter innenfor en enkelt funksjon er beskrevet under forretningskontinuitet.
| Forretningskontinuitet | katastrofe~~POS=TRUNC gjenoppretting~~POS=HEADCOMP | |
|---|---|---|
| Hvem eier den | Drift, risiko eller en dedikert kontinuitetsleder, med ledelsessponsorering. | IT eller infrastruktur, ofte det samme teamet som driver plattformen daglig. |
| Hva utløser det | Forretningspåvirkning som når en terskel, uansett årsak, inkludert årsaker uten teknisk komponent. | En teknisk feil eller tap av et system, nettsted eller datasett. |
| Hva gjenopprettet betyr | Kritiske aktiviteter leveres til kunder igjen, via alle akseptable ruter. | De navngitte systemene kjører, er tilgjengelige og verifisert mot dataintegritetskontrollene deres. |
| Hvor målene kommer fra | Analysen av forretningsmessige konsekvenser, signert av personene som er ansvarlige for hver aktivitet. | Arvet fra kontinuitet. Gjenoppretting setter ikke sine egne mål. |
| Hva revisorer ber om | Dokumentasjon på øvelser som involverer virksomheten, og at prioriteringene gjenspeiler dagens drift. | Bevis på gjenopprettingstester med resultater, og at sikkerhetskopier faktisk kan gjenopprettes. |
| Hva det koster å ta feil | Arbeidet stopper selv om systemene er i orden, fordi ingen ble enige om den manuelle ruten. | Systemer kommer tilbake i en rekkefølge som lar den kritiske aktiviteten vente lengst. |
Hvem eier hver plan, og hvorfor forårsaker det problemer?
Delt eierskap er fornuftig. De som vet hvilke kundeforpliktelser som er viktige, er ikke de som kjenner gjenopprettingssekvensen for en databaseklynge. Problemet er ikke delingen, det er at de to sidene ofte skriver isolert og bare oppdager avviket under en hendelse.
Tre mønstre dukker opp gjentatte ganger. Det første er en gjenopprettingsplan med mål ingen i bransjen er enige om, vanligvis satt ut fra hva infrastrukturen komfortabelt kan oppnå i stedet for hva aktiviteten trenger. Det andre er en kontinuitetsplan som forutsetter en manuell løsning som i stillhet avhenger av det samme systemet som har sviktet. Det tredje er det vanligste: begge planene eksisterer, begge er teknisk forsvarlige, og ingen av dem sier hvem som rapporterer en hendelse eller hvem som bestemmer at normal drift har gjenopptatt.
Løsningen er ikke en fusjon. Det er et definert grensesnitt: felles mål hentet fra analysen av forretningsmessige konsekvenser , én myndighet til å påberope seg og trekke seg, og en felles øvelse minst én gang i året der begge sider er med i rommet.
Det er et større bilde bak dette.
Denne siden dekker én del av forretningsrobusthet. Real Resilience – IOs rammeverk for å koble sammen sikkerhet, personvern og AI-styring – er der hele bildet kommer sammen.
Hvor overlater den ene til den andre?
De fleste obduksjoner av hendelser som legger skylden på en plan, beskriver egentlig en overlevering som aldri ble definert. Kontinuitet og gjenoppretting går parallelt, ikke i rekkefølge, og de berører fire punkter: beslutningen om å aktivere, valget av hva virksomheten gjør mens systemene er nede, øyeblikket teknologien erklæres brukbar igjen, og bekreftelsen på at virksomheten virkelig er tilbake i stedet for bare å være tilkoblet.
Legg merke til hvor sekvensen starter. Deteksjon er nesten alltid teknisk, og det er derfor så mange organisasjoner behandler hele hendelsen som en IT-sak og involverer virksomheten for sent. Når kontinuitetsbeslutningen er nødvendig, er det nyttige vinduet for en ren løsning ofte allerede lukket.
Hva skjer i løpet av de første 24 timene?
Begge planene er aktive samtidig og utfører ulikt arbeid. Å sette dette eksplisitt er den mest verdifulle siden i begge dokumentene, fordi den fjerner pausen der alle venter på å se hvem som går først.
| Scene | Kontinuitet gjør det | Gjenoppretting er i gang |
|---|---|---|
| Første time | Fastslå hvilke aktiviteter som er berørt og bekrefte hvem som har myndighet til å påberope seg disse. | Diagnostisere omfang, isolere feilen og bekrefte om sikkerhetskopiene er intakte. |
| Timer to til fire | Stå opp for den alternative arbeidsmåten og fortelle det til ansatte og kunder. | Avgjøre om man skal reparere på stedet eller bruke failover, og starte gjenopprettingen. |
| Timer fire til tolv | Holde løsningen tilgjengelig for folk og spore hva som akkumuleres ugjort. | Gjenoppretter i avhengighetsrekkefølge og verifiserer data etter hvert som hvert lag kommer tilbake. |
| Klokkene tolv til tjuefire | Håndtering av tretthet, overleveringer og den voksende etterslepet som løsningen ikke kan absorbere. | Tilbakeføring av de gjenværende applikasjonene og testing av dem mot reelle transaksjoner. |
| Utover tjuefire timer | Bestemme når man skal trekke seg, og deretter rydde opp i etterslepet i prioritert rekkefølge. | Bekrefter full service, avstemmer data skrevet under løsningen. |
Den siste raden er der de fleste planer stopper, og de fleste reelle hendelser stopper ikke. Arbeid som gjøres manuelt må avstemmes inn i systemene etterpå, og en etterslep som ryddes i feil rekkefølge kan forårsake en ny forstyrrelse.
Trenger du begge deler, eller kan ett dokument dekke det?
Små organisasjoner har ofte ett enkelt dokument, og for en virkelig liten operasjon kan det fungere. Testen er ikke størrelse, men om de to målgruppene hver kan finne det de trenger under press. En ingeniør som gjenoppretter en database klokken tre om morgenen, bør ikke lese om kundekommunikasjon, og en driftsleder som starter en manuell prosess, bør ikke bla gjennom failover-kommandoer. Hva selve kontinuitetsdokumentet skal inneholde, og hvor hver seksjon får innholdet sitt, er angitt i forretningskontinuitetsplanen.
Hold dem separate når en av målgruppene trenger mer enn en side eller to, og hold dem kryssreferert. Det som aldri må dupliseres er tallene. Hvis gjenopprettingstidsrammen vises i begge dokumentene og de ikke stemmer overens, vil planene motsi hverandre akkurat når det betyr mest. Sett målene én gang, i konsekvensanalysen, og referer til dem alle andre steder. Detaljene i det tekniske dokumentet dekkes under katastrofegjenopprettingsplan , og scenarionivået under begge står i beredskapsplanene dine.
Hvis din interesse her er rammeverksspesifikk, dekkes sammenligningen med en SOC 2-revisjon separat i hva SOC 2 krever av kontinuitet og gjenoppretting.
Hvilke standarder dekker hver enkelt?
Splittelsen vises i selve standardene, noe som er en nyttig fornuftssjekk av omfanget. ISO 22301 spesifiserer et styringssystem for forretningskontinuitet: det er sertifiserbart og handler om organisasjonens kapasitet. ISO/IEC 27031 dekker beredskap for informasjons- og kommunikasjonsteknologi for forretningskontinuitet, som er gjenopprettingslaget. ISO 27001 forbinder dem gjennom vedlegg A, hvor kontroll 5.29 omhandler informasjonssikkerhet under avbrudd og kontroll 5.30 omhandler IKT-beredskap.
Å jobbe etter disse standardene slår ikke sammen de to disiplinene, men det tvinger frem grensesnittet. Et styringssystem må vise at den tekniske beredskapen tjener forretningsprioriteringene, og det er nettopp den fugen som svikter når ingen blir bedt om å demonstrere den.
ISO 27001 gjort enkelt
Et forsprang på 81 % fra dag én
Vi har gjort det harde arbeidet for deg, og gir deg 81 % forsprang fra det øyeblikket du logger på. Alt du trenger å gjøre er å fylle ut de tomme feltene.
Hvordan passer paret inn i forretningsrobusthet?
Kontinuitet og gjenoppretting svarer begge på det samme spørsmålet: hva skjer når noe går i stykker. Motstandskraft svarer på et bredere spørsmål. Det er evnen til å absorbere endringer av alle slag, inkludert forstyrrelser du aldri skrev en plan for og forpliktelser som ikke eksisterte da du skrev dem. Begge planene er komponenter av den snarere enn erstatninger for den.
Resilience Loop kjører informasjonssikkerhet i henhold til ISO 27001 , databeskyttelse i henhold til ISO 27701 og AI-styring i henhold til ISO 42001 som ett sammenkoblet system. Kontinuitet og gjenoppretting ligger over de samme kontrollene som en ekstra linse. Det er viktig i bunn og grunn: tilgangsstyringen, sikkerhetskopieringen og leverandørkontrollene som en gjenopprettings-runbook er avhengig av, er de samme som kontinuitetsløsningen er avhengig av, så å vedlikeholde dem tjener begge. Hvordan hele settet passer sammen er beskrevet i rammeverket for forretningsrobusthet.
Det forklarer også hvorfor et driftsavbrudd kan bli en personvernsak i løpet av timer. Å gjenopprette et system fra en eldre sikkerhetskopi kan gjenopprette data en person ba deg om å slette, og en løsning som flytter kundeposter til et regneark skaper en behandlingsrute som ingen har vurdert. Å behandle gjenoppretting som rent teknisk er hvordan disse konsekvensene blir oversett.
Hvordan beviser du at begge deler fungerer?
Ingen tester om du eier to dokumenter. Kunder, revisorer og regulerte kunder stiller et vanskeligere spørsmål: vis meg at begge fungerer, at de stemmer overens, og at de gjenspeiler hvordan du opererer nå.
Det betyr de nåværende målene med bevis på hvem som godkjente dem, en gjenopprettingstest med resultater i stedet for en planlagt dato, en forretningsøvelse med navngitte deltakere, funnene fra begge og de korrigerende tiltakene som er avsluttet. Den felles øvelsen er den som oftest mangler, og det er det eneste beviset som i det hele tatt taler for overleveringen. Tilnærmingen er beskrevet i hvordan man dokumenterer motstandskraft , og motstandskraftspoengsummen gir deg et grunnlag.
Hvorfor velge ISMS.online for kontinuitet og gjenoppretting?
Skjærepunktet mellom disse to planene er like mye et problem med registrering som et problem med planlegging. ISMS.online sørger for at begge sider jobber fra samme kilde.
- Ett sett med målGjenopprettingstidsrammene ligger på ett sted og forsyner begge planene, slik at de ikke kan glide fra hverandre.
- Planer knyttet til kontrollene de er avhengige avSikkerhetskopierings-, tilgangs- og leverandørkontrollene bak hver plan er synlige, så et hull i den ene vises i den andre.
- Innebygde treningsloggerPlanlegg tekniske gjenopprettingstester og forretningsøvelser sammen, registrer funn og spor tiltak i samme system.
- Ett kontrollsett, hvert rammeverk: kartlegg én gang og bruk på nytt på tvers av ISO 22301, ISO 27001, ISO 27701 og ISO 42001 i stedet for å opprettholde parallelle sett.
- Bevis på forespørsel: vis en gjeldende plan med testhistorikk, ikke et dokument og en forsikring.
- Eierskap som holdernavngitte eiere, stedfortredere og gjennomgangsdatoer på begge sider av overleveringen.
- Bygget for britiske og regulerte markeder: utviklet for organisasjoner som må bevise motstandskraft for å vinne og beholde kontrakter.
Se hvordan det passer sammen på plattformen for forretningsrobusthet , eller bestill en demonstrasjon.
Spørsmål og svar
Er katastrofegjenoppretting en del av forretningskontinuitet.
Ja, i den forstand at gjenoppretting tjener målene som er satt for kontinuitet. Forretningskontinuitet er den bredere disiplinen som dekker alle kritiske aktiviteter og alle årsaker til forstyrrelser, inkludert de uten teknisk element. Katastrofegjenoppretting er teknologikomponenten i den. Gjenoppretting arver sine mål fra kontinuitet i stedet for å sette sine egne, og det er derfor en gjenopprettingsplan skrevet uten en forretningskonsekvensanalyse har en tendens til å beskytte feil systemer først.
Kan vi ha en katastrofegjenopprettingsplan uten en plan for forretningskontinuitet?
Du kan, og det gjør mange organisasjoner, men da gjetter du på dine egne prioriteringer. Uten en avtalt oppfatning av hvilke aktiviteter som er viktige og hvor lenge hver enkelt kan avbrytes, settes gjenopprettingsordren av teknisk bekvemmelighet. Den gir heller ingen løsning for forstyrrelser som ikke er tekniske, som å miste et anlegg, en nøkkelleverandør eller personene som driver en kritisk prosess.
Hvem bør eie hver plan?
Kontinuitet hører hjemme i virksomheten, vanligvis drift eller risiko, med en leder som kan forplikte seg til prioriteringer. Gjenoppretting hører hjemme i IT eller infrastruktur. Den viktigste delen er ikke rapporteringslinjen, men grensesnittet: én navngitt myndighet til å påberope seg og trekke seg, ett felles sett med gjenopprettingsmål og en felles øvelse der begge sider er til stede.
Bruker de to planene samme RTO?
De bør bruke de samme tallene, hentet fra én kilde. Målet for gjenopprettingstid for en aktivitet er satt i forretningskonsekvensanalysen, og den tekniske planen er utformet for å oppfylle det, med tanke på at et system som er tilbake ikke er det samme som aktiviteten som skal leveres. Hvis de to dokumentene har sin egen versjon av tallet, vil de til slutt være uenige, og uenigheten vil dukke opp under en hendelse.
Hvor ofte bør vi trene dem sammen?
Minst årlig, og etter enhver endring som påvirker overleveringen: et nytt kritisk system, en annen hostingordning, en omorganisering som flytter eierskap, eller en reell hendelse. Separate tekniske gjenopprettingstester kan kjøres oftere og bør. Fellesøvelsen er den som tester grensesnittet, så et program med hyppige tekniske tester og ingen fellesøvelse lar det mest sannsynlige feilpunktet være uutforsket.
