CISSO common mistakes
CISSO · Understand the traps and how to avoid them.
When asked who owns a control, the candidate answers with the team that operates it (the SOC, the sysadmin, the vendor) instead of the accountable business or system owner, and picks the first plausible operational role in the options.
CISSO-style governance items hinge on the distinction between accountability (the owner who accepts risk) and responsibility (the operator who performs the work). Candidates with hands-on security backgrounds default to the doer because that is who they interact with daily, and exam distractors are deliberately written as the operational role.
What to do instead
Before answering any ownership question, classify each option as accountable, responsible, consulted, or informed. The correct answer for 'who owns the risk' or 'who accepts residual risk' is almost always the business/system/data owner or the authorizing official, never the implementer. Practice by writing the accountable role next to each control in a one-page RACI for a system you know.
The candidate treats a risk assessment as a one-time deliverable tied to a project or audit and selects 'perform the assessment' as the fix for a newly discovered threat, rather than selecting continuous monitoring or reassessment triggers.
Training and many internal processes frame risk assessment as a document produced before go-live. Exam items test whether the candidate understands that risk changes when the threat landscape, architecture, or data sensitivity changes, and the 'assess once' answer is a comfortable, familiar distractor.
What to do instead
Memorize reassessment triggers: significant architecture change, new data classification, new threat intelligence, major incident, vendor change, and scheduled review intervals. When an item describes a change in conditions, prefer the answer that re-evaluates and updates the risk register over the one that simply repeats the original assessment.
The candidate selects the strongest available control (for example, full disk encryption everywhere, or a hard block on all USB ports) instead of the control proportionate to the identified risk and business need.
Security professionals are conditioned to advocate maximum protection, and 'most secure' feels like the safe answer. CISSO items reward proportionality, cost-benefit reasoning, and alignment with business mission, so the maximalist option is frequently the wrong one.
What to do instead
For every control-selection item, ask what the asset's classification and the risk rating justify, and whether the option names a residual risk acceptance path. Choose risk-based, layered controls with a documented rationale; treat 'strongest' or 'all' as red flags unless the item explicitly states a high-impact, high-sensitivity context.
The candidate answers architecture questions with a product or vendor category ('install a WAF', 'buy an EDR') when the item is asking for a design principle such as least privilege, defense in depth, segregation of duties, or fail-safe defaults.
Product-first thinking is reinforced by day-to-day operations and by marketing-heavy study material. Items that describe a design weakness are testing whether the candidate can map the weakness to a principle, and product answers are written to sound authoritative.
What to do instead
Build a one-line definition and a one-line example for each core principle: least privilege, separation of duties, defense in depth, fail-safe/fail-secure defaults, complete mediation, economy of mechanism, open design, and least common mechanism. When an item describes a design flaw, name the principle first, then look for the option that restores it rather than the option that adds a tool.
The candidate confuses encryption, hashing, encoding, and tokenization, or picks encryption as the answer for integrity and password-storage scenarios where hashing with a salt is required.
The terms are used loosely in vendor documentation and in everyday conversation, and all four 'protect' data in some sense. Items that describe storing credentials or verifying integrity are designed to catch candidates who reach for confidentiality controls by reflex.
What to do instead
Anchor each primitive to the property it provides: encryption for confidentiality (reversible with a key), hashing for integrity (one-way, salted for passwords, use a memory-hard algorithm), encoding for format only (no security), tokenization for reducing scope. Read the item's stated goal word by word and match the property before looking at options.
The candidate describes incident response as starting with containment or eradication, skipping identification and the initial triage that establishes scope, or jumps straight to pulling the plug on a system.
Under time pressure the instinct is to act, and containment feels like the decisive step. Exam items test sequencing and the trade-off between preserving evidence and stopping spread, so an answer that contains first without validating the incident is a common trap.
What to do instead
Internalize the order prepare, detect and identify, contain, eradicate, recover, and lessons learned, and note that containment strategy depends on scope and evidence needs. For each scenario, ask whether the item has established what happened and how far it spread; if not, the correct answer is triage and scoping, not eradication.
The candidate orders a system wiped or rebuilt before forensic preservation, or selects 'restore from backup' as the first forensic step, destroying volatile evidence such as memory and logs.
Recovery urgency and the desire to 'clean' a compromised host dominate operational habits. Items that mention an investigation, legal hold, or law enforcement are testing order of volatility and chain of custody, and the recovery answer is placed as a tempting distractor.
What to do instead
Memorize order of volatility (CPU registers and cache, memory, network state, running processes, disk, remote logs, archival media) and the rule that preservation precedes remediation when an investigation or legal matter exists. When an item mentions legal hold, regulators, or prosecution, choose the option that captures and documents evidence with a chain of custody before any rebuild.
The candidate treats disaster recovery as a backup question and selects the backup technology rather than the recovery objective, confusing RTO with RPO or selecting the cheapest option without checking it against stated objectives.
Backups are the most familiar DR artifact, and RTO/RPO are easy to swap under exam pressure. Items often give explicit recovery time and recovery point requirements precisely to see whether the candidate applies them to the option set.
What to do instead
Write the definitions until automatic: RTO is maximum tolerable downtime, RPO is maximum tolerable data loss. For every DR item, extract the stated time and data-loss limits first, then eliminate any option whose recovery method cannot meet them, and check that the plan names testing, alternate site strategy, and dependency order for restoration.
The candidate assumes a certification, accreditation, or audit finding is closed once the technical fix is deployed, without addressing documentation, evidence, and the formal approval or risk-acceptance step.
Engineers measure closure by remediation of the technical condition, while compliance frameworks require documented evidence and an authorizing decision. Items describing an audit finding or an authorization decision are testing the process, not the patch.
What to do instead
For any finding or accreditation item, look for the option that includes documented remediation evidence, validation or retest, and formal sign-off or updated authorization. If a residual risk remains, the correct answer involves the authorizing official accepting it in writing, not the security team deciding on its own.
The candidate answers legal and regulatory items from general best practice, ignoring jurisdiction, contractual flow-down, data subject location, and notification timelines, or assumes one global regulation applies uniformly.
Study material often summarizes requirements without the jurisdictional nuance, and candidates transfer habits from their own region. Items that mention cross-border data, third parties, or breach notification are testing whether the candidate identifies the applicable obligation and its deadline.
What to do instead
For each legal item, first identify the data type, the subjects' location, the contractual obligations, and the sector regulator, then apply the strictest applicable requirement and its notification clock. Build a short reference table of the frameworks you are accountable for, including breach notification windows and cross-border transfer conditions, and cite the obligation rather than a generic control.