How to Build a NIS2 Disaster Recovery Plan: RTO, RPO, MTPD, and CIR Annex 4’s 8 Mandatory Fields

Article 21(2)(c) of the NIS2 Directive names three things inside one security measure: “business continuity, such as backup management and disaster recovery, and crisis management.”^[1] Three concepts, not one. CIR 2024/2690 — the implementing regulation that spells out what those measures actually require — splits them the same way: Annex point 4.1 covers the business continuity and disaster recovery plan, 4.2 covers backup and redundancy, and 4.3 covers crisis management.^[2] Your Disaster Recovery Plan is the IT-recovery half of what point 4.1 describes — whether you write it as its own file or as a chapter inside a wider continuity plan is a practical choice the regulation itself doesn’t dictate, as the FAQ below explains.

This article assumes you already know you need one and focuses on what most guides skip: the exact 8 fields the regulation requires, how to set recovery objectives that actually hold together under scrutiny, what happens operationally when the plan gets activated against real cloud infrastructure, and what an auditor asks to see for each field.

Disaster Recovery Plan vs. Business Continuity Plan: The Distinction NIS2 Actually Draws

A Business Continuity Plan answers a broad question: how does the business keep running — staffing, alternate premises, supplier failover, customer communication? A Disaster Recovery Plan answers a narrower one: how do the IT systems and data actually come back — servers, databases, network paths, cloud regions. NIS2 keeps them as related but distinct concepts under the same Article 21(2)(c) measure, and CIR 2024/2690 draws its own line one level up: it groups the business continuity and disaster recovery plan under a single Annex point (4.1), with backup and redundancy (4.2) and crisis management (4.3) each getting their own separate point.^[2] Our BCP/DRP/crisis-plan comparison and field-by-field template walkthrough covers how to structure all three as separate documents; this article assumes that structure is already decided and goes deep on the DRP itself.

One structural mistake shows up often enough that auditors specifically flag it: merging the DRP into the BCP as a single chapter. It reads as thorough on first pass. In practice, a system-level DR update — a new cloud region, a changed backup vendor — then forces a full re-approval of the combined document, and version history stops meaning anything. Keep them as separate files with a shared reference, not one file with two headings.

The 8 Fields CIR 2024/2690 Annex Point 4.1 Actually Requires

The regulation is specific about content, though it hedges on rigidity: the plan “shall include, where appropriate,” these eight elements.^[2] That qualifier matters — a five-person managed service provider and a 3,000-employee cloud infrastructure operator both need all eight, but the depth scales with size and risk exposure.

Field	What it requires
(a) Purpose, scope and audience	Which systems, which teams, and who is authorised to read it
(b) Roles and responsibilities	Named roles, not just titles, for every recovery action
(c) Key contacts and communication channels	Internal escalation plus vendor/cloud-provider support contacts, with an offline copy
(d) Conditions for activation and deactivation	The specific trigger that turns “an incident” into “a declared disaster”
(e) Order of recovery for operations	Which system comes back first when everything is down at once
(f) Recovery plans per operation, including recovery objectives	RTO/RPO stated per system, not one number for the whole organisation
(g) Required resources, including backups and redundancies	The infrastructure — cloud regions, standby capacity, backup storage — the plan actually depends on
(h) Restoring and resuming activities from temporary measures	How you get off the emergency workaround and back to normal operations

Fields (d) through (h) are where DRPs most often fail an audit, because they demand decisions, not descriptions: a real activation trigger, a real recovery order, real numbers per system. The rest of this article works through exactly those five: setting the objectives in field (f) correctly, activating field (g)’s cloud resources against fields (d) and (e), and what field (h) looks like in practice.

The RTO/RPO/MTPD Triangle: Setting Recovery Objectives That Actually Fit Together

Most disaster recovery plans get the order backwards. Teams pick a Recovery Time Objective first — often a round number like “4 hours” because it sounds achievable — then discover during the first real test that it doesn’t match what the business can actually survive. The correct starting point is the Maximum Tolerable Period of Disruption: the point at which a system being down stops being an inconvenience and becomes unacceptable, contractually, legally, or financially.^[3] MTPD isn’t itself a recovery target; it’s the ceiling. Your Recovery Time Objective must sit at or below that ceiling, with margin — in practice, most practitioners build that margin in deliberately, since the clock from disruption to full restoration also has to absorb the detection and decision time that happens before recovery work formally starts.^[3]

Recovery Point Objective sits on a different axis entirely — not time-to-restore, but tolerable data loss, measured backwards from the moment of failure. It’s driven by how often you can realistically back up or replicate, not by how urgent the system feels.^[3] A payment system can carry a tight RTO and a near-zero RPO at the same time, because users notice downtime fast and a lost transaction is a real loss; an internal reporting dashboard might tolerate a 24-hour RTO with a 24-hour RPO, because nobody needs yesterday’s numbers back in real time.

A concrete example makes this less abstract. Say your organisation issues statutory e-invoices with a same-day legal deadline. The Business Impact Analysis — covered in full in our BIA guide — should surface an MTPD of roughly 8 hours for that system, set by the legal deadline itself, not by IT preference. RTO then gets set below that ceiling, at 4 hours, leaving margin for detection and decision time; RPO gets set independently at 1 hour, driven by how frequently the invoicing database can realistically replicate without a performance hit. Three numbers, three different justifications, one system.

A widely used practical framework — a heuristic, not itself a NIS2 or CIR requirement — tiers systems by criticality and assigns RTO/RPO bands accordingly: mission-critical systems in seconds to minutes, business-critical in minutes, operational systems in hours, administrative systems in hours to days.^[6] Use it to triage where your BIA effort goes first, not as a substitute for actually doing the BIA. Manufacturing and OT environments need this tiering exercise even more, because a single production line often contains systems spanning all four tiers at once.

Cloud DR Activation: What Actually Happens When You Declare a Disaster

Field (d) — conditions for activation and deactivation — is where vague plans get caught. “We’ll activate DR if there’s a major outage” isn’t a condition; it’s a restatement of the problem. A workable condition names the observable signal — a health check failing past a defined window, a confirmed regional outage on the cloud provider’s own status page, a corrupted primary database — and names who has authority to declare it: typically one named DR lead, not “IT,” because ambiguity about who can pull the trigger causes exactly the hesitation that turns a contained incident into a prolonged one.^[6] Declaring DR also doesn’t pause your Article 23 notification clock — the 24-hour early warning still runs from the moment you become aware of a significant incident, in parallel with whatever recovery work is underway, not after it.^[4]

Once declared, what happens next depends on which of four standard cloud recovery postures field (g)’s resources were actually built around:^[5]

• Backup and restore — lowest cost, slowest recovery. Data and infrastructure-as-code exist in the recovery region; nothing is running. You redeploy from scratch. Fine for systems with an RTO measured in many hours or days.
• Pilot light — core data stores replicate continuously to the recovery region; application servers exist as ready-to-deploy configuration but stay switched off until needed. Recovery means turning them on and scaling out.
• Warm standby — a scaled-down but fully functional copy already runs in the recovery region, serving no live traffic. Recovery means scaling up capacity, not deploying from nothing.
• Multi-site active/active — the workload already runs in more than one region simultaneously. There’s no failover in the traditional sense — traffic simply shifts away from the failed region — but it’s the most expensive posture by a wide margin.

The actual cutover, in most of these postures, comes down to a DNS or traffic-manager change — redirecting a domain from the failed region’s endpoint to the recovery region’s — rather than anything more exotic. That step itself is fast. What takes longer is everything upstream of it: confirming the failure is real, getting the declare authority to act, and validating that the recovery environment’s data is current enough to serve traffic within your RPO.^[5][6] Automating the declare-and-failover decision entirely sounds appealing but carries its own risk — an automated trigger that fires on a false alarm causes the exact outage the plan exists to prevent, which is why manual-but-scripted activation, “the push of a button” rather than a from-scratch response, is the common middle ground in practice.^[5]

Failback — returning to the original region once it’s healthy again — deserves the same documentation as failover and almost never gets it. It requires confirming data has synchronised back correctly, picking a low-traffic window, and running the same validation steps in reverse. A DRP that documents only the emergency direction and not the return trip fails field (h) — “restoring and resuming activities from temporary measures” — even when the emergency response itself was flawless.

Backup Validation Is Your DRP’s Required Test — Not a Separate Obligation

CIR point 4.1 requires the business continuity and disaster recovery plan to be “tested, reviewed and, where appropriate, updated at planned intervals and following significant incidents,” with lessons learnt incorporated.^[2] Point 4.2.6, in the neighbouring backup-and-redundancy section, separately requires regular testing of backup recovery, with documented results and corrective action where a test fails. These read like two obligations. For the DRP specifically, they’re the same test viewed from two angles: a documented, timed restore of a real backup, checked against the recovery objective set in field (f), is simultaneously your evidence that field (g)’s required resources actually work and your evidence that the plan has been tested per its own mandate. Our backup and redundancy guide covers the mechanics of running that test and the documentation format auditors expect; this section is about what the result proves for the DRP, not how to run the test itself.

A restore test that succeeds but isn’t timed against the stated RTO proves nothing for field (f). A restore test that finishes within RTO but never checks data currency against RPO proves nothing for field (g). The two objectives from the triangle above need separate confirmation in the same test cycle — restoration speed and data currency — not just a single pass/fail result.

The Auditor Evidence Checklist: One Item Per Mandatory Field

Our 31-control business continuity audit checklist covers the whole Article 21(2)(c) domain. The table below is the narrower slice specific to the disaster recovery plan itself — the artefact an auditor asks to see for each of the 8 mandatory fields, not the prose describing them.

Field	Evidence an auditor asks to see
(a) Purpose/scope/audience	A version-controlled document header naming systems in scope and the distribution list
(b) Roles/responsibilities	Named individuals, with deputies, not job titles alone
(c) Contacts/channels	A current contact sheet, including cloud-provider support tier and account numbers, stored somewhere reachable if primary systems are down
(d) Activation conditions	A written trigger definition plus the name and role of who is authorised to declare
(e) Recovery order	A prioritised system list with the dependency logic behind the order, not just a list
(f) Recovery objectives	Per-system RTO/RPO figures traceable to a BIA, plus the most recent test result measured against them
(g) Required resources	Architecture documentation for the recovery posture actually in use, matching what’s deployed today — not what was planned two years ago
(h) Restoring/resuming	A documented failback procedure with evidence it’s been exercised, not just failover

In our experience reviewing client plans, the single most common gap across these eight is field (g) evidence describing an architecture that was decommissioned or changed months earlier. Cloud infrastructure drifts faster than compliance documentation gets updated — treat the resource section as something to re-verify at every architecture change, not just at the annual review.

Who Owns What

Role	Responsibility	Effort
CISO / IT Security Manager	Defines recovery postures per system, owns fields (d)–(g), runs restore tests	High
IT Operations	Executes the runbook during activation, keeps architecture documentation current	Medium
Compliance Officer	Confirms field-by-field evidence exists before an audit, maintains version history	Medium
Board / Management	Approves recovery objectives that carry cost trade-offs	Low, per cycle

For the full picture beyond the DRP itself — business impact analysis, crisis management, and the complete Article 21(2)(c) requirement set — start with our business continuity guide, which links out to the full Article 21(2) breakdown covering all ten measures.

FAQ

Does NIS2 legally require the DRP to be a separate document from the BCP?

Neither the Directive nor CIR 2024/2690 states a rule on file structure — both are silent on it. What the CIR does require is that the plan be tested, reviewed and updated at planned intervals. Keeping the DRP as a separate file from the BCP avoids the re-approval and version-control problems described above; treat that as documented best practice, not a cited legal requirement.

What if we don’t have MTPD figures for our systems yet?

Then your RTO figures are unverified guesses, however confident they sound. MTPD comes out of the Business Impact Analysis — run that first for at least your most critical systems before finalising DRP recovery objectives.

Does NIS2 mandate a specific RTO or RPO number?

No. Neither the Directive nor CIR 2024/2690 sets a numeric RTO/RPO threshold — recovery objectives are risk-based and proportionate to the entity, set through your own BIA. Anyone citing a fixed NIS2 RTO figure is citing a practitioner heuristic, not the regulation.

How often does the DRP actually need to be tested?

The regulation says “at planned intervals and following significant incidents or significant changes” without naming a cadence.^[2] Quarterly testing for critical systems and semi-annual for the rest is common practitioner guidance, not a cited NIS2/CIR figure — set your own interval and document the rationale.

Key Takeaways

A DRP that would survive scrutiny isn’t defined by page count. It’s defined by whether each of CIR Annex 4.1’s eight fields resolves to something concrete: a named activation authority, a recovery order backed by dependency logic, per-system objectives traceable to a BIA, and a resource description that matches what’s actually deployed today. Set MTPD before RTO, treat your next backup restore test as the DRP’s own required test rather than a separate exercise, and document failback with the same care as failover. None of that is exotic — it’s mostly a documentation discipline problem, not a technology problem.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. NIS2 Directive, Article 21
2. CIR 2024/2690, Annex Section 4
3. PECB — Key Definitions Used in ISO 22301 and ISO 22313
4. NIS2 Directive, Article 23
5. AWS Whitepaper — Disaster Recovery Options in the Cloud
6. Microsoft Azure Well-Architected Framework — Disaster Recovery Design Guide