PECB Certified Lead Disaster Recovery Manager common mistakes
PECB Certified Lead Disaster Recovery Manager · Understand the traps and how to avoid them.
Using the terms disaster recovery, business continuity, and incident response interchangeably in scenario questions, then selecting an answer that describes a local incident response step (e.g., isolating a server or eradicating malware) as the DR action.
The three disciplines overlap in vocabulary and many candidates come from IT operations, where 'recovery' informally covers restoring a single system or containing an attack. The exam distinguishes scope: DR restores critical technology and data services after a disruptive event, BC keeps the whole business operating, and incident response manages the security event itself.
What to do instead
Before answering, label the scenario's trigger and scope. If the disruption is a security event still being contained, the correct first action usually belongs to incident response. If critical systems and data must be restored at an alternate site or from backup, it is DR. If the question concerns people, processes, and alternate business workflows, it is BC. Practice writing a one-line scope statement for each discipline and apply it to every scenario.
Treating RTO and RPO as synonyms or reversing them, for example stating that a 15-minute RPO means systems must be back online within 15 minutes.
Both are time-based targets defined during BIA, and candidates memorize the acronyms without anchoring them to a direction in time. Under exam pressure, the shorter-sounding metric gets attached to the wrong objective.
What to do instead
Anchor each term to a question: RTO answers 'how long may this be unavailable?' (forward from the outage). RPO answers 'how much data may we lose?' (backward from the outage, i.e., the maximum age of the last recoverable copy). For every metric in a question, restate it in plain language before evaluating options, and check that the chosen solution's backup frequency satisfies the RPO while its restore time satisfies the RTO.
Skipping or rushing the DR program charter and governance setup, and instead jumping straight to writing recovery procedures, so questions about roles, sponsorship, policy hierarchy, and program scope are answered with technical options.
Technical candidates find procedure-writing concrete and comfortable, while governance feels administrative. As a result they never internalize who owns the program, how DR policy relates to BC policy, or how scope boundaries are documented and approved.
What to do instead
Study the initiation sequence as a chain: management sponsorship and mandate, DR policy, scope statement, roles and responsibilities (including the DR manager's authority), program plan, and performance reporting. For governance questions, first ask 'who decides and who is accountable?' before asking 'what technology?' Memorize the distinction between the DR policy (management intent and requirements) and the DR plan (procedures).
Answering governance questions by assigning DR accountability to the IT department or the DR manager alone, rather than to top management, and failing to recognize that accountability cannot be delegated away.
In daily practice DR is executed by IT, so candidates map operational execution onto accountability. The exam tests the principle that senior management remains accountable for the program while execution and coordination are delegated.
What to do instead
Separate three verbs in every governance item: accountable (senior management, approves policy, resources, and risk acceptance), responsible (DR manager and recovery teams, do the work), and consulted/informed (business units, suppliers, communications). When an option makes IT solely accountable for the program's adequacy, treat it as a distractor.
Performing a risk assessment that lists threats without linking them to likelihood, impact, and existing controls, or producing a generic threat list that is not used to prioritize which risks the DR program must address.
Candidates confuse a threat inventory with a risk assessment and believe more threats listed equals a better answer. They also overlook that risk evaluation must feed strategy selection, so a standalone list looks complete.
What to do instead
Structure every risk assessment answer as: asset or process in scope, threat, vulnerability or exposure, existing controls, likelihood, impact, and resulting risk level with treatment decision. Verify that the output is explicitly referenced by later strategy and plan decisions. If an option stops at 'identify threats', it is incomplete.
Conducting the BIA at department level using opinions and gut feel, without identifying critical business processes, their dependencies, and the maximum tolerable downtime derived from actual impact over time.
Stakeholders often answer BIA questions optimistically or defensively, and candidates accept those answers as data. Without a time-based impact curve, RTOs get set by IT capability rather than business need.
What to do instead
Describe the BIA method: identify processes and their owners, map dependencies (applications, data, people, suppliers, facilities), quantify impact across time horizons (hours, days, weeks) in financial, regulatory, safety, and reputational terms, then derive MTD and cascade RTO/RPO to supporting assets. In questions, prefer answers that validate BIA input with owners and evidence over answers that simply accept a stated number.
Choosing a single recovery strategy (for example, warm site or replication) without matching it to the BIA-derived RTO/RPO and without comparing cost, risk, and feasibility of alternatives.
Candidates look for the 'most robust' or 'most modern' option instead of the fit-for-purpose one, and they forget that a strategy must be justified by requirements and approved through cost-benefit analysis.
What to do instead
For every strategy question, first extract the required RTO and RPO from the stem, then eliminate options that cannot meet them (too slow) or are grossly over-engineered and unaffordable (too costly). Justify the survivor with a short cost versus risk-reduction argument, and remember that different tiers of systems may warrant different strategies within one program.
Writing DR plans that are technically detailed but lack decision authority, activation criteria, communication trees, and manual workarounds, so scenario questions about who declares a disaster or what happens when tools are unavailable are answered with tool-dependent steps.
Authors write plans for the happy path they know, assuming systems, staff, and connectivity behave normally. The exam tests plans that must work when those assumptions fail and when judgement and escalation are required.
What to do instead
Include in every plan: activation and escalation criteria with named decision authority and alternates, a contact and notification cascade, roles with succession, dependency-ordered recovery procedures, manual interim procedures, and interfaces to BC and crisis communication. When a question asks for the first plan action after a disruption, prefer assessment and declaration by the authorized role over immediate technical restoration.
Treating testing as a one-off event or accepting a test that only confirms the plan document exists, rather than designing a progressive exercise program with objectives, scenarios, and documented corrective actions.
Candidates equate 'testing' with a full failover and therefore either avoid it or treat a tabletop as sufficient proof. They miss that each exercise type validates different things and that findings must be tracked to closure.
What to do instead
Learn the progression and what each validates: plan review and walkthrough (completeness and roles), tabletop (decision-making and communication), simulation (procedures without moving systems), and full failover or parallel test (technical recoverability and RTO achievement). For each, state measurable objectives and require after-action reports with assigned corrective actions, owners, and due dates fed back into the plan.
Leaving the DR plan static after approval, with no maintenance triggers, ownership for updates, or version control, so questions about organizational change, new systems, or supplier changes are answered as if the plan remains valid.
Plans are treated as a project deliverable rather than a living capability, and no one is assigned to keep content current. Candidates underestimate how quickly contact lists, dependencies, and technology details decay.
What to do instead
Establish maintenance requirements: a named plan owner, scheduled review cycles, event-driven triggers (major change, reorganization, new critical system, supplier change, exercise findings, actual invocation), version control with distribution lists, and training and awareness so responders know their roles. In questions, prefer answers that update and re-validate the plan after a change over answers that rely on the previously approved version.