10 Recover? Business Continuity and Incident Management
When (not if) the region goes dark, the runbook you never tested is the plan you actually have.
🗂️ Tessera Case: When the region fails
Full access has changed the kinds of question you can ask. At the outset of the engagement you would have been grateful for a continuity policy to read; now you ask to see the failover runbook and the result of the last time it ran. Tessera’s CTO points you to a 47-page business-continuity plan and a diagram showing a primary region, a standby region, and an RTO of four hours. It looks exactly right. So you ask the only question that matters: when did you last fail over, and what happened? Pause for the answer and request the record. Silence tells you nothing reliable about whether the recovery capability works.
10.1 The break that is coming
Continuity and incident management are the controls that assume failure. A mature organisation treats the question as when, not if: AWS regions fail, databases corrupt, ransomware encrypts, a contractor clicks the link. The discipline here is to survive those events, and to prove you can.
ISO/IEC 27001:2022 treats this seriously, and mostly inside the large organizational family. Information security during disruption (A.5.29) and ICT readiness for business continuity (A.5.30) are the two continuity controls, the latter new in the 2022 edition and worth a section of its own. Incident management is a five-control cluster: planning and preparation (A.5.24), assessment and decision on security events (A.5.25), response (A.5.26), learning (A.5.27), and collection of evidence (A.5.28). NIST CSF 2.0 gives the work two whole functions of its own: Respond (RS) and Recover (RC). The ASD Essential Eight, for its part, folds the same intent into its eighth and most underestimated mitigation: regular backups.
The posture shift of Act II matters here more than anywhere. In Act I you read the continuity policy and noted, correctly, that its design looked complete and that you could not tell whether any of it operated. Now you hold the runbook, the test schedule, the incident log, the backup configuration, and the people who would actually run it at 2am on a Sunday. The polished plan finally meets its evidence.
10.2 RTO and RPO: derived, not picked
The Recovery Time Objective (RTO) is a target interval for restoring the specified service after disruption. Define the start event and what counts as restored service. The Recovery Point Objective (RPO) specifies how far back in time the recovered data may be relative to the disruption.
Keep these separate from maximum tolerable disruption, the business-impact limit beyond which consequences become unacceptable. An RTO should leave room for required business resumption within that limit. A restored database alone may not constitute a restored service.
A business-impact analysis identifies affected processes, dependencies and the consequences of interruption over time. It informs targets alongside commitments, feasible strategies and authorised risk decisions. Targets must be agreed and supported; a generic “industry standard” number is not a derivation.
E08 supplies the signed criteria for this exercise: RTO four hours, RPO fifteen minutes and maximum tolerable disruption eight hours. The contract separately promises 99.9% monthly availability. In a 30-day month, 0.1% is 43.2 minutes, before applying the contract’s exclusions. A four-hour qualifying outage would exceed that monthly budget. It does not follow that the SLA automatically sets an RTO of 43.2 minutes: examine service definition, exclusions, remedies, business impact and risk acceptance.
The auditor should make that exposure visible. Ask whether management understands the consequences of a recovery that meets its RTO yet misses its availability commitment. Do not silently alter either criterion to reconcile them.
An illustrative draft changes the case’s RPO to one hour because that is a plausible SaaS target. E03 and E08 say fifteen minutes. Restore the agreed criterion before evaluating the test. A second draft concludes that a five-and-a-half-hour restore meets the four-hour RTO because it is below the eight-hour disruption limit. That confuses a recovery target with a business-impact ceiling.
10.3 How you test a plan: tabletop, simulation, failover
A plan that has never been exercised is a draft. ISO/IEC 27001 expects continuity controls to be tested, and the discipline in Act II is to establish not just that a test happened but that it tested the right thing at the right depth. Testing falls along a spectrum, and the deeper you go, the more it costs in time and risk, and the more it proves.
Tabletop is a paper walkthrough. The team sits in a room, or on a call, and talks through a scenario: “Sydney is down, here is the runbook, what do you do?” It tests understanding, roles, decision rights, and whether the runbook reads the way someone under stress would need it to. It costs almost nothing, and it reliably surfaces the first category of problem: the plan nobody has read, the contact list with last year’s phone numbers, the approval step that names a person who left the company. A tabletop can support conclusions about understanding and decision paths under the exercise conditions. It does not demonstrate technical restoration throughput or data integrity.
Simulation raises the stakes. The team runs a scenario against a realistic but non-production environment, with some actual mobilisation: pages go out, an incident channel opens, people log in to the recovery systems. Simulation tests the process under load: how fast the team assembles, how the runbook holds when the steps are real, where the confusion lives. It still does not touch production, which is what makes it the workhorse test for most organisations, run once or twice a year.
Failover is the real thing. The service is actually moved to the recovery environment, either in parallel with production or, in the most demanding form, by interrupting production to force the switch. A well-designed failover test can provide integrated evidence: that the standby database really has the data, that DNS really reroutes traffic, that the application really starts in the standby region, that the RTO is achievable and the RPO holds. It is also the test organisations avoid, because it is expensive, it is risky, and it can break the very thing it is meant to protect. So they do not run it, and then they tell you it would work.
An isolated restore can also test technical claims, including backup usability, throughput and application checks. State what it omits, such as production routing or live dependencies. A more disruptive test is not automatically better evidence for every question.
Agree the environment, authority, rollback, stop conditions and acceptable business impact before any exercise. The auditor requests and observes authorised tests; this book does not authorise readers to fail over production. The speed of a witness’s answer is not a substitute for the test record.
10.4 The region-failure audit
🗂️ Tessera Case: The failover that has never failed over
E08 resolves the book’s scenario version. Its signed BIA and policy set the targets. A draft diagram depicts a hot standby that the deployment inventory does not contain. The actual runbook uses a cold restore. That discrepancy needs correction, but absence of a standby alone does not prove recovery impossible.
The isolated exercise starts at 10:00 and passes application/dependency checks at 15:30. Elapsed time is 5 hours 30 minutes, exceeding the four-hour RTO by 1 hour 30 minutes. The latest usable backup contains data through 09:20, so the recovery-point gap at interruption is 40 minutes, exceeding the fifteen-minute RPO by 25 minutes.
The restored copy passed its supplied integrity checks. That positive result belongs in the record. It does not cancel the missed targets, untested production cutover and untested key-service dependency. Nor does a non-production result establish exactly how long a real regional incident would last.
Record F04, high under E02: the supplied recovery exercise misses P-REC’s targets and leaves material dependencies unverified. No later successful test exists in the case. Management’s planned July exercise is an action, not evidence of closure.
Multiple availability zones can reduce exposure to a zone failure while leaving regional dependencies. Inspect where the usable backups, replicas, keys and recovery tooling reside and what failures they are designed to survive. A cold restore can be a valid strategy if it meets the agreed objectives and is adequately tested. A diagram alone establishes neither deployment nor recoverability.
10.5 Incident response: the lifecycle you audit
Continuity is the slow failure: the region is down, we recover. Incident response is the fast one: we are under attack, or something is wrong, right now. The two share people and overlap in practice, because every incident has a recovery phase, but they answer different questions and they audit differently.
The familiar four-phase model, preparation; detection and analysis; containment, eradication and recovery; post-incident activity, comes from SP 800-61 Rev. 2. Revision 3, published in April 2025, superseded it and integrates incident response throughout CSF 2.0 risk management. The older phase names remain a useful historical teaching aid, not the current publication’s structure. Related ISO/IEC 27001:2022 control areas can guide evidence requests without implying exact equivalence: A.5.24 is preparation, A.5.25 is the assessment that decides an event is an incident, A.5.26 is the response, A.5.27 is learning, and A.5.28 is the evidence you collect along the way, increasingly load-bearing when the incident touches personal data and the Notifiable Data Breaches clock from chapter nine starts running.
The desk audit in Act I could confirm the IR plan existed and named a team. Act II asks whether it operates, and the test is the same as everywhere else: trace real events through the lifecycle. Ask for the last two or three security incidents and walk each one forward. Was it detected, by what, and how fast? Was it triaged and severity-assigned against the defined scale? Was the plan invoked, and is there a record of who did what and when: the incident channel, the paging history, the incident bridge notes? Was containment applied, and was the eradication complete or merely cosmetic? Was recovery validated before the incident was closed? And the step organisations skip most: was there a post-incident review, and were its action items tracked to closure, or did they die in a spreadsheet?
The single most revealing test is the gap between events and incidents. Pull the security event log over the same window as the incident register and compare them. If the alerts fired and nothing was triaged, detection exists but response does not, and the control is broken in the place nobody looked. A plan that handles declared incidents beautifully while the queue of undeclared ones piles up is a control that works on paper and fails in practice.
As a method extension, consider an organisation that connects cloud detection findings to automated response. The fixed case supplies no detector-evaluation or auto-remediation test, so this example adds no successful control result to Tessera’s opinion. This is the modern shape of incident response, and it raises a question the lifecycle does not answer on its own: when a machine decides an event is benign, or fires a response on one, can you trust it?
The audit moves in two directions. First, tune and coverage: what is the false-positive rate, what classes of threat are in scope and (crucially) out of scope, and who reviews the detection logic and how often? An untuned detector drowns the team in noise until they mute it, which is functionally identical to having no detector at all. Second, the human-in-the-loop boundary: which automated actions run without approval, and is that list defensible? Endpoint quarantine can interrupt clinical, industrial or business-critical work. Assess each action’s authority, blast radius, reversibility, dependencies and stop conditions; neither quarantine nor a production shutdown is universally safe. Ask to see the action that fired, the model’s confidence, and the human review that followed. If the response was fully automated with no record, the control ran, but nobody can tell you whether it ran correctly. An AI that reports “all clear” is still a judgement, and a judgement with no reviewer is an unattended control.
10.6 ICT readiness for business continuity
A.5.30, ICT readiness for business continuity, is a 2022 addition, and it deserves to be named because it is easy to read past and because it does work the older “information security during disruption” control does not. A.5.29 says the organisation must keep information security working during a disruption: controls do not switch off because you are in a crisis. A.5.30 says something more demanding: the ICT services themselves must be ready to meet the continuity objectives the business has set. It forces the join between the BIA’s numbers and the technology that has to hit them, and that join is exactly where Tessera’s plan falls apart.
Readiness is a property you can test. It asks whether the chosen hot, warm or cold recovery strategy meets the objectives; whether the data replication actually runs and within the RPO; whether the runbook matches the infrastructure that is really there; and whether the people who would execute it have rehearsed. NIST SP 800-34 and ISO 22301 give the broader contingency and continuity disciplines their proper home, and ISO/IEC 27031 is the one aimed squarely at ICT readiness. For an auditor, A.5.30 collapses all of that into a single testable question: if the disruption happened today, on the estate as it actually stands, would the ICT services meet the objectives? For Tessera, the supplied exercise misses the agreed targets, and dependencies remain untested. That is the supported conclusion.
10.7 The question, answered
The supplied cold restore recovered an integrity-checked copy but missed both agreed targets. Production cutover and a key-service dependency remain unverified. F04 stays open; the evidence does not justify a promise of four-hour regional recovery.
E05 separately supplies one incident chronology and a privacy-adviser assessment. Trace detection, containment state, assessment and notification using those records. It does not establish that every incident in the period was identified or handled effectively.
Time: 25 minutes. No AI required. Recompute E08’s elapsed restoration time, recovery-point gap and SLA budget. Compare each with its own criterion. State one supported success and two limitations. Add F04 and its closure evidence request, then trace INC-01 from E05 without inventing additional incidents.
The next chapter turns the tested conditions into findings and an explicit closure ledger.