Peak-Season Ransomware and an Untested Continuity Plan
Bluefin Outfitters sells outdoor clothing online, with €18 million in annual revenue and more than half of it in November and December. Its business continuity plan, written three years ago by an employee who has since left, states a recovery time objective of four hours for the order platform and an RPO of 15 minutes. In practice, backups run nightly to a SAN in the same room as the production servers, and the last copy sent offsite is nine days old. The plan references a server that was decommissioned last year and names a crisis team that no longer meets. On a peak Saturday, staff find ransom notes on the order database and the file server. The first suggestion in the incident call is to restore from backup immediately so the shop can reopen. The payment provider's contract requires notification of suspected card-data compromise within 24 hours.
1. Assess the stated RTO and RPO against the actual backup arrangements. What does the gap tell you?
Read the worked answer
The RPO is not achievable. An RPO of 15 minutes allows at most 15 minutes of lost transactions. Nightly backups mean up to 24 hours of orders and customer records can be lost, and the offsite copy was nine days old - so in a full-site loss the firm would lose nine days of business data. The stated RPO is off by two orders of magnitude.
The RTO is untested and therefore a hypothesis. Four hours requires known, documented restore steps, hardware or cloud capacity available on demand, and staff who have practised. A full restore from a SAN in the same room as the production servers is not a disaster recovery capability: whatever destroys the servers will probably destroy it. No restore appears to have been tested.
What the gap tells you: the plan was written as a document, not derived from a business impact analysis, and never validated. Objectives that are not tested are aspirations. Contradictions like this are exactly what a restore test and a tabletop exercise expose - cheaply, before a real event.
2. The first suggestion on the call is to restore from backup so the shop can reopen. Give the order of actions you would defend, and the reasoning for not restoring first.
Read the worked answer
Sequence:
- Contain: isolate affected hosts from the network, disable compromised accounts, and block command-and-control traffic. Reason: ransomware is still running; restoring into a live, infected network can re-encrypt the restored data.
- Preserve evidence: capture logs, memory and ransom notes before wiping anything. Reason: the payment provider's 24-hour notification clause requires knowing whether card data was reached; destroying evidence makes that judgement impossible.
- Establish scope and escalate: which systems and which data are affected, and who must be told. Activate the crisis team, including management, legal and communications.
- Notify: the payment provider within 24 hours of suspected card-data compromise, and follow GDPR and any other obligations; do not delay for complete certainty.
- Activate continuity: a manual or alternative ordering path so revenue continues while recovery proceeds.
- Restore last, and carefully: from a verified clean backup, in isolation, validated before reconnection.
Why not restore first: it destroys evidence, risks reinfection, and consumes the hours when notification and containment matter most. Speed matters, but uncontrolled speed converts an incident into a bigger one.
3. Name three changes to make before the next peak season and justify each with a continuity concept.
Read the worked answer
1. Rebuild backups on a 3-2-1 basis with an immutable or offline copy. Justification: the current backup shares a failure domain with production, so it does not provide recoverability for the scenario that matters. Test a restore quarterly and record how long it takes - that measurement is the only credible RTO.
2. Derive RTO and RPO from a business impact analysis owned by the business. Justification: continuity objectives must come from the maximum tolerable outage of the order platform during peak trading, not from a former employee's estimate. The analysis should identify dependencies (payment provider, hosting, courier integration) and revenue at risk per hour.
3. Exercise the plan and keep it alive. Justification: the plan referenced a decommissioned server and a crisis team that no longer meets. A tabletop exercise before November, with a named owner and a review date, plus a communication plan for customers and the payment provider, turns the document into a capability.
Optional fourth: a pre-agreed manual ordering fallback, so the shop can keep trading while recovery runs - continuity is not only about IT.