Why a backup is not the same as a recovery plan

The short answer

Backups answer "do we have a copy?" A recovery plan answers the questions that matter during an outage:

• What do we restore first, and what can wait?
• How long can each system be down (recovery time objective, RTO)?
• How much recent data can we afford to lose (recovery point objective, RPO)?
• Where will we restore to if the original servers, cloud account or office are unavailable?
• Who does what, and how do they reach each other if email is down?
• Have we proved it works, recently, by actually restoring?

The NIST Cybersecurity Framework makes the same point: it treats recovery as a function of its own, alongside prevention and detection, and expects recovery plans to be executed and improved after each event (NIST).

Why backups alone fall short

Common failures seen in real recoveries:

• Backups were not tested. Jobs reported success, but files were incomplete or could not be restored.
• Backups were reachable by the attacker. Ransomware encrypted or deleted backup copies stored on the same network with the same administrator credentials.
• Restores were too slow. Pulling terabytes from cloud storage over an office internet connection takes far longer than the business expected, and longer still on a congested or failing link.
• Dependencies were missing. Data was restored, but the application also needed a licence server, a database version, DNS records or identity services that no one had documented.
• SaaS data was assumed safe. Microsoft 365, Google Workspace or a line-of-business cloud application had no backup outside the provider's retention settings.
• No one knew the order. Staff restored what they could, not what the business needed first.

Set recovery objectives with the business

RTO and RPO are business decisions, not IT settings. For each important system, ask the people who depend on it:

Shorter objectives cost more: more frequent backups, standby systems, faster storage and more testing. The plan should record the trade-off the business chose.

Protect backups from ransomware

The widely used 3-2-1 rule means three copies of your information, on two different media types, with one copy off site, and CISA's ransomware guidance recommends keeping backups offline, disconnected from the network, so an attacker cannot reach them (CISA). In practice:

• Keep at least one copy offline or immutable (write-once storage that cannot be altered or deleted for a set period).
• Use separate credentials for the backup system, with MFA, not the same domain administrator accounts attackers target.
• Encrypt backups, and store the keys where you can reach them during an incident.
• Monitor backup jobs and alert on failures and unusual deletions.

CISA's ransomware guide covers preparation and recovery steps in more detail (CISA).

Do not forget cloud and SaaS data

Cloud providers keep their services running, but restoring your data after accidental deletion, a malicious insider or ransomware in a synced folder is usually your responsibility. For Microsoft 365, options include Microsoft 365 Backup, a pay-as-you-go service covering SharePoint, OneDrive and Exchange Online (Microsoft Learn), or third-party tools that keep copies outside Microsoft's service. Check every critical SaaS application for its export and restore options.

What a recovery plan contains

NIST's contingency planning guide describes a structured approach: business impact analysis, preventive controls, recovery strategies, plan documentation, testing and training, and maintenance (NIST SP 800-34). A practical plan for a small or mid-sized organisation includes:

1. Scope and triggers: which events activate the plan and who declares it.
2. Contacts: internal roles, IT providers, key vendors, insurer, legal adviser, stored somewhere reachable offline.
3. System priorities with RTO and RPO for each.
4. Dependencies for each system: identity, network, DNS, licences, databases, integrations.
5. Step-by-step restore procedures, written so a competent person who did not build the system can follow them.
6. Alternative arrangements: where people work, how they communicate, how the site is powered if the grid and generator fail, which second internet link is used, and what manual workarounds exist.
7. Communication templates for staff, clients and, if personal data is involved, the notifications described in personal data breach reporting in Nigeria.
8. Testing schedule and results.

Test, then test again

A test is the only evidence that recovery works. Mix three types:

• File and item restores, often, as routine checks.
• Full system restores of important systems to an isolated environment, at least annually, timed against the RTO.
• Tabletop exercises that walk leaders through a scenario, such as ransomware on a Monday morning, to test decisions and communication.

Record how long each test took and what went wrong, then update the plan.

Recovery readiness worksheet

Limitations

A recovery plan must be maintained: every new system, provider or office changes it. Review it at least annually and after any significant change. If you need backup, disaster recovery or restore testing set up or reviewed, see our backup and disaster recovery service.

Sources and further reading

Product capabilities and guidance change. These are the primary sources this article relies on, checked on the review date above.

1. #StopRansomware Guide, Cybersecurity and Infrastructure Security Agency (CISA)
2. NIST Cybersecurity Framework, National Institute of Standards and Technology
3. Contingency Planning Guide for Federal Information Systems (NIST SP 800-34 Rev. 1), National Institute of Standards and Technology
4. Overview of Microsoft 365 Backup, Microsoft Learn

This article is general information, not legal, accounting or security advice for your specific situation. Examples are hypothetical unless stated otherwise.