Business continuity and IT DR planning
A continuity plan that has been tested against a bad day.
Continuity plans are often written once for an audit. When an outage or a cyber attack hits, nobody has rehearsed them and the recovery order is guesswork. We work out what the business needs back first, write the IT recovery plans, and test them with the people who will use them.
See backup and disaster recovery
What we deliver
- A business impact analysis for IT: which services matter most, and what an outage of each costs the business
- Recovery objectives for each service: how much data it can lose and how quickly it must be back
- IT disaster recovery plans and runbooks, with the order of recovery and the dependencies
- Scenarios that matter now: ransomware, loss of a site, loss of a key provider, loss of Microsoft 365 or Azure in a region
- Tabletop exercises with your leadership and IT team
- A gap list where the current backup and DR design can't meet the objectives
How it runs
- Analyse: workshops with business owners to agree priorities and recovery objectives.
- Plan: recovery plans and runbooks written against the real environment.
- Exercise: a tabletop exercise walks through a realistic scenario and tests decisions, communications and the plan.
- Fix: gaps turned into a remediation plan for backup, DR and process.
From plan to proof
A plan proves little until recovery has been tested. The backup and disaster recovery service runs restore and failover tests against the objectives agreed here, so you have evidence rather than assumptions. For APRA-regulated entities, the work supports CPS 230 tolerance levels and testing against severe but plausible scenarios.
Questions buyers ask
Do you write the whole business continuity plan?
We focus on IT: the impact analysis for IT services, recovery objectives and the IT recovery plans. We work alongside whoever owns the wider business continuity plan.
What is a tabletop exercise?
A facilitated session where your leadership and IT team walk through a realistic scenario, such as ransomware, and make the decisions they would make on the day. It shows where the plan and the roles need work.
How often should we test?
At least once a year for the plan as a whole, and after major changes. Restore testing for critical systems should happen more often.
Does this satisfy APRA CPS 230?
It provides much of the IT evidence CPS 230 expects: critical operations mapped to systems, tolerance levels and tested recovery. Your risk team decides how it fits your overall program.
What happens after the plan is written?
Gaps are fixed as projects, and the backup and disaster recovery service keeps the plan tested and current.
Start a conversation
Rehearse the bad day before it arrives.
Tell us when your continuity plan was last tested.
Talk to an Engineer