The VAPT Certificate: What It Evidences

A customer has asked for "your VAPT certificate" and you do not have one. Or a document with that title has just landed and you are not sure what it is worth.

There is no standardised VAPT certificate. No authority defines its format, no body issues it, and no register records who holds one. It is a letter, written by the firm that did the testing, on their letterhead.

What it is

A certificate is a summary statement that accompanies the real deliverable, the report. It typically names the firm, the scope, the testing dates and the methodology, and states that the findings were remediated and verified.

Its value comes from who signed it, what it names, and whether a retest stands behind it. A certificate with no scope, no dates and no retest is a compliment printed on headed paper.

What it evidences

• That testing happened, by a specific firm, on specific dates.
• What was in scope, the part most recipients skim.
• That findings were closed, where the certificate follows a retest and says so.

What it does not evidence

That the system is secure. It records that somebody looked within a boundary, in a window, and that what they found was fixed. Everything outside the boundary is unexamined, and a narrow scope produces a clean certificate just as easily as a well-built system does.

That the system is still in the state described. A certificate describes a version on a date. If you have shipped since, it describes something that no longer exists.

That the testing was thorough. Nothing on the certificate distinguishes fifteen days of manual testing from an automated scan with a cover page. That distinction lives in the report, so ask for the report as well when the decision matters. What to look for in it is set out in what is actually inside a VAPT report. The side-by-side shows how to tell a written finding from tool output.

Who asks for one, and what they are really asking

Enterprise customers, through security questionnaires and vendor onboarding. It is usually the least demanding audience, since a certificate naming a relevant scope and a recent date satisfies most questionnaires.

Regulated organisations passing an obligation down their supply chain. Here the requirement usually originates in a framework that binds your customer. Read the wording, because what they need may be the report and the closure document, not a summary.

Tender and procurement processes, particularly in the public sector, which frequently specify who the auditor must be as well as what the document must say.

Marketplaces, app stores and payment partners, as a precondition of listing or integration.

Where the auditor's identity becomes the requirement

For many Indian requirements, the certificate is accepted only if it comes from a CERT-In empanelled auditing organisation. More good documents fail on this point than on any other. The testing was competent, the report is thorough, and the certificate is refused because the firm is not on the register.

Establish this before you commission the work. A public register settles whether a given firm is genuinely empanelled. For the ways that claim goes wrong, see how to check an auditor is really CERT-In empanelled.

The five things a useful certificate states

1. The scope, specifically: the application, environment, URLs or address ranges. Not "the client's IT infrastructure".
2. The testing dates, listed separately from the issue date.
3. The methodology, named: OWASP, PTES, NIST SP 800-115, not "industry best practice".
4. The auditor's identity and standing, including empanelment where it is relied on.
5. The closure position: that findings were remediated and retested, with the retest date. A certificate issued before the retest certifies that testing occurred, not that anything was fixed.

Validity, and what "one year" means

Certificates are conventionally treated as valid for twelve months. That convention comes from audit cycles and not from the document itself. Nothing expires, because the certificate describes a past event.

As time passes, that description tells you less about the system you are running today. A twelve-month convention is a reasonable default for a stable system and a poor one for something released weekly, so test on significant change as well as on the calendar. That trade-off is in how often you should run a VAPT.

If you are the one being asked

Ask what the requester needs before you commission anything. "Send us your VAPT certificate" can mean a summary letter, the full report under NDA, evidence for a named framework, or a completed questionnaire. Each is a different piece of work, and asking first is cheaper than buying the wrong one. See how a VAPT scope gets sized before you agree to anything.