Penetration testing versus a vulnerability scan: which one you need
A scan finds known weaknesses automatically. A penetration test has a person trying to break in. Which one your business needs, and when to do both.
The short answer
A vulnerability scan is software checking your site for known problems: missing headers, outdated components, exposed files, classic injection patterns. It runs in minutes, costs little, and should happen regularly. A penetration test is a person, with the scanner’s output as a starting point, actively trying to break in: chaining small issues, abusing logic, doing what the application designer did not expect.
They are not alternatives. The scan is the routine; the test is the examination. The question is not which one, but whether your situation justifies the second.
Side by side
| Vulnerability scan | Penetration test | |
|---|---|---|
| Who does it | Software | A person, using tools |
| What it finds | Known, documented weaknesses | Known weaknesses plus logic flaws, chains and context-specific issues |
| How often | Monthly, and after every change | Yearly, or after major changes to a high-risk system |
| Time | Minutes to hours | Days to weeks |
| Cost | Low | Significant, scoped per engagement |
| Output | A list of findings by severity | A report with reproduction steps, impact and fixes, plus a re-test |
| Best for | Every website, as hygiene | Applications with logins, payments, personal data or internal connections |
When a scan is enough
A company website with a contact form, no accounts and no payments has a small attack surface. Regular scans, correct headers, a spam-protected form and a modern hosting platform cover it well. Spending on a penetration test here buys little that the scan and good configuration have not already given you.
When you need a test
- You take payments or hold customer accounts. Logic flaws here cost money directly.
- You process personal or sensitive data. Health, finance, identity documents, anything a regulator would ask about after an incident.
- The site connects to internal systems. A CRM, an ERP, a booking engine. The website becomes a door to something bigger.
- A customer or tender asks for it. Enterprise clients and public bodies increasingly require a recent test report.
- You just built or heavily changed an application. New code, new logic, new mistakes. A test before launch is cheaper than one after an incident.
What a good test looks like
- A written scope. Which systems and addresses, which user roles, what kind of attacker is simulated, what is explicitly out of bounds.
- Credentials where it matters. Testing behind the login finds the logic flaws; testing only the front door finds what the scan already found.
- A report you can act on. Each finding with severity, business impact, exact reproduction steps and a fix. A management summary on top.
- A re-test. After fixes, the tester confirms they worked. Without this, the report is a to-do list with no closure.
What this means for you
Scan every site you run, regularly, and fix what it finds. Then look at the list of five situations above. If one of them describes your business, budget for a penetration test on that system, scoped in writing, with credentials, a real report and a re-test. If none does, keep scanning and revisit the question when the site starts doing more.
Frequently asked questions
Do we need a penetration test for a brochure website?
Usually not. A marketing site with a contact form and no logins has a small attack surface, and regular scans plus good configuration cover it. The moment the site takes payments, has customer accounts, handles personal data or connects to internal systems, a test becomes worth it.
How long does a penetration test take?
Days for a focused web application, longer for a platform with several roles and integrations. The scoping conversation beforehand determines it: what is in scope, what kind of attacker is simulated, and whether the tester gets credentials. A test without a written scope is not a test.
What should the report contain?
Each finding with severity, a clear description of the impact in business terms, exactly how it was reproduced, and how to fix it. Plus a summary for management and a re-test of the fixes afterwards. A list of scanner output with a logo on it is not a penetration test report.
Can the same company that built our site test it?
They can test it, and they should as part of their own quality process. For an independent view, a separate tester is stronger, because they do not share the builder's assumptions. We do both: we test what we build, and we recommend independent testing for high-risk systems.
Sources
- OWASP Web Security Testing Guide (accessed 2026-09-11)
- OWASP Top Ten (accessed 2026-09-11)