A penetration test looks for as many weaknesses as possible in an agreed set of systems. A red team exercise pursues one realistic goal, such as reaching sensitive data, across people, process and technology, and also tests whether your team detects and responds. Both are authorized, scoped in writing and run safely; they answer different questions.
Side by side
| Penetration test | Red team exercise | |
|---|---|---|
| Question answered | Where are the weaknesses in these systems? | Could a realistic attacker reach this goal, and would we notice? |
| Scope | A defined list of apps, APIs, cloud accounts or networks | A goal, a starting point and wider boundaries |
| Breadth | Wide: as many findings as possible | Narrow and deep: one path to the goal is enough |
| Who knows | Usually your technical team | A small control group; defenders usually do not know |
| Detection | Not the main subject | A main subject: what was seen, when and how the team responded |
| Typical result | Ranked findings with fix steps | An attack narrative mapped to MITRE ATT&CK, with detection gaps and fixes |
| Best timing | Before a release, after a big change, or on a regular cycle | When basic weaknesses are already being fixed and you want to test detection and response |
When a penetration test is the right choice
- A new application, API or mobile app is about to launch.
- A migration, new cloud setup or new vendor integration has changed your exposure.
- A customer, auditor or regulator asks for independent evidence that a system was tested.
- You have not tested a system before and want a broad picture of its weaknesses.
When a red team exercise is the right choice
- You already test regularly and fix what you find, and want to know if the pieces hold together.
- You want to know whether your monitoring and your people would notice a real attack.
- A specific scenario worries you, such as a compromised vendor account or a stolen staff laptop.
- Leadership wants evidence of how far an attacker could get, not a list of individual bugs.
How a red team exercise runs safely
Because defenders are not told, a red team needs extra safeguards. At Edilec, the goal, starting point, boundaries and a small control group are agreed in a signed rules-of-engagement document before anything starts. The control group can tell a real alarm from the exercise and can stop it at any time. Destructive attacks, ransomware and safety-critical systems are excluded, and staff phishing runs only when the client approves it in writing.
Mapping activity to MITRE ATT&CK
MITRE ATT&CK is a public catalogue of attacker tactics and techniques. Mapping each step of a red team exercise to ATT&CK lets your defenders see which techniques were used, which were detected and which were missed. That turns the exercise into concrete detection work rather than a story.
Doing both
The two are not rivals. Many organizations run penetration tests on new and changed systems throughout the year, and a red team exercise less often, once the basics are in place. If you are not sure which you need, start from the question: "where are the weaknesses?" points to a penetration test; "would we notice and stop an attacker?" points to a red team.
Both start with a clear scope; see How to scope a penetration test and Rules of engagement and authorization letters. Edilec runs both; see Penetration Testing and Red Team Services.
