CISSP common mistakes
CISSP · Understand the traps and how to avoid them.
Picks the option with the strongest technical control available (mandatory 256-bit encryption everywhere, disable all USB ports, block all external email attachments) whenever the question asks for the BEST answer, and rejects the option framed around risk tolerance, cost or business enablement.
Most candidates come from hands-on technical roles and have been trained to equate 'more secure' with 'more correct'. CISSP is written from the perspective of a risk advisor reporting to senior management, so the technically maximal answer is often the wrong one.
What to do instead
Before choosing, silently restate the stem as 'what would an experienced security manager recommend to the business?' Then prefer the answer that reduces risk to an acceptable level, references policy/governance/ownership, and preserves business function. If two answers are both technically valid, pick the one a manager could actually approve and fund.
Uses threat, vulnerability, risk, exposure and likelihood as if they were interchangeable, and calculates ALE as asset value times number of incidents per year instead of SLE multiplied by ARO.
The words are near-synonyms in everyday speech, and the quantitative formulas get memorised as a shape ('value times something') rather than as precise relationships.
What to do instead
Write the definitions out once in your own words: threat = potential cause, vulnerability = weakness that a threat exploits, risk = likelihood combined with impact, exposure = the state of being subject to possible loss. Then drill SLE = asset value x exposure factor, ALE = SLE x ARO, and practise solving for each missing variable rather than only the final number.
Assumes the IT administrator or the security team decides how data is classified and who may access it, and assigns retention or destruction decisions to the wrong role.
In daily operations IT staff do perform these tasks, so the candidate's lived experience directly contradicts the governance model the exam tests.
What to do instead
Memorise the accountability chain: the data owner (a senior business manager) is accountable, assigns classification and approves access rules; the custodian (usually IT) implements and operates the controls; users follow the rules; a data steward, where one exists, handles day-to-day quality and retention. Any question about 'who decides the classification level' or 'who authorises access' resolves to the owner.
Selects Bell-LaPadula for a scenario that is actually about integrity (preventing low-integrity data from contaminating high-integrity data) or selects Biba for a confidentiality scenario.
The two models are mirror images ('no read up, no write down' versus 'no read down, no write up'), they are studied back to back, and under time pressure the rules bleed into each other.
What to do instead
Anchor each model to a single keyword before answering: Bell-LaPadula = confidentiality; Biba = integrity; Clark-Wilson = integrity via well-formed transactions and separation of duties. Read the stem first and name the asset being protected (secrecy of the data versus trustworthiness of the data), then pick the model that matches.
Claims that a digitally signed message is therefore confidential, or proposes asymmetric encryption as the way to protect a large data set or backup volume.
Signing and encrypting are usually described in the same paragraph and are both experienced by the user as 'the secure option', so the distinct property each one provides gets flattened.
What to do instead
Map one function to one property every time: symmetric = confidentiality at scale and speed; asymmetric = key exchange and signatures, too slow for bulk data; hash = integrity only; digital signature = authenticity, integrity and non-repudiation, never confidentiality. If the stem asks for confidentiality of a large file, the answer is symmetric encryption with a securely exchanged key.
Assigns protocols, attacks and devices to the wrong OSI layer, for example describing ARP spoofing as a layer 4 attack, placing a switch at layer 3, or calling TLS a layer 4 protocol.
The seven layers are memorised as an ordered list rather than as a map of what each layer actually does, so anything not on the rehearsed list gets guessed by position.
What to do instead
For each layer be able to name one PDU, one device and one attack: L2 frame/switch/ARP or MAC flooding; L3 packet/router/IP spoofing; L4 segment/gateway/SYN flood; L7 data/WAF or proxy/injection. Classify by asking 'what unit of data is being handled here?', not by reciting the list.
Treats authentication and authorisation as a single step, and answers federation questions by swapping SAML, OAuth 2.0 and OpenID Connect interchangeably.
In every real login flow these happen together, and the three acronyms appear side by side in every SSO architecture diagram, so they feel like three names for the same thing.
What to do instead
Hold one line per protocol: SAML = XML-based enterprise SSO carrying authentication and attributes; OAuth 2.0 = delegated authorisation (grants access, does not assert identity); OpenID Connect = an authentication layer built on top of OAuth 2.0. For any stem, first ask whether it wants identity proven or permission granted, then choose.
Uses vulnerability scanning, penetration testing and auditing as synonyms, and picks 'run a vulnerability scan' when the question asks for evidence that a control actually resists a real attack.
All three produce findings reports, tooling overlaps, and vendor marketing deliberately blurs the terms, so the distinctions are rarely sharpened in day-to-day work.
What to do instead
Separate them by goal and by who performs them: scan = broad, automated, enumerates known weaknesses, no exploitation; penetration test = authorised, goal-directed exploitation within a defined scope; audit = independent evaluation against defined criteria or a standard. Match the verb in the stem - 'identify known weaknesses', 'prove exploitability', 'attest to compliance'.
Moves straight to eradication and recovery once the cause is identified, skipping containment and evidence preservation, and answers 'who is notified first' with law enforcement, the regulator or the media.
Real responders are rewarded for restoring service quickly, and news coverage of breaches reinforces the idea that external notification is the headline event.
What to do instead
Default to the disciplined order: preparation, detection and analysis, containment, eradication, recovery, lessons learned - and contain before you touch or rebuild anything. Preserve volatile evidence before making changes, and remember the first notification normally follows the internal escalation path in policy (management, legal, communications), with external parties notified through that channel.
Treats security as a hardening phase performed after code is written - choosing 'penetration test the application before release' when the stem asks how to prevent a class of defect, or mixing up SAST, DAST and software composition analysis.
On most real projects security is engaged late, just before go-live, so 'test it before release' feels like the responsible, familiar answer.
What to do instead
Order activities by how early they can catch defects: security requirements, then threat modelling and design review, then secure coding standards, then SAST in the IDE and CI pipeline, then DAST against a running build, with SCA tracking third-party components throughout. If the stem says 'prevent' or 'most cost-effective', move left in the lifecycle rather than adding a test at the end.