Vulnerability assessment vs penetration testing: what you need and what to do with the report

Scans and pen tests are often sold together as “VAPT”, and often confused. They answer different questions, cost very different amounts and fit at different points in the year. Here is how to choose, how to scope a test, what PCI DSS actually asks for and how to turn a 60-page report into decisions.

By Alex Martyushin, founder & risk consultant · Updated 30 October 2026 · 12 min read

The difference at a glance

A useful way to think about it: the assessment tells you the doors that look unlocked; the pen test tries the handles, walks through, and tells you which room it reached. A pen test against systems that have never been scanned mostly finds missing patches — expensive time spent on what a scanner would have found for a fraction of the cost.

Both feed your vulnerability management process, which is where findings are triaged, fixed and verified. Neither replaces a cybersecurity risk assessment, which decides which weaknesses matter to the business.

Types of penetration test

“Pen test” covers very different exercises. Pick the type from the risk you want to test, not from a supplier’s menu.

Black, grey and white box

A black-box test gives testers no inside information, simulating an outsider. A white-box test gives them documentation, source code or administrator access. A grey-box test — usually with ordinary user accounts for each role — is the most common for web applications, because it spends the budget testing the application rather than guessing usernames. For a fixed number of days, more information usually means more findings that matter.

Which one do you need?

• Always: regular vulnerability scanning of internet-facing systems, plus internal systems if you have them. It is cheap, frequent and catches the most common cause of compromise — known, unpatched flaws.
• Add an annual pen test when you run your own web application, store checkout, customer portal or API; when you hold significant personal or payment data; or when a standard, client or insurer asks for one.
• Add a pen test after significant change: a new platform, a redesigned checkout, a new login method, a migration to the cloud or a major integration.
• Scanning alone may be enough for a small business on fully hosted software with no custom code, provided accounts are protected with MFA and the scan covers the website and email set-up.

Clients and frameworks increasingly ask for evidence of testing. In the UK, Cyber Essentials Plus includes hands-on technical verification by an assessor — useful, but narrower than a full pen test. Many buyers ask for testing by a CREST-accredited company; UK public sector work may specify the NCSC’s CHECK scheme. Requirements differ by sector and contract, so check what your customers and regulators actually require before buying.

PCI penetration testing

For online stores, the most common hard requirement comes from PCI DSS. Under version 4.0.1:

Which of these apply depends on your self-assessment questionnaire. As our PCI DSS checklist explains, most online merchants need quarterly ASV scans, but the penetration testing requirement applies to SAQ A-EP and SAQ D, not SAQ A. A store that moved to a fully hosted payment page may not need a PCI pen test at all — though it may still want one for its own reasons.

Two practical points. The tester does not need to be a QSA or ASV, but must be independent of the systems tested — your own developer cannot test their own code. And “after significant change” is defined by you; write down what counts (for example, a new checkout or payment integration) so the decision is not made under deadline pressure.

How to scope a pen test

Most disappointing pen tests fail at scoping, not testing. Before asking for quotes, write a one-page scope:

1. Objective. What are you trying to learn? “Can a customer see another customer’s orders?” beats “test the website”.
2. Targets. URLs, IP ranges, apps, APIs and cloud accounts in scope — and explicitly out of scope. Third-party services such as a payment provider usually need their own permission or are excluded.
3. Roles and test accounts. One account per user type: customer, staff, administrator, partner.
4. Environment. Production or a staging copy that truly matches it. Testing production is more realistic but needs care around live orders and data.
5. Rules of engagement. Testing windows, contacts, what to do if a critical flaw or evidence of a previous compromise is found, and anything off limits (for example, denial-of-service testing).
6. Deliverables. Report format, severity scale, a debrief call and whether a retest is included.

Tell your hosting provider and any monitoring service before testing starts. Some cloud and hosting providers publish their own pen testing policies; follow them.

What a penetration test costs

We are not going to quote a price range: published figures vary so widely by country, provider and scope that they mislead more than they help. What is consistent is how pen tests are priced. Most are quoted in tester-days, so the cost follows the effort needed to cover the scope properly.

• Size and complexity of scope — number of applications, pages with distinct functions, user roles, API endpoints, IP addresses.
• Type of test — a web application test with several roles takes longer than an external network test of a few hosts; red team exercises are longer still.
• Depth — grey or white box usually gets more value per day than black box.
• Retest — included or charged separately. For PCI you need one.
• Accreditation and seniority — CREST, CHECK or similar, and the experience of the testers assigned.
• Constraints — out-of-hours testing, on-site work, urgent start dates.

To compare quotes fairly, send the same written scope to each provider and ask how many days each part will take, who will do the testing and what the report will look like. A much cheaper quote often means fewer days or an automated scan sold as a pen test. Ask for a sample report.

Reading a penetration testing report

A good penetration testing report is written for two audiences: leadership, who need to know how exposed the business is, and the people who will fix things.

Severity in the report is usually based on CVSS or the tester’s own scale. Treat it as a starting point: the tester knows the technical impact, but you know which system holds card data, which one the business cannot trade without and which compensating controls exist. That context comes from your risk register.

What to do with the report

A report filed in a shared drive changes nothing. Work through it in four passes.

1. Fix and verify

Every finding becomes a ticket in your vulnerability management process, with an owner and a due date by priority. Critical and high findings on internet-facing systems get fixed first. Book the retest when they are done.

2. Record what cannot be fixed in time

Some findings will not be fixed within your SLA — a legacy system, a vendor dependency, a redesign. Each becomes a time-limited exception with a named person accepting the risk, recorded in the register with compensating controls and a review date.

3. Look for themes

Individual findings are symptoms. If three findings are broken access control in different parts of the store, the risk is not three bugs; it is that your development process does not check authorisation. That theme belongs in the register as a risk with a treatment — secure coding training, a review checklist, automated tests — and the findings are its evidence.

4. Update scores and indicators

A test is evidence about likelihood. If testers reached customer data in an afternoon, the likelihood score for a data breach was too low; if they were stopped at every turn, the control effectiveness you claimed is supported. Re-score, and track a few key risk indicators from test to test:

Example register entries from a store pen test

The scores are illustrative, on a 5×5 matrix. See inherent vs residual risk for how to score before and after treatment.

Common mistakes

• Buying a scan labelled as a pen test. If the report is a scanner export with a logo, you paid for an assessment. Ask how many manual tester-days are included.
• Pen testing before scanning. Fix the easy, known issues first so testers spend their time on what scanners cannot find.
• Scope that misses the crown jewels. Testing the marketing site but not the checkout or admin panel.
• No retest. A finding is not closed until someone independent confirms the fix.
• Treating the report as the risk assessment. A pen test is evidence for your risk scores, not a substitute for deciding what matters.
• Same findings every year. Repeated findings mean the root cause was never treated. Put the theme in the register.
• Once a year and forgotten. The test is a snapshot; scanning and patching carry you through the other 51 weeks.