Disaster Recovery & Business Continuity

Building recovery programmes that work when it matters most – not just on paper.

Most organisations have some form of disaster recovery documentation. Far fewer have tested it, validated it against real-world dependencies, or asked what happens when three systems fail simultaneously instead of one. That gap, between documented plans and genuine resilience, is where I work.

Unlike business continuity, which has a clear international standard in ISO 22301, disaster recovery has no single governing framework. Organisations typically draw on NIST SP 800-34 for contingency planning guidance, ISO/IEC 27031 for ICT readiness, or ISO 22301 itself, but none of these fully address the complexity of how real systems fail and recover in practice. That gap is structural: contingency planning too often remains at a high level, leaving organisations uncertain whether their BC measures genuinely meet their risk appetite, whether their DR infrastructure is fully understood, and whether RTOs and RPOs reflect actual risk rather than optimistic assumptions.

It was precisely to address this that I developed my layered dependency mapping framework and wrote An IT Manager’s Guide to Disaster Recovery, to give organisations a rigorous, end-to-end approach that connects risk management to BC requirements, validates those requirements against real infrastructure, and ensures that DR objectives are set to meet the risks that actually exist, not the risks an organisation hopes it has.

Across more than 20 years, I’ve delivered and tested over 30 disaster recovery plans for organisations ranging from UN agencies to multinational corporations. I’ve seen what fails under pressure, and I build programmes specifically designed to avoid those failures.

 

30+

DR Plans Delivered & Tested

20+

Years of DR Experience

3 Test Types

Tabletop · Technical
Full Interruption

Frameworks

ISO 22301
NIST 800-34
ISO/IEC 27031

What Makes My Approach Different

Standard DR planning identifies critical systems, documents recovery steps, and meets compliance requirements. That’s necessary — but it’s not sufficient.

What it consistently misses is the cascading effect: when System A fails, what else goes down with it? When you begin recovering System B, does that create a conflict with System C’s recovery? Which hidden dependencies will only reveal themselves at the worst possible moment?

My approach uses a layered dependency mapping framework developed across real-world engagements to surface these issues before they surface during an actual disaster. The result is a recovery programme that accounts for how your infrastructure actually behaves under failure conditions, not how a compliance checklist assumes it will.

Disaster Recovery Strategy & Planning

Every effective DR programme starts with understanding what your business actually needs to recover, not what a standard template assumes. I work with you to define recovery objectives that are realistic, prioritised, and grounded in your operational context.

What you receive:

      • A DR strategy aligned to your business objectives and risk appetite
      • Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) defined and validated against operational reality
      • Disaster scenario modelling covering technical, environmental, and human failure modes
      • Clear documentation your teams can actually use under pressure, not shelf-ware

Business Impact Analysis & Dependency Mapping

Most BIAs produce a list of critical systems. Mine produces a map of how those systems connect, depend on each other, and fail together. This is the foundation on which everything else is built.

What you receive:

      • Identification of critical processes and the systems, people, and suppliers that support them
      • Multi-layer dependency mapping using my proprietary framework
      • Cascading failure analysis — what fails when your primary system fails
      • Quantified impact assessment: financial, operational, reputational, and regulatory
      • Recovery sequence priorities based on actual interdependencies

DR Testing & Validation

A plan that’s never been tested is an assumption, not a strategy. I design and facilitate testing programmes that build genuine confidence — and uncover gaps before a real disaster does.

What you receive:

      • Tabletop exercises — structured scenario walkthroughs with key stakeholders
      • Technical recovery testing — validating that systems can actually be recovered within agreed timeframes
      • Full interruption testing — simulating real failure conditions with live systems
      • Post-test analysis, gap identification, and structured plan refinement
      • An ongoing testing schedule that keeps your programme current as your infrastructure evolves

Recovery Orchestration & Runbooks

The difference between a recovery plan that works and one that doesn’t is often in the detail: who does what, in what sequence, and what they do when something unexpected happens. I build runbooks that are clear, executable, and designed for real crisis conditions.

What you receive:

  • Step-by-step recovery procedures for each critical system and process
  • Roles and responsibilities clearly defined, no ambiguity under pressure
  • Escalation paths and communication protocols for both internal and external stakeholders
  • Recovery sequencing optimised around your dependency map
  • Vendor and third-party coordination procedures

Business Continuity Planning

Disaster recovery restores your IT systems. Business continuity keeps your organisation functioning while that recovery happens. The two are inseparable — and both need the same rigour.

What you receive:

      • Business continuity strategy covering operations, people, facilities, and supply chain
      • ISO 22301-aligned Business Continuity Management System (BCMS) design
      • Crisis management framework and communication planning
      • Business continuity testing and exercise programme
      • Integration with your IT disaster recovery programme

ISO 22301 & NIST 800-34 Compliance Support

Compliance with DR and BC frameworks is often a business or regulatory requirement. I help you meet those requirements in a way that produces real resilience, not just audit-ready documentation.

What you receive:

      • Gap analysis against ISO 22301 and NIST 800-34
      • Remediation roadmap with prioritised actions
      • Policy and procedure development aligned to framework requirements
      • Audit readiness support and evidence preparation
      • Ongoing compliance programme guidance

Business Continuity vs Disaster Recovery: What’s the Difference?

The two are closely related but serve distinct purposes. Most organisations need both.

Business Continuity

Keeping your organisation operational during a disruption — regardless of cause.

Covers:

    • People, processes, facilities
    • Supplier and partner dependencies
    • Communications and crisis management
    • Maintaining critical services while recovery happens

Disaster Recovery

Restoring your IT systems, data, and infrastructure after a disruption has occurred.

Covers:

  • Servers, networks, applications, cloud environments
  • Data backup and restoration
  • Recovery time and recovery point objectives
  • Structured restoration to normal operations

In practice, the two programmes are deeply intertwined. Business continuity keeps the organisation stable while disaster recovery restores normal operations. I design them together – because that’s how they need to work.

What a Strong BCDR Programme Delivers

Operational Continuity

Critical systems stay available or recover within agreed timeframes

Cascading failures identified and mitigated before they cause extended outages

Recovery Confidence

Teams know exactly what to do, in what order, when a real incident occurs

Plans have been tested under realistic conditions — not just documented

Compliance Readiness

Demonstrable alignment with ISO 22301, NIST 800-34, and sector requirements

Audit-ready evidence and gap remediation in place

Stakeholder Trust

Clients, regulators, and partners see a mature, tested resilience capability

Internal teams have confidence in the programme and their own roles within it

In Practice: UN Agency, Geneva

A UN agency with global operations needed a DR programme that could be trusted — not just documented. Their existing plans had never been tested, and IT leadership had genuine concerns about whether recovery procedures would hold under real conditions.

Working through a full dependency mapping exercise, we identified over 30 previously undocumented critical interdependencies. Recovery orchestration was redesigned around these findings, and the programme was validated through a full interruption test — simulating real system failures with live infrastructure.

The result: a tested, trusted recovery programme. Estimated recovery time reduced by 40% through optimised sequencing. Zero unplanned failures during the full interruption test. Teams with genuine confidence in their own procedures.

Testimonial

Jon’s explanation and implementation of the layered framework was clear and thorough, and enabled us, in partnership, to develop a DR plan that not only identified and addressed previously unseen weaknesses, but resolved several operational concerns as well.

Disaster Recovery Team Leader

Organisation withheld

With the plan Jon helped us develop, we were able to recover successfully from a ransomware attack.

IT Manager

Organisation withheld

Jon’s guidance and the development of our DR plan enabled us to recover from a significant breach.

CIO

Organisation withheld

How We Work Together

  1. Discovery & Scoping
      • We start with a conversation, no forms, no questionnaires. I want to understand your organisation, your current state, and what a successful outcome looks like for you. From there I’ll propose a scoped approach.
  2. Assessment & Analysis
      • Business impact analysis, dependency mapping, and gap assessment against your current plans and applicable frameworks. This phase surfaces the issues that matter and prioritises the work ahead.
  3. Design & Development
      • DR strategies, recovery runbooks, BC plans, and governance frameworks — built collaboratively with your teams so they own the outcome, not just receive a document.
  4. Testing & Validation
      • Structured testing — from tabletop exercises to full interruption tests — to validate the plans and build confidence in the teams who will execute them.
  5. Ongoing Support & Improvement
      • DR programmes need to evolve as your infrastructure changes. I’m available for retainer-based ongoing support, annual reviews, and repeat testing cycles.

Ready to Build a DR Programme You Can Trust?

Whether you’re starting from scratch, stress-testing existing plans, or preparing for an audit, I’d welcome an initial conversation. No obligation — just a straightforward discussion about what you need and whether I can help.

Book a consultation
Read my book on DR