ISTQB CT-SEC common mistakes
ISTQB CT-SEC · Understand the traps and how to avoid them.
Treating security testing as a phase that starts after system testing, so planning answers place all security activities at the end of the lifecycle and omit threat modeling or security requirements analysis from the plan.
Candidates carry over the V-model habit of functional test levels and assume security is a late gate. ISTQB treats security as a whole-lifecycle concern, and the planning syllabus explicitly ties early activities to cost of defect removal.
What to do instead
In any planning question, place threat modeling and security requirement analysis in requirements/design, abuse-case derivation in design, and verification throughout. When asked 'when should X start', default to the earliest lifecycle phase where the artifact exists, and justify with cost-of-fix and shift-left reasoning.
Writing a security test plan that lists only test cases and omits entry/exit criteria, scope exclusions, environment and data-handling constraints, and the authorization/legal basis for testing.
Candidates memorize test case design techniques but not the structure of a plan, and they underestimate that active security testing (scanning, penetration testing) requires explicit permission, rules of engagement, and safe handling of real data.
What to do instead
Use a fixed checklist for every plan answer: scope and out-of-scope, objectives tied to risks, approach and techniques, environment and tooling, entry/exit criteria, deliverables, roles, schedule, and constraints including legal authorization, data privacy, and rules of engagement. Explicitly state that no intrusive test runs without written authorization.
Choosing security test intensity by gut feel or by 'test everything equally', instead of deriving depth, breadth, and effort from the risk analysis and the asset's exposure and impact.
The exam tests risk-based testing as a decision procedure, but candidates answer with generic 'more testing is better' statements and cannot map likelihood and impact to concrete effort allocation.
What to do instead
Always show the chain: asset and threat identification, likelihood and impact estimation, risk level, then test intensity and technique selection. High-risk, internet-facing assets get deeper manual analysis and penetration testing; low-risk internal assets get automated scanning and review. State that risk levels drive both prioritization and stopping criteria.
Confusing vulnerability scanning, penetration testing, and static/dynamic analysis when selecting the technique for a stated objective, for example proposing a scanner to validate a business-logic authorization flaw.
Tool categories overlap in marketing language, and candidates learn tool names without learning what each can and cannot detect. Business-logic and access-control defects are invisible to signature-based scanners.
What to do instead
Learn a detection-capability table: SAST finds code-level patterns with no runtime context; DAST and scanners find known signatures and configuration issues; penetration testing with human reasoning finds logic, chaining, and authorization flaws. Match the objective to the capability and name the limitation explicitly in the answer.
Designing security test cases only from functional requirements and ignoring misuse/abuse cases, negative inputs, and attacker behavior, so the test set never exercises what an adversary would do.
Candidates default to positive-path functional test design and forget that security testing is largely about invalid, unexpected, and hostile input and about violating assumptions.
What to do instead
For every security requirement, add at least one abuse case phrased from the attacker's perspective ('as an unauthenticated user I attempt to reach admin function X'). Include input validation boundaries, authentication and session manipulation, privilege escalation attempts, and error-handling leakage checks in the derived test set.
Assessing residual risk after testing as zero once planned tests pass, rather than reporting residual risk with its assumptions, unknowns, and untested areas.
Candidates conflate 'tests passed' with 'system is secure'. Security is a negative property; passing tests only shows the tested attacks failed, and the exam expects explicit residual-risk communication to stakeholders.
What to do instead
State that passing tests reduces but never eliminates risk. Report residual risk as a qualitative or quantitative estimate with the basis: coverage achieved, techniques not applied, environment differences, and unknown threats. Recommend risk acceptance, mitigation, or further testing as a management decision.
Ignoring human factors and organizational context when evaluating security results, for example treating a phishing susceptibility finding as purely technical or omitting security awareness and insider threat from the evaluation.
Candidates focus on technical defects and forget that the syllabus includes people, process, and organizational culture as sources of risk and as targets of evaluation.
What to do instead
When a scenario involves users, administrators, or developers, explicitly evaluate awareness, usability of security controls, process adherence, and insider risk. Connect human-factor findings to concrete mitigations such as training, secure defaults, and usable authentication design.
Reporting vulnerability findings without severity, exploitability, business impact, or remediation guidance, producing a raw tool-output list as the evaluation deliverable.
Candidates equate finding enumeration with evaluation and do not apply risk rating, false-positive triage, or context about the affected asset.
What to do instead
Structure evaluation output as: finding, affected asset and exposure, evidence, severity with justification, likelihood and impact, false-positive status, remediation recommendation, and retest criteria. Prioritize by business risk, not by tool severity score alone.
Selecting and configuring security tools without addressing false positives and false negatives, tool limitations, or the need for human validation of results.
Tool questions tempt candidates to pick 'the most powerful tool' and forget that every detection technique has blind spots and that scanner output requires triage.
What to do instead
For any tool question, state the technique, what it detects, its known blind spots, expected false-positive profile, and who validates results. Recommend combining complementary techniques and calibrating rules to the application rather than trusting raw output.
Treating standards and legal frameworks as interchangeable names to memorize, so answers cite the wrong standard for an activity (for example using a payment-card standard for general privacy obligations or a testing standard for certification).
Candidates memorize acronyms without mapping each standard to its purpose and scope, and the exam tests the ability to choose the applicable standard for a given obligation.
What to do instead
Build a mapping table: what each standard governs (testing process, security techniques, privacy, sector regulation), who it applies to, and what evidence it requires. When answering, first identify the obligation type (process, technical method, legal, contractual) and then select the matching standard, naming its scope explicitly.