SAMRA common mistakes
SAMRA · Understand the traps and how to avoid them.
Treating 'risk' as synonymous with 'hazard' or 'uncertainty', so scenario questions about likelihood and impact get answered with a hazard description instead of an assessed risk statement.
Candidates learn ISO 31000 vocabulary quickly but never practise converting a hazard (e.g. 'flooding') into a two-dimensional risk statement with expressed uncertainty and consequence.
What to do instead
Before answering, force every risk into the form 'event - cause - consequence - likelihood/impact'. Drill ten hazards into risk statements and check each has a consequence and a likelihood dimension; if either is missing, the option is wrong.
Confusing risk criteria with risk appetite/tolerance, and picking the answer that sets the appetite when the question asks what is used to decide whether a risk is acceptable.
The three terms are defined adjacently in standards and candidates memorise them as a cluster rather than as distinct decision tools with different owners and uses.
What to do instead
Build a one-line contrast card: criteria = the measures/levels used to evaluate significance; appetite = amount of risk the organisation is willing to pursue; tolerance = acceptable deviation around a limit. Then practise classifying five sample statements into each category.
Using a single technique (usually a workshop brainstorm or a checklist) for every identification question, regardless of the prompt's context such as a novel technology or a mature process with historical data.
Candidates learn a list of techniques but not the selection logic, so they default to the most familiar method and miss prompts signalling that a data-driven or structured method is needed.
What to do instead
Memorise a selection matrix: novel/unknown → structured creative methods (HAZOP, scenario analysis, Delphi); historical data available → incident review, trend analysis, bow-tie; complex interdependent systems → FMEA, fault tree. Match the prompt's cues to the matrix before choosing.
Presenting a risk register entry with a vague cause ('poor management') or a compound cause with several unrelated drivers, which invalidates the subsequent analysis and treatment questions.
Candidates rush to fill the consequence column and treat cause as a formality, so the causal chain is not genuinely identified.
What to do instead
For each entry, write the cause as a specific, controllable condition and test it with 'if this condition were removed, would the event still occur?'. Split compound causes into separate entries and check each has its own treatment.
Selecting 'avoid' or 'transfer' as the treatment when the scenario describes reducing likelihood or consequence, or when the prompt asks for the treatment type that retains the risk with a funding plan.
Candidates match on keywords in the scenario rather than on the definition of each treatment option, and insurance is reflexively labelled 'transfer' even when the question is about residual risk financing.
What to do instead
Learn the four options by their mechanism: avoid = remove the activity; reduce = change likelihood or impact; transfer = shift financial consequence to a third party; retain = accept and plan. For each practice scenario, state which element of the risk (frequency, severity, financing) the action changes.
Describing controls without classifying them as preventive versus detective or assessing their effectiveness, so the answer lists activities but never evaluates whether they reduce risk to within tolerance.
Candidates equate 'having a control' with 'controlling the risk', and the layered-controls concept is understood abstractly rather than applied to a specific scenario.
What to do instead
For any control question, answer in three parts: type (preventive/detective/corrective), mechanism (what it actually does to likelihood or impact), and effectiveness evidence (testing, audit, metrics). Check whether the scenario needs a single strong control or independent layers.
Choosing a communication approach based only on what to say, ignoring the audience's decision role, so the answer recommends a full register to the board or a one-line summary to operational staff.
Candidates treat risk reporting as a formatting exercise and skip the stakeholder-analysis step that should determine content, frequency, and escalation thresholds.
What to do instead
Before selecting an option, identify the audience's role (oversight, decision, operational action) and their required granularity. Then check the option against three filters: right level of detail, right frequency, and a clear escalation trigger.
Treating monitoring and review as a one-off annual activity, or choosing 'review the register' when the scenario calls for monitoring a specific key risk indicator with defined thresholds.
Candidates collapse the two concepts and default to periodic review, missing prompts that describe early-warning signals, drift, or changes in the external context.
What to do instead
Separate the two: monitoring = ongoing tracking of indicators and control performance against thresholds; review = periodic reassessment of whether the framework and assessments remain valid. For each scenario, ask 'is this about detecting change now, or revalidating the approach?'.
Citing a framework clause as the answer without linking it to the organisation's context, so questions about tailoring or maturity are answered with 'implement the standard fully'.
Candidates memorise standard structures (ISO 31000 principles, COSO ERM components) and assume compliance equals effectiveness, overlooking that standards require adaptation to context and purpose.
What to do instead
For every framework question, add the tailoring test: does the answer reflect the organisation's objectives, size, and obligations? Rehearse the principle that frameworks are guidance to be adapted, not checklists to be certified, and practise spotting options that over-apply a clause.
Answering project risk questions with enterprise-level or operational risk language, or ignoring the project life-cycle stage when recommending an action such as contingency use or baseline change.
Candidates apply a single generic risk process to all contexts and do not distinguish project uncertainty (delivery, scope, schedule) from ongoing operational risk, nor account for stage-gate decision points.
What to do instead
Anchor each answer to the project context: identify the life-cycle stage, the objective at risk (scope, time, cost, quality), and who owns it. Eliminate options that describe standing operational controls or enterprise appetite statements when the prompt is about a delivery decision.
Dismissing emerging risks as unquantifiable and recommending they be added to the register later, rather than proposing horizon scanning, scenario analysis, or adaptive capacity building.
Candidates are trained on likelihood-times-impact methods that require data, and emerging risks by definition lack historical data, so the standard toolkit appears inapplicable.
What to do instead
Learn the emerging-risk toolkit explicitly: horizon scanning, weak-signal detection, scenario planning, stress testing, and building slack and redundancy for resilience. When data is absent, select options that generate information or increase adaptive capacity rather than deferring action.