Penetration testing vs vulnerability scanning
Vulnerability scanning automatically checks for known vulnerabilities. Penetration testing manually exploits weaknesses, including business logic. The Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 requires both for in-scope components: scans at least once every three months and after any significant change; penetration tests at least once every 12 months and after any significant infrastructure or application upgrade or change.
Penetration testing and vulnerability scanning compared
The table compares both methods by the NIST SP 800-115 definitions (checked on 2026-09-22), by the PCI DSS v4.0.1 Requirements and Testing Procedures (checked on 2026-09-16) for systems that store, process, or transmit cardholder data, and by DORA, Regulation (EU) 2022/2554 with Delegated Regulation (EU) 2024/1774 (both checked on 2026-09-22).
| Factor | Penetration testing | Vulnerability scanning |
|---|---|---|
| Definition in NIST SP 800-115 | Penetration testing is security 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. | Vulnerability scanning is a technique used to identify hosts, host attributes, and associated vulnerabilities. |
| How the test runs | A tester plans, discovers, attacks, and reports, following the example four-phase model in NIST SP 800-115 section 5.2.1. | A scanner matches the software versions it detects against the known vulnerabilities in its database, as NIST SP 800-115 section 4.3 describes. |
| What the method finds | A penetration test finds combinations of weaknesses and business logic abuse, such as a refund above the captured amount. | A vulnerability scan finds outdated software versions, missing patches, and misconfigurations. |
| Reliability of results | A penetration test finding comes from an attack that the tester ran against the target system. | NIST SP 800-115 says network-based vulnerability scanners can have a high false positive error rate and an expert should interpret the results. |
| Frequency under PCI DSS v4.0.1 | PCI DSS v4.0.1 requires internal and external penetration tests at least once every 12 months and after any significant infrastructure or application upgrade or change (11.4.2, 11.4.3). | PCI DSS v4.0.1 requires internal and external vulnerability scans at least once every three months (11.3.1, 11.3.2) and after any significant change (11.3.1.3, 11.3.2.1). |
| Who performs the work under PCI DSS v4.0.1 | Under PCI DSS v4.0.1, a qualified internal resource or qualified external third party with organizational independence performs the penetration test and is not required to be a Qualified Security Assessor (QSA) or an Approved Scanning Vendor (ASV). | Under PCI DSS v4.0.1, a PCI SSC Approved Scanning Vendor (ASV) performs the three-monthly external scans, and qualified personnel with organizational independence perform the internal scans. |
| Closure condition under PCI DSS v4.0.1 | PCI DSS v4.0.1 requires exploitable vulnerabilities to be corrected by the risk ranking of requirement 6.3.1 and the penetration test to be repeated (11.4.4). | PCI DSS v4.0.1 requires high-risk and critical internal vulnerabilities to be resolved and rescanned (11.3.1), and external scans to meet the Approved Scanning Vendor (ASV) Program Guide requirements for a passing scan (11.3.2). |
| Place in DORA | The Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, lists penetration testing in Article 25(1), and Article 26(1) requires threat-led penetration testing (TLPT) at least every 3 years from identified financial entities other than Article 16(1) entities and microenterprises, and the competent authority may, where necessary, request a reduced or increased frequency. | The Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, lists vulnerability assessments and scans in Article 25(1), and for entities outside the Article 16(1) simplified framework, Delegated Regulation (EU) 2024/1774 Article 10(2)(b) sets scan frequency and scope by asset classification and overall risk profile. |
| Risk to the tested systems | NIST SP 800-115 says penetration testing can damage systems or render them inoperable and should be performed only after careful consideration, notification, and planning. | NIST SP 800-115 says vulnerability scanning may disrupt network operations by taking up bandwidth and slowing response times. |
| Main artifact | A penetration test report records scope, methodology, findings, and retest results, and PCI DSS 11.4.1 requires retention of results for at least 12 months. | A scan report lists the detected vulnerabilities per host, and an Approved Scanning Vendor (ASV) scan report is the evidence for external scans under PCI DSS 11.3.2. |
When to choose penetration testing
- The risk sits in business logic or access control. PCI DSS 11.4.1 requires application-layer penetration testing for, at a minimum, the vulnerabilities in requirement 6.2.4, which include attacks on business logic and attacks on access control mechanisms.
- The 12-month window or a significant change arrives. PCI DSS 11.4.2 and 11.4.3 apply at least once every 12 months and after any significant infrastructure or application upgrade or change. The PCI DSS page maps the full requirement 11 evidence set.
- Segmentation keeps systems out of PCI scope. If segmentation isolates the cardholder data environment, PCI DSS 11.4.5 requires penetration tests of the segmentation controls at least once every 12 months and after any changes to segmentation controls or methods. Requirement 11.4.6 shortens the interval to at least once every six months for service providers.
- A scan finding needs proof of impact. NIST SP 800-115 section 4.3 says vulnerability scanners can provide information on targets for penetration testing. A penetration test confirms whether the weakness reaches accounts or funds.
- DORA applies to the entity. DORA Article 24(6) requires financial entities, other than microenterprises, to ensure at least yearly that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions. The DORA page covers TLPT, and the DORA readiness scenario covers preparation.
When to choose vulnerability scanning
- The requirement is a recurring scan. PCI DSS 11.3.1 and 11.3.2 require internal and external scans at least once every three months, and 11.3.1.3 and 11.3.2.1 add scans after any significant change. A penetration test report does not replace an ASV scan report for 11.3.2.
- Known vulnerabilities appear between releases. NIST SP 800-115 section 4.3 says vulnerability scanning can help identify outdated software versions and missing patches. PCI DSS 11.3.1 requires the scan tool to be kept up to date with the latest vulnerability information.
- A penetration test needs a starting inventory. A current scan result gives the tester the hosts, open ports, and known weaknesses.
Our recommendation, not a requirement of any standard: treat the scan as the input and the penetration test as the proof. The 11.4.1 customized approach objective in PCI DSS v4.0.1 (checked on 2026-09-16) describes testing that "attempts to exploit vulnerabilities and security weaknesses via simulated attack methods by a competent manual attacker", and a scan report does not show that.
Cost and timeline factors
Penetration testing effort grows with scope:
- Applications, API operations, and user roles. Each role and tenant multiplies the access control checks.
- Environment. A production-like test environment with synthetic data keeps the damage risk that NIST SP 800-115 describes away from live customers. DORA TLPT runs on live production systems (Article 26(2)), which adds risk management controls under Article 26(5).
- Retest cycles. PCI DSS 11.4.4 requires a repeated penetration test to verify corrections, so the timeline includes the fix window and a retest.
- Methodology and independence. PCI DSS 11.4.1 requires a documented methodology, and 11.4.2 and 11.4.3 require organizational independence of the tester.
Vulnerability scanning effort grows with triage:
- False positive triage. NIST SP 800-115 section 4.3 says network-based scanners can have a high false positive error rate, so an engineer confirms each finding before the development team spends time on it.
- Rescans. PCI DSS 11.3.1 requires rescans that confirm high-risk and critical vulnerabilities are resolved, and 11.3.2 requires rescans as needed to confirm that vulnerabilities are resolved per the ASV Program Guide requirements for a passing scan.
- First assessment. For the initial PCI DSS assessment against 11.3.2, fewer than four passing scans are accepted under the conditions the assessment scenario lists.
Our security testing service delivers the web, API, and mobile penetration test report, findings with retest results, and PCI DSS requirement 11 test evidence for the assessor.
Questions
What is the difference between a vulnerability scan and a penetration test?
NIST Special Publication (SP) 800-115 defines vulnerability scanning as a technique used to identify hosts, host attributes, and associated vulnerabilities. NIST SP 800-115 defines penetration testing as security 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. A vulnerability scan reports known weaknesses; a penetration test shows which weaknesses an attacker can exploit and combine.
How often should vulnerability scans be performed?
The Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 requires internal and external vulnerability scans at least once every three months and after any significant change (requirements 11.3.1, 11.3.1.3, 11.3.2, and 11.3.2.1). A PCI Security Standards Council (PCI SSC) Approved Scanning Vendor (ASV) performs the three-monthly external scans. Under the Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, Delegated Regulation (EU) 2024/1774 Article 10(2)(b) (Official Journal text, checked on 2026-09-22) sets scan frequency by the information and communication technology (ICT) asset's classification and risk profile for entities outside the Article 16(1) simplified framework.
Scope your penetration test
Send your API specification, the list of user roles, and the date of your last penetration test, and we return a test scope mapped to PCI DSS requirement 11.4 or DORA Article 25.
Scope your testing