ECF-GSF Core common mistakes
ECF-GSF Core · Understand the traps and how to avoid them.
Treating risk as a single number and selecting the highest-scoring risk for treatment without separating likelihood from impact, so answers that correctly prioritise a low-likelihood/high-impact risk are missed.
Candidates memorise 'treat the biggest risk first' and collapse the two axes, then cannot justify why a rare catastrophic event outranks a frequent minor one, or why risk acceptance is valid for a high-score item with low cost of loss.
What to do instead
Practise scoring likelihood and impact separately, then state the treatment decision (mitigate, transfer, avoid, accept) with the residual risk and the owner named. For each practice item, write one sentence on why the chosen treatment fits the risk appetite rather than the raw score.
Describing a firewall or segmentation design as 'defence in depth' without naming which control sits at which layer and what it stops that the layer above does not.
The phrase is repeated so often in study material that it becomes a label rather than an architecture, and candidates cannot map a control to the threat it addresses or explain why one control alone is insufficient.
What to do instead
For every architecture answer, build a short table: layer, control, threat blocked, failure mode if removed. If you cannot fill the 'failure mode if removed' cell, the control is not justified. Rehearse two designs (flat versus segmented) and state the specific lateral-movement path each permits.
Choosing multi-factor authentication as the fix for every authentication weakness, including session hijacking, credential stuffing against a breached password, and insider misuse of a valid session.
MFA is the strongest single control most candidates know, so it becomes the default answer even where the attack occurs after authentication or where the second factor is phishable.
What to do instead
Classify the attack stage first: pre-authentication, at authentication, or post-authentication. Then match controls - rate limiting and breached-password checks for stuffing, phishing-resistant factors (FIDO2/passkeys) for real-time phishing, session binding and short token lifetimes for session theft. State the residual gap for each.
Answering data-classification questions by labelling data 'confidential' and stopping there, without connecting the label to handling rules, retention, encryption requirement, and access review frequency.
Candidates treat classification as a naming exercise rather than the input to a control set, so they cannot say what changes operationally when a label is applied.
What to do instead
For each label, write the four downstream rules: who may access, what protection in transit and at rest, how long retained, and how disposed. Then answer classification items by tracing label to rule to control, and check that the rule set is enforceable rather than aspirational.
Confusing hashing, encryption, and encoding - for example recommending AES to protect passwords or Base64 to protect data in transit.
All three transform data into unreadable-looking output, and revision notes rarely force the candidate to state the property being relied on (reversibility, key management, integrity).
What to do instead
Learn the decision rule: is the property confidentiality (reversible with a key), integrity/one-way verification (irreversible), or transport representation (no security)? Then practise converting a requirement sentence into the primitive, e.g. 'verify without storing the secret' maps to a salted password hash, not encryption.
Treating 'the cloud provider is responsible for security' as a blanket statement, and misassigning controls in a shared-responsibility model for IaaS, PaaS, and SaaS.
Marketing language and the phrase 'secure by default' blur the boundary, and candidates apply one mental model across all three service models.
What to do instead
Draw the responsibility line for each service model across physical, hypervisor, OS, runtime, application, identity, and data. Then answer by naming the service model first and stating the customer-side controls explicitly, including the ones that never transfer (data classification, identity governance, access policy).
Writing incident response answers that jump from detection to eradication, skipping containment, evidence preservation, and the decision authority for taking systems offline.
Eradication feels like the productive step, and candidates optimise for 'fixing it' rather than for a defensible, reversible process with preserved evidence.
What to do instead
Use a fixed skeleton for every scenario: detect, triage and declare, contain (with the business impact stated), preserve evidence, eradicate, recover, review. Name who authorises containment and what is logged. If an answer removes a host before imaging, mark it wrong and say why.
Selecting a monitoring control without stating what it detects, its false-positive profile, and how an alert becomes a response.
Candidates memorise tool categories (IDS, SIEM, EDR) and pick the most advanced-sounding one, but cannot explain detection coverage or why an unmonitored control is not a control.
What to do instead
For each detection answer, state the data source, the detection logic, the expected false-positive rate, and the runbook step that follows the alert. Practise identifying blind spots - for example, host telemetry without network telemetry, or logs collected but never reviewed.
Treating compliance as equivalent to security, and answering 'we are compliant, therefore the risk is managed' or the reverse.
Frameworks and audit language dominate the study material, and the distinction between meeting a control's letter and achieving its intent is rarely tested explicitly in revision.
What to do instead
For each framework control, state the risk it addresses and one way an organisation can pass the audit while remaining exposed. Then answer by separating the compliance obligation, the security outcome, and the evidence that demonstrates the outcome - and say which one the question is actually asking for.
Answering legal and jurisdictional questions with a generic 'report it and notify the regulator' without identifying the applicable law, the notification threshold, the timeline, and who decides.
Candidates learn one breach-notification rule and apply it globally, ignoring that thresholds, clocks, and regulators differ by jurisdiction and by data type.
What to do instead
Build a one-page matrix: jurisdiction, law, triggering data types, threshold, deadline, notifying body, and internal decision owner. Answer by naming the jurisdiction and data category first, then the obligation and clock. Where the scenario is cross-border, state which law applies and why.