ISO/IEC 27005 Lead Risk Manager common mistakes
ISO/IEC 27005 Lead Risk Manager · Understand the traps and how to avoid them.
Treating ISO/IEC 27005 as a certifiable management system standard and answering that an organisation can be '27005 certified' or audited against it, instead of recognising it as non-normative guidance that supports the ISMS requirements in ISO/IEC 27001.
Candidates see 'ISO/IEC standard' and assume every standard is certifiable like 27001; the exam deliberately probes the guidance-versus-requirements distinction, and marketing language about '27005 certification' reinforces the error.
What to do instead
Memorise the positioning: 27001 states requirements (certifiable, 'shall'), 27005 provides guidance (informative, 'should/can') on the information security risk management process and is not a management system standard. When a question asks what an organisation can be certified against, the answer is 27001, never 27005.
Using 'risk' as a synonym for 'threat' or 'vulnerability', for example answering that a DDoS attack is a risk, or that patching a server is a risk treatment that removes the risk rather than reducing a vulnerability.
Everyday security language conflates the three, and candidates carry that habit into the exam where the definitions are precise and heavily tested.
What to do instead
Anchor on the definitions: risk is the effect of uncertainty on objectives, expressed as a combination of the consequences of an event and its likelihood; a threat is a potential cause of an unwanted incident; a vulnerability is a weakness that can be exploited by a threat. Practise restating scenarios in the form 'threat exploits vulnerability leading to consequence with likelihood', and note that treating a vulnerability changes likelihood, not the threat itself.
Skipping or rushing context establishment and jumping straight to asset inventories and threat lists, so questions about scope, risk criteria, risk appetite and the risk management approach are answered with generic 'identify assets' responses.
Context establishment looks like administrative preamble, and candidates with technical backgrounds find it less concrete than risk analysis; they therefore under-invest in the domain where criteria-dependent questions are decided.
What to do instead
Learn the four context-establishment outputs as a checklist: scope and boundaries (including interfaces and dependencies), the organisation's environment and constraints, the risk management approach and process, and the risk evaluation criteria (impact and likelihood scales, risk acceptance criteria, risk appetite). For any question asking what to do first or what determines acceptability, test the answer against these criteria before choosing a technical activity.
Confusing risk evaluation with risk assessment, or placing risk evaluation before risk analysis in the sequence, and answering that risk evaluation is where likelihood and consequence are estimated.
The terms overlap in ordinary usage, and the three-step structure (identification, analysis, evaluation) is easy to blur under time pressure.
What to do instead
Fix the hierarchy: risk assessment = risk identification + risk analysis + risk evaluation. Identification finds and describes risks; analysis estimates consequences and likelihood (and thus the level of risk); evaluation compares the analysed level against the established criteria to decide whether treatment is needed. Any option that puts estimation inside evaluation is wrong.
Treating risk treatment as a purely technical control-selection exercise and omitting the decision logic - comparing treatment options, checking residual risk against acceptance criteria, and obtaining explicit risk acceptance from the accountable owner.
Candidates with engineering backgrounds default to 'apply the control', and the exam's treatment questions are designed to reward the governance sequence rather than the control catalogue.
What to do instead
Memorise the treatment sequence: select appropriate options (modify, retain, avoid, share - noting that ISO/IEC 27005 lists these as options, not a mandated hierarchy), determine controls, assess residual risk, compare against acceptance criteria, obtain formal acceptance by the risk owner, then document and communicate. When an option says 'implement control X' without the residual-risk and acceptance steps, look for the option that completes the cycle.
Assuming all risk must be eliminated or reduced to zero, and rejecting options that retain or share risk, or choosing 'avoid' as the safest answer whenever an option exists.
Zero-risk thinking is culturally ingrained, and candidates misread 'risk acceptance criteria' as 'risk elimination criteria'.
What to do instead
Remember that residual risk always remains and that retention (acceptance) is a legitimate, documented decision made by the risk owner within the acceptance criteria; sharing (insurance, outsourcing, contracts) transfers some consequence but not accountability. Avoidance is chosen when the risk cannot be brought within criteria or the activity's value does not justify it - not as a default. Select the option that matches the stated criteria, not the one that sounds most cautious.
Treating the risk register as a static deliverable produced once at project start, and failing questions about monitoring, review, and the triggers for re-assessment (changes to the environment, incidents, new threats, changed criteria).
Risk assessment is often taught as a one-off workshop, so candidates picture a document rather than a living process with owners, review cycles and change triggers.
What to do instead
Learn monitoring and review as a continuous phase with defined responsibilities: the risk owner monitors their risk, reviews occur at planned intervals and on trigger events, and results feed back into context, identification and treatment. Expect questions where the correct answer is 're-assess because the context changed' rather than 'apply the existing control'.
Describing risk communication as one-way reporting to management after the assessment, and missing that it is a continuous, two-way exchange with stakeholders throughout every phase of the process.
Corporate reporting habits frame communication as an output, and candidates overlook consultation with asset owners, control owners and external parties during identification and analysis.
What to do instead
Frame communication and consultation as a plan: who needs what information, when, in what form, and how their input returns into the process. For scenario questions, prefer answers that build shared understanding and gather stakeholder input early over answers that only escalate a report at the end.
Mixing up the qualitative, semi-quantitative and quantitative approaches - for example claiming a qualitative assessment produces monetary loss figures, or that a quantitative approach is always required for ISO/IEC 27001 conformity.
The exam tests whether candidates understand the trade-offs (speed and consistency versus precision and cost), and vendor material often implies quantitative is superior.
What to do instead
Learn each approach's output and trade-off: qualitative uses ordinal scales and is fast but subjective; semi-quantitative uses scaled ranks or numeric bands that are not true monetary values; quantitative uses monetary values and frequencies but needs reliable data. All three are acceptable if consistent with the risk criteria; select based on the decision's needs, available data and resources, and be alert to options that misattribute monetary outputs to qualitative methods.
Failing to connect the risk management process to the ISO/IEC 27001 ISMS clauses - not recognising that risk assessment and treatment results drive the risk treatment plan, Statement of Applicability, and clause 6 planning, or that clause 9 and 10 activities (monitoring, internal audit, management review, improvement) close the loop.
Candidates study 27005 in isolation, so integration questions feel like a separate topic and they cannot trace a risk decision into the ISMS documentation.
What to do instead
Draw the mapping explicitly: risk criteria and assessment feed the risk treatment plan and the SoA justification for inclusion or exclusion of Annex A controls; monitoring and review feed performance evaluation and management review; changes in risk feed continual improvement. Practise tracing a single identified risk from identification through treatment, SoA entry, monitoring and management review to cement the integration.