CISO common mistakes
CISO · Understand the traps and how to avoid them.
Answering governance questions as if you were still an operational security engineer: recommending a tool deployment (DLP, SIEM tuning) when the stem asks how to establish accountability for risk decisions across the enterprise.
Most candidates come from hands-on security roles, so their default reflex is technical remediation. CISO-level items test whether you can design decision rights, reporting lines, and oversight bodies, and the technical answer is a distractor that feels satisfyingly concrete.
What to do instead
Before choosing, ask 'who decides, who is accountable, and how is that recorded?' If the option names a control product rather than a forum, charter, policy owner, or escalation path, treat it as a lower-level answer. Practise rewriting each governance stem into an accountability question first.
Selecting the most complete-sounding risk treatment (typically 'mitigate' or 'avoid') instead of the treatment consistent with the stated risk appetite and cost-benefit context in the scenario.
Candidates memorise the four treatment options but not the decision logic. Exam stems usually embed a signal - a tolerance threshold, a residual risk figure, a business constraint - that makes transfer, accept, or avoid the correct answer, and that signal gets skipped under time pressure.
What to do instead
Underline the quantitative or appetite cue in the stem before reading options. Then eliminate any treatment that contradicts the stated tolerance, and check that the chosen treatment is proportionate to the asset value mentioned. Build a one-page decision tree mapping appetite language to treatment.
Treating compliance certification as equivalent to security assurance, and choosing 'achieve ISO 27001 certification' or 'pass the audit' as the answer to a question about demonstrating effective risk management.
Certification is visible, measurable, and heavily marketed, so it feels like the strongest answer. Exam items deliberately test the distinction between conformity (documented process exists) and effectiveness (control actually reduces risk), and candidates blur them.
What to do instead
When an option is a certificate or audit pass, ask whether it proves the control operated effectively. Prefer answers involving control testing, metrics, continuous monitoring, or independent assurance over point-in-time attestation. Note explicitly in your study notes that certification is a baseline, not evidence of efficacy.
Writing strategy answers that list frameworks and standards (NIST CSF, ISO 27001, CIS Controls) as the strategy itself, rather than articulating business objectives, risk appetite, target state, and measurable outcomes.
Framework knowledge is the most easily revised content, so candidates over-index on it. Strategy questions reward alignment with business drivers and a roadmap, and a list of adopted frameworks signals adoption, not direction.
What to do instead
Structure every strategy answer as: business context → risk-informed priorities → capability target state → roadmap with owners and metrics. Reference a framework only as the organising mechanism, never as the deliverable. Draft three practice strategy outlines and check each contains at least two business-outcome statements.
Choosing the option that reports security upward through the CIO or CTO because it is 'more efficient', missing that the item is testing independence and conflict of interest.
In many organisations security does sit under IT, so candidates answer from lived experience rather than from governance principle. Items on reporting lines are testing whether security can challenge the same function that owns delivery pressure.
What to do instead
When reporting lines appear, evaluate independence from the function being overseen. Prefer reporting to the CEO, board risk committee, or CISO with direct board access; treat IT-reporting options as correct only when the stem explicitly describes a small organisation with compensating board-level oversight.
Answering architecture questions by picking the control that stops the specific attack described in the stem, rather than the design principle that reduces the class of risk (segmentation, least privilege, defence in depth, zero trust).
Stems are written as vivid incidents, which pulls attention to the named technique. Architecture items reward abstraction: the right answer usually addresses why the attack succeeded, not the attack itself.
What to do instead
After reading the stem, restate the failure in one abstract sentence ('flat network allowed lateral movement') and choose the option that structurally prevents that class. Reject any option that is a point fix for one technique unless the stem asks for immediate containment.
Selecting 'add another monitoring tool' or 'increase logging' as the fix for a detection gap, when the stem's root cause is unowned alerts, missing triage capacity, or undefined severity criteria.
Operations items often include a plausible tooling option, and tooling feels like decisive action. Candidates miss that the scenario describes a process or staffing failure, and adding telemetry to an unprocessed pipeline worsens the problem.
What to do instead
Diagnose the failure point first: collection, correlation, triage, escalation, or response. Match the fix to that stage. If the stem mentions alert backlog, false positive volume, or undefined ownership, choose process, tuning, or staffing answers over new sensors.
Handling incident-management items by jumping straight to eradication or recovery, skipping containment, evidence preservation, and declaration/notification decisions.
Candidates want to 'fix it', and eradication feels like the substantive step. Exam items test sequence and decision authority - who declares an incident, when legal and regulators are engaged, and how containment is scoped to limit spread without destroying forensics.
What to do instead
Memorise and apply the order: detect → validate/declare → contain → preserve evidence → eradicate → recover → lessons learned. For each practice stem, state the current phase and the next decision owner before looking at options. Treat any option that destroys logs or images as wrong unless the stem explicitly authorises it.
Treating business continuity as IT disaster recovery: choosing data replication, backup restoration, or failover as the answer to a question about maintaining business operations during disruption.
DR is the part of continuity most candidates have operated. Items about BIA, RTO/RPO derivation, manual workarounds, and business-owned recovery plans are answered with technical resilience because that is familiar territory.
What to do instead
Separate the two explicitly in notes: BIA defines impact over time and derives RTO/RPO; continuity covers people, process, facilities, and suppliers; DR covers technology recovery. When a stem mentions customers, revenue, or manual processes, prefer business-continuity answers over infrastructure answers.
Choosing awareness-programme answers built on annual completion rates and phishing click-rate reduction alone, ignoring role-based training, behaviour metrics, and executive sponsorship.
Completion percentage is the easiest metric to report and the most commonly seen in practice, so it reads as the 'correct' measurement. Items test whether training changes behaviour for high-risk roles and whether leadership visibly participates.
What to do instead
Prefer answers that segment training by role and risk, measure behaviour (reporting rates, simulated-incident performance, repeat clickers) alongside completion, and include visible executive participation. Treat any option that only cites annual completion or a single click-rate figure as incomplete.