Testing
Penetration test, vulnerability scan, or red team: choosing by the question you have
These are not three price points for the same thing. They answer different questions, and buying the wrong one produces a report that is technically correct and practically useless.
A vulnerability scan tells you what is known to be wrong. A penetration test tells you what an attacker could actually do about it. A red team tells you whether you would notice and respond. Each is the right answer to a different question, and none of them substitutes for the others.
The comparison, without the marketing
| Vulnerability scan | Penetration test | Red team | |
|---|---|---|---|
| Core question | What known weaknesses exist? | What can an attacker actually achieve? | Would we detect and respond in time? |
| Driven by | Automated tooling and signatures | Human judgement, tool-assisted | Threat intelligence and objectives |
| Exploitation | None, or safe checks only | Yes, within agreed scope | Yes, and chained toward an objective |
| Business logic flaws | Missed almost entirely | Found — this is the main value | Found where they serve the objective |
| Blue team awareness | Fully aware | Usually aware | Deliberately unaware |
| Typical effort | Hours, automated | Days to weeks | Weeks to months |
| Output | Prioritised list of known issues | Reproducible findings with impact | Narrative of attack paths and detection gaps |
| Cadence | Continuous or monthly | At least annually, and on change | Every one to three years, when mature |
What a scan genuinely cannot see
Scanners match observed state against known signatures. That is valuable and cheap, and everyone should run one. But an entire class of the most damaging vulnerabilities has no signature, because the flaw is in your business logic.
- Broken object-level authorisation — changing an identifier in a request and receiving another customer's record. Every parameter looks valid; only the authorisation decision is wrong.
- Workflow bypass — reaching step five of a process without completing steps two through four.
- Privilege escalation through a legitimate feature, such as a user-management function that fails to check whether the target user is in your tenant.
- Pricing and quantity manipulation in commercial flows.
- Chained conditions where three individually low-severity issues combine into full compromise.
What a penetration test cannot tell you
A penetration test is a cooperative exercise. Your team knows it is happening, the source addresses are allowlisted so the test is not blocked, and the tester's goal is coverage rather than stealth. That combination makes it excellent at finding weaknesses and useless for assessing detection.
If a report says no alerts were raised during testing, that is not evidence that your detection is poor — the tester was probably not trying to be quiet, and may have been allowlisted. Conversely, if alerts did fire, it is not proof detection works, because the tester made no effort to evade.
When a red team is and is not appropriate
Red teaming is the right exercise when you have a detection and response capability whose effectiveness you want to measure. It is the wrong exercise when you do not, because the result is predetermined and you will pay a lot to learn something you could have assumed.
A reasonable readiness bar: you have monitoring covering endpoints and identity, someone is responsible for triage during business hours at minimum, you have run at least one round of penetration testing and remediated the results, and you have an incident response process that has been used at least once. If two or more of those are missing, spend the budget on the gap instead.
The middle options people forget
Purple teaming
Offensive and defensive teams work together, openly, executing known techniques while the defenders watch what their tooling produces. It is far cheaper than a red team, produces immediate detection improvements, and is often the best next step after a first penetration test. You lose the realism of an unaware blue team, and gain speed of improvement.
Assumed-breach testing
A penetration test that starts from a compromised position — a standard user account, or a foothold on a workstation. It skips the initial-access phase, which is the least informative and most time-consuming part, and spends the budget on what happens next. For most organisations this produces the highest value per day of any single exercise.
A sensible progression
- Continuous vulnerability scanning, with results actually triaged. Non-negotiable baseline.
- Annual authenticated penetration testing of internet-facing and business-critical systems, with retesting.
- Assumed-breach internal testing once the obvious external issues are closed.
- Purple team exercises to build and verify detection coverage for the techniques that testing showed are viable.
- Objective-led red teaming once detection is real, to measure it under realistic conditions.
Skipping steps is possible but rarely economical. A red team against an organisation without detection produces a short report saying so, and everyone involved knew it in advance.
Frequently asked questions
Is a vulnerability scan the same as a penetration test?
No. A vulnerability scan is automated and matches your environment against known issues. A penetration test is human-led and establishes what an attacker could actually achieve, including business logic and authorisation flaws that have no signature and are therefore invisible to scanners.
Do we need a red team?
Only if you have detection and response capability whose effectiveness you want to measure. Without monitoring, triage ownership, prior penetration testing and a used incident response process, a red team will confirm what you already know at considerable cost. Purple teaming or assumed-breach testing is usually the better next step.
What is assumed-breach testing?
A penetration test that begins from a compromised position — typically a standard user account or a foothold on a workstation — rather than from the outside. It skips the initial access phase and concentrates the budget on lateral movement, privilege escalation and data access, which reflects how most real incidents unfold.
Talk to the team
Need this tested rather than described?
QuietHours is a European cybersecurity practice operated by the securIT team. Send us the system, service, or control you are concerned about and we will help turn it into a workable scope.
Discuss your scope