Comment répondre à une question du CISSP, étape par étape

Une question du CISSP se traite en quatre gestes : lire la demande réelle avant les options, identifier la décision demandée et à qui elle revient, respecter à la lettre les critères explicites de l’énoncé, et n’ajouter aucune hypothèse. Ces gestes sont reconstitués à partir de 138 questions d’entraînement partagées par des candidats entre 2023 et 2026 et surtout des justifications qui les accompagnent — des avis de candidats, jamais des corrections officielles d’ISC2, et aucun énoncé n’est reproduit ici.

Par où commencer la lecture d’une question CISSP ?

Par la fin. Une des consignes les plus répétées des témoignages consiste à lire d’abord la dernière phrase de l’énoncé — celle qui porte la demande réelle — avant de lire le scénario, et avant de regarder les options. Un scénario de dix lignes sur une institution financière, sa segmentation réseau et son audit récent n’est souvent qu’un décor ; la question tient dans les quinze derniers mots.

Cette lecture inversée est formalisée dans une méthode en quatre temps qui circule largement : lire la dernière phrase, éliminer, analyser les deux options restantes, décider. Elle s’accompagne d’un impératif de lenteur :

« 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. »

« Lisez chaque question L E N T E M E N T et au moins DEUX FOIS — un seul mot donne souvent la réponse ou élimine deux choix. »

Le témoignage des candidats contient un cas d’école de ce mot unique. Une question demande où trouver l’information publiée par un acteur malveillant organisé ; le réflexe pousse vers les canaux habituels du renseignement sur les menaces, alors que la préposition change tout — ce que l’auteur d’une attaque publie lui-même ne se trouve pas là où les défenseurs publient leurs analyses. La difficulté n’était pas la connaissance, c’était la lecture.

Une troisième formule complète le tableau : « Read like a lawyer » — lisez comme un juriste. Chaque mot de l’énoncé est opposable. Elle appartient au triptyque « think like a manager, understand like a technician, read like a lawyer », qui est, lui, la formule la plus répétée des témoignages.

Comment identifier la décision réellement demandée ?

Une fois la demande isolée, il reste à la qualifier avant de regarder les options. La grille la plus aboutie des témoignages tient en quatre questions posées à soi-même :

« 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? »

« Identifiez la décision avant de regarder les réponses : à qui appartient cette décision ? Dans quelle phase suis-je — gouvernance, conception, mise en œuvre, exploitation, réponse ? Quel objectif est optimisé — réduction du risque, continuité, conformité, sécurité des personnes, coût ? De quelle autorité l’acteur dispose-t-il réellement ? »

La phase est le filtre le plus rentable. Un analyste qui vérifie si une alerte est un vrai positif avant toute action est encore en détection, pas en réponse ; une organisation qui évalue ses obligations légales de notification le fait au stade du rapport, quand les faits sont établis. Dans les deux cas, l’option choisie par erreur décrit une phase voisine et parfaitement correcte — au mauvais moment.

Le verbe de la demande fixe l’objectif. Une question qui demande d’éviter une exposition n’attend pas la même famille de réponses qu’une question qui demande de la réduire : dans un cas la minimisation des données l’emporte, dans l’autre la surveillance ou le contrôle technique.

Quel rôle joue la persona indiquée dans l’énoncé ?

C’est le raffinement le plus solide des témoignages, et celui qui résout le plus d’ambiguïtés :

« 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. »

« Le rôle donné dans la question est votre indice. RSSI ou direction générale → pensez gouvernance. Architecte ou ingénieur → pensez technique et opérationnel. Ce seul filtre m’a résolu beaucoup de questions ambiguës. »

Quand aucun rôle n’est donné, la position par défaut retenue par les témoignages est celle de conseiller en risques. Mais quand un rôle est donné, il prime sur tout réflexe, y compris sur les priorités qu’on croit absolues. Cas frappant des témoignages : un incident met hors service un équipement vital dans un site accueillant des personnes vulnérables, et l’énoncé désigne le répondant comme membre de l’équipe de réponse à incident. Le réflexe « la vie humaine d’abord » pousse vers l’évacuation — mais évacuer n’est pas la décision de cette équipe, elle revient au personnel soignant. La priorité aux personnes n’est pas suspendue ; c’est l’autorité du personnage qui ne la couvre pas.

Ce filtre explique aussi pourquoi le mantra « think like a manager » a perdu du terrain après 2024 : il fonctionne quand la persona est managériale, et produit des réponses fausses sinon. Deux contributeurs se présentant comme rédacteurs de questions pour ISC2 vont plus loin et démentent le concept lui-même ; leurs propos, et les réserves qu’appellent des identités déclaratives, sont examinés dans le débat sur le mantra. Pour la lecture qui nous occupe ici, l’enseignement tient en une ligne : le rôle écrit dans l’énoncé se lit, il ne se devine pas.

Quels critères explicites ne faut-il jamais ignorer ?

Tous. Un critère écrit dans l’énoncé prime sur toute heuristique, y compris sur la préférence spontanée pour la solution la plus sûre. Le témoignage des candidats en fait une règle sèche :

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

« Vous ne pouvez pas simplement ignorer des critères explicitement énoncés comme "le coût le plus bas". »

L’exemple d’origine mérite d’être transposé. Imaginez une passerelle de filtrage, dans une entreprise de logistique, qui redémarre régulièrement et reste indisponible une vingtaine de minutes à chaque fois ; l’énoncé demande de maintenir la disponibilité au coût le plus bas, et précise que d’autres contrôles couvrent le même flux. Les options les plus robustes — redondance, bascule automatique — satisfont la disponibilité mais violent le second critère, écrit noir sur blanc. Deux critères ont été posés : la réponse doit satisfaire les deux.

Les mots qui changent la réponse sont peu nombreux et reviennent constamment : BEST, MOST, FIRST, NEXT, LEAST, PRIMARY, PREVENT, MINIMUM. Le témoignage des candidats des questions en ajoute un neuvième, particulièrement discriminant : une question sur qui est « ultimately » redevable ne cherche pas qui exécute mais qui ne peut pas déléguer. Et « minimum » disqualifie toute option qui protège tout sans distinction.

Le symétrique compte aussi : le coût reste en arrière-plan même quand il n’est pas mentionné. « Best ≠ most secure » — la meilleure réponse n’est pas la plus sécurisée.

Quelles hypothèses faut-il s’interdire absolument ?

Toutes. C’est l’erreur la plus documentée des témoignages, et elle est la cause directe de la majorité des désaccords entre un candidat et un corrigé. La règle tient en une phrase :

« If the question didn’t say it, it didn’t happen. »

« Si la question ne l’a pas dit, ça n’a pas eu lieu. »

Sa variante mnémotechnique est plus dure : « Think like a pedantic auditor » — pensez comme un auditeur tatillon. Ni le budget que vous imaginez contraint, ni le niveau d’engagement de service jamais mentionné, ni l’architecture que vous complétez mentalement n’existent.

Les cas des témoignages sont instructifs parce qu’ils sont tous de bonne foi. Un candidat conteste un corrigé sur la migration de serveurs vers un hébergement externe : il avait supposé que les serveurs y étaient déjà, ce que l’énoncé ne disait pas. Un autre écarte, sur une question de reprise d’activité, l’option la plus économique alors que l’énoncé donnait l’objectif de reprise : c’est un niveau de service jamais mentionné qui a nourri l’objection. Dans les deux cas, la connaissance était là ; c’est l’information ajoutée qui a produit la mauvaise réponse.

Le contre-mantra qui a émergé des témoignages fin 2024 s’appelle simplement Just Answer The Question, et il vise exactement cette dérive : chercher une intention cachée revient à ajouter au texte ce qu’il ne contient pas. Sa formulation la plus citée, et la façon dont elle a détrôné le mantra managérial, sont rapportées dans notre article sur le débat.

L’hypothèse ajoutée est d’ailleurs l’une des erreurs de préparation les plus tenaces, parce qu’elle se renforce à mesure qu’on gagne en expérience métier : elle figure en bonne place parmi les erreurs à éviter en révision.

Faut-il répondre selon son expérience terrain ou selon le référentiel ?

Selon le référentiel, chaque fois que les deux divergent — et ils divergent souvent. Un énoncé demande comment empêcher qu’un attaquant ayant compromis le compte quotidien d’un administrateur obtienne des privilèges élevés : l’élévation contrôlée figure bien parmi les options, mais la solution moderne qui la sécurise — l’authentification multifacteur — n’est pas proposée, et la réponse attendue consiste à séparer strictement les privilèges du compte de travail. Tous les commentateurs du fil reconnaissent que c’est une mauvaise pratique en production, et concluent qu’il faut répondre à la préoccupation telle qu’elle est formulée.

Même mécanisme ailleurs : un candidat objecte qu’en cas d’incident majeur, dans la vraie vie, on prévient les autorités presque immédiatement ; la logique du référentiel place cette évaluation à une phase ultérieure et l’emporte.

L’inverse est tout aussi vrai, et c’est la nuance que les candidats manquent le plus souvent : le référentiel n’est pas anti-technique. Une question demandant un accès distant en ligne de commande à un équipement réseau attend une réponse technique précise, pas une politique. La formule qui tranche :

« Thinking like a manager doesn’t mean you should discard technical answers. »

« Penser comme un manager ne signifie pas qu’il faut écarter les réponses techniques. »

C’est pour cela que la révision utile ne consiste pas à mémoriser des bonnes réponses mais à savoir énoncer pourquoi chaque mauvaise option est fausse — le geste que Cybridia a systématisé : pour chacune de ses 4 298 questions, l’explication détaille pourquoi les distracteurs sont faux. C’est aussi la raison pour laquelle un pourcentage d’examen blanc renseigne mal sur le niveau réel, comme l’explique notre repère sur les scores d’entraînement.

Que faire quand la question semble mal écrite ?

Cela arrive, y compris dans des ouvrages réputés. Le témoignage des candidats documente une question sur les échanges d’un protocole d’attribution d’adresses dont la réponse officielle est largement tenue pour une coquille d’édition, jamais corrigée d’une édition à l’autre. Une autre est déclarée non répondable : sans indication de rôle, les quatre options se défendent.

La conduite recommandée tient en trois gestes. Traiter chaque question « dans son propre vide », sans chercher de cohérence avec une autre question de la même série. Choisir l’option la moins mauvaise selon les termes exacts de l’énoncé. Puis passer à la suivante : le vrai danger d’une mauvaise question n’est pas le point perdu, c’est le doute qu’elle installe pour la suite de l’épreuve. Ce mécanisme est le même que celui décrit dans l’impression d’échouer pendant l’examen, et il se combat de la même manière : en refermant chaque question derrière soi.

Reste à savoir écarter les options. C’est l’objet de l’élimination des distracteurs, et quand deux corrigés sérieux se contredisent, de l’arbitrage entre banques de questions.