The VAPT Certificate: What It Evidences

People arrive at this subject from two directions. Either a customer has asked for "your VAPT certificate" and you do not have one, or you have just received a document with that title and are unsure what it is worth.

The first thing to know is that 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.

That is not a criticism. It is simply what the document is, and it determines everything about how much weight it can carry.

What it actually is

A certificate is a summary statement accompanying the real deliverable, which is the report. It typically says that a named firm tested a named scope between named dates, using a named methodology, and that the findings identified have been remediated and verified.

Its value comes entirely from three things: 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 — which is the part most often read carelessly by the person receiving it.
• 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 — and you have — it describes something that no longer exists in that form.

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, which is why anyone relying on a certificate for a decision that matters should ask for the report as well. What to look for in it is in what is actually inside a VAPT report, and how to tell a written finding from tool output is in the side-by-side.

Who asks for one, and what they are really asking

Enterprise customers, through security questionnaires and vendor onboarding. Usually the least demanding audience — 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 rather than you, and the specific wording matters, because what they need may be the report and the closure document rather than 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 a large class of Indian requirements, the certificate is only accepted if it comes from a CERT-In empanelled auditing organisation. This is the detail that most often invalidates an otherwise good document: the testing was competent, the report is thorough, and the certificate is refused because the firm is not on the register.

Establish this before commissioning, not after. Whether a given firm is genuinely empanelled is checkable in a public register, and the ways that claim goes wrong are set out in 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, and the issue date, which are not the same thing.
3. The methodology, named — OWASP, PTES, NIST SP 800-115 — rather than "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 rather than from anything about the document, and it is worth being clear that nothing expires — the certificate describes a past event, and a past event stays true.

What changes is how much the description tells you about now. A twelve-month convention is a reasonable default for a stable system and a poor one for something released weekly, which is the argument for testing 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 actually needs before commissioning 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. Those are four different pieces of work, and the cheapest mistake to avoid is buying the wrong one — see how a VAPT scope gets sized before agreeing anything.