Disaster Recovery and Business Continuity Planning

Business Continuity Planning (BCP) and Disaster Recovery Planning (DRP) are two sides of the same coin, but they serve different purposes. BCP is about keeping the organisation functioning during a disruption. DRP is about restoring IT systems and data after a disaster. Think of BCP as the lifeboat that keeps everyone afloat while the ship is sinking, and DRP as the dry dock where you repair the hull.

A Business Continuity Plan (BCP) documents the procedures and resources needed to continue critical business operations during and after a disaster. It identifies which business functions are essential — for example, payroll, customer support, or order processing — and outlines how to maintain them manually or with backup systems. A BCP must consider threats like power outages, cyberattacks, natural disasters, and pandemics. It usually includes contact lists, alternative work locations (like working from home), and prioritised recovery steps.

A Disaster Recovery Plan (DRP) is a subset of BCP that focuses specifically on IT infrastructure. It specifies how to recover systems, applications, and data. For example, if a ransomware attack encrypts all servers, the DRP tells the IT team how to restore data from backups, rebuild servers using images, and bring the network back online. DRP has two key metrics:

Why do these plans exist? Because organisations cannot afford to stop. A hospital must keep treating patients during a power cut. An e-commerce site must keep accepting orders even if its main server farm burns down. Regulations like HIPAA (healthcare) and PCI DSS (payment cards) often require documented BCP and DRP. The plans also protect against lawsuits — if a company loses customer data and has no recovery plan, it can be sued for negligence.

What do these plans replace? In the past, many organisations had no formal plan and simply reacted when a disaster struck. That reactive approach led to chaos — people didn't know whom to call, backups were missing, and recovery took weeks. Modern BCP/DRP is proactive: you plan, document, test, and update regularly. A key concept is the Business Impact Analysis (BIA), which identifies which systems are critical and what the financial and operational impact would be if they went down. The BIA drives your RTO and RPO decisions.

Another critical element is the backup strategy. Backups can be full (copy of everything), incremental (only changes since last backup), or differential (only changes since last full backup). They are stored on-site (fast restore but vulnerable to same disaster) or off-site (slower restore but safer). The 3-2-1 rule is a best practice: three copies of data, on two different media types, with one copy off-site.

Finally, you need to test these plans. A tabletop exercise is a discussion-based test where people talk through a scenario. A walkthrough is a step-by-step review of the plan. A simulation involves actually restoring systems from backup. Testing reveals gaps — like missing passwords, outdated contact numbers, or corrupted backups — and lets you fix them before a real disaster.

Sarah is the IT manager at a mid-sized accounting firm called Ledgerwise Ltd. She has 50 employees, a small on-premises server room, and a cloud-based accounting platform. One Tuesday morning, a sprinkler system in the server room malfunctions, spraying water across three server racks. Two servers fail immediately; a third sparks and shuts down. Sarah needs to execute the DRP she wrote last quarter.

Step 1: She declares a disaster. She calls the CEO and the emergency response team (the facilities manager, the head of finance, and herself). She opens the DRP document from a waterproof binder and her laptop (backed up to the cloud). The plan states that RTO for the file server is 4 hours, and RPO is 1 hour. For the email server, RTO is 1 hour, RPO is 15 minutes.

Step 2: She contacts the off-site data centre where they have a hot standby server. A hot standby is a fully configured server that is already running and can take over within minutes. She gives the data centre team the authorisation code from the plan. They begin replicating the most recent backups to the standby. The backups are taken every 15 minutes for email and every hour for file shares, stored on a separate disk array in the data centre.

Step 3: She redirects traffic. Using the cloud-based DNS management console, she changes the company’s email and file server domain names to point to the standby servers' IP addresses. Within 30 minutes, employees can access email and shared folders again, though the file server is still in its 4-hour window.

Step 4: She initiates the recovery for the damaged servers. The facilities manager dries the room and orders replacement hardware. Sarah copies the server images from a secure off-site backup to new hardware. This takes 3 hours because the full backup is 500 GB.

Step 5: She tests the restored servers before bringing them live. She runs a quick integrity check on the data and verifies that the accounting software connects correctly. By 5 PM, the original servers are replaced and functional.

The next day, Sarah reviews the incident. She finds that the BCP (business continuity) had worked well — staff worked from home for two hours using laptops and a backup internet connection. But the DRP had a gap: the hot standby contract didn't include email filtering, so spam flooded in. She updates the plan to add a spam filtering service to the standby. She also schedules a quarterly simulation test, where the IT team deliberately fails a server to practise the restore procedure.

The key takeaway for the CAS-005 candidate: an IT professional does not just write a DRP and put it on a shelf. They maintain it, test it, and refine it based on lessons learned. The real world demands that plans be practical, tested, and updated after every exercise or actual incident.