To those unfamiliar with these disciplines, they might all sound like variations of the same thing — but each has its own distinct place in keeping an organisation secure.
Vulnerability Scan
The aim of a vulnerability scan is to catch the low-hanging fruit on a website or web application. The scanner identifies the versions of software used by services and cross-references them against a database of known vulnerabilities. Essentially, it flags: “You’re running version X.Y, and version X.Y has these known vulnerabilities.” What it doesn’t do is verify whether those vulnerabilities are actually exploitable, or whether any technical mitigations are already in place.
A very common example is a website running an outdated JavaScript library. The scanner spots the library, checks its database, finds a known vulnerability, and adds it to the report. However, that vulnerability may only be exploitable under specific circumstances that simply don’t exist in that website, or the affected function of the library may never actually be called. So yes, the site is running old tech — but it isn’t necessarily vulnerable.
Vulnerability scanners do perform some basic testing, including rudimentary checks for XSS (cross-site scripting) and SQL injection, but these are limited to predefined checks and won’t catch anything complex or context-dependent.
Vulnerability scanning is well-suited as a regularly scheduled service, for example quarterly, to catch low-hanging fruit and ensure software is kept up to date. This matters because a large proportion of attacks against organisations are automated bots scanning for known vulnerabilities. That said, it isn’t comprehensive enough to stand alone as a security measure. That’s where penetration testing comes in.
Penetration Testing
The aim of a penetration test is to perform comprehensive testing against an agreed scope, with the goal of finding issues and demonstrating real impact. A penetration tester will identify the same version information that a vulnerability scanner would, but will then actively test each finding to rule out false positives — ensuring only actionable issues make it into the report.
Beyond eliminating false positives, a pentest also uncovers complex issues that no scanner would find. For example, there might be a business logic flaw that allows a user to apply a discount code multiple times when it should be single-use — potentially stacking discounts to achieve a 100% reduction on a purchase.
Penetration tests do have constraints, and these are typically defined upfront. The two biggest are scope and time. A client might only include one web application in scope, and allow only one week for testing, both of which are entirely normal. Clients generally want their live applications tested and need the report delivered by a specific date, whether for a supplier review or a compliance requirement.
Penetration testing is excellent for ensuring that a website, web application, or network has been thoroughly assessed and that most, if not all, issues have been identified. Tests are typically conducted annually or following significant changes. The limitation is that attackers aren’t bound by a scope or a deadline.
Red Teaming
The aim of red teaming is to simulate a real-world attacker. There are no scope limitations, and the engagement window is measured in months rather than days or weeks. Where a penetration test defines a fixed set of targets and aims to find all vulnerabilities within that boundary, a red team has a single objective: reach the high-value target and demonstrate maximum impact. A red team won’t produce a comprehensive list of every vulnerability in the organisation, it will show you the chain of weaknesses that led them to the keys to the kingdom.
With no hard scope restrictions, a red team will leverage all available information and techniques to achieve their objective. This might mean identifying a legacy system that has historically been excluded from penetration tests and exploiting it. It might mean using data from public breaches to check whether employees are reusing credentials. Or it might involve social engineering staff into disclosing sensitive information or performing actions such as transferring funds to an attacker-controlled account.
The primary constraint on a red team is usually cost, these are long engagements. The focus is on reaching the areas of the business where a real attacker could cause the most damage, and ensuring those vulnerabilities are remediated before that happens.
But what if your digital defences are solid and your employees are well-trained with strict validation protocols? That raises a different question: how secure is your physical access?
Physical Assessment
The aim of a physical assessment is to test your physical access controls. Your digital defences might be robust enough to prevent a remote attacker from reaching your servers, but is your front door equally well protected?
Consider a scenario where an attacker doesn’t need to bypass your network at all. What if they can simply walk in and plug a keylogger into a device on the CEO’s desk? Or what if the goal isn’t to compromise IT systems, but to steal valuable equipment or materials? That’s exactly what a physical assessment is designed to uncover.
During a physical assessment, an assessor will attempt to gain access to a site or location by any reasonable means. This could include picking a lock, using specialist tools to manipulate doors or windows, or — in some cases — finding an unsecured entry point entirely. Once inside, they might install keyloggers, duplicate keys, relocate vehicles (to simulate theft), or access servers in a way that completely bypasses all digital defences.
Physical assessments aren’t limited to covert night-time operations either. Daytime scenarios are equally valid — slipping through an unsecured side entrance, or simply convincing reception staff to grant access without proper verification.
The typical limitations on a physical assessment relate to the methods of entry and avoiding intentional damage. Anyone can smash a window to get in, but if the goal is to remain undetected, that approach immediately raises the alarm. The more realistic and valuable test is demonstrating what a skilled, patient attacker could achieve without leaving a trace.
Summary
No single assessment type covers everything. A mature security programme will layer these disciplines over time, using each where it delivers the most value.
| Vulnerability Scan | Penetration Test | Red Team | Physical Assessment | |
|---|---|---|---|---|
| Goal | Identify known vulnerabilities | Find and validate all vulnerabilities in scope | Simulate a real attacker reaching a target | Test physical access controls |
| Scope | Defined (tools, URLs, IPs) | Defined and agreed upfront | Unrestricted | Site or location |
| Duration | Hours | Days to weeks | Months | Days to weeks |
| Depth | Surface-level, automated | Thorough, manual and automated | Targeted, goal-driven | Hands-on, scenario-driven |
| False positives removed? | No | Yes | Yes | Yes |
| Finds business logic flaws? | No | Yes | Yes | N/A |
| Includes social engineering? | No | Rarely | Yes | Sometimes |
| Typical frequency | Quarterly | Annually / post-major change | Every few years | Annually / as needed |
| Best for | Ongoing hygiene and patch validation | Compliance, supplier assurance, thorough coverage | Testing resilience against a determined attacker | Validating physical security controls |