Business Continuity, Disaster Recovery and Resilience
Business continuity, disaster recovery and resilience examines how an organisation keeps critical services running through disruption and restores them in a defined order. The exam is heavy on business impact analysis metrics such as RTO, RPO and MTD, and on choosing recovery strategies that genuinely meet them rather than merely sounding robust.
The analysis chain
- A business impact analysis identifies critical processes, their dependencies on people, suppliers, systems and sites, and how impact grows with downtime.
- MTD is set by the business. RTO is the target time to restore a service and must be less than or equal to MTD.
- RPO defines acceptable data loss and drives backup frequency and replication mode.
- Recovery strategies are chosen to meet RTO and RPO: backup and restore, pilot light, warm standby, active-active, with cost rising as RTO falls.
Resilience and testing
Resilience reduces the chance of disruption: redundancy, diversity of providers and routes, graceful degradation, immutable backups and tested restores. Plans are worthless untested. Exercise types in increasing rigour are desk check, tabletop, simulation, parallel test, full failover and live game day. Record the RTO actually achieved against the target. Crisis management covers command structure, communications with staff, customers and regulators, and decision authority when systems are down.
Worked example
An order system must be restored within 4 hours (MTD 6, RTO 4) and may lose at most 15 minutes of orders (RPO 15 minutes). Nightly backups give an RPO of 24 hours and an 8-hour restore, failing both targets. A warm standby in a second region with asynchronous replication every 5 minutes and automated failover meets RPO 15 minutes and RTO under 2 hours at higher cost. The choice is justified by the BIA numbers, not by preference for a technology.
Traps
- Confusing RTO with MTD, or quoting backups as a strategy without a restore time.
- Assuming replication is a backup; it faithfully copies deletions and ransomware.
- Testing only the plan document, never an actual restore.
- Omitting third-party and cloud dependencies from the BIA.
Privacy, Data Protection and Legal/Ethical Issues
Privacy, data protection and legal and ethical issues tests whether you can handle personal data lawfully across its lifecycle and act ethically where the law is silent. Expect questions on data protection principles, controller and processor roles, breach notification, cross-border transfers, evidence handling and professional conduct.
Principles and roles
Common principles, GDPR-style and echoed in many national laws: lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation; integrity and confidentiality; accountability. A controller decides purpose and means; a processor acts only on documented instructions. A processor that goes beyond those instructions becomes a controller for that processing.
Operational obligations
- Establish a lawful basis before collection: consent, contract, legal obligation, vital interests, public task or legitimate interests. Consent must be specific, informed and withdrawable.
- Conduct a data protection impact assessment for high-risk processing such as new technology, large-scale monitoring or sensitive categories.
- Honour data subject rights: access, rectification, erasure, restriction, portability and objection, within statutory deadlines.
- Cross-border transfers need a mechanism: adequacy decision, standard contractual clauses or binding corporate rules.
- Notify the regulator of qualifying breaches, under GDPR within 72 hours of awareness where risk is likely, and notify individuals where risk is high.
Ethics and evidence
Professional codes require competence, confidentiality, integrity and due care. Responsible disclosure gives vendors time to fix before publication. When handling evidence, preserve integrity with hashes and a chain of custody, and stay strictly within authorised scope, since accessing systems beyond authorisation is a criminal matter regardless of intent.
Worked example
A marketing team wants to email a purchased contact list. The lawful basis is unclear: consent was not obtained by the organisation, and legitimate interests is hard to justify for cold prospecting under GDPR. The advice is not to send, but to collect first-party consent with a clear notice and a suppression list. If a small test send already happened, record it, assess the risk, and decide whether the 72-hour notification threshold is met.
Traps
- Treating anonymisation and pseudonymisation as identical; pseudonymised data is still personal data.
- Assuming a processor needs no written contract.
- Notifying every incident, or waiting for full forensic certainty before notifying.
- Ignoring retention schedules so data is kept just in case.