Business Continuity Plans (BCPs) and Disaster Recovery Plans (DRPs): Definitions, Differences, and Implementation in Small and Medium-Sized Enterprises (SMEs)

The Business Continuity Plan (BCP) enables a company to maintain its essential operations during a crisis, if necessary in a degraded mode. The Disaster Recovery Plan (DRP) organizes the restart of the information system after a disaster, within a predetermined timeframe and with a predetermined level of data loss. The former prevents downtime, while the latter limits its duration. In small and medium-sized businesses, both plans rest on the same foundations: knowing which applications are critical, having backups that can actually be restored, and having tested the procedure before it is needed.

PCA and PRA: What Are the Differences?

The two plans are often mentioned together (“PCA/PRA,” “PRA and PCA”) because they address the same risk: business interruption. They are not implemented at the same time and do not involve the same resources.

‍

‍

We also come across the acronyms PCI and PRI (IT Continuity Plan, IT Recovery Plan), which refer to the strictly IT-related aspects of these plans. In an SME, this distinction is rarely useful: the BCP/DRP is primarily an IT matter, supplemented by business procedures that enable operations to continue during a crisis.

RTO and RPO: The Two Numbers That Define Everything

A disaster recovery plan is built around two objectives, which must be defined on a per-application basis:

• RTO (Recovery Time Objective), or DMIA (maximum permissible downtime): How long can the business operate without this application?
• RPO (Recovery Point Objective), or PDMA (Maximum Permissible Data Loss): How many hours' worth of data can the company afford to lose?

These two metrics determine the technology and the budget. An RPO of 24 hours can be met with a daily backup. An RPO of a few minutes requires continuous replication to a secondary site. The shorter the RPO, the more expensive the solution: that is why these targets must be set by management in collaboration with the business units, and not just by the IT team.

In practice, an SME doesn't need the same recovery time objectives across the board. Email, ERP systems, or production may require an RTO of just a few hours, while an intranet or archiving tool can wait several days.

Developing a Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP) for Small and Medium-Sized Enterprises (SMEs): The Steps

1. Conduct a business impact analysis (BIA). List the business processes, the applications on which they depend, and the impact of a disruption over time (financial, contractual, regulatory, and reputational). This analysis determines the RTO and RPO.
2. Analyze risks. Identify the most likely scenarios: ransomware, hardware failure, human error, damage to the premises, or failure of a service provider or cloud service. This analysis is part of a governance, risk, and compliance (GRC) framework.
3. Select technical solutions. Backup, replication, disaster recovery infrastructure, network access redundancy: each choice must meet specific RTO and RPO requirements.
4. Develop procedures. Who declares a crisis, who does what, in what order services are resumed, and how to contact teams, service providers, and customers. These procedures and the crisis directory must remain accessible even if the information system is down.
5. Test. A plan that has never been tested is just a hypothesis. Testing reveals overlooked dependencies and actual recovery times.
6. Keep the plan up to date. Every new application, migration, or change in service provider affects the plan. Reviewing it at least once a year—and after every major change—helps prevent it from becoming obsolete.

Backup and Disaster Recovery: Why Backup Alone Isn't Enough

Backup is the foundation of any disaster recovery plan, but it is only one part of it. A company may back up its data every night and still be unable to resume operations in less than a week if it has never measured its recovery time or planned which infrastructure to use for recovery.

The standard rule remains 3-2-1: three copies of the data, on two different media, one of which is stored off-site. In response to ransomware, this has been expanded to 3-2-1-1-0: one immutable or offline copy that an attacker cannot encrypt or delete, and zero errors detected during restore tests.

Three points make all the difference in an attack:

• Isolate the backup system. Attackers typically prioritize destroying backups before encrypting data. The backup console must not rely on the same administrative accounts as the rest of the information system and must be protected by multi-factor authentication.
• Verify the restore, not just the backup. A "backup successful" log does not prove that the data can be restored.
• Also cover the cloud. Microsoft 365 ensures service availability, but the Recycle Bin and retention periods are no substitute for an independent backup of your data, especially in the event of a mass deletion or malicious encryption.

Checking Your PRA: Types of Tests and Frequency

There are several levels of testing, ranging from the simplest to the most comprehensive:

• The restore test: restore a file, a database, or a server and measure the time it takes;
• Table-top exercise: Run through a crisis scenario in a meeting with the managers to ensure that everyone knows their role;
• the partial switchover test: restarting a critical application on the backup infrastructure;
• The full-scale exercise: simulate the loss of the primary site and resume operations using the backup system.

There is no single regulatory frequency. A common practice is to regularly test the recovery of critical applications, conduct at least one exercise per year, and retest after every major change to the infrastructure. Each test must be documented, including the date, scope, elapsed time compared to the RTO, observed deviations, and corrective actions. These reports also serve as the evidence required during a compliance audit.

‍

‍

PCA, PRA, and Regulatory Requirements

The PCA/PRA is no longer just a best practice. Several regulations require it directly or indirectly:

• NIS2: Article 21 of the directive lists business continuity—including backup management, disaster recovery, and crisis management—among the risk management measures required of affected entities. To find out if your company is affected, see NIS2: Is My Company Affected?
• DORA: Effective January 17, 2025, for financial institutions, the regulation requires an IT business continuity policy, response and recovery plans, and backup and restore policies. These requirements are incorporated into the contracts of their IT service providers.
• GDPR: Article 32 requires measures to ensure that personal data is restored and access to it is restored within a reasonable timeframe in the event of an incident.

To provide a framework for this process, the SGDSN publishes a methodological guide for developing a business continuity plan, and the ISO 22301 standard defines the requirements for a business continuity management system for companies seeking certification.

The Most Common Mistakes

• A disaster recovery plan stored only on the system it is intended to restore. If the file server is encrypted, the procedure is also encrypted.
• Backups can be accessed using the same credentials as the production environment. An attacker who gains administrative privileges can delete them.
• RTOs set without a budget. Promising recovery within an hour without a backup infrastructure creates a false sense of security.
• Forget about SaaS applications and service providers. Email, CRM, payroll software: you need to plan for the possibility that they might be unavailable as well.
• Never test it. This is the most common mistake—and the one that turns an incident into a crisis.

What IT Systèmes Covers

IT Systèmes designs and implements business continuity and disaster recovery plans for its clients, conducting regular tests to verify their effectiveness. Our support includes conducting an impact assessment, defining recovery objectives, implementing backups and disaster recovery solutions in collaboration with our technology partners—including Veeam—and documenting the tests.

PCA/PRA is an integral part of our IT governance, risk, and compliance offerings and of IT Systèmes’ cybersecurity approach: the teams that oversee and operate your infrastructure on a daily basis are also the ones who prepare for its recovery.

FAQ

BCP or DRP: Which One Should You Start With?
For most small and medium-sized businesses, start with the DRP: isolated, restorable, and tested backups, along with a restart procedure. The BCP comes next for operations that cannot be shut down, where a switchover or degraded mode is warranted.

Is an SME required to have a PCA/PRA?
Yes, if it falls within the scope of NIS2 or DORA. The GDPR also requires the ability to restore the availability of personal data. Outside of these cases, the requirement often stems from customers, requests for proposals, or insurers.

What is the difference between a backup and a disaster recovery plan (DRP)?
A backup is a copy of the data. A DRP is the comprehensive plan for resuming operations: priorities, recovery infrastructure, procedures, responsibilities, and target timelines.

What do RTO and RPO mean?
The RTO is the maximum acceptable downtime for an application, while the RPO is the maximum amount of data that can be lost, expressed in terms of time. These are the two objectives that determine the scope of the disaster recovery plan.

How often should a PRA be tested?
There is no single frequency specified in any guidelines. A common practice is to combine regular recovery tests on critical applications, at least one annual exercise, and a new test after each major change.

‍

‍