Vulnerability scan vs penetration test: what each one answers

A vulnerability scan is an automated check that compares your systems with a database of known weaknesses and reports possible matches. A penetration test is an attempt by specialists, within an agreed scope and an agreed number of days, to exploit weaknesses and show what an attacker could reach. The test follows selected weaknesses to see where they lead.

Before ordering either service, check what evidence your customer or your IT team needs. Both should document what was checked and what was found — potential security issues — and both are sold as "security testing". Buying the wrong assessment can leave the original request unanswered: a company pays for a penetration test to learn what a scan would have shown, or it sends a scan report to a customer who asked for a penetration test, and the security questionnaire comes back.

What a vulnerability scan does

A scanner connects to the systems you point it at and identifies what is running: operating systems, web servers, application versions, open ports. It then matches that against the vulnerabilities it knows. NIST's testing guide describes vulnerability scanning as "a technique used to identify hosts/host attributes and associated vulnerabilities" (NIST SP 800-115, 2008).

You can repeat the automated checks as systems change. Someone still needs to review the results. A scan is good at questions with a known answer. Is this software version outdated? Is a patch missing? Was a setting left at an insecure default? Is a certificate about to expire?

Scanners find "surface vulnerabilities": each weakness on its own. They work from known checks and attack patterns, so what they find depends on the tool, its configuration and the access it has. They "can have a high false positive error rate" — false alarms, in plain terms — and the guide asks for someone with networking and security expertise to interpret the results.

Two questions help when you compare scope. Is it a network scan, which checks the systems and services that answer on the network, or a web application scan, which checks the pages, inputs and interfaces of an application? They are different checks, so "we scanned it" is not enough detail when you compare quotes. And does the scan get login access? Host credentials let it inspect installed software and settings; an application test account lets it check the functions that account can reach. Login access is a separate question from where the scanner runs, inside or outside your network.

This is also why a vulnerability assessment and a vulnerability scan are not quite the same thing. An assessment can combine scanning, manual checks and analysis of the results: a person checks the suspected false alarms, rates each finding for your environment and decides what comes first. The tool's severity label is a starting point: NIST advises assessors to set the risk level themselves rather than accept the scanner's (NIST SP 800-115, section 4.3).

What a penetration test does

In a penetration test, people try to get in. NIST defines it as testing "in which evaluators mimic real-world attacks in an attempt to identify ways to circumvent the security features of an application, system, or network" (NIST glossary).

A scanner reports that a vulnerability may exist. A tester may investigate that finding further and demonstrate its impact within the agreed limits. A successful attempt is evidence that the weakness is real; an unsuccessful one does not prove it is absent, only that it was not exploited under those conditions and in that time. Testers also look for combinations: several weaknesses that each look minor can add up to access that none of them gives alone. In NIST's words, most penetration tests look for "combinations of vulnerabilities" that give "more access than could be achieved through a single vulnerability".

The work runs under rules agreed in advance: which systems, which dates, what is off limits, who to call if something breaks. It needs people who can reason about an application the way an attacker would. The team agrees the duration and the repeat schedule around the systems in scope, the access available and the depth of testing required.

Vulnerability scan vs penetration test

The comparison below covers an automated scan and a scoped penetration test. An assessment may add manual validation and prioritization; confirm what the proposed service includes.

The question it answers

• Vulnerability scan: which known weaknesses might exist on these systems?
• Penetration test: what could an attacker actually reach, and how?

Who does the work

• Vulnerability scan: a tool, ideally with a person reviewing the output.
• Penetration test: specialists, using tools where they help.

How it works

• Vulnerability scan: runs known checks against what it detects and reports matches.
• Penetration test: tries to exploit weaknesses and chain them together, within an agreed scope.

How often

• Vulnerability scan: on an agreed schedule: weekly, monthly or continuous runs are all common, depending on the setup.
• Penetration test: periodically, and after significant changes to the systems in scope.

What you receive

• Vulnerability scan: findings with severity ratings and supporting details. Results may include false positives and need review.
• Penetration test: a report of confirmed findings with evidence, likely impact and prioritized recommendations.

Limits

• Vulnerability scan: a standard scan may miss flaws in the application's own rules, or attack paths that combine several weaknesses. Coverage depends on the checks enabled and the access provided.
• Penetration test: weaknesses the testers did not reach in the time available, and anything outside the scope. It describes one moment in time.

Whichever you order, agree before the work starts who will review the findings and who will make the fixes, and set a target date for each one. Ask whether rescanning or retesting is included in the price, and how the results will be recorded.

What an external scan can see

An external scan looks at your company from the internet. Websites, mail servers, VPN access, remote-access portals: whatever answers from outside. An external scan without login access checks the in-scope services that answer from the scanner's location, and it needs no access to your internal network. Filtering rules can limit what it sees.

Its blind spots are specific. It sees only the systems that answer while it runs, and only the ones it was told about or can find. A test server set up last week and never recorded may be reachable from the internet and still missing from the scan list. And a firewall that filters traffic changes what the scanner can see; NIST lists this among the challenges of external scanning (SP 800-115, section 4.3).

So knowing what to scan is a problem of its own. Our article on reconciling the declared and the actual perimeter explains how to check the inventory against what is really reachable.

Which one do you need?

Start from the question someone is asking you.

• A customer or an auditor asked for a penetration test report. A scan report does not answer that request, however long it is. For example, a software supplier may meet this when filling in a bank's supplier questionnaire.
• You handle card payments. Where PCI DSS v4.0.1 applies to your assessment, requirement 11.3.2 calls for passing external scans by an Approved Scanning Vendor (ASV) at least once every three months, with remediation and rescanning as needed. Requirement 11.3.2.1 also requires external scans after significant changes; these need qualified, independent personnel, but not necessarily an ASV. Requirement 11.4.3 requires external penetration testing at least once every 12 months and after significant infrastructure or application changes. Which requirements apply to you is confirmed with whoever accepts your assessment, such as your acquiring bank.
• You launched something new, such as a customer portal, an API (the interface other software uses to talk to your system) or an online store before a seasonal sale. A scan can catch known issues in its components; a test can check the application's own rules — for example, whether one customer account can open another customer's invoice, using approved test accounts.
• Nobody has ever looked. Begin with the external view: which systems are reachable from the internet, and which known issues they carry. That inventory can help scope a later external penetration test.

Sources for the PCI points: the PCI Security Standards Council's page on Approved Scanning Vendors and its FAQ on quarterly scans cover the scanning side. The text of requirements 11.3.2, 11.3.2.1 and 11.4.3 is in PCI DSS v4.0.1 itself, available from the PCI SSC document library.

Continuous monitoring between assessments

A scan and a penetration test both describe your systems on the day they ran. Between runs, new websites, services and cloud resources can appear without anyone recording them. Regular external checks can reveal those changes; what they find depends on their coverage and on how often they run. Our article on why an annual pentest starts aging the day it is delivered explains what can change between one test and the next. SeguriScan, IntruForce's platform, identifies systems associated with your company, checks them for security issues and brings the results together with company accounts found in data leaks. It covers systems reachable from the internet; it does not assess your internal network, and it does not replace a penetration test.

Request an external review or a scoped test

If you want the external picture first, use Check My Company at the end of this page. It is a request to the IntruForce team, not an instant scan: you share your company website and a work email, and our team replies by email. Nothing that interacts with your systems runs without your confirmation.

If a specific system already needs a closer look, IntruForce Expert Services are targeted assessments led by our team: penetration testing, web application and API security testing, and phishing simulations (test messages that imitate an attempt to deceive your team). Describe what you need to assess in the request form on the services page. Sending a request does not commit you to buying a service, and tests that interact with your systems are agreed separately.