De flesta team skriver en kontinuitetsplan en gång, oftast för att en kund eller revisor bad om det. Den hamnar på en delad enhet, får ett versionsnummer och blir liggande. Sedan går en leverantör ner eller ett hus blir strömlöst, och det visar sig att planen beskriver ett företag som inte längre finns: fel personer, fel system, fel telefonnummer.

En plan du aldrig testar är ingen plan. Det är ett dokument. Verklig kontinuitet kommer av att veta vad som är viktigt, bestämma i förväg hur du håller det igång och öva på det beslutet tills teamet kan fatta det under press. Den här guiden går igenom skillnaden mellan kontinuitet och återställning, hur du bygger båda på en konsekvensanalys, och varför testandet är det som faktiskt räknas.

Kontinuitet och katastrofåterställning är inte samma sak

Folk använder begreppen som synonymer, men de svarar på olika frågor.

Kontinuitet handlar om att hålla hela verksamheten igång när något går fel. Det omfattar människor, processer, lokaler, leverantörer och kommunikation. Om kontoret inte går att nå, hur fortsätter personalen att betjäna kunderna? Om en nyckelleverantör fallerar, vad är reservlösningen? En kontinuitetsplan svarar på de frågorna.

Katastrofåterställning är smalare. Den handlar om att återställa de tekniska tjänster verksamheten är beroende av efter ett avbrott: systemen, plattformarna, uppkopplingen. En plan för katastrofåterställning svarar på hur du får tillbaka de tjänsterna och hur snabbt.

Återställningen ligger inuti kontinuiteten, inte bredvid den. Du kan inte hålla verksamheten igång om tjänsterna den vilar på är nere, och att återställa tjänster är meningslöst om ingen först definierat vad verksamheten behöver. Betrakta katastrofåterställning som en strategi inom ditt bredare kontinuitetsprogram, inte som en egen pärm.

Allt börjar med en konsekvensanalys

Du kan inte skydda allt lika mycket, och försöket är just hur kontinuitetsplaner blir 90-sidiga dokument som ingen läser. En konsekvensanalys för verksamheten (BIA) talar om var du ska lägga fokus.

En BIA går igenom varje verksamhetsprocess och frågar vad som händer om den stannar. Vilka processer är kritiska? Vad är de beroende av? Hur länge kan var och en ligga nere innan skadan blir allvarlig? Den sista frågan ger dig två tal som styr hela planen:

• Återställningstid (RTO): hur snabbt en process eller tjänst behöver vara tillbaka.
• Återställningspunkt (RPO): hur mycket av det senaste arbetet du har råd att förlora.

En lönekörning kan tåla ett dygns avbrott. En kundnära tjänst kanske bara tål minuter. BIA:n gör de avvägningarna tydliga i stället för att lämna dem till den som skriker högst under incidenten. Varje återställningsstrategi, budgetbeslut och testscenario bör kunna spåras tillbaka till den.

Definiera återställningsstrategier som matchar prioriteringarna

När BIA:n väl talat om vad som är viktigt och hur snabbt det behöver komma tillbaka utformar du strategier för att nå de målen. En strategi är inte en förhoppning. Det är ett konkret svar på "när X fallerar gör vi Y."

Strategierna varierar mellan processer. Vissa behöver en reservkapacitet redo att ta över. Vissa behöver en manuell reservlösning som teamet kan köra ett dygn eller två. Vissa behöver en alternativ leverantör redan avtalad så att du slipper förhandla mitt i en kris. Rätt val beror på den återställningstid och återställningspunkt som BIA:n satt, vägt mot vad strategin kostar att upprätthålla.

Skriv ner varje strategi så utförligt att någon som inte utformat den skulle kunna följa den. Personen som kan reservlösningen är ofta den som är på semester när du behöver den.

Roller och en kommunikationsplan

En incident är ett dåligt tillfälle att lista ut vem som bestämmer. Kontinuitetsplaner fördelar roller i förväg: vem som har befogenhet att utropa en incident, vem som leder insatsen, vem som äger varje återställningsuppgift och vem som kliver in om den första personen inte går att nå.

Kommunikationen förtjänar en egen plan. Under en störning kan du behöva nå personal, kunder, leverantörer och, i reglerade sektorer, tillsynsmyndigheter, ofta med korta frister. Bestäm i förväg vad du ska säga, vem som godkänner det och hur du skickar det om dina vanliga kanaler är just det som ligger nere. Ett förskrivet första meddelande slår ett tomt ark klockan två på natten.

Håll kontaktuppgifterna aktuella. Föråldrade telefonnummer är det enskilt vanligaste skälet till att en välskriven plan faller i praktiken.

Testet är planen

Här är delen de flesta team hoppar över, och det är den som betyder mest. En otestad plan är en hypotes. Testandet gör den till en förmåga.

Det finns två nivåer värda att köra:

En skrivbordsövning samlar insatsteamet kring ett scenario och går igenom det högt. Ingen rör ett skarpt system. Du beskriver en störning, och teamet förklarar vad de skulle göra, steg för steg. Skrivbordsövningar är billiga, riskfria och lysande på att blottlägga luckor: den saknade ägaren, beroendet ingen kartlagt, antagandet som visar sig vara fel.

En fullskalig övning, ibland kallad funktionell eller skarp test, aktiverar faktiskt återställningsstrategin. Du växlar över till reservlösningen, kör den manuella rutinen på riktigt eller simulerar avbrottet från början till slut. Den är mer störande och mer avslöjande, för den visar om din återställningstid är realistisk eller en from förhoppning.

Båda formerna ger samma värdefulla resultat: lärdomar. Varje lucka du hittar i ett test är en lucka du slapp hitta under en verklig incident. Mata tillbaka fynden in i planen, åtgärda de svaga punkterna och testa igen. Kontinuitet är en slinga, inte en milstolpe.

Vad revisorer och DORA förväntar sig

Kontinuitet är inte bara god sed, det är ett krav i de ramverk du sannolikt mäts mot.

• ISO 27001 förväntar sig informationssäkerhetskontinuitet och IKT-beredskap (kontrollerna A.5.29 och A.5.30), och systerstandarden ISO 22301 ägnas helt åt ledningssystem för kontinuitet.
• SOC 2 täcker återställning och testning under tillgänglighetskriteriet, och revisorer frågar efter bevis på att du faktiskt kört testerna.
• DORA, EU:s förordning om digital operativ motståndskraft, går längst. För finansiella entiteter kräver den planer för respons och återställning som testas regelbundet, plus ett formellt program för testning av digital motståndskraft med scenariobaserade övningar. DORA nöjer sig inte med en plan på papper. Den vill ha bevis på att du testat den och agerat på resultatet.

Den gemensamma nämnaren är bevis. Inget av dessa ramverk tar dig på orden. De vill se planen, testprotokollen, fynden och uppföljningen. Kan du inte visa dem på begäran har du ingen kontinuitet du kan bevisa, vad dokumentet än säger.

Så håller OptiTech kontinuiteten sammankopplad

Det är här ett splittrat upplägg faller isär. Planen ligger på ett ställe, tillgångslistan på ett annat, testanteckningarna i någons inkorg, och när revisionen kommer stämmer inget överens.

OptiTech håller ihop det. Du kopplar varje kontinuitetsplan till de kritiska tillgångar den skyddar, så att planen speglar det du faktiskt driver, och en ändring i din tillgångsförteckning flaggar de planer som behöver ses över. När du kör en skrivbordsövning eller fullskalig övning registrerar du den som bevis mot de relevanta kontrollerna, med datum, scenario, deltagare och lärdomar bifogade. De kontroller som kräver kontinuitetstestning förblir uppfyllda eftersom beviset finns där, inte hoprafsat veckan före en revision.

Och eftersom allt är ett program kan ditt trust center visa kunder att du tar motståndskraft på allvar utan att blotta känsliga detaljer. En säkerhetsgranskare ser att dina kontinuitetsplaner testas och är aktuella. Beviset bakom det påståendet stannar i OptiTech Console där det hör hemma.

Kom igång

Du behöver ingen perfekt plan dag ett. Du behöver en verklig plan som du fortsätter öva på.

1. Kör en konsekvensanalys på dina viktigaste processer och sätt en återställningstid och återställningspunkt för var och en.
2. Skriv återställningsstrategier som når de målen, så utförligt att någon annan kan följa dem.
3. Fördela roller och en kommunikationsplan, med namngivna ägare och aktuella kontaktuppgifter.
4. Boka din första skrivbordsövning, och sedan en fullskalig övning för din mest kritiska process.
5. Registrera varje test som bevis och koppla dina planer till tillgångarna de skyddar.

En kontinuitetsplan gör verklig nytta den dag något går fel. Arbetet du gör nu, och testerna du kör innan du behöver dem, är det som gör ett dokument till en plan verksamheten kan lita på.

Redo att koppla ihop dina kontinuitetsplaner, kritiska tillgångar och testprotokoll på ett ställe? Boka en demo och se hur OptiTech gör motståndskraft till bevis du kan visa.