EXIN ISMP common mistakes
EXIN ISMP · Understand the traps and how to avoid them.
Answering questions as if ISMP were a technical, hands-on IT security exam - choosing firewall configuration, patch mechanics, or penetration-testing answers when the question is about governance, policy, and management responsibility.
The exam title 'Information Security Management Professional' invites candidates with a technical background to pattern-match to engineering solutions, and technical candidates often assume depth in tooling is what is being tested.
What to do instead
Before answering, classify each question: is it asking who decides, who owns, who approves, or what process applies? If so, eliminate any option that is a technical control implementation and select the option describing a management role, a policy, or a process step. Practise by rewriting technical answers into management answers during review.
Treating information security as an IT-department-only responsibility and selecting answers where the CIO, IT manager, or security officer alone owns risk, rather than answers assigning ownership to business process owners and line management.
Many candidates come from operational IT roles where security is delegated to a specialist team, so 'the security manager decides' feels natural and authoritative.
What to do instead
Anchor on the principle that risk is owned where the information is created and used. When two options look plausible, prefer the one naming a business owner, process owner, or line manager as accountable, with security in an advisory or facilitating role.
Confusing the roles of the three management levels - treating operational, tactical, and strategic responsibilities as interchangeable, for example assigning long-term security strategy to a line manager or day-to-day incident handling to the board.
The three-level model is presented early and simply, so candidates skim it, then face scenario questions where the level is implied rather than stated.
What to do instead
Build a one-page matrix: strategic (direction, policy approval, risk appetite), tactical (translation into standards, planning, coordination), operational (execution, monitoring, incident response). For each practice question, first label the scenario's level, then choose the option matching that level's typical output.
Skipping the plan-do-check-act cycle and choosing 'do' answers - implementing a control immediately - when the scenario describes a gap that first requires planning, risk assessment, or a documented decision.
Candidates want to solve the visible problem, and action feels like the strongest answer, especially under time pressure.
What to do instead
When a scenario presents a problem, ask which phase is missing. If no risk assessment or plan exists, the correct answer is the planning or assessment step, not the control. Look for keywords such as 'first', 'before', 'ensure', and 'structure' that signal a PDCA phase rather than an action.
Selecting the most comprehensive or technically strongest control as the answer instead of the control that is proportionate to the identified risk and the organisation's risk appetite.
Exam writers often include an over-engineered distractor that sounds thorough; candidates equate 'more secure' with 'more correct'.
What to do instead
Judge every control option against the stated risk and the organisation's context. Ask: is this proportionate, cost-effective, and aligned with the risk appetite described? Eliminate options that are disproportionate even when they are technically sound.
Mixing up the terms of the risk vocabulary - using threat, vulnerability, likelihood, impact, and risk interchangeably - and therefore picking an option that mislabels the element described in the scenario.
In everyday speech these words blur together, and exam questions deliberately describe a situation in plain language without naming the term.
What to do instead
Drill definitions with one-line examples: threat = who or what can cause harm; vulnerability = the weakness that allows it; likelihood = chance of exploitation; impact = consequence; risk = combination of likelihood and impact. In each question, underline the described element and match it to the definition before reading the options.
Treating risk treatment as a single step - assuming every identified risk must be mitigated - and rejecting options to accept, transfer, or avoid risk.
Candidates associate good security with reducing risk, and acceptance can feel like negligence, so the accept option is dismissed as a distractor.
What to do instead
Memorise the four treatment options and their conditions: mitigate when cost-effective, transfer where a third party can bear it, avoid when the activity is not worth the exposure, accept only with explicit, documented, owner-level sign-off. When an option describes documented acceptance by the accountable owner, treat it as a valid answer.
Answering incident-related questions with containment or eradication as the first step, ignoring detection, classification, and escalation, or ignoring the post-incident review.
Technical instincts push toward fixing the problem fast, and the early and late phases of the incident lifecycle receive less attention during study.
What to do instead
Memorise the lifecycle as a sequence: detect, classify and prioritise, escalate and notify, contain, eradicate, recover, evaluate and learn. Match the question's wording to the phase it describes, and remember that the lessons-learned step is frequently the intended answer when the question asks what should happen after recovery.
Confusing business continuity with disaster recovery - choosing backup restoration or IT system recovery answers when the question concerns keeping critical business processes running.
The two disciplines overlap heavily in practice, and IT-oriented candidates default to the technology recovery view.
What to do instead
Separate the scopes explicitly: business continuity covers the organisation's critical processes and is owned by business management; disaster recovery covers the recovery of IT facilities and systems and supports continuity. When the scenario names a business process, customer service, or production, choose the continuity answer; when it names servers, data, or infrastructure, choose the recovery answer.
Ignoring the control categories - preventive, detective, corrective - and selecting a detective control such as logging or monitoring when the question asks how to prevent an event, or vice versa.
Candidates classify controls by how familiar they are rather than by function, and many controls can appear in more than one category depending on framing.
What to do instead
For each control in a question, ask what it does at the moment of the event: stops it (preventive), notices it (detective), or restores after it (corrective). Build a short reference list of common controls under each heading and rehearse classifying unfamiliar controls by that single question.