Vulnerability assessment and penetration testing are two distinct security disciplines that together form a complete picture of your attack surface. A vulnerability assessment is a systematic process of identifying, classifying, and prioritising security weaknesses across your systems. Penetration testing goes further: a skilled tester actively tries to exploit those weaknesses to prove whether they are genuinely dangerous. Understanding where one ends and the other begins is what separates a mature security programme from a compliance checkbox exercise.
Most organisations run one or the other when the budget review comes around, then wonder why incidents still happen. The gap between scanning for vulnerabilities and confirming an attacker cannot reach your crown-jewel data is exactly what a combined VAPT engagement is designed to close. This article walks through the methodology, scoping decisions, reporting expectations, and the UK CREST accreditation context that should inform every engagement you commission, as of 2026.
Vulnerability Assessment vs Penetration Testing: What Each One Actually Measures
The confusion between these two disciplines is understandable because vendors often use the terms interchangeably for commercial reasons. They measure fundamentally different things.
A vulnerability assessment is breadth-first. You deploy automated scanners, such as Nessus, Qualys, or Rapid7 InsightVM, against a defined scope, and the output is a prioritised list of known weaknesses mapped to CVE identifiers and CVSS scores. The process tells you what is exposed. It does not tell you whether those exposures are exploitable in your specific environment, whether a misconfigured firewall rule prevents access, or whether compensating controls elsewhere in the stack reduce the real-world risk.
A penetration test is depth-first. A tester, or a small team, is given defined scope and rules of engagement, then attempts to chain vulnerabilities into an actual attack path. The goal is to reach a pre-agreed objective: domain admin access, extraction of a test dataset, or lateral movement into a segmented network. A finding in a penetration test carries one critical piece of information a scanner cannot provide: proof that the vulnerability is exploitable under realistic conditions.
| Attribute | Vulnerability Assessment | Penetration Testing |
|---|---|---|
| Primary method | Automated scanning | Manual exploitation with tool support |
| Output | Prioritised vulnerability list (CVE/CVSS) | Proven attack paths with evidence |
| Depth | Broad coverage, shallow confirmation | Narrow scope, deep validation |
| Duration | Hours to days | Days to weeks |
| Cost | Lower | Higher |
| Best for | Continuous hygiene, patch validation | Pre-launch assurance, compliance, M&A due diligence |
| False positive rate | High without manual triage | Low (exploitability is confirmed) |
The honest observation from fieldwork is that many organisations treat their quarterly scan report as security assurance. It is not. A CVSS 9.8 critical rating means a vulnerability is severe in the abstract; it does not mean an attacker can reach it from the internet through your specific network topology. That confirmation requires a tester who can think creatively about your environment rather than a scanner that works from a fixed signature database.
When to Run a Vulnerability Assessment and When to Commission a Penetration Test
The decision is rarely binary. Most mature programmes run both, but at different frequencies and for different purposes.
You should run vulnerability assessments continuously, or at minimum monthly, as part of your broader threat and vulnerability management programme. They are particularly useful after patch cycles, infrastructure changes, or new deployments, where you need rapid confirmation that the change did not introduce a regression.
Commission a penetration test when the stakes of a compromise are highest. Pre-launch assurance for a new application or API is the most common trigger. Regulatory frameworks including PCI DSS (Requirement 11.4), ISO 27001 (Annex A control 8.8), and the UK NCSC Cyber Essentials Plus scheme all specify penetration testing at defined intervals or after significant change. The NCSC guidance at ncsc.gov.uk states clearly that organisations should use CREST-accredited testers for any engagement that touches sensitive systems.
Mergers and acquisitions are a frequently overlooked trigger. Inheriting an unknown infrastructure without independent assurance is a well-documented route to post-acquisition breach, and the VAPT report becomes a negotiating data point as much as a security document.
How a Combined VAPT Engagement Is Structured
Running vulnerability assessment and penetration testing as a single integrated engagement rather than two separate exercises produces a materially better output. Here is how a properly structured VAPT engagement runs.
Scoping and Rules of Engagement
Scoping determines what is in bounds, what is explicitly excluded, and what the tester is authorised to do if they gain an initial foothold. Poor scoping is the single biggest cause of VAPT reports that fail to answer the question the client actually needed answered.
The scoping document should define: IP ranges and hostnames in scope; any cloud accounts or SaaS applications included; whether social engineering is permitted; whether physical access attempts are in scope; the testing window (business hours only versus round-the-clock); and the emergency contacts if a live system is inadvertently affected.
The Penetration Testing Execution Standard (PTES) provides a detailed framework for pre-engagement interactions that covers all of these elements. The OWASP Testing Guide v4.2, available at owasp.org, handles the web application equivalent and is the reference most CREST-accredited testers use for application-layer engagements.
Reconnaissance and Scanning Phase
The engagement opens with passive and active reconnaissance. Passive reconnaissance uses open-source intelligence: DNS records, certificate transparency logs, job postings that reveal your technology stack, and data from breach databases. Active reconnaissance touches your systems directly, mapping open ports, service banners, and technology fingerprints.
This phase transitions into the vulnerability assessment proper: automated scans against the defined scope, with manual triage to eliminate false positives. NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment, defines four phases for technical security testing: planning, discovery, attack, and reporting. The discovery phase maps almost directly to what practitioners call the vulnerability assessment component of a VAPT engagement.
Exploitation and Post-Exploitation
This is where penetration testing separates itself from scanning. The tester selects findings from the discovery phase that appear exploitable and attempts to confirm them. A successful exploit is only the beginning; post-exploitation work determines what an attacker could actually do with that access.
Post-exploitation typically covers: privilege escalation attempts; lateral movement across network segments; credential harvesting from compromised hosts; data exfiltration testing against defined target datasets; and persistence mechanism planting (in agreed testing scenarios). The objective is not to cause damage but to demonstrate the realistic impact of a breach, which is the information a risk owner needs to make an informed remediation investment decision.
For web applications specifically, the attack methodology follows the OWASP Top 10 as a baseline, expanded by the OWASP Testing Guide to cover authentication bypass, business logic flaws, and API security. If your application includes custom authentication flows or exposes an API surface, you almost certainly need web application penetration testing as a distinct workstream within the broader engagement.
Reporting and Evidence Package
A VAPT report that does not produce an actionable remediation roadmap has failed its primary purpose. The report anatomy matters as much as the testing quality.
A well-constructed VAPT report contains the following components. The executive summary presents the overall risk posture in non-technical language, suitable for board-level review, covering what was tested, what was found, and what the business impact of the most critical findings would be. The technical findings section documents each vulnerability with: a description of the issue; proof-of-concept evidence (screenshot, HTTP request/response, or command output); the affected component; the risk rating using CVSS v3.1 or CVSS v4.0 scoring; and a prioritised remediation recommendation with a specific version target or configuration change. The remediation section maps findings to precise actions, not generic posture advice. Finally, the retest section defines the conditions under which the tester will verify that critical and high findings have been correctly remediated, producing a fresh evidence package as confirmation.
The retest is not optional for compliance-driven engagements. PCI DSS 4.0 requires evidence that vulnerabilities identified through penetration testing have been corrected and that testing was repeated to verify the corrections.
CREST Accreditation and Why It Matters for UK Engagements
In the UK, CREST (the Council of Registered Ethical Security Testers) is the primary professional body for penetration testing accreditation. CREST-accredited organisations have demonstrated that their testing methodologies, staff qualifications, and quality assurance processes meet a defined standard. Individual testers hold certifications at different levels: CREST Registered Tester (CRT) for infrastructure, CREST Certified Web Application Tester (CCT APP) for applications, and CREST Certified Infrastructure Tester (CCT INF) for network-layer work. Each certification requires a formal examination, and the accreditation body audits member firms annually. This matters to buyers because it provides an objective basis for comparing suppliers beyond their own marketing claims, and because many regulated sectors treat CREST accreditation as a minimum procurement requirement rather than a nice-to-have signal of quality.
As of 2026, most regulated UK sectors, including financial services firms supervised by the FCA, NHS digital suppliers, and central government bodies operating under the GovAssure scheme, require CREST-accredited providers for assurance testing. If your supplier cannot provide a CREST certificate of accreditation, their report will not satisfy your auditor regardless of the technical quality of the work.
TIBER-EU engagements, the red team framework used by the Bank of England and European Central Bank for financial infrastructure testing, sit above standard VAPT in scope and sophistication, but they are built on the same foundational methodology. Understanding VAPT well is the prerequisite for commissioning or interpreting any more advanced assurance exercise.
How Often You Should Run VAPT and What Compliance Frameworks Require
Frequency depends on three factors: the pace of change in your environment, your regulatory obligations, and your risk appetite.
For vulnerability assessments, the baseline is monthly for internet-facing systems and quarterly for internal infrastructure, with an additional scan triggered by any significant change. This aligns with the NCSC guidance on vulnerability management and with the controls specified in NIST SP 800-53 (control RA-5, Vulnerability Monitoring and Scanning), documented at csrc.nist.gov.
For penetration testing, the minimum is annual for most frameworks, but the practical answer for organisations undergoing rapid development cycles is more frequent. Teams shipping code weekly cannot rely on a once-yearly point-in-time test to represent their current risk. Continuous penetration testing programmes, which combine scheduled engagements with ongoing automated penetration testing between cycles, are increasingly the standard for organisations that need assurance at the pace of their development pipeline.
The compliance requirements most commonly cited in UK and international engagements, as of 2026:
- PCI DSS 4.0: Annual penetration test; additional test after significant infrastructure or application changes (Requirement 11.4.3)
- ISO 27001:2022: No prescribed frequency; must be proportionate to risk, with evidence of testing in the ISMS documentation
- Cyber Essentials Plus: Annual assessment including a verified vulnerability scan of external-facing systems
- SOC 2 Type II: Penetration test typically required at least annually as evidence for the Availability and Security criteria
- DORA (EU Digital Operational Resilience Act): Threat-Led Penetration Testing for significant financial institutions on a three-year cycle, with vulnerability assessments continuous
- GovAssure (UK Cabinet Office): Annual cyber assessment for central government bodies, with penetration testing required for systems rated as high or very high risk
Common Scoping Mistakes That Invalidate VAPT Results
Scope creep and scope restriction are equally damaging. Both produce a report that does not reflect your actual risk.
The most common mistake is excluding cloud infrastructure from scope because it feels like the cloud provider’s responsibility. Your misconfigured S3 bucket is not AWS’s problem; it is yours. Infrastructure as code repositories, CI/CD pipelines, and identity provider configurations are attack surfaces that belong in scope for any realistic assessment of your environment.
The second mistake is testing a staging environment and presenting the results as representative of production. Staging environments often have weaker authentication, different network controls, and older software versions than production. A penetration test of staging tells you about staging. If your auditor asks whether production is secure, a staging test report is not the answer.
Third: agreeing to business-hours-only testing when your threat model includes adversaries who operate outside those hours. Ransomware groups and APT actors do not pause their operations because your change management window is closed. Rules of engagement should reflect the threat, not the tester’s convenience.
Interpreting VAPT Results and Driving Remediation
A VAPT report sitting unread in a shared drive three months after delivery is the most expensive document in your organisation. The value is in the remediation cycle, not the testing itself.
Triage findings by exploitability rather than CVSS score alone. A CVSS 9.8 vulnerability on an internal system accessible only from a management VLAN with strong authentication controls is operationally lower priority than a CVSS 7.5 finding on an unauthenticated internet-facing endpoint. Context collapses the score into a decision.
Assign owners for each finding at the point of report delivery, not after a committee review cycle. The longer a critical finding sits without an owner, the more likely it is to become a breach statistic. Set remediation SLAs in advance: critical findings addressed within 24 to 72 hours; high within two weeks; medium within 30 days. These timelines are not arbitrary; they reflect the average dwell time for actively exploited vulnerabilities before they appear in attacker toolkits. Document the owner assignment, the SLA, and the current status in a remediation tracker that is reviewed at least weekly by someone with authority to escalate. Without a tracker with live status, the report becomes a historical document rather than an active risk management tool.
Treat the retest as a gate, not a courtesy. Until the tester confirms remediation with an updated evidence package, the finding is open. A developer comment in a ticket saying the issue is fixed in the latest deploy is not evidence. A tester confirming they can no longer reproduce the exploit is evidence. The full cycle of vulnerability assessment and penetration testing only delivers value when remediation is treated with the same rigour as the testing itself.
Frequently Asked Questions
What is VAPT?
VAPT stands for vulnerability assessment and penetration testing. It describes a combined security engagement that first identifies weaknesses across your systems through automated scanning and manual review, then attempts to actively exploit those weaknesses to confirm which ones pose genuine risk. The two phases together produce a more complete picture of your attack surface than either approach alone.
What is the difference between vulnerability assessment and penetration testing?
A vulnerability assessment uses automated tools to identify and prioritise known security weaknesses, producing a broad list mapped to CVE identifiers and CVSS scores. A penetration test involves a skilled tester manually attempting to exploit vulnerabilities to prove they are genuinely exploitable under real-world conditions. Assessment tells you what is exposed; penetration testing tells you whether it can be breached.
How often should you run VAPT?
Vulnerability assessments should run monthly for internet-facing systems, quarterly for internal infrastructure, and after every significant change. Penetration testing is typically annual as a minimum under most compliance frameworks, including PCI DSS and ISO 27001, with additional tests triggered by major application launches, infrastructure migrations, or acquisitions. Higher-risk environments often run quarterly penetration tests.
What should a VAPT report include?
A complete VAPT report includes an executive summary suitable for board review, a technical findings section with proof-of-concept evidence and CVSS scores for each vulnerability, specific remediation recommendations mapped to each finding, and a retest plan confirming how critical and high findings will be verified after remediation. Reports without proof-of-concept evidence or specific remediation steps are incomplete.
