IT Risk Fundamentals common mistakes
IT Risk Fundamentals · Understand the traps and how to avoid them.
Treating risk as a synonym for threat or vulnerability, so questions asking 'which of these is a risk?' get answered with the attacker or the weakness rather than the combination of a threat exploiting a vulnerability against an asset with an impact.
Everyday usage blurs the three terms, and scenario stems often mention only the attacker or only the flaw, which invites picking that term as the answer.
What to do instead
Before answering, state the three components in the stem: asset, threat, vulnerability, and the resulting impact or likelihood. If any component is missing from an option, it is not the risk.
Confusing inherent risk with residual risk, and answering with the pre-control exposure when the question asks what remains after controls are applied (or vice versa).
Both numbers appear in the same scenario, and the word 'risk' is used for both without a qualifier, so candidates grab the more dramatic figure.
What to do instead
Underline the phrase 'after controls', 'before controls', or 'currently' in the stem. Inherent = no controls; residual = after existing controls; target = desired level. Map the option to that exact phrase.
Selecting a control response (mitigate, transfer, avoid, accept) that does not match the action described in the stem, e.g. choosing 'transfer' when the organisation buys cyber insurance versus when it outsources the process.
Insurance and outsourcing both involve a third party, so 'transfer' feels right for both, but outsourcing shifts the activity while retaining accountability, which is closer to mitigation or avoidance depending on the scenario.
What to do instead
Ask what happens to the risk itself. Insurance moves the financial consequence (transfer). Stopping the activity removes it (avoid). Adding a control reduces it (mitigate). Doing nothing and documenting it is accept. Match the mechanism, not the vendor relationship.
Scoring likelihood and impact on the same scale or adding them instead of multiplying, producing a risk rating inconsistent with the matrix shown in the stem.
Under time pressure candidates shortcut the arithmetic and use intuition, which drifts toward adding two low numbers into a medium rating.
What to do instead
Use the matrix exactly as given: locate likelihood on one axis and impact on the other, read the cell. If only narrative is given, rank likelihood and impact separately first, then combine.
Treating a control as effective because it exists, rather than assessing whether it is designed and operating as intended, so 'we have a firewall' is accepted as reducing risk.
Checklist thinking equates presence with effectiveness, and exam options often include the control name as a distractor.
What to do instead
Separate design effectiveness (would this control address the cause?) from operating effectiveness (is it working now, tested?). An untested or misconfigured control does not justify a lower residual risk.
Mixing up qualitative and quantitative risk assessment and picking a monetary figure (ALE, SLE) when the question asks for a qualitative rating, or vice versa.
Both approaches appear in the same syllabus and the numeric option looks more rigorous, so candidates default to it even when the data needed for it is absent.
What to do instead
Check whether the stem supplies frequency and monetary loss data. If it does not, quantitative answers are unsupported; choose the qualitative or semi-quantitative option. Know SLE = asset value x exposure factor and ALE = SLE x annualised rate of occurrence.
Misreading 'risk appetite' versus 'risk tolerance' versus 'risk capacity' and selecting the wrong term for the statement in the stem.
The three are adjacent concepts with overlapping plain-language definitions, and stems are written to sound plausible for more than one.
What to do instead
Appetite = the amount of risk the organisation is willing to pursue for reward (a strategic statement). Tolerance = the acceptable variation around that, often expressed as limits. Capacity = the maximum it could bear before failure. Match the level of the statement: strategy, limit, or breaking point.
Choosing a technical control when the scenario calls for a governance or process control, such as answering 'install an intrusion detection system' where the gap described is an undefined risk owner or missing risk register.
Technical controls are more familiar and feel more concrete, so candidates reach for a tool even when the problem is accountability or documentation.
What to do instead
Identify the nature of the gap first: people, process, or technology. If the stem describes unclear ownership, inconsistent treatment, or no reporting, the answer is a governance artefact (risk register, ownership assignment, risk committee, reporting cadence), not a tool.
Ignoring the risk register's lifecycle and treating it as a static list, so questions about review frequency, closure criteria, or escalation are answered with 'add it to the register' alone.
The register is introduced early as a document, and candidates memorise it as an output rather than a maintained process.
What to do instead
Learn the register as a cycle: identify, assess, assign owner, treat, monitor, review, close or escalate. For any register question, ask which stage the stem describes and pick the action belonging to that stage.
Answering 'accept the risk' whenever the cost of the control exceeds the benefit, without checking whether the risk is above the organisation's stated tolerance and therefore must be escalated rather than accepted locally.
Cost-benefit reasoning is intuitive and the arithmetic in the stem supports acceptance, but acceptance authority is bounded by tolerance and delegation.
What to do instead
Check the tolerance threshold first. Below tolerance, acceptance by the owner is valid. Above tolerance, the decision escalates to the level with authority to accept, and the register must record the acceptance, the rationale, and a review date.