> diff compliance.conf threat-led.conf_
Ask ten organisations why they commission penetration tests and you'll get broadly two answers. Half will say "because we have to" — a compliance framework, a client contract, or an insurer demands it. The other half will say "because we want to know what an attacker could actually do to us."
Both are valid reasons to test. But they lead to fundamentally different engagements — different in scope, depth, methodology, reporting, and ultimately in the quality of security decisions that follow. The danger isn't in choosing one over the other. It's in thinking they're the same thing.
Organisations that treat a compliance-driven test as a genuine measure of their security posture are making decisions based on incomplete information. And organisations that treat a threat-led assessment as sufficient for compliance may find auditors unsatisfied with the scope or documentation. Getting the framing right at the start determines whether the engagement delivers real value or just generates paperwork.
A compliance-driven pen test tells you whether you meet a standard. A threat-led pen test tells you whether you'd survive an attack. These are different questions — and the answer to one does not imply the answer to the other.
Compliance-driven testing exists because a regulatory framework, industry standard, or contractual obligation requires it. The test is scoped, conducted, and reported in a way that satisfies the specific requirement — no more, no less.
There's nothing inherently wrong with this. Standards exist for good reason, and the testing requirements within them represent a baseline of security assurance that regulators and industry bodies have agreed upon. The problem arises when the baseline is mistaken for the ceiling.
Common compliance drivers for penetration testing include:
| Framework | Requirement | What It Demands |
|---|---|---|
| PCI DSS | Requirement 11.3 (v3.2.1) / Req 11.4 (v4.0) | Annual external and internal penetration testing. Must test the cardholder data environment (CDE) and any segmentation controls. Retesting required after significant changes. |
| ISO 27001 | Annex A.12.6 / A.18.2 | Technical vulnerability management and compliance review. Penetration testing is not explicitly mandated but is widely expected by certification bodies as evidence of control effectiveness. |
| Cyber Essentials Plus | Technical verification | Hands-on assessment of the five controls: firewalls, secure configuration, access control, malware protection, and patch management. Scope is organisation-wide. |
| GDPR / UK GDPR | Article 32(1)(d) | "A process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures." Pen testing is a widely accepted way to satisfy this. |
| NIS2 Directive | Article 21 | Operators of essential services must implement risk management measures including "testing and auditing of security policies." Penetration testing is a key evidence source. |
| Contractual | Varies | Client or supplier agreements requiring annual pen tests, often specifying scope (e.g. "all internet-facing systems") and standards (e.g. "conducted by a CREST-accredited provider"). |
In each case, the scope is defined by the standard, not by the threat landscape. The tester assesses what the framework says to assess. The report is written to satisfy the auditor. The objective is certification, attestation, or contractual compliance.
Threat-led penetration testing — sometimes called adversary simulation, red teaming, or threat-informed testing — starts from a completely different premise. Instead of asking "do we meet the standard?", it asks "what would a real attacker do to us?"
The scope is defined not by a compliance requirement but by the organisation's actual threat profile: who are the likely adversaries, what are their objectives, what techniques do they use, and which of your assets are most valuable to them?
Threat-led testing uses real-world threat intelligence to design attack scenarios that reflect genuine risk. The tester doesn't just check for known vulnerabilities — they simulate the full attack lifecycle, from initial reconnaissance through exploitation, lateral movement, and objective completion.
| Framework / Approach | Context | How It Works |
|---|---|---|
| CBEST | UK financial services (Bank of England) | Threat intelligence-led penetration testing of critical financial institutions. A threat intelligence provider profiles the organisation's likely adversaries, and a separate testing team simulates those specific threats against live production systems. |
| TIBER-EU / TIBER-UK | European financial services | Threat Intelligence-Based Ethical Red Teaming. Similar to CBEST — a structured framework for conducting controlled, intelligence-led attacks against critical functions of financial entities. |
| STAR-FS | UK financial services (successor to CBEST) | Simulated Targeted Attack and Response. The next evolution, incorporating purple team elements and focusing on detection and response capabilities as well as prevention. |
| Red Teaming | Any sector | Full-scope adversary simulation with minimal rules of engagement. The red team operates covertly, attempting to achieve defined objectives (e.g. exfiltrate board minutes, access SCADA systems) using any available attack vector including social engineering and physical access. |
| Objective-Based Testing | Any sector | A pragmatic middle ground — penetration testing scoped around specific business objectives rather than compliance requirements. "Can an external attacker reach our customer database?" rather than "test all systems on this subnet." |
The output is fundamentally different too. Instead of a list of vulnerabilities sorted by CVSS score, a threat-led test produces an attack narrative — a step-by-step account of how an attacker moved from initial foothold to business-critical asset, which defences failed, which detections were missed, and what the real-world consequences would have been.
These aren't subtle distinctions. They affect every aspect of the engagement — and, critically, the quality of the security decisions that follow.
| Compliance-Driven | Threat-Led | |
|---|---|---|
| Starting question | "Do we meet the requirement?" | "Could an attacker achieve their objective?" |
| Scope source | Defined by the standard or contract | Defined by threat intelligence and business risk |
| Attack surface | Only what the standard specifies (e.g. CDE, internet-facing systems, in-scope controls) | The full realistic attack surface — including people, processes, physical security, and supply chain |
| Methodology | Systematic testing against a checklist of controls or vulnerability categories | Intelligence-driven simulation of specific threat actors using their known tactics, techniques, and procedures (TTPs) |
| Social engineering | Rarely included unless the standard demands it | Frequently a core attack vector — phishing, vishing, physical access attempts |
| Detection testing | Not typically assessed — the focus is on whether vulnerabilities exist | Central concern — can the SOC or security team detect and respond to the attack in progress? |
| Duration | Days to weeks, depending on scope | Weeks to months — reflecting the patience and persistence of a real adversary |
| Reporting | Vulnerability list with CVSS scores and remediation guidance, formatted for auditors | Attack narrative with chained findings, detection gaps, and business impact analysis, formatted for leadership |
| Primary audience | Auditors, compliance team, QSA | Board, CISO, security operations, risk committee |
| Outcome | Compliance certificate, attestation, or audit sign-off | Genuine understanding of resilience against realistic threats |
| Cost | Lower — tightly scoped, shorter engagements | Higher — broader scope, longer duration, specialist threat intelligence |
The real damage isn't in choosing the wrong type of test. It's in misinterpreting the results — making strategic security decisions based on the wrong kind of evidence.
Here are the scenarios we see most frequently, and the consequences that follow.
| Mistake | What Happens | The Consequence |
|---|---|---|
| Treating a compliance test as a security assessment | "We passed PCI, so we're secure." The PCI pen test only covered the cardholder data environment. The attacker came in through an unrelated web application and pivoted into the CDE from the internal network. | False confidence. The compliance test assessed a narrow scope; the attacker ignored that boundary entirely. |
| Scoping to the minimum | The cheapest possible test is commissioned to satisfy the requirement. Testing covers only what the auditor will check. Anything out of scope — even if it's connected and exploitable — is ignored. | The auditor is satisfied. The attacker is delighted. You've paid for a false sense of security. |
| Reporting to the wrong audience | A compliance report lands on the CISO's desk. It lists 47 findings by CVSS score. There's no attack narrative, no business context, no prioritisation beyond "critical, high, medium, low." | The CISO can't tell the board which findings matter most. Remediation is prioritised by CVSS score rather than actual business risk. A critical finding on an isolated test server gets fixed before a medium finding on the payment system. |
| Never testing detection | Every pen test is compliance-scoped and announced in advance. The SOC knows when testing is happening. Detection and response capabilities are never actually tested under realistic conditions. | The organisation has no idea whether it can detect a real intrusion. When one happens, the mean time to detect is measured in months, not minutes. |
| Annual testing as a snapshot | One compliance test per year. The certificate is issued. Everyone forgets about security until the next annual renewal. No interim testing after major changes, incidents, or new deployments. | The security posture drifts continuously for 11 months. The annual test becomes a ritual, not a risk management activity. |
A compliance-driven pen test is like an MOT for your car — it checks whether the vehicle meets a defined standard at a point in time. A threat-led pen test is like a crash test — it simulates what actually happens when something goes wrong, and measures how well the occupants survive. You need your MOT to drive legally. You need the crash test to know if you'll survive the journey.
These aren't theoretical concerns. They're patterns we encounter regularly in our work — organisations that have been testing for years but have never truly understood their risk.
The answer isn't to abandon compliance testing in favour of threat-led assessments, or vice versa. Both serve distinct and important purposes. The answer is to use each one for what it's designed to do — and to stop expecting one to deliver the value of the other.
| Need | Right Tool |
|---|---|
| Satisfy PCI DSS Requirement 11.3/11.4 | Compliance-driven test scoped to the CDE and segmentation controls, conducted by a PCI-qualified assessor |
| Understand whether a nation-state actor could reach your crown jewels | Threat-led assessment (CBEST, TIBER, or red team) with bespoke threat intelligence and full-scope adversary simulation |
| Achieve Cyber Essentials Plus certification | Compliance-driven test against the five CE controls, conducted by an IASME-accredited assessor |
| Test whether your SOC can detect a realistic intrusion | Threat-led assessment with covert red team operations and purple team debrief |
| Satisfy a client contract requiring annual testing | Compliance-driven test scoped to the contractual requirements — but consider upgrading to objective-based testing for additional business value |
| Understand the real business impact of your most likely attack scenarios | Objective-based testing scoped around critical assets and realistic attack paths, with business-contextualised reporting |
For most organisations, the practical approach is a layered one:
This gives you compliance sign-off and genuine security assurance — without expecting either type of test to do the other's job.
Not every organisation is ready for a full red team engagement, and that's perfectly fine. The type of testing you commission should match your current security maturity — and evolve as your programme matures.
| Maturity Level | Typical State | Recommended Testing |
|---|---|---|
| Early | Basic security controls in place. Limited security team. First pen test or first structured testing programme. | Start with compliance-driven testing and vulnerability scanning. Establish a baseline. Fix the fundamentals. Build confidence in the remediation cycle. |
| Developing | Compliance requirements met. Dedicated security resource. Regular patching and monitoring. Remediation processes established. | Add objective-based testing alongside compliance tests. Start scoping around business risk, not just regulatory requirements. Introduce social engineering assessments. |
| Established | Mature security programme. SOC or managed detection capability. Incident response plan tested. Multiple compliance frameworks satisfied. | Introduce threat-led testing and red team exercises. Test detection and response. Challenge assumptions. Move beyond vulnerability discovery into adversary simulation. |
| Advanced | Threat intelligence programme. Proactive threat hunting. Purple team capabilities. Continuous security improvement culture. | CBEST/TIBER-style exercises. Continuous red team operations. Assume breach scenarios. Supply chain testing. Focus on resilience, not just prevention. |
There's no shame in being at the early stage — every mature programme started there. The important thing is to be honest about where you are, commission the right type of testing for your current maturity, and use the results to move forward.
Whether you're evaluating providers, briefing your team, or presenting a business case to leadership, these questions will help ensure you commission the right type of engagement for your actual need.
Compliance-driven and threat-led penetration testing are both valuable, but they answer different questions. A compliance test tells you whether you meet a standard. A threat-led test tells you whether you'd survive an attack. Confusing the two leads to false confidence, misallocated budgets, and security decisions based on the wrong evidence.
The most dangerous phrase in cyber security isn't "we've never been breached." It's "we passed our pen test." Passing a compliance-scoped test means you met the standard at a point in time, within a defined boundary. It doesn't mean an attacker can't get in — it means the auditor is satisfied.
Use compliance testing for compliance. Use threat-led testing for security. Use both for confidence.
Whether you need a compliance test, a threat-led assessment, or a combination of both — we'll advise honestly, scope precisely, and deliver reporting that serves the right audience.