Penetration Test vs Red Team: Scope, Goals and Which One You Need

What is the difference?

A penetration test measures the security of a system: a web application, an IoT device, an ECU, a network segment. The testers know the scope, the owner knows the dates, and the goal is to find as many exploitable weaknesses as possible in the time available and to document them so the team can fix them. A red team engagement measures the security of an organisation: given a goal such as “read the board’s mailbox” or “reach the production network”, a small team tries to get there by any agreed means over weeks, while the defenders do not know it is happening. The result is not a list of vulnerabilities but an answer to “would we notice, and would we stop it?”.

The two differ in breadth and depth. A pentest goes deep into one target and reports everything it finds. A red team goes wide across people, physical access, cloud identities and the network, uses only what it needs to reach the goal, and leaves most vulnerabilities untouched because exploiting them would be noisy. A red team that finds an open door walks through it; a pentest tries every door.

Side by side

	Penetration test	Red team
What it covers	One or a few defined targets, tested for every weakness class the scope allows	The organisation: people, premises, identities, network, detection and response, measured against one or more objectives
What it misses	Detection quality, response speed, social engineering and physical access unless scoped in	Most vulnerabilities in any single system; it stops exploring once a path works
Who does it	Security engineers with a scope and rules of engagement, with the owner’s IT informed	A small team of operators for initial access, infrastructure and lateral movement; only a few insiders (the “white team”) know
Duration	Days to three weeks per target	Four to twelve weeks, including reconnaissance and a slow, quiet pace
Typical cost	6,000 to 15,000 euros for a web application, 20,000 to 45,000 for an ECU; typical ranges for Germany and the EU	40,000 to 150,000 euros and more, depending on duration and objectives; not an offer
Frequency	Once or twice a year per system and after major changes	Every one to three years, once the basics are in place
Required by	PCI DSS, TISAX and OEM requirements, CRA conformity evidence, customer contracts, NIS2 risk management in practice	DORA Art. 26 (threat-led penetration testing at least every three years for selected financial entities), TIBER-EU; otherwise voluntary
Output	Report with every finding, proof, severity and fix; retest	Attack narrative with timeline, the detections that fired and those that did not, a debrief with the blue team, a short list of root causes

Choose a penetration test when

• You want to know what is wrong with a specific system before launch, before a customer audit or after a rewrite. A red team would not tell you about the second and third weakness in your login flow.
• You ship a product. Firmware, debug ports, CAN and UDS, radio protocols, a mobile app: that is pentest territory, and no red team spends weeks desoldering flash chips.
• You have no SOC, no EDR and no incident-response process yet. A red team against a company without detection is over in a day and teaches you only what you already know.
• A regulation or a customer asks for a test report on a named system. Red team reports are deliberately not that.

Choose a red team when

• You already pentest regularly, run a SOC or a managed detection service, and want to know whether it works against someone who is trying not to be seen.
• Your question is organisational: can an attacker with one phished account reach the domain admin, the OT network or the payment system, and how long until anyone notices?
• You fall under DORA or TIBER-EU, or the board wants evidence beyond “all findings fixed”.
• You want to exercise incident response for real, with a defined objective and a debrief, instead of a tabletop exercise.

In these cases the red team is the better choice even though it costs several times more, because a pentest cannot measure detection and response at all.

Both together

Pentests build the foundation; a red team checks whether the foundation and the people on top of it hold. The usual order is: pentest the exposed systems and products, fix, set up detection, then red team every one to three years with the blue team debrief as the most valuable part. Many organisations settle on a purple team in between, where attackers and defenders work on specific techniques from MITRE ATT&CK together; it is cheaper than a full red team and improves detection faster.

Zyberum’s core work is penetration testing across IT, IoT, automotive and OT. We do not run full red team operations with physical intrusion and months of covert activity; if that is what you need, we say so, help you write the objectives and rules of engagement, and test the systems a red team would later use as a way in. If you have no monitoring yet, a red team is the wrong purchase; start with pentests and, where it fits, with detection such as the Zyberdome managed SOC.