CRIE common mistakes
CRIE · Understand the traps and how to avoid them.
Treating the incident response lifecycle as a rigid one-way pipeline and answering scenario questions as if a phase is skipped once passed (e.g., refusing to re-enter containment after new evidence emerges during eradication).
Candidates memorize the phases as an ordered list and assume each phase occurs exactly once, so they miss questions describing iteration, feedback loops, or phase overlap.
What to do instead
Learn the lifecycle as iterative and overlapping: recovery findings can trigger renewed detection, eradication gaps can force re-containment, and lessons learned can revise preparation. In scenario questions, ask which phase activity is being described rather than which phase number comes next.
Choosing a response action that destroys or alters potential evidence (rebooting a suspected host, deleting a suspicious file, wiping and reimaging immediately) before any preservation step.
Candidates default to the fastest-sounding remediation and forget that volatile data and disk state may be needed for scoping, attribution, or legal purposes.
What to do instead
Before any disruptive action, identify what evidence exists and preserve it in order of volatility (memory, network connections, running processes, then disk). Prefer isolation over shutdown, and document every action taken with timestamps.
Confusing a plan's components: labeling a contact roster as the full incident response plan, or treating a playbook as a substitute for policy and procedures.
The terms policy, plan, procedure, playbook, and checklist are used loosely in study material, so candidates map questions to whichever artifact they remember first.
What to do instead
Memorize the hierarchy: policy sets authority and intent, the plan defines roles/phases/communication, procedures give step-by-step actions, and playbooks are scenario-specific. Match the question's scope to the correct artifact level.
Failing to define or apply severity/classification criteria, treating every alert as a full-scale incident or dismissing a low-severity alert that later proves significant.
Candidates skip triage frameworks and answer based on gut reaction to the scenario's wording rather than on documented escalation criteria.
What to do instead
Study how severity is determined (impact, scope, data sensitivity, criticality of assets) and how classification drives escalation, notification, and resource allocation. In questions, identify the classification trigger before choosing a response level.
Not recognizing the need for legal/privacy/regulatory involvement and notification timelines when an incident involves personal or regulated data.
Candidates focus on technical containment and forget that breach notification, counsel involvement, and regulatory clocks run in parallel with technical response.
What to do instead
Build a mental checklist for data-related incidents: engage legal and privacy early, determine jurisdictional and contractual notification obligations, and preserve evidence for potential litigation. Treat notification as a parallel track, not a post-incident afterthought.
Skipping or superficially performing lessons learned, producing a report that lists what happened but no root cause, no measurable corrective actions, and no owners or deadlines.
Candidates treat post-incident review as paperwork and describe it generically instead of as a structured improvement process with accountability.
What to do instead
Frame lessons learned as: timeline reconstruction, root cause analysis, identification of control gaps, and corrective actions with owners, due dates, and follow-up verification. Emphasize feeding results back into preparation and plan updates.
Containment choices that ignore scope and business impact-e.g., pulling the plug on a production server or blocking an entire subnet without confirming the blast radius.
Candidates equate containment with maximum disruption and forget trade-offs between short-term containment, isolation, and continued monitoring to observe attacker behavior.
What to do instead
Evaluate containment options against scope, criticality, and evidence needs. Consider staged containment and segmentation, and justify the choice by balancing business continuity with stopping spread.
Assuming eradication is complete after removing the initial malware without verifying persistence mechanisms, lateral movement, or credential compromise.
Candidates anchor on the first indicator found and treat removal of that artifact as the end of the intrusion.
What to do instead
Eradication must address all identified footholds: persistence, compromised accounts, scheduled tasks, and unauthorized access paths. Verify with re-scanning and monitoring before declaring recovery, and define validation criteria.
Describing chain of custody and evidence handling without the operational details: no unique identifiers, no hash verification, no documentation of who handled evidence and when.
Candidates know the phrase 'chain of custody' but not what makes it defensible, so answers stay abstract.
What to do instead
Learn the concrete elements: labeling with unique IDs, recording collector/date/time/location, hashing at acquisition and re-verifying, secure storage, and a transfer log. Apply these to any scenario involving evidence collection.
Ignoring communication structure-no designated spokesperson, no predefined escalation paths, inconsistent internal versus external messaging, or sharing unverified details during an active incident.
Candidates concentrate on technical response and treat communication as a soft topic, missing questions about roles, approval of external statements, and information accuracy.
What to do instead
Study the communication plan elements: defined roles (incident commander, spokesperson, legal), escalation and notification paths, approved channels, and message consistency. In scenarios, verify facts and route external communication through designated authority.