ISO 27035 LIM common mistakes
ISO 27035 LIM · Understand the traps and how to avoid them.
Treating 'event' and 'incident' as interchangeable, so candidates label any logged anomaly (a failed login, a port scan) as an information security incident and then apply the full response lifecycle to it.
Everyday IT language uses 'incident' loosely (helpdesk tickets, outages). The exam draws a deliberate line: an event is an occurrence indicating a possible breach of security policy; an information security incident is one or more events assessed as having significant probability of harming the organization. Candidates import the colloquial meaning and never test the significance threshold.
What to do instead
Before answering, force the classification question: has an assessment established a real or likely adverse impact on information or operations? If not, it is an event to be logged and triaged, not an incident. Practice by sorting a list of 20 scenarios into event / incident / incident-candidate and writing the one-line justification for each.
Memorizing the process phases as a strict waterfall and insisting that containment cannot begin until a full forensic investigation is complete, or that lessons learned must wait for full closure.
The standard's process is presented as a sequence of stages (plan and prepare; detection and reporting; assessment and decision; responses; lessons learned), and candidates read the diagram as a gate model. Real responders work iteratively, and the exam tests whether you understand stages can overlap and loop.
What to do instead
Learn the phases as a loop with feedback edges, not a chain. Be able to say which phase a given activity belongs to (e.g., evidence preservation sits in the response phase, post-incident review in lessons learned) and which phases may run concurrently. Answer 'what happens next' questions by asking what the current phase's objective is, not by counting steps.
Confusing the roles: assigning accountability for the incident management process to the incident response team lead, or expecting the CISO to personally direct technical containment.
Job titles in real organizations blur the standard's role model. The exam separates management responsibility (approving policy, resourcing, owning the process), the incident response team (executing handling), and individual reporters/users (detecting and reporting). Candidates map familiar titles onto the wrong role.
What to do instead
Build a small role table: who owns and authorizes the process, who leads the response team, who triages and decides severity, who communicates internally and externally, who reports. For each practice question, identify which role the stem describes before choosing an answer, and reject options that give a role authority the standard does not assign it.
Skipping the business case and starting the design work at the procedure level, so answers describe runbooks while the question is asking about establishing policy, scope, and management commitment.
Technical candidates find policy and governance content abstract and jump to the concrete steps they know. Design questions, however, often test the sequence: mandate and policy first, then scope and risk assessment, then roles, then procedures, then testing.
What to do instead
Learn the design order explicitly and be able to state why each layer precedes the next (policy authorizes; scope bounds; risk assessment prioritizes; roles assign; procedures operationalize; exercise validates). When a stem asks 'what should be done first', prefer the governance artifact over the technical one unless the stem already establishes that governance exists.
Treating severity classification and escalation criteria as the same thing, or answering severity questions with a fixed technical score (e.g., a CVSS number) rather than a business-impact judgement.
Tools produce technical scores automatically, so candidates equate a high score with high severity. The standard frames severity around impact on the organization, and escalation is a separate decision about who must be informed and how fast.
What to do instead
Separate the two concepts in your notes: severity = assessed business impact (confidentiality, integrity, availability, legal, reputational, operational); escalation = notification and authority path triggered by severity and other factors. For scenario questions, ask 'who needs to know and how quickly' versus 'how bad is this for the organization' and answer the one actually asked.
Jumping straight to eradication or recovery in a scenario, without first securing evidence and containing the spread, because the candidate wants to 'fix the problem'.
The instinct to restore service is strong, and containment steps look like delay. Exam scenarios deliberately reward the responder who preserves volatile evidence and limits damage before removing the cause, especially where legal or disciplinary action is possible.
What to do instead
Adopt a fixed decision order for live-incident scenarios: detect and confirm, assess and classify, contain (including evidence capture), eradicate, recover, review. If an option destroys or overwrites potential evidence or expands the blast radius, eliminate it even if it restores service faster. Practice by writing the first three actions for ten different incident types.
Assuming the incident response plan is validated by having it approved and distributed, and choosing 'review the document' as the way to gain assurance that it works.
Document-centric quality habits from audit preparation carry over. The standard expects plans to be exercised and tested, with results feeding improvement, so approval is the start of assurance, not the end.
What to do instead
Distinguish document control (versioning, approval, distribution) from validation (exercises, tests, drills, and review of their results). When a question asks how to gain confidence in the plan, prefer exercising and measuring against objectives over reading or re-approving the plan.
Handling communication and notification as an afterthought, or not knowing when regulators, customers, law enforcement, or insurers must be engaged, and answering with 'inform everyone immediately'.
Candidates focus on technical handling and either forget the notification obligations or over-correct into blanket disclosure. The exam tests planned, role-assigned, need-to-know communication with defined triggers and channels.
What to do instead
Prepare a notification matrix: stakeholder, trigger condition, who authorizes, who delivers, timeframe, and channel. Note that legal and regulatory timing may be set externally and may be shorter than internal reporting cycles. In scenarios, choose answers that route communication through the designated role and trigger rather than the broadest possible broadcast.
Recording incident details informally (chat messages, memory, a shared spreadsheet) and reconstructing the timeline later, rather than maintaining contemporaneous records during handling.
Under time pressure, documentation feels like overhead, and responders believe they will remember. The standard expects each incident to be logged and tracked through its lifecycle, and later lessons-learned and legal use depend on that record.
What to do instead
Treat the incident record as part of the response, not a report written afterwards: timestamped actions, decisions and their rationale, evidence handling, communications. In exam scenarios, prefer the option that maintains a structured, time-stamped log over one that relies on recollection, and expect questions on what the record must contain.
Writing lessons-learned outputs as a narrative of what happened, with no root-cause analysis, no assigned corrective actions, and no follow-up verification, so the same weakness recurs.
Post-incident reviews are often run as debriefs that produce a report for management and then stop. The standard's improvement stage requires identifying causes, agreeing changes to process and controls, tracking them to completion, and feeding results back into planning and preparation.
What to do instead
Structure every lessons-learned answer as: what happened and impact, root cause (not just proximate trigger), what worked and what did not, specific corrective and preventive actions with owners and dates, updates to the plan and risk assessment, and verification that actions closed. Reject options that end at 'produce a report' or 'share findings' without tracked action and re-testing.