ISO 27005 RM common mistakes
ISO 27005 RM · Understand the traps and how to avoid them.
Treating risk as the vulnerability or the threat itself (e.g., answering 'SQL injection' when asked for the risk), instead of expressing risk as the effect of uncertainty on objectives stemming from a threat exploiting a vulnerability against an asset.
Everyday language uses 'risk' loosely, and candidates carry that habit into the exam; ISO/IEC 27005 keeps a strict chain of asset, threat, vulnerability, and consequence, and exam items exploit the gap between colloquial and standard usage.
What to do instead
Before selecting an answer, rewrite the option in the template 'the potential for loss or harm to <asset/objective> when exploits , resulting in '. If the option names only a threat or only a weakness, it is a component of risk, not risk. Practise converting ten real incidents into this sentence form.
Confusing risk assessment with risk treatment, or treating risk assessment as a one-off project that ends when the report is delivered, rather than a continuing activity feeding treatment decisions and monitoring.
Many candidates come from audit or project backgrounds where a risk register is produced once; ISO/IEC 27005 places assessment and treatment inside a continuing process loop that includes communication, consultation, and monitoring and review.
What to do instead
Memorise the process as a cycle: context establishment, risk assessment (identification, analysis, evaluation), treatment, acceptance, communication and consultation throughout, and monitoring and review throughout. For any item, first decide which process step the question is asking about, then answer within that step only.
Skipping or under-specifying context establishment, then answering a scenario question with a generic control instead of one justified by the organisation's scope, criteria, constraints, and risk appetite.
Context establishment feels like administrative preamble, so candidates skim it; but scope boundaries, risk criteria, and acceptance criteria determine which later answers are defensible, and scenario items are usually built to test exactly that dependency.
What to do instead
For each scenario, explicitly note scope, asset and business context, risk criteria, and constraints before evaluating options. Reject options that impose controls or criteria the organisation never defined, and prefer options that first align with the stated context and criteria.
Mixing qualitative, semi-quantitative, and quantitative scales within one analysis, or comparing outputs across methods without converting them, and then selecting an answer that assumes a precision the chosen method cannot deliver.
Scales look interchangeable (low/medium/high versus 1-5 versus monetary values), and candidates answer by intuition about which 'sounds more rigorous' rather than which is consistent with the scenario's stated method.
What to do instead
Learn the characteristics of each approach and its limits: qualitative for consistency and speed, semi-quantitative for ranked scales, quantitative where reliable data exists. In items, check that the scale in the option matches the scale in the stem, and treat any option that silently upgrades qualitative output into monetary figures as suspect.
Treating risk evaluation and risk treatment as the same decision, e.g., choosing 'apply a control' when the question asks what should happen after comparing the analysed risk against the risk criteria.
The steps are adjacent and both involve decisions, so candidates collapse them; evaluation is the comparison against criteria producing a decision to accept, treat, avoid, or share, whereas treatment is the selection and implementation of options.
What to do instead
Anchor on the phrase 'compare with risk criteria' as the marker for evaluation. If the stem asks for a comparison outcome, the answer is a decision category; if it asks how to modify the risk, the answer is a treatment option. Drill by labelling each step of a worked example with one verb only.
Assuming risk treatment always means reducing risk by adding a technical control, and overlooking risk retention, avoidance, and sharing, or misclassifying transfers such as insurance and contractual allocation.
Security training emphasises controls, so candidates default to 'implement a safeguard'; the standard's treatment options include options that are not controls at all, and the exam tests whether the candidate can distinguish them.
What to do instead
Build a four-way table: modification (reduce likelihood or consequence), retention (accept and monitor), avoidance (stop the activity), sharing (insurance, contracts, outsourcing) with residual risk noted. For each scenario, ask whether the business outcome permits avoidance or sharing before assuming modification.
Ignoring residual risk and the need for explicit risk acceptance by an accountable owner, and answering that treatment closes the risk once controls are implemented.
Project thinking treats control implementation as completion; ISO/IEC 27005 requires that residual risk be compared against criteria and formally accepted, with the owner identified, and exam items frequently hinge on who accepts and on what basis.
What to do instead
Always append two questions to any treatment answer: what residual risk remains, and who accepts it against which criteria? Prefer options that name the accountable risk owner and documented acceptance over options that declare the risk eliminated.
Conflating the risk management framework with the risk management process, or describing programme implementation as producing documents only, without roles, accountability, integration with decision-making, and monitoring.
Both concepts are described in the same clauses and share vocabulary; candidates memorise lists without attaching each element to its purpose, so they cannot tell which layer an item is probing.
What to do instead
Separate the two explicitly: the framework is the set of components providing the foundations and arrangements (policy, roles, resources, integration), while the process is the repeated set of activities. When an item mentions governance, commitment, or integration, answer at framework level; when it mentions identification, analysis, or evaluation, answer at process level.
Treating ISO/IEC 27005 as a certifiable management system standard and confusing its guidance with ISO/IEC 27001 requirements, e.g., answering that an organisation is 'certified to 27005' or citing Annex A controls as 27005 content.
The standards are used together and share terminology, so candidates assume parallel status; 27005 provides guidance on information security risk management and supports the risk-related requirements of a management system, it does not itself set auditable requirements.
What to do instead
Memorise a short positioning statement for each standard in scope: 27001 requirements for the management system including risk-related requirements, 27005 guidance on risk management, 27002 controls guidance. For any item, ask whether it is asking for a requirement, guidance, or control practice, and answer in that register.
Answering questions on alternative assessment methods (such as baseline, asset-based, scenario-based, or FAIR-style quantitative approaches) with the ISO process vocabulary alone, without matching the method to the question's stated purpose, data availability, or repeatability needs.
Candidates prepare mainly from the main standard and treat other methods as optional reading, so they cannot distinguish when a scenario-based or quantitative method is the better fit and default to the familiar answer.
What to do instead
For each method, memorise three attributes: what it starts from (assets, scenarios, baseline controls, or loss events), what data it needs, and what output it produces. In items, match the stem's stated driver (speed, comparability, monetary decision support, regulatory baseline) to the method whose attributes fit, and eliminate methods whose data needs the scenario cannot meet.