A scan checks for known weaknesses quickly and cheaply. A test shows what a person could actually do. Here is how to choose, scope and buy each.
A vulnerability scan is an automated check for known weaknesses and common configuration mistakes. A penetration test is an authorised attempt by a person to break in, which shows what an attacker could actually do. Most products need both, at different moments: scans often and cheaply as routine hygiene, and a test when the stakes rise, such as before launch.
Some providers sell a scan under the name of a test, so the difference is worth knowing before you buy either.
What a vulnerability scan does
A scanner compares what it can see against a database of known problems. Most are published as CVE entries, public records of flaws in specific software versions, and rated with CVSS, a common severity scale. It also runs checks for typical mistakes, such as a missing security header, an outdated protocol or a default page left exposed. A good routine uses several kinds:
- **Network scans** look at servers and open ports.
- **Web application scans** crawl a running site and probe its forms and parameters.
- **Dependency scans** read your lockfile and flag libraries with published vulnerabilities.
- **Cloud and container scans** check settings and images against known good practice.
A scan can run unauthenticated, as an outsider, or authenticated, signed in with a test account so it reaches pages behind the login. Its strengths are breadth, speed and repetition: running it again on every release costs little. Its limit is judgment. A scanner reports what matches a pattern and cannot tell whether a finding matters in your product.
What a penetration test does
A [penetration test](/glossary/penetration-testing) is carried out by a skilled person with written permission, within an agreed scope and time. The tester maps the application, tries to break it, chains small weaknesses into larger ones and reports what worked, with evidence. Tools help, but the value is judgment: the tester asks what the product must prevent, then tries to do exactly that. Our [penetration testing page](/services/cybersecurity/penetration-testing) covers the method and the black, grey and white box approaches.
What each finds, and what each misses
| Problem | Vulnerability scan | Penetration test |
|---|---|---|
| An outdated library or server with a published flaw | Finds it reliably | Finds it, but it wastes tester time |
| Missing headers, weak TLS settings, exposed default pages | Finds them | Finds them and checks whether they matter |
| A signed-in user reading another user's record by changing an ID | Rarely, because it does not know who should see what | Finds it, using two accounts |
| A discount, quota or approval step that can be abused | Misses it | Often finds it |
| Small weaknesses that combine into a serious one | Lists each alone, if at all | Chains them and shows the result |
| A weak password-reset or sign-in flow | Mostly misses it | Tests the whole flow by hand |
| Code that nobody reaches | Misses it | Misses it unless the tester reaches it |
Both have blind spots. A scan produces false positives, findings that look real but are not, and misses real problems it never noticed. A test is a snapshot of one version, on one date, for the time you paid for.
Which one fits your situation
Choose by the question you are asking, not by the price.
| Situation | Start with | Why |
|---|---|---|
| Every release | Automated scans in your pipeline | They are cheap, repeatable and catch known problems before a person has to |
| Launching a product with accounts, payments or personal data | A scan, then a penetration test | Fix what the scanner finds first, so the tester's time goes on logic and access control |
| You changed sign-in, roles or payment flows | A focused test of the changed area | One flaw there does the most harm |
| You inherited a codebase | A scan plus a [secure code review](/services/cybersecurity/secure-code-review) | You cannot assume anyone checked it, and a review sees code testers never reach |
| A contract or customer asks for evidence | Ask exactly what is required | The wording decides it, so confirm with whoever sets the requirement |
The order matters. Scan first, fix the obvious findings, then test. Paying a tester to rediscover an outdated library wastes hours better spent on flaws no tool can see.
How scope and reports differ
| Aspect | Vulnerability scan | Penetration test |
|---|---|---|
| Scope is set by | Addresses, domains, repositories or cloud accounts entered into a tool | Features, roles and flows, agreed in writing as rules of engagement |
| Effort | Set up once, then repeated at little cost | Days or weeks of a person's time, depending on scope |
| The report | A long list sorted by severity, with duplicates and false positives | Fewer findings, each verified, with steps to reproduce, impact and a fix, plus a summary for decision makers |
| Rechecking | Run it again | An agreed retest of each finding |
A scan report needs triage. For each finding ask three questions: is the affected component really in use, can an attacker reach it, and what would they gain? Fix those where all three answers are yes. Record the rest as false positives or accepted risks, with a reason, so the same alert does not return every week. A CVSS score describes a flaw in general; your own context decides how urgent it is.
A test report needs less triage, because the tester has verified each finding, and it should say what was not tested.
How to prepare
For a scan, start with an inventory of what you own, because forgotten domains, test servers and old APIs are where surprises hide. Then decide four things:
- **Targets.** Scan only what you own or have permission to scan, and check your hosting provider's rules.
- **Viewpoint.** Outsider, signed in, or both.
- **Timing.** A web scanner submits forms and creates load, so use a staging copy or quiet hours at a gentle request rate.
- **Ownership.** Who receives the results, and who decides what is a false positive.
A penetration test needs more: a fixed scope, a staging environment that mirrors production, test accounts for every role and a named contact. The [penetration testing page](/services/cybersecurity/penetration-testing) has the full list. For either, fix known issues first and tell your hosting and monitoring teams when the work will happen, so nobody mistakes it for a real attack.
What to ask a provider
- **How much is manual?** Ask what the tester does by hand beyond running tools. A scan with a cover page is still a scan.
- **What is in and out of scope?** Expect it in writing before a quote.
- **Can I see an anonymised sample report?** Look for reproduction steps, impact and fix advice, not only a scanner export.
- **How do you handle false positives** before the report reaches me?
- **Which methodology guides the work?** For web applications the common references are the OWASP Web Security Testing Guide and Application Security Verification Standard. The [OWASP Top 10](/glossary/owasp-top-10) is an awareness list, not a test plan.
- **What happens if you find something critical mid-test?** You want to hear that day.
- **Is a retest included, and for how long?**
- **How are my credentials, data and findings handled and deleted?**
Be wary of any provider who promises to find every vulnerability, quotes without asking about scope, or calls a scan a penetration test.
Where a code review and a disclosure policy fit
A [secure code review](/services/cybersecurity/secure-code-review) reads the source, so it sees the paths a tester never reaches and the logic errors a scanner cannot recognise. It cannot see how the application is deployed, which is what a test is for.
The other source of findings is people outside your team. Researchers and customers sometimes notice a flaw by accident, and they need somewhere to send it. A disclosure policy tells them where, and what to expect. Ours is public at [/security](/security). Whatever the source, every finding should land in one place: a ticket with an owner.
On the products we build, we combine these layers: a threat review at the start, testing before every release, and a security review before launch that hands you a prioritised fix list. The [cybersecurity service](/services/cybersecurity) page has the detail.