CSPI common mistakes
CSPI · Understand the traps and how to avoid them.
Computing ALE by plugging percentages into the formula instead of currency - e.g. multiplying an asset value by an exposure factor expressed as a decimal, then treating the result as a percentage, or quoting an ALE without ever comparing it against the annual cost of the proposed control.
Candidates memorise 'SLE = AV × EF' and 'ALE = SLE × ARO' as strings of letters and rush the arithmetic under time pressure, so unit errors and skipped comparison steps go unnoticed.
What to do instead
Before answering, write the three quantities on scratch paper with units attached: SLE in currency (AV in currency × EF as a decimal), ARO as events per year (not a percent), ALE in currency per year. A control is only justified when the ALE reduction exceeds the control's total annual cost; if the answer options ignore that comparison, look for the 'cost exceeds benefit / accept the risk' option.
Treating 'threat', 'vulnerability', 'risk' and 'impact' as interchangeable in the stem, and picking the option that claims a control can 'eliminate' or 'remove' risk.
Everyday security language blurs the terms, and 'eliminate the risk' sounds like the strongest, most thorough answer, which feels right to an exam taker.
What to do instead
Parse the stem into the components explicitly: an asset, a threat source, a vulnerability, a likelihood, an impact. Then reject any option that claims risk is eliminated - residual risk always remains and must be accepted, transferred, mitigated or avoided. The correct answer usually reduces likelihood or impact, or states that residual risk is formally accepted by management.
Mixing up inherent risk, residual risk and the risk treatment options - for example describing 'purchasing cyber insurance' as risk mitigation, or labelling the risk remaining after controls as the 'inherent' risk.
The four treatment options (avoid, mitigate, transfer, accept) overlap in real organisations, and insurance intuitively feels like it makes the risk smaller.
What to do instead
Build a one-line test for each option: mitigation changes the likelihood or impact; transfer moves the financial consequence to a third party without changing the likelihood; avoidance removes the activity; acceptance is a documented decision to retain the residual risk. Then check the stem for the words 'before controls' (inherent) and 'after controls' (residual) before reading the options.
Selecting the answer that is legal and defensible for the organisation when the stems asks what is ethical, or choosing 'do nothing because no law requires it' over an option that protects the public.
Candidates reason like practitioners protecting an employer rather than applying the profession's code of ethics, and they read 'not illegal' as 'acceptable'.
What to do instead
When the words 'ethical', 'best', 'appropriate' or 'professional' appear, rank the options against the code's order of obligations: protect society and the public, act honourably and justly, provide diligent and competent service, then advance and protect the profession. Compliance is a floor, not the answer.
Confusing the governance document hierarchy - labelling a mandatory measurable requirement as a 'policy', or treating a high-level management intent statement as a 'procedure'.
Organisations use these words loosely in job experience, so candidates map real-world usage onto the exam's stricter definitions.
What to do instead
Apply a fixed ladder: policy = management's high-level intent and mandatory direction; standard = specific mandatory requirements and baselines; procedure = step-by-step instructions to perform a task; guideline = recommended, non-binding advice. Check the option for the words 'steps', 'measurable baseline' or 'management intent' to place it on the ladder.
Classifying a control by its mechanism when the stem asks for its category (or vice versa) - e.g. calling a security awareness programme a 'technical control', or describing a firewall as a 'corrective control'.
The two axes both use the word 'control' and the options are usually all real controls, so the discriminator is the axis, not the example.
What to do instead
Before reading the options, decide which axis the stem names. Category axis: administrative/managerial, technical/logical, physical. Function axis: preventive, detective, corrective, deterrent, compensating, recovery. Silent alarms, logs and monitoring are detective; firewalls, access rules and encryption are preventive and technical; backups and restore testing are corrective/recovery.
Picking a strong control that answers a different question than the stem - for example choosing data encryption when the requirement is to detect unauthorised modification, or choosing a preventive control where the stem explicitly describes containment after an event.
Encryption and firewalls are the 'safe' security answers, so they draw the eye, and candidates match on the topic rather than on the verb in the requirement.
What to do instead
Underline the requirement verb in the stem: prevent, detect, correct, recover, deter, compensate. Match the option's function to that verb first, then to the subject matter. If two options share the subject, the one whose function matches the verb is correct.
Swapping RTO and RPO, or confusing either with MTD - e.g. stating that RPO is 'how long the system may be down' or quoting the maximum tolerable downtime as the backup interval.
The acronyms sound similar and all appear in business impact analysis questions, and candidates answer from recall rather than from what each number measures.
What to do instead
Anchor each term to the loss it bounds: RTO bounds downtime (how long until restored), RPO bounds data loss (how far back the last good copy is), MTD bounds total tolerable outage (RTO must be shorter than MTD). If the stem mentions backups or replication, it is RPO; if it mentions resumption of service, it is RTO.
Ordering incident response by 'severity' intuition rather than by phase - eradicating the root cause or restoring service before containment is complete, or dropping the lessons-learned/post-incident review because the incident is 'over'.
Restoring service fast is the operationally rewarded instinct, and lessons learned produces no visible deliverable, so it is treated as optional.
What to do instead
Force the sequence every time: preparation, detection and analysis, containment, eradication, recovery, lessons learned. Check that containment precedes eradication and recovery in the chosen option, and reject any option that ends at recovery - post-incident review and updates to controls and playbooks are part of the process.
Collecting evidence in the wrong order - imaging or powering down a host before capturing volatile data, or seizing media without documenting who handled it at each transfer.
The instinct is to 'secure the machine' first, and chain-of-custody paperwork feels like an administrative afterthought next to technical collection.
What to do instead
Apply order of volatility before reading options: registers and cache, memory and running processes, network connections and logs, then disk, then backups and archival media. Document each handoff (who, what, when, where, why) as an unbroken record from collection to presentation; any option that skips a link in that chain is wrong even if its technical step sounds correct.