Most organizations have a disaster recovery plan tucked somewhere in a SharePoint folder. Far fewer have a disaster recovery *policy* , and auditors notice the difference. After the CrowdStrike Falcon Channel File 291 outage in July 2024 took down an estimated 8.5 million Windows devices globally, regulators in multiple jurisdictions asked the same pointed question: *who was accountable for recovery, and what documented standard governed it?* Many teams couldn't answer cleanly.
This article explains what a disaster recovery policy is, how it differs from a DR plan, and how to write one that holds up under regulatory scrutiny.
TL;DR
- A disaster recovery policy sets governance rules , scope, ownership, and standards , while a DR plan provides step-by-step execution detail.
- The policy must name RTO and RPO thresholds, define roles, and reference compliance obligations (ISO 22301, DORA, etc.).
- Without a signed, versioned policy, DR plans lack organizational authority and audit evidence.
- Writing one takes roughly five structured sections; each is covered below.
What Is a Disaster Recovery Policy?
A disaster recovery policy is the formal governance document that defines an organization's commitment to restoring IT systems and data after a disruptive event. It establishes scope, ownership, recovery objectives, and compliance obligations , typically one to three pages , and gives the downstream DR plan its organizational authority. It tells readers *why* and *who*; the plan tells them *how*.
Disaster Recovery Policy vs Disaster Recovery Plan
Practitioners often conflate these two documents. The confusion is understandable , both live in the DR program , but conflating them causes real problems. If you bury governance commitments inside a 40-page technical runbook, executives won't read them, boards can't approve them, and auditors flag the gap.
| Dimension | Disaster Recovery Policy | Disaster Recovery Plan |
|---|---|---|
| Purpose | Governance and accountability | Operational execution |
| Audience | Board, executives, auditors | IT teams, operations staff |
| Length | 1–4 pages | 20–80+ pages |
| Update frequency | Annual or on material change | Quarterly or after each test |
| Contains RTO/RPO | Yes , as targets | Yes , as procedural inputs |
| Signed by | CISO, CIO, or Board | IT Director or DR Manager |
| Regulatory evidence | Primary audit artifact | Supporting artifact |
Think of the policy as the constitution and the plan as the legislation that implements it. You need both. For a deeper look at plan construction, see How to Build an IT Disaster Recovery Plan (Step-by-Step).
Why a Standalone Policy Matters for Compliance
Regulators are explicit about documentation hierarchy. Under DORA Article 11, financial entities must maintain ICT business continuity policies that are approved by management and reviewed at least annually. ISO 22301:2019 Clause 8.4 requires documented information establishing recovery procedures with defined recovery time objectives. Neither requirement is satisfied by an undated plan buried in a team wiki.
The NIST SP 800-34 Rev. 1 contingency planning guide for federal systems similarly separates the *policy* (which must receive senior official approval) from the *plan* (which the IT team maintains). Australian organizations operating under APRA CPS 230 face comparable requirements.
The Change Healthcare ransomware attack in February 2024, which disrupted prescription processing for over 100 US pharmacy chains, surfaced a related pattern: UnitedHealth Group faced intense Congressional scrutiny not just about what failed, but about the governance structure that should have prevented or bounded the failure. A clear, board-approved DR policy is part of that governance structure.
Five Sections Every Disaster Recovery Policy Needs
1. Purpose and scope
State plainly what the policy governs and what it excludes. Scope creep in a policy is as dangerous as scope creep in a project. A common mistake practitioners make is writing scope statements so broad that the policy nominally covers every system the organization has ever touched , which makes meaningful RTO/RPO commitments impossible.
Be specific: name the IT assets, data classifications, geographic locations, and business units covered. If certain legacy systems are excluded pending decommissioning, say so explicitly and document the risk acceptance.
2. Recovery objectives
The policy must state approved RTO and RPO targets by system tier. These aren't aspirational numbers , they're governance commitments that drive budget, architecture, and vendor contracts.
A practical tiering looks like this:
| System tier | Example systems | RTO target | RPO target |
|---|---|---|---|
| Tier 1 , Critical | Core banking, ERP, patient records | < 4 hours | < 1 hour |
| Tier 2 , Important | CRM, email, payroll | < 24 hours | < 4 hours |
| Tier 3 , Standard | Internal wikis, dev environments | < 72 hours | < 24 hours |
These numbers should come from a business impact analysis. The BIA is where you calculate what downtime actually costs per tier; the policy is where leadership formally accepts those targets. Skipping the BIA and guessing at RTOs is a common shortcut that creates liability.
3. Roles and responsibilities
Name roles, not individuals. People leave; roles persist. The policy should define:
- Policy owner , typically the CISO or CIO, responsible for annual review and board sign-off
- DR program manager , responsible for maintaining plans, scheduling tests, and managing vendors
- Business unit liaisons , responsible for validating RTO/RPO assumptions for their functions
- Crisis decision authority , who can invoke the DR plan and under what threshold
In most organizations we've seen, the accountability gap sits between IT (who runs the technical recovery) and business operations (who determines whether recovery is adequate). The policy is the right place to close that gap formally.
4. Testing and maintenance requirements
A policy that doesn't mandate testing is a document, not a commitment. Specify minimum testing frequency by tier , most frameworks recommend at least annual testing for Tier 1 systems, with tabletop exercises more frequently. Reference your disaster recovery testing schedule and require that test results feed back into plan updates.
Also specify the review trigger events beyond annual cycle: material infrastructure change, acquisition, significant incident, or regulatory change. The CrowdStrike outage of July 2024 should have been a mandatory review trigger for any organization that relied on that endpoint product.
5. Compliance and regulatory alignment
List the specific frameworks and regulations the policy is designed to satisfy. This section turns the policy into an audit artifact. For example:
- ISO 22301:2019 Clause 8.4 (recovery procedures)
- DORA Article 11 (ICT business continuity)
- NIST SP 800-34 Rev. 1 (contingency planning)
- APRA CPS 230 (operational risk management)
- FCA PS21/3 (operational resilience for UK financial services)
If your organization operates across jurisdictions, mapping each requirement to a specific policy section saves significant time during audits. This kind of compliance mapping is also where purpose-built BCM platforms , rather than static documents , start to earn their cost.
How to Write One: A Practical Sequence
Step 1: Gather inputs before you write. You need the BIA outputs (system tiers and cost-of-downtime data), existing DR plans (to understand what governance they assume), and any recent audit findings. Writing a policy in a vacuum produces a document that conflicts with reality on day one.
Step 2: Draft the scope and exclude thoughtfully. Run the draft scope past both IT leadership and legal. Legal will often want to include data retention obligations; IT will want realistic boundaries.
Step 3: Set RTO/RPO targets in a working session. Don't email a spreadsheet and ask for sign-off. Gather the CISO, CTO, and key business unit heads in one session and work through tier classifications together. Disagreements surface here, not during an incident.
Step 4: Assign named roles to the responsibility matrix. Even though the policy uses role titles, attach a living annex (or link to an RACI in your BCM platform) that maps current names to roles. Keep it outside the policy body so updating names doesn't require re-approval.
Step 5: Get formal sign-off and version it. A policy signed by the CISO but not the board has limited authority in regulated industries. Determine the right approver tier for your regulatory context, then version the document clearly: v1.0, approval date, next review date.
Step 6: Link it to subordinate plans. The policy should explicitly reference your DR plan(s), cloud DR strategy, and DR plan examples by industry if applicable. Auditors follow document hierarchies; make the trail obvious.
For a full walkthrough of the planning process that the policy governs, see the Disaster Recovery Planning: A Complete Guide.
Common Policy Gaps That Fail Audits
In most organizations we've seen reviewed under DORA or ISO 22301, three gaps appear repeatedly:
Missing third-party dependencies. The policy covers internal systems but says nothing about critical SaaS vendors or cloud providers. The Snowflake customer breaches (April to June 2024) reminded practitioners that your recovery capability is only as strong as your upstream vendor's. The policy should state that material third-party services are subject to the same RTO/RPO classification as equivalent internal systems.
No defined invocation threshold. The policy says the DR plan can be activated but doesn't define what event or severity level triggers activation. This creates hesitation during actual incidents , exactly the wrong moment for ambiguity. Define trigger criteria: data loss exceeding RPO, system unavailability exceeding a time window, or declaration by a named authority.
Stale version without review evidence. A policy dated three years ago with no evidence of annual review is worse than a gap in some regulatory contexts, because it shows the control existed but was abandoned. If your review cycle slipped, document why and when it resumed. Version control in a managed platform makes this easier than hunting through email threads.
Relationship to Business Continuity Policy
A DR policy sits within a broader resilience governance structure. The business continuity policy covers the organization's overall approach to continuity across people, premises, and processes , not just IT. The DR policy is a subordinate document that zooms in on technology recovery.
Framing matters for board presentations: when leaders understand that DR policy is a component of business continuity governance, which in turn is part of enterprise resilience, they're more likely to treat the approval process seriously rather than viewing it as an IT housekeeping task.
For organizations managing cascading failures across interconnected systems, the cascading crises framework is a useful companion to the policy's tier classification.
Sources
- ISO 22301:2019, Clause 8.4 , Business Continuity Management Systems: Requirements
- DORA (EU Regulation 2022/2554), Article 11 , ICT Business Continuity Policy
- NIST SP 800-34 Rev. 1 , Contingency Planning Guide for Federal Information Systems
- APRA CPS 230 , Operational Risk Management (effective 1 July 2025)
- FCA PS21/3 , Building Operational Resilience (effective March 2022)
- Reuters reporting on CrowdStrike global outage, July 2024
- Congressional testimony on Change Healthcare ransomware attack, February–March 2024
Discover how Fortiv's disaster recovery solutions help teams build audit-ready policies and keep recovery objectives current across every system tier →
