CIMA P3 Risk Management common mistakes
CIMA P3 Risk Management · Understand the traps and how to avoid them.
Classifying a risk by its source or symptom (for example calling a supplier failure an 'operational risk') instead of by its consequence for the organisation's objectives, then answering follow-on questions from that label.
Candidates learn the risk-category taxonomy (strategic, operational, financial, reputational, hazard) as a list of examples and pattern-match keywords, so a factory fire is labelled 'hazard' and a key customer loss is labelled 'strategic' without testing the label against the strategic/operational boundary or the entity's stated objectives.
What to do instead
Before answering, write the objective at risk in one line and ask whether the event threatens the whole business model or a process within it. Build a three-column table (event, objective threatened, category) for every scenario in the question, and where an event spans categories say so explicitly and justify the dominant one.
Treating the risk register as a static list and answering 'identify the risk' questions only from the events named in the scenario, missing second-order and correlated risks.
Exam questions present a small set of facts and candidates assume the listed facts are the complete risk universe; they do not run structured identification techniques (SWOT, PESTLE, scenario analysis, process mapping, bow-tie) that would surface knock-on risks such as reputational damage, regulatory attention, or loss of key staff following an initial event.
What to do instead
For each scenario, deliberately generate at least one risk from each of four angles: direct, consequential, correlated, and control-failure. Practise bow-tie analysis on a single event to separate causes from consequences, and state which identification technique you applied so the marker can follow your reasoning.
Confusing inherent risk with residual risk, or quoting a risk rating without stating whether controls have been applied.
The two terms are learned as definitions rather than as sequential steps in a workflow, so candidates compute a score and label it inconsistently, or claim a control reduces a risk to 'low' without assessing control effectiveness or the possibility of control failure.
What to do instead
Always present risk in a two-stage format: inherent likelihood x impact, then list the specific controls, then assess control effectiveness (design and operating), then residual likelihood x impact. If a question asks for one figure, state which basis you are using in the first sentence of your answer.
Applying a single generic risk response (usually 'mitigate') to every risk instead of selecting among avoid, reduce, transfer, accept, and exploit/share with reference to the organisation's risk appetite.
Candidates default to the intuitively safe answer and do not test whether the risk sits above or below appetite, what the cost-benefit of the response is, or whether transfer is even available (for example, uninsurable reputational or regulatory risk).
What to do instead
For each risk, state its position against appetite first, then justify the response by cost versus expected loss reduction and by feasibility of transfer. Explicitly name risks where acceptance is correct because the cost of control exceeds the expected loss, and identify risks that cannot be transferred.
Describing controls as a list of activities without distinguishing preventive, detective, and corrective controls, or without linking each control to a specific risk.
Control frameworks are memorised as categories rather than as a mapping exercise, so answers read as a generic 'we will have policies, training, and audits' with no logic connecting a named risk to a named control and its frequency or owner.
What to do instead
Use a control matrix: risk, control description, control type (preventive/detective/corrective), frequency, owner, evidence produced. In exam answers, write at least one control per type for the main risk and state what evidence would prove the control operated.
Confusing the three lines model: allocating assurance, management, and internal audit responsibilities to the wrong parties, or treating the board as a fourth line.
Candidates conflate 'who owns the risk' with 'who assures on the risk', and often state that internal audit owns or manages risks, which is a fundamental governance error that loses marks across governance questions.
What to do instead
Fix the model in memory: first line owns and manages risk (operational management), second line sets frameworks, monitors, and challenges (risk and compliance functions), third line provides independent assurance to the board (internal audit). The board and audit committee sit above and receive assurance; they do not form a line. State the line explicitly whenever you name a function.
Answering risk-appetite questions with a vague statement ('the board is risk averse') rather than a quantified or clearly bounded appetite with tolerances and escalation triggers.
Risk appetite is learned as a concept rather than as a management tool, so candidates never convert it into capacity, appetite, tolerance, and trigger levels, and cannot explain how it drives decision-making or escalation.
What to do instead
Express appetite in measurable terms (for example maximum acceptable expected loss, VaR limit, maximum single-counterparty exposure, downtime hours) and distinguish risk capacity, appetite, tolerance, and trigger. In answers, show how a breach of tolerance escalates and what decision the board would take.
Treating cyber risk as purely a technology problem and proposing only technical controls, omitting human, third-party, and governance dimensions.
Candidates associate cyber with IT departments and firewalls, so they miss phishing and social engineering, supplier and cloud concentration risk, privileged access, incident response and reporting, regulatory notification duties, and board-level oversight of cyber as an enterprise risk.
What to do instead
Structure cyber answers across four layers: governance (ownership, reporting, board cyber literacy), people (training, phishing simulation, culture of reporting), process (access management, patching, incident response, backup and recovery testing), and technology (segmentation, monitoring, encryption). Add third-party and supply-chain exposure and the regulatory notification timeline.
Describing risk culture only in terms of 'tone at the top' without addressing incentives, speak-up mechanisms, or how culture is measured and evidenced.
Culture is treated as a soft topic with one acceptable phrase, so candidates cannot explain the mechanisms that shape behaviour (performance and remuneration metrics, blame versus learning in incident reporting, near-miss reporting rates) or how a board would obtain assurance over culture.
What to do instead
Answer culture questions with mechanisms: what leaders do and reward, whether risk metrics appear in individual objectives, how near misses and whistleblowing are handled, and what evidence (staff surveys, incident reporting trends, audit findings, exit interviews) provides assurance. Link culture failures to a concrete behavioural outcome in the scenario.
Producing unbalanced evaluations: listing only advantages or only risks of a strategic option, or reaching a recommendation without stating assumptions, criteria, and sensitivity to those assumptions.
Under time pressure candidates write descriptive lists and skip the evaluative step, so they never define decision criteria, weight them, test the recommendation against a downside scenario, or acknowledge what would change the answer.
What to do instead
Use a fixed structure for every evaluation: criteria (strategic fit, risk, return, feasibility, stakeholder impact), assessment against each, key assumptions, sensitivity or scenario test (base, downside, severe but plausible), then a recommendation with conditions and a trigger for review. State explicitly what evidence would overturn your recommendation.