EC-Council EDRP common mistakes
EC-Council EDRP · Understand the traps and how to avoid them.
Treating RTO, RPO, MTD and WRT as interchangeable acronyms, so the candidate selects an answer that quotes a recovery time objective when the scenario actually asks for the maximum tolerable downtime or the recovery point measured in data loss.
The terms are all expressed in time units and vendors often use them loosely, so candidates memorize the abbreviations without internalizing what each one measures. Exam items deliberately place several of these values in the same scenario to test whether the candidate can map the business requirement to the correct metric.
What to do instead
Build a one-page glossary that states, for each term, what it measures, who owns it, and whether it is a business-driven or technology-driven figure. For every practice scenario, underline the phrase that describes the consequence (lost transactions, hours offline, acceptable data loss) and translate it to the metric before reading the options.
Designing a disaster recovery strategy that lists only backup technology and failover hardware, omitting the business impact analysis outputs, the declaration and escalation authority, and the recovery team roles that make the plan executable.
Candidates with a technical background gravitate to the tools they know and treat the plan as a technology document. The exam tests whether the candidate understands that a DR plan is a business governance instrument whose technical components serve the BIA-derived priorities.
What to do instead
For any plan-design question, run a mental checklist of four layers: business impact and prioritization, governance and authority to invoke, people and communications, and technology recovery. If an answer option addresses only the technology layer in a question that asks for a complete plan, it is a distractor.
Selecting the highest availability architecture (active-active multi-site, synchronous replication) for every scenario regardless of the stated budget, criticality tier, or acceptable cost per hour of downtime.
Candidates equate 'best practice' with 'most resilient' and assume exam questions reward the strongest technical control. In reality the discipline is matching recovery capability to business requirements and cost, and many items include cost or proportionality cues that make the most expensive option wrong.
What to do instead
Before answering, extract the criticality tier, the MTD, and any cost or resource constraint from the stem. Choose the least-costly option that still meets the stated recovery requirement, and be prepared to reject a superior architecture that exceeds the requirement or the budget.
Confusing a disaster recovery plan with a business continuity plan, answering a BC question with a data-restoration or server-failover step, or answering a DR question with a manual-workaround or alternate-site staffing step.
The two disciplines overlap heavily and share artifacts, so the boundary blurs in study material. Exam items often hinge on whether the correct answer addresses continuation of critical business functions or restoration of technology services.
What to do instead
Anchor the distinction: BC focuses on keeping prioritized business functions running through disruption using any combination of people, process and alternate arrangements; DR focuses on restoring technology infrastructure and data. When a stem describes customer-facing service continuity or manual procedures, look for BC answers; when it describes systems, data and infrastructure, look for DR answers.
Skipping the business impact analysis step and jumping straight to solution selection, or producing a BIA that ranks systems by technical convenience rather than by financial, regulatory and operational impact over time.
The BIA is time-consuming and abstract, so candidates treat it as a documentation formality and focus on recovery technologies. The exam repeatedly tests the principle that recovery priorities and targets must be derived from quantified business impact.
What to do instead
Memorize the BIA workflow: identify critical business functions, map them to supporting systems and dependencies, quantify impact across time horizons, derive MTD and then RTO and RPO, and obtain management sign-off. Practice converting a narrative impact statement into a prioritized tier before choosing any recovery strategy.
Assuming a backup exists and is recoverable without addressing verification, restore testing, integrity checking, immutability and protection of the backup copies themselves from ransomware or credential compromise.
Candidates think of backup as a completed action rather than an unverified claim. Modern attack patterns deliberately target backup infrastructure, and exam items test whether the candidate knows that an untested or deletable backup is not a recovery capability.
What to do instead
Apply a backup assurance checklist to relevant questions: defined schedule aligned to RPO, encrypted and immutable or air-gapped copies, at least one offline or isolated copy, documented restore procedures, and periodic full restore tests with recorded results. Reject options that treat backup completion as equivalent to recoverability.
Treating the plan as finished once it is written and approved, ignoring maintenance triggers such as infrastructure change, organizational restructuring, new critical applications, and the schedule of exercises and tests.
Plans are often produced under a project deadline and then shelved, so candidates internalize a 'write once, approve, file' lifecycle. The exam tests lifecycle management, including the requirement to review after significant change and to validate through progressively rigorous exercises.
What to do instead
Learn the exercise progression from plan review and walkthrough to tabletop, simulation and full failover, and note that each exercise should produce corrective actions with owners and dates. For lifecycle questions, remember the review triggers: major change, audit finding, post-incident lessons, and a defined periodic cycle.
Failing to distinguish alternate site types and their readiness trade-offs, such as hot, warm and cold sites, mobile sites, reciprocal agreements and cloud-based recovery, and choosing a site that cannot meet the stated RTO.
The site categories sound intuitive, but the exam tests quantitative fit: a cold site with no pre-installed equipment cannot satisfy an aggressive RTO, and a reciprocal agreement carries capacity and compatibility risks that candidates overlook.
What to do instead
Create a comparison table listing for each site type the infrastructure pre-positioned, typical activation time, relative cost, and suitability against short, medium and long RTOs. When a scenario states an RTO, eliminate any site type whose realistic activation time exceeds it before evaluating the remaining options.
Ignoring dependencies and single points of failure outside the primary system, such as identity providers, DNS, network transit, power, staffing, key vendors and third-party cloud regions, when assessing recovery capability.
Candidates scope the recovery analysis to the application named in the scenario and forget that recovery fails when a shared dependency is unavailable. Exam items embed hidden dependencies to see whether the candidate maps the full service chain.
What to do instead
Practice dependency mapping for a sample critical application: authentication, name resolution, connectivity, hosting, data stores, integrations, people and suppliers. When evaluating a strategy, ask which shared component could invalidate the recovery of multiple systems simultaneously, and prefer answers that address the dependency explicitly.
Choosing an answer that confuses crisis communications and incident response sequencing with recovery, or that omits the declaration criteria, escalation path and communication plan needed to activate the plan under pressure.
Activation and communication are soft-skill elements that candidates deprioritize in favor of technical recovery steps. The exam tests whether the candidate knows that unclear authority and poor communication are among the most common real-world causes of failed recovery.
What to do instead
Memorize the activation sequence: detection, assessment against declaration criteria, notification and escalation, declaration by the authorized role, plan invocation, communication to stakeholders, and transition to recovery and then to restoration and return-to-normal. For any question about plan effectiveness, check that authority, criteria and communication channels are defined.