Four terms (security audit, vulnerability assessment, VAPT, and penetration testing) are used interchangeably in procurement conversations, compliance requirements, and vendor marketing. They describe different activities that produce different types of evidence and satisfy different compliance obligations.
Commissioning a vulnerability assessment when a compliance framework requires a penetration test produces a finding list but not the evidence the auditor will accept. Commissioning a penetration test when you need a security audit produces exploitation evidence but not the policy and control attestation the audit requires. Understanding what each type of engagement actually proves (the specific evidentiary output) is the prerequisite for commissioning the right one.
A security audit is a structured review of security policies, procedures, configurations, and controls against a defined standard or framework. The auditor reviews documentation, interviews personnel, observes processes, and inspects configurations. The output is an assessment of whether the required controls exist, are documented, and are operating as described.
What a security audit proves: Controls exist and are operating. The audit produces documented evidence that specific security controls are in place (access management policies, change management procedures, encryption configurations, logging practices) and that they are followed in practice. This is the evidence that compliance frameworks like ISO 27001, SOC 2, and GDPR assessments require to confirm that a security management system is functioning.
What a security audit does not prove: Whether those controls would hold under attack. An audit confirms that a firewall rule exists and is configured as documented. It does not test whether the firewall rule actually blocks the traffic it is supposed to block. An audit confirms that MFA is required by policy. It does not test whether MFA can be bypassed through an alternative authentication path. Controls that exist on paper but fail under adversarial testing pass a security audit and fail a penetration test.
When to commission a security audit: When a compliance framework or contractual obligation requires evidence of control existence and operation. ISO 27001 certification requires a security audit of the ISMS (Information Security Management System). GDPR compliance requires documented privacy controls. Enterprise customer security questionnaires frequently ask for audit evidence of specific controls. The audit answers: "Do your controls exist and are they operating?"
A vulnerability assessment is an automated or semi-automated scan of systems, applications, and infrastructure to identify known vulnerabilities: CVEs in software versions, missing patches, configuration weaknesses, and other findings that match known vulnerability signatures.
What a vulnerability assessment proves: Potential vulnerabilities exist in the defined scope. The assessment produces a finding list of potential issues ranked by severity, based on signature matching against known vulnerability databases. It is comprehensive for the vulnerability classes that have known signatures and broad coverage for the defined scope.
What a vulnerability assessment does not prove: Whether those potential vulnerabilities are actually exploitable in this specific environment. A vulnerability assessment that flags "potential SQL injection" in a login endpoint has matched a signature pattern: it has not confirmed that the SQL injection is exploitable, has not demonstrated data extraction, and has not assessed business impact. The finding is potential risk, not confirmed risk. Vulnerability prioritization: why exploit proof beats CVSS scores explains the distinction between potential and confirmed risk in prioritization. Penetration testing automation: beyond scripted scans maps where vulnerability assessment sits on the automation spectrum.
A vulnerability assessment also cannot find vulnerability classes that have no signatures: business logic flaws, multi-role authorization gaps, race conditions, and attack chains. Vulnerability management automation: where AI agents fit in the pipeline covers where vulnerability assessment fits within the broader vulnerability management programme.
When to commission a vulnerability assessment: When broad coverage of known vulnerability classes across a large scope is the priority. Pre-remediation to establish a baseline of known CVEs and configuration weaknesses. As a continuous scanning layer in the vulnerability management programme alongside more thorough periodic penetration testing. When the budget or timeline does not support a full penetration testing engagement. The assessment answers: "What potential vulnerabilities exist in this scope?"
VAPT (Vulnerability Assessment and Penetration Testing) is a combined engagement that runs a vulnerability assessment to identify potential findings, then applies penetration testing methodology to confirm which of those findings are exploitable and to discover additional vulnerabilities that scanning cannot find.
What VAPT proves: Both potential vulnerabilities exist and some of them are confirmed exploitable. The VAPT report contains two layers: the vulnerability assessment findings (potential risks with scanner-generated severity ratings) and the penetration testing findings (confirmed exploitable vulnerabilities with proof-of-exploitation evidence). What is inside a VAPT report covers the report structure in detail.
Why VAPT is commonly commissioned: Many compliance frameworks and security requirements specify "penetration testing and vulnerability assessment" as a combined requirement. PCI DSS requires both an internal vulnerability scan and a penetration test. Organisations commissioning their first engagement frequently want the breadth of the vulnerability assessment alongside the depth of the penetration test. The combined engagement provides a more complete picture than either alone.
What VAPT does not prove: VAPT is still a point-in-time engagement: it proves the state of the environment at the time of testing, not on an ongoing basis. Agentic pentesting and continuous security validation covers the continuous model that addresses the point-in-time limitation.
When to commission VAPT: When a compliance framework or contractual requirement specifies both vulnerability assessment and penetration testing. When the scope includes both infrastructure (suited to vulnerability assessment methodology) and applications (suited to penetration testing methodology). When a comprehensive first engagement is needed to establish a baseline across the full scope. The combined engagement answers: "What potential vulnerabilities exist and which ones are actually exploitable?"
Penetration testing is a structured attack simulation in which skilled testers (human experts or agentic AI systems) attempt to exploit vulnerabilities in a defined scope using attacker methodology. The testers form hypotheses based on observed application behaviour, design test cases, execute exploits, confirm exploitability with proof, and chain findings into realistic attack paths.
What penetration testing proves: Specific vulnerabilities in the defined scope are actually exploitable, with demonstrated business impact. Each confirmed finding comes with exploitation evidence: the specific payload, the response demonstrating successful exploitation, the data accessed or the action taken, and the attack chain that led to the finding. This is the evidence type that compliance frameworks specifically require when they mandate "penetration testing" rather than "vulnerability assessment." What's in a penetration testing report: a buyer's breakdown covers the evidence standard in detail.
Penetration testing also discovers vulnerability classes that vulnerability assessment cannot find: business logic flaws, multi-role authorization gaps, race conditions, injection vulnerabilities without existing signatures, and chained attack paths.
What penetration testing does not prove (without continuous coverage): A point-in-time penetration test proves the state of the environment at the testing date. Code deployed the next day is untested. For organisations shipping frequently, the gap between point-in-time tests and the current state of the application can be significant.
When to commission penetration testing: When a compliance framework explicitly requires penetration testing evidence: PCI DSS Requirement 11.4, SOC 2 auditor expectations for application security testing, ISO 27001 technical vulnerability management. When underwriters require penetration testing as a condition of cyber insurance coverage. Cyber insurance requirements: what underwriters expect from penetration testing covers what underwriters accept and what they reject. SOC 2 penetration testing: what auditors actually require covers the SOC 2 evidence standard specifically. The engagement answers: "Is this application or system actually exploitable, and can we confirm it with proof?"
| Engagement type | What it tests | What it proves | What it does not prove |
|---|---|---|---|
| Security audit | Policies, procedures, configurations | Controls exist and are operating | Controls hold under attack |
| Vulnerability assessment | Systems and applications via signature scanning | Potential vulnerabilities exist | Any findings are actually exploitable |
| VAPT | Systems + applications (scan + exploitation) | Potential vulnerabilities + confirmed exploits | Ongoing coverage after point-in-time engagement |
| Penetration testing | Applications, APIs, systems via active exploitation | Specific vulnerabilities are exploitable with proof | Controls operate correctly (audit's domain) |
PCI DSS: Requires both an internal vulnerability scan (quarterly, Requirement 11.3) and a penetration test (annually and after significant changes, Requirement 11.4). The scan satisfies the vulnerability assessment requirement; the penetration test must include active exploitation of discovered vulnerabilities. A vulnerability assessment alone does not satisfy Requirement 11.4.
SOC 2: Penetration testing is not explicitly mandated in the SOC 2 Trust Services Criteria, but the availability and security criteria that auditors evaluate are most credibly demonstrated through penetration testing evidence. Auditors increasingly expect penetration testing evidence for applications processing customer data. A security audit of controls is the foundation; penetration testing evidence demonstrates those controls have been tested under adversarial conditions.
ISO 27001: Requires technical vulnerability management (Annex A 8.8) and penetration testing is the standard mechanism for satisfying this requirement in application environments. Security audit evidence satisfies the information security management system requirements; technical vulnerability management evidence requires testing evidence.
Cyber insurance: Most carriers require penetration testing as a condition of coverage above basic limits. Underwriters who ask "do you conduct annual penetration testing?" and receive vulnerability assessment reports are increasingly distinguishing between the two and asking follow-up questions. Cyber insurance requirements: what underwriters expect from penetration testing covers the underwriting requirements in detail.
If the question is budget-driven, the prioritisation should reflect which evidence type is most needed:
Need to demonstrate control existence for a compliance audit: Security audit. No penetration testing required to satisfy this need.
Need to know what CVEs and configuration issues exist across a large infrastructure scope: Vulnerability assessment. Fast, broad coverage, suitable for establishing a CVE baseline.
Need to satisfy a compliance requirement that specifies both: VAPT. The combined engagement satisfies requirements that mandate both components.
Need to confirm exploitability with proof for a compliance framework that specifically requires penetration testing, for cyber insurance, or for genuine security validation: Penetration test. Nothing else satisfies this need. How much does penetration testing cost? a realistic breakdown covers pricing for each engagement type.
For penetration testing services in the US that produce confirmed exploitable findings with proof-of-exploitation evidence, VAPT services for the combined assessment and testing engagement, and PTaaS for continuous coverage beyond the point-in-time model, the 10x Pentest platform covers the application and API security testing layer. See pricing or get in touch to discuss which engagement type your compliance requirement or security programme needs.
Q1. What is the difference between a security audit and a penetration test?
A security audit reviews whether security controls exist, are documented, and are operating as required: it answers "do your controls exist and are they functioning?" A penetration test actively attempts to exploit vulnerabilities to determine whether those controls hold under attack: it answers "can an attacker breach your systems and what would they access?" The two produce different types of evidence. A security audit produces documented evidence of control existence suitable for compliance frameworks like ISO 27001 and SOC 2. A penetration test produces confirmed exploitable findings with proof-of-exploitation evidence suitable for compliance frameworks like PCI DSS Requirement 11.4 and for cyber insurance underwriting requirements. Both are valid; they answer different questions.
Q2. What is the difference between a vulnerability assessment and a penetration test?
A vulnerability assessment scans systems and applications to identify potential vulnerabilities through signature matching: CVEs in known software versions, configuration weaknesses, and known vulnerability patterns. It produces a list of potential risks. A penetration test actively attempts to exploit discovered vulnerabilities to confirm which are actually exploitable in the specific environment, producing confirmed findings with proof-of-exploitation evidence. The key difference is confirmation: a vulnerability assessment tells you what might be exploitable; a penetration test tells you what is exploitable. For compliance purposes, most frameworks that specify "penetration testing" require confirmation evidence that vulnerability assessments cannot provide.
Q3. What is VAPT?
VAPT (Vulnerability Assessment and Penetration Testing) is a combined engagement that includes both a vulnerability assessment (automated or semi-automated scanning to identify potential vulnerabilities broadly) and penetration testing (active exploitation to confirm which findings are exploitable and to discover vulnerability classes that scanning cannot find). The output is a two-layer report: scanner findings showing potential vulnerabilities and penetration testing findings showing confirmed exploitable vulnerabilities with exploitation evidence. VAPT is commonly required by compliance frameworks and enterprise customers that specify both components, and is particularly suitable for environments that include both infrastructure (suited to scanning methodology) and applications (suited to penetration testing methodology).
Q4. Does a vulnerability assessment satisfy PCI DSS penetration testing requirements?
No. PCI DSS Requirement 11.4 explicitly requires penetration testing: active attempts to confirm that vulnerabilities are exploitable, in addition to the separate vulnerability scanning requirements in Requirement 11.3. A vulnerability assessment satisfies the vulnerability scanning requirements; it does not satisfy the penetration testing requirement. PCI DSS Requirement 11.4 specifies that penetration testing must include exploitation of discovered vulnerabilities to validate their exploitability, which is the active exploitation component that vulnerability scanning does not provide. Submitting vulnerability assessment output in place of penetration test evidence will not satisfy a QSA review.
Q5. Which should I commission: a security audit, vulnerability assessment, VAPT, or penetration test?
The answer depends on what question you need answered and what compliance obligation you are satisfying. A security audit satisfies requirements for documented control evidence (ISO 27001 certification, SOC 2 control attestation, GDPR privacy controls). A vulnerability assessment is appropriate for broad CVE coverage across large infrastructure scope or as a continuous scanning baseline. VAPT is appropriate when a compliance requirement specifies both components or when a comprehensive first engagement is needed. A penetration test is required when a compliance framework explicitly mandates active exploitation evidence (PCI DSS Requirement 11.4), when cyber insurance underwriters require penetration testing, or when genuine security validation (confirmed exploitability with proof) is the objective. If you are uncertain which your compliance framework requires, read the specific requirement language: "penetration testing" means active exploitation evidence; "vulnerability assessment" means scanning evidence; "security audit" means control existence evidence.
A gap analysis maps where your security controls fall short of a framework or baseline. Penetration testing then confirms which gaps are actually exploitable. This guide covers how to conduct both and what each produces.
Tejas Dhokane Oct 12, 2026 
CVSS scores rate how severe a vulnerability could be. Exploit proof shows what an attacker can actually do to your systems right now. They are different types of evidence, and prioritization should treat them differently.
Tejas Dhokane Oct 9, 2026 
ASPM consolidates AppSec tool findings into a unified risk view. But the tools it aggregates mostly identify potential vulnerabilities not confirmed ones. Continuous pentesting fills the validation gap that ASPM platforms reference but do not provide.
Tejas Dhokane Oct 9, 2026 Schedule a free consultation and see how teams like yours are strengthening their security posture — continuously.
