ISTQB Security Test Engineer Certification: Skills, Cost and Career Value

The ISTQB Security Test Engineer certification is for testers who want to move from finding functional defects to finding exploitable ones. It shows that you can choose and run security test techniques, build tests from OWASP, CWE and CVSS, adapt them to Agile and DevOps delivery, and report vulnerabilities in a form an information security team can act on.

ISTQB launched the certificate, exam code CT-STE, in February 2025 as part of its Specialist stream. The syllabus in force is version 1.0.1, dated 31 January 2025, and it was still the current release when we checked ISTQB's Security Test Engineer certification page in November 2026. This article looks at the certificate from the job outward: what the role involves, who the exam suits, how its 40 questions are spread, what each part of the syllabus asks you to do at work, and how to prepare without losing a month to reading.

What does a security test engineer actually do on a delivery team?

A security test engineer runs the tests that show whether a system resists attack, and then explains the results so that the right people fix the right things first. The syllabus draws a clear line between two roles. A Security Test Analyst designs security tests; the Security Test Engineer, the role this certificate covers, carries them out, sets up the environment they run in, chooses the tools, adapts the work to the project's lifecycle and writes the report. In a small team one person does both. In a larger organisation the engineer is the person closest to the system under test.

In practice the work splits into four recurring tasks:

• Preparing a safe test environment. The syllabus lists four characteristics: isolated at the right level, representative of production in version and configuration, equipped with the tools needed to plan, run and report, and recoverable so tests can be repeated after corruption. Payment-card rules are a good example of why this matters: PCI DSS requires pre-production environments to be separated from production and forbids live production data in test.
• Running security tests at every test level. Component tests check code against weaknesses such as unsafe input handling; integration tests check how components trust each other; system and acceptance tests confirm end-to-end security requirements such as login, session handling and data protection.
• Testing the controls that protect identities and data. That means identification, authentication and authorisation, the periodic recertification of user permissions, encryption, and protective technologies such as system hardening and firewalls.
• Turning findings into decisions. A vulnerability report is only useful if it rates severity, carries evidence and reaches an information security management system (ISMS) that tracks risk over time.

The difference from functional testing is mostly one of mindset. A functional tester asks whether the system does what the requirement says. A security tester asks what the system does when someone deliberately behaves in a way no requirement mentions: sends a malformed token, replays a request, reads a file through a path that was never meant to be reachable. The certificate's job is to make that second question systematic rather than ad hoc.

Is security testing a growing career path?

Demand is strong, although official statistics do not track "security tester" as a job title of its own. The closest category in the US Bureau of Labor Statistics data is information security analysts, a group that includes many people who test and assess systems. According to the BLS Occupational Outlook Handbook, the median annual wage for that group was $129,180 in May 2025, there were about 192,900 jobs in 2025, and employment is projected to grow 21 percent between 2025 and 2035, much faster than average. Pay for a security-focused tester depends heavily on country, sector and how much of the role is hands-on testing, so treat the BLS figure as a direction of travel rather than a salary promise.

What the certificate changes is how you are read in that market. A Foundation Level tester applying for a security role usually has to prove, interview by interview, that they understand threat models, vulnerability scoring and the difference between static and dynamic analysis. The Security Test Engineer syllabus covers exactly those points, so the certificate gives a hiring manager a known baseline before the technical interview starts.

Who should take the ISTQB Security Test Engineer certification, and what must you hold first?

The certificate suits testers, test leads, developers who test their own code and security staff who want a structured view of testing. The firm requirement is the ISTQB Certified Tester Foundation Level certificate: the syllabus states that it must be obtained before you take the Security Test Engineer exam. ISTQB also recommends at least a minimal background in software development, software testing or security testing. An accredited training course is not a prerequisite, so self-study candidates can book the exam directly through an ISTQB member board or exam provider.

Item	Detail
Certification	ISTQB Certified Tester - Security Test Engineer (CT-STE)
Stream	Specialist
Syllabus version	Version 1.0.1 (31 January 2025)
Entry requirement	ISTQB Foundation Level certificate
Questions	40 multiple-choice questions, 43 points in total
Passing score	28 / 43 (about 65 percent)
Exam length	75 minutes, plus 25 percent extra time when sitting in a non-native language
Price	USD 249 (as of November 2026; confirm with your exam provider)

Fees and delivery options vary by country, because the exam is sold through member boards and their exam providers. Some sell it online with remote proctoring, others through test centres or at the end of a training course. Check the final price, local taxes and available languages when you book.

How it relates to the older Security Tester certificate

Many candidates first meet ISTQB security testing through the Advanced Level Security Tester certificate (CT-SEC), built on a 2016 syllabus. The Security Test Engineer certificate is a separate qualification with its own syllabus and exam. When ISTQB announced it on 3 February 2025, it confirmed that no grandfathering applies to CT-SEC holders: if you hold the older certificate and want this one, you sit the new exam. The content overlaps in places, but the newer syllabus adds topics that barely existed in 2016 testing practice, such as zero trust, open-source supply-chain risk and security testing inside DevOps pipelines.

How are the 40 questions spread across the nine chapters?

ISTQB's Exam Structures and Rules tables (version 1.20, October 2026) fix how many questions each learning objective receives. Most questions carry one point. Questions at cognitive level K4, which ask you to analyse a scenario, carry two points each, which is why 40 questions add up to 43 points. The table below combines those figures with the course time the syllabus sets for accredited training, which is a fair guide to how much study each chapter needs.

Chapter	Course time (min)	Highest K-level	Questions	Points
1. Security paradigms	135	K3	6	6
2. Security test techniques	150	K3	7	7
3. The security test process	120	K3	5	5
4. Standards and best practices	195	K3	4	4
5. Adjusting to the organisational context	195	K4	4	6
6. Adjusting to lifecycle models	165	K4	4	5
7. Security testing in an ISMS	105	K3	4	4
8. Reporting security test results	135	K3	3	3
9. Security testing tools	90	K3	3	3

Three things stand out. First, the paper has no pure recall questions: of the 40, twenty-four are at K2 (understand), thirteen at K3 (apply) and three at K4 (analyse). Keywords are still examinable, but they turn up inside scenarios rather than as definition questions. Second, the opening three chapters provide eighteen of the 43 points, so a candidate who knows the techniques and the process well has most of a pass before reaching the harder material. Third, the two K4 chapters, on organisational context and lifecycles, carry eleven points between them while taking only eight questions.

The rules tables also suggest a time per question: about one minute for a K2 question, three for a K3 and four for a K4. Added up, that fills the full 75 minutes with nothing to spare, so pacing matters more here than on Foundation Level. Answer the K2 questions briskly and bank the time for scenario questions, which often need you to read a short case, a code fragment or a test log before choosing.

Which security test techniques does the syllabus expect you to apply?

Chapters 1 to 3 form the working core of the certificate. They move from the ideas behind security testing to the techniques themselves and then to the process that holds them together.

Security paradigms: assets, audits, zero trust and open source

Chapter 1 starts with assets. Not everything a system holds deserves the same protection, so the syllabus asks you to link the security level of an asset to the depth of testing it needs, using confidentiality, integrity and availability as the yardstick. It then separates security testing from security audits: an audit checks that controls exist and follow policy, while testing shows whether they actually hold up. Zero trust gets its own learning objective at K3, which means you must be able to apply it. In testing terms, that means never assuming a request is safe because it comes from inside the network: every call between services is a test target. The chapter closes with open-source software, where the risk sits in components you did not write and may not even know you ship.

Techniques: box views, static and dynamic, and the controls themselves

Chapter 2 asks you to classify security tests in two ways. The first is how much you know about the system: black-box (no internal knowledge), white-box (full access to code and design) and grey-box (partial knowledge, such as an API specification or a test account with defined rights). The second is whether the code runs: static testing examines code or configuration without executing it, while dynamic testing attacks the running system. Then the chapter turns to the controls a tester must check:

• Reconciliation and recertification of identities and permissions: are the accounts and rights in the system the ones the business actually approved, and are they reviewed on schedule?
• Identification, authentication and authorisation: weak password rules, missing lockout, session tokens that survive logout, and users who can reach another user's records by changing an ID in a request.
• Data protection and encryption: whether sensitive data is encrypted at rest and in transit, whether weak algorithms are still accepted, and whether keys are managed and rotated correctly.
• Protective technologies: system hardening and firewalls, tested to confirm that only the needed services are open, that access is restricted to the right roles and that firewall rules block what they should.

The one K3 objective here asks you to apply security test cases from a given test approach. Expect a scenario that describes an approach and asks which test case fits it best.

The process: from threat model to end-to-end test

Chapter 3 places those techniques inside the ISTQB security test process and across test levels. The syllabus treats threat modelling as a repeated activity: each test level is adjusted according to the latest threat-model results, rather than the model being drawn once at the start and forgotten. At component level you derive tests from a code fragment; at integration level you look at the trust boundaries between components; at system and acceptance level you implement an end-to-end test that confirms one or more security requirements, the K3 objective in this chapter.

How do OWASP, CWE, CVSS and CAPEC turn into test cases?

Chapter 4 is the longest in course time, tied with Chapter 5, and the one that carries most directly into daily work. It covers the public catalogues and scoring systems that give security testing a shared vocabulary. The syllabus names the Open Web Application Security Project (OWASP), Common Vulnerabilities and Exposures (CVE), Common Weakness Enumeration (CWE), the Common Vulnerability Scoring System (CVSS), the Common Weakness Scoring System (CWSS) and the Common Attack Pattern Enumeration and Classification (CAPEC). The K3 objective asks you to apply them, not just recognise the acronyms.

Here is how they fit together on a single test target, a login form that takes a username and password:

1. Start from a weakness class. CWE describes the kind of mistake, for example CWE-89, improper neutralisation of special elements used in an SQL command. That tells you what could be wrong in the code.
2. Pick the matching attack pattern. CAPEC describes how an attacker exploits it. The syllabus itself uses SQL injection (CAPEC-66) and relative path traversal (CAPEC-139) as examples. The attack pattern gives you the shape of the test inputs.
3. Use a test guide for the technique. The OWASP testing guide lists test objectives and techniques for authentication, input validation and cryptography, which keeps your test cases complete and repeatable.
4. Check known vulnerabilities. If the login runs on a third-party framework, CVE entries tell you which published vulnerabilities affect the version you have.
5. Score what you find. CVSS rates a vulnerability on a scale from 0 to 10, which turns "we found an injection" into a severity that a product owner can compare with other work.

The chapter also covers when standards are mandatory and when they are voluntary, and what they offer as test oracles, sources of expected results. An oracle drawn from a standard is objective and auditable, but it can lag behind new attack techniques and it says nothing about the business logic of your particular system. Exam questions often ask you to weigh exactly that trade-off.

When you reach this point in your reading, it helps to test yourself with questions written in the exam's scenario style. Our security test engineer sample questions show how a standards question is framed around a short case rather than a definition.

Why do the two K4 chapters decide so many results?

Chapters 5 and 6 are where most well-prepared candidates still drop points. Both include K4 objectives, so their questions describe a situation and ask you to analyse it, and those questions carry two points each.

Organisational context, regulation and attack scenarios

Chapter 5 asks you to analyse a given organisation and decide what matters for security testing there: its structure, the data it holds, who its attackers might be and which regulations bind it. A hospital, a bank and a games studio need different testing even when they run similar software. The regulation objective asks how government rules, such as data-protection law like the EU's GDPR, shape security policy and how you would test that the policy is actually enforced. The K4 objective, analysing an attack scenario to identify its likely sources and motivation, receives two questions. A typical case gives you an incident description and asks who is most likely behind it and why, which in turn shows which defences deserve testing first.

Sequential, Agile and DevOps lifecycles

Chapter 6 asks how security testing changes with the development model. In a sequential project there is time for a planned security test phase, but findings arrive late and are costly to fix. In Agile, security tests have to fit into each iteration, often as acceptance criteria on user stories. In DevOps, much of the testing moves into the pipeline as automated static and dynamic checks, with the risk that nobody looks at the results once they turn into a stream of warnings. The K4 objective asks you to analyse how a given lifecycle affects security testing activities. The chapter then covers testing during operations and maintenance, where security regression tests check that a fix has not opened something else and confirmation tests check that the fix itself works.

The best preparation for these chapters is not more reading but more cases. Take two or three systems you know, a work project, an online bank, a public sector portal, and write down for each who would attack it, what they would want, which regulations apply and how the lifecycle would change your test plan. That habit is exactly what the scenario questions measure.

What happens after a vulnerability is found?

Chapters 7, 8 and 9 cover the part of the job that turns test results into risk decisions, and the tools that produce those results in the first place.

Feeding an information security management system

Chapter 7 links security testing to an ISMS, the management system, often aligned with ISO/IEC 27001, through which an organisation governs information risk. Security tests need clear acceptance criteria, because those criteria decide which tests are chosen and when testing can stop. Test results then become input for the ISMS: they show which controls work and which do not. The chapter also asks how adjusting your testing can improve the ISMS, both by giving a more complete view of the organisation's security and by making it measurable, for example by tracking how long vulnerabilities of each severity stay open.

Reporting and closing vulnerabilities

Chapter 8 starts from a point testers sometimes forget: security test results are themselves sensitive. A report that lists unfixed weaknesses is a map for an attacker, so it needs controlled distribution, not a ticket that every employee can read. The chapter then covers analysing results to identify real vulnerabilities, separating them from false positives, and two ways of closing them:

• Hiding a vulnerability changes the system so the defect can no longer be exploited, even though it still exists, for example a filter or configuration change in front of the weak component. It reduces impact quickly but leaves the root cause in place.
• Avoiding a vulnerability removes the defect itself: locate it, fix it at the right level, and retest. The syllabus is candid that this is usually time-consuming and expensive, which is why teams often hide first and avoid later.

Exam questions in this chapter tend to give you a situation and ask which closing technique fits it, or what should happen to a report that has reached the wrong people.

Choosing and using security testing tools

Chapter 9 is the shortest. It classifies tools as white-box, black-box and grey-box, and as static or dynamic, then covers what to consider when selecting one, such as the test approach, the technologies under test and how the results fit the reporting process. Static application security testing tools read source code or binaries for known weakness patterns. Dynamic tools probe the running application, much as an attacker would. You are expected to understand how each type works and when to use it, not to know any particular product.

How can a working tester prepare in about four weeks?

The syllabus sets about 22 hours of accredited course time. A self-study candidate who already holds Foundation Level and works in testing can usually cover that, plus practice, in four weeks of evening and weekend study. The plan below follows the point weightings rather than the chapter order alone.

• Week 1 – chapters 1 to 3. Read the syllabus closely and build a one-page summary of the box views, static and dynamic testing, the control areas and the four characteristics of a test environment. These chapters carry eighteen points, so do not rush them.
• Week 2 – chapters 4 and 9. Work through the standards with a real example, as in the login walkthrough above, and pair each tool category with the technique it supports. Read the OWASP testing guide sections the syllabus cites for authentication and cryptography.
• Week 3 – chapters 5 and 6. Spend most of the week writing your own cases: an organisation, its likely attackers, its regulations and its lifecycle. Then do the same in reverse: read an incident report from the news and identify the attacker's probable motivation.
• Week 4 – chapters 7 and 8, then timed practice. Finish the reporting and ISMS material, then sit the official ISTQB sample exam under the 75-minute limit. Review every wrong answer against the learning objective it tests.

Before you book, a timed run through our CT-STE mock exam shows whether your pacing holds across all nine chapters, and which K3 and K4 topics still cost you points.

Mistakes that cost points

• Studying keywords in isolation. There are no K1 questions on this paper, so a memorised glossary helps only when you can apply each term inside a scenario.
• Treating audits and tests as the same thing. The syllabus separates them, and questions often hinge on that difference.
• Answering from your own company's practice. The exam follows the syllabus. If your team handles reports or tooling differently, answer the way the syllabus describes.
• Running out of time on scenarios. With roughly three to four minutes allowed for each K3 and K4 question, spending too long early on recall-style items leaves the two-point questions rushed.
• Ignoring the lifecycle angle. Many candidates know the techniques but cannot say how DevOps or Agile changes when and how they are applied, which is exactly what the two-point Chapter 6 question asks.

The Security Test Engineer certificate will not make you a penetration tester overnight, and it does not try to. What it does is give a working tester a structured, internationally recognised way of thinking about security: which assets matter, which techniques fit, which standards to lean on and how to report what you find. For many testers, that structure is the step that turns occasional security testing into a security career.

Frequently Asked Questions

Do I need the ISTQB Foundation Level certificate before the Security Test Engineer exam?

Yes. The Security Test Engineer syllabus states that the ISTQB Certified Tester Foundation Level certificate must be obtained before you take the exam. ISTQB also recommends some background in software development, software testing or security testing, although no minimum years of experience are set.

How many questions are on the CT-STE exam, and what score do I need to pass?

The CT-STE exam has 40 multiple-choice questions worth 43 points, because its three K4 analysis questions carry two points each. You need 28 of the 43 points, about 65 percent. The exam lasts 75 minutes, with 25 percent extra time for candidates sitting in a non-native language.

How much does the ISTQB Security Test Engineer exam cost?

The exam fee is USD 249 as of November 2026. ISTQB exams are sold through member boards and their exam providers, so the final price, local taxes, languages and delivery options such as remote proctoring or test centres can differ by country. Confirm the details with your provider when you book.

Does the CT-SEC Security Tester certificate count towards CT-STE?

No. When ISTQB launched the Security Test Engineer certification in February 2025, it confirmed that no grandfathering applies to holders of the earlier CT-SEC Security Tester certificate. CT-STE has its own syllabus and exam, so CT-SEC holders who want the new certificate must pass the CT-STE exam.

Do I have to attend an accredited training course before sitting the exam?

No. The syllabus states that completing an accredited training course is not a prerequisite for the Security Test Engineer exam. Accredited courses must provide about 22 hours of instruction, which is a useful guide to the study time a self-study candidate should plan, but you can book the exam on your own.

Select ratingPoorOkayGoodGreatAwesome

Average: 5 (1 vote)