Topics in this domain
- Enterprise Architecture and IT Risk
- Change Management Risk
- Assets, Configuration and Dependencies
- Incident and Problem Management Oversight
- Project Governance and IT Risk
- Governing the Secure SDLC
- DevOps, CI/CD and Agile Delivery Risk
- Testing, Release and Deployment Risk
- Data Classification, Ownership and Handling
- Data Lifecycle: Integrity, Retention and Disposal
- Business Continuity Planning and Governance
- Disaster Recovery and Testing Recovery Capability
- Emerging Technology Risk: Cloud, IoT and OT
- AI and Machine Learning Risk
- Setting Risk Boundaries for Innovation
- Core Security Concepts: CIA, IAM, Cryptography and Network Security
- Security Frameworks and Control Standards
- Security Awareness Culture and Measuring Training
- Privacy Governance and Data Protection Principles
- Developing a Data Protection Control Strategy
Disaster Recovery and Testing Recovery Capability
Objectives drive the solution
- The recovery time objective (RTO) decides how fast systems must return.
- The recovery point objective (RPO) decides how much data loss is acceptable.
Faster recovery costs more, so options should match the objectives from the BIA.
Recovery sites
Testing recovery
Example. A DR test brought the core application up in two hours, but staff couldn’t log in: the identity service only existed at the primary site. The plan was updated to recover identity first, and the next test passed.
What a good test proves
- The objectives (RTO, RPO) were met.
- People knew their roles.
- Dependencies came up in the right order.
- Data was complete and consistent.
- Issues were logged and fixed.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| What drives recovery site choice | RTO and RPO from the BIA |
| MOST significant DR weakness | The plan hasn’t been tested |
| Least disruptive test | Checklist review or walkthrough |
| Test reveals problems | A useful result; fix and retest |
In short
- RTO decides how fast systems must return; RPO decides how much data loss is acceptable.
- Faster recovery costs more; recovery options should match objectives from the BIA.
- Recovery sites range from mirrored and hot to warm and cold; cloud DR can play any of these roles.
- Tests progress from checklist and walkthrough to simulation, parallel and full interruption.
- An untested plan can't be relied on; test results and fixes feed back into the plan.
Exam traps
- Choosing a recovery site before setting RTO and RPO.
- Assuming backups work without restore testing.
- Running a full interruption test before simpler tests have succeeded.
- Forgetting dependencies such as identity, DNS and network at the recovery site.
Slides
Click the slide and use the arrow keys. F toggles full screen.
Objectives drive the solution
Recovery sites
Testing recovery
ExampleA DR test brought the core application up in two hours, but staff couldn't log in: the identity service only existed at the primary site. The plan was updated to recover identity first, and the next test passed.
1 / 8