A penetration test looks for exploitable weaknesses in a defined system and reports them. A red team exercise emulates a real adversary's goals to test whether your defenders detect and stop them. Most organizations need regular pen tests long before they need a red team.
What do the official definitions say?
NIST's glossary gives one definition of penetration testing as a method in which assessors, typically working under specific constraints, attempt to circumvent or defeat the security features of a system. It defines a red team as a group authorized and organized to emulate a potential adversary's attack or exploitation capabilities against an enterprise's security posture, with the objective of improving cybersecurity by demonstrating the impact of successful attacks and showing what works for defenders in an operational environment.
The difference is in the objective. A pen test asks what is vulnerable. A red team asks whether you would notice and stop a determined attacker pursuing a goal.
How do they differ in practice?
Scope. A pen test has a defined target: an application, an API, a network range. A red team scope is broader: the organization, with an objective such as "reach the customer database" and wide freedom in how.
Knowledge. Defenders often know a pen test is happening. In a red team exercise a small group may know, so that the blue team's response is real.
Output. A pen test report lists vulnerabilities with evidence and fixes. A red team report tells a story: the path taken, what was detected, what was missed, how long it took defenders to react.
Overlap. Both use the same techniques and both are authorized, with rules of engagement. NIST SP 800-115 is a guide to planning and conducting technical security tests and analyzing findings.
A constructed example
A company launches a new customer portal. A pen test of the portal finds an authorization flaw that lets one tenant read another's invoices. That is the right tool: bounded, fast, and the fix is clear. A year later the same company asks whether its security team would detect an attacker who phishes an engineer and moves toward production. Now a red team fits, because the question concerns detection and response across people, process and tools.
When do you need each?
Run pen tests when you ship major features, before launches, after architecture changes, and to meet customer or compliance expectations. Consider a red team when you already fix pen test findings quickly, run monitoring with real alerting, and want to test the human and process side. If you cannot yet patch what a pen test finds, a red team will only prove the same weakness expensively.
A related option is a purple team exercise, where attackers and defenders work together to tune detections. It is often a better step between the two.
How to check or apply this
- Write down the question you want answered: what is vulnerable, or would we notice an attacker.
- If the first, scope a pen test with named targets and a retest included.
- If the second, confirm monitoring and response exist, then define an objective and rules of engagement.
- Agree safety limits: no destructive actions, defined hours, an emergency contact.
- Choose a provider with relevant references and ask for a sample report.
- Plan remediation capacity before the test starts.
- Retest fixes and record the results.
Safeguard's vulnerability and reachability data can help you triage and fix what a pen test reports faster, but it does not replace human testing.
Quick check
Is a red team just an expensive pen test?
No. The objective differs. It tests detection and response against a goal-driven adversary rather than listing vulnerabilities in a scope.
Can automated scanning replace a pen test?
Scanning finds known issue classes at scale. A pen test adds human reasoning about logic and chained flaws.
Sources
- NIST CSRC glossary, penetration testing
- NIST CSRC glossary, red team
- NIST SP 800-115, Technical Guide to Information Security Testing and Assessment
Last reviewed: 18 October 2026.
