CISAW ES common mistakes
CISAW ES · Understand the traps and how to avoid them.
Treating the CIA triad as three interchangeable words and answering 'confidentiality' for any control that involves encryption or passwords, even when the scenario is about data being altered in transit or a system being unavailable.
Candidates memorise the acronym but never attach a decision test to each leg, so under time pressure they match on the surface keyword (encryption, password) rather than on the security property the scenario actually describes.
What to do instead
Before answering, write one line: what is the harm in the scenario - someone reading it (confidentiality), someone changing it (integrity), or nobody being able to use it (availability)? Then pick the control that addresses that harm. Practise with mixed scenarios where a hash protects integrity, a backup protects availability, and encryption protects confidentiality.
Classifying every privacy or data-handling question as a compliance question and citing a law, when the question is actually asking which security objective or control class applies.
Law and regulation content is memorable and heavily emphasised in study material, so candidates over-apply it and stop reading the actual stem, which may be about least privilege or data minimisation as a design principle.
What to do instead
Read the stem's final clause first to identify what is being asked (a principle, a control, a legal obligation, or a role). Only invoke a specific law when the stem names a jurisdiction, a data subject right, or a breach notification timeline.
Treating risk appetite, risk tolerance, risk capacity, and risk threshold as interchangeable terms.
The vocabulary is similar in ordinary usage, and many study resources use them loosely. Exam items discriminate precisely: appetite is the amount of risk the organisation is willing to pursue, tolerance is the acceptable variation around a target or limit, capacity is the maximum it could withstand, and thresholds are the concrete trigger points.
What to do instead
Memorise one-line operational definitions and a distinguishing example for each. When two options both sound right, choose the one that matches the specific term used in the stem rather than a neighbouring concept.
Confusing risk treatment ownership with risk ownership: assuming the risk practitioner owns, and is accountable for, the identified risk.
The practitioner facilitates the process; the business process or asset owner owns the risk and the treatment decision. Candidates with a controls or compliance background default to the practitioner being accountable, which leads to wrong answers about who accepts residual risk.
What to do instead
On any ownership or sign-off question, map roles explicitly: risk practitioner advises, monitors, and reports; the business owner owns and accepts; senior management sets appetite; the board provides oversight. Choose the option that places accountability with the business owner unless the stem says otherwise.
Treating a technical or security control as a substitute for a governance or risk-process answer when the stem is about oversight, roles, or strategy.
Technical candidates gravitate to familiar controls (patching, encryption, MFA, logging) and pick the most technically reassuring option, missing that the stem asks about policy, accountability, or alignment with enterprise objectives.
What to do instead
Read the stem for governance signals: strategy, objectives, roles and responsibilities, policy, oversight, alignment, performance measurement. If present, exclude pure technology options even when they would genuinely reduce the risk.
Confusing authentication with authorisation and assigning the wrong control to a scenario, for example answering 'multi-factor authentication' when the question is about limiting what a logged-in user can reach.
Both live in the same identity domain and both are described with similar vocabulary (access, permissions, credentials), so candidates pattern-match on 'access' and pick the wrong half of the pair.
What to do instead
Distinguish identity verification from the authorization decision for the actual request. Some resources allow unauthenticated public access, and authorization can be checked repeatedly during a session. Roles and permissions concern allowed actions rather than merely proving who supplied a credential.
Treating symmetric and asymmetric keys as interchangeable and choosing the wrong key for a task, such as using a public key to decrypt a password vault or a private key to encrypt bulk data.
The key pair vocabulary is learned as a pair of words rather than as a workflow, so candidates cannot reconstruct who holds which key and what each operation achieves.
What to do instead
Draw the two-party diagram once from memory: sender encrypts with the recipient's public key, recipient decrypts with their own private key; sender signs with their own private key, verifier checks with the sender's public key. Rehearse it until you can derive any key question from the diagram rather than recall.
Answering control-design questions with control-testing or monitoring activities, and vice versa.
Control design, operating effectiveness, and continuous monitoring appear together in real programmes, so candidates conflate them. Exam stems often hinge on whether a control exists on paper versus whether it actually worked in practice.
What to do instead
Label the question first: 'does the control exist and is it designed suitably?' (design), 'did it operate as intended over the period?' (effectiveness), or 'is it still working now?' (monitoring). Then eliminate options that answer a different one of those three questions.
Assuming an emerging-technology risk should be avoided or blocked until it is fully understood, rather than managed through incremental assessment and monitoring.
Uncertainty feels like a reason to stop, and regulatory or security caution reinforces that instinct. CRISC expects emerging risk to be assessed, piloted, and monitored with defined triggers, not reflexively prohibited.
What to do instead
When a stem describes new or evolving technology with limited information, prefer the option that combines a bounded assessment with defined monitoring triggers and review points. Treat 'prohibit until proven safe' and 'proceed without assessment' as the two distractors.
Assuming a firewall or IDS alone stops an attack, and choosing 'install a firewall' as the fix for problems that are actually about inspection of encrypted traffic, lateral movement inside a trusted zone, or application-layer payloads.
Perimeter devices are the most familiar control in the network domain, and candidates default to them because they can picture the device, not because it addresses the specific failure described.
What to do instead
For each network scenario, name the layer first (packet, session, application) and the zone (outside, DMZ, internal). Then ask whether the described traffic crosses a boundary at all; if it is internal east-west traffic or encrypted payload, a perimeter filter is the wrong answer and segmentation, inspection, or endpoint controls are correct.
Recommending 'apply all patches immediately' or 'disable the service' as the universal hardening answer without weighing operational impact, change control, or the actual exposure of the asset.
Hardening checklists are learned as absolutes, and candidates do not practise the trade-off reasoning that distinguishes a critical internet-facing server from an isolated lab host.
What to do instead
State the asset's exposure and criticality before choosing a remediation. Rank by risk (likelihood times impact), and prefer answers that include testing, a maintenance window, or compensating controls when the stem mentions uptime requirements or legacy dependencies.
Mixing up encoding, hashing, encryption, and digital signatures, for example saying a hash 'encrypts' a password or that a signature 'encrypts' a message for confidentiality.
All four transform data into unreadable-looking output, and study material often presents them in one chapter, so the distinctions blur into a single 'scrambling' concept.
What to do instead
Separate reversible representation, cryptographic digests, encryption and signature schemes. A bare fast digest is unsuitable for password storage, and a signature is not generic private-key encryption. Match the required property and use the specified validated construction.