Säkerhetskopiering är kontrollen alla tror att de redan bockat av. Du slår på automatiska kopior, ser de gröna bockarna och går vidare. Det känns klart. Sedan går något fel, du sträcker dig efter en återställning, och upptäcker att kopiorna var ofullständiga, tyst korrupta eller omöjliga att få tillbaka inom en tid som din verksamhet klarar av.

En säkerhetskopia du aldrig återställt är en förhoppning, inte en kontroll. Det vet revisorer, och därför ställer varje seriöst ramverk numera samma två frågor: kan du återställa, och kan du bevisa att du testat det? Den här texten går igenom varför säkerhetskopior i sig inte räcker för efterlevnad, hur du sätter en policy som håller vid granskning, och hur OptiTech spårar kontrollen och dina bevis från återställningstester på ett ställe.

Varför säkerhetskopior i sig inte räcker

En säkerhetskopia är ett medel, och målet är återställning. Kopior som finns men aldrig kommer tillbaka rent ger dig en falsk trygghet som är värre än att veta att du har en lucka.

Felen är tysta och vanliga. Kopieringsjobb glider utanför sitt omfång när ett nytt system läggs till och ingen uppdaterar schemat. Filer blir korrupta utan att någon larmas. Gallringen raderar just den kopia du behövde. Krypteringsnycklar eller konfiguration ligger någonstans som kopieringen aldrig fångade, så datan återställs men tjänsten startar ändå inte. Och utpressningsprogram riktar sig allt oftare mot själva säkerhetskopiorna och krypterar ditt skyddsnät tillsammans med produktionsdatan.

Därför belönar ramverken inte att kopior finns. ISO 27001 behandlar säkerhetskopiering som en kontroll kopplad till tillgänglighet. SOC 2 lägger återställning under sina tillgänglighetskriterier. NIS2 förväntar sig en kontinuitet du kan driva i praktiken, och DORA kräver påvisbar motståndskraft i it-driften för finansiella aktörer. Ingen av dem godtar "vi har säkerhetskopior" som svar. De ber dig visa att du kan återställa, enligt ett schema, med bevis.

3-2-1-principen som policy

3-2-1-regeln är en användbar tumregel på policynivå, och du behöver inte gå in i teknisk implementation för att styra den. Behåll minst tre kopior av viktig data, på två olika typer av lagring eller platser, med en kopia förvarad på annan plats eller på annat sätt isolerad från din primära miljö.

Formulerat som policy blir det till några tydliga åtaganden. Du utser en ägare för säkerhetskopieringskontrollen. Du anger var kopiorna finns, och för ett nordiskt bolag som hanterar EU-data håller du dem inom din datalagringsgräns, så att kopiorna stannar i Stockholm och Frankfurt i stället för att glida till en annan region av bara farten. Du kräver minst en isolerad eller oföränderlig kopia, eftersom en säkerhetskopia som utpressningsprogram kan nå inte är någon säkerhetskopia. Och du sätter en översynstakt så att policyn följer verkligheten när dina system förändras.

Poängen är inte siffran tre. Poängen är att din policy svarar på frågorna en granskare kommer att ställa: hur många kopior, var, hur isolerade, och vem som äger det.

Sätt återställningsmål innan en incident

Du kan inte bedöma ett kopieringsschema utan att veta vilken återställning du faktiskt behöver. Det är vad återställningsmål är till för, och de är verksamhetsbeslut, inte tekniska.

Ditt återställningsmål för data, RPO, är hur mycket data du har råd att förlora, mätt i tid. Ett RPO på en timme betyder att du accepterar att förlora högst en timmes data. Ditt återställningsmål för tid, RTO, är hur länge du kan ligga nere innan påverkan blir oacceptabel. Båda kommer från verksamheten, inte från vad dina verktyg råkar göra.

Målen gör kontrollen mätbar. "Vi säkerhetskopierar var 24:e timme" betyder ingenting förrän du jämför det mot ett RPO. Om verksamheten bara tål en timmes dataförlust är en daglig kopiering ett policymisslyckande som gömmer sig bakom en grön bock. Olika tjänster bär oftast olika mål, så sätt dem per tjänst och låt de kritiska styra var du lägger dina resurser.

Delen alla hoppar över: testade återställningar

Här är steget som skiljer en riktig kontroll från en kryssruta. Du måste återställa, med avsikt, innan du tvingas till det.

Ett återställningstest är enkelt att beskriva. Du återställer en säkerhetskopia till en isolerad miljö, verifierar att datan är komplett och användbar, och mäter hur lång tid det tog mot ditt RTO. Du gör det med en bestämd takt, kvartalsvis för kritiska system är en vanlig utgångspunkt, och efter varje större förändring i systemen som skyddas. Sedan skriver du ner vad som hände.

Bevisen är hela poängen. Ett återställningstest som inte lämnar något spår kan lika gärna aldrig ha ägt rum. Fånga vem som körde det, datumet, vad som återställdes, hur lång tid det tog, om det klarade dina mål och alla problem du hittade på vägen. Om testet misslyckades eller drog över tiden är det inget skäl att dölja det. Ett dokumenterat misslyckande följt av en åtgärd är precis den mognad revisorer vill se.

Vad revisorer faktiskt vill se

En revisor letar inte efter en skärmdump av en kopieringspanel tagen dagen före granskningen. De letar efter en kedja som håller ihop över tid.

Den kedjan lyder ungefär så här: en skriven säkerhetskopieringspolicy finns, en ägare är utsedd, schemat följer policyn, återställningstester sker med angiven takt, varje test har daterade bevis med ett tydligt utfall, och alla luckor har följts till avslut. Datumen betyder lika mycket som dokumenten. Konsekventa, tidsstämplade bevis genom hela granskningsperioden berättar en betydligt bättre historia än en aktivitetsstorm precis före deadline.

Styrning är skillnaden mellan att klara det en gång och att förbli efterlevande. När kontrollen lever i ett system som påminner dig när nästa test ska ske, behöver du inte förlita dig på att någon kommer ihåg.

Så spårar OptiTech säkerhetskopieringskontrollen

I OptiTech Console är säkerhetskopiering och återställning en enda kontroll som mappas mot varje ramverk du driver. Du definierar den en gång, och den uppfyller de relevanta kraven i SOC 2 Type II, ISO 27001, NIS2 och DORA samtidigt, i stället för att du underhåller fyra separata versioner av samma bevis.

Varje återställningstest du kör kopplas till kontrollen som bevis, med datum, ägare, utfall och eventuella fynd noterade på plats. OptiTech håller koll på takten och flaggar kontrollen när det senaste testet börjar bli inaktuellt, så att ett förfallet återställningstest dyker upp innan din revisor upptäcker att det saknas. När en lucka uppstår loggar du åtgärden mot samma kontroll, och hela historiken förblir intakt.

Samma underlag matar ditt trust center. I stället för att svara på "hur hanterar ni säkerhetskopiering och återställning?" för hand i varje säkerhetsgranskning hänvisar du köpare till en aktuell, bevisbackad ställning de kan läsa själva.

Kom igång

Du kan sätta upp det här i en fokuserad första omgång:

1. Skriv säkerhetskopieringspolicyn. Fånga 3-2-1 på policynivå och knyt kopiorna till din EU-datalagring i Stockholm och Frankfurt.
2. Sätt RPO och RTO per tjänst. Låt verksamheten definiera acceptabel dataförlust och nedtid, och prioritera de kritiska tjänsterna.
3. Schemalägg återställningstester och utse ägare. Kvartalsvis för kritiska system, plus efter större förändringar.
4. Fånga bevis varje gång. Notera vem, när, vad, hur länge, utfallet och eventuell åtgärd i OptiTech.
5. Mappa kontrollen och publicera den. Koppla en säkerhetskopieringskontroll över dina ramverk och visa ställningen i ditt trust center.

Säkerhetskopiering känns färdig i samma stund som du slår på den, men efterlevnaden börjar vid återställningen. Bevisa återställning enligt ett schema, håll bevisen daterade, så svarar samma arbete både dina revisorer och dina köpare på en gång.

Redo att göra säkerhetskopiering till en kontroll du kan bevisa? Boka en demo och se hur OptiTech spårar din säkerhetskopieringskontroll och dina bevis från återställningstester på ett ställe.