What is VAPT?

Definition and what the two halves mean

VAPT stands for Vulnerability Assessment and Penetration Testing. It is not a single standard published by an issuing authority. It is the common industry name for a security testing engagement that combines two distinct activities carried out against an agreed scope of systems, networks or applications.

A vulnerability assessment is broad and mostly automated. Scanning tools and configuration reviews are used to enumerate as many known weaknesses as possible across the target estate, and the findings are then validated by an analyst to remove false positives. The question it answers is what weaknesses exist.

A penetration test is narrow and manual. A tester works within agreed rules of engagement to see whether identified weaknesses can actually be exploited, whether they can be chained together, and how far an attacker could get. The question it answers is what an attacker could actually do with those weaknesses.

Because these two answer different questions, they are usually bought together. The assessment gives coverage and the penetration test gives proof of real world impact.

Who needs it and what triggers it

VAPT is commissioned by organisations that hold sensitive data or run internet facing systems, and it is very often driven by an external requirement rather than by choice. Common triggers include:

• A contractual clause with a customer or partner requiring independent testing before go live and periodically afterwards.
• A regulatory or standards requirement. ISO/IEC 27001 expects technical vulnerability management and testing of controls, PCI DSS requires internal and external penetration testing for cardholder data environments, and sector regulators in banking, healthcare and government commonly mandate it.
• A significant change, such as a new application release, a cloud migration, a new integration, or a merger that brings unfamiliar infrastructure into scope.
• Due diligence during fundraising, acquisition or vendor onboarding.
• Post incident assurance, where an organisation needs independent confirmation that a weakness has been closed.

Methods and standards testers work to

Although VAPT itself is not a certifiable standard, competent testing is not improvised. Assessors work to published, publicly available methodologies and scoring systems, and you should expect the proposal to name which ones apply to your scope:

• NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment, published by the National Institute of Standards and Technology. It sets out planning, execution and post execution phases for technical assessments.
• OWASP Web Security Testing Guide, the reference methodology for testing web applications, maintained by the OWASP Foundation.
• OWASP Top Ten, the awareness document describing the most critical web application security risks, used as a minimum coverage checklist rather than a full methodology.
• Penetration Testing Execution Standard, which describes the phases of an engagement from pre engagement interactions through to reporting.
• CVSS, the Common Vulnerability Scoring System maintained by FIRST, used to give each finding a comparable severity score.
• CVE identifiers, used to reference publicly known vulnerabilities unambiguously.

Scope is normally described as external network, internal network, web application, mobile application, cloud configuration, API, or wireless, and each is tested differently. Test perspective also matters: black box testing is done with no prior knowledge, grey box testing is done with limited credentials or documentation, and white box testing is done with full access to configuration and sometimes source code.

How assurance actually works for VAPT

This is where a great deal of confusion sits. VAPT is an engagement, not a management system standard. There is no issuing body, no accredited certification scheme, no Stage 1 and Stage 2 audit, no three year certificate and no annual surveillance visit. Nobody can be certified to VAPT, because there is nothing to be certified against.

What you receive at the end of an engagement is a report. A properly built report contains:

• The agreed scope, the test window, the rules of engagement and any exclusions.
• The methodology and tooling used.
• An executive summary that states the overall risk position in language a board can act on.
• Each finding with a severity rating, the affected asset, reproduction steps, evidence, and business impact.
• Practical remediation guidance for each finding, prioritised rather than presented as an undifferentiated list.
• A retest section confirming which findings were closed after remediation.

Some providers issue a letter of attestation or a summary certificate of testing after a retest confirms that high severity findings are closed. That letter is evidence that a test took place and what its outcome was. It is not an accredited certification, and it carries weight only to the extent that the testing organisation is credible. Where a client or regulator asks for assurance about the tester rather than the test, the recognised route is the individual and firm level credentials the testers hold, not a VAPT certificate.

How Univate approaches VAPT engagements

Univate scopes and runs testing engagements as part of wider security and compliance programmes. A typical engagement runs as follows:

• Scoping, in which the assets, environments, test perspective and constraints are agreed and written into the rules of engagement, including out of hours windows and escalation contacts.
• Authorisation, including written permission from asset owners and, where systems are hosted, notification to the cloud or hosting provider where their terms require it.
• Testing against the applicable methodology, with critical findings escalated immediately rather than held back for the report.
• Reporting with CVSS scored findings, evidence and remediation guidance mapped to the control framework the client is working to, whether that is ISO/IEC 27001, PCI DSS, ADHICS or a sector standard.
• Remediation support and a retest to confirm closure, with an updated report reflecting the final position.

Testing is scheduled around release cycles so that findings arrive when there is still time to fix them, rather than as a compliance formality just before an audit.

Frequently asked questions about VAPT

Is VAPT a certification?

No. VAPT is a security testing engagement, not a standard, so there is no issuing body and no certificate to be awarded. Some providers issue a letter or attestation confirming that testing took place and that findings were remediated, but that is evidence of a test, not an accredited certification.

What is the difference between a vulnerability assessment and a penetration test?

A vulnerability assessment is broad and largely automated, enumerating known weaknesses across the estate and validating them to remove false positives. A penetration test is narrow and manual, attempting to exploit weaknesses under agreed rules of engagement to establish what an attacker could actually achieve.

Which methodologies should a VAPT provider follow?

Expect the provider to name published methodologies relevant to the scope, such as NIST SP 800-115 for technical assessment generally, the OWASP Web Security Testing Guide for web applications, and the Penetration Testing Execution Standard for engagement structure. Findings should be scored using CVSS and referenced to CVE identifiers where applicable.

How often should VAPT be carried out?

Frequency is driven by change and by obligation rather than by a fixed rule. Most organisations test at least annually, and additionally after significant changes such as a major release, an infrastructure migration or a new internet facing service. Where a standard or contract specifies a frequency, that requirement governs.

What do we actually receive at the end of a VAPT engagement?

A report setting out the agreed scope and methodology, an executive summary, each finding with a severity rating, affected asset, reproduction steps, evidence and business impact, prioritised remediation guidance, and a retest section confirming which findings were closed.

Does ISO/IEC 27001 require VAPT?

ISO/IEC 27001 requires technical vulnerabilities to be managed and controls to be tested, and testing of this kind is the usual way organisations evidence that. The standard does not prescribe a particular testing product or provider, so the scope and frequency should follow the organisation’s own risk assessment.

Need an independent vulnerability assessment or penetration test scoped properly against your compliance obligations? Speak to the Univate team.

Univate Global delivers ISO certifications, data privacy compliance, and cybersecurity frameworks across 9 markets.