6  Incident & Disaster Planning

The question isn’t whether something will go wrong, but whether you’re ready when it does.

At Harbour, an unexpected login prompt and a bulk-export event arrive within minutes of each other. Who can suspend access, preserve the logs, talk to the service provider and decide what the centre tells participants? This chapter turns those questions into a response plan. Preparation and recovery tests belong before the first incident.

6.1 What this chapter covers

By the end you should be able to:

• Distinguish incident response, business continuity, and disaster recovery.
• Explain RTO and RPO and why they drive the plan.
• Describe what a good incident response process looks like (detect → respond → recover → learn).
• Explain the role of backups, alternate sites, and testing the plan.

6.2 When prevention runs out

Patching and access controls lower the chance of compromise. Detection, response and recovery reduce harm when prevention fails. They also help with mistakes and outages unrelated to an attacker.

Preparation means deciding authority, keeping contact information available, and testing recovery while there is time to correct a failure. A response plan should work when the usual administrator is absent and the primary communication system is unavailable.

6.3 Incident response: the lifecycle

An incident involves an actual or imminent threat to security. A suspicious event needs triage; staff should not wait for certainty before reporting it. A response process turns incomplete observations into proportionate action:

• Detect and assess. Record the observation, time and affected service. Decide urgency and scope, distinguishing facts from assumptions.
• Respond. Contain damage under assigned authority. Preserve useful evidence where feasible while restricting compromised access. Record actions that change or destroy evidence and why they were necessary.
• Recover. Address the cause and persistence, restore or rebuild from an acceptable state, and validate access and integrity before reconnecting. A successful restore is not proof the attacker has been removed.
• Learn. Review controls, decisions and communication. Assign improvements and check that they are completed.

These activities overlap. Evidence collection and analysis begin during response, not only after restoration. Do not indiscriminately wipe a system before consulting the response lead; equally, do not leave serious harm continuing solely to obtain perfect evidence. NIST SP 800-61 Rev. 3 places incident response within continuing risk management.

Two things make or break response in practice, and neither is technical. Roles must be decided in advance (who declares an incident, who talks to whom, who has the authority to take a critical system offline), because a crisis is the worst possible time to be working out the org chart. And communication must be planned: internal coordination, and the harder question of what you tell customers, regulators, and the public, and when.

6.4 Business continuity and disaster recovery

Two related disciplines sit alongside incident response, and people constantly confuse them.

Business continuity is the big picture: keeping the organisation running during a serious disruption of any kind, not just a cyberattack. If the office floods, the payroll system dies, or ransomware locks every file, how does the business keep serving customers and paying staff? It covers people, processes, premises, and priorities, the whole organisation’s ability to function through a crisis.

Disaster recovery is the technical subset of that: restoring the IT systems and data after they’ve been lost or damaged. Business continuity asks “how does the company keep operating?”; disaster recovery asks “how do we get the systems and data back?” Recovery serves continuity (you restore the systems so the business can continue), but they are not the same plan, and an organisation needs both.

6.5 The two numbers that drive the plan: RTO and RPO

Disaster recovery turns on two deceptively simple targets, and getting them straight is the most useful thing in this chapter.

Recovery Time Objective (RTO) is the target elapsed time for restoring an agreed service level after disruption. Set it within the organisation’s maximum tolerable disruption, allowing for dependencies and validation. A trading platform’s RTO might be minutes; an internal wiki’s might be days.

Recovery Point Objective (RPO) is how much data you can afford to lose: the maximum tolerable gap between your last good backup and the moment of failure. An RPO of one hour means you can lose at most an hour’s work; an RPO of a day means losing a day’s is acceptable.

The RPO constrains your recovery design, including backup or replication frequency and the availability of usable recovery points. This is where plans contradict themselves. If a company declares an RPO of one hour but backs up only once a night, the plan is broken on its face: a failure just before the nightly backup could lose nearly twenty-four hours of data, not one. The stated goal and the actual practice don’t match, and no one notices until the day it matters. Test the gap using a failure time near the end of the backup interval. A copied but corrupt or compromised backup does not meet the target. NIST’s contingency-planning guidance helps distinguish recovery objectives from tolerable disruption.

6.6 Backups and alternate sites

Backups support recovery. The 3-2-1 rule of thumb means three copies, on two types of media, with one off-site. Geographic separation protects against a local disaster. Offline or appropriately immutable protection addresses a different problem: an attacker modifying or deleting backups.

An off-site copy reachable with the same compromised administrator account may still be lost. Separate administration, retention controls and tested restoration matter. Check that recovery documentation and required keys remain available during an outage. Neither a backup job’s success message nor a provider’s promise substitutes for an observed restore test.

Good backups can reduce pressure to pay for decryption. They do not erase data already stolen, resolve legal obligations or guarantee a clean recovery. CISA’s ransomware guide covers prevention, data theft and recovery together.

For systems that can’t tolerate much downtime, recovery relies on an alternate site, a second location ready to take over. These come in flavours by cost and readiness: a hot site is fully equipped and running, ready in minutes; a cold site is just space and power you’d have to build out, cheap but slow; a warm site sits in between. Which you choose is a risk-and-cost decision: the cost-benefit reasoning of the previous chapter, applied to recovery.

6.7 The clock and the crowd

A response plan needs separate owners for technical recovery, communication and legal assessment. Do not promise that “every breach has a 72-hour clock”. Under GDPR, the controller’s regulator-notification deadline generally runs from awareness of a personal-data breach, with a risk-based exception; communication to affected people has a different threshold. Australia’s NDB scheme uses its own coverage, serious-harm and assessment rules. Web Security and Data Protection sets out the distinction and primary sources.

Record when relevant facts became known and escalate promptly to the responsible adviser. Investigation may continue while notification duties are addressed. Customers need accurate information about what is known, what is uncertain and what they should do.

A ransom demand adds pressure. Payment does not guarantee restored data or deletion of stolen copies, and legal restrictions may apply. The authorised decision-makers need technical and legal advice for the actual circumstances. This book’s exercises do not ask the reader to negotiate or decide a real ransom payment.

6.8 Testing the plan

One rule outweighs all the rest: an untested plan is only a hope. Recovery plans fail at the moment they’re needed for depressingly ordinary reasons: the backups were running but never restored-tested and turned out to be corrupt; the recovery documentation was itself on the system that went down; the one person who knew the process had left. Every one of these is caught by rehearsing: restoring from backups for real, running tabletop exercises, walking the team through the crisis while it’s still hypothetical. The organisations that recover smoothly are the ones that practised; the ones that discover their plan’s flaws during the real disaster paid the worst possible price for the lesson.

TipPlay it

Incident Zero has two modules that live in this chapter. Incident Response races you to uncover a hidden attack chain before time and budget run out; Disaster Recovery drops you into a live breach with a 72-hour notification clock and the ransom decision on the table. Reading about incident response is one thing; running one against a clock is another. → incidentzero.retroverse.studio

6.9 Where this connects

This chapter is what you do when a risk from risk management happens anyway, and the hot, warm, and cold-site choice is that chapter’s cost-benefit reasoning applied. Investigation starts alongside containment; its evidence and attribution methods are taken up in cybercrime, botnets and forensics. And the breach-notification obligations here are grounded in the data-protection law of web security and data protection.

6.10 Questions to consider

1. What’s the difference between business continuity and disaster recovery? Give an example of each.
2. A company backs up nightly. Their RPO is “no more than one hour of data lost.” What’s wrong, and what would you change?
3. Why do so many disaster-recovery plans fail at the moment they’re needed? What single practice would most reduce that?

6.11 Rehearse the first decisions

Use Harbour’s evidence cards for a 15-minute paper tabletop. Decide who acts at 09:15, 09:20 and 09:25; distinguish reporting from attribution. Calculate the rehearsal’s recovery time and both printed recovery-point gaps. State what still needs checking before reconnecting. Success requires preservation alongside containment and separate treatment of exported data.

Case inputs and checks: Harbour dossier.