Topics in this domain
- Event vs Incident vs Breach
- Developing the Incident Response Plan
- Incident Response Team Roles and Authority
- Incident Classification and Severity Levels
- Incident Response Playbooks and Decision Trees
- Escalation and Communication Plans
- Business Impact Analysis
- RTO, RPO, MTD and Recovery Prioritisation
- Business Continuity Planning and Strategies
- Crisis Management and Continuity Governance
- Disaster Recovery Planning
- Recovery Sites: Hot, Warm and Cold
- Backup Strategies and Cloud DR
- Incident Response Training
- Testing Plans: Tabletop, Functional and Full Interruption
- Evaluating Exercises and Improving Readiness
- Security Event Detection and Monitoring Methods
- SIEM, the SOC and Event Correlation
- Threat Intelligence and Indicators of Compromise
- Incident Triage and Initial Investigation
- Evidence Preservation, Forensics and Chain of Custody
- Containment Strategies: Short-Term and Long-Term
- Making Containment Decisions
- Breach Notification and Regulatory Reporting
- External Communications: Customers, Media and Law Enforcement
- Eradication, Recovery and Return to Normal Operations
- Post-Incident Review and Root Cause Analysis
- Lessons Learned and Incident Trend Analysis
Disaster Recovery Planning
Getting IT back
When systems are lost, the disaster recovery plan (DRP) is the step-by-step recipe for bringing them back, in the order the business needs, within the time and data-loss limits set by the BIA. The DRP is part of the BCP and is aligned with the incident response plan. It should be written so a competent stranger could follow it.
What’s in the DRP
- Declaration: the criteria, and who may declare a disaster.
- Teams and roles, each with a deputy.
- Contacts: staff, vendors, carriers, the recovery site, insurers.
- Procedures in priority order, matching the BIA.
- Resources and backups: what’s needed and where it is.
- Return to normal: moving back to the primary site, not just failing over.
Recovery teams
Large plans organise recovery into teams: emergency action (people’s safety), damage assessment, emergency management (coordination and decisions), technical recovery teams, and relocation and salvage.
Recovering from a cyberattack
Cyber recovery is harder than recovering from a flood:
- Is the backup clean? Attackers may have been inside for weeks, so recent restore points may be infected.
- Is the attacker gone? Eradicate before restoring, or they’ll return.
- Rebuild, don’t just restore: critical systems such as identity services are rebuilt from known-good images.
- Credentials: reset passwords and keys, because the old ones may have been stolen.
Example. After ransomware, a company restores its domain controllers from last night’s backup. Within hours, encryption starts again: the attacker’s backdoor account was in the backup. The second recovery uses a clean rebuild of identity services and backups verified against the attack timeline.
Keeping the DRP usable
- detailed enough for someone other than the usual administrator
- deputies for every role
- copies offline and with key staff
- updated after system changes and tests
- covers the return to the primary site
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Basis for DRP priorities and timing | The BIA’s objectives (RTO and RPO) |
| Main extra risk in recovering from a cyberattack | Restoring infected backups, or the attacker still being present |
| Who can declare a disaster? | Authorised people named in the plan |
| How the DRP relates to the BCP | The DRP is part of the BCP |
| Where to keep DRP copies | Offline or offsite, accessible to the team |
In short
- The disaster recovery plan (DRP) restores IT systems, data and infrastructure within the RTOs and RPOs set by the BIA.
- It covers declaration, teams and roles, contacts, recovery procedures in priority order, resources and backups, and return to normal.
- The DRP is part of the BCP and aligned with the incident response plan, sharing triggers and contacts.
- Cyber recovery differs from natural disasters: backups may be infected, the attacker may still be present, and systems must be rebuilt clean.
- Procedures must be detailed enough for someone other than the usual administrator to follow, and every role needs a deputy.
- The plan is tested, updated after changes and incidents, and kept accessible offline.
Exam traps
- Restoring compromised systems from infected backups brings the attacker straight back.
- A DRP only the usual administrator can follow fails when that person is unavailable.
- The plan must cover returning to the primary site, not just failing over.
- Who may declare a disaster must be defined in advance.
Slides
Click the slide and use the arrow keys. F toggles full screen.
What's in the DRP
Recovery teams