Disaster Recovery and Continuity Review
A continuity plan that has never been tested is a document, not a capability. We review the plan against the recovery the business actually requires, verify that backups restore rather than merely report success, and report the distance between the documented position and the real one. This is an independent review rather than an implementation engagement, which matters where the environment is managed by somebody else.
1
Impact
What downtime costs
2
Objectives
RPO and RTO agreed
3
Verify
Backups actually restore
4
Plan
Currency and dependencies
5
Report
Gap to the objective
How We Review
01
Business Impact Assessment
Recovery priorities are a business decision that is routinely left to IT by default. We establish with management what each process costs per hour of downtime and in what order systems have to come back, because an IT led recovery sequence rarely matches the operational one.
- Critical process identification with management
- Cost and consequence of downtime per process
- Required recovery sequence for a full outage
- Interdependencies between processes and systems
02
Recovery Objectives Assessment
We compare the recovery objectives the business needs against what the current arrangement can actually deliver. The gap between the two is usually the single most useful output of the review.
- Documented RPO and RTO per system
- Technical capability tested against each objective
- Gap analysis between required and achievable
- Cost implication of closing each gap
03
Backup and Restore Verification
A backup job reporting success proves the job ran. We verify by restoring, because corrupt backups, incomplete application aware backups and expired retention are only discovered at restore time.
- Backup configuration against documented objectives
- Observed restore of a sample of systems
- Verification that restored data is usable
- Retention and offsite copy verification
04
Continuity Plan Review
We assess whether the plan could be followed by somebody who did not write it, at three in the morning, without the author available. Plans naming individuals who left years ago are common.
- Plan currency, ownership and approval date
- Contact lists, escalation paths and authority to invoke
- Dependency on named individuals
- Alternative site, remote working and manual workarounds
05
Test Observation and Reporting
Where a disaster recovery test is scheduled we observe it rather than accept a report of it. Findings are written with the control weakness underneath, and rated by the exposure they leave.
- Observation of a live or simulated DR test
- Actual recovery time measured against the objective
- Findings rated by residual exposure
- Remediation roadmap with owners and dates
What You Receive
- Business impact assessment with prioritised recovery sequence
- Recovery objectives compared to demonstrated capability
- Restore verification results with evidence
- Continuity plan review and currency assessment
- Findings rated by residual exposure
- Remediation roadmap with owners and due dates
Indicative Timeline
A continuity review normally takes two to four weeks. Restore verification is the step that extends it, because it depends on when a test window can be arranged around operational commitments.
- Business impact interviews: one week
- Documentation and configuration review: one week
- Restore verification and test observation: scheduled around operations
- Reporting and management comment: one week
What We Assess Against
Continuity is reviewed against recognised standards as well as against the objectives your own business has set.
ISO 22301
The business continuity management standard, used as the structural benchmark for the plan itself.
ISO/IEC 27031
ICT readiness for business continuity, covering the technology side specifically.
King IV
Principle 11 and 12, where resilience and technology governance sit with the governing body.
COBIT 2019
Managed continuity as a defined objective with measurable practices rather than a document.
MFMA and PFMA
Public sector obligations for safeguarding assets and maintaining service delivery.
Recovery Objectives
Your own agreed RPO and RTO, which are ultimately the standard everything is measured against.
Frequently Asked Questions
We have backups. Is that not enough?
Backups are one component. Continuity also requires knowing what to recover first, having somewhere to recover to, having people who know the procedure, and having proven the restore works. Organisations with excellent backups and no tested plan still lose days.
Is this the same as your Managed ICT backup service?
No, and deliberately so. This is an independent review of an arrangement, whoever operates it. Where we manage the environment ourselves we cannot also review it independently, so the two are alternative engagements for any given client.
Do you actually test the restore, or review the reports?
We observe a restore. Reviewing backup success reports establishes only that a job completed. Where a restore cannot be arranged during the engagement we say so explicitly in the report rather than implying verification we did not perform.
What is a realistic recovery time objective?
It depends entirely on what downtime costs you. Four hours is expensive to achieve and unnecessary for many processes. Twenty four hours is achievable for most systems at moderate cost. The point of the impact assessment is to make that a business decision rather than a technical default.
How often should a DR test be run?
Annually as a minimum for a full exercise, with more frequent restore testing of individual systems. Anything less frequent and the plan drifts out of step with an environment that changes continuously.
Will this help with our audit findings?
Continuity and backup findings are common in public sector ICT audits, and they repeat because the remediation is usually documented rather than demonstrated. A review with observed restore evidence gives you something an auditor can actually rely on.
Related Services
This sits inside our ICT Audit practice. Related work: Backup and Disaster Recovery if you want the capability built and operated rather than reviewed, and Cyber Security Assessments for the ransomware scenario recovery most often has to survive.
