PECB Certified Lead Disaster Recovery Manager study materials
PECB Certified Lead Disaster Recovery Manager study resources

PECB Certified Lead Disaster Recovery Manager cheat sheet

PECB Certified Lead Disaster Recovery Manager · Keep the key ideas within reach.

Quick reference

Disaster Recovery Concepts and Principles

  • Disaster recovery (DR) restores prioritized technology and data services after disruption; business continuity (BC) sustains critical business functions, so DR is a subset of the wider BC management system (ISO 22301).

  • Recovery Time Objective (RTO) = maximum tolerable time to restore a service after disruption; Recovery Point Objective (RPO) = maximum tolerable data loss measured backward from the incident, expressed in time.

  • Maximum Tolerable Downtime (MTD) = maximum period a function can be unavailable before unacceptable harm; MTD must be greater than or equal to the sum of RTO plus time to detect and respond.

  • Recovery Time Actual (RTA) is measured restoration time from exercises; a strategy is acceptable only when RTA is consistently below RTO.

  • Availability = MTBF / (MTBF + MTTR), where MTBF is mean time between failures and MTTR is mean time to repair; raising MTBF or lowering MTTR both raise availability.

  • Four DR tiers: cold site (space and power only), warm site (partial hardware, data restoration needed), hot site (replicated systems, near-immediate), and mirrored site (simultaneous duplicate processing).

  • Service level agreement (SLA) states provider commitments to customers; operational level agreement (OLA) states internal dependencies; both must be consistent with the RTO and RPO set by business impact analysis.

  • Incident command principles: single declared incident, defined severity levels, named incident manager, and pre-agreed escalation and communication paths.

  • DR scope covers data, applications, infrastructure, facilities, third parties, and the people needed to run recovery; excluding any category leaves an untested dependency.

Quick reference

DR Program Initiation and Governance

  • Program mandate requires documented executive sponsorship, a charter defining scope and authority, and an approved budget; without a named accountable owner the program has no enforcement power.

  • Governance bodies: steering committee (strategic direction, funding, risk acceptance), DR program manager (delivery), and recovery teams (execution per plan).

  • Three lines model: operations own and execute controls, risk and compliance monitor, internal audit provides independent assurance.

  • Policy hierarchy: DR policy (intent and principles) → standards (mandatory requirements) → procedures and runbooks (step-by-step execution) → records (evidence).

  • RACI assigns each DR activity exactly one Accountable role; multiple accountable owners is a governance defect, not a control.

  • Key performance indicators: percentage of plans tested on schedule, percentage of RTOs met in tests, open corrective actions past due, and recovery staff trained and current.

  • Key risk indicators: aging of untested plans, concentration of critical systems with one provider, and drift between configuration management records and documented recovery procedures.

  • Regulatory and contractual drivers commonly include sector regulators, data protection law, and customer contract clauses; map each obligation to a specific control and evidence source.

  • Awareness and training must cover recovery team roles, call trees, and decision authority; competence records are the audit evidence that training occurred.

Quick reference

Risk Assessment and Business Impact Analysis for DR

  • Risk assessment: identify threats and vulnerabilities, estimate likelihood and impact, then derive risk level; treat, transfer, tolerate, or terminate.

  • Business impact analysis (BIA) is the primary source of RTO, RPO, and MTD values; DR strategy selection must trace back to BIA outputs, not to technical preference.

  • Impact dimensions to assess over time: financial loss, regulatory breach, safety, operational disruption, reputation, and contractual penalties; plot each against elapsed downtime.

  • Criticality tiers are assigned by impact thresholds, for example: tier 1 (loss unacceptable within hours), tier 2 (tolerable to 24 hours), tier 3 (tolerable to days).

  • Dependency mapping captures upstream suppliers, downstream consumers, shared infrastructure, identity services, DNS, and network paths; a single shared dependency can collapse many RTOs.

  • Recovery Point Objective derives from data change rate and tolerance for rework: RPO cannot be tighter than the replication or backup interval actually in place.

  • Maximum data loss tolerance expressed in transactions or currency converts to time using average transaction rate, giving an RPO in hours or minutes.

  • Risk register entries need owner, date, treatment action, residual risk rating, and acceptance signature; risk acceptance without an accountable signatory is not valid.

  • Validate BIA findings by interviewing function owners and cross-checking against financial and operational records rather than relying on a single questionnaire.

Quick reference

DR Strategies and Solutions

  • Backup strategies: full, incremental (changes since last backup of any type), and differential (changes since last full); restore time grows with the number of incremental sets chained to a full.

  • The 3-2-1 rule: at least three copies of data, on two different media or systems, with one copy offsite or offline; an immutable or air-gapped copy defends against ransomware.

  • Replication modes: synchronous replication gives near-zero RPO but adds latency and distance limits; asynchronous replication has lower latency impact but a nonzero RPO.

  • Site strategy selection is driven by RTO and cost: mirrored (lowest RTO, highest cost) → hot → warm → cold → backup-and-restore (highest RTO, lowest cost).

  • High availability (local redundancy, clustering, failover within a site) differs from DR (recovery at a separate location); HA reduces MTTR but does not replace DR.

  • Cloud DR patterns: backup and restore, pilot light (core data replicated, minimal services running), warm standby (scaled-down live copy), and multi-site active-active.

  • Recovery of dependencies must precede recovery of business applications; typical order is facilities and network, then identity and directory, then data stores, then applications.

  • Single points of failure are removed by redundancy at every layer: power, network path, storage, database, and vendor; test that failover actually triggers.

  • Strategy justification requires a documented comparison of RTO/RPO achieved against BIA targets, plus cost, complexity, and residual risk for each option considered.

Quick reference

DR Plan Development, Testing, and Maintenance

  • Plan structure: purpose and scope, roles and contact data, activation and escalation criteria, recovery procedures in order, dependencies, communications, and appendices with inventories.

  • Activation criteria must be objective and pre-agreed (for example, declared outage exceeding a stated duration or impact threshold) so that invocation is not a judgment call under pressure.

  • Call trees and contact lists require at least two contact channels per person and must be verified on a fixed cycle; stale contacts are the most common exercise failure.

  • Test types in increasing rigor: plan review (walkthrough), tabletop exercise, simulation, parallel test (recovery systems run alongside production), and full interruption or cutover test.

  • Test design rules: define objectives and success criteria before execution, capture actual RTO and RPO achieved, log every deviation, and never declare success without measured evidence.

  • Exercise findings feed a corrective action register with owner and due date; closure is verified by retest of the affected procedure.

  • Plan maintenance triggers: organizational change, new or changed critical system, infrastructure or vendor change, post-incident lessons, and a scheduled review interval.

  • Version control requirements: unique version identifier, approval signature, distribution list, and retrieval location that remains accessible when primary systems are down.

  • Crisis communication covers employees, customers, regulators, and media; pre-approved templates and a designated spokesperson reduce delay and inconsistency during activation.

Quick reference

DR Concepts and Principles

  • Disaster recovery restores technology and data services after a disruption, while business continuity sustains critical business functions; DR is therefore a subset of the wider continuity management system.

  • Recovery Time Objective (RTO) is the maximum tolerable time to restore a service after disruption; Recovery Point Objective (RPO) is the maximum tolerable data loss measured backward from the incident.

  • Maximum Tolerable Downtime (MTD) is the longest a function can be unavailable before unacceptable harm; MTD must be greater than or equal to RTO plus detection and response time.

  • Availability equals MTBF divided by (MTBF plus MTTR); raising mean time between failures or lowering mean time to repair both increase availability.

  • DR site tiers are cold (space and power only), warm (partial hardware, data restoration required), hot (replicated systems, near-immediate), and mirrored (simultaneous duplicate processing).

  • Service level agreements state provider commitments to customers, while operational level agreements state internal dependencies; both must be consistent with BIA-derived RTO and RPO.

  • Incident command requires a single declared incident, defined severity levels, a named incident manager, and pre-agreed escalation and communication paths.

  • DR scope includes data, applications, infrastructure, facilities, third parties, and recovery staff; omitting any category leaves an untested dependency.

Quick reference

DR Program Initiation and Governance

  • A program mandate requires documented executive sponsorship, a charter defining scope and authority, and an approved budget; without a named accountable owner the program cannot enforce anything.

  • Governance bodies are the steering committee (strategy, funding, risk acceptance), the DR program manager (delivery), and recovery teams (execution per plan).

  • The three lines model separates operations that own and execute controls, risk and compliance that monitor, and internal audit that provides independent assurance.

  • The policy hierarchy runs from DR policy (intent and principles) to standards (mandatory requirements) to procedures and runbooks (execution steps) to records (evidence).

  • A RACI assigns each DR activity exactly one accountable role; multiple accountable owners is a governance defect rather than a control.

  • Key performance indicators include percentage of plans tested on schedule, percentage of RTOs met in tests, open corrective actions past due, and trained recovery staff.

  • Key risk indicators include aging of untested plans, concentration of critical systems with one provider, and drift between configuration records and documented recovery procedures.

  • Regulatory and contractual drivers commonly include sector regulators, data protection law, and customer contract clauses; each obligation maps to a specific control and evidence source.

  • Awareness and training must cover recovery team roles, call trees, and decision authority, and competence records are the audit evidence that training occurred.

Quick reference

Risk Assessment and BIA for DR

  • Risk assessment identifies threats and vulnerabilities, estimates likelihood and impact, then derives a risk level; the response is to treat, transfer, tolerate, or terminate.

  • The business impact analysis is the primary source of RTO, RPO, and MTD values, and DR strategy selection must trace back to BIA outputs rather than technical preference.

  • Impact dimensions assessed over elapsed downtime include financial loss, regulatory breach, safety, operational disruption, reputation, and contractual penalties.

  • Criticality tiers are assigned by impact thresholds, for example tier 1 (loss unacceptable within hours), tier 2 (tolerable to 24 hours), and tier 3 (tolerable to days).

  • Dependency mapping captures upstream suppliers, downstream consumers, shared infrastructure, identity services, DNS, and network paths; one shared dependency can collapse many RTOs.

  • RPO derives from data change rate and tolerance for rework, and cannot be tighter than the replication or backup interval actually in place.

  • Maximum data loss tolerance expressed in transactions or currency converts to time using average transaction rate, producing an RPO in hours or minutes.

  • Risk register entries need an owner, date, treatment action, residual risk rating, and acceptance signature; acceptance without an accountable signatory is not valid.

  • BIA findings are validated by interviewing function owners and cross-checking against financial and operational records rather than relying on a single questionnaire.

Quick reference

DR Strategies and Solutions

  • Backup types are full, incremental (changes since the last backup of any type), and differential (changes since the last full); restore time grows with the number of incremental sets chained to a full.

  • The 3-2-1 rule requires at least three copies of data, on two different media or systems, with one copy offsite or offline; an immutable or air-gapped copy defends against ransomware.

  • Synchronous replication gives near-zero RPO but adds latency and distance limits; asynchronous replication has less latency impact but a nonzero RPO.

  • Site strategy selection is driven by RTO and cost, from mirrored (lowest RTO, highest cost) through hot, warm, and cold to backup-and-restore (highest RTO, lowest cost).

  • High availability uses local redundancy, clustering, and failover within a site, whereas DR recovers at a separate location; HA reduces MTTR but does not replace DR.

  • Cloud DR patterns are backup and restore, pilot light (core data replicated, minimal services running), warm standby (scaled-down live copy), and multi-site active-active.

  • Recovery order places dependencies first: facilities and network, then identity and directory, then data stores, then business applications.

  • Single points of failure are removed by redundancy at every layer, including power, network path, storage, database, and vendor, and failover must be tested to actually trigger.

  • Strategy justification requires a documented comparison of achieved RTO and RPO against BIA targets, plus cost, complexity, and residual risk for each option considered.

Quick reference

DR Plan Development, Testing, and Maintenance

  • Plan structure covers purpose and scope, roles and contact data, activation and escalation criteria, ordered recovery procedures, dependencies, communications, and appendices with inventories.

  • Activation criteria must be objective and pre-agreed, such as a declared outage exceeding a stated duration or impact threshold, so invocation is not a judgment call under pressure.

  • Call trees and contact lists need at least two contact channels per person and must be verified on a fixed cycle; stale contacts are the most common exercise failure.

  • Test types in increasing rigor are plan review or walkthrough, tabletop exercise, simulation, parallel test (recovery systems run alongside production), and full interruption or cutover test.

  • Test design requires objectives and success criteria defined before execution, measured actual RTO and RPO, logged deviations, and no success declaration without evidence.

  • Exercise findings feed a corrective action register with owner and due date, and closure is verified by retesting the affected procedure.

  • Plan maintenance triggers include organizational change, new or changed critical systems, infrastructure or vendor change, post-incident lessons, and a scheduled review interval.

  • Version control requires a unique version identifier, approval signature, distribution list, and a retrieval location accessible when primary systems are down.

  • Crisis communication covers employees, customers, regulators, and media, and pre-approved templates with a designated spokesperson reduce delay and inconsistency during activation.