ISTQB CT-SEC study plan

Map the four exam domains to your own work context and write down, per domain, which artefacts (test plan, risk register, tool inventory) you can already produce and which you cannot

Draft a security test strategy outline for a fictional three-tier web application, stating objectives, scope, in-scope assets and explicit out-of-scope items

Distinguish security testing from functional testing and from penetration testing by writing one paragraph on each and listing who owns which activity in a delivery lifecycle

Identify the stakeholders for a security test plan and note, for each, the decision they make from test results

Build a risk register of at least 15 threats for the fictional system using STRIDE as a prompt, and score each on likelihood and impact with a stated rationale

Derive test objectives from the top five risks and write each as a verifiable test condition rather than a topic heading

Sequence security test activities across the lifecycle (requirements, design, build, deployment, operations) and justify why each activity sits where it does

Write entry and exit criteria for a security test level, including what evidence counts as a pass

Explain the purpose and limits of static analysis, dynamic analysis and interactive approaches, and select an appropriate technique for each of your five test conditions

Design test cases for authentication and session management weaknesses, specifying preconditions, steps, expected secure behaviour and the failure signal you would observe

Design test cases for input handling and injection classes without relying on a specific tool, describing the oracle for each case

Define a coverage model for security testing that goes beyond code coverage, and state how you would report residual risk when coverage is incomplete

Perform a structured review of a sample set of requirements and design documents, logging at least 10 security-relevant defects or gaps with severity and rationale

Apply a vulnerability classification scheme to your logged findings and separate genuine vulnerabilities from weaknesses and from informational observations

Practise writing a defect report that a developer can act on without asking follow-up questions, including reproduction detail and business impact

Evaluate the same finding from a risk perspective and from a requirements perspective, and articulate where the two evaluations disagree

Analyse a set of security test results and decide which findings require retest, which require a risk acceptance decision, and which are false positives, justifying each decision

Assess security test adequacy against stated requirements and against risk coverage, and write the gap statement for each shortfall

Examine human factors in security testing by identifying at least five ways tester or developer behaviour (habituation, confirmation bias, alert fatigue, unclear ownership, pressure to ship) can degrade results

Propose concrete mitigations for each human-factor issue you identified and state how you would detect the issue recurring

Categorise security testing tools by function (static analysis, dynamic scanning, dependency and composition analysis, fuzzing, traffic interception, configuration checking) and state one strength and one limitation per category

Define selection criteria for a tool in each category, covering accuracy, false positive behaviour, integration, licensing and reporting

Interpret the output of a scanner report conceptually, distinguishing a true finding, a false positive and an unverifiable item, and describe the triage workflow

Explain the role of standards and reference sources in security testing and describe how you would use one to justify a test approach

Re-derive the full exam syllabus structure from memory, listing the main topics under each of the four domains and marking uncertain areas

Close your three weakest marked areas by producing a written explanation and a worked example for each

Work through scenario-style questions that combine planning, execution and evaluation, and record why each wrong option is wrong

Time yourself on a mixed set of questions and analyse whether errors come from knowledge gaps, misreading or time pressure

Consolidate your week 1 strategy, week 2 plan, week 3 test cases, week 4 review, week 5 evaluation and week 6 tool sheet into one coherent end-to-end security testing case study

Check the case study for internal consistency so that every risk traces to a test condition, to a test case, to a finding and to an evaluation decision

Rehearse explaining the case study aloud in ten minutes, covering planning, execution, evaluation and tooling choices

Review your gap-closure log one final time and confirm each entry is resolved or explicitly accepted as residual uncertainty