IR Level I common mistakes
IR Level I · Understand the traps and how to avoid them.
Assigning activities to the wrong IR lifecycle phase - for example calling memory capture 'containment', placing lessons-learned inside detection and analysis, or labelling host rebuild as 'eradication' when the exam's framework treats it as recovery.
Phases are memorised from a circular diagram rather than from each phase's objective, and everyday security vocabulary overlaps with framework terminology, so plausible-sounding but wrong mappings feel correct under time pressure.
What to do instead
Learn one framework's phase definitions verbatim (objective, entry condition, typical outputs) and practise sorting 30 sample activities into phases, justifying each with the definition rather than with intuition. Note explicitly where frameworks place evidence preservation, eradication and recovery.
Treating a logged event or a fired alert as an incident and answering escalation questions as if declaration were automatic, or conversely insisting that nothing can be declared until full technical confirmation exists.
Candidates collapse the event → alert → incident escalation chain into a single idea, and exam scenarios reward either over- or under-reaction depending on how the stem is phrased; without explicit criteria the answer defaults to habit.
What to do instead
State the escalation criteria you are applying (impact, scope, data sensitivity, contractual trigger) and show the decision, including who declares an incident and what changes operationally once declared. Distinguish suspicion-driven declaration from confirmation-driven closure.
Describing preparation as tool acquisition only - naming EDR, SIEM and backups while omitting out-of-band communications, call trees, role assignments, jump kits, legal and comms contacts, and any exercise that proves those elements work.
Preparation is the least dramatic phase; candidates gravitate to technology because it is easy to list and feels like the 'real' answer, and documentation or tabletop work is mentally filed as administrative overhead.
What to do instead
Answer preparation questions along a people–process–technology triad and always add a validation step (tabletop, simulation, call-tree test) plus the artefact it produces. Be able to name the specific gaps a given exercise would expose.
Investigating or closing an alert on the strength of one telemetry source and the vendor-supplied severity label, without independent corroboration or a recorded triage rationale.
Alert fatigue and time pressure make the platform's severity score feel authoritative, and candidates fear that adding validation steps looks indecisive; exams with long stems also push toward the fastest-sounding path.
What to do instead
For every triage answer, name at least two corroborating sources (endpoint, identity, network, email), state the confidence level, and record the disposition and rationale. Treat vendor severity as an input to prioritisation, never as a conclusion.
Collecting evidence in the wrong order - imaging a disk before capturing memory, running-state process lists or network connections - and failing to hash at acquisition or maintain a transfer log.
'Forensics' is mentally equated with disk imaging from media coverage and coursework, and volatile data feels ephemeral or optional; the order-of-volatility principle is recalled as a phrase but not applied.
What to do instead
Recite the volatility order and place it at the start of any evidence-handling answer, then add hashing at acquisition, unique identifiers, storage location and a documented chain of transfers with times and handlers.
Eradicating the first affected host immediately - reimaging or cleaning it - before sweeping the estate for the same indicators or determining initial access, then reporting the incident as resolved.
Operational urgency and a single-alert framing make the visible host feel like the whole incident, and decisive action reads as competence; scoping work is invisible in the answer and easy to skip.
What to do instead
Use an explicit sequence - scope, contain, eradicate, verify, recover - and show the sweep (IOC search across endpoint, identity and mail logs) that establishes scope before any rebuild. State what would prove the scope is complete.
Declaring recovery complete the moment services are restored, without verifying that persistence and attacker access were removed, without staged restoration, and without a defined enhanced-monitoring window.
Business pressure to return to normal dominates the scenario, and 'systems are back up' is a concrete, satisfying endpoint; candidates rarely volunteer exit criteria because nothing in the question explicitly asks for them.
What to do instead
Define exit criteria before recovery begins: clean rebuild from trusted images, credential rotation, confirmation of no residual persistence, staged return with heightened monitoring for a stated period, and an owner who signs off.
Writing lessons-learned findings as vague aspirations ('improve user awareness', 'strengthen monitoring') with no owner, due date, success measure or tracking, and closing the case once the report is issued.
Post-incident activity is treated as the report rather than as change management, and the exam's end-of-scenario positioning makes completion feel like the finish line rather than the start of remediation.
What to do instead
Convert each finding into a specific, assigned, dated corrective action with a measurable success criterion, log it in a tracked register, and describe how closure will be verified and reported back to management.
Hunting by browsing dashboards or running favourite queries without a written hypothesis, named data sources, or documentation of negative results - reporting only the hits.
Hunting is associated with tooling skill rather than with structured inquiry, so candidates describe clicking through EDR or SIEM rather than a testable proposition; negative outcomes feel like wasted effort and get omitted.
What to do instead
Structure every hunting answer as hypothesis drawn from an intelligence requirement, data sources and time range, query or analytic logic, findings, and the detection rule or visibility gap produced - explicitly including what a null result means.
Starting the notification clock at the wrong point (first alert versus confirmed incident versus discovery) and telling only one audience - usually the regulator - while ignoring contractual, customer, insurer, law-enforcement and cross-border obligations.
Attention in the scenario is absorbed by technical containment, notification duties are scattered across jurisdictions and contracts, and candidates assume a single universal deadline exists rather than per-obligation triggers.
What to do instead
Build and apply an obligation matrix: for each audience, the trigger event that starts the clock, the deadline, the approver and the content required. Involve legal counsel early and state which clock you are starting and why.