Vulnerability assessment and penetration testing get sold as alternatives, quoted as alternatives and budgeted as alternatives. They are not alternatives. They are two different instruments, pointed at two different questions, running on two different clocks — and the UK businesses that get the most out of a security budget are usually the ones that stopped choosing between them and started deciding the order and the ratio instead.
The short version is this. A vulnerability assessment is a broad, repeatable, largely automated sweep that tells you what is known to be wrong across everything you own. A penetration test is a narrow, manual, adversarial exercise that tells you what a skilled human could actually do with what is wrong. The first is a census. The second is a break-in. A census run once a year is useless, and a break-in run every month is unaffordable, which is precisely why the two run on different schedules and why the question “which one do we need?” almost always has the answer “both, in this order, in this ratio”.
This guide answers that properly. It defines each instrument in the terms the National Cyber Security Centre actually uses, sets out the five differences that decide the buying order, maps what each one finds and misses, prices both against 2026 UK market rates, and then costs one 60-person business four different ways so you can see the trade-off in pounds.
If price is your immediate question, our companion guide to penetration testing cost UK covers day rates and scoping in detail, and what a cyber security audit costs prices the five separate products UK firms buy under that one phrase. Every figure below is a published rate, a government statistic, or arithmetic performed on numbers stated in this article.
Table of contents
- Vulnerability assessment vs penetration testing: the one-minute answer
- What a vulnerability assessment actually is
- What a penetration test actually is
- Vulnerability assessment and penetration testing: the five real differences
- What a vulnerability assessment finds, and what only a test will
- The vulnerability assessment toolchain: scans, scanners and scope
- Severity is not risk: reading a vulnerability assessment report
- Fixing what the vulnerability assessment found
- How often to run a vulnerability assessment, and how often to test
- What compliance demands: where a vulnerability assessment is enough
- What the two instruments cost in the UK in 2026
- A worked twelve-month vulnerability assessment and testing programme
- When a vulnerability assessment is the wrong buy
- When a penetration test is the wrong buy
- How to tell a real test from a vulnerability assessment in disguise
- Buying a vulnerability assessment well: scoping, questions and evidence
- Running the vulnerability assessment in-house versus buying it
- Vulnerability assessment vs penetration testing: the decision table
- Mistakes that waste a vulnerability assessment budget
- Frequently asked questions about vulnerability assessment and penetration testing
- References and Further Reading
Vulnerability assessment vs penetration testing: the one-minute answer
If you read nothing else, read this section. Most buying mistakes in this market come from a single confusion: treating a vulnerability assessment as a cheap penetration test, or treating a penetration test as a thorough vulnerability assessment. Neither substitution works, because the two are measuring different things.
The one-sentence definition of each
A vulnerability assessment identifies and catalogues known weaknesses across a defined estate, usually with automated tooling and a human reviewing the output. A penetration test attempts to exploit weaknesses in a defined target, by hand, to establish what an attacker could achieve.
The question each one answers
A vulnerability assessment answers “what is wrong out there, and how much of it is there?” A penetration test answers “if somebody competent attacked this, how far would they get?” You cannot get the first answer from the second, because a test covers a fraction of the estate. You cannot get the second answer from the first, because a scanner does not chain findings together the way a person does.
The clock each one runs on
The NCSC’s own scanning guidance says you should aim to run scans of your infrastructure “on a regular basis (at least once every month)”. Its penetration testing guidance, by contrast, describes tests as periodic assurance exercises, and notes that the gaps between them are “often a year or more”. A vulnerability assessment is therefore a continuous discipline. A penetration test is an event.
The relationship the NCSC actually describes
This is the line that settles most arguments. The NCSC states that penetration testing “should be viewed as a method for gaining assurance in your organisation’s vulnerability assessment and management processes, not as a primary method for identifying vulnerabilities”. In other words, the test is not there to find your bugs. It is there to check whether your own vulnerability assessment process is finding them. That sequencing is the whole answer to “which does my business need first”.
The two instruments, side by side
| Dimension | Vulnerability assessment | Penetration test |
|---|---|---|
| Core method | Automated detection, human review | Manual exploitation by a tester |
| Primary goal | Coverage — find everything known | Assurance — prove what is reachable |
| Shape of the answer | A ranked list of findings | A narrative of attack paths |
| Breadth | Whole estate, every host | A named, bounded target |
| Depth | Surface, signature-driven | Deep, chained, context-aware |
| Typical cadence | Monthly, or continuous | Annually, or after major change |
| False positives | Common — triage is part of the job | Rare — findings are demonstrated |
| Business logic flaws | Almost never found | A core part of the work |
| Chained attack paths | Not modelled at all | The main deliverable |
| Skill to run | Configuration and triage skill | Specialist offensive skill |
| Skill to interpret | High — the raw output misleads | Moderate — the report explains itself |
| Typical UK price | £500–£3,500 per cycle | £2,500–£25,000+ per engagement |
| Cost driver | Number of assets and cycles | Consultant days |
| What it proves | That you know your exposure | That your defences hold, or do not |
| What it misses | Anything without a signature | Everything outside the scope |
| Buy it first when | You do not know what you own | You already fixed the known list |
If you only have budget for one
Buy the vulnerability assessment, and buy it as a repeating programme rather than a one-off report. A single penetration test on an estate that has never been scanned will spend its first two days re-finding missing patches you could have found for a fraction of the money, and you will pay a specialist day rate for the privilege. Get the known list down first. Then buy the test that tells you whether the list was the right list.
What a vulnerability assessment actually is
The phrase gets used loosely enough that two providers can quote wildly different work under it, so it is worth being precise about what a vulnerability assessment includes, what runs underneath it, and where the human effort sits.
The NCSC definition
The NCSC describes vulnerability scanning as “the automated process of detecting defects in an organisation’s security program”. A vulnerability assessment is that automated process plus the part that makes it useful: scoping, credentialed access, triage, prioritisation and a report a human can act on. The scan is the engine. The vulnerability assessment is the vehicle.
The four stages of a vulnerability assessment
Every credible vulnerability assessment runs the same four stages. Discovery establishes what exists and what is reachable. Detection runs the checks against each asset. Triage separates the real findings from the noise and ranks what is left. Reporting turns that into an ordered set of actions with owners and deadlines attached.
What the scanner is actually doing
Infrastructure scanners look for missing operating system or software application patches, use of default or weak passwords, and weak cryptography or clear text services. Web application scanners look for injections from malicious user input, broken authentication, and use of vulnerable third-party components. In both cases the scanner is matching observed conditions against a database of known issues.
Why a vulnerability assessment is only as good as its inventory
A scanner cannot examine an asset it was never pointed at. This is the single most common failure in a vulnerability assessment programme: the scope is drawn from an out-of-date asset register, so the forgotten test server, the shadow SaaS subscription and the branch office printer are all invisible. Discovery scanning across your full address space, rather than a list somebody typed, is what turns a partial vulnerability assessment into a real one.
Authenticated versus unauthenticated scanning
An unauthenticated scan looks at a host the way an anonymous internet user would. An authenticated, or credentialed, scan logs in and inspects installed software versions, registry state and configuration directly. The NCSC’s buying guidance explicitly asks whether a scanner “can support authenticated checks. For example, is it able to log into Windows hosts?” The difference in yield is enormous — an unauthenticated vulnerability assessment sees a fraction of what a credentialed one does, and it is the reason PCI DSS v4.0.1 now requires internal scans to be authenticated.
The five kinds of scan a full vulnerability assessment includes
| Scan type | Vantage point | What it is good at | Blind spot |
|---|---|---|---|
| External unauthenticated | Public internet | Exposed services, expired certificates, open ports | Anything behind authentication |
| Internal authenticated | Inside the network, with credentials | Patch level, configuration, local privilege issues | Assets the credentials do not reach |
| Web application | Against the application itself | Injection, weak session handling, stale components | Multi-step business logic |
| Cloud configuration | Provider control plane, via API | Public buckets, over-broad roles, missing logging | Workload-level flaws inside instances |
| Container and image | Registry and build pipeline | Vulnerable base images and libraries | Runtime behaviour after deployment |
Where the human effort really goes
Buyers assume the tool is the expensive part of a vulnerability assessment. It is not. Running the scan is minutes of machine time; deciding which of the four hundred findings matter to this business, this quarter, is hours of skilled judgement. A vulnerability assessment priced purely on the number of IP addresses, with no triage line, is selling you the engine without the vehicle.
What a penetration test actually is
The matching definition matters just as much, because the word “test” is doing a lot of work in a market where plenty of things get called one.
The NCSC definition
The NCSC defines penetration testing as “a method for gaining assurance in the security of an IT system by attempting to breach some or all of that system’s security, using the same tools and techniques as an adversary might”. Two words carry the weight: assurance and attempting. You are buying evidence about your defences, produced by somebody genuinely trying to get through them.
The audit analogy the NCSC uses
The NCSC compares a penetration test to a financial audit: “Your finance team tracks expenditure and income day to day. An audit by an external group ensures that your internal team’s processes are sufficient.” Your day-to-day tracking, in this analogy, is the vulnerability assessment programme. The test is the external check on it.
What a tester does that a scanner cannot
A tester chains findings. A low-severity information disclosure plus a default credential plus an over-permissive file share is three separate, individually unremarkable entries on a vulnerability assessment report — and one clean path to your finance system in the hands of a person. Scanners do not reason about sequences. That reasoning is the product you are buying.
The kinds of test and what the UK market charges
| Test type | Typical days | Published UK band | What it establishes |
|---|---|---|---|
| External network | 3–5 | £3,000–£6,000 | Whether the perimeter can be crossed |
| Web application | 2–5 | £2,500–£8,000 | Whether the app’s logic and access control hold |
| Internal network | 5–8 | £5,000–£12,000 | How far a foothold spreads |
| Cloud assessment | 3–6 | £4,000–£10,000 | Whether identity and configuration contain a breach |
| Full security assessment | 10–20 | £12,500–£25,000+ | Everything above, as one narrative |
What a penetration test is not
It is not remediation, it is not monitoring, and it is not a substitute for knowing your own estate. The NCSC is blunt that a test is “not a magic bullet”, that it validates the state of a system only at the time of testing, and that “risk assessment and decisions on the application of fixes are your responsibility”. A test that finds nothing is not proof you are secure; it is proof that this tester, in these days, against this scope, did not get through.
The ideal a test is supposed to confirm
The most useful sentence in the NCSC’s penetration testing guidance is the one that describes what success looks like before the test starts: “In an ideal world, you should know what the penetration testers are going to find, before they find it.” If a test’s findings surprise you, the surprise is the real result — it means the vulnerability assessment process feeding it is not working.
Vulnerability assessment and penetration testing: the five real differences
Marketing pages list a dozen differences. Only five of them change what you should buy, and all five follow from one root cause: automation scales across breadth, and humans scale into depth.
Difference one: coverage against depth
A vulnerability assessment is designed to look at everything once a month. A penetration test is designed to look at one thing exhaustively once a year. The NCSC’s guidance on scanning tools puts it plainly — automated scanning “cannot compare to manual processes such as penetration testing when it comes to the breadth and depth of test coverage” on a given target, because scanners “aim for breadth instead of depth” and “generally lack the ability to navigate web applications or detect vulnerabilities that require complicated interactions”.
Difference two: known against unknown
A vulnerability assessment finds what is already documented somewhere as a defect: a CVE, a weak cipher, a default account. A penetration test finds what nobody has written down, because it is specific to how your application, your permissions and your processes fit together. If the flaw has no signature, only a person will see it.
Difference three: a list against a story
The output of a vulnerability assessment is a ranked inventory. The output of a test is a narrative: here is where I started, here is what I used, here is what I reached. Boards act on narratives and ignore inventories, which is one reason a test often unlocks remediation budget that a year of vulnerability assessment reports could not.
Difference four: repeatability against realism
A vulnerability assessment gives you a number you can trend. Run it monthly and you can watch your open-finding count fall, your mean time to remediate shrink and your exposure window close. A test gives you realism but no trend line, because the next test has a different tester, a different scope and a different set of tools.
Difference five: what each one costs to repeat
Repeating a vulnerability assessment costs very little — the tooling is already licensed and the scope is already defined. Repeating a penetration test costs almost exactly what the first one cost, because you are buying human days again. That single asymmetry explains why the sensible programme runs one continuously and the other periodically.
The five differences in one table
| Difference | Vulnerability assessment | Penetration test | What it means for the buyer |
|---|---|---|---|
| Coverage vs depth | Everything, shallowly | One thing, exhaustively | Scope the test, sweep with the assessment |
| Known vs unknown | Documented defects | Situation-specific flaws | Custom software needs a human |
| List vs story | Ranked findings | Attack narrative | Use the test to move the board |
| Repeatable vs realistic | Trendable metrics | Point-in-time realism | Metrics come from the assessment |
| Cost to repeat | Marginal | Full price again | Run one monthly, one annually |
Why the difference is not “automated versus manual”
That shorthand is wrong in both directions. Good testers use automation heavily during reconnaissance, and a serious vulnerability assessment involves real human triage. The honest distinction is intent: an assessment is trying to enumerate, a test is trying to succeed.
What a vulnerability assessment finds, and what only a test will
The fastest way to settle an internal argument about which to buy is to walk through concrete findings and ask which instrument would have surfaced each one.
Ten findings and which instrument surfaces them
| Finding | Vulnerability assessment | Penetration test |
|---|---|---|
| Unpatched VPN appliance with a public CVE | Yes, reliably | Yes |
| Expired or weak TLS configuration | Yes, reliably | Yes, incidentally |
| Default credentials on a network printer | Yes, if in scope | Yes, and then used |
| Publicly readable cloud storage bucket | Yes, with a configuration scan | Yes |
| A user able to view another customer’s order | Almost never | Yes — core work |
| Discount logic that accepts a negative quantity | No | Yes |
| Password reset that leaks account existence | Sometimes | Yes |
| Three low findings that combine into domain admin | Lists all three, connects none | Yes — the headline |
| A forgotten server nobody knew existed | Yes, with discovery scanning | Only if in scope |
| Helpdesk resetting MFA without identity checks | No | Yes, in a scoped social engineering test |
The pattern in that table
Everything in the top half has a signature. Everything in the bottom half requires somebody to understand what the system is for. That is the buying rule in one line: signature-shaped problems go to the vulnerability assessment, meaning-shaped problems go to a tester.
The finding neither instrument gives you
Neither is threat intelligence, and neither is monitoring. A vulnerability assessment tells you about your own estate, not about who is currently interested in it, and a penetration test tells you about one week in the year. Detection and response are a third budget line, and treating either instrument as a substitute for them is the most expensive misunderstanding in small-business cybersecurity spending.
Why the volume argument favours the assessment
There is simply too much known badness to handle by hand. FIRST’s mid-year forecast, published in June 2026, projects roughly 66,000 CVE records for 2026, up from 48,185 published in 2025 and 40,009 in 2024. No human process reviews that volume; only a vulnerability assessment pipeline can, which is exactly why the assessment is the base layer and the test sits on top of it.
Published CVE records, three years
The counterweight: volume is not risk
The same FIRST release notes that “actionable exploitability remains flat” once the raw volume is filtered for real-world risk, and records the CISA Known Exploited Vulnerabilities catalogue at 1,587 entries as of 1 May 2026. That is the number that should drive your remediation queue. A vulnerability assessment that ranks purely on raw counts will bury the fifteen findings that matter under four hundred that do not.
The vulnerability assessment toolchain: scans, scanners and scope
Once you decide to run a vulnerability assessment programme rather than buy a one-off report, the practical questions become tooling, scope and who operates it.
The three families of tooling
Infrastructure scanners examine hosts, services and network devices. Application scanners examine web and API surfaces. Cloud posture tools examine the provider control plane through its API. Most UK SMEs need the first two; anyone with a significant cloud footprint needs all three, because a configuration error in the control plane is invisible to a network scan.
What “agent-based” changes
Agent-based scanning installs a small client on each endpoint and reports continuously, rather than reaching across the network on a schedule. For a workforce that is mostly remote, an agent-based vulnerability assessment is often the only way to reach laptops at all, since a scheduled internal scan simply misses every device that is not on the office network that night.
Scoping a vulnerability assessment properly
Scope by address space, not by asset list. Give the scanner every internal subnet and every public range you are allocated, then let discovery tell you what is really there. Scoping from a spreadsheet guarantees you find only what the spreadsheet already knew, which defeats the point of the exercise.
The credential problem, and why it is worth solving
Credentialed scanning needs a service account with enough rights to read configuration on every target. Security teams resist creating it, and as a result many organisations run years of unauthenticated scans and believe they have a vulnerability assessment programme. They have a port scan with a report attached. Solve the credential problem once and the yield of every subsequent cycle roughly transforms.
Frequency, and what NCSC actually recommends
The NCSC’s position is unambiguous: “You should aim to perform vulnerability scans of your infrastructure on a regular basis (at least once every month).” Monthly is the floor, not the target. For internet-facing estate, weekly or continuous scanning is now normal, because exposure windows on public services are measured in days.
False positives are a workload, not a defect
The NCSC’s own vendor questions include whether a scanner “often produce[s] false positives… or false negatives”. Both happen. Budget for triage explicitly: a vulnerability assessment that hands you nine hundred unreviewed findings has transferred the work to you rather than doing it. Ask any provider what proportion of raw findings they expect to close as false positives, and how that triage is priced.
Severity is not risk: reading a vulnerability assessment report
The most common way a good vulnerability assessment gets wasted is straightforward — the organisation treats the severity column as a work queue.
What CVSS is, and what it is for
The Common Vulnerability Scoring System, maintained by FIRST, scores the technical severity of a vulnerability. Version 4.0 splits its metrics into four groups: Base, Threat, Environmental and Supplemental. The nomenclature matters when you read a report — CVSS-B is base metrics only, CVSS-BT adds threat, CVSS-BE adds environmental, and CVSS-BTE uses all three.
The severity bands
| Rating | CVSS v4.0 score | What it should trigger |
|---|---|---|
| Critical | 9.0–10.0 | Emergency change, same week |
| High | 7.0–8.9 | Scheduled change, within the standard window |
| Medium | 4.0–6.9 | Next maintenance cycle |
| Low | 0.1–3.9 | Fix opportunistically |
| None | 0.0 | Record and move on |
Why the score alone is the wrong queue
The NCSC’s triage guidance is explicit that although a vulnerability assessment tool or vendor advisory may give a severity rating such as CVSS, “it’s essential that you consider business impact and risk for your organisation”. A 9.8 on an isolated lab box that holds nothing matters less than a 6.4 on the payment path. Severity is an input to prioritisation, not prioritisation itself.
The three multipliers that turn severity into priority
Exposure comes first: the NCSC says to prioritise vulnerabilities “in services or applications that are internet facing”. Exploitation comes second — is this one being used in the wild right now? Impact comes third: what does this asset actually do for the business? A vulnerability assessment that reports all three columns is worth several times one that reports severity alone.
Using exploitation data properly
The KEV catalogue and exploit prediction scoring exist precisely because the CVSS number does not know what attackers are doing this month. Feed both into your triage. A medium-severity finding that appears on a known-exploited list outranks a critical that has never had a working exploit written for it.
What a good report looks like
A usable vulnerability assessment report opens with a page the finance director can read, carries an evidence appendix an engineer can act on without asking questions, states clearly which assets were and were not reachable, and separates confirmed findings from potential ones. If the deliverable is a raw tool export with a cover page, you bought a scan, not a vulnerability assessment.
Fixing what the vulnerability assessment found
A finding is not a fix, and the gap between the two is where most security budgets quietly leak. This is also the stage at which the two instruments stop competing and start reinforcing each other.
The NCSC best-practice update timescales
The NCSC publishes explicit timescales for applying updates, and they are the cleanest remediation targets a UK business can adopt without inventing its own.
| Category | Timeframe | NCSC note |
|---|---|---|
| Internet-facing services and software | 5 days | Install on test environment or backup first, then test and roll out |
| Operating system and applications | 7 days | Should be applied automatically, as soon as an update is published |
| Internal or air-gapped service and software | 14 days | Install on test environment or backup first, then test and roll out |
The timescales, plotted
Why the internet-facing window is the shortest
Because the exposure is continuous and anonymous. The NCSC advises reducing the window “to as small a window as possible” when a vulnerability is under active exploitation, particularly on internet-facing systems. Your monthly vulnerability assessment cycle is what tells you whether you are hitting these numbers; without it, the policy is aspiration.
Turning findings into owned actions
Every finding needs four attributes before it leaves the report: an owner, a deadline derived from the table above, a decision (fix, mitigate or accept) and a review date if it was accepted. A vulnerability assessment programme with no accepted-risk register accumulates a permanent tail of medium findings that nobody has actually decided about.
Retesting, and who pays for it
Retest is the step buyers most often cut and most often regret. On the assessment side, the next monthly cycle is the retest and costs nothing extra — one of the quiet advantages of running a vulnerability assessment as a programme. On the test side, retest is chargeable time. Agree in the contract whether a retest of the specific findings is included, and for how long after the original engagement.
Remediation service levels worth adopting
| Severity | Internet-facing | Internal | Evidence required |
|---|---|---|---|
| Critical, known exploited | Immediate, out of hours if needed | 48 hours | Clean rescan plus change record |
| Critical | 5 days | 14 days | Clean rescan |
| High | 5 days | 14 days | Clean rescan |
| Medium | Next monthly cycle | Next maintenance window | Next scheduled scan |
| Low | Opportunistic | Opportunistic | Tracked only |
The metric that proves the programme works
Count the number of findings older than their service level, every month, and report that single number. It is the only vulnerability assessment metric that survives contact with a board, because it measures your process rather than the internet’s supply of new CVEs.
How often to run a vulnerability assessment, and how often to test
Cadence is where the two instruments separate most clearly, and where most published advice is vague enough to be useless.
The assessment cadence
Monthly is the NCSC’s stated floor for infrastructure. In practice, run external scanning weekly or continuously, internal authenticated scanning monthly, web application scanning monthly or on every significant release, and cloud configuration scanning continuously through the provider API. The marginal cost of an extra cycle is close to zero once the programme exists.
The trigger-based scans that matter more than the calendar
Run an unscheduled vulnerability assessment after any change that alters your attack surface: a new public service, a firewall rule change, a merger, an office move, a major software upgrade, or a vendor advisory about something you run. Calendar-driven scanning alone leaves an exposure window exactly as long as your interval.
The testing cadence
Annually is the baseline for most UK SMEs, plus a test after any significant change to the tested system. That is also what the regulated frameworks converge on, which is not a coincidence — twelve months is roughly the point at which a system has drifted far enough that last year’s assurance no longer describes it.
Why annual testing alone leaves a gap the NCSC names
The NCSC observes that the gaps between penetration tests are “often a year or more” and that a test validates known issues only at the time of the test. That gap is not a criticism of testing; it is a description of the space that a monthly vulnerability assessment is supposed to fill. Buying only the test leaves the gap open by design.
What the UK market actually does
The government’s Cyber Security Breaches Survey shows how thin this market really is. Among UK businesses, 30% carry out a risk assessment, 22% run mock phishing exercises, 18% carry out a vulnerability audit and only 13% commission penetration testing, with 11% using threat intelligence. Among those doing a vulnerability audit, 39% of businesses used external auditors only.
Assurance activity across UK businesses
What that distribution tells a buyer
Assessment-type activity is roughly 40% more common than testing, and both are minority behaviours. If you run a monthly vulnerability assessment programme and an annual test, you are already ahead of roughly nine in ten UK businesses — which is worth knowing when a customer questionnaire asks what you do.
What compliance demands: where a vulnerability assessment is enough
Regulatory drivers are the most common reason a UK business buys either instrument, so it is worth being exact about which frameworks require which.
Cyber Essentials
Cyber Essentials covers five technical control areas: firewalls, secure configuration, security update management, user access control and malware protection. It does not require a penetration test. It does effectively require the outcome a vulnerability assessment delivers — knowing that your software is patched and supported — which is why so many firms fail their first attempt on unpatched or unsupported software they did not know they were running.
Cyber Essentials Plus
Plus adds independent hands-on verification by an assessor, which is a technical audit rather than a penetration test. Certification-body pricing runs to IASME bands of roughly £1,399, £1,699, £2,399 and £3,499 plus VAT for micro, small, medium and large organisations, with the base certificate starting from £320 plus VAT. Running a vulnerability assessment before the assessor arrives is the cheapest possible insurance against a failed Plus attempt.
PCI DSS: the clearest split in any framework
PCI DSS v4.0.1 separates the two instruments into two different requirements, which makes it the best worked example of the distinction. Requirement 11.3 covers scanning; requirement 11.4 covers penetration testing. You must do both, and doing one does not satisfy the other.
The PCI DSS mapping in detail
| Requirement | What it demands | Frequency | Who may perform it |
|---|---|---|---|
| 11.3.1 | Internal vulnerability scans | At least once every three months, and after significant change | Qualified internal or external resource |
| 11.3.1.2 | Internal scans must be authenticated | Every internal scan cycle | Qualified internal or external resource |
| 11.3.2 | External vulnerability scans with a passing result | At least once every three months | A PCI SSC Approved Scanning Vendor |
| 11.4.2 / 11.4.3 | Internal and external penetration testing | At least every 12 months, and after significant change | A qualified, organisationally independent tester |
| 11.4.4 | Remediate findings and retest | After each test | The organisation, verified by retest |
| 11.4.5 / 11.4.6 | Segmentation control testing | Annually for merchants, every six months for service providers | A qualified tester |
ISO 27001
ISO 27001 names neither instrument as a mandatory activity, but a certification auditor will expect a technical vulnerability management process with evidence behind it. In practice that means a documented vulnerability assessment cycle, records of triage decisions, and evidence of remediation within stated timescales. Testing is expected for internet-facing or high-risk systems and is very hard to argue your way out of.
The Cyber Assessment Framework and NIS-regulated operators
The CAF expects both discovery of vulnerabilities and independent validation of defences, expressed as outcomes rather than as prescribed products. Regulated operators generally end up with continuous scanning plus periodic independent testing, because nothing else produces the evidence the outcomes ask for.
DORA and the financial sector
For identified financial entities, DORA articles 26 and 27 require threat-led penetration testing at least every three years, delivered through the TIBER-EU framework, against live production systems. Staged environments and automated scans do not qualify. Everything below that threshold still needs the ordinary vulnerability assessment and testing programme underneath it.
Public sector and CHECK
For central government systems at OFFICIAL or above, testing must be carried out by an NCSC CHECK service provider. The NCSC is explicit about the boundary of that rule: “If your organisation is not public sector, penetration testing does not need to be conducted by a CHECK service provider.” Most UK SMEs are therefore free to choose a CREST-accredited firm instead.
The compliance summary in one table
| Framework | Vulnerability assessment | Penetration test |
|---|---|---|
| Cyber Essentials | Effectively required by outcome | Not required |
| Cyber Essentials Plus | Strongly advisable before assessment | Not required |
| PCI DSS v4.0.1 | Required, quarterly, authenticated internally | Required, at least annually |
| ISO 27001 | Expected as documented process | Expected for exposed systems |
| Cyber Assessment Framework | Expected as an outcome | Expected as independent validation |
| DORA (in scope entities) | Assumed as baseline | Threat-led, at least every three years |
| Customer security questionnaires | Usually asked about | Increasingly asked about |
What the two instruments cost in the UK in 2026
Price is where the difference becomes obvious, because the two are priced on completely different units. A vulnerability assessment is priced on assets and cycles. A test is priced on human days.
The day-rate reality
The fair market rate for thorough manual testing in the UK sits at around £1,200 per day, with a credible range of £1,000 to £1,500. Junior or offshore capacity runs lower. The line that matters most to a buyer is the floor: below roughly £500 per day, you are almost certainly getting an automated scan, not a manual test. Our full breakdown of penetration testing cost in the UK works through how those days are counted.
What a day of testing costs
What a vulnerability assessment costs
A standalone automated vulnerability assessment typically lands between £500 and £2,000 depending on the size of the estate. A fuller managed vulnerability assessment for a 20-person office, with triage and a written report, runs closer to £2,000 to £3,500. Where a provider quotes a monthly programme rather than a one-off, expect the per-cycle figure to fall sharply after the first cycle, because scoping and credentialing are one-time costs.
Why the two price shapes matter more than the two prices
A vulnerability assessment is a fixed-cost, low-marginal-cost service, so adding cycles is cheap and adding assets is fairly cheap. Testing is pure variable cost: every extra day is another full day rate. This is why scope discipline saves so much more money on the test side, and why frequency is nearly free on the assessment side.
The price comparison in one table
| Purchase | Unit of pricing | Typical UK figure | Cost of one more cycle |
|---|---|---|---|
| Automated scan, one-off | Estate size | £500–£2,000 | Low |
| Managed vulnerability assessment | Assets plus triage hours | £2,000–£3,500 | Low after first cycle |
| External network test | Consultant days | £3,000–£6,000 | Full price again |
| Web application test | Consultant days | £2,500–£8,000 | Full price again |
| Internal network test | Consultant days | £5,000–£12,000 | Full price again |
| Full security assessment | Consultant days | £12,500–£25,000+ | Full price again |
The retest line nobody budgets for
Assume one chargeable retest day per test engagement at the same rate. On a £1,200 day rate that is £1,200 you should put in the budget rather than discover later, and it is the difference between a report that closes and a report that sits open for a year.
A worked twelve-month vulnerability assessment and testing programme
Abstract ranges are hard to budget against, so here is one business, costed four different ways. Every figure below uses rates already stated in this article.
The business
A 60-person UK e-commerce and logistics company across two sites, a head office and a warehouse. It runs 148 endpoints and 12 servers, of which two are on-premises and ten sit in a single cloud account. It holds 38 public IP addresses across three ranges, operates one customer-facing web application with 34 endpoints and three user roles, runs a Microsoft 365 tenant with 60 licences, and sits in PCI DSS scope through its online checkout. Four VLANs separate office, warehouse, guest and card-handling traffic.
The arithmetic that drives everything below
The estate is 160 hosts, so a monthly authenticated internal vulnerability assessment cycle examines 160 × 12 = 1,920 host-checks a year. The external scan covers 38 addresses monthly, or 38 × 12 = 456 address-checks a year. Together the programme performs 2,376 examinations a year. A three-day external test examines those same 38 addresses once. A four-day web application test examines 34 endpoints across three roles, or 102 role-and-endpoint combinations, once.
Option A: vulnerability assessment only
Twelve monthly cycles at the £500 automated floor gives £6,000 a year, covering all 2,376 examinations. It buys complete coverage, monthly trend data and a defensible answer to most customer questionnaires. It buys no proof that the defences hold, and it will not find a single business logic flaw in the checkout.
Option B: penetration testing only
A four-day external test at £1,200 is £4,800, a four-day web application test is another £4,800, and one retest day is £1,200, giving £10,800 a year. It buys nine days of expert attention and a report a board will read. For the other 356 days the business has no current view of its own patch state at all.
Option C: the balanced programme
Twelve scan cycles at £6,000, plus a three-day external test at £3,600, plus a four-day web application test at £4,800, plus one retest day at £1,200, gives £15,600 a year. This is the shape most 60-person UK businesses should be buying, and it satisfies both halves of the PCI DSS split.
Option D: depth-first, for regulated or post-incident situations
Option C’s scanning at £6,000, plus a six-day internal network test at £7,200, plus a three-day external test at £3,600, plus a four-day web application test at £4,800, plus a three-day cloud assessment at £3,600, plus two retest days at £2,400, gives £27,600 a year. This is the right shape after a breach, before a major certification, or when a contract demands it.
The four options side by side
| Option | Line items | Annual total | What it leaves uncovered |
|---|---|---|---|
| A — assessment only | 12 × £500 | £6,000 | Logic flaws, chained paths, proof |
| B — testing only | 4 + 4 + 1 days at £1,200 | £10,800 | 356 days of unmonitored patch drift |
| C — balanced | £6,000 + 3 + 4 + 1 days | £15,600 | Internal network depth, cloud depth |
| D — depth-first | £6,000 + 6 + 3 + 4 + 3 + 2 days | £27,600 | Very little, at 4.6× option A |
The four options, plotted
Where option C’s money actually goes
The unit economics, which settle the argument
Divide each line by what it examines. The scanning programme costs £6,000 for 2,376 examinations, or £2.53 per examination. The external test costs £3,600 for 38 addresses, or £94.74 per address. The web application test costs £4,800 for 102 role-and-endpoint combinations, or £47.06 each. Depth costs roughly 37 times more per asset examined than breadth does — which is the whole argument for using each instrument for what it is good at.
Cost per examination, plotted
The twelve-month calendar this implies
| Month | Assessment activity | Testing activity | Spend |
|---|---|---|---|
| 1 | Discovery, credentialing, first full cycle | — | £500 |
| 2–3 | Monthly cycles, remediate the critical backlog | — | £1,000 |
| 4 | Monthly cycle, confirm clean external result | External network test, 3 days | £4,100 |
| 5 | Monthly cycle plus targeted rescans | Remediation of test findings | £500 |
| 6 | Monthly cycle | Retest day | £1,700 |
| 7–9 | Monthly cycles, application scanning on each release | — | £1,500 |
| 10 | Monthly cycle | Web application test, 4 days | £5,300 |
| 11–12 | Monthly cycles, annual trend report | Remediation and evidence pack | £1,000 |
Why the external test lands in month four, not month one
Because months one to three are spent clearing the known list. Running the test first would have spent expert days rediscovering unpatched software that £500 of scanning finds automatically. Ordering the programme this way is the single largest saving available to a first-time buyer, and it follows directly from the NCSC’s advice that you should know what the testers will find before they find it.
When a vulnerability assessment is the wrong buy
The instrument is cheap, broad and useful, which makes it easy to over-apply. There are situations where more scanning is simply the wrong answer.
When you already know the list and have not fixed it
If your last vulnerability assessment produced 340 findings and 300 are still open, another cycle produces 340 findings again. The constraint is remediation capacity, not detection. Spend the money on engineering time, not another report.
When the risk lives in business logic
An online booking system that lets a customer change a price parameter, a portal that shows one client another client’s documents, an approval workflow that can be skipped — none of these have a CVE. A vulnerability assessment will return a clean result on a system with all three, which is exactly the false comfort that makes a test necessary.
When you need evidence for a specific customer or regulator
A customer contract that says “annual independent penetration test” is not satisfied by a scan report, however thorough. Buying more assessment cycles because they are cheaper simply delays the conversation.
When the estate is tiny and static
A five-person firm with laptops, a Microsoft 365 tenant and no servers gains less from a paid vulnerability assessment programme than from turning on automatic updates, enabling multi-factor authentication and certifying to Cyber Essentials. Match the instrument to the surface area.
When it becomes a substitute for ownership
The failure mode here is subtle: a monthly vulnerability assessment arrives, nobody owns the actions, and the report itself becomes the deliverable. A programme that generates reports nobody acts on has converted a security control into an administrative habit.
When a penetration test is the wrong buy
The reverse error is more expensive per pound, because you are buying specialist days.
When you have never scanned anything
This is the classic waste. Testers spend the first days of the engagement enumerating exactly what a vulnerability assessment would have listed for a fraction of the cost, then run out of time before reaching the interesting work. You paid a specialist rate for automatable output.
When the scope is drawn to fit the budget rather than the risk
A two-day test on a system that needs five days does not give you 40% of the assurance. It gives you a report that says “no critical findings within the time available”, which is worse than no report at all because it will be quoted back at you in a questionnaire.
When there is no capacity to fix what comes back
A test that lands a fortnight before year end, with no change window and no engineering time reserved, produces a document that ages badly. Book the remediation capacity at the same time as the test, or move the test.
When it is bought for a certificate rather than an answer
Some buyers want the PDF for a supplier pack. That is a legitimate commercial motive, but say so out loud, because it changes the right scope, the right depth and the right price — and it usually means a narrower engagement than a genuine assurance exercise.
When the environment changes weekly
Testing a platform that ships twice a week gives you assurance about a build that no longer exists. Continuous vulnerability assessment plus targeted testing of major releases fits that reality far better than an annual set-piece.
How to tell a real test from a vulnerability assessment in disguise
The most common mis-sale in the UK market is an automated scan invoiced as a penetration test. It is easy to detect if you know what to look for.
The price tells you first
Work out the implied day rate. If a “penetration test” of a whole estate is quoted at £900 all in, no human days are in that number. Below roughly £500 per day you are buying automation with a covering letter.
The report tells you second
A real test report contains reproduction steps, evidence, and a narrative of how findings connect. A vulnerability assessment export contains a plugin identifier, a CVSS score and generic vendor remediation text. Both are useful documents. Only one of them is a test.
The questions they ask before starting tell you third
A tester asks about user roles, business-critical transactions, what would hurt most, and which systems are off limits. A scanning provider asks for IP ranges and credentials. If nobody asks what your application is for, nobody is going to test its logic.
The people tell you fourth
Ask who is doing the work, what their certifications are, and whether they hold CREST or Cyber Scheme qualifications. Ask whether the same person writes the report. On a genuine engagement these questions have specific, confident answers.
Red flags in a quote
| What you see | What it usually means | What to ask |
|---|---|---|
| No day count in the proposal | The work is automated or undefined | How many consultant days, and by whom? |
| Unlimited IP addresses, fixed price | A scan, priced as a subscription | Is any manual exploitation included? |
| Instant turnaround | No triage, no manual verification | How long is the reporting phase? |
| Sample report is a tool export | A vulnerability assessment in disguise | Can I see a redacted narrative report? |
| Retest quoted separately, undefined | The closure step will cost more later | Is retest included, and for how long? |
| No named tester or qualifications | Work may be subcontracted | Who performs it and what do they hold? |
The one question that separates them cleanly
Ask: “will you attempt to exploit what you find, and will the report show me how far you got?” A vulnerability assessment provider will say no, correctly and without embarrassment. A testing provider will say yes and explain the rules of engagement. Anyone who is vague is selling one and charging for the other.
Buying a vulnerability assessment well: scoping, questions and evidence
Getting good value from the cheaper instrument is mostly about scoping and about what you demand in the deliverable.
Scope every address you own, not every asset you remember
State your full internal ranges and every public range allocated to you. Ask the provider to report on assets discovered that were not on your list — that delta is often the single most valuable output of a first vulnerability assessment.
Insist on credentialed scanning from cycle one
Unauthenticated results understate your patch position substantially. If credentials cannot be provided immediately, agree a date and treat the first cycles as provisional rather than as a baseline.
Ask for the triage split
A good provider will tell you what proportion of raw findings they expect to confirm. Getting this in writing turns “we found 900 issues” into “we confirmed 140 and closed 760 as not applicable”, which is a completely different conversation with your engineering team.
Twelve questions worth asking any vulnerability assessment provider
| Question | What a good answer sounds like |
|---|---|
| Is scanning authenticated? | Yes, on all in-scope hosts, with a named service account |
| How is discovery performed? | Across supplied ranges, not from your asset list alone |
| Who triages the output? | A named analyst, with a stated confirmation rate |
| Does prioritisation use exploitation data? | Yes — known-exploited lists feed the ranking |
| How are cloud accounts covered? | Through provider APIs, as configuration checks |
| How are remote laptops covered? | Agent-based, reporting independently of the office network |
| What is the cycle frequency? | Monthly minimum, weekly or continuous externally |
| What does the report contain? | Summary, ranked findings, evidence, coverage statement |
| Are trends reported? | Yes — open findings and overdue items, month on month |
| Is remediation advice specific? | Named packages and versions, not generic vendor text |
| What is excluded? | Stated explicitly, in the coverage section |
| How is the data protected? | Named storage location, retention period and deletion terms |
The coverage statement is the most under-read page
Every vulnerability assessment report should say which assets were reachable, which were not, and why. A programme that quietly drops 12% of the estate every month because a firewall rule blocks the scanner is producing a clean-looking trend line about the wrong population.
Evidence you should keep for questionnaires and audits
Keep the scope definition, the monthly reports, the triage decisions, the change records that closed findings, and the accepted-risk register. That bundle answers most customer security questionnaires without a single meeting, and it is exactly what an ISO 27001 auditor asks to see.
Running the vulnerability assessment in-house versus buying it
Both instruments can be insourced, but the economics are very different and only one of them usually makes sense to bring in-house at SME scale.
The case for in-house assessment
Tooling is affordable, the work is repeatable, and the person who runs the vulnerability assessment is often the person who will fix the findings — which removes an entire handoff. If you already have a competent systems administrator with spare capacity, this is a reasonable build.
The case against in-house assessment
It is nobody’s day job until it is somebody’s day job. The tooling needs maintaining, credentials rotate, coverage silently degrades, and triage quality depends on one person’s knowledge. Buying the cycle from a provider converts all of that into a fixed line item with a stated deliverable.
Testing in-house is a different proposition
Offensive testing needs current specialist skill, and independence is part of the product. PCI DSS explicitly requires organisational independence for its testing requirement. For almost every UK SME, testing is bought, not built.
The hybrid most mid-sized firms end up with
| Activity | Usually in-house | Usually bought |
|---|---|---|
| Asset discovery | Yes | Sometimes with the first cycle |
| Scheduled scanning | Often | Often, as a managed service |
| Triage and prioritisation | Sometimes | Commonly |
| Remediation | Almost always | Rarely |
| Penetration testing | Rarely | Almost always |
| Independent sign-off | Never | Always |
The staffing arithmetic worth doing before you build
At a £1,200 day rate, the £15,600 balanced programme is equivalent to 13 consultant days a year. If bringing the vulnerability assessment in-house consumes more than about a day a month of a skilled person’s time, plus tooling, the build stops being cheaper than the buy — and it is nearly always more than a day a month in the first year.
Vulnerability assessment vs penetration testing: the decision table
Everything above reduces to a set of situations. Find yours.
| Your situation | Buy first | Why |
|---|---|---|
| You have never scanned anything | Vulnerability assessment | You cannot scope a test without knowing the estate |
| A customer contract names a penetration test | Penetration test | Nothing else satisfies the clause |
| You are preparing for Cyber Essentials Plus | Vulnerability assessment | It finds the unsupported software that fails you |
| You are launching a custom web application | Penetration test | Logic flaws have no signature to scan for |
| You are in PCI DSS scope | Both, to different requirements | 11.3 and 11.4 are separate obligations |
| You just acquired another company | Vulnerability assessment | Discovery across the new ranges comes first |
| You had an incident last quarter | Both, depth-first | You need to know how far an attacker could go |
| Your last test found only patch issues | Vulnerability assessment | You are paying a day rate for automatable output |
| Your board wants a risk narrative | Penetration test | Boards act on stories, not on inventories |
| You have hundreds of open findings | Neither — buy remediation | Detection is not your constraint |
| You are fully cloud-hosted with no servers | Vulnerability assessment, configuration-focused | Most of your risk is in the control plane |
| You ship code twice a week | Continuous assessment, targeted tests | An annual set-piece tests a build you no longer run |
The default answer, if none of those fit
Run a vulnerability assessment monthly, run a penetration test annually against whatever is most exposed, and reserve one retest day per test. That is option C above, and for a business of roughly 60 people it costs about £15,600 a year.
Mistakes that waste a vulnerability assessment budget
Six failure patterns account for most of the wasted money in this market.
Scanning only what you already knew about
Scoping from the asset register guarantees the forgotten host stays forgotten. Scope by network range every time, and treat newly discovered assets as the highest-value finding of the cycle.
Running unauthenticated scans for years
It looks like a vulnerability assessment programme and produces a reassuring trend line, while systematically understating patch exposure. Fix the credential problem before you buy another cycle.
Treating the CVSS column as the work queue
Severity is technical, not contextual. Rank by exposure, exploitation and business impact, exactly as the NCSC’s triage guidance describes, or you will fix a 9.8 in a lab while a 6.4 on the payment path stays open.
Buying a test before the estate is clean
You pay a specialist day rate to be told about missing patches. Clear the known list first, then buy the days.
Scoping a test to the budget
A short test on a large system produces a report that says nothing found in the time available. Either fund the days the scope needs or narrow the scope honestly.
Never closing the loop
The retest is what converts a finding into a fix on paper. Without it, next year’s engagement starts by rediscovering last year’s findings, and you will have paid twice for the same information.
Frequently asked questions about vulnerability assessment and penetration testing
Is a vulnerability assessment the same as a vulnerability scan?
Not quite. The scan is the automated part. A vulnerability assessment is the scan plus scoping, credentialed access, human triage, prioritisation and a report that names actions and owners. If you are quoted for a vulnerability assessment and receive a raw tool export, you were sold the scan.
Can a penetration test replace a vulnerability assessment?
No, and the NCSC says so directly: testing is for gaining assurance in your vulnerability assessment and management processes, “not as a primary method for identifying vulnerabilities”. A test covers a fraction of your estate for a fraction of the year.
Which should a small UK business buy first?
The vulnerability assessment, run as a monthly programme rather than a one-off report. It is cheaper, it covers everything, and it makes any subsequent test far better value because the testers spend their days on genuinely interesting problems.
How much should we budget in total?
For a business of roughly 60 people, £15,600 a year buys twelve scanning cycles, a three-day external test, a four-day web application test and a retest day. Smaller and simpler estates can run a credible programme for considerably less; regulated or breached organisations should expect closer to £27,600.
Does Cyber Essentials require a penetration test?
No. Cyber Essentials and Cyber Essentials Plus are assessments against five technical control areas, and Plus adds hands-on verification by an assessor rather than adversarial testing. A vulnerability assessment beforehand is nonetheless the cheapest way to avoid failing on unpatched or unsupported software.
How often does PCI DSS require each one?
Internal and external vulnerability scans at least once every three months under requirement 11.3, with internal scans authenticated, and internal and external penetration testing at least every 12 months and after significant change under requirement 11.4. Segmentation testing is annual for merchants and every six months for service providers.
What is a reasonable UK day rate for testing?
Around £1,200, within a credible range of £1,000 to £1,500. Below about £500 per day, assume automation rather than manual testing, and ask directly what proportion of the engagement is performed by hand.
Do we need a CREST or CHECK provider?
CHECK is required for central government systems at OFFICIAL or above; the NCSC states that non-public-sector organisations do not need a CHECK provider. CREST or Cyber Scheme accreditation is the usual quality signal for UK private-sector buyers.
How long does each one take?
A vulnerability assessment cycle typically runs overnight to a few days depending on estate size, with reporting shortly after. A penetration test runs for the days quoted, plus a reporting phase of a few days, so a four-day test usually means two to three weeks from kick-off to final report.
What should we do with the report afterwards?
Assign every finding an owner and a deadline drawn from the NCSC timescales, decide explicitly which risks you are accepting, record those decisions, and retest. The report is an input to a process, not the output of one.
References and Further Reading
NCSC — Vulnerability Scanning Tools and Services
NCSC — Vulnerability Management
NCSC — Vulnerability Management Guidance
NCSC — Put in Place a Policy to Update by Default
NCSC — Carry Out Assessments by Triaging and Prioritising
NCSC — Responding to Active Exploitation of Vulnerabilities
NCSC — Verify and Regularly Review Your Vulnerability Management Process
NCSC — 10 Steps to Cyber Security: Vulnerability Management
NCSC — 10 Steps to Cyber Security
NCSC — CHECK Scheme Introduction
NCSC — Cyber Essentials Overview
NCSC — Cyber Assessment Framework
NCSC — Cyber Security Board Toolkit
NCSC — Keeping Devices and Software Up to Date
NCSC — The Problems with Patching
NCSC — Vulnerabilities Topic Index
NCSC — Assured Products and Services Search
FIRST — CVSS v4.0 Specification Document
FIRST — CVSS v4.0 User Guide
FIRST — Common Vulnerability Scoring System
FIRST — 2026 Mid-Year Vulnerability Forecast
FIRST — Exploit Prediction Scoring System
NIST National Vulnerability Database
NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment
OWASP Web Security Testing Guide
OWASP Application Security Verification Standard
OWASP Mobile Application Security
PCI Security Standards Council — Standards
PCI Security Standards Council — Document Library
PCI SSC — Approved Scanning Vendors
PCI SSC — Resource Guide: Vulnerability Scans and Approved Scanning Vendors
CREST — Penetration Testing Focus Group
CIS Critical Security Controls
CIS Control 7 — Continuous Vulnerability Management
Cyber Security Breaches Survey 2025/2026
Cyber Security Breaches Survey Collection
Cyber Governance Code of Practice
ICO — A Guide to Data Security
MITRE Common Weakness Enumeration
EIOPA — Digital Operational Resilience Act
ENISA — Vulnerability Disclosure
PortSwigger Web Security Academy
AWS — What Is Amazon Inspector
