BCP and DRP: continuity and recovery planning

What BCP and DRP are - and why the distinction matters

Business continuity planning (BCP) and disaster recovery planning (DRP) are complementary disciplines, but with distinct scopes. Confusing them leads to gaps that only surface at the worst possible moment: during a real incident.

The BCP - Business Continuity Plan covers the entire organization. It defines how critical functions will be maintained during any type of disruption: ransomware, power outage, loss of a physical facility, pandemic or failure of a strategic supplier. The BCP answers the business question: how does the company keep operating? It involves people, processes, suppliers, communication and alternative facilities - not just technology.

The DRP - Disaster Recovery Plan is a technical subset of the BCP. It focuses on restoring IT systems, data and digital infrastructure after severe disruption events. The DRP answers the technical question: how do the systems come back online, in what order and how quickly? Without a structured BCP behind it, the DRP fixes IT but leaves the business without direction.

The interdependence is clear: the BCP defines the recovery objectives that the DRP must meet. If the billing process has an RTO of 4 hours, the IT team responsible for the ERP system needs to deliver recovery within that window. This accountability chain - from business to technology - only exists when BCP and DRP were developed together.

BIA: the analytical foundation of all planning

The Business Impact Analysis (BIA) is the process that turns assumptions into numbers. Without it, continuity plans are opinions - with it, they are decisions grounded in data.

The BIA starts by identifying the critical business processes. Not all processes: only those whose interruption causes unacceptable impact on revenue, regulatory compliance, reputation or people's safety. For each identified process, the BIA maps:

• Internal dependencies: IT systems (ERP, CRM, payment platform), specific teams, physical facilities, critical data.
• External dependencies: cloud providers, telecommunications providers, logistics partners, settlement banks.
• Financial impact per time interval: loss in the first hour, the first day, the first week. Includes lost revenue, emergency recovery costs, contractual penalties and reputational damage.
• MTD (Maximum Tolerable Downtime): the point of no return - how long the organization can survive without that function before suffering irreversible damage.

The output of the BIA is a document of priorities: which processes must be recovered first, which resources are non-negotiable and what the cost of not having continuity is. This document is the technical justification for every cent invested in resilience.

RTO and RPO: the two numbers that govern every technical decision

Derived from the BIA, RTO and RPO are the parameters that turn business objectives into concrete technical requirements.

The RTO (Recovery Time Objective) is the maximum acceptable time between the start of an interruption and the full resumption of a process's operation. It must be shorter than the MTD, with a safety margin. If the billing system has an MTD of 8 hours, the RTO should be at most 5-6 hours - reserving time for the unexpected.

The RPO (Recovery Point Objective) is the maximum amount of data the organization accepts losing, expressed in time. An RPO of 1 hour means the organization tolerates losing at most 60 minutes of transactions. This imposes a direct requirement on the frequency of backup or data replication.

Process criticality	Example	Typical RTO	Typical RPO	Recommended IT strategy
Critical (Tier 1)	Payment platform, core banking systems	< 1 hour	< 5 minutes	Active-active high availability, synchronous replication
High (Tier 2)	ERP, e-commerce, customer service	2-4 hours	15-60 minutes	Hot site or DRaaS with asynchronous replication
Medium (Tier 3)	HR, BI, internal intranets	4-24 hours	4-8 hours	Warm site, frequent backup with fast restoration
Low (Tier 4)	File systems, historical reports	24-72 hours	24 hours	Cold site or daily backup restoration

Continuity strategies: from backup to full failover

With RTO and RPO defined, it is possible to choose the appropriate strategies - without overestimating (prohibitive cost) or underestimating (recovery beyond the deadline).

For data and IT systems

The minimum acceptable standard is the 3-2-1 rule: three copies of the data, on two different media types, with one copy offsite. To withstand ransomware, the third copy must be immutable - stored in a repository with WORM (Write Once, Read Many) protection or in storage that makes modification via a compromised credential impossible. A backup without immutability is not a backup against ransomware: it is just a mirror the attacker will also encrypt.

For RTOs below 4 hours, backup is not enough: the organization needs continuous replication to an alternative environment. The options vary in cost and activation speed:

• Hot site: mirrored infrastructure running in standby, with data replicated in real time. Activation in minutes. Highest cost.
• Warm site: pre-provisioned hardware, data replicated periodically, requires configuration before activation. Activation in hours.
• Cold site: reserved physical space or cloud capacity, without continuous replication. Activation in days. Lowest cost, used for Tier 3 and 4 processes.
• DRaaS (Disaster Recovery as a Service): the provider manages the failover infrastructure, usually cloud-based. Combines moderate cost with relatively fast activation (1-4 hours).

For people and facilities

Technology recovered without people able to operate it does not solve the problem. The BCP should include: cross-training for all critical roles (every essential position with at least one trained backup person); pre-identified and contracted alternative work sites; and tested remote work capability - not just declared.

For suppliers and the supply chain

Single suppliers are blind spots. The BIA should identify critical dependencies on third parties, and the BCP should document pre-qualified alternatives with contracts or contingency agreements activated on demand. The failure of a cloud provider, a payment processor or an input supplier can be as devastating as an attack.

Crisis plan and communication under pressure

When the BCP is activated, the command structure needs to be clear and predefined - it cannot be improvised while systems are down and customers are calling. The reference model is the Incident Command System (ICS), adapted to the corporate context:

• Incident Commander: the ultimate decision authority during the crisis. Sets priorities, authorizes resources, declares the start and end of the emergency.
• Operations Lead: executes the recovery actions. Coordinates technical and operational teams.
• Communications Lead: manages internal (employees) and external (customers, press, regulators) messaging. All external communication goes through them.
• Logistics Lead: sources and provisions resources: equipment, space, emergency services.
• Finance Lead: authorizes expenses, controls incident costs, documents for insurance and audits.

The cadence of communication during a crisis is as important as the technical actions. Regular updates - every 2-4 hours initially - to the entire organization prevent the information vacuum that breeds rumor, panic and customer defection. Organizational silence during a crisis is interpreted externally as chaos.

Testing: the only way to know whether the plan works

An untested continuity plan is a documented hypothesis. Real crises reveal flawed assumptions that no paper review detects: the remote access that freezes with 200 simultaneous users, the backup that was never restored and is corrupted, the emergency contact with an outdated number.

The testing program progresses in complexity and impact:

1. Tabletop exercise: the team gathers and walks through the scenario verbally. No real action is executed. Identifies gaps in procedures, responsibilities and communication. Low cost, high frequency (quarterly).
2. Walkthrough (physical verification): resources are physically verified - a visit to the alternative site, remote access test, restoration of a backup sample, confirmation of supplier contracts. Semi-annual.
3. Partial simulation: parts of the plan are executed in a controlled environment - failover of a non-production system, relocation of part of the team to the alternative site. Annual for Tier 1 functions.
4. Full-scale exercise: simulation of a real disaster with full activation of the BCP/DRP. Operation in continuity mode for 24-72 hours. High operational cost; performed every 2-3 years.

After each test: structured debriefing, updating the plans with the gaps found and tracking the corrections through to implementation. ISO 22301 requires that test results be documented and that the identified improvements be incorporated.

Relationship with incident response and ransomware

The BCP and DRP are activated by the same trigger that activates the incident response plan (IRP): a significant disruptive event. The difference is one of focus - the IRP manages the investigation, containment and eradication of the threat; the BCP/DRP manages business continuity and recovery. The two disciplines need to be integrated.

In the current context, ransomware is the main DRP trigger in Brazil. A successful attack encrypts production and backup data in minutes when both are on the same network. An effective response requires three simultaneous pillars: (1) immutable backups out of reach of the production network; (2) tested isolation and failover procedures - not just documented; (3) a ransomware-specific runbook with clear criteria for the ransom payment decision, communication protocols with authorities (ANPD, Federal Police, insurers) and customer communication scripts.

Organizations that have already tested the DRP against a ransomware scenario before suffering the attack recover in hours. Those that improvise take days or weeks - and frequently pay the ransom even when backups exist, because they were never restored.

Normative references: ISO 22301 and NIST SP 800-34

ISO 22301:2019 is the international standard for business continuity management systems (BCMS). It specifies the requirements to plan, implement, monitor and continuously improve continuity capability. Certified organizations demonstrate to customers, regulators and insurers that resilience is managed systematically - not reactively.

NIST SP 800-34 Rev.1 (Contingency Planning Guide for Federal Information Systems) is the most detailed technical reference available for free, with a step-by-step methodology for BIA, plan development and testing. Even for private Brazilian organizations, NIST SP 800-34 is the most complete operational guide for structuring an IT DRP.

For regulated organizations in Brazil, the LGPD (General Data Protection Law) requires technical and organizational measures to protect personal data - which implicitly includes the continuity and recovery of the systems that process it. The absence of a documented BCP/DRP can aggravate the ANPD's assessment in a data leak incident.

Frequently asked questions

What is the difference between BCP and DRP?

The BCP covers the entire organization - people, processes, facilities and suppliers - ensuring that critical functions continue during any disruption. The DRP is a technical subset of the BCP focused on restoring IT systems and data. In short: the BCP answers 'how does the company keep operating?' and the DRP answers 'how do the systems come back online?'.

What is RTO and how is it calculated?

RTO (Recovery Time Objective) is the maximum acceptable time to restore a function after an interruption. Calculated from the MTD identified in the BIA, the RTO must have a safety margin below the irreversible-damage threshold. Example: a process with an MTD of 6 hours should have an RTO of 2-4 hours.

What is RPO and why does it determine the backup strategy?

RPO (Recovery Point Objective) is the maximum amount of data accepted as lost, in time. An RPO of 5 minutes requires real-time replication; an RPO of 24 hours allows nightly backup. The RPO is the main cost driver of data protection.

What is a BIA and who should conduct it?

The BIA maps critical processes, their dependencies and the financial impact of interruptions over different time windows. It should be conducted by the continuity owner with the direct participation of business leaders - not just IT. Its output is the prioritized list of RTOs and RPOs that justifies investments.

How often should the BCP be tested?

ISO 22301 requires regular testing. Recommended practice: quarterly tabletops, semi-annual walkthroughs, annual partial simulations and a full-scale exercise every 2-3 years. Untested plans are not plans - they are documented assumptions.

How does ransomware fit into the BCP and DRP?

Ransomware is today the main DRP trigger. The plan should include immutable backups outside the production network (3-2-1 rule), tested isolation and failover procedures and ransomware-specific runbooks for the mass-encryption scenario - including criteria for the ransom payment decision and communication with authorities.

How Decripte structures continuity and resilience

Decripte serves organizations of 1 to more than 100,000 employees in structuring BCP and DRP - from the initial BIA survey to running full-scale exercises and ISO 22301 certification. The work begins with a free resilience maturity assessment: mapping the critical gaps and estimating the real financial impact of an unmanaged interruption.

For companies that have already suffered an incident, support includes immediate operational recovery and development of the continuity plan as part of the response - turning the crisis into a starting point for structured resilience. For companies that want to get ahead of the risk, the plans are built before the incident - which, in the current threat landscape, is only a matter of time.

Access the free assessment or explore the resilience and incident response plans available for each organization size.