Jeres backup er ikke en plan. Jeres gendannelse er.

Spørger man en ledelse, om virksomheden har backup, svarer de fleste umiddelbart ja. Spørger man, hvornår organisationen sidst har gendannet noget fra den — en hel server, et helt system, ikke bare en enkelt fil — bliver der ofte stille.

Det er en vigtig stilhed. For en backup, der aldrig er testet som gendannelse, er ikke en plan. Det er et håb.

Forestil jer en mandag morgen: Ingen kan logge ind. Økonomisystemet, kundeservicen og de fælles drev er væk. Backup-dashboardet var grønt fredag — men ingen ved, i hvilken rækkefølge identiteter, databaser og integrationer skal op. Og ledelsens første spørgsmål handler slet ikke om backup. Det lyder: Hvornår kan vi fakturere, levere og kommunikere igen?

Det spørgsmål kan backupsoftwaren ikke besvare. Det kan kun en gendannelsesplan, der er afprøvet.

Hvorfor en backup ikke er en plan

En backup besvarer spørgsmålet “har vi en kopi?”. En gendannelsesplan besvarer det spørgsmål, forretningen faktisk stiller den dag, det brænder: “hvornår kører vi igen — og hvad har vi mistet?”

Mellem de to spørgsmål ligger alt det, der i praksis afgør udfaldet: Er kopien komplet, eller mangler de systemer, ingen huskede at melde til? Kan den læses, eller fejler den midtvejs? Ved nogen, i hvilken rækkefølge systemerne skal op — og virker vejledningen også, når den kollega, der skrev den, er på ferie? Og det mest oversete: Hvor lang tid tager det reelt at gendanne alt? En fuld genetablering kan tage dage eller uger, selv om enkelte systemer kan rejses på timer — og den forskel opdages helst ikke først i krisen.

Hvad historien lærer os

To offentligt dokumenterede sager sætter tal på forskellen mellem kopi og plan.

Da NotPetya ramte Mærsk i juni 2017, måtte rederiet efter egne oplysninger geninstallere omkring 4.000 servere, 45.000 pc’er og 2.500 applikationer over cirka ti døgn, og virksomheden opgjorde selv den økonomiske påvirkning til 250-300 millioner dollar. Den mest lærerige detalje stammer fra de journalistiske rekonstruktioner af forløbet: Den eneste intakte kopi af virksomhedens Active Directory skulle have overlevet på én domænecontroller i Ghana, der var koblet af nettet af en strømafbrydelse, da angrebet ramte. Uanset detaljerne står læren tilbage: En genetablering, der afhænger af et heldigt tilfælde, er ikke en strategi.

Og det rammer også herhjemme: Hos høreapparatkoncernen Demant medførte ransomware-angrebet i september 2019 omfattende driftsforstyrrelser i produktion, distribution og klinikker. Virksomheden opgjorde senere den negative effekt på driftsresultatet til omkring 550 millioner kroner efter forsikringsdækning. Demant gendannede sine systemer fra backup. Regningen løb alligevel op, mens systemer og processer blev genetableret — og det er netop pointen: Selv med fungerende backup afgøres skadens størrelse af, hvor hurtigt forretningen kan komme tilbage.

Store virksomheder leverer de synlige tal — men problemet skrumper ikke med organisationen. I en mindre virksomhed er det ofte den samme person, der har ansvaret for backup, identiteter og dokumentation, kritisk viden ligger hos én leverandør, og den økonomiske udholdenhed er kortere. Der er færre systemer at gendanne — og færre hænder og mindre redundans at gøre det med.

Målrettet ransomware går ofte efter jeres backup først

For ti år siden var backup det pålidelige svar på ransomware: Slet det krypterede, gendan kopien, kom videre. Det ved angriberne godt. Ved mange målrettede angreb skaffes adgangen derfor først, hvorefter aktøren kan opholde sig ubemærket i miljøet, mens systemer, rettigheder og backupinfrastruktur kortlægges. Målet er ofte, at kopierne kan slettes eller krypteres samtidig med produktionen, inden angrebet udløses.

Det stiller ét spørgsmål over alle andre: Kan den, der ejer jeres netværk, også nå jeres backup? Administreres backupløsningen med de samme privilegerede konti som resten af miljøet — typisk via Active Directory — er risikoen væsentligt større for, at kopierne tabes sammen med produktionen. Derfor peger vejledningerne fra myndigheder som CISA og ENISA samme sted hen: kopier, der ikke kan ændres eller slettes (immutabilitet), mindst én kopi offline eller logisk afkoblet fra domænet, backup-adgang med egne, adskilte legitimationsoplysninger — og regelmæssig test. Tommelfingerreglen 3-2-1 — tre kopier, to medietyper, én placeret et andet sted — er stadig et godt udgangspunkt; i en ransomware-tid skal “én af dem uden for angriberens rækkevidde” læses som kravet, ikke som ekstraudstyr.

Og står I lige nu med krypterede systemer, er denne artikel ikke stedet at starte — det er beredskabssiden. Resten her handler om at undgå at få brug for den.

“Jamen, vi er jo i skyen”

Microsoft 365 er ikke uden sikkerhedsnet: Platformen har indbygget redundans, versionering og opbevaringspolitikker, og Microsoft tilbyder i dag også et egentligt backupprodukt, Microsoft 365 Backup. Men ansvarsfordelingen er uændret: Microsoft driver platformen — ansvaret for jeres data, jeres identiteter og jeres krav til gendannelse er jeres. Funktionerne bliver ikke af sig selv til en gendannelsesstrategi: Nogen skal definere kravene, slå beskyttelsen til og afprøve, om data, identiteter og kritiske arbejdsgange faktisk kan genetableres inden for de tidsrammer, forretningen forudsætter.

Papirkurve, versionering og retention er værdifulde, når en enkelt fil eller postkasse skal reddes. Men de dokumenterer ikke, at hele det kritiske miljø kan genetableres efter et omfattende angreb eller en alvorlig fejlkonfiguration. Det gælder også identitetslaget: brugere, grupper, Conditional Access-regler og applikationsregistreringer skal kunne genskabes. Kan I i dag svare på, hvordan I ville rejse jeres Entra ID-konfiguration igen, hvis den blev saboteret? Microsofts egen vejledning i genoprettelse af Entra ID er et godt sted at starte — for det spørgsmål bør kunne besvares, før en hændelse gør svaret nødvendigt. Microsoft har gjort det lidt lettere at svare: Microsoft Entra Backup and Recovery tager automatisk en daglig sikkerhedskopi af udvalgte objekter — brugere, grupper, applikationer, service principals og Conditional Access-politikker — med op til syv dages historik, og ingen administrator kan slå den fra. Men dækningen er ikke fuldstændig, funktionen kræver Entra ID P1 eller P2, og hard-deletede objekter kan ikke genskabes. Dokumentationen af den kendte, gode konfiguration og en afprøvet genoprettelsesproces er altså stadig jeres eget ansvar. Om beskyttelsen reelt er slået til, og om opsætningen matcher de krav, forretningen tror, den har stillet, er i øvrigt netop den slags, en sikkerhedsanalyse af Microsoft 365 afdækker.

De to tal, ledelsen skal beslutte

Bag al teknikken ligger to spørgsmål, som ingen IT-afdeling kan — eller bør — besvare alene:

Hvor meget må vi miste? En dags data? En time? Det tal (fagsproget kalder det RPO) angiver det maksimalt acceptable datatab målt i tid — altså hvor langt tilbage det seneste brugbare gendannelsespunkt må ligge. Det styrer blandt andet kravene til backupfrekvens, snapshots og replikering.

Hvor længe må vi ligge nede? En uge? Et døgn? Det tal (RTO) angiver den maksimalt acceptable tid, før de kritiske funktioner igen skal virke — og afgør både, hvad beredskabet skal kunne, og hvad det må koste.

Et regneeksempel gør forskellen konkret: Et ordresystem har fået ledelsens ord for højst én times datatab og højst fire timers nedetid — RPO én time, RTO fire timer. Ved testen gendanner IT data til 25 minutter før nedbruddet: RPO’en er opfyldt. Men der går seks timer, før database, identiteter, integrationer og brugeradgang er på plads igen. Backuppen virkede — beredskabet gjorde ikke. Det er hele forskellen mellem en fungerende kopi og en fungerende plan.

Det er forretningsbeslutninger om risiko og penge, forklædt som tekniske indstillinger. Alt for ofte er de aldrig truffet bevidst: IT har valgt en standardindstilling, og ledelsen har antaget et serviceniveau, ingen har lovet.

Er organisationen omfattet af NIS2, er det heller ikke længere valgfrit: Den danske NIS 2-lovs § 6 kræver passende og forholdsmæssige foranstaltninger, der udtrykkeligt omfatter driftskontinuitet — herunder backupstyring, reetablering efter en katastrofe og krisestyring — samt politikker og procedurer til at vurdere, om foranstaltningerne faktisk virker. Loven implementerer direktivets artikel 21, og dens § 7 placerer ansvaret samme sted som denne artikel: Foranstaltningerne skal godkendes af ledelsesorganet, der fører tilsyn med gennemførelsen.

Hvad et tilsyn konkret efterspørger, afhænger af organisationstype, sektorregler og tilsynspraksis — men uanset tilsynet bør testens omfang og frekvens fastlægges ud fra risiko og dokumenteres. Og mangler der én til at holde netop dén oversættelse fra krav til beslutning ved lige, er det i praksis den rolle, en fast sikkerhedsrådgiver udfylder.

Hvordan tester man, at man kan gendanne?

Test af gendannelse er en stige med fire trin — og hvert trin giver svar, det forrige ikke kan:

Læren i tabellen er ubehagelig, men vigtig: Man kan gennemføre en vellykket gendannelsestest og stadig have et utilstrækkeligt beredskab. Trin 1 er et naturligt sted at begynde — men det kan ikke give de svar, man kun får på trin 3 og 4. Og det er netop dér, planen testes og ikke kun teknikken: Hvem beslutter hvad? Hvem kommunikerer med kunder og myndigheder? Og holder rækkefølgen også, når backup-serveren skal gendannes før det Active Directory, den plejede at logge ind i?

En gennemført øvelse afdækker de antagelser, der først brister i mødet med virkeligheden — men kun, hvis der måles undervejs. En god test afleverer som minimum seks svar:

1. Hvilket gendannelsespunkt kunne vi faktisk nå?
2. Hvor lang tid gik der, før den kritiske funktion virkede?
3. Hvilke systemer, identiteter og integrationer var den afhængig af?
4. Hvilke konti, nøgler, licenser og leverandører skulle bruges undervejs?
5. Hvilke manuelle trin fandtes kun i hovedet på enkelte medarbejdere?
6. Hvem ejer hver konstateret mangel — og hvornår skal den være lukket?

En test er først afsluttet, når forretningen har bekræftet, at funktionen virker — ikke når IT kan starte serveren.

Fem spørgsmål til jeres næste ledelsesmøde

1. Hvornår har vi sidst gendannet et helt system — og hvor lang tid tog det?
2. Kan en angriber med fuld kontrol over vores netværk også slette vores backup?
3. Har ledelsen besluttet, hvor meget data vi må miste, og hvor længe vi må ligge nede — eller er det antagelser?
4. Dækker vores gendannelsesberedskab også Microsoft 365 — inklusive identiteter og kritisk konfiguration, ikke kun filer?
5. Findes vores gendannelsesplan på skrift et sted, der er tilgængeligt, når alt andet er nede?

Kan I svare klart på alle fem, hviler jeres beredskab på viden frem for antagelser. Kan I ikke, er det ikke et nederlag — det er et fund. Og fund, der gøres ved et mødebord, er de billigste, man nogensinde kommer til at håndtere.

Begynd med ét system

Begynd ikke med hele virksomheden. Vælg ét kritisk system. Aftal, hvor meget data I må miste, og hvor længe funktionen må være nede. Gendan det så i et isoleret miljø, tag tid på det — og lad forretningen bekræfte, at det virker.

Tager det længere tid end aftalt, har backuppen ikke fejlet. Den har gjort noget vigtigere: Den har vist forskellen mellem det beredskab, I troede, I havde — og det beredskab, I faktisk har.