CPIT InfoSec common mistakes
CPIT InfoSec · Understand the traps and how to avoid them.
Treating risk as a single number and answering 'accept the risk' or 'mitigate' without first identifying who owns the risk and what the risk appetite/tolerance is; jumping straight to a control recommendation when the stem asks for the next step in the risk management process.
Candidates memorize the risk treatment options (avoid, transfer, mitigate, accept) as a vocabulary list and pattern-match the word 'risk' to one of them. The exam often tests the sequence: identify assets, assess likelihood/impact, compare to tolerance, then treat, with the risk owner (business owner, not IT) making the acceptance decision. Candidates also forget that residual risk must be documented and accepted by the accountable owner.
What to do instead
Drill the sequence explicitly: asset identification → threat/vulnerability assessment → likelihood × impact → compare against risk appetite → treatment decision by the risk owner → document residual risk → monitor. When a stem asks 'what should the security manager do FIRST', answer with the earliest step in that chain, not the control. Practice classifying who owns each risk (data owner for data, system owner for systems, business unit for business process risk) and remember that IT/security recommends, the business accepts.
Confusing policies, standards, procedures, and guidelines, and misassigning which document type contains mandatory technical specifics versus high-level management intent.
The terms are used loosely in real workplaces, so candidates rely on colloquial usage. On the exam, a policy states management intent and is mandatory but high-level; standards are mandatory and specific (e.g., 'AES-256, TLS 1.2 minimum'); procedures are step-by-step operational instructions; guidelines are recommended but optional. Candidates pick 'policy' for anything authoritative or 'standard' for anything detailed.
What to do instead
Build a four-row table with the defining attribute (mandatory vs. recommended, high-level vs. specific, who approves, review cycle) and classify ten sample statements from memory. Anchor on the test: if it says 'must' and names a specific value or technology, it is a standard; if it says 'should' and gives advice, it is a guideline; if it describes who does what in what order, it is a procedure.
Choosing a defense-in-depth control that is 'stronger' but placed at the wrong layer, or selecting a detective control when the requirement is preventive (or vice versa), instead of matching the control to the specific threat path and asset.
Candidates optimize for 'most secure' rather than 'most appropriate'. Architecture questions usually hinge on where a control sits relative to the data flow and whether it prevents, detects, corrects, or compensates. A WAF does not stop a compromised internal host; network segmentation does not stop a stolen credential used from inside the segment. Without tracing the attack path, candidates pick the control with the most impressive name.
What to do instead
For every architecture question, draw the data flow in your head: asset → trust boundary → control point → attacker position. Then ask whether the control (a) prevents at that boundary, (b) detects after the fact, or (c) limits blast radius. Classify each candidate control by type (preventive/detective/corrective/compensating) and layer (network/host/application/data/identity) before choosing. Eliminate options that sit on the wrong side of a trust boundary.
Defaulting to 'segment the network' or 'add a firewall' for every network scenario, and misplacing controls relative to zones (DMZ, internal, management) and traffic direction (north-south vs. east-west).
Segmentation is a safe-sounding answer, so it survives elimination even when the stem describes an internal lateral-movement problem, a DNS exfiltration problem, or a management-plane exposure. Candidates also forget that a DMZ host should not initiate connections into the internal network, and that management interfaces belong on an out-of-band management network, not the production VLAN.
What to do instead
Memorize zone roles and permitted flow directions: internet → DMZ (inbound to published services only), DMZ → internal (denied or tightly brokered), internal → internet (proxied/egress filtered), management plane (separate, jump-host mediated). For each scenario, first label the traffic as north-south or east-west, then choose the control that fits that direction. Reject options that put management interfaces on user VLANs or allow DMZ-to-internal initiated sessions.
Treating authentication, authorization, and accounting as interchangeable, and picking 'MFA' as the answer for questions about least privilege, session management, or access review.
MFA is strongly associated with 'security best practice', so candidates select it for any identity question. But many stems test authorization models (RBAC vs. ABAC vs. MAC/DAC), least privilege, separation of duties, or periodic access recertification, where MFA is irrelevant. Candidates also confuse authentication (proving identity) with authorization (what you may do) and with federation assertions vs. actual credentials.
What to do instead
For each identity question, write one word first: authenticate, authorize, or account. Then match: authentication → factors, federation, credential storage; authorization → RBAC/ABAC/MAC/DAC, least privilege, SoD; accounting → logging, session records. Only choose MFA when the stem is about proving identity or defeating credential replay. Practice distinguishing 'who can access this resource' (authorization) from 'how do we know who they are' (authentication).
Assuming 'stronger algorithm' is always the right answer, and confusing hashing, encryption, and digital signatures; misassigning symmetric vs. asymmetric use cases and ignoring key management lifecycle.
Candidates learn algorithm names without their properties: hashing is one-way (integrity, not confidentiality), symmetric is fast and needs shared keys (bulk data), asymmetric solves key distribution and enables signatures (non-repudiation), and signatures require the sender's private key. Many stems actually test key lifecycle (generation, distribution, rotation, escrow, destruction) or the difference between encryption for confidentiality and signing for authenticity/integrity, where the algorithm choice is secondary.
What to do instead
Build a matrix: purpose (confidentiality/integrity/authenticity/non-repudiation) × key type (symmetric/asymmetric) × typical use (bulk data, key exchange, signatures, password storage). For every crypto question, name the security property required first, then the primitive that provides it. Separately memorize the key lifecycle stages and when escrow, rotation, and destruction apply, since many stems hinge on those rather than the cipher.
Answering host/endpoint questions with 'patch and antivirus' regardless of the scenario, and ignoring application-layer issues like input validation, output encoding, parameterized queries, and secure defaults.
Patching and AV are the most familiar controls, so they dominate. But many stems describe injection, XSS, insecure deserialization, or misconfiguration where the correct answer is a coding or configuration control (parameterized queries, context-aware output encoding, allow-listing, disabling default accounts). Candidates also forget that patching is a corrective/preventive control for known vulnerabilities and does nothing for logic flaws or zero-days.
What to do instead
Classify the vulnerability class in the stem first (injection, XSS, broken access control, misconfiguration, deserialization, supply chain), then choose the control that removes the root cause, not the symptom. Memorize the root-cause fix for each OWASP-style class: parameterized queries for SQLi, output encoding for XSS, server-side authorization checks for broken access control, secure defaults and hardening for misconfiguration. Reserve patching for known-vulnerability and configuration-drift scenarios.
Confusing monitoring, detection, and response activities: choosing 'review logs' when the stem asks for containment, or 'isolate the host' when the stem asks for the first detection step; also misordering incident response phases.
Candidates memorize the IR lifecycle loosely and then apply the most dramatic action. The exam tests sequencing: preparation → detection/analysis → containment → eradication → recovery → lessons learned, and often asks for the next action given a specific state. Candidates also conflate a SIEM alert (detection) with triage (analysis) and with containment, and forget that evidence preservation must precede destructive containment steps.
What to do instead
Memorize the phase order and, for each stem, identify the current phase before reading the options. Then eliminate options that belong to a later phase. Practice the rule: preserve volatile evidence before shutdown/reboot; contain before eradicate; eradicate before recover; document lessons learned after recovery. Distinguish 'detect' (alert fired) from 'analyze' (is it a true positive, what is the scope) from 'contain' (stop spread).
Treating BCP and DR as synonyms, and answering with the wrong metric (RTO vs. RPO vs. MTD vs. MTTR) or the wrong recovery strategy tier for the stated outage tolerance.
The terms overlap in casual use. On the exam, BCP covers keeping the business function operating (people, process, alternate sites, manual workarounds), while DR covers restoring technology and data. RTO is maximum tolerable downtime for a function, RPO is maximum tolerable data loss (backup frequency), MTD is the point of unacceptable business impact, and MTTR is how long repair actually takes. Candidates pick 'offsite backups' for scenarios that need hot-site or active-active continuity.
What to do instead
Build a decision table: business impact tolerance → RTO/RPO → recovery strategy (backup/restore, warm site, hot site, active-active) → cost. For each scenario, extract the stated tolerable downtime and tolerable data loss, then choose the cheapest strategy that meets both. Explicitly separate the business-continuity answer (alternate process, manual workaround, alternate site for people) from the DR answer (restore systems and data), and never answer a business-function question with a purely technical recovery option.
Applying a purely technical fix to a privacy/legal question, or ignoring data classification, lawful basis, retention, cross-border transfer, and breach-notification obligations when the stem is about personal data.
Candidates default to encryption or access control because those are familiar, but privacy stems often test whether the processing is lawful and minimal in the first place (purpose limitation, data minimization, consent/lawful basis), or which regulator/party must be notified and within what timeframe. Candidates also forget that pseudonymization is not anonymization, and that retention limits and data subject rights are process controls, not technical ones.
What to do instead
For any personal-data stem, run a checklist: what data, what lawful basis, minimum necessary, how long retained, who it is shared with, where it crosses borders, and what happens on breach (who is notified, how fast). Choose the option that addresses the legal/process gap first; only then consider technical safeguards. Memorize that pseudonymized data remains personal data, that anonymization must be irreversible, and that breach notification duties and timelines are jurisdiction-specific, so pick the answer that reflects the stated jurisdiction rather than a generic 'notify everyone'.