Building a Disaster Recovery Plan (DRP): BCP in 8 Steps

You walk into the office on a Monday morning to find the server room under water. The fire extinguisher discharged; the insurer is assessing damage. The answer to "what now?" takes consulting 5 people at once, wearing out IT on the phone with repeating questions, and missing customer requests in the meantime — the typical pattern during a disaster. With a disaster-recovery plan (DRP), everyone knows what to do, decisions have been made in advance, and only execution is required. This guide shows the skeleton of a DRP/BCP that an SME can actually deploy, in 8 concrete steps.

The Difference Between DRP and BCP

The two concepts are often confused:

• BCP (Business Continuity Plan): Covers every business process. Answers operational questions like "how do we respond to customer calls, how do we issue invoices, how do we ship from the warehouse."
• DRP (Disaster Recovery Plan): The IT slice of the BCP. Answers technological questions like "how do we recover the server, how do we restore the email system."

In an SME, the two can be combined into one document; called "DRP/BCP" on paper and covering both operations and IT.

Step 1: Set Scope and Goals

How deep will the plan go? A practical scope for SMEs:

• Which disasters do we cover? — fire, flood, ransomware, hardware failure, extended power outage, pandemic, loss of critical personnel
• Which systems/processes are critical? — accounting, email, file server, customer portal
• For what timeframe? — interim continuity within 24 hours, full recovery within 7 days

Scoping is done with management; it is not just IT's job. Senior management approval gives the next steps legitimacy.

Step 2: The Crisis Management Team

Who does what? Predefined roles reduce friction during a crisis:

• Crisis lead: Usually the CEO/owner. The final decision authority.
• IT lead: Runs the technical recovery process.
• Communications lead: Customer, employee, press communications.
• Operations lead: Manual continuation of workflows.
• Site lead: Physical recovery (after fire, flood).

For each role, a primary and backup person is identified. The question "if X happens to the owner, who decides?" must be answered. The contact list keeps everyone's phone, alternate number, and email written down.

Step 3: Business Impact Analysis (BIA)

Which system is how critical? The ranking drives the budget. A simple BIA table for an SME environment:

Numbers are estimates; the math should include revenue loss, customer loss, late-delivery penalties, and wasted employee time. These numbers are determined sitting down with senior management.

Step 4: RTO and RPO Definitions

The target recovery time (RTO) and acceptable data loss (RPO) are written down for each system. For details, see our RTO/RPO guide. These numbers drive the technology choices in the next step.

Step 5: Recovery Procedures

The most important and usually missing step. For each critical system, step-by-step instructions on how to bring it back. Example:

System: Accounting server (Windows Server 2022 + SQL)

Scenario: Hardware failure, server will not boot.

Procedure:

1. Bring the standby server from the office storage (on the labeled shelf)
2. Plug in network and power
3. Check the BIOS boot order — SSD first
4. Sign in to the Veeam Console as admin (account: dr-admin, password: in the safe)
5. "Restore entire VM" → source: 2026-04-26 21:00 backup → target: standby server
6. Automatic IP assignment during restore; old server's IP will be used (192.168.1.50)
7. Estimated restore time: 90 minutes
8. After restore, SQL service starts automatically; verify manually
9. In the ERP software, try saving a test record
10. Notify employees: "system is ready, you can log in"

This procedure should be printed on paper + in the IT folder + in cloud Drive. It must be followable click by click during a crisis.

Step 6: Communications Plan

During a crisis, who notifies whom and how? Three directions:

• Internal: Tell employees what is going on, when it will return to normal, and the interim working method (e.g., "no email today, communicate via the WhatsApp group"). A message must go out within 1 hour.
• Customers: Proactive contact with affected customers. Volunteering the information without being asked builds trust. A clear message like "there is a brief disruption in our systems; it will be resolved within X hours."
• Suppliers/partners: Notify in advance if shipments, deliveries, or invoicing will be delayed. Watch the contract terms (late-delivery penalties, etc.).

Templated messages live in the plan document. Instead of writing during a crisis, you paste from a structured template.

Step 7: Testing and Drills

An untested plan is just nice-sounding sentences on paper. A practical test calendar for an SME environment:

• Small test every 3 months: Restoring a single file or email from backup. A 1-hour exercise.
• Medium test every 6 months: Full restore of one critical system. Restore to a test server and verify it works. A half-day exercise.
• Major drill once a year: A "our server room burned down completely" scenario. Exercising every role in the team, real restore + communications + operational continuation. A 1-2 day exercise.

Post-drill report-out: what worked, what fell short, which procedure needs an update. These reports form the basis for the next revision of the plan.

Step 8: Revision and Updates

The plan is a living document. It must be updated in these cases:

• When a new system goes live
• When headcount changes by 20%+
• When you change premises
• When a new threat (e.g., a new ransomware variant) emerges
• When a gap is found during a test

An annual formal review (signed off by management) is mandatory. The plan date, version, and last test date should appear at the top of the document.

Common Mistakes

• Writing the plan and shelving it: An untested plan fails most successfully. Do not loosen the "1 annual drill" requirement.
• Only involving IT: Business continuity is not something IT can solve alone. Senior management, finance, operations, and customer relations must take part.
• Calling a single-page name list a "plan": Without practical procedures, execution becomes impossible during a crisis. Step-by-step instructions for each critical system are essential.
• Not updating the old version: The plan was written 3 years ago and is unchanged; meanwhile servers changed, employees left, the backup software was upgraded. An old plan misdirects.
• Forgetting the paper copy: In a scenario that includes a digital fire, the digital plan may be lost too. Keep paper printouts + copies at a different location.

Frequently Asked Questions

Who should the team be? We have no IT department; we outsource IT.

In that case, the IT lead role is held by the outsourced service provider (like Yamanlar Bilişim); DR responsibility must be explicitly written into the contract. A reachable 24/7 line must be in place during a crisis, with an SLA tied to the RTO number.