- What it is: the ISTQB Certified Tester Security Test Engineer (CT-STE) certifies that you can carry out security testing: apply techniques, set up the environment, use tools, analyze vulnerabilities and report them.
- Current version: syllabus v1.0.1 (January 2025), part of the Specialist stream of the ISTQB portfolio.
- Prerequisite: the ISTQB Foundation Level (CTFL) certification. You don't need to code or take an accredited course, although a technical background helps.
- Content: 9 chapters and a minimum of 1,290 minutes (about 22 hours) of accredited training.
- Exam: 40 questions, 43 points, pass mark 28 points (65%), 75 minutes (+25% if it isn't your native language).
- How it relates to CT-SEC: ISTQB split the former Security Tester (2016) into two certifications: Security Test Engineer (execution) and Security Test Analyst (strategy and risk). There is no automatic transfer.
Security is no longer a topic reserved for the cybersecurity team. Any team that ships software needs someone who knows how to test authentication, permissions, encryption, open-source dependencies and exposed configurations. ISTQB created the Certified Tester Security Test Engineer (CT-STE) for exactly that profile. This guide explains what it covers, what the exam looks like and where to start if you want to get certified.
What CT-STE is and where it sits in the ISTQB portfolio
CT-STE belongs to the ISTQB Specialist stream, the group of certifications that go deep into one type of testing or one industry. The official syllabus is version 1.0.1: version 1.0 was published on October 18, 2024, and 1.0.1, after the final technical review, on January 31, 2025. ISTQB announced the official launch in February 2025.
Its focus is hands-on. The syllabus itself points out a complementary profile, the Security Test Analyst, who designs the security tests that the Security Test Engineer then executes. Put simply: the analyst decides which risks to go after and with what strategy; the engineer puts it into practice with tools, environments, evidence and reports.
If you hold the earlier certification, the 2016 ISTQB Security Tester (CT-SEC), read the section on how the two relate further down: ISTQB has confirmed there is no grandfathering for CT-SEC holders.
If you are still getting your bearings on the full certification map, check our ISTQB certification guide, with the portfolio, costs in your currency and how the exam works.
Who it is for and prerequisites
CT-STE is designed for people who already work in testing or development and want to specialize in security:
- QA testers and test analysts who already do functional testing and want to add security testing to their daily work.
- Automation engineers who want to plug SAST, DAST or software composition analysis (SCA) scanners into their pipelines.
- Developers who need to understand how the security of what they build is tested.
- DevOps and infrastructure people who validate hardening, firewalls and configurations.
- QA leads who need to speak the same language as the information security team.
Official requirements
- Mandatory: hold the ISTQB Foundation Level (CTFL) certification before taking the exam.
- Recommended: at least a minimal background in development, testing or security testing. ISTQB states that technical or programming knowledge is not mandatory for the exam, although it makes the examples easier to follow.
- Not mandatory: taking an accredited course. You can prepare on your own.
The syllabus is not tied to any industry: it applies equally to banking, e-commerce, healthcare, government or enterprise software.
What you will be able to do: the syllabus business outcomes
ISTQB defines nine business outcomes for CT-STE holders. In plain terms, a certified Security Test Engineer can:
| Code | What you will be able to do |
|---|---|
| STE-BO1 | Understand the fundamental security paradigms and their impact on testing. |
| STE-BO2 | Use appropriate security test techniques and know their strengths and limitations. |
| STE-BO3 | Contribute to planning, designing and executing security tests. |
| STE-BO4 | Use security standards and best practices for testing. |
| STE-BO5 | Adapt security testing to the organization's context. |
| STE-BO6 | Adapt security testing to the development method and lifecycle (sequential, Agile, DevOps). |
| STE-BO7 | Feed test results into an information security management system (ISMS). |
| STE-BO8 | Collect, evaluate and aggregate results and write a detailed report with evidence and findings. |
| STE-BO9 | Define tool requirements and help select security testing tools. |
The CT-STE syllabus chapter by chapter
The syllabus has nine examinable chapters. The times below are the minimums ISTQB requires for an accredited course, and they are also a good guide for how long to study each topic.
| Chapter | Minimum time | Max K-level | Key topics |
|---|---|---|---|
| 1. Security paradigms | 135 min | K3 | Asset security levels, information sensitivity, audits, Zero Trust, open-source software |
| 2. Security test techniques | 150 min | K3 | Black-, white- and grey-box; static vs. dynamic; IAM, reconciliation and recertification; encryption; protective technologies |
| 3. The security test process | 120 min | K3 | Activities and responsibilities, test environment, design per test level, end-to-end testing |
| 4. Standards and best practices | 195 min | K3 | ISO, NIST, OWASP, CAPEC, CWE, CWSS, CVSS, CVE; oracles derived from standards |
| 5. Organizational context | 195 min | K4 | Organizational structures, regulations and policies, attack scenario analysis, incident response |
| 6. Development lifecycles | 165 min | K4 | Sequential, Agile and DevOps models; regression and confirmation testing in maintenance |
| 7. Security testing within an ISMS | 105 min | K3 | Acceptance criteria, ISMS inputs, maturity and measurability |
| 8. Reporting results | 135 min | K3 | Criticality and handling of results, vulnerability analysis, closing vulnerabilities |
| 9. Security testing tools | 90 min | K3 | Categories (SAST, SCA, DAST, IAST), selection criteria, open source vs. commercial |
Chapter 1. Security paradigms
Before testing, you need to know what to protect and how much. The chapter opens with asset security levels: an informational page is not the same as the customer database or the encryption keys. Information sensitivity drives how deep testing goes, based on the confidentiality, integrity and availability triad.
It then explains the role of testing in a security audit: the audit checks that controls exist and are followed; testing provides the technical evidence that they work. It also introduces Zero Trust (trust nothing by default, not even inside the network) and how to apply it when testing, for example by checking that an internal microservice rejects a call without a valid token even when it comes from another service on the same network.
It closes with open-source software: most of an application today is third-party dependencies, and each one can bring known vulnerabilities. A practical example: a logging library with a public vulnerability forces you to identify which systems use it and to test the patch.
Chapter 2. Security test techniques
This is the most technical chapter. It first classifies tests by the information available: black-box (you attack as an outsider without knowing the code), white-box (with access to code and architecture) and grey-box (partial knowledge, for example with a regular user's credentials). It then separates static testing (code review, static analysis, configuration review) from dynamic testing (running the system and attacking it).
The second part gets down to specific controls:
- Identity and access management (IAM): reconciliation tests (actual accounts and permissions match the authorized ones) and recertification tests (permissions are reviewed periodically). Example: finding that someone who left the company three months ago still has active access.
- Identification, authentication and authorization: testing weak passwords, account lockout, MFA, and that a user cannot see another user's data by changing an ID in the URL.
- Encryption: checking that data in transit uses correctly configured TLS and that sensitive data at rest is encrypted.
- Protective technologies: system hardening, firewalls, intrusion detection, malware scanning and data obfuscation (for example, making sure test environments don't use unmasked production data).
Chapter 3. The security test process
Here the syllabus takes the test process you know from Foundation Level (planning, analysis, design, implementation, execution, monitoring and control, completion) and adapts it to security, stating which tasks belong to which role. For example, during execution the engineer runs functional security tests and penetration tests; at completion, results and sensitive data are archived in secure locations.
It also describes what makes a good security test environment: isolated from production, representative and authorized. Then it explains how to design tests per level: component (for example, checking that a function sanitizes input against SQL injection), integration (services authenticate each other) and system and acceptance, where the K3 objective is to implement an end-to-end test that validates security requirements within a business process, such as a complete password recovery flow.
Chapter 4. Standards and best practices
A Security Test Engineer doesn't reinvent the wheel; they rely on recognized catalogs. The chapter separates standards (ISO, NIST) from best practices and goes deep into the industry's de facto resources:
- OWASP: a community with guides and risk lists for web applications and APIs.
- CAPEC: a catalog of attack patterns.
- CWE: a catalog of software weakness types (for example, improper input validation).
- CVE: identifiers for specific public vulnerabilities.
- CVSS and CWSS: systems for scoring the severity of vulnerabilities and weaknesses.
The K3 objective is to apply these resources when testing. Example: you take a scanner finding, map it to its CWE, check whether a CVE exists for that component version and use CVSS to prioritize it. You will also see how to use standards as a test oracle, their pros and cons, and the difference between applying them because you must (regulation, contract) or voluntarily.
Chapter 5. Adapting security testing to the organizational context
This is one of the two chapters at K4 (analyze). It first looks at how the organization's structure (size, sector, suppliers, cloud) changes what needs testing. It then covers regulations, their impact on security policies and how to test that those policies are actually followed.
The most interesting part is attack scenario analysis: types of attackers and their motivations, and the typical phases of an attack (information gathering, exploitation and gaining access, persistence and clearing tracks). It closes with incident response: preparation, detection and analysis, containment, eradication and recovery, and post-incident activity. On the exam you may get a scenario and have to identify the likely source and motivation of the attack.
Chapter 6. Adapting security testing to the lifecycle
Security must be tested throughout the lifecycle, not just at the end. The chapter compares how activities change in sequential models, in Agile (with principles such as "developers and testers over security specialists" and "securing as you work over securing after you are done") and in DevOps, where security tests are automated inside the pipeline.
In operations and maintenance, the K3 objective is to define and run security regression and confirmation tests after a change. Example: after upgrading the authentication framework, you rerun session, token expiration and access control tests, and confirm the fixed vulnerability can no longer be exploited.
Chapter 7. Security testing as part of an ISMS
An ISMS (information security management system, such as the one described in ISO/IEC 27001) needs data to manage risk. This chapter explains how security acceptance criteria shape the techniques you choose, how your test results become ISMS input and how you can help it mature by adding new test objects, new approaches or better coverage, and by making security more measurable.
Chapter 8. Reporting security test results
A security finding is sensitive information: if the report leaks, it becomes an attack manual. That is why the chapter starts with the criticality of results and how to handle and communicate them. It then teaches you to evaluate results to identify real vulnerabilities (ruling out false positives and adjusting impact to context) and to evaluate techniques for closing them: hiding the vulnerability (a temporary mitigation, for example a web application firewall rule) or avoiding it (fixing the root cause in code or configuration).
Chapter 9. Security testing tools
The last chapter classifies tools: white-, black- and grey-box; static ones such as SAST (source code analysis) and SCA (third-party component analysis); and dynamic ones such as DAST (attacking the running application) and IAST (instrumenting the application while it is tested). It also covers selection criteria, including open-source versus commercial tools. The syllabus doesn't recommend brands; it teaches you to choose based on your needs.
Download the official syllabus
Download the syllabus to study from the original source. At the time of writing, ISTQB publishes it in English.
The CT-STE exam
This is the official structure according to the ISTQB exam structure tables:
| Item | Value |
|---|---|
| Number of questions | 40 (multiple choice) |
| Total points | 43 |
| Pass mark | 28 points (65%) |
| Duration | 75 minutes; 94 minutes if you take it in a language that isn't your native language (+25%) |
| Distribution by K-level | 24 K2 questions, 13 K3 and 3 K4 |
| Prerequisite | ISTQB Foundation Level (CTFL) certification |
Note the distribution: more than a third of the questions are application or analysis. Memorizing definitions is not enough; you will be working through scenarios.
Exam formats
- Online with remote proctoring (iSQI FLEX): from home, 24/7. You need a webcam, a microphone, a second camera (your phone works) and a government-issued ID. Book ahead: iSQI asks for at least 2 hours for Foundation exams and 48 hours for advanced ones; confirm the lead time for this exam when you book.
- Pearson VUE: at a test center or online with OnVUE, depending on availability for this exam.
- At your company: for groups of 6 or more, Cool Testers brings a proctor for an in-person exam.
Paper exams are no longer offered. At the time of writing, iSQI offers the CT-STE exam in English, so the 25% extra time applies if English isn't your native language. The certification is worth exactly the same in any language.
Where to buy it
- Directly from iSQI, our partner and official exam provider. Best if you are paying yourself.
- Through Cool Testers, with 1 or 2 attempts and 1 year to take it. Best if your company pays, you get reimbursed or you need a Mexican tax invoice: buy or get a quote for your certification exam.
Not sure which option fits you? Message us on WhatsApp.
How to prepare for CT-STE
Cool Testers doesn't currently offer a dedicated CT-STE course, so here is the path we recommend:
- Lock in your Foundation Level base. It is mandatory, and the security syllabus reuses the CTFL test process, test levels and techniques. If you don't have it yet, start with our ISTQB Foundation Level (CTFL 4.0) course: 40 live hours, a pre-recorded course, an Express review course and 4 practice exams. And check the ISTQB certification guide to plan your path.
- Read the whole syllabus once without taking notes, to get the big picture.
- Study chapter by chapter using the times as a guide. Chapters 4 and 5 are the longest (195 minutes each), and chapters 5 and 6 have K4 objectives: give them more time.
- Practice on real cases. Take an intentionally vulnerable practice application, go through the OWASP Top 10, run a DAST scanner in an authorized environment and classify the findings with CWE and CVSS.
- Take the official ISTQB sample exam and work out why each wrong answer is wrong.
- Review the glossary: every keyword and security term is examinable at K1.
Need to train a team at your company in security testing? Request a corporate training proposal.
Benefits and career paths
- Clear differentiation: there are many functional QA testers and few who master security testing within a recognized framework.
- A common language with information security: CWE, CVSS, ISMS and incident response stop being foreign acronyms.
- A natural fit for DevSecOps: plugging SAST, SCA and DAST into the pipeline is a growing need for teams that release often.
- International recognition: ISTQB is the most widespread software testing certification scheme in the world, useful if you work, or want to work, on projects for the US or Europe.
Roles where it adds value: security-focused QA, Security Test Engineer, automation engineer with DevSecOps responsibilities, junior vulnerability analyst, or quality consultant in regulated sectors such as banking and healthcare.
How it relates to other certifications and what comes next
CT-STE and CT-SEC
The 2016 Security Tester (CT-SEC) combined several roles and activities in a single certification. According to ISTQB, it was split in two to draw a clearer line between responsibilities: CT-STE, focused on the hands-on execution of security testing, and CT-STA (Security Test Analyst), focused on analyzing business security risks and defining security testing strategies. ISTQB scheduled CT-STA for 2026; check istqb.org for its current status. CT-SEC holders don't get CT-STE automatically: they have to pass the exam.
Other complementary certifications
- Technical Test Analyst (CTAL-TTA): goes deeper into technical quality characteristics, including security, and white-box techniques.
- Quality in DevOps (CT-QDO): ideal if your security tests live in a CI/CD pipeline.
- Test Automation Engineering (CTAL-TAE): for designing automation architectures that integrate security tools.
- Performance Testing (CT-PT): availability is security too; load testing helps you understand resilience to denial-of-service attacks.
Frequently asked questions
What does CT-STE stand for?
Certified Tester Security Test Engineer. It is the ISTQB certification for professionals who carry out security testing: they apply techniques, set up environments, use tools, analyze vulnerabilities and report results.
Do I need Foundation Level to take CT-STE?
Yes. ISTQB requires the Foundation Level (CTFL) certification before you take the CT-STE exam. An accredited course is not mandatory.
How many questions does the CT-STE exam have and how long is it?
It has 40 questions worth 43 points in total; you pass with 28 points (65%). It lasts 75 minutes, or 94 minutes if you take it in a language that isn't your native language.
Do I need to know how to code?
It isn't mandatory. ISTQB states that technical knowledge is not an exam requirement, although a development or testing background helps you follow the code and tool examples.
Does CT-STE replace CT-SEC?
ISTQB split the 2016 CT-SEC into two certifications: Security Test Engineer (execution) and Security Test Analyst (strategy and risk). There is no automatic transfer: if you hold CT-SEC and want CT-STE, you have to take the exam.
Which languages is the CT-STE exam available in?
At the time of writing, iSQI offers it in English, with 25% extra time if English isn't your native language. The certification has the same value regardless of exam language.
Does Cool Testers offer a CT-STE course?
Not at the moment. We recommend starting with the ISTQB Foundation Level (CTFL 4.0) course, which is a prerequisite, and preparing with the official syllabus and sample exam.