Business Continuity and Disaster Recovery for Cyber

For most Australian organisations, the single most likely cause of a serious operational outage is no longer fire, flood or hardware failure. It is a cyber incident. Ransomware, destructive attacks and supply-chain compromises can take core systems offline for days or weeks, yet many continuity plans still treat cyber as a minor variant of a natural disaster. That gap is where organisations get hurt.

Business continuity and disaster recovery planning for cyber is its own discipline. The defining difference is that in a cyber incident, the very systems you would normally rely on to recover, including backups, identity providers and management tools, may be the things the attacker has targeted. Planning that assumes a clean environment to recover into is planning that fails on the day.

Continuity and recovery are not the same thing

It is worth being precise about terms, because conflating them leads to plans that cover neither well. Business continuity keeps critical business functions operating during a disruption, often through manual workarounds, alternate sites or degraded modes of working. Disaster recovery is the technical process of restoring IT systems, data and infrastructure to a working state.

You need both, and they operate on different clocks. While DR teams work to rebuild domain controllers and restore databases, the business needs a way to keep serving customers, paying staff and meeting statutory obligations. If your only plan is “restore the systems”, you have no answer for the hours or days before those systems return.

Get your RTO and RPO right before anything else

Two numbers anchor every recovery decision: Recovery Time Objective and Recovery Point Objective.

• Recovery Time Objective (RTO) is the maximum tolerable downtime for a given system or process before the impact becomes unacceptable.
• Recovery Point Objective (RPO) is the maximum tolerable data loss, expressed as the time gap between your last recoverable backup and the moment of failure.

These should not be guessed by IT in isolation. They emerge from a business impact analysis that asks each business owner what an outage actually costs in revenue, safety, reputation and compliance terms. A payroll system might tolerate a 24-hour RTO but a near-zero RPO, because losing a day’s pay data is catastrophic while a day’s downtime is survivable. A customer-facing portal might be the reverse. Mismatching the engineering to the real objectives wastes money on systems that do not need it and underprotects the ones that do.

Be realistic. An aggressive RTO of minutes requires hot standby infrastructure and continuous replication, which is expensive. A relaxed RTO of days can be met with restore-from-backup approaches at a fraction of the cost. The discipline is matching investment to genuine business need, tier by tier.

Run a business impact analysis you can defend

The business impact analysis (BIA) is the unglamorous work that makes everything downstream credible. Done properly, it produces a ranked list of business processes, the systems and data each depends on, the people and third parties involved, and the cost of losing each one over time. That last point matters: impact is rarely linear. A four-hour outage of an order-processing system might be a nuisance, while a two-day outage of the same system threatens contracts, cash flow and reputation. Capturing how impact escalates with time is what lets you set defensible objectives rather than arbitrary ones.

A good BIA also surfaces hidden dependencies that wreck recovery plans. A “tier-two” application may turn out to feed a tier-one process. A critical system may depend on an authentication service, a licensing server or a third-party API that nobody listed. Map these chains explicitly, because in a real recovery you must restore in dependency order, and the surprises always arrive at the worst time. Where critical functions rely on external providers, your continuity plan is only as strong as theirs, which makes supplier and third-party due diligence part of resilience rather than a separate procurement exercise.

Plan for an environment you cannot trust

This is the cyber-specific part that generic continuity templates miss. In a ransomware or destructive incident, you must assume that production infrastructure, administrative credentials and even some backups are compromised. Effective cyber recovery planning therefore includes:

• Clean, isolated recovery copies that are immutable or air-gapped, so they cannot be encrypted or deleted by an attacker who has reached your network.
• A documented rebuild order that recovers identity and core security services first, so you are not restoring applications into a still-compromised environment.
• Out-of-band communications, because your email and chat platforms may be down or untrusted during the incident.
• Pre-agreed decision authority for actions like isolating networks, taking systems offline or engaging external responders, so nobody waits for an unreachable executive.

Your backup strategy is the foundation here, and it deserves its own attention. A resilient approach following the 3-2-1-1-0 model, with immutability and verified restores, is what separates a multi-week ordeal from a controlled recovery.

Write runbooks people can actually follow

A continuity plan that lives in a 90-page document nobody has opened is not a plan. Under pressure, responders need concise, role-specific runbooks: who declares an incident, who is called, what gets isolated, in what order systems are recovered, and how decisions are recorded. Keep them short, current and available offline, including printed copies, because a network outage may take your document store with it.

Map your runbooks to the controls many Australian organisations are already expected to maintain. The regular backups and tested restoration requirements within the Essential Eight dovetail directly with recovery planning, and for regulated entities the resilience expectations of frameworks like APRA CPS 234 make tested recovery a compliance obligation, not just good practice.

Test, or you do not really have a plan

The uncomfortable truth is that most recovery plans fail their first real test because they were never properly exercised. Testing should happen at several levels:

1. Component restores: quarterly, prove you can actually restore critical systems from backup within their RTO, not just that backups exist.
2. Tabletop exercises: twice yearly, walk leadership and technical teams through a realistic ransomware scenario and surface the gaps in decision-making and communication.
3. Full failover exercises: at least annually for tier-one systems, demonstrate end-to-end recovery into a clean environment.

Record what breaks, assign owners and fix it before the next cycle. The goal of a test is to fail in the rehearsal so you succeed in the real event. Test results also provide the evidence regulators, auditors and insurers increasingly demand.

One discipline elevates testing from theatre to genuine assurance: inject realistic constraints. Run the exercise as if the primary administrator is on leave and unreachable, as if the main data centre is the thing that is down, or as if the first backup you reach for is corrupted. These are the conditions that real incidents impose, and a plan that only works when everything else is intact has not been tested at all. Capture the recovery times you actually achieve and compare them honestly against your stated RTOs; the gap between the two is your remediation backlog.

Common failure points to design out

Across the incidents organisations actually suffer, the same weaknesses recur. Designing them out in advance is far cheaper than discovering them mid-crisis.

• Recovery credentials stored only in the systems being recovered, so the password manager or documentation you need is itself encrypted or offline. Keep break-glass credentials in a secure, separate, offline location.
• Single points of knowledge, where only one person understands how a critical system is rebuilt. Document and cross-train before that person is on a plane or unavailable.
• Untested third-party dependencies, where a supplier’s outage cascades into yours and no alternative has been arranged.
• No plan for partial operation, treating recovery as all-or-nothing rather than restoring the most critical functions first and degrading gracefully.

Where this fits in your wider security posture

Business continuity and disaster recovery are not standalone projects; they are part of an integrated resilience programme that also includes prevention, detection and response. Many mid-sized organisations lack the in-house leadership to pull these threads together, which is where a virtual CISO can help: setting realistic objectives, prioritising investment and ensuring the plan is tested rather than shelved. If you operate in regulated industries or the public sector, the recovery obligations are sharper still, and tailored guidance for government and council environments or the private sector is worth seeking early.

If a cyber incident has already disrupted your operations, or you want an honest assessment of whether your recovery plan would survive contact with reality, CISO Advisory provides Australia-wide support, on-site same day or next business day. You can reach us on 07 2112 8502 at any hour, or through our contact page. The best time to build a defensible recovery capability is well before you need it.