Most people first meet the word VAPT in someone else's document. A customer's security questionnaire asks for "a VAPT report from the last twelve months". A tender lists "VAPT audit" as an eligibility condition. An auditor notes that periodic security testing is missing from the control set. The request is usually terse, and whoever receives it has to work out what is being asked for, how much of it they need, and what would count as a satisfactory answer.
We answer those questions here from the tester's side of the table: what VAPT testing is, how a properly run engagement unfolds, what belongs in the report, what people mean when they ask for a "VAPT certificate", and when the report has to come from a CERT-In empanelled auditor specifically.
What VAPT stands for
VAPT is vulnerability assessment and penetration testing. It names two activities that are deliberately bought together.
The vulnerability assessment covers breadth. It systematically enumerates known weaknesses across a defined scope (outdated software, missing patches, weak TLS configuration, exposed services, misconfigured cloud resources), largely with automated tooling, and then triages the output to remove noise.
The penetration test covers depth. A skilled tester tries to exploit the system the way an attacker would: abusing authentication, crossing authorisation boundaries between users, pushing business workflows into states they were never meant to reach, and chaining individually minor issues into one serious outcome. This is manual work. It finds a class of flaw that scanners miss, because the flaw exists only in the logic of your particular application.
We have written separately about why a scan is not a VAPT, with a worked example of the kind of authorisation flaw that only a human finds. If a VAPT contains no meaningful manual testing, what you have actually bought is a vulnerability scan.
How a VAPT engagement runs
A well-run engagement follows the same sequence whatever is being tested, although the details differ from target to target.
1. Scoping
Everything else depends on scope, so it comes first. Scoping establishes exactly what will be tested (which applications, hostnames and IP ranges, API endpoints, mobile builds) and how. The useful questions are concrete. How many user roles exist? Which flows sit behind authentication? Will testing be black-box, with no credentials or internal knowledge, or credentialed? Is the target production, or a staging environment equivalent to production?
Scope also determines effort. A single web application with two roles is a different engagement from a mobile app with a partner API, and a quote that asks about neither has been priced without knowing what is to be tested.
2. Rules of engagement and authorisation
Before testing starts, both parties agree in writing what is permitted: in-scope targets, excluded techniques (denial-of-service and destructive payloads are commonly excluded or confined to staging), testing windows, the source IP addresses testers will use, and named escalation contacts on both sides. If testing touches infrastructure you do not own outright, such as a cloud provider, a hosting company or a third-party SaaS, their policies need checking as well.
This document has a real purpose. Testing a system without the owner's authorisation is an offence in most jurisdictions, and the rules of engagement are what separate a penetration test from an attack. They protect you too: if a critical issue turns up mid-engagement, the escalation path means you hear about it that day instead of weeks later in the final report.
3. Testing
Testing usually moves from discovery to exploitation. Testers map the attack surface, run automated assessment to establish the known-vulnerability baseline, validate what the tools report, and then spend most of their time on manual work: authentication and session handling, access control between users and roles, input handling, business logic, and whatever is specific to the target.
Reputable testers follow published methodologies so that coverage is systematic. For web applications that typically means the OWASP Web Security Testing Guide and the OWASP Top 10 risk categories; for APIs, the OWASP API Security Top 10; for mobile apps, OWASP's MASVS and MASTG; for infrastructure, frameworks such as NIST SP 800-115 or PTES. Following a methodology does not guarantee quality, but a tester who cannot name one is worth questioning.
4. Reporting
Findings are verified, rated and written up. This takes real time after active testing ends, because each finding needs evidence that someone else can reproduce. The next section covers what the report should contain.
5. Remediation and retest
Your engineers fix what was found. The tester then retests those specific findings to confirm each fix works and has not introduced anything new. The retest gives you evidence in place of a belief that the issue was fixed, and it is usually what an enterprise customer or auditor wants to see, since their concern is whether issues were closed rather than merely found.
What a good VAPT report contains
Most of the value of an engagement reaches you through the report. Testing that is not documented clearly enough to act on is worth very little, and a report that cannot withstand scrutiny from a customer's security team can cost you the deal it was meant to win. A sound VAPT report includes:
- An executive summary in plain language, covering what was tested, the overall risk picture and the few issues that matter most, for readers who will skip the technical sections.
- Scope and methodology. Exactly which targets were tested, the testing window, the approach (black-box, grey-box, credentialed), the standards followed, and anything explicitly out of scope. A reader should be able to tell what the report does not cover.
- Findings, each with:
- a clear title and description of the weakness;
- a severity rating, normally aligned to CVSS (the Common Vulnerability Scoring System maintained by FIRST) and adjusted for context, since a flaw on an internal admin tool and the same flaw on a public payments endpoint are not equally urgent;
- affected components, URLs or hosts;
- step-by-step reproduction instructions with request and response evidence or screenshots;
- the realistic impact, meaning what an attacker could actually do with it;
- specific remediation guidance written for developers, rather than copied boilerplate.
- Retest results, where a retest was performed, showing the status of each original finding.
Two warning signs come up in reports we are asked to review. One is findings with no reproduction steps, which the reader has to take on trust. The other is hundreds of unvalidated scanner items with their CVSS scores pasted in unchanged. Either suggests the manual half of the VAPT did not really happen.
Our own VAPT engagements follow this structure, with CVSS-aligned, prioritised findings, reproduction steps and developer-facing remediation, plus an executive summary and an optional retest.
Types of VAPT
"VAPT" describes an approach rather than a target. It is applied to several distinct surfaces, and each needs its own expertise:
- Web application VAPT: authentication, session management, access control, injection, cross-site scripting and business logic in browser-based applications. Most customer-mandated testing falls here. See web application security testing.
- API VAPT: REST, GraphQL and internal APIs, where broken object-level and function-level authorisation are the recurring serious findings. See API security testing and our walkthrough of how APIs actually fail in testing.
- Network and infrastructure VAPT: the external perimeter and internal networks, including exposed services, patching, segmentation, and what an attacker could reach after an initial foothold. See network security assessment.
- Mobile application VAPT: the app binary, local data storage, transport security, and the backend APIs the app talks to. See mobile application security testing.
- Cloud security assessment: identity and access configuration, storage exposure, network controls and logging across AWS, Azure or GCP accounts.
Most products span more than one of these. A SaaS platform with a web app, a public API and a mobile client has three attack surfaces, and a VAPT scoped to only one of them leaves the other two unexamined.
What a "VAPT certificate" actually is
Buyers often ask for a "VAPT certificate", and the term causes real confusion. There is no single, universal, regulator-issued VAPT certificate. People usually mean one of three things:
- The VAPT report itself, or a summary of it, from an independent tester. This is what most enterprise customers want: evidence that a competent third party tested the system recently.
- An attestation letter or certificate from the testing firm confirming that a defined scope was assessed during a stated period, and often that identified issues were remediated and retested. It lets you show that testing happened without handing a customer your full findings.
- A report from a CERT-In empanelled auditor, when the requirement comes from an Indian regulator, government body or tender. This is covered below.
Safe Tech AI issues assessment certificates of the second kind. Each one names the organisation, the assessment type, the parameters it was assessed against and a validity window, and anyone can confirm on our site that it is genuine. Such a document is an attestation that a stated scope was independently assessed at a point in time, and nothing more. Safe Tech AI is not an accredited certification body. Our certificate is not a regulatory certification, it is not a substitute for ISO 27001 or SOC 2, and it never claims that a system is unconditionally secure.
That last point applies to anyone's VAPT certificate. Be sceptical of any document that "certifies" a system as secure. Testing shows what was found within a scope and a time window; it cannot prove the absence of every flaw.
How often should you run VAPT?
There is no single correct cadence, but some defaults are sensible:
- At least annually for any system that handles customer data, payments, or multi-tenant separation. Annual third-party testing is what most security questionnaires and many compliance frameworks expect to see.
- Before and after significant change, such as a major release, a new authentication system, a new payments flow, a migration, or a change to how tenants are separated. Testing a release candidate costs less than testing after an incident.
- When a regulator or contract says so. Some frameworks and customer contracts specify the frequency. Where they do, treat it as the minimum rather than the goal.
- Continuously, for the automated half. Vulnerability scanning of infrastructure and dependencies should run far more often than manual testing, so that newly disclosed issues are caught between engagements.
If you are pursuing ISO 27001, periodic technical testing is a natural way to show that vulnerabilities are being managed, and auditors will generally want to see both the testing and what was done about the findings.
When you need a CERT-In empanelled auditor
CERT-In, the Indian Computer Emergency Response Team, empanels information security auditing organisations and publishes the current list of empanelled auditors on its website. Empanelment matters when the party asking for the report requires it, which in India is common in a few specific contexts:
- Government departments, public sector undertakings and public tenders frequently specify that security audits be carried out by a CERT-In empanelled organisation.
- Some sector regulators set the same expectation for the entities they regulate. SEBI's Cybersecurity and Cyber Resilience Framework (CSCRF), issued in August 2024, is a prominent example: its requirements point regulated entities to CERT-In empanelled IS auditing organisations for their audits and testing.
- Customer contracts, typically from banks, financial institutions or government-linked buyers, may write the same condition into their vendor requirements.
If none of these apply (for example, a private enterprise customer simply wants recent third-party penetration test evidence), empanelment is usually not required, and what matters is the quality and independence of the testing. If one of them does apply, check the requirement before testing begins, because it determines who must issue the report.
Safe Tech AI is not itself CERT-In empanelled. Where a regulator, tender or customer specifically requires a report from an empanelled organisation, we deliver the engagement with a CERT-In empanelled partner auditor so that the report meets the requirement. Raise it at scoping, since it affects who issues the report and the schedule. Our VAPT service page explains how this works.
Deciding what you need
Before you commission anything, it helps to have answers to three questions: which surfaces your customers and auditors actually care about (web app, API, mobile, network, cloud), whether the request in front of you names a cadence or a CERT-In empanelled auditor, and whether you need the full report or an attestation you can share. Those answers settle most of the scope, and they also tell you whether a certificate will satisfy the person asking or whether they expect the report itself.
If you are still working out what kind of testing you need, how much of it, and whether empanelment applies to you, our free 30-minute manual assessment is a reasonable place to start. A practitioner looks at what is reachable from outside and gives you an honest view of your sensible next step. Sometimes that is a full VAPT, sometimes a narrower test, and occasionally nothing at all yet.