ISC2 CSSLP common mistakes
ISC2 CSSLP · Understand the traps and how to avoid them.
When asked where in the SDLC security activities belong, the candidate selects a single phase - usually Testing or Implementation - and rejects the option that distributes activities across every phase.
The candidate mentally equates 'security work' with penetration testing and scanning, and has memorised phase-by-phase checklists as isolated silos rather than as a continuous lifecycle with feedback loops.
What to do instead
Reframe each phase as owning a specific security artifact: Concepts (risk appetite, CIA trade-offs), Lifecycle Management (governance gates, metrics), Requirements (misuse/abuse cases), Design (threat model), Implementation (code review, secure coding standards), Testing (verification of requirements), Deployment/Ops (hardening, monitoring), Supply Chain (provenance). When an item appears in two phases, prefer the earliest phase where it can be cost-effectively performed.
Classifying controls by the wrong category - e.g., labelling encryption, firewalls or access control lists as detective or corrective controls, or describing a compensating control as a primary control.
Candidates memorise control names without mapping them to the control's timing and purpose (prevent / detect / correct / deter / compensate / recover), and many real controls do several things, so the candidate picks on intuition rather than on the stated objective.
What to do instead
Read the control's stated purpose in the stem and ask 'what happens to the threat at this moment?' If the action stops the event before it occurs it is preventive; if it records or notices it, detective; if it restores after, corrective/recovery; if it stands in for an unavailable control, compensating. Encryption of data at rest is preventive against disclosure; log monitoring is detective; restoring from backup is corrective.
Accepts security requirements written as adjectives ('the application shall be secure', 'the system shall protect sensitive data') as a valid answer choice instead of recognising them as unverifiable.
These sentences sound like what a policy document says, so they feel authoritative, and candidates under time pressure confuse 'sounds like a requirement' with 'is a testable requirement'.
What to do instead
Apply the testability screen: a usable security requirement names an actor, an asset, a measurable threshold and a verification method (e.g., 'after 3 failed authentications within 5 minutes the account locks for 15 minutes, verified by functional test TC-xx'). If you cannot write the test case from the sentence, the option is wrong. Also derive requirements from data classification, regulatory obligations and misuse/abuse cases, not from generic good intentions.
Treats threat modelling as a single design-phase deliverable that is 'completed' once a diagram is drawn, and selects an option that avoids revisiting the model after architecture or feature changes.
Threat modelling is taught as a discrete workshop technique, so candidates picture a one-off meeting rather than a living artifact tied to change management and re-assessment triggers.
What to do instead
Anchor on three properties: it is iterative, it is triggered by change (new data flow, new trust boundary, new third-party component), and it produces tracked, prioritised mitigations with owners. If a choice describes threat modelling as finished, archived or design-only, eliminate it; prefer the choice that re-runs on change and feeds residual risk back into requirements and test cases.
Consistently picks the strongest technical control offered (maximum key length, total lockout, mandatory MFA everywhere) rather than the control that satisfies the stated risk while preserving business function and cost.
Candidates import a 'more security is always the right answer' heuristic from technical certification exams, but CSSLP is a management exam where the best answer is risk-appropriate and defensible to the business.
What to do instead
Before committing, re-read the stem for the business constraint (usability, availability, budget, regulatory scope). Reject options that are unachievable given the stated constraint or that create unacceptable availability/operational impact, and prefer the layered or compensating option that meets the requirement at proportionate cost, documented with rationale and residual risk acceptance.
Chooses client-side input validation, hidden fields, or obfuscation as the defence against tampering or injection, or selects a blacklist-based filter over an allowlist.
Client-side checks visibly appear to reject bad input during a demo, and obfuscation feels like protection, so the candidate who has not internalised the trust-boundary rule mistakes presentation-layer behaviour for an enforcement control.
What to do instead
Apply the rule 'never trust the client': all validation and authorisation decisions are re-enforced server-side, with client-side checks considered usability only. For input handling prefer positive/allowlist validation with canonicalisation and output encoding at the sink. Treat obfuscation, hidden fields and commented-out code as obscurity, never as a control.
Mixes up the coverage of testing techniques - recommending dynamic analysis to find hard-coded secrets or unsafe library calls, static analysis to find runtime configuration weaknesses, or asserting that a clean penetration test proves the absence of vulnerabilities.
The technique names are learned as a list rather than as a map of what each can and cannot see, and a passed pen test feels like a binary proof of security.
What to do instead
Memorise by vantage point: SAST inspects source/bytecode without execution (finds coding flaws, taint paths, secrets in code but produces false positives and misses runtime/config issues); DAST exercises the running app from outside (finds runtime and config issues but poor code-level localisation); IAST instruments runtime with code context; SCA inspects dependencies. No single technique or test result proves absence of defects - verification is evidence of coverage against defined requirements, not a guarantee.
When a production vulnerability or incident is disclosed, selects 'immediately patch', 'immediately notify the public', or 'immediately shut the service down' as the first action, skipping triage, containment and validation.
Urgency framing in the stem plus a desire to appear decisive pushes candidates past the response lifecycle; they answer with the most dramatic action rather than the first ordered step.
What to do instead
Default to the sequence: detect and validate the finding, triage and assess risk/impact, contain, eradicate, recover, then communicate and conduct lessons learned. Patching is eradication and follows containment; disclosure follows assessment and legal/communications review. If a stem asks 'first', the answer is almost always confirm/assess, not act.
Answers a third-party or open-source component risk question with 'require the vendor to fix it' or 'trust the vendor's security page', omitting contractual, technical and verification safeguards.
Candidates treat acquisition as a procurement formality and underestimate that supply chain risk persists after purchase; they also conflate open-source risk with licence compliance only.
What to do instead
Expect a layered answer: security requirements and right-to-audit / breach-notification clauses in the contract, vendor assurance evidence (attestations, test results, certification scope), an SBOM with component provenance and version tracking, continuous monitoring for new CVEs in components, and a defined patch/exit strategy. Nothing a vendor promises verbally counts - the control must be contractual, technical or verifiable.
Confuses accountability for security with execution of security tasks - e.g., answering that the security team, the developer or the auditor is accountable for residual risk, or that an external auditor 'signs off' the system as secure.
In real organisations security teams do most of the visible work, so the candidate maps 'does the work' to 'owns the outcome', missing the governance distinction between accountable, responsible, consulted and informed.
What to do instead
Hold the line that business/system ownership carries accountability for risk decisions and acceptance of residual risk (senior management for enterprise risk), while security practitioners are responsible for defining standards, reviewing and advising, and auditors provide independent assurance only - they never own or accept risk. When a stem mentions accepting residual risk, look for the business or system owner, not the security function.