Red teaming: what it is and how it differs from a penetration test

Red teaming is a goal-oriented adversary simulation in which a team of ethical specialists, with the organization's authorization, plays out the realistic moves of a genuine adversary to test whether the organization can be compromised — and whether its defenders can detect and stop the attack in time. Unlike a classic penetration test, which sets out to find as many vulnerabilities as possible, red teaming verifies whether a concrete objective — for example, access to the most sensitive data — can be reached across the entire chain of people, processes, and technology. The result is not a list of flaws but an honest answer to how well the organization detects and contains a determined attacker.

Red teaming versus penetration testing

A penetration test and red teaming are often treated as the same thing, even though they answer different questions. A penetration test is vulnerability-based: within a pre-agreed scope, such as a specific application or network segment, it systematically finds and proves as many exploitable flaws as possible in a limited time. Red teaming is objective-based: it measures whether an attacker can reach a business-relevant outcome, while deliberately staying stealthy so that it also tests the ability to detect the attack.

• Measure of success. A penetration test succeeds when it finds vulnerabilities; red teaming succeeds when it reaches — or misses — a predefined objective.
• Scope. A penetration test is narrow and deep; red teaming is broad and crosses the boundaries of systems, people, and physical locations.
• Visibility. A penetration test is usually overt and coordinated; red teaming is covert and known in advance to only a small circle of people.
• The question it answers. "Where are we vulnerable?" versus "Would we notice an attack and stop it before it causes harm?"

Red, blue, and purple teams

A mature security program thinks in terms of team colors. These are not necessarily separate departments but roles that an organization fills internally or with external partners.

The red team

The red team adopts the attacker's perspective. Its task is to emulate the tactics, techniques, and procedures (TTPs) of likely adversaries and attack the organization along a realistic path — not to cause damage, but to reveal where a real attacker would succeed.

The blue team

The blue team are the defenders: the security operations center (SOC), analysts, incident response engineers, and system administrators. Their task is to detect, investigate, and stop the attack. The real value of red teaming shows precisely in how the blue team responds.

The purple team

The purple team is not a third group but a mode of collaboration: the red and blue teams work with their cards on the table, exchange findings as they go, and improve detection together. This approach is faster to learn from but less realistic in terms of stealth, so it is often used after a covert engagement has been completed.

How a red team engagement unfolds

A realistic engagement follows the same steps as a genuine attack. Practitioners often describe them using the MITRE ATT&CK framework, a public knowledge base of real-world attacker tactics and techniques that makes each step traceable, repeatable, and comparable.

• Planning. Together with the client we define the objectives, scope, rules, and the threat scenario we will follow.
• Reconnaissance. Gathering publicly available information about people, technology, suppliers, and exposed services.
• Initial access. The first breach — often via targeted phishing, an exposed service, or physical entry.
• Establishing a foothold and privilege escalation. Setting up persistence in the environment and acquiring higher rights.
• Lateral movement. Spreading unnoticed across the network toward key systems and accounts.
• Reaching the objective. Access to the "crown jewels" — the organization's most critical data or systems.
• Exfiltration simulation. Demonstrating data leaving the environment without actual loss — proof, not harm.

Not every engagement has to start from zero. In the "assume breach" approach, the red team begins already inside the network, so attention shifts to lateral movement and detection rather than the first break-in.

Attack vectors: cyber, social, and physical

Real attackers do not choose their path according to a defense's org chart, but according to the weakest link. That is why good red teaming combines three vectors.

The cyber vector

Attacks on applications, networks, cloud services, identities, and endpoints — from exploiting vulnerabilities to abusing misconfigurations and compromised credentials.

Social engineering

Exploiting people, not machines: spear phishing, phone-based deception (vishing), and abusing the trust of employees. The human being remains the most common entry point for a determined attacker.

The physical vector

Attempting physical entry into premises — tailgating an authorized person, false identities, and access to meeting rooms, network sockets, or server rooms. The physical and digital worlds are often connected more closely than they appear.

Rules of engagement

Red teaming is a controlled operation, not a free-for-all. The rules of engagement are a written agreement that clearly defines what is permitted and protects both the organization and the provider.

• Scope and exclusions. Which systems, locations, and techniques are permitted, and what is explicitly off-limits, such as critical medical or industrial equipment.
• Written authorization. A signed permission from a responsible officer — the legal basis that separates a test from a criminal act.
• De-escalation procedure. Predefined contact persons and a "safe word" for an immediate stop if the engagement were to endanger operations.
• Deconfliction. Ongoing coordination with a small circle of those in the know (the "white team"), so that genuine detection can be told apart from the simulation.

Testing detection and response

The key takeaway from red teaming is not the breach but the response to it. The engagement measures whether the defense noticed the attack, how quickly, and how correctly it responded.

• Did we detect it? Which moves triggered an alert and which remained invisible.
• How quickly? Time to detect and time to respond — how long the attacker would have operated undisturbed (so-called dwell time).
• How correctly? Whether the response processes, tools, and people worked as planned.

This is exactly why it makes sense to conclude every engagement with a joint review by the red and blue teams, walking step by step through what actually happened and what the defense saw. That comparison produces concrete improvements to detection rules and response procedures.

Threat-led testing: TIBER-EU and DORA

The most demanding form is threat-led penetration testing, where the scenarios are driven by real threat intelligence about the attackers who actually target the organization's sector. In Europe, the reference framework is TIBER-EU, designed by the European Central Bank.

• TIBER-EU. A harmonized European framework for threat-led red teaming on live, production systems, with separate threat-intelligence and red-team providers and oversight by the competent authority.
• DORA. The Digital Operational Resilience Act for the EU financial sector, applicable since January 2025, which introduces mandatory threat-led penetration testing (TLPT) for significant entities, based on TIBER-EU, as a rule at least every three years.
• Related frameworks. Similar approaches exist elsewhere too, for example the UK's CBEST for the financial sector.

What leadership learns from red teaming

For leadership, red teaming is not a technical exercise but a test of business resilience. A good report speaks the language of risk, not just vulnerabilities.

• A realistic picture. Whether a determined attacker would reach the most sensitive assets and how long they would remain unnoticed.
• Chains, not points. How individual, seemingly harmless weaknesses combine into a successful attack.
• Defensive capability. Where the defense works and where it needs investment in people, processes, or technology.
• Prioritized measures. A concrete, risk-ranked improvement plan that supports budget decisions.

When is an organization mature enough for red teaming

Red teaming is not the first step but a test of an already mature program. If an organization has not yet put the basics in place, an adversary simulation will only confirm the known at great cost — it is better to start with vulnerability assessments and penetration tests.

Signs of sufficient maturity include: an accurate asset inventory, functioning vulnerability and patch management, established monitoring and an incident response capability (a SOC or an equivalent function), and a clear definition of the most sensitive assets worth defending. Only once the defense can already detect something does it make sense to test whether it can also do so against a determined, stealthy adversary.

Frequently asked questions

What is the difference between red teaming and a penetration test?

A penetration test finds as many vulnerabilities as possible within a limited scope and is mostly overt. Red teaming is a covert, goal-oriented adversary simulation that tests the entire chain of people, processes, and technology and — most importantly — the organization's ability to detect an attack and respond to it. A penetration test answers the question "where are we vulnerable," while red teaming answers "would we stop the attack."

Which organizations need red teaming?

Organizations with a mature security program and high-value assets: financial institutions, critical infrastructure, technology companies, healthcare, and the public sector. In the EU financial sector, threat-led testing is even a regulatory requirement for significant entities (DORA). Less mature organizations should first put the basics in place and run penetration tests.

Is red teaming safe?

Yes, when it is carried out professionally. It is governed by written rules of engagement, a signed authorization, ongoing deconfliction, and agreed procedures for an immediate stop. The goal is to prove the attack path without causing harm; data leaving the environment is usually only simulated, and critical systems are often explicitly excluded from scope.

How often should red teaming be performed?

It depends on the risk profile, but a common practice is at least once a year and after major changes, such as a cloud migration, a merger, or the introduction of a new key system. Regulatory frameworks such as DORA generally prescribe threat-led testing at least every three years, which should be combined with regular penetration testing and continuous monitoring.

At the Institute for Security and Strategic Research (IVSR), we bring the cyber, physical, and human sides of security together into a complete picture of an organization's resilience. If you are wondering whether your organization is mature enough for an adversary simulation — or how to get there — contact us for a consultation.