Vulnerability Assessment vs Penetration Testing: What Each Finds and When You Need It

A vulnerability assessment finds and ranks known weaknesses across many systems, mostly with automated scanning and analyst review. A penetration test has people try to exploit weaknesses to show what an attacker could reach. The assessment covers the whole estate every month or quarter and answers what is wrong and where, while the test covers a defined scope once a year and after major changes and answers what someone could do with it. Most organizations need both, and PCI DSS v4.0.1 requires both: vulnerability scans at least once every three months under Requirement 11.3 and penetration tests at least once every 12 months under Requirement 11.4. This guide compares the two, shows where a scan ends and a test begins, explains how to read each one's results, and gives a rule for budgeting and sequencing them.

Vulnerability assessment vs penetration testing, side by side

The two services answer different questions, so they differ on almost every line a buyer scopes.

The penetration test ranges come from our penetration testing cost analysis, which also explains why a quote near $2,000 is almost always a scan with a cover page: a skilled tester bills $1,500 to $2,500 a day, and a modest application takes five to ten tester days plus reporting. The assessment ranges are the planning figures we use for quarterly authenticated internal scanning, and the number moves with asset count, the share of hosts scanned with credentials, and the analyst time spent validating results.

Where does a scan end and a test begin?

A scan ends when the tool reports what it observed, and a test begins when a person tries to use that observation to reach something. NIST SP 800-115 draws the line the same way. It says vulnerability scanners identify known vulnerabilities by matching hosts against their vulnerability databases, that scanners can have a high false positive error rate, and that scan results provide targets for penetration testing. It defines penetration testing as security testing in which assessors mimic real-world attacks to identify methods for circumventing the security features of an application, system, or network, and it describes the attack phase as verifying potential vulnerabilities by attempting to exploit them.

The assessment sits between the two. NIST's glossary defines a vulnerability assessment as a systematic examination of a system to determine the adequacy of its security measures and identify security deficiencies. In practice that means the scan plus analysis: an analyst removes false positives, collapses duplicates, adds asset context, and ranks what remains. Manual verification does not turn the result into a penetration test. PCI SSC's Penetration Testing Guidance describes vulnerability scans as automated tools combined with manual verification of identified issues, and it states that simply running an automated tool does not satisfy the penetration testing requirement.

Only a test finds the flaws that leave no signature: a user in one tenant reading another tenant's invoices, a refund workflow that pays out more than the original charge, or three medium findings that combine into control of the domain. A scanner sees a normal, successful response in each case, because these are authorization and business logic failures.

When is each the right purchase?

Buy the assessment first and keep it running, then buy a penetration test when you need proof of impact for a defined scope. The assessment is the right purchase when you have never measured your exposure, when you need evidence of regular scanning for PCI DSS 11.3 or SOC 2, after each patch cycle to confirm fixes, and whenever new assets join the estate.

A penetration test is the right purchase before a major release or migration, when a customer's security review asks for one, for the annual tests PCI DSS 11.4 requires, to prove under 11.4.5 that segmentation isolates the cardholder data environment, and when scan results are under control and the open question is what an attacker could chain together. If the question is whether your team would detect an attacker, a red team exercise answers it and neither of these services does. When a test is the right purchase, our penetration testing services scope it to the systems and roles that carry the risk, and the testers' starting knowledge sets how far they reach in the same hours, as our guide to black box vs white box penetration testing explains.

How to read vulnerability assessment results: CVSS, EPSS, and the KEV catalog

Rank assessment results by likelihood of exploitation and the value of the asset, and treat severity scores as one input. Three public signals do most of the work.

CVSS describes severity, and its authors say so. The CVSS v4.0 User Guide states that Base scores are designed to measure the severity of a vulnerability and should not be used alone to assess risk. Version 4.0 labels each score by the metric groups behind it, from CVSS-B for Base metrics only to CVSS-BTE for Base, Threat, and Environmental, so a report shows whether anyone adjusted the number for your environment.

EPSS, the Exploit Prediction Scoring System, estimates the probability that a published CVE will be exploited in the wild in the next 30 days. FIRST reports that in any 30-day period it tracks exploitation activity against 1.5 to 3 percent of published vulnerabilities, so a queue sorted by CVSS alone fills with work attackers ignore. FIRST's guidance on using EPSS warns against multiplying an EPSS score by a CVSS score to build one risk number, and it tells teams to treat any entry in the CISA Known Exploited Vulnerabilities (KEV) catalog as actively exploited, whatever its EPSS score.

Breach data shows what slow prioritization costs. Verizon's 2026 Data Breach Investigations Report found exploitation of vulnerabilities was the most common initial access vector, at 31 percent of breaches. It also found that organizations fully remediated only 26 percent of critical vulnerabilities in 2025, down from 38 percent, with critical meaning listed in the KEV catalog, and that the median time to full resolution rose to 43 days. A risk-based queue puts KEV entries on internet-facing systems first, then high-probability EPSS items on systems that hold regulated data or money, then everything else by CVSS within each asset tier.

How to tell scanner output from manual findings in a report

Read three or four findings in full and the source of the work shows. Scanner output describes a condition on a host, while a manual finding describes what a tester did with a weakness and what it exposed. The table lists the signals to check in any report labeled a penetration test.

A good report contains both and labels which is which. A penetration test report made almost entirely of the left column is a vulnerability assessment with a different title, and it is the product behind the $2,000 quote.

What do the standards require?

PCI DSS sets both cadences, and the other common drivers name one activity or leave the choice to your risk analysis. The table summarizes each driver as of October 2026.

PCI SSC's FAQ 1152 states that PCI DSS requires internal and external vulnerability scans at least once every three months, and FAQ 1087 treats 90 days as the longest acceptable gap. External scans under 11.3.2 must come from an ASV and meet the ASV Program Guide's passing criteria, which FAQ 1152 describes as no vulnerabilities scored 4.0 or higher on CVSS, and internal scans must run with authenticated access under 11.3.1.2. Penetration tests under PCI DSS v4.0.1 Requirement 11.4 run on a 12-month cycle, and the tester can be a qualified internal resource or a qualified external third party with organizational independence, who does not need to be a QSA or an ASV. Our guide to PCI compliance levels explains which validation document your level requires. BD Emerson is not a QSA company or an ASV: we perform penetration and segmentation tests, and an ASV runs your external scans.

SOC 2 states its expectations as points of focus in the AICPA Trust Services Criteria. Under CC7.1, the entity conducts vulnerability scans designed to identify potential vulnerabilities or misconfigurations on a periodic basis and after any significant change, and a CC4.1 point of focus names penetration testing among the separate evaluations management can use. HIPAA requires a risk analysis under 45 CFR 164.308(a)(1)(ii)(A) and periodic evaluation under 164.308(a)(8), and the proposed rule HHS published on January 6, 2025 would add vulnerability scanning at least every six months and penetration testing at least once every 12 months; as of October 2026 HHS has not finalized it. Insurers ask about the two separately, and CFC's US cyber supplementary application defines a scan as an automated test for known vulnerabilities and a penetration test as an authorized simulated attack.

How they work together in a vulnerability management program

A vulnerability management program runs the assessment continuously and uses the penetration test to check whether the program works. The cycle has five steps: inventory and scan every asset with credentials, prioritize with KEV and EPSS against asset value, fix with a named owner and a due date, rescan to verify, and test the systems that matter most to find what the scans and fixes missed. Each test feeds the program, because a chained path points to the scan checks, detection rules, and coding standards that should have stopped it.

Order matters as much as cadence. A test run before scan results are under control spends tester days on findings a scanner would have reported for a fraction of the cost, and a test run once a year after a clean scan still leaves months of change untested, which our comparison of continuous vs annual penetration testing addresses. Our vulnerability management service runs the cycle and hands engineering a queue it can clear.

A rule for budget and sequencing

Fund coverage before depth. BD Emerson's rule is to run authenticated scanning across the whole estate until KEV-listed and critical findings stay closed from one cycle to the next, then buy the penetration test, timed after a remediation cycle and with the retest reserved. For a mid-size company, that puts about a quarter of the annual testing budget into the assessment program and the rest into one deep test of the systems that hold customer data or money, plus its retest.

Consider a 400-person company with one customer-facing web application, a public API, and a $50,000 annual testing budget. At a $2,000 day rate, the midpoint of the range in our cost analysis, the plan below spends 24 percent on the assessment program and reserves retests at about 19 percent of the $32,000 testing spend, inside the 10 to 20 percent that analysis expects.

The calendar does the rest of the work. Months one and two scan and fix, month three tests, months four and five fix, and month six retests, with scanning running throughout and a targeted test added after any major release.

Common mistakes

These six mistakes are the ones we see most often, and each is cheap to avoid at scoping.

• Buyers call a scan a penetration test. A report that satisfies 11.3 does not satisfy 11.4, and an enterprise customer's security team can tell the two apart in minutes.
• Teams book the test without remediation time. A test booked two weeks before an audit produces findings you cannot fix in time, and PCI DSS 11.4.4 expects corrections followed by a repeated test.
• Teams skip the retest. A finding without a confirmed fix stays open for auditors and customers, and a retest bought later at a day rate usually costs more than one built into the engagement.
• Scans run without credentials. An unauthenticated scan sees only what a host exposes to the network, which is why PCI DSS 11.3.1.2 requires authenticated internal scans.
• Queues rank by CVSS alone. A 9.8 on an isolated test server can outrank an exploited 7.5 on the internet-facing system that holds customer records.
• Scans cover part of the estate. Assets the scanner never reaches are unmeasured risk, so reconcile scanner coverage against the asset inventory before tuning anything else.

Frequently asked questions

What is the difference between a vulnerability assessment and a penetration test? A vulnerability assessment uses automated scanning and analyst review to find and rank known weaknesses across many systems. A penetration test uses people to exploit weaknesses in a defined scope and show what an attacker could reach. The assessment runs monthly or quarterly across the whole estate, and the test runs once a year and after major changes, so most organizations need both.

What is VAPT? VAPT stands for vulnerability assessment and penetration testing, an engagement that combines an assessment across the environment with a penetration test against a defined scope. The assessment finds and ranks known weaknesses, and the test exploits the most promising ones to prove impact. Buy it as two clearly labeled deliverables, because PCI DSS, auditors, and customers treat scans and penetration tests as different evidence.

Is a vulnerability scan the same as a penetration test? No. A vulnerability scan is an automated check for known weaknesses, and a penetration test is a manual attempt to exploit weaknesses and show what an attacker could reach. PCI SSC states that simply running an automated tool does not satisfy the penetration testing requirement, and PCI DSS treats them as separate requirements: scans under 11.3 every three months and tests under 11.4 every 12 months.

How often should you run vulnerability scans and penetration tests? Scan at least monthly, at least once every three months where PCI DSS applies, and after every significant change. Run a penetration test at least once every 12 months and after major changes such as a new application, a migration, or an acquisition. Teams that ship weekly move to continuous testing, which tests changes as they ship instead of once a year.

Does PCI DSS require both vulnerability scans and penetration tests? Yes, for merchants and service providers that validate the full standard. PCI DSS v4.0.1 Requirement 11.3 requires internal and external vulnerability scans at least once every three months, with external scans run by an Approved Scanning Vendor, and Requirement 11.4 requires penetration tests at least once every 12 months and after significant change. SAQ A includes the external scans but not the penetration tests.

How much does a vulnerability assessment cost compared with a penetration test? In BD Emerson planning ranges, a quarterly authenticated assessment program costs $3,000 to $15,000 a year for a mid-size environment and $10,000 to $40,000 for a large one. A single penetration test costs more per engagement: most run $8,000 to $30,000, small external network tests start around $4,000, and complex application or AI work reaches $40,000 and beyond.

Should a vulnerability assessment come before a penetration test? Yes. Run the assessment first, because it finds the known, scanner-detectable weaknesses for a fraction of the cost of tester days. Fixing those before the test lets the testers spend their hours on authorization flaws, business logic, and chained attack paths that only people find. Book the penetration test after a remediation cycle, and reserve time and budget for the retest.

If you are building the scan, fix, and test cycle, our vulnerability management team can run the assessment program, set the remediation queue by KEV and EPSS, and time the penetration test so the retest lands before your audit.