Red Teaming: What Penetration Tests Can't Tell You About Detection and Response

Introduction

Picture a hypothetical organisation with a clean security record. It commissions a CREST-accredited penetration test every year. Findings are fixed, retests are passed and the board receives a tidy report. It has a managed detection service, endpoint protection on every laptop and a written incident response plan.

Then someone asks a simple question in a board meeting: "If a capable attacker got in tomorrow, how long would it take us to notice, and what would we actually do?"

Nobody in the room can answer with evidence. The penetration test never asked that question. It was not designed to.

That gap is what red teaming exists to close. A penetration test tells you where your systems are weak. A red team engagement tells you whether your organisation can detect and stop someone who is exploiting those weaknesses quietly, over time, with a specific goal in mind. This article explains the difference, when each is the right tool, why regulators value red teaming, and how to commission an engagement that produces evidence rather than theatre.

Two different questions

Penetration testing and red teaming use many of the same skills. The difference is the question each is built to answer.

A penetration test asks: "What vulnerabilities exist in this defined scope, and how far can they be exploited?" The testers work methodically and openly. Your IT team usually knows the test is happening. The goal is coverage: find as many meaningful weaknesses as possible in the web application, the external perimeter or the internal network, and explain how to fix them.

A red team engagement asks: "Can a realistic adversary achieve a specific objective without us detecting and stopping them?" The objective might be reaching a payments system, obtaining domain administrator rights or exfiltrating a defined set of data. Only a handful of trusted people know the exercise is running. The goal is not coverage. It is to test the whole defensive system: technology, people and processes, under conditions that resemble a real intrusion.

Put simply, a penetration test is about your attack surface. A red team is about your defenders.

Penetration test

• Core question: What is vulnerable, and how badly?
• Scope: Defined systems or applications
• Who knows: IT and security teams, usually
• Approach: Thorough, often noisy
• Main output: Prioritised list of vulnerabilities
• Best for: Assurance of specific systems, compliance testing

Red team engagement

• Core question: Can we detect and stop a realistic attacker?
• Scope: An objective, reached by any in-scope route
• Who knows: A small control group only
• Approach: Stealthy, patient, intelligence-led
• Main output: Attack narrative, detection and response gaps
• Best for: Testing security operations and incident response

Neither is better. They measure different things.

What a penetration test cannot tell you

A well-run penetration test is essential. But because of how it is designed, there are things it will never reveal.

Whether anyone is watching

During most penetration tests, the security team either knows the test is running or has been asked to whitelist the testers. Even when they don't, the test is rarely structured to measure detection. You learn that a server was vulnerable. You do not learn whether your monitoring saw the exploitation, whether an alert fired, or whether anyone acted on it.

How long an attacker could stay

Real attackers do not have a five-day window. Mandiant's M-Trends 2026 report puts the global median dwell time, the time an attacker is present before being discovered, at 14 days for incidents investigated in 2025, up from 11 days the year before. Mandiant attributes much of that rise to espionage groups and North Korean IT worker operations, where the median dwell time was 122 days (M-Trends 2026 Executive Edition).

A penetration test does not try to stay hidden for two weeks, let alone four months. A red team does.

Whether your people and processes hold

Many intrusions succeed not because of a single technical flaw but because a chain of small human and procedural failures lines up. A convincing phone call to the service desk. An alert that was triaged as a false positive. An escalation path that nobody followed at 2am. Mandiant's same report notes that voice phishing rose to 11% of initial infection vectors in 2025, becoming the second most common route in after exploits. Those are failures of process and behaviour, and a scoped technical test of a single system is not built to find them.

Whether your security investment works as a whole

You may own an endpoint detection and response (EDR) platform, a SIEM, a managed SOC contract and an email gateway. Each vendor will tell you its product works. A red team engagement is the closest you can get to seeing whether they work together, against an adversary who is actively trying to avoid them. Mandiant reports that attackers increasingly favour edge devices and appliances that do not support EDR, and abuse legitimate administrative tools to reduce the chance of detection. Those are exactly the blind spots that only show up when someone deliberately exploits them.

What a red team engagement involves

Every engagement is different, but a well-structured one follows a recognisable shape.

1. Objectives and rules of engagement

The engagement starts by agreeing what the red team is trying to achieve and what is off limits. Objectives should map to real business risk: "access the customer database", "move money in the test payments environment", "reach the operational technology network". The rules of engagement define safety boundaries, out-of-scope systems, emergency stop procedures and how the control group (sometimes called the white team or white cell) will be contacted.

2. Threat intelligence

Good red teaming is not "do whatever you like". It is built around the threat actors most likely to target your organisation and the techniques they actually use. This phase gathers open-source intelligence about your people, suppliers, infrastructure and digital footprint, then turns it into realistic attack scenarios.

3. Initial access

The red team attempts to get a foothold the way a real adversary would. Depending on scope, that may include targeted phishing, phone-based social engineering, physical access to premises, or exploitation of exposed services. This is where red teaming draws on the same disciplines as our physical penetration testing and social engineering work, but combined into a single campaign.

4. Persistence, lateral movement and the objective

Once inside, the team works quietly. It uses "living off the land" techniques, abusing legitimate tools such as PowerShell and Windows Management Instrumentation (WMI), to move between systems and escalate privileges while avoiding detection. Every action is logged and mapped to the MITRE ATT&CK framework so that, at the end, you can see exactly which techniques were detected and which were not.

5. Reporting and the debrief with your defenders

The most valuable output is not the list of things the red team did. It is the timeline set against what your defenders saw. Where did an alert fire? Where did it fire but get ignored? Where was there no telemetry at all? A strong engagement ends with a joint session, sometimes called a purple team exercise, where the red team replays its techniques so your blue team can tune detection rules and response playbooks.

Why regulators value red teaming

Red teaming is not a niche exercise invented by consultancies. Financial regulators have adopted intelligence-led red teaming as a supervisory tool, and the EU's DORA rules are a clear example.

DORA and TIBER-EU. Under Article 26 of the EU's Digital Operational Resilience Act, financial entities identified by their competent authority must carry out threat-led penetration testing (TLPT) at least every three years, on live production systems supporting critical or important functions (DORA Article 26). The supporting technical standards, Commission Delegated Regulation (EU) 2025/1190, were drafted in accordance with the European Central Bank's TIBER-EU red teaming framework (EUR-Lex 2025/1190). The TIBER-EU framework itself states that tests are run without the prior knowledge of the blue team, with only a small control team aware (TIBER-EU framework, 2025). These formal tests are regulator-led exercises with their own requirements for the testers who carry them out. This article is about red teaming as a way to test your own detection and response, not about those formal schemes.

You do not need to be a bank to learn from this. These frameworks reflect a regulatory view that a mature organisation should be able to show it can detect and respond to a realistic attack, not just that it has patched its servers.

When you need which

Red teaming is not a replacement for penetration testing, and it is not the right starting point for everyone.

Start with penetration testing if:

• You have not had a recent, thorough test of your external perimeter, internal network or key applications.
• Basic issues such as missing patches, weak credentials and flat networks are still being found.
• You need assurance on a specific system before go-live, or evidence for PCI DSS, ISO 27001 or a client contract.
• You do not yet have a security monitoring capability to test.

A red team against an organisation with obvious, unfixed vulnerabilities will mostly tell you what a penetration test would have told you more cheaply.

Consider red teaming when:

• You have run regular penetration tests and fixed the findings.
• You have invested in detection: an EDR platform, a SIEM, an internal SOC or a managed detection service.
• Your board, regulator or insurer is asking how quickly you would detect and contain a breach.
• You want to know whether your incident response plan works when nobody has been warned.
• You operate in a sector, such as financial services or critical national infrastructure, where intelligence-led testing is expected.

Many organisations run both: a regular programme of scoped penetration tests to keep the attack surface clean, and a periodic red team engagement to test whether the defences around it actually work.

How to commission a red team engagement that produces evidence

The value of a red team depends heavily on how it is set up. A poorly scoped engagement becomes an expensive demonstration that "the hackers got in". A well-scoped one produces measurable evidence your defenders can act on.

Agree objectives that matter to the business. "Get domain admin" is a technical milestone. "Access the HR system containing payroll and personal data" is a business objective the board understands. Use both where you can.

Keep the control group small. If half the IT department knows, you are not testing detection. Typically a few senior people, such as the CISO, a legal or risk representative and a technical lead, form the control group and can stop the exercise if needed.

Define safety rules in writing. Agree which systems are out of bounds, how production risk will be managed, how the control group will be contacted day and night, and what happens if a real incident occurs during the test.

Decide what you are measuring. Be explicit about detection and response. Which stages should have been detected? How long did it take? Was the escalation path followed? Our red team operations are designed to measure mean time to detect and mean time to respond, so you leave with numbers rather than impressions.

Ask for ATT&CK mapping and a defender debrief. Insist that every action is mapped to MITRE ATT&CK and replayed with your blue team at the end. That is where most of the long-term value is created.

Plan the remediation and the retest. Treat findings as a programme of work: detection rules to build, processes to change, controls to add. Then retest the gaps, ideally within 90 days, to prove they are closed.

Practical Insights

1. Penetration tests and red teams answer different questions. One measures your attack surface. The other measures your ability to detect and respond.
2. A clean pentest report does not prove you would spot an intruder. Most penetration tests are not designed to measure detection at all.
3. Attackers stay longer than your test window. Mandiant reports a 14-day global median dwell time for 2025, and far longer for espionage-driven intrusions.
4. Red teaming only pays off once the basics are in place. Fix the findings from regular penetration testing first.
5. Regulators value this in finance. The EU's DORA rules on threat-led penetration testing, and the TIBER-EU framework they draw on, are built on intelligence-led red teaming.
6. Objectives should reflect business risk. Choose goals the board will recognise, not just technical trophies.
7. The debrief is the product. ATT&CK mapping and a joint session with your defenders turn a dramatic story into better detection.
8. Retest the gaps. Evidence of closure is what boards, auditors and insurers ultimately want to see.

Conclusion

Penetration testing remains the foundation of any security assurance programme. It finds the weaknesses an attacker would use and tells you how to fix them.

But it cannot tell you whether your organisation would notice someone using those weaknesses right now. For organisations that have invested in monitoring and response, that is the question that matters most, and it is the one boards and regulators are increasingly asking.

A well-run red team engagement answers it with evidence: what was seen, what was missed, and how long it took. You can read more about how we run these operations on our full-spectrum red teaming page.

Don't wait for a real adversary to find the pathway. Contact our team today to discuss a tailored manual assessment for your organisation.