Lesson 1.1: What is CTEM, and why does it matter for security teams? - GBHackers

Compliance Framework Mapping

Introduction

Welcome to Lesson 1.1: What is CTEM, and why does it matter for security teams? - GBHackers! Over the next 45 minutes, we will explore the Continuous Threat Exposure Management framework and its role in modern security operations.

But first, let me tell you about Marcus Webb.

It's 3:17 PM on a Tuesday in October. Marcus Webb, a senior security analyst at a financial services firm in London, is reviewing a quarterly vulnerability scan report. The air in the office is stale, the hum of servers a constant background noise. He sips cold coffee, his eyes scanning rows of flagged issues, most marked as 'medium' or 'low' priority.

He notices the report is nearly identical to the last one. The same old Java library on an internal admin server, the same outdated WordPress plugin on the marketing site. He's seen them for months. The business has pushed back on patching the admin server because of a 'critical business process' that runs on it every weekend. The marketing team says updating the site might break a form. Marcus logs the findings, adds them to the risk register, and moves on. The report is filed, the box is ticked.

Three days later, a notification blares on his screen. The marketing website is defaced. An hour after that, the internal admin server is beaconing out to a suspicious IP in a country they don't operate in. The outdated plugin was the entry point. The old Java library provided the lateral movement. The decision to accept the risk, based on a static, point-in-time report, has just cost the organisation.

This is the story of Cyberattack. By the end of this lesson, you'll understand exactly why Marcus never stood a chance, and more importantly, what could have saved him.

Content Section 1: What is CTEM?

Think of your organisation's digital presence not as a castle with walls, but as a sprawling, ever-changing city. Traditional security is like sending out a survey team once a quarter to note down which doors are unlocked. CTEM is like having a live satellite feed, traffic cameras, and ground sensors all working together, 24/7, telling you not just which doors are unlocked, but which ones criminals are actually trying to open, right now.

The Five Stages

Continuous Threat Exposure Management is a framework, not a single tool. It's a cycle of five connected stages: Scoping, Discovery, Prioritisation, Validation, and Mobilisation. The goal isn't to find every single flaw; it's to continuously understand which flaws an attacker is most likely to use against you, and to fix those first.

Scoping defines what you care about. Is it your customer-facing web apps? Your cloud storage buckets? Your developer environments? Discovery then constantly looks for assets and vulnerabilities within that scope. This is where Marcus's quarterly scan lived, but in CTEM, discovery is continuous and uses multiple methods.

This is where it changes. Prioritisation doesn't just look at a CVSS score from a database. It asks: Is this vulnerability being actively exploited in the wild? Is it on an internet-facing server that holds customer data? Does a proof-of-concept exploit exist? Validation tests whether the vulnerability can actually be exploited in your specific environment. Mobilisation is the act of getting the right fix to the right team with the right context.

Why the Old Model Breaks

The traditional model Marcus used is reactive and periodic. A scan runs, it produces a report, security teams spend weeks triaging it, they argue with IT or development teams about patching schedules, and by the time a decision is made, the environment has already changed. New assets have been spun up in the cloud. New vulnerabilities have been published.

This model creates a dangerous gap between what you think your exposure is and what it actually is. It treats all vulnerabilities within a severity band as equal, ignoring the real-world threat context. It gives a false sense of security because a report was generated, even if no meaningful risk was reduced.

DORA Article 5-17 DORA's ICT risk management framework requires financial entities to have continuous processes for identifying, classifying, and documenting ICT vulnerabilities. A point-in-time scan does not meet the 'continuous' requirement.

ISO A.5.1 ISO 27001 A.5.1 requires management to ensure information security objectives are established and that roles and responsibilities are assigned. A static vulnerability management programme lacks the objectives and operational rhythm of a continuous process like CTEM.

Content Section 2: The Technical Shift: From Inventory to Intelligence

Understanding CTEM reveals why it's more than just faster scanning. Let me show you exactly how Marcus's old process was bypassed, and what a CTEM approach would have seen.

The Attack Flow Marcus Missed

The attack didn't start when the website was defaced. It started weeks earlier. A vulnerability in the WordPress plugin was added to a popular exploit kit. This fact was in threat intelligence feeds. A CTEM system, ingesting those feeds, would have automatically elevated that plugin's vulnerability from 'medium' to 'critical' in Marcus's environment the moment it became weaponised.

The attackers scanned the internet for sites using the old plugin. They found Marcus's company marketing site. They used the exploit to gain a foothold. Here, a CTEM process with external attack surface management would have shown that the marketing site was not only vulnerable but was also actively being probed by suspicious IPs—an early indicator of compromise.

From the marketing server, the attackers moved laterally. They found the internal admin server with the old Java library. This library had a known vulnerability that allowed remote code execution. A CTEM system performing validation might have safely simulated this attack path, proving that the two 'medium' issues on separate systems could be chained together for a critical breach.

Key Components of a CTEM System

A CTEM architecture pulls from several sources: Asset Discovery tools build a continuous inventory. Vulnerability Scanners (both traditional and agent-based) find flaws. Threat Intelligence Feeds provide context on what's being actively exploited. Attack Surface Management tools see your systems from an attacker's perspective. Breach and Attack Simulation or Penetration Testing tools handle the validation.

The magic isn't in any one tool; it's in the orchestration platform that correlates this data. It matches vulnerabilities to assets, enriches them with threat intel, maps potential attack paths, and outputs a continuously updated shortlist of what to fix first, with evidence on why it matters.

Why Traditional Defences Fail Against Modern Attacks

Notice what all of these methods have in common. They are reactive, slow, and operate on stale data. CTEM integrates and automates to create a proactive, continuous, and intelligence-driven feedback loop.

Traditional, siloed defences are slow and lack context. Here’s how a CTEM process addresses their gaps:

NIST ID.RA-1 NIST CSF ID.RA-1 requires asset vulnerabilities to be identified and documented. CTEM operationalises this by making identification continuous and documentation dynamic, linked to threat context, not just a static list.

NIS2 Article 21 NIS2 Article 21 mandates risk management measures that are state-of-the-art. Industry data indicates that a continuous, threat-informed approach like CTEM is becoming the expected standard for managing cyber threat exposure.

Content Section 3: Operationalising CTEM: Signals and Response

Marcus's computer knew something was wrong when the server started beaconing. It just couldn't tell him in a way that connected back to the risk he had already accepted. A mature CTEM programme creates the signals that bridge that gap.

Programme-Level Indicators

Track mean time to inventory (MTTI): how long does it take for a new cloud instance to appear in your asset register? Track mean time to prioritisation (MTTP): from when a vulnerability is discovered, how long to assess its threat context and business impact? Finally, track mean time to remediation (MTTR): how long to actually fix the prioritised items?

These metrics move the conversation from 'we scanned 1000 assets' to 'we reduced our most dangerous exposure window from 45 days to 72 hours.' They show the health of the process, not just the output of a tool.

A key signal is the trend of your 'prioritised backlog.' In a working CTEM system, the list of validated, critical exposures should be small and constantly changing as items are fixed and new ones are identified. A large, static backlog indicates a breakdown in the mobilisation stage.

Technical Integration Points

The CTEM orchestration platform must feed into ticketing systems like Jira or ServiceNow. The ticket shouldn't just say 'Patch server X for CVE-YYYY-XXXXX.' It should say: 'Patch server X (Customer Payment API) for CVE-YYYY-XXXXX. This vulnerability is being actively exploited in ransomware campaigns (Threat Intel Source: Z). Our external monitoring detected scan attempts against this server last week (ASM Source: Y). Validation confirmed we are vulnerable.'

This context turns a technical task into a risk mitigation task, making it easier for operational teams to understand the urgency and for managers to allocate resources.

Governance and Communication Signals

Regular briefings should shift from presenting massive vulnerability counts to discussing the top 5-10 attack paths currently open. The discussion is about business risk: 'This path could lead to a breach of customer data,' or 'This could disrupt our online sales platform.'

Another critical signal is exception management. When a risk cannot be immediately remediated, the CTEM process forces a formal, time-bound exception with clear compensating controls and review dates. This replaces the informal, forgotten 'acceptance' that happened in Marcus's case.

SOC2 CC7.1 SOC 2 CC7.1 requires monitoring procedures to identify changes that could impact security. CTEM provides a structured, evidence-based monitoring process for changes in threat exposure, far beyond simple configuration change tracking.

GDPR Article 32 GDPR Article 32 requires appropriate technical measures to ensure security of processing. A continuous process to identify, prioritise, and remediate the most threatening vulnerabilities, especially on systems processing personal data, is a demonstrable technical measure.

Content Section 4: Building Your Compliance Narrative

Compliance reports are often seen as paperwork. But with CTEM, your operational data becomes your evidence. It's the difference between showing an auditor a stack of quarterly scan reports and showing them a live dashboard demonstrating a managed, risk-based process.

Evidence Generation

This lesson provides documentation for multiple compliance frameworks:

For DORA Article 5-17 auditors... For DORA auditors, you can now demonstrate an understanding of the requirement for continuous ICT vulnerability management processes. Your activity and follow-up plan show a gap analysis towards implementing a CTEM framework.

For ISO A.5.1 auditors... For ISO 27001 assessors, you can evidence management awareness of the need for a strategic, process-driven approach to vulnerability management (CTEM) rather than a tactical, tool-driven one.

For NIST ID.RA-1 auditors... For NIST CSF reviewers, you can show a documented understanding of how continuous asset discovery and threat-informed vulnerability prioritisation (core to CTEM) fulfil the ID.RA-1 requirement more effectively than periodic scans.

Audit Trail

Document your completion of this lesson:

• Lesson title and date completed
• Time invested: approximately 45 minutes
• Key learnings in your own words
• Activity submission reference
• Follow-up actions identified (e.g., 'Schedule meeting with vulnerability management team to discuss CTEM concepts')

Conclusion

Let me tell you how Marcus's story ended.

The incident took a week to fully contain. The marketing site was restored from backups. The compromised internal server was rebuilt from scratch. The total cost, including incident response, forensics, lost productivity, and a small regulatory fine for the data exposure, was estimated at over £120,000. Marcus wasn't fired, but his role was changed. He was moved away from operational security management.

Six months later, the organisation began piloting a CTEM platform. They started by integrating their cloud asset inventory with a threat intelligence feed. The first report it generated didn't have thousands of items. It had 12. The old Java library was number three on the list, with a note: 'Associated with 3 recent ransomware incidents in our sector.' It was patched that weekend.

But it doesn't have to be your story. That's why we're here.

You should now understand that CTEM is a continuous cycle, not a point-in-time tool. You understand that its power comes from correlating asset, vulnerability, and threat data to find attack paths, not just flaws. You know that it shifts metrics from volume of findings to speed of risk reduction. And you understand that it turns operational security data into compelling compliance evidence.

Next, we'll explore Next, we'll explore Lesson 1.2: 'Establishing Your CTEM Scope and Governance.' We'll look at how to define what's in scope for your programme, how to get stakeholder buy-in, and how to build the policies that make the cycle turn.

See you there.

Resources

The course materials folder contains downloadable resources for this lesson:

• Lesson 1.1 Quick Reference Card - Summarise the five stages of the CTEM cycle (Scoping, Discovery, Prioritisation, Validation, Mobilisation) and key questions to ask at each stage for your organisation's What is CTEM, and why does it matter for security teams? - GBHackers programme.
• Compliance Mapping Worksheet - Map the controls and evidence generated by a CTEM process to specific articles in DORA, ISO 27001 A.5.1, NIST CSF ID.RA, NIS2 Article 21, SOC 2 CC7.1, and GDPR Article 32.
• Risk Assessment Template - Assess your organisation's exposure to the specific gaps highlighted in this lesson: siloed tools, static prioritisation, and slow mobilisation, using the CTEM model as a benchmark.
• Further reading - Links to Gartner's research notes defining the CTEM framework and official documentation for the NIST CSF and ISO 27001 standards referenced in the lesson.

What is CTEM, and why does it matter for security teams? - GBHackers Defence Masterclass | Threat Intelligence | Lesson 1.1
© LimitedView Limited | 2026