Red Teaming: When Your Organisation Needs More Than a Pentest

TL;DR

A penetration test tells you where vulnerabilities exist. A red team exercise tells you something different and more important: whether your organisation can detect, contain, and respond to a real attack in progress. Red teaming is not a more expensive pentest. It is a fundamentally different type of assessment, designed for organisations that have already addressed basic security hygiene and want to know whether their defences hold under realistic attack conditions.

What red teaming is

Red teaming is a full-scope adversary simulation. An independent team of ethical hackers, the red team, acts as a real attacker and attempts to achieve specific objectives inside your environment: access sensitive data, disrupt a critical system, establish persistent presence, or move laterally from one part of the network to another.

The red team is not constrained by a predefined list of systems to test. It approaches your organisation the way a real attacker would: with intelligence gathering, patience, and a focus on achieving objectives rather than cataloguing findings. Your security team, your SOC, your helpdesk, and sometimes your physical security staff are all part of the exercise, whether they know it is happening or not.

The exercise ends when the agreed objectives have been achieved, or when the engagement window closes. What you receive is not a list of open ports and CVEs. You receive an account of what a real attacker could have done, how far they got, what they accessed, and critically, whether your defences detected and responded to any of it.

How red teaming differs from a penetration test

A penetration test is a structured assessment of a defined scope. You define the systems, the test type, the timeframe, and the methodology. The tester finds and documents vulnerabilities within that scope. It answers the question: what vulnerabilities exist here?

A red team exercise answers a different question: if a motivated, capable attacker targeted our organisation right now, using all available attack vectors, would we detect it? Would we contain it? Would we recover from it?

The practical differences are significant:

Scope. A pentest has a defined, agreed scope. A red team exercise has objectives, not a scope list. The red team can use any attack vector that a real attacker would, including social engineering, phishing, physical access, and supply chain targeting.

Awareness. A pentest is conducted with the knowledge of the IT or security team. A red team exercise is typically conducted without the knowledge of the blue team or SOC, so their detection and response is tested under realistic conditions.

Duration. A pentest runs for days to weeks. A red team exercise runs for weeks to months, allowing time for realistic attacker behaviour including patience, persistence, and opportunistic pivoting.

Output. A pentest produces a list of vulnerabilities with severity ratings and remediation guidance. A red team exercise produces an attack narrative, a detailed account of what the team did, what they accessed, and what your organisation detected or missed.

When your organisation needs a red team exercise

Red teaming is not the right starting point for every organisation. It is appropriate when certain conditions are met.

You have an established security baseline. Red teaming is most valuable when known vulnerabilities have been addressed through regular penetration testing and patch management. If basic hygiene is missing, a pentest will find more actionable findings more efficiently.

You want to validate your detection capability. If you have a SOC, a SIEM, or an incident response function, a red team exercise is the most realistic way to test whether those investments actually catch real attacks. Alert rules that look good on paper often miss attacker behaviour in practice.

You operate in a high-risk sector. Critical infrastructure, financial services, healthcare, and public administration organisations face motivated, well-resourced attackers. A red team exercise models the actual threat you face rather than a generic vulnerability scan.

You are subject to DORA or similar regulatory requirements. Significant financial entities under DORA are required to conduct Threat-Led Penetration Testing (TLPT) under the TIBER-EU framework. TLPT is an intelligence-led red team exercise, not a standard pentest, and must be conducted by certified providers with results reported to the competent authority.

You want a realistic picture of your residual risk. After years of security investment, many organisations still do not know how an attacker would actually progress through their environment. A red team exercise provides that picture with evidence.

What attackers actually exploit

Real attackers do not follow a penetration test methodology. They follow the path of least resistance to their objective. In practice, that path almost always runs through one of three areas.

People

Social engineering remains the most reliable initial access vector for sophisticated attackers. A convincing spear phishing email, a vishing call to a helpdesk agent, a pretext conversation with a receptionist. People are targeted because they respond to urgency, authority, and familiarity in ways that firewalls do not.

Red teams routinely achieve initial access through people before a single technical vulnerability is exploited. The technical attack often only begins once a foothold has been established through human interaction.

Credential theft and lateral movement

Once inside, attackers rarely need to exploit new vulnerabilities. Credential reuse, misconfigured permissions, overprivileged service accounts, and weak internal segmentation allow lateral movement that is often invisible to standard monitoring. Red teams consistently find that attackers can move from a compromised workstation to domain administrator access within hours in environments that have passed annual penetration tests.

Detection gaps

Most organisations have detection tools. Few have detection coverage. Alert fatigue, poorly tuned rules, missing log sources, and gaps in monitoring coverage mean that attacker activity often goes undetected for days or weeks. A red team exercise maps these gaps with evidence, showing exactly which actions triggered alerts and which did not.

What a red team exercise looks like in practice

A red team engagement follows a structured process, even when the attack itself is unconstrained.

Rules of engagement and scoping

Before the exercise begins, specific objectives are agreed, along with rules of engagement that define what is out of scope, who knows the exercise is happening, and what happens if the red team encounters a real incident in progress. This is done under strict confidentiality and typically involves only a small group of senior stakeholders.

Intelligence gathering

The red team builds a picture of your organisation using the same publicly available sources a real attacker would use: LinkedIn, company websites, job postings, technical footprint analysis, email format discovery, and open-source intelligence. This phase often reveals more than organisations expect about their external exposure.

Initial access and exploitation

The red team attempts to gain a foothold using the most realistic and effective attack vectors available: targeted phishing, vishing, exploitation of external-facing vulnerabilities, or physical access attempts. The approach is adapted in real time based on what works.

Post-exploitation and objective pursuit

Once inside, the red team moves toward the agreed objectives while attempting to remain undetected. This phase tests your internal segmentation, monitoring, and response capability. It often includes lateral movement, privilege escalation, data exfiltration simulation, and persistence establishment.

Reporting and debrief

The exercise closes with a full attack narrative, a timeline of what the red team did and when, a comparison of red team actions against blue team detections, identified gaps in detection and response, and strategic remediation recommendations. The debrief session with both technical and executive stakeholders is where the most valuable learning happens.

Purple teaming: when collaboration accelerates improvement

A purple team exercise is a collaborative variant of red teaming in which the red team and your internal security or SOC team work in parallel. The red team executes attack techniques while the blue team attempts to detect and respond, with findings shared in real time rather than at the end of the engagement.

Purple teaming is not a test of whether you would catch a real attacker. It is a structured improvement exercise. It is most effective for organisations that want to build and validate specific detection rules, improve SOC analyst skills in a controlled environment, or close identified gaps from a previous red team exercise.

Common mistakes organisations make

Commissioning red teaming before addressing basic hygiene. A red team will find an entry point quickly if basic vulnerabilities remain unpatched or if phishing simulations have never been run. The findings will be useful, but the investment is better spent on structured penetration testing first.

Treating the report as the deliverable. The most valuable part of a red team exercise is the debrief and the subsequent remediation work. Organisations that receive the report, share it with the board, and take no further action miss most of the value.

Selecting a provider based on price alone. Red team quality varies enormously. A low-cost red team that runs automated tools and calls it adversary simulation does not test what a real attacker would do. Ask specifically how the team would achieve initial access, what OSINT techniques they use, and how they document the attack narrative.

Expecting the red team to be caught. Many organisations approach a red team exercise hoping to demonstrate that their defences work. In practice, experienced red teams achieve their objectives in the large majority of engagements. That is not a failure of the exercise. It is the finding. The value is in understanding how it happened and what needs to change.

Red teaming and regulatory compliance

DORA requires significant financial entities to conduct Threat-Led Penetration Testing under the TIBER-EU framework. TLPT is an intelligence-led red team exercise scoped by the competent authority, conducted by certified external testers, and reported directly to the regulator. It is not a standard red team exercise, and not all providers are qualified to conduct it.

NIS2 does not explicitly require red teaming, but it does require organisations to assess the effectiveness of their risk management measures. For essential entities with complex environments, a red team exercise is the most credible way to demonstrate that assessment.

FAQ

What is red teaming in cybersecurity?

Red teaming is a full-scope adversary simulation in which an independent team of ethical hackers acts as a real attacker, attempting to achieve specific objectives such as gaining access to sensitive data, disrupting critical systems, or establishing persistent presence in your environment. Unlike a penetration test, which focuses on finding vulnerabilities in defined scope, a red team exercise tests whether your entire organisation, people, processes, and technology, can detect and respond to an attack.

What is the difference between red teaming and penetration testing?

A penetration test is a structured assessment of a defined scope, typically infrastructure, applications, or a specific system, conducted over a fixed timeframe. It answers the question: what vulnerabilities exist? A red team exercise is an unconstrained, objective-driven simulation of a real attack. It answers a different question: if a motivated attacker targeted our organisation right now, would we detect it, and could we stop it? Red teaming is broader, longer, and tests your detection and response capabilities, not just your vulnerability exposure.

When does an organisation need a red team exercise?

Red teaming is appropriate when your organisation has already addressed basic vulnerability exposure through regular penetration testing, has a security operations function or detection capability you want to validate, operates critical infrastructure, handles sensitive data at scale, or is subject to regulations that require threat-led testing such as DORA TLPT. It is not the right starting point for organisations without an established security baseline.

What attack techniques does a red team use?

Red teams use the full range of techniques that real attackers use, including open-source intelligence gathering (OSINT), spear phishing and social engineering, exploitation of technical vulnerabilities, credential theft and lateral movement, physical security testing, and attempts to establish persistent access and evade detection. The exercise is constrained only by pre-agreed rules of engagement, not by scope limitations.

What is a purple team exercise?

A purple team exercise brings the red team and your internal security or SOC team together in a collaborative format. Instead of the red team operating covertly, both teams work in parallel: the red team executes attack techniques while the blue team attempts to detect and respond, with findings shared in real time. Purple teaming accelerates detection improvement and is particularly effective for organisations that want to build their SOC capability rather than simply test it.

How long does a red team exercise take?

A red team exercise typically runs for four to twelve weeks, depending on the scope, objectives, and whether it includes physical testing and social engineering components. Intelligence-led exercises such as TIBER-EU TLPT take longer due to the threat intelligence preparation phase. The engagement ends when the agreed objectives have been achieved or the time window closes, not when a predefined list of tests has been completed.

Related services and resources

Sectricity conducts red team assessments across Belgium, the Netherlands, and the UK, combining technical exploitation, social engineering, and physical security testing into a single objective-driven engagement. We also provide penetration testing for organisations building their security baseline and social engineering assessments as standalone engagements. For organisations subject to DORA or NIS2, we offer compliance-mapped security testing. Not sure where to start? Begin with a free security scan.