CTEM Penetration Testing 2026: What It Is, Where It Fits

CyberOrbit Team

August 5, 2026·26 min read

CTEM is Gartner's five-phase program for continuously finding and reducing exposure, and CTEM penetration testing sits inside it at phase four, validation. The question every security leader asks next is whether adopting the framework means they can stop paying for the annual signed test. The short answer is no, and the reason has nothing to do with budget inertia or auditor conservatism. It is that the two things answer to different audiences with different standards of proof, and the compliance frameworks say so in their own words.

What Is CTEM? Gartner's Five Phases in Plain English

Continuous Threat Exposure Management is a program you run, not a product you buy. Gartner introduced the term in 2022 to describe an operating cycle: instead of assessing your security once a year and filing the result, you run a loop that keeps asking what is exposed, what matters, and whether your controls actually hold. The framework is deliberately vendor-neutral, and no single tool covers all five phases.

That distinction matters. Buyers who treat CTEM as a software category come back with a discovery tool that has a dashboard bolted on. Buyers who treat it as a program design the cycle first, then fill each phase with what they can afford.

The five phases, and what each one actually asks

Scoping asks: what are we defending, and what would hurt if it broke? Not an asset inventory, a business-risk boundary. Which systems carry regulated data, which face the internet, which would stop revenue if they went down.

Discovery asks: what is actually inside that boundary? Assets, identities, misconfigurations, exposed services, third-party dependencies. It routinely returns more than scoping expected, which is the point.

Prioritisation asks: of everything we found, what deserves attention first? Not by CVSS alone. By exploitability, by reachability from the internet, by what the exposure is attached to.

Validation asks: can an attacker actually reach and use this, and would our controls stop them? This is phase four, and where penetration testing lives.

Mobilisation asks: how does the fix get made? Owners, tickets, SLAs, and the unglamorous work of getting engineering to accept security work into a sprint.

ℹ️CTEM is a program, not a product

No vendor sells "a CTEM", and no purchase completes the cycle. What you buy fills a phase. What you run is the loop that connects them, and the loop is the part that has to keep turning in a quarter where nothing new gets approved.

Read that list again and notice something. Most security teams already do phases one, two and five under different names. Scoping happens in your risk register. Discovery happens in your asset inventory and your scanner. Mobilisation happens in Jira. What CTEM adds to those three is not new activity but a cadence and a feedback loop connecting them. The framework has been public since 2022. So why did it land on your desk this quarter?

Why CTEM Is On Every 2026 Board Agenda

Two things happened. Exposure management finished turning from an analyst idea into a recognised buying category: Gartner has carried threat exposure management on its top cybersecurity trends list since 2023, and in November 2025 it published its first Magic Quadrant for Exposure Assessment Platforms. A named market category is what puts a topic in front of every board member who reads an analyst summary. And the 2022 prediction that accompanied the framework finally reached its target year.

That prediction is worth quoting carefully, because it is the most repeated statistic in CTEM marketing and it is almost always misused. Gartner projected that by 2026, organisations prioritising their security investments based on a continuous exposure management program would be three times less likely to suffer a breach. That is a real Gartner statement, and it is why your board is asking.

Gartner's 2026 breach-reduction prediction

Attributed to Gartner's 2022 strategic planning assumption, not a measured outcome. We are not aware of any independent study since publishing an adopter versus non-adopter breach-rate comparison.

It is also a strategic planning assumption, not a measured outcome. Gartner publishes forward-looking predictions to help organisations plan, and this was one. It was not derived from a study comparing breach rates between adopters and non-adopters, because in 2022 there were no adopters to compare, and we have found no independent study publishing that comparison since. If you see the three-times figure presented as a research finding, ask the vendor presenting it for the underlying study before you put it in a board pack.

None of which makes CTEM a bad idea. The underlying logic is sound: fixing the exposures an attacker can actually reach beats fixing whatever your scanner ranked highest this week. But know which parts of the pitch are evidence and which are assumption, because the difference surfaces the first time your CFO asks what the program bought.

The board pressure is real regardless. And when teams start building, one phase generates almost all of the confusion.

Phase 4 Is Where Everyone Gets Stuck: What Validation Means

Validation asks a narrow, useful question: of the exposures we prioritised, which can an attacker actually reach and use, and would our controls stop them? It separates a vulnerability list from a risk picture. A critical CVE on a host unreachable from any untrusted network is a patching task rather than an emergency, though it stays on the list, because reachability is a property of today's network and an assumed-breach path can change it without the CVE changing at all. The same CVE on an internet-facing host with no compensating control is an incident with a date on it.

Gartner is explicit that validation is not one technique. It expects a mix: breach and attack simulation, attack path mapping, red team exercises, and penetration testing. Automated pentesting is one input to phase four, not the whole of it. Teams that buy a single validation tool and call the phase done have bought a partial answer at full price.

The validation spectrum, from cheap and shallow to expensive and deep

At the cheap end sits control validation and breach and attack simulation. These fire known attacker techniques at your existing controls and tell you whether the EDR alerted, whether the WAF blocked, whether the egress rule held. Fast, safe, repeatable daily.

In the middle sits automated penetration testing and attack path analysis. These chain findings together, attempt real exploitation where it is safe to do so, and map how one exposure leads to another. Genuinely valuable work, and we covered where its boundary sits in when automated pentesting is enough and how the agentic generation works in our guide to agentic pentesting.

At the expensive end sits human red teaming and manual testing against business logic, chained authorisation flaws, and the kind of creative abuse no template encodes.

Here is the limitation vendor material tends to skip. Continuously running techniques stop at the boundary of what a live exploit can safely fire in production. You cannot detonate a destructive proof of concept against the system that runs payroll. Picus Security, a vendor in this space, describes its own validation product as covering the 85 to 90 percent of exposures that live exploitation cannot safely touch, which puts the share safely and automatically exploitable in a typical production environment at roughly 10 to 15 percent. Treat that as a vendor estimate rather than an independently measured figure, and note that Picus is commercially positioned on the remainder, so read the split as directional. Their analysis of where automated pentesting fits in CTEM sets out the reasoning. Wherever the exact line falls, the point holds: a large share of exposures need something not fully automated to confirm, whether that is a safe-mode test, a lab reproduction, or a human with authorisation and judgement.

What continuous testing is genuinely good at

The case for running phase four continuously is strong and deserves equal airtime. It catches drift between assessments, the config change on a Tuesday afternoon that quietly reopened a path you closed in March. It proves a patch closed the attack path rather than just closing the ticket, a distinction that has embarrassed more than one team during an incident review. And it keeps pace with a deploy cadence measured in hours rather than quarters, which annual testing structurally cannot do. If your environment changes weekly and you test yearly, you are testing a system that no longer exists for 51 weeks of the year.

Pros

✅Catches drift between assessments, including the config change nobody logged
✅Proves a patch closed the attack path, not just the ticket
✅Keeps pace with a deploy cadence measured in hours rather than quarters
✅Cost-effective to repeat, so testing frequency is not a budget decision

Cons

❌Stops at the boundary of what a live exploit can safely fire in production
❌Output is mutable and unsigned, so it evidences your program rather than attesting to it
❌No scope statement fixed to a point in time
❌No independent attester with a name and a liability attached

So run it. Phases one and two cost nothing to start, and the sooner you know what you actually expose, the sooner phase four has a scope worth testing.

But notice what every technique on that spectrum has in common. They all answer the question "is this exploitable." None of them answer the question "who says so, and will someone who was not in the room believe them."

See what your external surface exposes, mapped to the controls it touches.

Run a free External Security Check →

Two Audiences, Two Standards of Proof

That second question is the whole argument, and where most CTEM discussions go wrong.

A CTEM program answers to the CISO and the board. It optimises for reducing exposure between assessments, and its outputs are a trend line and a work queue. Are we closing exposures faster than we create them? Which three attack paths carry most of our reachable risk? Those are internal management questions, and a dashboard is exactly the right artefact for them. Nobody outside the organisation needs convincing.

The signed penetration test report answers to somebody else entirely: a third party who was not there. An auditor. A QSA. A prospective customer's procurement team working through a security questionnaire. An insurer pricing a cyber policy. A regulator.

That audience cannot accept a dashboard, and the reason is structural rather than cultural. A dashboard is mutable, so the number they saw last Tuesday is not necessarily the number that was there. It is self-hosted, so the organisation being assessed controls the data. It is unsigned, so no identified professional has attached their name and liability to the conclusion. And it carries no scope statement fixed to a moment in time, so nothing establishes what was tested on any given date.

Which means the requirement was never recency. Everyone reads it that way because the word "annual" appears in the standard, but that is the cadence, not the substance. The actual requirement is attestation by an identified independent party, about a defined scope, at a defined time. A test from eleven months ago meeting those three conditions clears the bar. A dashboard updated four minutes ago that meets none of them does not.

The questionnaire asks for a third-party pentest in the last twelve months. A dashboard does not answer that question.

This is not new. It is the same independence problem that surfaces when compliance automation platforms blur monitoring into assessment, and the same evidentiary problem behind the question of whether auditors trust AI-generated pentest reports.

🎯Key Takeaway

The requirement was never recency. It is attestation by an identified independent party, about a defined scope, at a defined time. A dashboard cannot supply that because a dashboard is mutable, self-hosted and unsigned.

None of this is our interpretation. One standard closes the argument in its own words.

PCI DSS 11.4 Settles the Argument

Requirement 11.4 of PCI DSS v4.0.1 is unusually direct for a compliance standard. Under 11.4.3, external penetration testing must be performed per the entity's defined methodology, at least once every twelve months, and after any significant infrastructure or application upgrade or change. 11.4.2 sets the same conditions for internal testing. Both require the test to be performed by a qualified internal resource or qualified external third party, and both state that organisational independence of the tester must exist, with the standard adding that the tester is not required to be a QSA or ASV. And under 11.4.4, exploitable vulnerabilities and security weaknesses found during testing must be corrected, with testing repeated to verify the correction. Full text via the PCI Security Standards Council document library, and what QSAs actually reject in our PCI DSS 4.0 pentest requirements guide.

Read the "and after any significant change" clause next to a CTEM program and the relationship inverts:

Continuous testing is what tells you a significant change happened. The signed test is what you owe when it does.

Follow that through and the conclusion is uncomfortable for the "CTEM means you can stop testing" pitch. A CTEM program does not reduce demand for signed reports. It generates it, because a program built to detect material change keeps surfacing the events that trip 11.4's second condition: the new payment integration, the CDE segment migrated to a different VPC, the authentication rewrite. Every one resets your obligation.

A team with no continuous visibility does not know when a change reset its twelve-month clock, so it tests on the anniversary and hopes nothing material happened. A team running CTEM knows. That is more testing, not less.

When 11.4.1 asks for an industry-accepted methodology, NIST SP 800-115 is the reference most testers name, and naming it in your report turns "we ran a test" into "we followed a documented methodology."

⚠️The clause most teams miss

PCI DSS 11.4 says at least every twelve months and after any significant infrastructure or application change. Most teams read the twelve months and skip the second half. The second half is the one a continuous program keeps triggering, because detecting material change is exactly what the program is built to do.

What the other frameworks require

Internal (11.4.2) and external (11.4.3) penetration testing at least once every twelve months and after any significant infrastructure or application upgrade or change, per a defined methodology (11.4.1). The tester must be a qualified internal resource or qualified external third party, and organisational independence of the tester must exist, though the standard does not require a QSA or ASV. Exploitable findings must be corrected and retested to verify correction (11.4.4). What QSAs actually reject is covered in our PCI DSS 4.0 pentest requirements guide.

SOC 2 (CC4.1) states that the entity selects, develops and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning. Note the "and/or": the criterion does not mandate a separate evaluation in every case, and it never names penetration testing. In practice auditors routinely accept an independent test as the evidence for the separate-evaluation half, and "separate" is doing real work there: separate from the people operating the control. See our SOC 2 penetration testing requirements guide.

ISO 27001:2022 handles this through Annex A 8.8 on management of technical vulnerabilities, which covers your live estate, and A 8.29 on security testing in development and acceptance, which covers testing before a change ships. A 8.8 is the one most pentest evidence is filed against. No fixed annual cadence is mandated, but certification auditors expect a defined testing frequency, evidence it was followed, and independence from the development team.

DORA is the most prescriptive, and it runs on two tiers that are routinely conflated. Article 24(6) is the one that applies to virtually all in-scope financial entities: test ICT systems and applications supporting critical or important functions at least yearly, with independence and no conflict of interest required of the tester under Article 24(4). Threat-led penetration testing under Article 26(1), at least every three years against the tougher tester requirements in Article 27, applies only to entities designated by their national competent authority. If you have had no designation notification, Article 24(6) is your obligation, not TLPT. Detail in our DORA penetration testing requirements guide.

Essential Eight is the outlier. The ACSC maturity model measures mitigation strategies rather than assessment activity, so it mandates no testing cadence. Australian organisations use independent testing to evidence that their maturity self-assessment is accurate, which we cover in our Essential Eight penetration testing guide.

Different cadences, one shared requirement: somebody independent, on the record, about a defined scope. Which raises the question of what all this costs when you are not an enterprise.

What a CTEM Program Actually Costs at Mid-Market

Every CTEM guide published so far assumes an enterprise stack: an exposure management platform, a BAS tool, an attack path product, a red team on retainer, and three full-time people to run the loop. Defensible at 20,000 employees. At 200 to 2,000 employees with a security team of two to six, it is a fantasy budget, and pretending otherwise is why most mid-market CTEM projects stall in discovery. Here is the honest per-phase picture at that size.

What does an enterprise CTEM stack assume you already have?

Before any of those products earn their licence fee, the reference architecture assumes five things are already in place. A maintained asset inventory that reflects reality rather than last year's diagram. Attack path mapping software, licensed separately from your scanner and your BAS tool. A current CMDB with owners attached to records, not just hostnames. A dedicated exposure management owner whose job this is, rather than a fifth priority on the security lead's plate. And a mobilisation workflow with agreed SLAs per severity that engineering has actually accepted.

None of those appear as line items in a CTEM pitch, and every one of them is a prerequisite rather than an output. If you are missing three or more, buying the platform first is how the project stalls in discovery.

Phase	What it actually requires	Mid-market approach	Budget
1. Scoping	A business-risk boundary the business has agreed to	Half-day workshop each quarter, documented	Time only
2. Discovery	Assets and exposures inside that boundary	Cloud asset inventory, your existing scanner, certificate transparency logs, free external reconnaissance	Time only to start
3. Prioritisation	A consistent, defensible ranking rule	Written rule: reachability, then exploit availability, then business context, then CVSS	Time only
4. Validation	Independence, which cannot be self-supplied	Scheduled independent testing against the declared scope, ending in a signed report	$7,999 to $14,999 per engagement
5. Mobilisation	Named owners, tickets, agreed SLAs	Your existing ticketing system, plus SLA per severity that engineering has accepted	Time only

Four of the five phases are staffing and discipline, not procurement. That is the number worth taking into the budget conversation, because the pitch you have been shown almost certainly priced all five.

Scoping is a workshop, a spreadsheet, and a decision about what your crown jewels actually are. Half a day quarterly outperforms any tool.

Discovery starts with what you already own, and that combination surfaces most of what an internet-facing mid-market estate exposes. It gets expensive only when you buy a dedicated discovery platform, which most teams should defer until scoping proves the need.

Prioritisation is discipline, not software. A documented decision rule beats an unconfigured risk-scoring engine every time.

Mobilisation is your ticketing system plus the political work of getting engineering leadership to accept the queue. No purchase required.

Validation is the phase that requires outside capability, because independence cannot be self-supplied. This is where the CTEM penetration testing budget goes, and where the cost picture has changed most.

Traditional engagements run $15,000 to $30,000, take six to eight weeks from kickoff to report, and quote a change order for the retest. That pricing forces most mid-market teams into a single annual test, which is precisely the snapshot problem CTEM was designed to solve. CyberOrbit's engagements run $7,999 to $14,999 with retesting included, which turns the budget that previously bought one annual test into two or three tests a year. Market breakdown in our 2026 penetration testing cost guide, current tiers on the pricing page.

$7,999

Independent signed pentest, retest included

Against a traditional mid-market range of $15,000 to $30,000 with the retest quoted as a change order, which is the arithmetic that decides whether your validation phase runs once a year or several times.

Which leaves one question: how do you stand up the validation phase without buying the enterprise stack?

Building the Validation Layer Without an Enterprise Budget

Do it in this order. The sequence matters more than the tooling does.

Week one, establish your external footprint. Run these against domains you own or are formally authorised to assess, and nothing else. Start with our free security check against your primary domain for a baseline, then enumerate what you expose with the subdomain finder. Most teams find a forgotten staging host. Check TLS and certificates with the SSL checker, response headers with the header checker, and email authentication with the DNS analyzer.

Week two, build the prioritisation rule. Take the discovery output, check what is known-exploitable with the CVE lookup, and score the rest consistently with the OWASP risk calculator. Write the rule down. A prioritisation method that lives in one person's head is not a program.

Week three, set the validation cadence. Decide two things: what runs continuously against your own environment, and what triggers an independent test. Tie the second to the change events your own standard already names, not just to the calendar. For a practical framework on how to set your testing cadence based on change velocity and compliance obligations, see Penetration Testing Frequency: Continuous vs Annual.

That third decision is where we fit. CyberOrbit is the validation layer of a CTEM program: scheduled testing against your declared scope, and the signed third-party report your auditor accepts. We do the testing and the evidence, not the discovery and prioritisation. We don't monitor your attack surface. We test it. Phases one, two, three and five stay yours.

⬜Declared scope documented and signed off by the business, not just by security

⬜External attack surface enumerated for that scope, including the hosts your inventory forgot

⬜Prioritisation criteria written down before findings arrive, not negotiated after

⬜Testing cadence tied to change triggers, not just the calendar

⬜Independent tester identified and named in the report

⬜Retest path agreed before the first engagement, with the cost known

⬜Report format checked against your auditor's expectations

⬜Evidence retained for at least twelve months and retrievable on request

Your First 90 Days: A CTEM Rollout That Survives Contact

Days 0 to 30

Scope declared and agreed with the business, external surface enumerated against it, asset owners assigned.

Days 30 to 60

Prioritisation criteria agreed and written down, validation cadence stood up, change triggers defined.

Days 60 to 90

First independent signed test against the declared scope, findings mobilised with named owners and SLAs.

Day 90 and beyond

The cycle repeats on the twelve-month clock, or sooner on any significant change your program detects.

Days 0 to 30, scope and discover. Write the risk boundary before you run a single tool, and get the business to agree to it. Then discover against that boundary using what you already own. Expect the asset count to come back higher than your inventory says, and resist the urge to fix anything yet. Month one delivers a defensible scope statement and an honest exposure list, nothing more.

Days 30 to 60, prioritise and stand up cadence. Apply your documented rule to the exposure list and produce a ranked queue with named owners. Then start the validation cadence: continuous checks against your own environment, with a written trigger for when an independent test is required. Run your first mobilisation cycle on the top five items and measure how long closing one actually takes. That number, not your exposure count, is the metric your board will care about by quarter three.

Days 60 to 90, get the artefact. Commission the first independent test against the scope you declared in month one. Two things fall out of it: a signed report you can hand to an auditor or a procurement team, and a calibration check on your prioritisation. If the test surfaces something your program ranked low, your rule needs adjusting, and finding that out in month three is far cheaper than finding it out during fieldwork. If an audit window is close, an audit readiness scan will show the evidence gaps before the assessor does.

At 90 days you do not have a finished program. You have a loop that turns, an artefact third parties accept, and a measured remediation velocity to improve next quarter. That is the version still running in a year.

🎯Key Takeaway

CTEM tells you what changed and what is reachable. The signed test tells a third party who was not there that an identified independent professional tested a defined scope at a defined time. Running the first is what tells you when you owe the second.

You own the discovery and the prioritisation. The validation phase needs an independent test against your declared scope, and an artefact a third party will accept. That is what we deliver in 48 hours, signed by a certified security professional.

Request a Scoped Pentest

Frequently Asked Questions

What is CTEM (Continuous Threat Exposure Management)?

CTEM is a five-phase operational program introduced by Gartner in 2022 for continuously identifying, prioritising and reducing security exposure. It is a program an organisation runs, not a software category. The phases cycle rather than running once a year, and no single product covers all five, so most organisations assemble it from tools they already own plus outside capability where independence is required.

What are the five stages of CTEM?

Scoping (defining the business-risk boundary you defend), Discovery (finding assets, identities and exposures inside it), Prioritisation (ranking by exploitability and business impact rather than raw severity), Validation (confirming which exposures an attacker could reach and use, and whether controls would stop them), and Mobilisation (getting fixes assigned, ticketed and closed). The cycle repeats.

Where does penetration testing fit in a CTEM program?

Penetration testing sits in phase four, validation. Gartner expects that phase to combine breach and attack simulation, attack path mapping, red teaming and penetration testing. Automated testing is one input rather than the whole phase, and independent testing supplies the evidentiary artefact the other techniques cannot produce.

Does CTEM replace annual penetration testing?

No. The two answer to different audiences. CTEM answers to the CISO and the board, optimising for exposure reduction between assessments, and its output is a trend and a queue. A signed report answers to a third party who was not present: an auditor, a QSA, a procurement team. PCI DSS 11.4 requires testing at least every twelve months and after any significant change, by a qualified tester with organisational independence, who may be internal or external. A CTEM program surfaces those triggers, generating signed-report demand rather than removing it.

What happens in the CTEM validation stage?

Validation tests whether prioritised exposures are reachable and exploitable, and whether existing controls would stop the attack. In practice that means safely attempting exploitation, mapping attack paths between findings, and firing known attacker techniques at detection and prevention controls. It converts theoretical vulnerabilities into demonstrated attack paths, which is what makes the remediation queue defensible.

Can a mid-market company run a CTEM program without an enterprise budget?

Yes, with realistic scoping. At 200 to 2,000 employees, phases one, two, three and five can start with tooling you already own plus documented discipline: your cloud asset inventory, your scanner, free reconnaissance tools, your ticketing system, and a written prioritisation rule. Phase four requires outside capability, because independence cannot be self-supplied. Budget there and build the rest in-house.

Does a CTEM dashboard satisfy a SOC 2 or PCI DSS pentest requirement?

No. A dashboard is mutable, self-hosted, unsigned and carries no scope statement fixed to a point in time, so it cannot function as third-party attestation. SOC 2 CC4.1 contemplates separate evaluations, and a separate evaluation gets its value from being performed by someone other than the people operating the control. PCI DSS 11.4 requires organisational independence of the tester and a defined methodology. Continuous data supports your program. It does not satisfy the independence requirement in either standard.

Sources

Gartner: What Is Continuous Threat Exposure Management?
Gartner: Magic Quadrant for Exposure Assessment Platforms (first edition, November 2025)
Picus Security: Where Does Automated Pentesting Fit in CTEM? (vendor estimate, not an independent study)
PCI Security Standards Council Document Library (PCI DSS v4.0.1 and the Penetration Testing Guidance information supplement)
NIST SP 800-115: Technical Guide to Information Security Testing and Assessment

Gartner is a registered trademark of Gartner, Inc. PCI DSS is a registered trademark of the PCI Security Standards Council, LLC. SOC 2 is a registered trademark of the American Institute of Certified Public Accountants. These marks are used here only to identify and comment on the frameworks referred to. CyberOrbit AI Pty Ltd is not affiliated with, endorsed by, or sponsored by any of them.

This post is general information about security testing and compliance frameworks. It is not legal, audit, or compliance advice, and it is not a substitute for the current text of the standards discussed or the judgement of your own assessor. Requirement references describe PCI DSS v4.0.1 as published at the date above.

#ctem #continuous threat exposure management #penetration testing #exposure management #security strategy #gartner #pci dss #validation