CC common mistakes
CC · Understand the traps and how to avoid them.
In a CIA scenario question, the candidate sees the words 'encryption' or 'password' and immediately selects Confidentiality, even when the scenario describes records being silently altered or a system being knocked offline for hours.
The exam deliberately reuses familiar technical vocabulary as distractors, so candidates pattern-match on the technology named instead of the outcome described.
What to do instead
Before looking at the options, write one phrase: what actually went wrong? Disclosure to an unauthorized party = Confidentiality; unauthorized or inaccurate change = Integrity; loss of timely access = Availability. Then choose the principle that matches that phrase, not the technology mentioned.
Classifies a control by the tool's name instead of its function or category: calls an intrusion detection system 'preventive' because it is a security product, and calls a written security policy 'technical' because it talks about technology.
Job roles and vendor marketing frame security by product, so candidates default to product categories; the exam tests function (prevent/detect/correct/deter/recover) and category (administrative/technical/physical) as two separate axes.
What to do instead
Answer two independent questions for every control: (a) What does it do to an attack - stop it, notice it, fix it, discourage it, or substitute for another control? (b) Who or what implements it - a person with a document (administrative), a system setting (technical), or a physical object (physical)? Never infer one axis from the other.
Chooses 'policy' for an option that lists step-by-step actions, or chooses 'procedure' for a high-level management statement of intent about protecting data.
In everyday usage these governance words overlap loosely, while the exam treats them as a strict, non-interchangeable hierarchy with different audiences and levels of detail.
What to do instead
Memorize by function, not by wording: policy = mandatory management intent, no detail; standard = mandatory specific requirement or metric; procedure = mandatory step-by-step 'how'; guideline = recommended and optional. If the option contains numbered steps or an ordered sequence, it is a procedure regardless of how formal it sounds.
Selects the security team, the IT department, or the analyst who discovered the issue as the party that accepts residual risk or approves a risk treatment plan.
Technically skilled candidates assume that technical authority implies decision authority; CC deliberately separates the people who identify and measure risk from the people who own it.
What to do instead
Anchor on ownership: risk acceptance belongs to senior management or the business/data owner who owns the asset and its budget. The security function identifies, advises, and monitors risk; it never accepts risk on the business's behalf. Options naming a security role as the risk acceptor are almost always wrong.
Answers a question about 'what a user is allowed to do' by selecting authentication, or describes entering a username and PIN as the authorization step.
Both occur inside the same login flow, the words look nearly identical, and the sequence feels like a single event rather than two distinct decisions.
What to do instead
Hold two definitions in mind: authentication = proving who you are, using something you know, have, or are, and it always happens first. Authorization = what that now-proven identity may reach, expressed as permissions, roles, or access control models. If the option mentions resources, rights, or permitted actions, it is authorization.
Treats a hash as a reversible way to keep data secret, or selects asymmetric encryption to protect a large database at rest because it is 'more secure'.
All three are 'cryptography' in casual reading, and the distractors swap the three terms inside otherwise plausible sentences so the answer feels familiar.
What to do instead
Lock in three one-liners and check the option against them: hashing = one-way integrity fingerprint, never reversible, never used for confidentiality; symmetric = one shared key, fast, used for bulk data at rest and in transit; asymmetric = key pair, slow, used for key exchange, digital signatures, and non-repudiation.
Selects the cloud provider as responsible for customer data classification, identity and access configuration, or an unpatched guest operating system, reasoning that 'the cloud is the provider's job'.
Provider marketing about a 'secure cloud', plus the customer's invisibility into the physical layer, encourages the assumption that everything has been outsourced.
What to do instead
Split every scenario with two questions: 'Who can physically touch it?' (provider: facilities, hardware, hypervisor, the underlying infrastructure of a managed service) and 'Who can misconfigure it?' (customer: data, identities and access, configuration, and everything above the service-model boundary - OS and up for IaaS, mostly data and users for SaaS).
Chooses an intrusion prevention system for a requirement to 'detect and alert', or places a packet-filtering firewall at Layer 7 of the OSI model.
Product names suggest functions imprecisely, and the OSI model is memorized as a recited list rather than as the layer at which each control actually operates.
What to do instead
Use two decision rules: if the correct answer must stop traffic it must be inline, so IDS (passive, out-of-band, alerts only) cannot be it; and map devices by what they inspect - MAC switching at Layer 2, IP routing and ACL filtering at Layers 3–4, content or application inspection and web application firewalls at Layer 7.
Orders incident response actions with eradication or recovery before containment, or jumps straight to containment as the first action after an alert without an analysis step.
Urgency bias: candidates want to fix the problem, and the words 'eradication' and 'recovery' feel like solving it, so they skip the sequence the exam is testing.
What to do instead
Memorize the fixed order - Preparation, Detection and Analysis, Containment, Eradication, Recovery, Lessons Learned - and apply two checks: containment always precedes removal of the cause, because spread must stop first; and the phase that follows detection is analysis, not action.
Swaps RTO and RPO when asked how much data loss is tolerable, or treats the business continuity plan and the disaster recovery plan as a single interchangeable document.
Both metrics read as 'recovery time' colloquially and both plans deal with outages, so the distinction collapses under time pressure.
What to do instead
Fix the direction of each: RTO = how long the business can wait for the service to return, measured forward from the failure, so it drives redundancy; RPO = how much data loss is acceptable, measured backward from the failure to the last good copy, so it drives backup frequency. Then separate scope: BCP keeps the whole business running (people, processes, facilities); the DRP is the technical subset that restores IT systems and data.