DRP og BCP

Hvor ofte skal man teste sin DRP?

Kontrollér automatisk, at kopierne stadig starter, mindst hver måned, og gennemfør en reel failover med en forretningsopgave mindst én gang om året. Test igen, så snart serveren, netværket, leverandøren eller den person, der har nøglen, skifter.

Opdateret i oktober 20263 min. læsetid6 kilder citeret

Det vigtigste

Hver dag: Læs de mislykkede backups. Hver måned: teknisk opstart af nødmiljøet.
Hvert kvartal: en gendannelse med tidtagning. Hvert år: en reel failover med tilbagerulning.
NIST foreskriver en årlig test af genetableringskapaciteten; GDPR og ANSSI (Frankrig) kræver regelmæssige test.
Enhver væsentlig ændring (server, større version, administrator, leverandør, internetforbindelse) udløser en test.
Det vigtigste: den skriftlige dato for den seneste test og de afvigelser, der er rettet.

Hvad referencerammerne siger

NIST. Vejledningen SP 800-34, der er skrevet til amerikanske føderale systemer, foreskriver at teste genetableringskapaciteten og teamene hvert år for at identificere svagheder. Selve planen skal holdes ajour med en hyppighed, som organisationen fastlægger, for eksempel hvert år, og efter hver væsentlig ændring.
GDPR. Artikel 32 kræver midler til rettidigt at genoprette tilgængeligheden af personoplysninger og en procedure for regelmæssigt at teste og vurdere effektiviteten af sikkerhedsforanstaltningerne.
ANSSI (Frankrig). Ifølge Frankrigs nationale agentur for cybersikkerhed skal backups testes regelmæssigt, og der skal udarbejdes en procedure for gendannelse af informationssystemet, som jævnligt gennemføres. Til kriseøvelser anbefaler agenturet at tænke i en flerårig strategi med formater, der gradvist bliver mere krævende.

Ingen af disse tekster kræver »hver måned under reelle forhold«. De peger alle på hyppige kontroller og en fuld test mindst én gang om året.

Hvorfor ikke »hver måned under reelle forhold«

En reel failover afbryder eller risikerer at afbryde produktionen. At gøre det hver måned koster mange timer og meget energi, og teamene ender med at sjuske med det. En grundig årlig test er bedre end et månedligt ritual, hvor ingen åbner applikationen.

Omvendt er det for længe at vente et år på at opdage, at en backup ikke længere starter. Derfor den hyppige, lette tekniske kontrol og den sjældne, fuldstændige forretningstest.

En realistisk kalender for en SMV

Hvornår	Hvad
Hver dag	Læs de mislykkede backups. En DRP, der bygger på en defekt kopi, er en defekt DRP
Hver måned	Teknisk opstart af nødmiljøet uden at afbryde produktionen
Hvert kvartal	Gendannelse af en fil eller en database med tidtagning
Hvert år	Reel failover eller tilsvarende med forretningsbruger og tilbagerulning
Ved hver ændring	Ny server, ny større version, administratorens fratrædelse, skift af leverandør eller internetforbindelse

Stærkt regulerede sektorer og kritiske systemer (sundhed, kontinuerlig industriproduktion) forkorter linjen »hvert år«, undertiden til hvert halve år. Det er ikke minimumsstandarden for en SMV i servicebranchen. Detaljerne for hvert niveau findes i Hvordan tester man en DRP?.

Hvad der tæller mere end hyppigheden

Den skriftlige dato for den seneste test og de afvigelser, der er rettet. En DRP, der blev testet for elleve måneder siden med en rapport, er i bedre stand end en DRP, der er »testet hele tiden«, men uden dokumentation for, hvad der er kontrolleret. NIST kræver, at hver øvelse resulterer i en rapport med observationer og anbefalinger til forbedringer.

Hvis den seneste test er mere end tolv måneder gammel, så sig det ligeud til ledelsen. Det er en oplysning, ikke en skam. Fejlen består i at fortælle en kunde eller et forsikringsselskab, at planen er driftsklar.

Efter en reel hændelse

En reel katastrofe er en test, forudsat at der udarbejdes en rapport inden for en uge: hvad der tog længere tid end forventet, hvad der manglede, hvad der ændres i planen. Uden det rammes man to gange på samme måde. Se også Min server er gået ned: hvad gør jeg?.

Hos WeDoBack

Opstartskontrollen er månedlig og inkluderet i DRP uden at røre ved produktionen: Den dækker linjen »hver måned« i tabellen for imaget, men ikke for forretningsopgaven. Testen under reelle forhold planlægges, med op til ti timer, efter tilbud: Den er det naturlige valg til den årlige linje. Intet i tilbuddet tester den menneskelige procedure for jer (hvem beslutter, hvor er nøglen, hvordan varsles teamet). Den del følger rytmen af fratrædelser og ansættelser, ikke softwarens rytme.

Se tilbuddet DRP Bed om et tilbud

Ofte stillede spørgsmål

Er der et lovkrav om, hvor ofte der skal testes?

Der er ingen generel regel for alle SMV’er. GDPR (artikel 32) og ANSSI, Frankrigs agentur for cybersikkerhed, kræver test »regelmæssigt« uden at fastlægge en hyppighed. NIST anbefaler for amerikanske føderale systemer en årlig test. Visse regulerede sektorer, jeres kontrakter eller jeres forsikringsselskab kan kræve en højere hyppighed.

Tæller en reel katastrofe som en test?

Ja, forudsat at der udarbejdes en rapport inden for en uge: hvad der tog længere tid end forventet, hvad der manglede, hvad der ændres i planen. Uden denne dokumentation bidrager hændelsen ikke til at forbedre planen.

Hvad siger man til en kunde eller et forsikringsselskab, hvis den seneste test er mere end et år gammel?

Sandheden, med datoen. At erklære en plan for driftsklar uden en nylig test skaber risiko for en kløft mellem løfte og virkelighed på katastrofedagen. Det er bedre at oplyse den planlagte dato for den næste test.

Læs videre

Kilder

Dokumenter gennemgået i oktober 2026.

SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
Forordning (EU) 2016/679 (GDPR), artikel 32 — EUR-Lex
Sauvegarde des systèmes d’information – Les fondamentaux (Backup af informationssystemer – det grundlæggende, ANSSI-BP-100, v1.1, 27. november 2025) — ANSSI (fransk agentur)
Organiser un exercice de gestion de crise cyber (Tilrettelæggelse af en øvelse i cyberkrisestyring) — ANSSI (fransk agentur)
SP 800-84, Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities (september 2006) — NIST
Tilbuddet DRP: genoptagelse af driften efter en katastrofe — WeDoBack

Et projekt inden for backup, DRP eller BCP?

Mere end 20 års erfaring med beskyttelse af virksomheders data.

Anmod om et tilbud +33 9 72 50 78 28

Beskyt dine data med WeDoBack

Krypteret offsite-backup, uforanderlig lagring, DRP og BCP: Fortæl os om dine servere, så foreslår vi den rette kombination.

Anmod om et tilbud Se løsninger og priser