I kan undvære et system så længe, som forretningen tåler, og det tal skal ledelsen fastsætte. RTO og RPO er de to mål, der gør svaret brugbart. RTO siger, hvor hurtigt systemet skal køre igen, og RPO siger, hvor mange data I må miste. Når tallene står skrevet, kan både gendannelse og exit måles mod samme grænse, og det er den grænse, en exit-plan skal holdes op imod.
De to tal forklaret
RTO står for recovery time objective og er målet for genopretningstid. Hvor lang tid må der gå, fra systemet stopper, til det kører igen? RPO står for recovery point objective og er målet for genopretningspunkt. Hvor langt tilbage må I falde? Tages der kopi hver nat, kan I miste op til et døgns arbejde, og så er jeres RPO i praksis et døgn.
To ord mere dukker op i samme samtale. MAO, maximum acceptable outage, er den længste afbrydelse, forretningen kan overleve, og RTO skal ligge inden for den. SLA er serviceniveauet i aftalen med leverandøren. Et løfte om høj oppetid siger noget om, hvor ofte systemet er nede i et normalt år. Det siger ingenting om, hvor længe I står uden system, når noget går alvorligt galt, så SLA og RTO skal holdes adskilt.
Tallene er en ledelsesbeslutning
IT kan fortælle, hvad en gendannelse tager. Hvor længe forretningen kan vente, kommer fra konsekvensanalysen. Tidsaksen viser, hvornår omvejene holder op med at fungere, og lige før det punkt ligger grænsen.
Spørg ledelsen ét system ad gangen: hvor mange dage må dette system være væk, og hvor mange dages arbejde må vi miste? Svarene behøver ikke at være fine. “To dage og ingen tabte ordrer” er et brugbart krav, og IT kan derefter svare, om det kan lade sig gøre, og hvad det kræver.
SAMSIK stiller samme spørgsmål i sin vejledning til NIS2-loven. Blandt vejledningens eksempelspørgsmål står, hvor lang tid der er acceptabel for gendannelse af driftskritiske systemer (RTO), og hvordan det verificeres, at backups kan gendannes (s. 27). Det er eksempler i en vejledning og ikke lovens ordlyd.
Samme grænse for gendannelse og exit
Her adskiller en exit-plan sig fra et almindeligt beredskab. Når grænsen er sat, skal den bruges tre gange.
- Gendannelsen. Hvor lang tid tog det sidst, I prøvede at gendanne? Målte I det, eller er tallet et gæt?
- Exit under pres. Er systemet væk, fordi en leverandør er lukket, eller en konto er spærret, gælder grænsen også her. Hvor hurtigt kan I arbejde videre et andet sted, og med hvilke data?
- Ordnet exit. Her kører systemet videre, mens I flytter, så grænsen presses mindre. Tiden afhænger af opsigelsesvarsler, data og integrationer, se jeres egen exit-tid.
Forskellen på de to sidste er afgørende. For cloudtjenester skal et ordnet skifte efter Data Act (dataforordningen) kunne indledes med to måneders varsel eller mindre, og selve overgangen må vare op til 30 kalenderdage. Er det teknisk umuligt, kan udbyderen med en begrundelse angive op til syv måneder (art. 25, stk. 2 og 4). De frister hjælper, så længe tjenesten kører. De hjælper ikke den dag, adgangen er væk.
Sæt derfor tallene op side om side for hvert system: tolerance, målt gendannelsestid og beregnet exit-tid under pres. Et system med en tolerance på tre dage og en exit-tid på flere måneder er det, planen skal handle om.
Når tallet ikke kan nås
I har tre muligheder, og alle tre er legitime.
- Forkort tiden. En egen kopi uden for leverandøren er ofte det, der flytter tallet mest, fordi data så findes, uanset hvad der sker hos leverandøren.
- Køb tid. En reserveløsning eller en bedre omvej kan holde forretningen i gang, mens det egentlige arbejde pågår.
- Accepter afstanden. Ledelsen kan beslutte at leve med den. Det skal stå skrevet som en bevidst accept med navn og dato.
For digitale udbydere under NIS2-gennemførelsesforordningen skal backupplaner omfatte genopretningstider, og genopretning skal testes regelmæssigt (bilag, punkt 4.2.2 og 4.2.6). Almindelige virksomheder er uden for kredsen. Kravene viser alligevel en god rækkefølge. Sæt et mål, og kontrollér derefter, om det holder. Hvordan ledelsen skal forstå selve backupdelen, er beskrevet under backup og reetablering.
Hvad det kræver, og hvad det koster at lade være
Selve fastsættelsen tager et møde pr. system, når konsekvensanalysen foreligger. Det større arbejde ligger i at måle, om tallene holder. Lav et dateret overslag over testen med bedste og værste bud i timer.
Mangler tallene, kan ingen afgøre, om backup, reserveløsning og plan er gode nok. Virksomheden kan komme til at betale for en hurtighed, den ikke har brug for, eller opdage for sent, at den faktiske gendannelse tager længere, end forretningen tåler.
Lad ledelsen se tre ting samtidig: hvad det kræver at nå målet, hvad en stoppet dag betyder for bundlinjen, regnet med jeres egne tal, og hvad tallene giver alligevel. De giver et klart krav til leverandører, et svar til kunder og tilsyn og et mål, testene kan bedømmes efter.
Det skal I lade være med
- At overtage leverandørens tal · deres oppetid er ikke jeres tolerance.
- At skrive mål uden at måle · en RTO, der aldrig er prøvet, er et ønske.
- At bruge samme tal for alle systemer · grænsen følger forretningens tab pr. system.
Det skal planen kunne vise
- ☐ RTO og RPO pr. kritisk system, godkendt af ledelsen.
- ☐ Den målte gendannelsestid med dato for testen.
- ☐ Exit-tiden under pres og ved et ordnet skifte.
- ☐ Afstanden mellem tolerance og faktisk tid.
- ☐ Beslutningen om at forkorte, købe tid eller acceptere.
Kilder
- SAMSIK: Vejledning til implementering af cybersikkerhedsforanstaltninger: eksempelspørgsmål, PDF-side 27. Vejledning, ikke lovkrav.
- Forordning (EU) 2023/2854 (Data Act): art. 25 om frister ved skift.
- Gennemførelsesforordning (EU) 2024/2690: bilag, punkt 4.2.2 og 4.2.6, gælder digitale udbydere og bruges her som model.
Senest gennemgået: november 2026.
Næste skridt
Skriv to tal ud for hvert system i den øverste gruppe, og bed IT om den senest målte gendannelsestid. Viser sammenligningen en afstand, skal ledelsen tage stilling til, om den vil lukke den.
Læs også: Backup er ikke en exit-plan · Gendannelse et andet sted
→ Kontakt · Tlf. 70 13 63 23 · Exit-plan og exit-rådgivning hos Nielco IT
