Executive Summary
De fleste SMV’er siger, at de har backup. Færre kan dokumentere, at de faktisk kan gendanne drift, når noget går galt. Det er en vigtig forskel. Ransomware rammer ikke kun produktion og filer, men også selve evnen til at komme tilbage, fordi angribere ofte går efter backupmiljø, administrationskonti og de legitimationsoplysninger, der binder det hele sammen. Både CISA og UK NCSC peger på backup og genopretning som centrale kontroller, men også på, at de skal testes i praksis.
For ledelsen er spørgsmålet derfor ikke, om der tages backup. Spørgsmålet er, om virksomheden kan gendanne de vigtigste systemer inden for de mål, I selv har besluttet for nedetid og datatab. Det er her en defensiv pentest af backup og restore giver mening. Ikke som tung teknisk øvelse, men som en lille, afgrænset test med klare acceptkriterier, beviser og retest. Det ligger også tæt på tankegangen i GDPR artikel 32 og NIS2, hvor sikkerhedsforanstaltninger skal være passende, risikobaserede og kunne fungere i praksis.
Hvis du vil gøre arbejdet konkret, så start med fem forretningskritiske systemer, et mini-scope og tre ja eller nej-kriterier, som ledelsen kan underskrive. På den måde bliver testen et beslutningsværktøj. Ikke bare endnu en rapport til IT-skuffen.
Backup er ikke det samme som gendannelse
Mange virksomheder har et grønt flueben ud for backup, men det siger meget lidt om reel modstandskraft. Et backupjob kan være kørt i nat uden at nogen ved, om data kan læses, om afhængighederne er dokumenteret, eller om restore tager seks timer eller seks dage. Når ransomware rammer, er det netop de forskelle, der afgør, om du mister en arbejdsdag eller en hel uge.
CISA anbefaler blandt andet offline eller isolerede kopier, beskyttelse af backupinfrastruktur og regelmæssige tests af gendannelse. NCSC fremhæver tilsvarende, at organisationer skal kunne genskabe drift hurtigt og sikkert. Samme logik findes i NIST SP 800-34, som beskriver beredskab og genopretning som en planlagt disciplin, ikke som et håb.
For en dansk SMV handler det sjældent om at gendanne alt på én gang. Det handler om at vide, hvad der kommer først. ERP, mail, filserver, lønsystem, produktion, kundesystem eller webshop. Den prioritering bør være ledelsesejet. Hvis du er i tvivl om jeres samlede modenhed og dokumentation omkring krav, roller og beviser, giver det ofte mening at koble testen sammen med en modenhedsanalyse.
Mini-scope: sådan gør du testen ledelsesvenlig
Den største fejl i restore-tests er scope, der bliver for stort. Så ender øvelsen i kalenderkaos, teknikdiskussioner og uklare resultater. En defensiv pentest af backup og restore bør i stedet afgrænses, så den kan gennemføres hurtigt og give et klart svar.
Start med fem systemer eller processer, som virksomheden ikke kan undvære i mere end kort tid. Beslut derefter for hvert system et realistisk RTO, altså hvor lang tid I accepterer nedetid, og et realistisk RPO, altså hvor meget datatab I accepterer. Hvis de tal ikke er besluttet endnu, er testen allerede nyttig, fordi den tvinger ledelsen til at vælge.
Et godt mini-scope for en SMV kan for eksempel være Microsoft 365 eller Google Workspace, økonomisystem, fælles filområde, et kundesystem og én kritisk server eller cloud-applikation. Hvis du vil forstå forskellen på bred kontrol og dybere test, kan du også læse om samspillet mellem sikkerhedstjek og pentest. Her er pointen, at restore-testen ikke skal bevise alt. Den skal bevise nok til at ledelsen kan prioritere de næste beslutninger.
De 8 testtrin, der gør backup til en ja eller nej-test
- 1. Vælg de fem vigtigste systemer. Brug forretningspåvirkning som kriterium. Ikke teknisk interesse.
- 2. Fastlæg RTO og RPO for hvert system. Et mål uden tal kan ikke testes.
- 3. Kortlæg afhængigheder. Notér identitet, netværk, nøgler, licenser, integrationspunkter og admin-adgange, som restore faktisk kræver.
- 4. Verificér backupkæden. Find ud af hvor data ligger, hvem der har adgang, og om backup er isoleret mod almindelige bruger- og adminkonti.
- 5. Gennemfør en kontrolleret restore af udvalgte systemer. Ikke kun filniveau, men så tæt på reel drift som muligt.
- 6. Dokumentér faktisk tid og faktisk datatab. Mål restore mod de RTO- og RPO-mål, I selv satte i starten.
- 7. Test adgangsveje og beredskab. Kan teamet logge ind, få nøgler, kontakte leverandører og aktivere de nødvendige roller uden at være afhængige af kompromitterede konti?
- 8. Lav retest på de røde fund. Ikke seks måneder senere. Så hurtigt som muligt, mens læringen er frisk.
Det afgørende er, at testen følger en tydelig metode. NIST SP 800-115 beskriver planlægning, afgrænsning, udførelse og rapportering som grunddiscipliner i sikkerhedstest. Overført til backup og restore betyder det, at I skal aftale spilleregler, beviser og succeskriterier på forhånd. Det er også kernen i en mere defensiv, purple-team-light tilgang, hvor formålet ikke er at skabe drama, men at dokumentere om kontrollen virker.
Tre acceptkriterier ledelsen kan underskrive
Hvis testen skal skabe værdi uden teknisk støj, skal resultatet kunne reduceres til få, tydelige ja eller nej-beslutninger. Vi anbefaler tre acceptkriterier, som ledelsen kan tage stilling til uden at være backup-specialister.
Det første kriterium er tid: Kan de fem vigtigste systemer gendannes inden for aftalt RTO. Det andet er datatab: Holder gendannelsen sig inden for aftalt RPO. Det tredje er gennemførlighed: Kan restore gennemføres uden skjulte afhængigheder til kompromitterede konti, enkeltpersoner eller udokumenterede manuelle trin.
Hvis ét af de tre kriterier fejler, er testen ikke mislykket. Tværtimod. Så har du fået et ærligt billede af risikoen. Det er præcis den type dokumenterbar kontrol, som både kunder, cyberforsikring og compliancearbejde i stigende grad efterspørger. Har du behov for at koble det til ledelsesansvar og styring, er workshop-formatet ofte en god ramme til at få beslutningerne forankret.
Typiske fund i danske SMV’er
De fleste restore-tests fejler ikke kun på software. De fejler i samspillet mellem teknik, drift og mennesker. En backup kan godt eksistere, mens gendannelsen stadig går i stå, fordi MFA-enheden ligger hos en enkelt medarbejder, fordi servicekonti ikke er dokumenteret, eller fordi en ekstern leverandør skal aktiveres, uden at nogen ved hvem der ringer til hvem.
I praksis ser vi ofte fire mønstre. Backup er taget, men ikke testet. Restore virker på filer, men ikke på hele systemer. RTO og RPO er enten ikke besluttet eller urealistiske. Og rollerne under en hændelse er uklare. Det sidste er vigtigt, fordi genopretning i en krise også er en adfærdsopgave. Hvis brugere, ledelse og driftsteam ikke ved, hvad de skal gøre, bliver tekniske værktøjer hurtigt mindre værd. Derfor kan det være relevant at supplere med awareness-træning eller et mere samlet beredskab via Forkant, hvis jeres organisation har brug for en fast rytme i arbejdet.
Retest: fra rapport til prioriteret handlingsplan
En restore-test uden retest giver kun halv værdi. Hvis testen viser, at økonomisystemet først kommer op efter 19 timer mod et mål på 6, eller at backup ikke kan gendannes uden en admin-konto, som også bruges til daglig drift, så er den vigtigste opgave at få ændringerne verificeret hurtigt.
Lav derfor en enkel retest-model. Røde fund retestes inden for 14 til 30 dage. Gule fund samles i næste forbedringsrunde. Grønne fund dokumenteres som bevis for, at kontrollen virker. Outputtet skal være kort og ledelsesvenligt: fund, konsekvens, ejer, deadline og retest-status. Ikke 40 sider teknik.
Det er her mange SMV’er får reel værdi. En defensiv pentest af backup og restore bliver et lille styringsværktøj for forretningskontinuitet. Den hjælper dig med at prioritere investeringer, leverandørdialog og interne vaner. Og den gør det lettere at svare, når en kunde, revisor eller forsikringspartner spørger: Har I testet, at jeres gendannelse faktisk virker?
Næste skridt: kør en 30-dages restore-øvelse
Hvis du vil gøre noget konkret i denne måned, så vælg fem systemer, skriv RTO og RPO ned på én side, og planlæg en kontrolleret restore-test med tydelige beviser og dato for retest. Hold scope lille. Mål faktisk tid. Mål faktisk datatab. Notér alle skjulte afhængigheder. Det giver mere værdi end endnu et grønt backup-dashboard.
Har I endnu ikke et fælles overblik over kontroller, compliance og prioritering, så kan det være en god start at samle tekniske og ledelsesmæssige beslutninger omkring modenhedsanalyse, sikkerhedstjek og pentest. Pointen er enkel: Backup tæller først for alvor, når din virksomhed kan bevise, at I også kan komme tilbage i drift.