A red team is an authorized group that imitates an adversary to test an organization's defenses. A blue team is the group that defends against it and strengthens the security posture. Often a third group, the white team, referees the exercise and keeps it within agreed rules.
How does NIST define the red team?
The NIST glossary, citing NISTIR 7622, describes 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. The stated goal is to improve the enterprise's information assurance by demonstrating the impact of successful attacks, and by showing what works for the defenders.
Look at the second half. The point is not to win. It is to produce evidence that helps the defenders improve.
How does NIST define the blue team?
The same entry gives two meanings. In the first, the blue team is the group responsible for defending the enterprise's use of information systems against mock attackers. It typically defends over a significant period, in a realistic operational setting, under rules monitored by a neutral referee, the white team.
In the second, blue team describes people who run operational network vulnerability evaluations and give mitigation advice to customers who want an independent review. NIST adds that a blue team is often used alone, or before a red team engagement, so the network is as secure as possible before the red team tests it.
That ordering is worth remembering. Sending a red team against an environment with no basic hygiene mostly proves what you already know.
How is that different from a penetration test?
A penetration test usually has a defined scope and aims to find as many weaknesses as possible in that scope. A red team exercise tests the whole defensive process, including detection and response, against a realistic objective such as reaching a specific system. The two overlap, and different organizations draw the line differently, so agree on definitions in writing before you buy either.
A constructed example
A company wants to know whether it would notice a stolen employee login. The red team is given a goal: reach the finance share without being stopped. The white team sets the rules, including which systems are off limits and who can call a halt. The blue team is not told when the test starts. The red team gets in through a reused password and reaches the share in two days. The blue team's alerts fired on day one but nobody read them. The report shows the exact gap, an alert with no owner, which is the thing to fix.
How to check or apply this
- State the objective of the exercise as a question, such as can we detect and stop this behavior.
- Fix the rules in writing: scope, off limits systems, hours, and an emergency stop.
- Name a white team contact who can pause the test.
- Run a basic hygiene pass before the red team starts, so the test finds new problems.
- Record what the blue team saw and when, not just what the red team did.
- Turn each finding into an owned task with a date, and retest it.
- Share the results with engineering, not only with security leadership.
If your exercise includes the software supply chain, Safeguard can give the blue team a dependency inventory and flag reachable vulnerabilities in your own code. That helps with preparation, but it does not replace a red team.
Quick check
What is a purple team?
The term is commonly used for red and blue teams working together and sharing findings in real time. The NIST entry above covers red, blue and white, so treat purple as common usage and agree on what it means in your exercise.
Who needs a white team?
Any exercise where a mistake could cause real harm. The white team keeps the test within agreed rules and can stop it.
Sources
Last reviewed: 18 October 2026.
