How to answer a CISSP question, step by step

A CISSP question is handled in four moves: read the actual request before the options, identify the decision being asked and whose it is, follow the explicit criteria of the stem to the letter, and add no assumptions. These moves are reconstructed from 138 practice questions shared by candidates between 2023 and 2026, and above all from the justifications that accompany them — candidate opinions, never official ISC2 corrections, and no question stem is reproduced here.

Where should you start when reading a CISSP question?

At the end. One of the most repeated instructions in the candidate reports is to first read the last sentence of the stem — the one carrying the actual request — before reading the scenario, and before looking at the options. A ten-line scenario about a financial institution, its network segmentation and its recent audit is often just scenery; the question sits in the last fifteen words.

This reversed reading is formalised in a widely circulated four-step method: read the last sentence, eliminate, analyse the two remaining options, decide. It comes with a requirement to slow down:

"READ each question S L O W L Y and at least TWICE — a single word often gives away the answer or eliminates two choices."

The candidate reports contain a textbook case of that single word. One question asks where to find information published by an organised threat actor; the instinct points to the usual threat intelligence channels, whereas the preposition changes everything — what an attacker publishes themselves is not found where defenders publish their analyses. The difficulty was not knowledge, it was reading.

A third formula completes the picture: "Read like a lawyer." Every word of the stem is binding. It belongs to the triptych "think like a manager, understand like a technician, read like a lawyer," which is itself the most repeated formula in the candidate reports.

How do you identify the decision actually being asked?

Once the request is isolated, it still has to be qualified before looking at the options. The most developed framework in the candidate reports comes down to four questions you ask yourself:

"Identify the decision before looking at the answers: Who owns this decision? What phase am I in — governance, design, implementation, operation, response? What objective is being optimised — risk reduction, continuity, compliance, safety, cost? What authority does the actor actually have?"

The phase is the most productive filter. An analyst verifying whether an alert is a true positive before taking any action is still in detection, not response; an organisation assessing its legal notification obligations does so at the reporting stage, once the facts are established. In both cases, the option wrongly chosen describes an adjacent and perfectly correct phase — at the wrong moment.

The verb in the request sets the objective. A question asking how to avoid an exposure does not expect the same family of answers as one asking how to reduce it: in one case data minimisation wins, in the other monitoring or a technical control.

What role does the persona in the stem play?

This is the soundest refinement in the candidate reports, and the one that resolves the most ambiguity:

"The role given in the question is your cue. CISO or senior leadership → think governance. Architect or engineer → think technical and operational. That single filter resolved a lot of ambiguous questions for me."

When no role is given, the default position adopted in the candidate reports is that of a risk advisor. But when a role is given, it overrides every reflex, including priorities you believe to be absolute. A striking case from the reports: an incident takes a vital piece of equipment out of service at a site housing vulnerable people, and the stem designates the respondent as a member of the incident response team. The "human life first" reflex points to evacuation — but evacuating is not that team's decision, it belongs to the care staff. The priority given to people is not suspended; it is the persona's authority that does not extend to it.

This filter also explains why the "think like a manager" mantra lost ground after 2024: it works when the persona is managerial, and produces wrong answers otherwise. Two contributors presenting themselves as ISC2 question writers go further and reject the concept itself; their statements, and the caveats that self-declared identities warrant, are examined in the debate about the mantra. For the reading task at hand, the lesson fits in one line: the role written into the stem is read, not guessed.

Which explicit criteria must never be ignored?

All of them. A criterion written into the stem overrides any heuristic, including the spontaneous preference for the most secure solution. The candidate reports turn this into a blunt rule:

"You cannot just ignore explicitly stated key criteria like 'lowest cost'."

The original example is worth transposing. Picture a filtering gateway at a logistics company that reboots regularly and stays unavailable for around twenty minutes each time; the stem asks for availability to be maintained at the lowest cost, and specifies that other controls cover the same flow. The most robust options — redundancy, automatic failover — satisfy availability but violate the second criterion, written in black and white. Two criteria were set: the answer must satisfy both.

The words that change the answer are few and come up constantly: BEST, MOST, FIRST, NEXT, LEAST, PRIMARY, PREVENT, MINIMUM. The candidate reports on these questions add a ninth, particularly decisive one: a question about who is "ultimately" accountable is not looking for who executes but for who cannot delegate. And "minimum" disqualifies any option that protects everything indiscriminately.

The mirror image matters too: cost stays in the background even when it is not mentioned. "Best ≠ most secure" — the best answer is not the most secure one.

Which assumptions must you absolutely rule out?

All of them. This is the most documented mistake in the candidate reports, and it is the direct cause of most disagreements between a candidate and an answer key. The rule fits in one sentence:

"If the question didn't say it, it didn't happen."

Its mnemonic variant is harsher: "Think like a pedantic auditor." The budget you imagine to be constrained, the service level nobody ever mentioned, the architecture you fill in mentally — none of them exist.

The cases in the candidate reports are instructive because they are all made in good faith. One candidate disputes an answer key about migrating servers to external hosting: he had assumed the servers were already there, which the stem never said. Another rules out the cheapest option on a disaster recovery question even though the stem gave the recovery objective: the objection rested on a service level the stem never mentioned. In both cases the knowledge was there; it was the added information that produced the wrong answer.

The counter-mantra that emerged from the candidate reports in late 2024 is simply called Just Answer The Question, and it targets exactly that drift: looking for a hidden intent amounts to adding to the text what it does not contain. Its most quoted formulation, and how it dethroned the managerial mantra, are reported in our article on the debate.

The added assumption is, incidentally, one of the most persistent preparation mistakes, because it gets stronger the more professional experience you have: it ranks high among the mistakes to avoid while studying.

Should you answer from field experience or from the CBK?

From the CBK, every time the two diverge — and they diverge often. One stem asks how to prevent an attacker who has compromised an administrator's day-to-day account from obtaining elevated privileges: controlled elevation is indeed among the options, but the modern solution that secures it — multi-factor authentication — is not offered, and the expected answer is to strictly separate privileges from the working account. Every commenter in the thread agrees this is bad practice in production, and concludes that you must address the concern as it is worded.

Same mechanism elsewhere: a candidate objects that in a major incident, in real life, the authorities are notified almost immediately; the CBK logic places that assessment at a later phase, and it wins.

The reverse is just as true, and it is the nuance candidates miss most often: the CBK is not anti-technical. A question asking about command-line remote access to a network device expects a precise technical answer, not a policy. The formula that settles it:

"Thinking like a manager doesn't mean you should discard technical answers."

That is why useful revision does not consist of memorising correct answers but of being able to state why each wrong option is wrong — the move Cybridia has systematised: for each of its 4,298 questions, the explanation details why the distractors are wrong. It is also why a practice exam percentage says little about your actual level, as explained in our benchmark on practice test scores.

What should you do when the question seems badly written?

It happens, including in well-regarded books. The candidate reports document a question about the exchanges in an address assignment protocol whose official answer is widely held to be an editing error, never corrected from one edition to the next. Another is declared unanswerable: with no role indicated, all four options can be defended.

The recommended approach comes down to three moves. Treat each question "in its own vacuum," without looking for consistency with another question in the same series. Pick the least bad option according to the exact terms of the stem. Then move on: the real danger of a bad question is not the lost point, it is the doubt it plants for the rest of the exam. This mechanism is the same one described in the feeling of failing during the exam, and it is fought the same way: by closing each question behind you.

What remains is knowing how to rule options out. That is the subject of eliminating distractors, and when two serious answer keys contradict each other, of arbitrating between question banks.