What Is Red Teaming? A Buyer's Guide to Adversary Simulation

The short definition

The National Institute of Standards and Technology (NIST) glossary defines a red team as "a group of people authorized and organized to emulate a potential adversary's attack or exploitation capabilities against an enterprise's security posture." It defines a red team exercise as one "reflecting real-world conditions, that is conducted as a simulated adversarial attempt to compromise organizational missions and/or business processes."

Put plainly, a red team engagement asks one question: if a capable attacker came after something that matters to your business, would your organization notice, and would it respond in time? The team pursues an agreed objective the way an adversary would, and the result is a record of what they reached and what your defenders saw along the way.

Red team or penetration test?

The two are often bought interchangeably, and they should not be. They answer different questions.

A penetration test aims for coverage. The tester works through a defined scope, tries to find every exploitable weakness they can in the time available, and reports each one with evidence and a fix. Defenders usually know the test is running.

A red team aims for an objective. The team picks the paths an attacker would realistically take toward a specific target, often moving quietly, and does not try to find every weakness on the way. The main thing being tested is your detection and response.

For a broader comparison that also covers bug bounty programs, see red team vs penetration test vs bug bounty.

What a red team is testing

The target of a red team engagement is less a system than a capability. The Cybersecurity and Infrastructure Security Agency (CISA) describes its own red team assessments (RTAs) this way: "During RTAs, a CISA red team emulates cyber threat actors to assess an organization's cyber detection and response capabilities."

That usually covers three things:

• Prevention. Which controls stopped the team outright, and which ones they got around.
• Detection. Which actions produced an alert in your security operations center (SOC), your endpoint detection and response (EDR) tooling or your logs, and which produced nothing.
• Response. When something was detected, whether the right people were told, whether they understood what they were looking at, and whether they acted fast enough to matter.

Detection is where engagements most often earn their cost. In an advisory describing two red team assessments run at the same time, CISA reported that the red team reached full domain compromise at both organizations, but that one "failed to detect or contain the activity" while the other "rapidly identified initial compromise attempts, isolated affected systems, and forced the red team into an assume breach model." The same attack produced two very different outcomes, and the difference was the defenders.

How an engagement is planned

Realism comes from planning, not improvisation. Most red team engagements are built from the same pieces:

1. Objective. One or more agreed targets that would matter to the business if an attacker reached them, such as a payment system, a source code repository or a set of executive mailboxes.
2. Threat model. Which kind of adversary to emulate and which behaviours they use. MITRE ATT&CK, a knowledge base of adversary tactics and techniques based on real-world observations, is the usual shared vocabulary; MITRE describes it as "a common language and framework that red teams can use to emulate specific threats and plan their operations."
3. Starting point. Whether the team starts from the outside, or from an assumed foothold such as a standard employee laptop and account. An assumed-breach start spends the budget on what happens after entry rather than on getting in.
4. Stealth and detection tolerance. How quietly the team should operate, and what happens if they are caught: stop, continue from a new foothold, or move on to the next phase.
5. Control group. NIST describes a white team as "a small group of people who have prior knowledge of unannounced Red Team activities," which "ensures the scope of testing does not exceed a pre-defined threshold." In practice this is a handful of your staff who know the dates, can pause the work and can tell the exercise from a real incident.

All of this sits inside the same paperwork as any offensive engagement: a statement of work (SOW), rules of engagement with escalation contacts and stop conditions, and signed authorization for every system in scope. Our approach page describes each document.

What you should receive

A red team report is written for two audiences: the security team that detects and responds, and the owners of the systems the team reached. It should include:

• An operation timeline of each action the team took, matched against what your team observed, alerted on or missed.
• Detection and response gaps, each tied to the telemetry that was missing or the process step that failed.
• Findings for system owners: the weaknesses that let the team move toward the objective, with evidence and remediation guidance.
• An executive summary that states plainly whether the objective was reached, how far the team got, and what that means for the business.

The natural follow-up is a purple team engagement, in which the same behaviours are replayed with your defenders present so the detection gaps can be closed while the activity is on screen.

Questions to ask a red team provider

Put these into the request for proposal (RFP) or the first scoping call. Cost is driven by the objective, the starting point, the length of the operation and how quietly it must run. Our pricing page publishes starting prices, and the red team and adversary simulation service lists what is in scope.

Sources

1. 01NIST, Glossary: red teamAccessed 2026-09-26
2. 02NIST, Glossary: red team exerciseAccessed 2026-09-26
3. 03NIST, Glossary: white teamAccessed 2026-09-26
4. 04CISA, AA23-059A, CISA Red Team Shares Key Findings to Improve Monitoring and Hardening of NetworksAccessed 2026-09-26
5. 05CISA, AA26-237A, A Tale of Two SOCs: Insights From Two Red Team AssessmentsAccessed 2026-09-26
6. 06MITRE, ATT&CKAccessed 2026-09-26
7. 07MITRE, ATT&CK Resources: Adversary Emulation and Red TeamingAccessed 2026-09-26