Penetration Test vs Vulnerability Scan: Key Differences

Buyers often hear "penetration test" and "vulnerability scan" used as if they meant the same thing. They do not. A vulnerability scan is an automated check that compares systems against a database of known weaknesses. A penetration test is a scoped, human-led exercise in which a tester examines whether weaknesses can actually be used against an agreed target, and documents the evidence. Both are useful. The right choice depends on the question you need answered, the maturity of your environment, and who will read the results.

What It Is

A vulnerability scan runs a tool against hosts, websites, or applications and reports issues it can recognise: missing patches, outdated software versions, exposed services, weak TLS settings, or common misconfigurations. Scans are fast and repeatable, which makes them a good fit for regular hygiene. Their limits are well known. Scanners produce false positives, miss issues that depend on business logic, and cannot tell you whether a low-rated finding becomes serious when combined with another. A penetration test starts from a written scope and rules of engagement. The tester uses tools, including scanners, but then works manually: validating findings, testing authentication and authorisation, checking how roles and tenants are separated, and following realistic paths an attacker could try. The output is a report with evidence, severity, and remediation guidance rather than a raw list of tool output. In short, a scan tells you what might be wrong; a penetration test tells you what is demonstrably wrong in the agreed scope and why it matters.

Who It Is For

This comparison is useful for teams that:

Have received a request from a customer, partner, or insurer for "security testing" and need to understand what is actually being asked
Run regular scans already and want to know whether a manual test would add meaningful insight
Are launching a new web application, API, or mobile app and need to decide how deep pre-launch testing should go
Need to explain to management why two quotes for "testing" look very different in effort and output

What It Helps Clarify

Reading the two side by side helps clarify:

Whether your question is about known-issue hygiene (scan) or exploitable risk in a specific system (penetration test)
Which findings in an existing scan report are likely noise and which deserve manual validation
How business logic, access control, and multi-step attack paths sit outside what automated tools usually detect
What evidence a stakeholder will expect to see in a final report

What's Included

Scan checklist: define the asset list, schedule scans regularly, assign an owner to triage results, and track remediation over time
Penetration test checklist: agree targets, environments, test window, access method, named contacts, and stop conditions in writing before work starts
Confirm written authorisation from the system owner, and from any hosting provider or supplier that operates in-scope systems
Decide whether authenticated testing is needed (test accounts for each role) so access-control issues can be examined
Agree how findings will be rated and how evidence will be shared securely with named contacts
Plan a retest window so fixed findings can be confirmed after remediation

What's Not Included

A claim that a scan alone demonstrates an application is secure
A claim that a penetration test finds every weakness; it examines an agreed scope within an agreed time
Exploitation instructions or testing of systems you do not own or have no permission to test
Certification, compliance approval, or a formal audit opinion

When to Choose It

Choose scanning when you need regular, broad visibility across many assets and have a process to triage and fix what it reports. Choose a penetration test when a specific system matters to the business, when a customer or partner asks for evidence of manual testing, before a significant launch, or after major changes to authentication, payments, or data handling. Many organisations use both: scheduled scans to keep hygiene steady and a periodic penetration test to examine the systems that carry the most risk. If you cannot yet list your assets or owners, a broader baseline review may be a more useful first step than either.

Our Approach

Start with the decision you need to make. If a customer questionnaire asks for an annual penetration test, a scan report will usually not satisfy it. If you simply need to know whether internet-facing servers are patched, a full manual test may be more than you need. Next, confirm the scope: which applications, APIs, environments, and user roles are included, and which are explicitly excluded. Agree the test window and who can pause the work. Our Penetration Testing service follows this pattern: scope, written authorisation, testing within the agreed rules of engagement, a written findings report with prioritised remediation guidance, a debrief, and, where included, a retest of agreed findings. Whatever provider you use, ask to see a sample report before you commit, and check that it separates validated findings from informational observations. Finally, budget time for remediation. A test that produces findings no one has time to fix adds little value, so align the test date with your team's capacity to act on the results.

Penetration Testing

View the Penetration Testing service page