ISSMP common mistakes
ISSMP · Understand the traps and how to avoid them.
When a stem asks what the CISO or security manager should do FIRST, the candidate selects a specific technical control (deploy MFA, enable logging, patch the server) instead of the governance or programmatic action the role actually owns.
Most candidates arrive from hands-on engineering or analyst roles, so the most vivid, concrete answer feels the most 'correct'; technical answers are also the easiest to picture being implemented.
What to do instead
Before reading the options, identify the role in the stem (CISO, steering committee, system owner, SOC analyst) and the verb (approve, sponsor, charter, delegate). Eliminate any option that the named role would not personally perform; the remaining answer is usually policy, sponsorship, funding, or assignment of accountability.
Reporting program health to executives using activity counts (number of scans run, tickets closed, patches deployed) rather than metrics tied to business risk, control effectiveness, or trend.
Activity data is what the security team already collects in its tooling, so it is the easiest to produce and feels like evidence of a well-run program.
What to do instead
For any question about executive reporting, ask 'what decision does this metric support?' Choose the option expressing residual risk, control coverage against critical assets, time-to-remediate trends, or alignment to business objectives; treat raw volume counts as distractors.
When asked where in a project security requirements or controls should be introduced, the candidate picks the testing, hardening, or go-live phase because that is where vulnerabilities are found and where security staff usually get engaged.
Security teams are typically pulled in late in real organizations, so late-phase answers match the candidate's lived experience rather than the intended process model.
What to do instead
Anchor on the rule that cost of change rises and remediation options shrink across the lifecycle. When the stem asks for the MOST effective or LEAST costly point to influence security, select the requirements or design phase unless the stem explicitly describes an already-deployed system.
Treating change management and configuration management as interchangeable, or selecting an answer that lets an emergency change bypass security review and baseline update entirely.
The two disciplines overlap in practice and the terms are used loosely at work, so the distinction blurs under exam time pressure.
What to do instead
Memorize the split: change management decides whether and when a change is authorized; configuration management records and controls the state of the asset and its baseline. Any correct option keeps authorization, security impact assessment, and baseline/documentation update together, even on an emergency path.
Concluding that controls are adequate because the organization passed an external audit or holds a certification, and choosing 'no further action' or 'reduce monitoring' as a result.
Certification is highly visible and socially persuasive, and candidates conflate 'met the auditor's sample test on that date' with 'controls are operating effectively now.'
What to do instead
When an option rests on a past audit as proof of security, treat it as a distractor. Correct answers in this domain favor continuous monitoring, scoping checks, evidence freshness, and treatment of exceptions, since a point-in-time attestation covers only sampled controls at a point in time.
Selecting 'accept the risk' or 'transfer the risk via insurance' without confirming that the accountable risk owner and, where required, senior management have formally authorized that decision.
Acceptance reads as the cheapest and fastest option and candidates mentally place decision authority with the security team because the security team identified the risk.
What to do instead
Recall that the business or asset owner owns the risk and the security function advises. Eliminate acceptance or transfer options that lack an explicit owner sign-off, documented rationale, and review date; prefer the option that routes the decision to the accountable party.
Choosing a treatment based purely on the quantitative result, e.g. rejecting a control because annualized loss expectancy is lower than the control's annual cost, while ignoring regulatory, contractual, safety, or reputational exposure.
The arithmetic is memorable and feels objective, so candidates treat the number as the whole decision rather than one input.
What to do instead
When a stem includes regulatory or contractual obligations, safety, or reputation alongside the loss figures, the correct answer accounts for those non-monetary factors. Use the quantitative comparison only when the scenario is purely financial and data quality is explicitly sound.
Ordering incident response actions incorrectly, most often choosing eradication or full root-cause analysis before containment, or notifying external parties before the incident is scoped.
Eradication feels like 'fixing the problem' and notification feels like taking responsibility, so both are attractive under pressure, while containment sounds passive.
What to do instead
Apply the fixed order: preparation, detection and analysis, containment, eradication, recovery, lessons learned. Choose the action that stops spread and preserves evidence first; place communication and long-term remediation after containment unless the stem involves a legal or regulatory reporting clock that has already started.
Reducing threat intelligence to feed consumption and indicator blocking, and picking the option that adds another data source when the stem asks how to improve the intelligence program.
Tooling and IOC feeds are the visible artifacts of threat intelligence, so 'buy more feeds' feels like progress, and the requirements-and-dissemination phases are invisible in day-to-day operations.
What to do instead
Frame every threat intelligence question against the intelligence cycle: requirements and direction, collection, processing, analysis, dissemination, feedback. If the stem describes unfocused data or unused reports, select the option that defines intelligence requirements or improves dissemination to decision-makers, not the option that adds collection.
Skipping straight to recovery strategy or backup restoration in a continuity question, or declaring the plan validated after a tabletop exercise alone.
Backups and restoration are familiar and concrete, while the business impact analysis and exercise-type hierarchy are abstract, so the tangible answer wins.
What to do instead
In continuity stems, locate the missing step in the sequence: business impact analysis to set RTO and RPO, then strategy selection, then plan, then exercise. Choose the option that fills the earliest gap. For validation questions, remember a tabletop tests plans and roles, while failover and full-scale exercises test actual recovery capability.