ISTQB Security Tester (CT-SEC): How to Prepare and What It Covers

Updated on 22 September 2026. What’s new: added ISTQB's 2025 announcement of the CT-STE exam and what it means for the CT-SEC 2016 syllabus.

Picture a release that passed every functional test and still leaked customer data within a week: the checkout worked, the reports added up, yet one account could read another account's orders. The ISTQB Certified Tester Security Tester (CT-SEC) credential proves you can find that kind of gap. It is a 45-question, 120-minute exam, passed at 52 of 80 points, open to Foundation Level holders with relevant experience.

This article follows that leaky release from the post-mortem back to the syllabus. It explains why functional testing missed the problem, what the CT-SEC exam expects you to know, how its nine chapters are weighted, where security testing belongs in a lifecycle, why people are treated as a security surface of their own, and how to prepare without wasting weeks. It closes with an honest look at where CT-SEC stands now that ISTQB has introduced newer security testing certifications.

Why can a release pass every functional test and still leak data?

Go back to that release. The test team had done its job by the usual measure. Every user story had acceptance tests, every test passed, and the regression suite was green. The defect that reached customers was not a broken feature. It was a missing control: the order page trusted the order number in the address bar and never checked that the order belonged to the person asking for it. Change one digit and a stranger's delivery address appeared.

Functional tests are written from the requirement outward. They ask whether the system does what it should for the people who are supposed to use it. Nobody had written a requirement saying that a customer must not be able to view someone else's order, so nobody had a test for it. The tests were correct, and they were aimed at the wrong question.

Security asks a different question

Security testing starts from the other side. It asks what the system allows that it should not, and who would want to make use of that. The tester thinks about assets worth stealing, the people motivated to steal them, and the paths those people could take. In the leaky release, the asset was personal data, the path was a predictable identifier, and the missing test was a simple authorisation check with a second account.

Why the gap keeps appearing

The ISTQB syllabus makes a point worth remembering here: security cannot be patched into code or tested into code after the fact. It has to be stated in requirements, built into design and implemented in code, and testing then verifies that each of those steps held. When a project treats security as a final scan before release, gaps like the order page are almost guaranteed, because nobody owned the question earlier. A security tester is the person who asks it at every stage, which is precisely the skill CT-SEC sets out to certify.

What the post-mortem would have found

A good security test process would have caught the defect in at least three places. A requirements review would have flagged that access rules for order data were never written down. A design review would have noticed that the order identifier was sequential and exposed. A system-level test with two accounts would have shown the leak directly. None of these needs exotic tooling. They need someone who knows which questions to ask and when.

What does the ISTQB Security Tester certification actually prove?

CT-SEC shows that a tester can plan, perform and evaluate security tests from several angles: risk, vulnerabilities, human behaviour and requirements. It also covers security testing tools and the standards that shape security work. It was first published as an Advanced Level syllabus in 2016, which is why many people still search for it as the ISTQB Advanced Security Tester, and ISTQB now lists it among its specialist certifications.

Who the exam is aimed at

The certification suits testers who already run functional or non-functional tests and now carry security responsibilities, test analysts who review requirements and designs, developers moving toward application security, and test managers who have to plan and staff security testing. It is less suitable for someone entirely new to testing: the exam assumes you understand test design, test levels and defect reporting, and then asks you to apply them to security.

Entry requirements

According to ISTQB's Security Tester certification page, candidates must hold the Certified Tester Foundation Level certificate and have at least three years of relevant academic, practical or consulting experience. The Foundation certificate matters in practice too, because the syllabus builds on its vocabulary for test processes, levels and techniques without explaining them again.

The exam facts in one place

Item	Detail
Exam name	ISTQB Certified Tester Security Tester
Exam code	CT-SEC
Certification	ISTQB Certified Tester - Security Tester (CT-SEC)
Exam fee	USD $249
Exam duration	120 minutes
Number of questions	45
Passing score	52 / 80
Syllabus	ISTQB CT-SEC syllabus, version 2016 (checked September 2026)
Prerequisite	ISTQB Foundation Level certificate plus three years of relevant experience

Two details in the table deserve a second look. First, the passing score is expressed in points, not questions. Questions are worth different numbers of points depending on their cognitive level, so the harder analysis questions carry more weight than a simple recall question. Second, ISTQB allows an extra quarter of the time for candidates who sit the exam in a language that is not their own, as stated on the same ISTQB page. Fees can differ by country and exam provider, so confirm the price when you book.

Where CT-SEC sits in ISTQB's current line-up

In February 2025 ISTQB announced the Certified Tester Security Test Engineer (CT-STE), and its help pages describe the 2016 Security Tester syllabus being divided between CT-STE and a planned Security Test Analyst certification. ISTQB has also said there is no grandfathering: holding CT-SEC does not give you CT-STE. At the time of writing, ISTQB's CT-SEC page still lists the 2016 syllabus and the exam details shown above, with no retirement date. The last section of this article discusses what that means for your choice.

What do the nine chapters of the Security Tester syllabus cover, and where is the weight?

ISTQB gives every chapter a recommended teaching time, and those minutes are the best public signal of how much material each chapter holds. Across all nine chapters the total is 1,110 minutes. The chart shows the six largest; chapter 7 follows at 70 minutes, then chapter 8 at 55 and chapter 9 at 40.

Two chapters, testing security mechanisms and security across the lifecycle, account for roughly two fifths of the teaching time between them. They are also the chapters with the most "demonstrate" and "implement" objectives, so they reward practice rather than memorising. Our Security Tester syllabus breakdown lists every learning objective under its chapter, which makes it a handy checklist while you study.

Chapter 1: The basis of security testing

This chapter ties testing to business risk. You learn how risk assessment feeds security test planning, how to identify the assets worth protecting and what they are worth, and how security policies and procedures are applied and judged against test results. It closes with the purpose of a security audit and how audits differ from testing.

Chapter 2: Purposes, goals and strategies

Here the syllabus explains why an organisation tests security at all: to identify risks, to measure how well current defences work and to show due diligence if a breach ever ends up in court. You learn to align security test objectives with the organisation's security policy, to choose among testing approaches for a given situation, to analyse why an approach failed, and to use key performance indicators to improve the practice.

Chapter 3: Security testing processes

This is the test process seen through a security lens: defining the process, reviewing a security test plan for strengths and weaknesses, designing abstract security tests from risks, building a safe test environment, getting approval before any test that could disrupt systems, evaluating results for the nature, extent and impact of each vulnerability, and keeping the process current as threats change.

Chapter 4: Security testing throughout the lifecycle

The longest chapter after mechanisms, and the one the next section covers in detail. It asks you to analyse requirements and designs for security deficiencies, implement component and integration security tests, write end-to-end security scenarios, define acceptance criteria for security, and plan retesting during maintenance.

Chapter 5: Testing security mechanisms

The heaviest chapter covers eight mechanisms, and for most of them you must both understand the concept and demonstrate how to test it: system hardening, authentication and authorisation, encryption, firewalls and network zones, intrusion detection, malware scanning, data obfuscation, and security training. The leaky order page from the opening is an authorisation failure, which is exactly the kind of weakness this chapter teaches you to probe.

Chapter 6: Human factors

This chapter looks at attackers, social engineering and security awareness. It is short in minutes but prominent in searches, and it gets its own section below.

Chapters 7, 8 and 9: Reporting, tools and standards

Chapter 7 covers revising security expectations as a project changes, keeping results confidential, and judging whether an interim security status report is accurate and suited to its audience. Chapter 8 explains static and dynamic analysis tools, how to document tool needs, the issues with open source tools and why a tool vendor's update rate matters. Chapter 9 introduces security testing standards, the difference between regulatory and contractual use, normative versus informative clauses, and where to follow industry trends.

When should security testing begin in the software lifecycle?

The syllabus answer is short: as early as possible, and then at every stage. Security testing begins before there is any code to test, because the cheapest security defect to fix is the one caught in a requirement. The diagram shows what the tester does at each stage, following chapter 4.

Requirements

The tester reads requirements looking for what is missing. Are there access rules for each type of data? Is there a stated rule for session length, password handling or audit logging? In the leaky release, a single sentence such as "a customer may view only their own orders" would have produced the test that caught the defect. Security requirements that are vague, such as "the system shall be secure", are themselves a finding.

Design

In design reviews the tester follows data across trust boundaries: where it enters, where it is stored, who can reach it and how identity is checked along the way. Predictable identifiers, trust in client-side checks and sensitive data sent to places it does not need to go are typical findings at this stage.

Implementation

During component testing, security tests check input handling, error handling and the correct use of security functions in each unit. During component integration testing, they check that the pieces keep their guarantees when joined: that one service does not accept a call another service should have rejected. Static analysis tools fit well here because they work on code before it runs.

System and acceptance testing

At system level the tester writes end-to-end scenarios that exercise a business process and verify one or more security requirements along the way, such as a full purchase in which a second user attempts to view, change or cancel the order. For acceptance, the syllabus asks you to define acceptance criteria for security, so that "secure enough to release" becomes a measurable decision instead of a feeling.

Maintenance

Every change can undo an earlier fix. The syllabus expects a retest and regression approach for security, based on risk, so that patches, configuration changes and new features are checked against the vulnerabilities already found. Many real breaches come from a control that once worked and quietly stopped working after an unrelated change.

Why does the syllabus give human factors a chapter of its own?

Because many successful attacks begin with a person rather than a flaw in the code. A strong password policy means little if someone reads a password out over the phone to a convincing caller. The syllabus treats people as part of the system under test, and this chapter draws steady search interest from candidates for good reason: it is where questions turn from technical controls to judgement.

Understanding the attackers

You are expected to explain how human behaviour creates security risk, how an attacker gathers information about a target during reconnaissance, and what motivates attacks. The syllabus notes that insiders who already have authorised access are a major source of attacks, and that attackers range from low-skill script users to highly motivated and well-resourced groups. Exam scenarios often describe an attack that was performed and discovered, then ask you to identify the likely source and motive.

Social engineering

This part covers how defences are bypassed by manipulating people: pretext phone calls, phishing messages and physical tricks such as following an employee through a secure door. A tester's role is to assess how exposed the organisation is, always with written authorisation and agreed limits, because this kind of testing involves real employees.

Security awareness

The chapter ends with awareness across the organisation and asks you to choose actions that raise it based on test outcomes. If a simulated phishing test shows that many staff entered their credentials, the useful response is targeted training and a follow-up measurement, not a list of names. That link between results and improvement also connects to the training mechanism in chapter 5.

How should you prepare for the CT-SEC exam in eight weeks?

Eight weeks of steady study suits most candidates who already hold the Foundation certificate and work in testing. Use the chapter minutes as your budget: spend the most time where the syllabus spends it, and practise the objectives that ask you to demonstrate, implement or analyse.

Weeks 1 and 2: Foundations and purpose

Read chapters 1 and 2 in the ISTQB Security Tester syllabus PDF and learn its keywords. For each objective, write a two-line example from your own work: an asset you would protect, a policy you have seen applied, a security objective you could derive from a real feature. Examples from your own projects stick far better than definitions.

Weeks 3 and 4: Process and lifecycle

Work through chapters 3 and 4 together, since the lifecycle chapter applies the process chapter stage by stage. Take one feature you know well and draft a small security test plan for it: risks, abstract tests, environment needs, approvals and retest strategy. Then review your own plan the way the exam would ask you to review someone else's.

Weeks 5 and 6: Mechanisms

Give chapter 5 two full weeks. For each of the eight mechanisms, write down what it protects, how it commonly fails and how you would test it. A small lab helps here: a deliberately vulnerable practice application run on your own machine lets you try authorisation, session and input tests safely and legally, without touching systems you do not own.

Week 7: People, reporting, tools and standards

Cover chapters 6 to 9. They are shorter, but their questions are often scenario-based. Practise reading an interim security report and deciding whether it is accurate and suited to its readers, and practise matching tool types to a documented testing need.

Week 8: Timed practice and review

Sit ISTQB's CT-SEC sample exam under real time limits, then review every answer, including the ones you got right by luck. Afterwards, a timed CT-SEC mock exam on fresh questions shows whether your score holds up when the wording is new, and which chapters still need a final pass. With 45 questions in 120 minutes you have well over two minutes per question, so the time pressure comes from long scenarios, not from volume.

What mistakes cost candidates points on the Security Tester exam?

Most lost points come from a handful of habits that show up again and again in exam reviews.

• Studying like a penetration tester. The exam is about the test process applied to security: planning, design, evaluation and reporting. Knowing attack tools in depth helps less than knowing how to choose and justify an approach.
• Skipping the short chapters. Chapters 7 to 9 are small in minutes but produce clear, answerable questions. Leaving them out throws away easy points.
• Treating every question as one point. Analysis questions are worth more. Rushing a long scenario to save time on easy recall questions is usually a bad trade.
• Answering from company habit. Your organisation may skip approvals or run scans in production. The exam follows the syllabus, which insists on authorisation, a controlled environment and confidentiality of results.
• Ignoring the business context. Many questions ask which option best fits the organisation's risk, policy or constraints. The most thorough technical answer is not always the right one.
• Confusing security testing with security auditing. The syllabus separates the two, and questions test whether you know which activity answers which purpose.

A useful check before booking: explain aloud, without notes, why the leaky order page from the opening escaped testing and which chapter's techniques would have caught it at each stage. If you can do that clearly, you understand the structure of the syllabus.

Is CT-SEC still worth taking now that CT-STE exists?

For many testers, yes, but it depends on what you need the certificate to say. CT-SEC remains on ISTQB's list with its 2016 syllabus, and that syllabus covers the whole span of security testing, from business risk and policy through lifecycle testing to people, tools and standards. That breadth suits test analysts and managers who have to plan security testing and talk to auditors, risk owners and developers in the same week.

When CT-STE may suit you better

CT-STE focuses on the practical execution of security testing and reflects more recent thinking, while the planned Security Test Analyst certification is intended to cover business risk analysis and strategy. If your role is hands-on security test execution, or an employer or client names CT-STE specifically, the newer credential may fit better. Because there is no grandfathering, CT-SEC holders who later want CT-STE must pass that exam too, so decide based on the work you do rather than on the name.

What the certificate does for your career

Security is one of the areas where testers can move from finding defects to influencing how systems are built. A recognised certificate helps in three concrete ways: it gives hiring managers evidence that you understand security testing as a discipline, it gives you a shared vocabulary with security teams, and it supports a move into roles that review requirements and designs rather than only execute tests. It does not replace hands-on experience, and employers will still ask what you have tested.

Making the decision

If you already work on security testing and want a broad, established credential that covers planning, lifecycle, people and standards, CT-SEC is a sensible choice while ISTQB continues to offer it. Check ISTQB's page before you book, since certification line-ups change, and plan your study around the chapter weights above. Whichever route you choose, the goal is the same one the leaky release taught: a team that asks what the system should never allow, and tests for it before customers find out.

Frequently Asked Questions

What is the ISTQB Advanced Security Tester certification?

It is the certification now listed by ISTQB as Certified Tester Security Tester, code CT-SEC. Its syllabus was first published in 2016 at Advanced Level, which is why the older name is still searched. It tests planning, performing and evaluating security tests, lifecycle security testing, security mechanisms, human factors, tools and standards.

What does the CT-SEC syllabus say about human factors in security testing?

Chapter 6 covers understanding attackers, including reconnaissance, insider threats and common motives, then social engineering and security awareness. Candidates must explain how human behaviour creates risk, analyse an attack scenario to identify its likely source and motive, and choose actions that raise awareness based on test results.

When should security testing begin according to the ISTQB Security Tester syllabus?

As early as possible. The syllabus treats security as a lifecycle activity: testers review requirements and designs for security gaps before code exists, then run component, integration, system and acceptance security tests, and plan risk-based retesting during maintenance. Security cannot be tested into software at the end.

How many questions are on the CT-SEC exam and what is the passing score?

The CT-SEC exam has 45 multiple-choice questions and a time limit of 120 minutes. The passing score is 52 of 80 points. Questions carry different point values depending on their cognitive level, so analysis questions count for more than recall questions. Candidates taking the exam in a non-native language receive extra time.

Do I need the ISTQB Foundation Level before taking CT-SEC?

Yes. ISTQB requires candidates to hold the Certified Tester Foundation Level certificate and to have at least three years of relevant academic, practical or consulting experience. The Foundation certificate also matters for study, because the Security Tester syllabus builds on its test process and technique vocabulary without explaining it again.

Select ratingPoorOkayGoodGreatAwesome

Rating: 4.8 / 5 (626 votes)