GSTP common mistakes
GSTP · Understand the traps and how to avoid them.
Treating a governance question as a pure policy-writing exercise: drafting controls and standards without first tying them to a business driver, risk appetite statement, or executive sponsor.
Candidates trained in compliance or audit reflexively jump to control language because it feels concrete and defensible, and the exam's governance stems often describe a business trigger (merger, new market, board mandate) that must be translated into strategy before controls are chosen.
What to do instead
For every governance item, force yourself to answer three questions in order: what business outcome is at stake, who owns the decision, and only then what control or policy implements it. Practise rewriting policy-first answers into outcome-first answers and note how the scoring language shifts.
Confusing security strategy with a technology roadmap, choosing an answer that lists tools (EDR, CASB, SIEM) when the stem asks about strategic direction or transformation sequencing.
Vendors and daily operations condition candidates to equate progress with product deployment, and tool lists look specific and therefore attractive among abstract-sounding options.
What to do instead
Before reading the options, label the stem as strategy, architecture, or operations. If it is strategy, eliminate any option whose primary content is a product name or a deployment step, and prefer options describing outcomes, capability maturity, risk posture, or decision rights.
Assigning risk treatment without matching it to the organisation's stated risk appetite, for example recommending full mitigation of a risk the stem says is within tolerance.
Candidates equate thorough security with eliminating risk, and risk-appetite language in stems is easy to skim past as scene-setting rather than as a decision constraint.
What to do instead
Highlight every appetite, tolerance, and constraint phrase in the stem before evaluating options. Then test each treatment (avoid, mitigate, transfer, accept) against that statement explicitly, and reject any option that spends disproportionate effort on a risk the organisation has already declared acceptable.
Designing a security programme as a flat list of controls rather than a structured set of capabilities with owners, maturity stages, dependencies, and funding tied to risk reduction.
Control frameworks are easier to memorise than programme design, so candidates reproduce framework categories instead of showing how a programme is sequenced and governed over time.
What to do instead
Practise building one-page programme designs: risk drivers, target capabilities, current maturity, sequenced initiatives, owners, and success metrics. When answering, prefer options that show prioritisation logic and dependency awareness over options that merely enumerate controls.
Selecting a reference architecture or technology pattern without first establishing the business and threat context in the stem, such as choosing zero trust for an air-gapped legacy environment with no identity modernisation path.
Zero trust, SASE, and cloud-native patterns dominate current discourse, so candidates pattern-match to fashionable architectures rather than to stated constraints like legacy protocols, latency limits, or regulatory data residency.
What to do instead
Extract the hard constraints (regulatory, technical, budget, skills) from the stem into a short list, then score each architecture option against them. An option that ignores a stated constraint is wrong even if it is the modern best practice.
Treating a technology transformation as a pure engineering cutover, omitting identity, data classification, logging, and control inheritance impacts on downstream systems.
Transformation questions reward systems thinking, but candidates focus on the headline technology and forget that identity and data flows are what usually break during migration.
What to do instead
Use a fixed checklist for every architecture item: identity and access, data classification and residency, logging and monitoring, control inheritance, and rollback. Mentally run the proposed change through all five and eliminate options that leave any unaddressed.
Answering change-leadership items with communication plans alone, ignoring resistance diagnosis, stakeholder coalition building, incentive alignment, and reinforcement after go-live.
Communication is the most familiar change tool, so candidates default to it, while the exam typically tests whether you can diagnose why adoption is failing and intervene at the systemic level.
What to do instead
For each change item, identify the adoption barrier type first (skills, incentives, trust, capacity, or clarity) and only then choose the intervention. Reject options that are purely informational when the stem shows a capability or incentive problem.
Assuming executive sponsorship alone drives adoption, without addressing middle-management behaviour and frontline workflow impact.
Sponsorship is heavily emphasised in change literature, so candidates stop there and miss that middle managers and workflow friction are the usual failure point in the stem's scenario.
What to do instead
Always ask who must change their daily behaviour for the initiative to succeed, and check whether the chosen option makes that change easier, rewarded, or enforced. Prefer options that engage middle managers and adjust workflows over options that only escalate to the executive.
Choosing metrics by what is easy to measure (patch rates, ticket counts, training completion) rather than by what demonstrates risk reduction or programme value to the stated audience.
Operational data is readily available, so candidates default to it, but the exam asks which metric serves a decision, and the audience (board, regulator, operations) determines the right answer.
What to do instead
For each metrics item, name the decision the metric informs and the audience consuming it. Then eliminate any metric that cannot change a decision, and prefer leading indicators and outcome measures where the stem implies a board or executive audience.
Treating operations questions as incident firefighting, selecting the fastest containment action without addressing detection gaps, root cause, or the process change that prevents recurrence.
Candidates read operational stems as urgent and reward decisive-sounding action, missing that the exam often tests the post-incident learning and control-improvement step.
What to do instead
Read the whole stem to find whether it asks about response, recovery, or improvement. If the incident is already contained or the stem mentions repeated events, choose the option that fixes detection, ownership, or process, not the option that adds short-term heroics.