{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://atlas.maintz.dev/)"},"id":"security/disaster-recovery-plan","url":{"en":"https://atlas.maintz.dev/en/terms/security/disaster-recovery-plan/","da":"https://atlas.maintz.dev/da/terms/security/disaster-recovery-plan/"},"term":{"en":"Disaster recovery plan (DRP)","da":"Disaster recovery plan (DRP)"},"aka":{"en":["DRP","DR plan"],"da":["DRP","genopretningsplan"]},"domain":["security"],"cluster":"incident-response","layer":"governance","status":"current","summary":{"en":"A technical plan for bringing data and systems back after a breakdown or attack, in a set order and time.","da":"En teknisk plan for at få data og systemer tilbage efter et nedbrud eller angreb i en fastlagt rækkefølge og tid."},"body":{"formal":{"en":"Step-by-step technical instructions for rebuilding systems and restoring data from backup, with a fixed order and target times taken from the recovery objectives and the business impact analysis.","da":"Trinvise tekniske instruktioner for at genopbygge systemer og gendanne data fra backup i en fast rækkefølge og med måltider hentet fra genopretningsmålene og konsekvensanalysen."},"plain":{"en":"Like a rebuild guide for a house after a flood - which walls go up first, where the spare parts are, and how long each step takes.","da":"Ligesom en genopbygningsvejledning for et hus efter en oversvømmelse - hvilke vægge der sættes op først, hvor reservedelene er, og hvor lang tid hvert trin tager."},"inPractice":{"en":"After ransomware locks a shipping company's servers, the IT department wipes them and restores the booking system from last night's backup first, then email, then the rest.","da":"Efter at ransomware har låst et rederis servere, sletter IT-afdelingen dem og gendanner først bookingsystemet fra nattens backup, derefter mail og så resten."},"whyItMatters":{"en":"A backup nobody knows how to restore is worthless, and guessing under pressure can turn a one-day outage into weeks.","da":"En backup, som ingen ved, hvordan man gendanner, er værdiløs, og gætteri under pres kan gøre et nedbrud på én dag til flere uger."}},"deepDive":{"en":"NIST SP 800-34 Rev. 1 defines the DRP narrowly as an information-system-focused plan for relocating systems to an alternate site after major, usually physical, damage that makes the primary facility unusable, and separates it from the information system contingency plan, which restores a single system in place. In common usage the DRP covers both: the technical procedures, resources and order needed to restore IT services within the recovery time and recovery point objectives set by the business impact analysis. ISO 22301 treats disaster recovery plans as part of the recovery procedures under clause 8.4, and ISO/IEC 27031 gives guidance on ICT readiness for business continuity.\n\nRecovery strategies are chosen by cost against RTO and RPO. Classic site options are cold sites (space and power only), warm sites (pre-installed hardware, data restored on demand) and hot sites or active-active configurations with continuous replication. Cloud providers describe the same spectrum as backup and restore, pilot light, warm standby and multi-site active-active. Synchronous replication can approach an RPO of zero but faithfully replicates corruption and encryption by ransomware, so point-in-time copies such as snapshots, journaled replication or immutable and offline backups are still required.\n\nThe core of the plan is a dependency-ordered runbook. Foundational services come first: network, DNS, time synchronisation, identity (typically Active Directory or the cloud identity provider), key management and backup infrastructure, followed by databases, application tiers and finally user-facing services. Each step records the owner, estimated duration, validation check and decision point. Credentials, license keys, vendor contracts and the runbook itself must be available when the directory and document management systems are down. Maersk's 2017 NotPetya recovery famously depended on the one domain controller that had survived because it was offline during a power cut in its Ghana office.\n\nCyberattacks change DR assumptions. After ransomware, restoring the most recent backup may reintroduce the attacker, because intrusion often precedes encryption by days or weeks, so recovery requires identifying a clean restore point, rebuilding in an isolated recovery environment, scanning restored data, resetting credentials including the krbtgt account, and preserving forensic evidence before wiping systems. Only exercises that measure actual recovery time and point against the objectives show whether a DRP works; untested restores, missing application-consistent backups and bandwidth limits on large data volumes are the usual failures. The DRP gets technology back, whereas the BCP keeps the business operating meanwhile.","da":"NIST SP 800-34 Rev. 1 definerer DRP'en snævert som en plan med fokus på informationssystemer, der flytter systemer til et alternativt sted efter større, typisk fysisk skade, som gør det primære anlæg ubrugeligt, og adskiller den fra beredskabsplanen for et enkelt informationssystem (ISCP), der genopretter ét system på stedet. I almindelig sprogbrug dækker DRP'en begge dele: de tekniske procedurer, ressourcer og den rækkefølge, der skal til for at genoprette IT-tjenester inden for de mål for genoprettelsestid og tolereret datatab, som konsekvensanalysen har fastsat. ISO 22301 behandler disaster recovery-planer som en del af genopretningsprocedurerne under afsnit 8.4, og ISO/IEC 27031 giver vejledning i IKT-parathed til driftskontinuitet.\n\nGenopretningsstrategier vælges ved at afveje omkostning mod RTO og RPO. De klassiske muligheder er cold sites (kun plads og strøm), warm sites (forhåndsinstalleret hardware, data gendannes efter behov) og hot sites eller active-active-opsætninger med løbende replikering. Cloududbydere beskriver det samme spektrum som backup and restore, pilot light, warm standby og multi-site active-active. Synkron replikering kan komme tæt på en RPO på nul, men replikerer trofast korruption og ransomwarekryptering, så der stadig er brug for kopier fra bestemte tidspunkter som snapshots, journalført replikering eller uforanderlige og offline backups.\n\nKernen i planen er en runbook ordnet efter afhængigheder. De grundlæggende tjenester kommer først: netværk, DNS, tidssynkronisering, identitet (typisk Active Directory eller cloudens identitetsudbyder), nøglehåndtering og backupinfrastruktur, derefter databaser, applikationslag og til sidst de tjenester, brugerne ser. Hvert trin angiver ansvarlig, forventet varighed, valideringstjek og beslutningspunkt. Adgangsoplysninger, licensnøgler, leverandørkontrakter og selve runbooken skal være tilgængelige, når katalogtjenesten og dokumentsystemerne er nede. Maersks genopretning efter NotPetya i 2017 afhang berømt nok af den ene domænecontroller, der havde overlevet, fordi den var offline under en strømafbrydelse på kontoret i Ghana.\n\nCyberangreb ændrer forudsætningerne for DR. Efter ransomware kan en gendannelse af den nyeste backup føre angriberen tilbage, fordi indtrængen ofte ligger dage eller uger før krypteringen, så genopretning kræver, at man finder et rent gendannelsespunkt, genopbygger i et isoleret genopretningsmiljø, scanner de gendannede data, nulstiller adgangsoplysninger inklusive krbtgt-kontoen og sikrer forensiske spor, før systemer slettes. Kun øvelser, der måler faktisk genoprettelsestid og faktisk datatab op mod målene, viser, om en DRP virker; utestede gendannelser, manglende applikationskonsistente backups og begrænset båndbredde ved store datamængder er de typiske fejl. DRP'en får teknikken tilbage, mens BCP'en holder forretningen i gang imens."},"howTo":{"steps":{"en":["Take the recovery time and recovery point objectives from the business impact analysis and list every system and data set the critical services need.","Map the dependencies and set a restore order that starts with network, DNS, time, identity, key management and the backup platform, then databases, applications and user-facing services.","Choose a recovery strategy per system, from backup and restore to warm standby or active-active, whose cost fits the objectives, and make sure offline or immutable backups exist.","Write a runbook step for each system with owner, expected duration, validation check and decision point, and store it offline together with credentials, licence keys and supplier contacts.","For cyberattacks, plan an isolated recovery environment, a way to find a clean restore point and a full credential reset, including krbtgt twice after a domain compromise.","Agree with the incident response lead when evidence has been secured, so systems may be wiped and rebuilt.","Test restores at least once a year, measure the actual recovery time and data loss against the objectives, and close the gaps you find.","Update the plan after every test, incident and major change in systems, hosting or suppliers."],"da":["Hent målene for genoprettelsestid og tolereret datatab fra konsekvensanalysen, og list alle de systemer og datasæt, de kritiske ydelser har brug for.","Kortlæg afhængighederne og fastlæg en gendannelsesrækkefølge, der starter med netværk, DNS, tid, identitet, nøglehåndtering og backupplatformen og derefter databaser, applikationer og de tjenester, brugerne ser.","Vælg en genopretningsstrategi pr. system, fra backup og gendannelse til warm standby eller active-active, hvor prisen passer til målene, og sørg for, at der findes offline eller uforanderlige backups.","Skriv et runbook-trin for hvert system med ansvarlig, forventet varighed, valideringstjek og beslutningspunkt, og opbevar det offline sammen med adgangsoplysninger, licensnøgler og leverandørkontakter.","Planlæg til cyberangreb et isoleret genopretningsmiljø, en metode til at finde et rent gendannelsespunkt og en fuld nulstilling af adgangsoplysninger, inklusive krbtgt to gange efter kompromittering af domænet.","Aftal med den hændelsesansvarlige, hvornår beviser er sikret, så systemer må slettes og genopbygges.","Test gendannelse mindst én gang om året, mål den faktiske genoprettelsestid og det faktiske datatab op mod målene, og luk de huller, I finder.","Opdatér planen efter hver test, hændelse og større ændring i systemer, hosting eller leverandører."]},"pitfalls":{"en":["Relying on replication or snapshots alone, when they copy ransomware encryption and corruption as faithfully as good data.","Restoring the newest backup without checking whether the attacker was already inside when it was taken.","Keeping the runbook and passwords in systems that are down during the disaster.","Never timing a full restore, so the RTO on paper has no link to reality."],"da":["At stole alene på replikering eller snapshots, som kopierer ransomwarekryptering og korruption lige så trofast som gode data.","At gendanne den nyeste backup uden at tjekke, om angriberen allerede var inde, da den blev taget.","At have runbooken og adgangskoderne liggende i systemer, der er nede under katastrofen.","Aldrig at tage tid på en fuld gendannelse, så RTO'en på papiret ikke har noget med virkeligheden at gøre."]},"guides":[{"title":"NIST SP 800-34 Rev. 1 - Contingency Planning Guide for Federal Information Systems","url":"https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final","publisher":"NIST","tier":"standard"},{"title":"#StopRansomware Guide","url":"https://www.cisa.gov/stopransomware/ransomware-guide","publisher":"CISA","tier":"official-doc"},{"title":"Disaster Recovery of Workloads on AWS - Recovery in the Cloud","url":"https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html","publisher":"AWS","tier":"official-doc"},{"title":"Beskyt dig mod destruktive cyberangreb","url":"https://samsik.dk/cyb-publikationer/beskyt-dig-mod-destruktive-cyberangreb/","publisher":"Styrelsen for Samfundssikkerhed","tier":"official-doc","lang":"da"}]},"edges":[{"type":"requires","to":"security/backup","confidence":"high","strength":"normal"},{"type":"requires","to":"security/recovery-objectives","confidence":"high","strength":"normal"},{"type":"part-of","to":"security/contingency-plan","confidence":"high","strength":"normal"},{"type":"mitigates","to":"security/ransomware","why":{"en":"A tested way back from clean backups removes the pressure to pay the ransom.","da":"En afprøvet vej tilbage fra rene backups fjerner presset for at betale løsesummen."},"confidence":"high","strength":"primary"}],"depth":5,"sources":[{"title":"Cyber Security Fast Track - Ordliste","tier":"course-material"},{"title":"NIST SP 800-34 Rev. 1","tier":"standard"}],"draft":true}