Continuous Threat Exposure Management · for a bank
CTEM is not a technology. It is a way of working.
CTEM is a repeating, five-stage cycle that decides which exposures matter to the business, proves they are real, and gets them fixed by the people who own them. Tools help with parts of it. None of them do it for you.
Gartner framework, 2022 · scoped cycles, not one big bang
What it is
Most banks already find vulnerabilities very well. They run several scanners, receive tens of thousands of findings, and still cannot answer a simple question from the board: are we less exposed than last quarter, where it matters?
CTEM answers that question by changing the unit of work. Instead of "every finding from every scanner", each cycle starts from a business service, looks at every way an attacker could reach it, ranks what is actually exploitable, tests it, and drives the fix through to closure. Then it starts again, with the lessons fed into the next scope.
The five stages
Diagnose: what could hurt us, and how much
Act: prove it, then fix it
1
Scoping
What are we protecting, against whom, and what is unacceptable?
People and process
Tie scope to important business services and impact tolerances
Name a business owner for each scope
Agree the threat scenarios
Where tools help
Asset inventory, service mapping, threat intelligence
2
Discovery
What exposures exist across every attack surface in scope?
People and process
Decide what counts as an exposure: CVEs, misconfiguration, identity, suppliers
Close coverage gaps against the inventory
Where tools help
Most of the work. This is where existing scanners live.
3
Prioritisation
Which exposures matter most to this bank, right now?
Is it really exploitable here, and do our controls stop or detect it?
People and process
Threat-led test plans
Purple teaming with the SOC
CBEST and TBEST, with remediation plans
Where tools help
Attack simulation, automated penetration testing
5
Mobilisation
Who fixes it, by when, and how do we know it is done?
People and process
Owners and SLAs outside security
Work within change control and freeze windows
Formal exceptions and risk acceptance
Report exposure against appetite
Where tools help
Ticketing and workflow, dashboards
What mobilisation learns becomes the scope of the next cycle. Without that loop, it is just vulnerability management with a new name.
Why it is not a technology
Scanners cover one stage in five
Discovery is the stage banks are already good at. Adding another discovery tool makes the pile of findings bigger, not smaller.
Platforms stop at the ranking
An "exposure management platform" can aggregate and score. It cannot decide what your business cares about, approve a risk, or deploy a patch.
Prioritisation needs business context
The ranking is only as good as the criticality behind it, and that comes from service owners and operational resilience, not a feed.
Security finds, other people fix
Remediation runs through IT operations, engineering and change management. None of them report to security, so CTEM is an operating model before it is anything else.
Who does the work
CTEM depends on as many teams outside security as inside it. The two most important inputs, the asset inventory and the business impact analysis, both come from outside.
Inside security
CISO and an exposure lead who owns the programme
Exposure analysts
Threat intelligence
Offensive security and the SOC
Cloud, application, identity and network security
Outside security
Business service owners, who accept or reject risk
Scope from resilienceStart from the important business services and impact tolerances already mapped under the PRA and FCA operational resilience rules. Do not build a second crown-jewel model that disagrees with it.
Reuse what regulators asked forCBEST and TBEST threat intelligence, SWIFT CSP and PCI DSS boundaries, and the DORA register and TLPT for EU entities are all scoping and validation inputs you already have.
Let risk own the modelSecond-line risk should approve the scoring model and the thresholds, so exposure is reported in the same terms as every other risk.
Count compensating controlsWhen a fix is not possible, segmentation or another control that breaks the attack path is a valid outcome, recorded with an expiry date.
Measure exposure, not effortReport exploitable exposure on important business services, time to fix it, and attack paths to crown jewels remaining. Finding counts measure scanner enthusiasm.
How it usually goes wrong
Buying the platform firstThe tool arrives before anyone has agreed a scope, an owner or a scoring model, and becomes another dashboard.
Scoping everythingThen prioritisation becomes a severity sort with extra steps.
No business ownerExposure has nobody accountable outside security, and remediation stalls.
Skipping validationTeams patch what is theoretically severe while the real path runs through a service account nobody scanned.
No loopEach cycle starts from scratch, so nothing learned changes the next scope.
Where to start
Before buying anything: name an accountable owner for the programme, get second-line risk to agree a scoring model, and pick one business service to map end to end.
External attack surface
Fast to stand up, shows quick wins, and always turns up assets the CMDB has never heard of.
One business service
Payments is a good first choice: well mapped, regulated, visible to executives. It proves the cross-team model works.
Identity tier 0
It cuts across every service, so fixing it reduces exposure everywhere at once.