Penetration test or vulnerability scan: what you are paying for

One word, two products

Both are sold as security testing, and both end in a document listing weaknesses. That is where the similarity stops. A vulnerability scan is an automated tool comparing what it can observe, versions, banners, responses, open ports, against a database of publicly known issues. A penetration test is a person with an objective and a deadline attacking systems you named, using tools where tools help and judgement everywhere else. Published methodologies such as the OWASP Web Security Testing Guide and NIST SP 800-115 describe the same shape of work.

The difference that matters when you are spending money is what each one can say at the end. A scan tells you which software and configurations look wrong. A test tells you what someone could actually do with your systems on the days it ran. The first is an inventory of possibilities. The second is evidence about your business.

This only becomes a problem when the two are quoted against each other, which happens constantly, because the cheaper number looks like the same work done more efficiently. It is not. If the engagement type itself is still open in your organisation, the case for starting low on the ladder rather than high is set out in why your first engagement probably should not be a full Red Team.

What a scanner is genuinely good at

Breadth and repetition. A scanner will cover ten thousand hosts on a schedule and complain at exactly the same standard on the last one as the first. Missing patches, expired certificates, default credentials, administrative interfaces facing the internet, services exposed that nobody meant to expose: these are real findings, they are the ones attackers use most often, and they are cheap to find this way.

A scanner also catches drift, which is the thing a test structurally cannot. An estate changes every week. A host gets built, a staging environment gets published, a container image gets rebuilt on a base nobody updated. A penetration test is a photograph of a set of systems on a set of days. A scan is the thing that notices next month's mistake.

Where scanning gets dismissed, the cause is usually that nobody triaged the output. An unread scanner is worse than no scanner, because it produces a queue that everybody learns to ignore and a report nobody can defend. The work a scan needs is the work after it runs: deciding which findings are true here, which are reachable, and which matter enough to schedule.

The questions a scanner cannot answer

The first is whether a finding is exploitable in your environment. A scanner infers a problem from a version string or a response. It cannot tell whether the vulnerable function is reachable in your configuration, whether something in front of it blocks the path, or whether the host is a decommissioned box that answers on port 443 and nothing else. Somebody has to make that call, and if the vendor does not, you will.

The second is authorisation and business logic, and this is the category that matters most in applications. Whether a user of one tenant can read another tenant's records. Whether a read-only role reaches a write endpoint. Whether a discount can be applied twice, or a refund issued against an order that was never paid. These behaviours are syntactically correct and wrong by intent, and there is no signature for an application permitting the wrong person to do an allowed thing.

The third is chaining. A username that can be enumerated, an error message that names the framework, an upload that checks the file extension rather than the content, a service account reused on two machines: four low findings in a table, one path to domain administrator in the hands of a person. A scanner grades each finding alone. Real risk lives in the combination, which is why a test report should show you the path rather than only the list.

How to tell which one you are being sold

Ask for a redacted sample report before you compare prices. It settles the question faster than any conversation about methodology. Scanner output is a severity-sorted table with a description, a reference and a remediation paragraph, all of it written before anyone saw your system. A test report has reproduction steps somebody wrote about your application, evidence attached, and an account of what was attempted and did not work.

Then ask three questions. How much of this engagement is manual, and what does the tester do in that time. How are false positives handled, and was every finding confirmed by hand. How many tester days are you selling, and against which assets. A proposal priced per asset with no days behind it has not been mapped to any effort, and a number that was guessed produces coverage that was guessed too.

Price gives the answer away when the other three do not. Manual testing of a mid-sized authenticated web application is measured in tester days, and a quote at a small fraction of that is not the same work done faster. It is a different product with the same word on the cover. What belongs inside the scope, and what to leave out of it, is covered in how to scope a penetration test.

What the money actually buys in each

A scan buys coverage and frequency. Known issues, across the whole estate, repeatedly, at a cost per host low enough that running it monthly is reasonable. It also buys a trend line, which is the part most organisations never use: whether the same class of finding keeps returning tells you something about your build process that no single report can.

A test buys judgement and proof. Days of a person's attention on the systems you named, and a document that says this is what someone could reach, this is how, and this is the evidence. That document is the thing you can hand to a customer, an insurer or an assessor, because it describes your systems rather than a database of everyone's.

Neither proves the absence of a problem, and any vendor implying otherwise should worry you. What a test adds is an honest boundary: it records what was examined, what was excluded and how long was spent, so a reader knows the shape of the assurance. When somebody asks whether the payment path was tested, the scanner ran across the range is not an answer to that question.

Running both, on different clocks

They are not competing line items, and treating them as one is how organisations end up with neither working. Scanning is continuous hygiene, run weekly or monthly, owned by your own team, feeding a patching process. Testing is periodic assurance, bought from outside, at a frequency driven by change: annually as a floor, before a significant release, and after an architecture change that moves a trust boundary.

The sequence between them is worth getting right, because it is free money. Run the scans and fix what they surface before a test starts. Every day a tester spends writing up a missing patch is a day of manual testing you paid for and did not get, and the findings that justify the engagement are the ones no tool was ever going to reach.

Book the retest at the same time as the test, and point the scanner at the same systems afterwards. A fix nobody verified is an assumption written in a spreadsheet, and the two mechanisms verify different halves: the retest confirms the specific finding is closed, the scan confirms the estate did not quietly grow three more instances of the same thing while the fix was in flight.

What this costs you in front of a UAE assessor

In the UAE the distinction usually surfaces during an assessment rather than during the purchase, which is the expensive order to discover it in. Four regimes name security testing. The Central Bank of the UAE binds licensed financial institutions, and its standards for exchange houses are the most explicit anywhere in the UAE rulebook on this exact distinction: clause 14.9.1 requires internal and external vulnerability scanning and penetration tests, annually at a minimum, as two obligations rather than one. DESC binds Dubai government entities and the suppliers who serve them. ADHICS binds Abu Dhabi healthcare providers. The Information Assurance Standards published by NESA cover federal entities. Evidence about the systems that matter satisfies each of them; a document existing does not. We have written separately on what CBUAE actually asks a UAE bank to prove. Where a control asks for penetration testing and receives a severity-sorted table generated by a tool, the substitution is apparent immediately. The finding then lands on your organisation, not on the vendor who sold it.

The practical difference between the two emirates is procurement. Dubai entities and their suppliers tie testing to the DESC control set and name the assets covered, so the scope document travels with the report. Abu Dhabi health sector buyers work to ADHICS control families and usually want the coverage mapped against them before they raise a purchase order. Free zone companies, including those based in Dubai Silicon Oasis, sit outside a sector regulator until a customer contract pulls them in. At that point the customer's regime becomes theirs in practice. All three situations end in the same question: which systems did you test, who tested them, for how long, and what did you leave out on purpose.

Frequently asked questions