GISP common mistakes
GISP · Understand the traps and how to avoid them.
Treating risk as a single number and selecting the control with the lowest cost or highest raw risk score, rather than weighing likelihood, impact, and residual risk against the organization's risk appetite and documenting the acceptance decision.
Candidates memorize risk formulas and control lists but never practice the judgment step: comparing treatment options, deciding what residual risk is tolerable, and recording who accepted it. Exam items are written to test that judgment, not arithmetic.
What to do instead
For each practice scenario, write a short risk register entry: asset, threat, vulnerability, likelihood, impact, existing controls, proposed treatment, residual risk, and the accountable owner who accepts it. Practice stating explicitly why transfer, avoid, mitigate, or accept was chosen over the alternatives.
Classifying data by its format or storage location (for example, calling anything in a database 'confidential') instead of by its sensitivity, value, and regulatory obligations, and then applying the same handling controls to every copy regardless of where it moves.
Candidates conflate data classification with asset labeling and network segmentation, so they answer questions about ownership, custody, and handling based on where data lives rather than what it is.
What to do instead
Build a one-page classification scheme with three or four tiers, and for each tier list who owns it, who may be a custodian, permitted storage and transmission channels, retention, and destruction method. Then run the same data element through email, cloud storage, backup, and third-party sharing and state what changes and what does not.
Choosing a cryptographic or architectural control by name recognition (for example, 'use AES' or 'add a DMZ') without matching key length, mode, protocol version, or trust boundary placement to the stated threat model and performance constraints.
Study material presents algorithms and architectures as vocabulary lists, so candidates never connect a control choice to the specific attack it prevents or the constraint it must satisfy.
What to do instead
For each major control, write down the threat it addresses, the failure mode it does not address, and one constraint that would make it inappropriate. Practice justifying a choice in two sentences that name the threat and the constraint, and practice rejecting a plausible-sounding but mismatched option.
Answering network security questions by picking the device or protocol that sounds most secure rather than reasoning about the layer, the direction of the traffic, and whether the control inspects, filters, or merely forwards.
Candidates memorize port numbers and device names but do not build a mental model of the OSI or TCP/IP path, so questions about where to place a control or what a control can see defeat them.
What to do instead
Draw the path a packet takes from client to service, marking each layer and each control it crosses. For every scenario, state the layer, the traffic direction, and whether the control can inspect payload, headers, or only addresses. Practice explaining why a control at one layer cannot do the job of a control at another.
Treating authentication, authorization, and accounting as interchangeable, and selecting an access control model (role-based, attribute-based, mandatory, discretionary) without checking whether the scenario's requirement is about identity proofing, permission granularity, or audit trail.
The three A's are learned as a slogan, so candidates answer 'who can do what' questions with authentication mechanisms and 'prove who you are' questions with authorization models.
What to do instead
For each practice item, first label the requirement as identification, authentication, authorization, or accounting, then choose the mechanism. Separately, write one paragraph per access control model describing the decision input it uses, the administrative burden it creates, and the scenario where it clearly wins.
Confusing vulnerability assessment with penetration testing, and confusing a compliance checklist with a security assessment, so recommendations omit scope, rules of engagement, sampling method, or the difference between a finding and an exploited finding.
Candidates study tool names and report formats but not the assessment lifecycle, so they cannot distinguish what each activity proves or which one answers a given business question.
What to do instead
Write a short scope and rules-of-engagement statement for a hypothetical assessment, then list what a vulnerability scan would and would not establish versus a penetration test. Practice converting a raw finding into a risk statement with evidence, exploitability, and a remediation owner.
Responding to incident scenarios by jumping to containment or eradication steps without first establishing detection, triage, evidence preservation, and escalation, and without distinguishing an event from an incident.
Candidates memorize the incident response phase names but practice them as an ordered list to recite rather than as decisions constrained by business impact, legal notification, and evidence integrity.
What to do instead
Walk through a tabletop scenario in writing and at each step state what evidence must be preserved, who is notified, what business function is affected, and why the next phase cannot start yet. Practice the containment trade-off: stopping the attack versus keeping the system available for investigation.
Treating secure development as a final testing gate, recommending only 'more testing' or 'a code review' instead of embedding threat modeling, secure coding standards, dependency management, and environment separation into the lifecycle.
Candidates learn SDLC models and security testing tools as separate topics, so they do not see where in the lifecycle each control belongs or what class of defect each one catches.
What to do instead
Map each control (threat modeling, static analysis, dependency scanning, code review, dynamic testing, secrets management) to the lifecycle phase where it is cheapest and to the defect class it detects. For each practice scenario, name the phase and the control, and state what a later-phase control would have missed.
Answering identity lifecycle questions by focusing only on provisioning and login, ignoring joiner-mover-leaver events, access recertification, privileged access management, and orphaned accounts.
Candidates associate IAM with authentication protocols and single sign-on, so questions about entitlement creep, role explosion, and stale accounts feel unfamiliar even though they are the operational core of IAM.
What to do instead
Build a lifecycle table for a sample employee: hire, role change, temporary elevation, leave, and termination, listing the access change, the approval, and the evidence required at each step. Add a recertification cycle and state what happens to unconfirmed entitlements.
Ignoring the business context in scenario questions, choosing the technically strongest control even when it breaks availability, exceeds budget, or conflicts with a stated regulatory or contractual constraint.
Candidates study domains in isolation and treat security as an absolute good, so they miss that the exam rewards the control that fits the organization's risk appetite, obligations, and operating constraints.
What to do instead
Before answering any scenario item, extract the stated constraints (budget, uptime, regulation, timeline, user population) and eliminate options that violate one. Practice writing a two-sentence justification that names the constraint satisfied and the residual risk accepted.