Penetration test vs red team.

Penetration test. A coverage-led assessment. The customer defines a scope (this web application, this API, this cloud environment). The tester works through a methodology and reports findings against each component in scope. The success criterion is coverage: did we test everything we said we would, and what did we find?

Red team engagement. A goal-led adversary simulation. The customer names an objective (gain access to the finance team's email, reach a specific database, plant a backdoor in production). The team pursues that objective using whatever realistic technique a real attacker would: phishing, exploiting an exposed service, social engineering, physical access, internal pivot. The success criterion is the objective: did we reach it, how, and what did your defences catch along the way?

Concrete differences in practice:

• Scope. A pentest is narrow (one application or environment). A red team is broad (anything the attacker would touch in pursuit of the goal).
• Methodology. A pentest follows a coverage checklist. A red team follows attacker tradecraft, choosing the path of least resistance.
• People in scope. A pentest usually does not target employees. A red team often does (phishing, OSINT, sometimes physical).
• Detection. A pentest typically tells the SOC that testing is happening. A red team usually does not, because seeing whether attacks are detected is part of the test.
• Deliverable. A pentest produces a findings report. A red team produces a narrative of the attack chain, what worked, what your defences saw, and what to fix at each stage.
• Cost and duration. A pentest runs one to four weeks. A red team runs four to twelve weeks.
• Compliance. Most compliance frameworks ask for pentests. Some (FFIEC, regulated financial sectors) ask for red team or threat-led assessments specifically.

A pentest fits when you need:

• Coverage assurance on a specific application or environment.
• Compliance evidence.
• A finding catalogue developers can act on.
• A predictable cost and timeline.
• The ability to test components separately as they ship.

A red team fits when you need:

• To answer a specific scenario question (could an attacker reach our crown jewels in 30 days?).
• To exercise your detection and response capability, not just your defences.
• To test the whole security programme: people, process, and technology together.
• To brief a board, regulator, or executive committee on a realistic attack picture.
• To validate readiness after major changes to the security programme.

A purple team is a red team engagement where the defenders work alongside the attackers. Instead of testing detection in stealth, the red team executes a technique, the blue team tries to detect it, and both sides discuss the result.

Purple teams build detection capability faster than red teams because the feedback loop is immediate. They lose the realism of a stealth red team but gain the ability to systematically improve detection. Many organisations run purple teams between red team engagements to harden detection between assessments.

Yes, on different cadences. Pentests run periodically (annually plus per release) for coverage and compliance assurance. Red teams run less often (annually or every two to three years for most organisations, more often in regulated financial services) for scenario assurance. Purple teams run between red team engagements to build detection.

In practice: most organisations should establish a consistent pentest programme first, then add a red team engagement once defences and detection capability are sufficient to make the exercise meaningful. Running a red team against a programme that lacks basic hygiene mostly proves what is already known.