Intelligence and Threat-led Penetration Testing for the Modern Enterprise

An organization can maintain a mature vulnerability management program, conduct regular penetration testing, and remediate findings within defined timelines, and yet remain vulnerable to a determined attacker. The issue may not be failure to identify vulnerabilities, but failure to understand how seemingly isolated weaknesses could be combined to compromise a critical business service.

Modern enterprise environments are increasingly interconnected, spanning external infrastructure, identities, cloud resources, application programming interfaces (APIs), third-party relationships, and the processes that connect them. Identifying these exposures does not establish whether they can be exploited in combination. Security teams must examine the routes an attacker could take through the environment and assess whether existing controls would prevent or detect that activity.

This raises a practical question: Once an organization has identified its attack surface and potential attack paths, how should those paths be tested?

This is where intelligence-led penetration testing (ILPT) and threat-led penetration testing (TLPT) become relevant. While both use threat intelligence to inform security testing, they can differ in scope, objectives, and the frameworks used to structure the engagement. This article examines how ILPT and TLPT fit within a broader security-testing program, what distinguishes threat-informed testing from conventional vulnerability assessment and penetration testing (VAPT), how frameworks such as CBEST and Threat Intelligence-based Ethical Red Teaming for the European Union (TIBER-EU), as well as regulatory requirements such as the Digital Operational Resilience Act (DORA), shape threat-led testing, and what these approaches mean for Indian organizations operating under the Reserve Bank of India (RBI), Indian Computer Emergency Response Team (CERT-In), and other sector-specific requirements.

Different Security Questions Require Different Assessments

No single assessment provides a complete picture of security risk. Vulnerability assessments establish broad coverage, while penetration testing validates whether identified weaknesses can be exploited within a defined scope. Attack-path testing examines whether weaknesses can be combined to reach a defined target, and red teaming evaluates an organization’s ability to prevent, detect, and respond to an adversary pursuing a defined objective. Adversary emulation replicates the tactics, techniques, and procedures (TTPs) of a relevant threat actor or group whereas intelligence-led testing adds a further layer by using information about relevant threats to shape the scenario itself.

For example, in a hospital, an attacker could compromise a remote-access account used by a third-party support provider, exploit excessive privileges to access the hospital’s clinical application environment, move laterally to systems supporting electronic health records and clinical operations, and attempt to disrupt access to patient-care systems. Testing this attack path can determine whether third-party access controls, identity and privilege management, network segmentation, and security monitoring can prevent or detect progression toward critical clinical services.

The appropriate approach therefore depends on the assurance required: whether the organization needs visibility into weaknesses, evidence of exploitability, validation of a potential attack route, or an assessment of how a relevant adversary could operate against its environment.

The relationship can be summarized as follows:

Security question	Assessment approach
What weaknesses exist in the environment?	Vulnerability Assessment
Can identified weaknesses be exploited?	Penetration Testing
Can weaknesses be chained into a viable route to a target?	Attack-path Testing
Can an attacker achieve a defined business objective?	Red Teaming
Can we emulate the behaviors of a relevant adversary?	Adversary Emulation
Which threats and adversary behaviors should determine the testing scenario?	Intelligence-led Testing

These approaches are not mutually exclusive. An organization may use VAPT for broad coverage, targeted penetration testing to validate exploitable weaknesses, and threat-informed testing to assess how those weaknesses could be used within a defined attack scenario. The appropriate combination depends on the organization’s risk profile, business objectives, and assurance requirements.

Intelligence-led Penetration Testing (ILPT) vs. Threat-led Penetration Testing (TLPT)

ILPT uses threat intelligence as the foundation for planning the assessment. The intelligence can cover relevant threat actors, their motivations, targeting patterns, capabilities, infrastructure, attack methods, and known TTPs. This information helps determine which threats are relevant to the organization and how the assessment should be designed and executed.

TLPT focuses the assessment around a defined threat scenario and the TTPs associated with a relevant threat actor. The exercise models how that type of adversary could target the organization, pursue a specific objective, and move through its environment. The red team uses the scenario to guide activities such as reconnaissance, exploitation, privilege escalation, and lateral movement rather than testing techniques in isolation.

The distinction is therefore primarily in what drives the assessment and how the testing is structured. ILPT describes an intelligence-driven methodology for determining relevant threats and informing the assessment, while TLPT defines a threat-focused testing model. In regulatory contexts such as DORA, TLPT also carries specific requirements governing how the exercise must be scoped, conducted, and documented.

There is significant overlap between the two approaches, and they should not be presented as sequential stages or mutually exclusive services. An engagement can be intelligence-led without being a DORA-regulated TLPT, while a TLPT incorporates threat intelligence as a core component of the testing process.

What Makes Penetration Testing Intelligence-led?

Intelligence-led penetration testing uses threat intelligence to inform the selection of threats, targets, and attack scenarios. Threat intelligence helps shape the adversaries, behaviors, and scenarios selected for testing based on the organization’s environment, business priorities, and risk profile.

Key elements of an intelligence-led engagement include:

• Adversarial profiling: Identifies relevant threat actors, their motivations, capabilities, targeting patterns, and commonly used tactics, techniques, and procedures (TTPs).
• Targeting and reconnaissance: Examines the organization’s external footprint, exposed assets, identities, and publicly available information relevant to the assessment.
• Threat-driven scenarios: Develops scenarios around critical systems and business functions, based on relevant threat intelligence.
• Control and detection testing: Assesses preventive controls, security monitoring, and incident response during the simulated attack.
• Framework alignment: Can draw on approaches such as CBEST and TIBER-EU, while MITRE ATT&CK provides a common reference for describing adversary behavior.

The Frameworks Behind Threat-led Testing

Threat-led testing does not depend on a single framework. Different frameworks address different aspects of the process and should not be treated as interchangeable. CBEST and TIBER-EU provide structured approaches for connecting threat intelligence with targeted security testing, while DORA establishes regulatory requirements for TLPT in the EU financial sector, with the associated technical standards defining how those requirements are implemented. While these approaches share common principles, they differ in scope and implementation.

• CBEST
  The Bank of England formally launched the CBEST framework on 10th June 2014. CBEST is an intelligence-led security testing framework used within the supervisory approaches of the Bank of England, Prudential Regulation Authority (PRA), and Financial Conduct Authority (FCA). It focuses on testing the cyber resilience of firms and Financial Market Infrastructures (FMIs) by using current and credible threat intelligence to inform penetration testing against the technology assets, people, and processes supporting their important business services.
  
  At a broad level, CBEST consists of four phases:

1. Initiation: Launch the assessment, establish the scope, form the Control Group, and procure the accredited threat intelligence and penetration testing service providers.
2. Threat Intelligence: Develop intelligence focused on the important business services in scope, including targeting information, relevant threat actors, and probable threat scenarios. These scenarios are then developed into a draft Penetration Test Plan.
3. Penetration Testing: Plan, execute, and review an intelligence-led penetration test against the target systems and services underpinning each in-scope important business service. The phase also assesses the firm’s Threat Intelligence maturity and Detection & Response capabilities.
4. Closure: Finalize the firm’s or FMI’s Remediation Plan, debrief the threat intelligence and penetration testing providers, and allow the regulator to supervise execution of the Remediation Plan.

• Digital Operational Resilience Act (DORA)
  DORA (Regulation (EU) 2022/2554) is an EU regulation that establishes TLPT requirements for designated financial entities. TLPT is not a blanket obligation for every financial entity: it applies only to those identified by their competent authority, based on factors such as size, risk profile, and ICT maturity. Article 26 of this Act requires identified entities to conduct advanced testing, at least every three years, of several or all critical or important functions and the live production systems supporting them. The detailed requirements for conducting TLPT are specified in the DORA TLPT Regulatory Technical Standards (RTS), Commission Delegated Regulation (EU) 2025/1190, which was adopted on 13th February, 2025, and has been applicable since 8th July, 2025. Testing must be carried out by external testers by default; internal testers are permitted only under strict conditions and with the approval of the authority.
  
  CBEST, described earlier, sets out four stages rather than three. The difference is one of presentation: CBEST lists threat intelligence and penetration testing as separate stages, while the RTS groups both under a single testing phase. At a broad level, the DORA TLPT RTS can be summarized in three phases:
• Preparation: Establish the TLPT, define its scope, form the control team, select the threat intelligence provider and testers, and establish the necessary arrangements. The TLPT authority is involved in every phase and validates or approves the key deliverables.
• Testing: Conduct the threat intelligence phase and red team test, using targeted threat intelligence to develop scenarios and executing the approved scenarios against the live production systems in scope. The active red-team testing phase must last at least 12 weeks under Article 11(5) of the RTS.
• Closure: Complete the red team test reporting, review the results, conduct the required purple-teaming and lessons-learned activities, agree upon a prioritized remediation plan, and conclude the testing engagement with an attestation issued by the authority, which allows the test to be mutually recognized across EU jurisdictions.
  
  The scope is not limited to the entity’s own estate. Where a critical or important function depends on an ICT third-party service provider, that provider’s systems can be drawn into the test, and pooled or joint tests involving several entities are permitted.

• Threat Intelligence-based Ethical Red Teaming (TIBER-EU)
  TIBER-EU is a European framework for threat intelligence-based ethical red teaming, published by the European Central Bank (ECB) in 2018. It provides a structured approach for testing an entity’s critical functions and underlying people, processes, and technologies through controlled, intelligence-led cyberattacks. The framework was updated in February 2025 to align its process and deliverables with the DORA TLPT regulatory technical standards, and the same update made purple teaming mandatory. The two are closely linked but they are not the same thing. TIBER-EU came first, and the RTS were developed on the basis of it. DORA and the RTS are legally binding, whereas TIBER-EU is an ECB framework rather than law. In practice, a TIBER-EU test conducted under the updated framework can be used to meet the DORA TLPT obligation.
  
  At a broad level, TIBER-EU can be summarized in three phases:

• Preparation: Establish the engagement, define and approve the scope, establish the testing teams, and procure the threat intelligence and red-team providers.
• Testing: Develop the Targeted Threat Intelligence Report and use it to develop and execute intelligence-led red-team scenarios against specified critical live production systems, people, and processes.
• Closure: Review the results, share findings, complete remediation planning, conduct the required purple-teaming and lessons-learned activities, and formally close the test.
  
  Neither DORA nor TIBER-EU creates an obligation for Indian organizations. They remain useful, however, as the clearest published model of how threat-led testing is structured in practice, and Indian financial institutions, technology companies, and service providers supporting EU clients may encounter these requirements through contracts, client assurance programs, or group-level obligations.

The Indian Regulatory Landscape

India does not currently have a unified regulatory framework for TLPT comparable to the DORA/TIBER-EU model. Instead, cybersecurity testing requirements are defined through sector-specific regulations and guidelines, with the applicable scope depending on the organization, its regulatory obligations, and the systems or services involved.

For example, RBI’s Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices (RBI/2023-24/107, 7^th November, 2023) prescribes vulnerability assessment and penetration testing requirements for applicable regulated entities. Section 26 covers VAPT for critical information systems and systems in the DMZ with customer interfaces, including periodic testing and testing throughout the system lifecycle.

CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines, issued on 25^th July, 2025, provide a structured framework for cybersecurity audits, including assessment areas such as VAPT, external attack penetration testing, web and API security, mobile application security, configuration, and compliance.

For Indian organizations operating across borders, global TLPT developments also provide a useful reference point. Financial institutions, technology companies, managed service providers, and multinational organizations may operate in jurisdictions or business relationships where threat-led testing forms part of the security or regulatory expectations. This makes the underlying approach relevant beyond organizations with a direct TLPT obligation.

Building Toward Threat-informed Testing

Organizations do not need to replace VAPT to adopt threat-informed testing. However, when existing assessments do not provide sufficient context on how relevant threats could affect critical business services, organizations should consider whether their testing approach provides the assurance they require referring to the below approach.

What Should a CISO Expect from an Intelligence-led Engagement?

An intelligence-led engagement should give the CISO more than a list of vulnerabilities and technical findings. It should provide clear evidence of how the selected threat scenario could affect the organization, which controls were effective, where defenses failed, and what actions would materially reduce the risk.

Assessment Area	What the CISO Should See
Threat relevance	Which threat or adversary was selected, what intelligence supported the selection, and why is it relevant?
Business impact	Which critical business service, application, process, or asset was the defined objective or at risk?
Attack path	How did the testers progress from initial access toward the defined objective?
Adversary behavior	Which relevant TTPs were attempted, and which were successfully executed or blocked?
Control effectiveness	Which preventive controls were effective, and where did control gaps allow the attack path to progress?
Detection and response	What was detected, what remained undetected, and how effectively did the organization respond?
Remediation priorities	Which changes would disrupt the attack path, address control gaps, or materially reduce risk?

The outcome should give leadership a clear view of how the tested threat could translate into business risk and where security improvements should be prioritized.

How Anzen Approaches Intelligence-led Testing

Anzen structures ILPT/TLPT around a simple principle: The threat determines the scenario, the environment determines the attack path, and the outcome determines the security decision.

From Testing to Assurance

At Anzen, we approach security testing as a progression rather than a collection of standalone assessments. Our capabilities span vulnerability assessment and penetration testing, red teaming, adversary emulation, and intelligence-led security testing, allowing organizations to select the depth and type of testing based on their threat landscape, business objectives, technology environment, and assurance requirements.

What differentiates our approach is the ability to connect these assessments rather than treat them as isolated exercises. VAPT identifies and validates weaknesses, red teaming examines how weaknesses can be combined to achieve a defined objective, adversary emulation tests whether defenses can withstand the techniques and behaviors of a relevant threat actor, and intelligence-led testing uses relevant threat intelligence to determine which adversaries, behaviors, and attack scenarios should drive the assessment. This enables organizations to examine not only individual vulnerabilities, but how attack paths, security controls, detection capabilities, and response processes interact within a defined scenario.

The result is evidence that helps security leadership understand what could be exploited, how an attack could progress, which controls would prevent or detect it, and where security improvements should be prioritized.

Not every penetration test needs to become a full-scale red-team exercise; the assessment should be matched to the security question at hand. For organizations looking to assess how relevant threats could translate into attack paths and business impact, Anzen helps define and execute the testing approach that fits the organization, from targeted VAPT and red teaming to intelligence-led engagements.

FAQ’s