These two get sold interchangeably, and that costs people real money. A scan and a penetration test answer different questions, and if you buy one expecting the other you will either overpay or walk away with false confidence.
What a scan actually does
A vulnerability scanner sends known probes and compares the answers against a database of known issues. It is fast, it is cheap, it runs unattended, and it is very good at the thing it does: finding the software you forgot to patch.
What it cannot do is reason. It does not know that your order ID is sequential and belongs to somebody else. It does not know that the password reset email can be pointed at an attacker's address by changing one header. It has no concept of what your application is for, so it cannot tell when the application is being used against itself.
What a test adds
A penetration test has a person in it. They read the application, work out what it is trying to protect, and then try to take it. The findings that follow are usually the ones no tool reports:
- Business logic. Buying at a negative quantity. Skipping the payment step. Applying one discount thirty times.
- Access control. Changing the identifier in a URL and reading somebody else's documents. A scanner has nothing to compare against, so it cannot see this.
- Chains. Three low-severity issues that are harmless alone and account takeover together.
- Context. A verbose error page is informational - unless it prints the database credentials.
False positives, and the other kind
Scanners report things that are not true. Someone has to check each one, and that work does not disappear because a tool produced the list. A tested finding has already been proven by the person who wrote it up.
The more expensive problem is the opposite: the issue the scanner never raised. A clean scan is easy to read as "we are secure". It means "nothing matched the patterns we checked for".
You want both
This is not an argument against scanning. Scan continuously - weekly, or on every deploy - because patch gaps appear constantly and a tool catches them for almost nothing.
Then test properly at the points where the stakes change: before a product goes live, after a significant rebuild, once a year for an established system, and whenever a compliance framework asks for it. The scan keeps the floor clean. The test tells you whether the door locks.
How to tell which you are being sold
Ask three questions. How many days of human testing are included? Can I see a sample report with the findings redacted? Is a retest included after we fix things?
If the answer to the first is vague, the sample is a tool export with a cover page, and a retest costs extra, you are buying a scan with a report template around it. That can be fine - as long as that is what you wanted, at that price.
Which one do you need
Can a scan ever replace a penetration test?
For the question "have we patched everything we know about", a scan is the right and cheaper tool, and it should run continuously. For the question "can somebody get in", it cannot help, because the findings that let people in - access control and business logic - require someone who understands what the application is for.
How can we tell which one a firm is actually selling us?
Ask how many days of human testing are in the price, and ask for a sample report. A proposal that cannot answer the first question, or whose sample is tool output with a cover page, is a scan with a penetration test’s price on it.
Should we run both?
Yes, and in that order of frequency: scanning continuously or monthly, testing at least annually and after major changes. Scanning keeps the known problems closed so that a test is not spent rediscovering them.
What does a test find that a scan never will?
Anything that requires understanding. Buying at a negative quantity, applying one discount thirty times, changing an identifier in a URL to read another customer’s documents, chaining three low-severity issues into account takeover. No tool has a concept of what your application is for.
Want this done on your own systems?
We scope the work in writing first, so you know exactly what will be touched and when.
Book a free consultation Back to the blog