What the abbreviations stand for
BCP stands for Business Continuity Plan. It sets out who acts and in what order so that critical processes continue during a disruption. DRP stands for Disaster Recovery Plan, the plan for recovering IT systems and data after a failure. The BCP covers business processes and people, the DRP covers infrastructure; both are part of the business continuity management system (BCM).
| Abbreviation | Full name | What it means in practice |
|---|---|---|
| BCM | Business Continuity Management | A management system, wider than any single document. Processes, roles, plans, tests and reporting that together keep the business working during disruptions |
| BCP | Business Continuity Plan | A document that describes how the company keeps serving clients while something is not working |
| DRP | Disaster Recovery Plan | A document that describes how the technical team restores information systems and data |
| BIA | Business Impact Analysis | A calculation that shows which processes are critical and what their downtime costs. All target time frames come from it |
| RTO | Recovery Time Objective | How quickly a process or system must be back in operation |
| RPO | Recovery Point Objective | How much data it is acceptable to lose, measured in time |
| ONiVD plan | Operational continuity and recovery plan | The Bank of Russia name for a BCP at supervised organisations |
How they are linked: nested levels
These approaches do not compete. They are circles nested inside one another. Each circle is narrower than the one around it and solves a narrower task.
- Risk management is the widest circle. It identifies and reduces all kinds of risk the company faces, from currency risk to reputational risk.
- BCM is the part of risk management that answers one question: how to keep working when something has already happened.
- BCP is the main document within BCM. It covers the business as a whole: processes, people, suppliers, clients and communications.
- DRP is the technical part, most often issued as an annex to the BCP. It covers servers, communication links, databases and backups.
Comparison table
| Parameter | BCP, business continuity plan | DRP, disaster recovery plan |
|---|---|---|
| Scope | Business processes and obligations to clients | Information systems, infrastructure and data |
| Main question | How to keep providing services while recovery is under way | How to get the systems working again |
| Owner | The business: a management board member or the chief operating officer | IT department |
| Who carries it out | All departments involved in critical processes | System, network and database administrators, contractors |
| Key metrics | Process RTO, MTPD, MBCO, cost of one hour of downtime | System RTO and RPO, time to switch to the backup site |
| What it includes | Scenarios, workarounds, communications, backup sites, activation procedure, crisis team roles | Recovery procedures, switchover procedure, backups, data integrity checks |
| Typical size | A main document plus action cards for each scenario | Technical procedures for each critical system |
| What happens without it | The systems are back up, but nobody knows how to serve clients or what to tell them | A decision has been made, but technically there is nothing to recover with and nothing to recover from |
| How it is tested | Tabletop scenario walk-throughs, crisis team exercises | Live switchover to the backup site, test restore from a backup |
BCP and DRP: where the boundary lies
The boundary lies where technology ends and obligations to the client begin. The easiest way to see it is with three test questions.
Question one. What does the company do in the hours while the systems are being restored? If there is no answer, you have a DRP and no BCP. Even in the most optimistic scenario, recovery takes hours, and all that time the business has to keep working somehow: take orders on paper, serve clients in a backup environment, shift the workload to another office.
Question two. Who says what to clients, staff and the regulator? Crisis communications sit entirely in the BCP. No technical procedure covers them, and this is where the second, reputational, damage most often happens.
Question three. What if IT has nothing to do with it? A fire at the warehouse, no access to the office, the departure of a key employee, the failure of a sole supplier, blocked payments to a counterparty. By definition, a DRP does not cover such scenarios, yet they account for a significant share of real continuity disruptions.
The opposite case is rarer, but it happens too: a company writes a polished BCP with processes and communications, and it contains no technical targets at all. During an incident it turns out that the business expects recovery within two hours, while backups run once a day and physically cannot meet that target. That is why both documents are prepared together, and their target time frames must match.
One incident, broken down by role
Friday, 19:40. Ransomware hits the company's file servers and some of its business applications. Let us see which document is in play at each moment.
| Time | What happens | Which document applies |
|---|---|---|
| 19:40 | Monitoring detects an anomaly; the duty administrator sees that systems are unavailable | Monitoring procedure, then the DRP |
| 19:55 | Encryption is confirmed. The decision is made to isolate network segments | DRP and the information security incident response plan |
| 20:10 | The business continuity plan is activated, the crisis team meets, a response lead is appointed | BCP, activation procedure section |
| 20:30 | Critical processes move to workarounds: orders taken by phone and on paper forms, manual reconciliation | BCP, scenario action cards |
| 21:00 | The first message goes out to clients and partners, a media statement is prepared, the regulator is notified | BCP, communications section |
| Night | Systems are restored from backups, data integrity is checked, the extent of data loss is assessed | DRP |
| Saturday | Processes return to normal operation step by step; data entered in workaround mode is reconciled | BCP, return to normal operations section |
| Monday | Incident review, record of actual downtime and losses, update of both plans | BCM as a system |
Note that the DRP works first and last, while the BCP carries the whole middle part, when the company is actually operating without its systems. This middle part is usually missing in companies where only the IT department deals with continuity.
RTO, RPO, MTPD and MBCO
Four metrics where business expectations and technical capabilities most often diverge.
RTO, recovery time objective. How quickly a process or system must be back in operation. The business sets it on the basis of calculation; it should not be left to technical staff to set as an afterthought.
RPO, recovery point objective. How much data it is acceptable to lose. It is measured in time: an RPO of four hours means that in an outage the company is ready to lose the data from the last four hours of work. This metric directly determines how often backups are made and what the solution costs.
MTPD (maximum tolerable period of disruption). This is the period after which the damage from a stopped process becomes unacceptable for the company: it loses its licence, a key client or the ability to recover. The RTO must always be shorter than the MTPD, otherwise the plan is meaningless.
MBCO, minimum acceptable level of service. It sets how much service the company commits to keep up in crisis mode, which goes beyond a simple “working or not”. For example, handling at least 40% of the normal payment flow. This metric turns the plan from a yes-or-no switch into something you can manage.
Who is responsible for what
| Role | BCP | DRP |
|---|---|---|
| Management board, board of directors | Approves the plan and the acceptable level of risk, allocates resources | Approves the budget for redundancy |
| Process owner | Sets the RTO and MBCO, describes workarounds, decides on activation | Sets the requirements for systems |
| Continuity or risk management function | Methodology, coordination, BIA, testing, reporting | Checks that technical time frames match business ones |
| IT | Takes part in carrying it out | Full owner of the document and the recovery procedures |
| Information security | Attack scenarios, requirements for isolation and recovery | Checks data integrity and that there is no reinfection |
| Communications and public relations | Message templates, work with the media and clients | Not involved |
| Internal audit | Checks that the plan is tested and updated | Checks actual restores from backups |
Russian terms: ONiVD and the ONiVD plan
In Russian regulatory practice, the same documents have other names. The Bank of Russia uses the term operational continuity and recovery (ONiVD), and the main document is called the ONiVD plan. In substance it is the same BCP, but with a mandatory set of sections, ties to technological processes with defined threshold values, and supervisory reporting.
The practical result is simple. If a company is supervised by the Bank of Russia, its current BCP is usually extended to meet the requirements of the regulation; there is no need to rewrite it from scratch. You add a list of technological processes, operational reliability targets, an incident recording procedure and a testing programme. A detailed review of the requirements and structure is in the article ONiVD and the ONiVD plan: Bank of Russia requirements, and a ready-made eleven-section plan framework in docx format is in the ONiVD plan sample (in Russian).
The reverse confusion also happens: a bank's contractors find a requirement to “provide an ONiVD plan” in their contract and do not understand what is wanted, although they already have a working business continuity plan under a different name.
Five common mistakes
Treating the DRP as enough. The most common mistake. The company orders a disaster recovery plan, ticks the “we have a plan” box and finds the gap only during a real incident.
Setting the RTO without calculation. The figure comes from general considerations instead of a business impact analysis. As a result, the company either overpays for redundancy of processes whose downtime is tolerable, or fails to provide redundancy for what is truly critical.
Different time frames in the BCP and DRP. The business wrote down two hours, the technical side delivers eight. The gap shows up at the very first test, if testing is done at all.
Forgetting non-IT scenarios. Loss of access to premises, loss of a key employee, supplier failure. These scenarios have no technical solution and need organisational arrangements made in advance.
A plan without an owner. The document exists, but no specific person is responsible for it, so it is not updated and goes out of date within a year.
Both abbreviations live inside one system. What this system is and how it works as a whole: business continuity: what it is and where to start.
Frequently asked questions
DRP stands for disaster recovery plan. It describes how to restore IT systems and data after a failure: in what order, how fast and with how much data loss. It is part of a wider business continuity plan, the BCP.
The business continuity plan, BCP, answers how the company will keep working until the systems are restored: people, premises, manual procedures, counterparties. The disaster recovery plan, DRP, answers how to bring the systems back. The first is wider, and the second sits inside it; the full comparison table is above.
Yes, if the company has at least one critical IT system. Without a DRP, the business does not know when the systems will be back; without a BCP, it does not know what to do until then. For a small company, both plans can be sections of one document.
A DRP is a disaster recovery plan, a document. A DRS, a disaster recovery site or disaster recovery system, is the backup site or system you switch to under this plan. The question “how fast will we recover” is for the plan; the question “where and on what” is for the site.
The process owner sets the RPO in the BCP, and the RPO determines how often backups are made under the DRP.
What is BCM in plain words? Business continuity management. It is a system that decides in advance which processes must not stop, how long the company can survive without them and what exactly people do when a process stops.
Which comes first, the BCP or the DRP? First a business impact analysis, which shows the critical processes and the acceptable time frames. Then the BCP, which sets the requirements. The DRP is written to requirements that are already known; otherwise the technical time frames are pulled out of thin air.
How is BCM linked to information security? Information security prevents and detects an attack; BCM keeps the company working if the attack succeeds. These are neighbouring functions with shared scenarios. More in the article BCM and data protection.
Does a small company need a BCP? Yes, but only a few pages long. A small business has few critical processes, and a plan for them takes one working day to write. Having no plan costs more.
What is a BCP stress test? A test of the plan under near-extreme conditions: several dependencies fail at once, some people are unavailable and time is short. The aim is to find the point where the plan breaks; passing the test is not the goal.
Where to start with business continuity
13 questions and 5 minutes will show your readiness level. Then there are two paths: work it out yourself through the programme, or build the system with us.
