Penetration test or vulnerability scan? The difference is one you can feel in the price
The same words get used for work that differs by a factor of ten in cost. Here is what each one actually is, what neither can do, and how to tell which one you are being sold.
Ask three providers for a penetration test and you will get quotes that differ tenfold. That is not a market failing to find a price. It is three different products with one name.
Knowing which you are being offered is most of the skill in buying security work, and it is not hard once you know what to listen for.
What a vulnerability scan actually does
A scanner holds a database of known issues — software versions with published vulnerabilities, default credentials, missing headers, common misconfigurations — and checks your systems against it. It is fast, cheap, repeatable, and genuinely useful.
What it is doing is pattern matching against things that are already known to be wrong. If your web server announces a version with a published flaw, the scanner will tell you. If a login page accepts admin/admin, the scanner will find it. If TLS 1.0 is enabled, it will say so.
Scanners are also tireless and consistent in a way people are not. Running one weekly catches the server somebody spun up and forgot, the certificate about to expire, the dependency that acquired a vulnerability last Tuesday. That is real work and you should be doing it — most of it is free.
What a scan cannot do
A scanner cannot tell whether customer 1041 should be able to read order 5567.
That sentence is the entire distinction, and it is worth sitting with. Authorisation flaws — broken object level authorisation, the most common serious issue in modern applications — are invisible to a scanner, because determining whether a request should have been allowed requires knowing what your application is for. There is no signature for "this endpoint returns other people's invoices." The response is a perfectly valid 200 containing perfectly valid JSON. Nothing is malformed. Nothing matches a pattern.
The same is true of business logic. A discount code that can be applied twice, a workflow that can be completed out of order, a refund that can exceed the original payment, a password reset whose token can be replayed — none of these are defects a database of known issues can describe. They are defects in your rules, and finding them requires someone to hold your application's logic in their head and ask what happens if they do things in the wrong order.
Chained findings are the third gap. Three medium-severity issues that individually look unremarkable, but which compose into full account takeover, will be reported by a scanner as three mediums. The composition is the finding, and only a person notices it.
What a penetration test adds
A person, working with intent, who understands what your application is supposed to do and tries to make it do something else.
In practice a good engagement includes a scan — it would be foolish not to, since the cheap automated coverage is genuinely valuable and takes an hour. But the scan is the first hour, not the product. The rest is the part that requires judgement: mapping how authorisation is meant to work and testing every place it might not, following a workflow to see where state can be manipulated, and reading the responses carefully enough to notice the identifier that should not have been there.
The other thing you are buying is the writing. A scanner produces a list. An assessment produces an argument: what the risk is in your terms, what to fix first and why, what was checked and found sound, and what was not tested at all. That document is the product, and it is where the price difference actually goes.
How to tell which one you are being sold
The tells are consistent.
Ask how many days of testing are included. A real assessment is measured in days of human effort. If the answer is vague, or the delivery is same-day, you are buying a scan.
Ask who writes the report. If it is not the person who did the testing, the findings have been through a translation layer that loses exactly the reasoning you are paying for.
Ask what manual testing means in their methodology. "Manual verification of scanner output" is a scan with a review pass. That is a legitimate product at a legitimate price, but it is not an assessment, and providers who blur the two do it deliberately.
Ask for a sample report and look for authorisation findings. A report consisting entirely of missing headers, outdated libraries and TLS configuration is a scan export regardless of the cover page. A report with a finding that says a user with role X can access resource Y belonging to another tenant could only have been produced by a person.
Look at the price against the calendar. Serious testing of a moderately complex application takes the better part of a week. If a quote implies a day and describes a full assessment, something has to give, and it is the depth.
When a scan is genuinely the right answer
Often, and any provider who never says so is selling rather than advising.
If you have never scanned anything, start there — you will find real problems cheaply and there is no sense paying someone to find them slowly. If your requirement is genuinely a compliance checkbox with no security question attached, buy the cheap thing knowingly and spend the difference on something that matters. If your application is a marketing site with no authentication, there is very little authorisation logic to test and a scan plus a header check covers most of what exists.
The reason to be honest about this is not modesty. It is that the alternative — selling depth to someone who needed breadth — produces a client who spent a lot of money to be told what a free tool would have said, and tells other people about it.
The short version
A scan answers are we running anything known to be broken? An assessment answers can someone actually do something they should not be able to do?
Most organisations need both, on different schedules. Scan continuously, because it is cheap and things change weekly. Assess occasionally and properly, because the flaws that matter most are the ones no database has a signature for.
Buy the one that answers the question you actually have — and if you are not sure which that is, that is a conversation worth having before a quote, not after.
If you're weighing this up for an Indian organisation, what an engagement costs and how remote testing actually runs is written out in rupees. The free tools here run the scan-shaped checks in a few seconds and cost nothing. If they come back clean, that is genuinely useful information, and I will tell you so rather than finding something else to sell.