At Lanware, we specialise in supporting regulated investment firms. When talking to customers, we often see confusion between disaster recovery (DR) and business continuity planning (BCP). While they are intrinsically linked, they are not the same thing.
They’re related, but they’re not interchangeable, and that confusion can often lead to slow decision-making and unrealistic recovery assumptions when real-life incidents occur, such as a cyber incident, cloud outage, loss of premises or third-party supplier failure.
In this article, we’ll explain the difference, how DR and BCP fit together, and what the Financial Conduct Authority (FCA) expects firms to be able to evidence, particularly through the lens of operational resilience. This isn’t about creating a 50-page document that nobody reads. It’s about having a plan that works and being able to prove it.
Our approach starts with business outcomes (what must keep running), then maps the people, process and technology dependencies behind them, before testing them in practice. We’re not interested in deploying technology for the sake of it, we’re interested in measurable recovery and clear decision-making under pressure.
DR vs BCP: the plain-English definitions
Disaster recovery (DR) is the IT side of recovery: how you restore technology and data after an incident. Think of servers, Microsoft 365, identity, connectivity, and the line-of-business applications your team relies on.
- Typical DR questions: How do we restore systems after ransomware? What happens if Microsoft 365 is unavailable? What if we lose office internet? What if a key SaaS platform has an outage?
- Key DR targets: RTO (Recovery Time Objective - how quickly a service must be back) and RPO (Recovery Point Objective - how much data loss you can tolerate, measured in time).
- DR outputs: Protected backups (often immutable), tested restore procedures and runbooks, failover design where appropriate, and evidence of regular testing.
Business continuity planning (BCP) is the business side of resilience: how you continue to deliver important services during disruption. It covers people, process, premises, technology, communications and third parties, including what you do when you can’t restore everything immediately.
- Typical BCP questions: Who declares an incident? Who makes decisions? How do we communicate with investors, counterparties and staff? What workarounds keep critical activity moving?
- BCP outputs: An incident management structure, call trees and communications templates, alternative working arrangements, prioritised workarounds, third-party escalation paths, and an exercise schedule.
DR usually sits inside BCP but BCP is broader and business-led.
The key differences
Aspect
Disaster recovery (DR)
Business continuity planning (BCP)
Primary focus
Technology and data restoration
Continuity of business services end-to-end
Owned by
Usually IT / technology (with business input)
Business leadership with IT, risk, compliance and operations
Time horizon
“How fast can we restore?”
“How do we keep operating while disruption continues?”
Success measure
RTO/RPO met; systems restored; data integrity verified
Service delivered within agreed tolerances; customer harm and market impact minimised
Typical outputs
Backups, restore runbooks, failover design, recovery testing evidence
Incident roles, communications plan, workarounds, third-party escalation, exercises
Common failure mode
Backups exist but restores are slow/untested; identity dependency blocks recovery
Everyone assumes “IT will fix it”; no clear decision-making or client comms; manual processes not rehearsed
Why the distinction matters more in smaller financial firms
Smaller firms often have the same regulatory expectations as much larger organisations, but with leaner teams and heavier reliance on third parties. In practice, that creates a number of predictable risks:
- Key-person dependency: Continuity plans fail when only one person understands the trading platform, the portfolio accounting process, or the restore steps.
- Third-party concentration: Managed service providers, cloud platforms and specialist vendors are central to service delivery, but accountability always remains with your firm.
- Hidden dependencies: You can’t restore an application if identity, DNS, internet access, devices, or privileged access controls aren’t available.
- Investor expectations: Limited partners and institutional clients increasingly ask for evidence of resilience, testing and supplier oversight.
- Regulatory scrutiny: The FCA’s focus on operational resilience means firms must evidence how they prevent, respond and recover from disruption, not simply state that they “have DR”.
What the FCA expects
The FCA takes a principle-led approach, caring less about the brand of tooling you use and more about whether you can demonstrate control, preparedness and learning. The key area is operational resilience - the ability to prevent, adapt to, respond to, recover and learn from disruption.
The FCA’s operational resilience rules came into force on 31 March 2022, and in-scope firms had until 31 March 2025 to complete their mapping and testing, and to be able to remain within their impact tolerances for each important business service. Even where parts of your IT are outsourced, accountability always stays with your firm and regulators expect evidence, not assumptions.
In practical terms, firms should be able to provide evidence for the following:
- Identify important business services: The services that, if disrupted, could cause intolerable harm to consumers or market integrity (e.g. ability to execute trades, value portfolios, meet margin calls, process subscriptions or redemptions, meet reporting obligations).
- Set impact tolerances: The maximum tolerable level of disruption for each important business service. These are often time-based but may also include measures such as volumes, value of transactions, or client segments impacted.
- Map resources and dependencies: The people, processes, technology, data, premises, and third parties required to deliver each important business service.
- Scenario test: Test severe-but-plausible disruption scenarios (e.g. cyber incidents, cloud outages, loss of premises, supplier failure) to assess whether your firm remains within impact tolerances and to identify vulnerabilities.
- Remediate vulnerabilities: Prioritise and invest to reduce the likelihood and impact of breaches of impact tolerance.
- Have response and recovery plans: Clear incident roles, decision points, communications, and recovery steps that work together - this is where BCP and DR meet.
- Governance and documentation: Board/SMF oversight, clear accountability, and a self-assessment that explains your approach and supporting evidence.
Bringing it together: what “good” looks like
For financial services firms, the goal isn’t to promise you’ll never have an incident. The goal is to be confident that when disruption occurs, you can keep your important business services running (or recover them quickly), communicate clearly, and demonstrate control to clients and regulators.
Lanware typically works with firms to identify important business services, set sensible impact tolerances, translate these into RTO and RPO targets, document and test recovery runbooks, and run scenario-based exercises that include key third parties. The output is a clear, auditable evidence pack you can use with investors, auditors and, when needed the FCA.
If you’d like guidance on how DR and BCP fit together in practice for a regulated firm, Lanware can help you assess your current position and identify practical next steps.
