An enterprise customer's security questionnaire asks for your VAPT certificate. An auditor asks for the same thing before a SOC 2 or ISO 27001 report can be signed off. Neither of them tells you what the document is supposed to look like. So here is the short version: a VAPT engagement produces three artefacts — a full technical report, an executive summary written for people who do not read CVSS scores, and a short signed attestation issued after your fixes have been re-tested, which is the document most providers label the VAPT certificate. That attestation is not an accredited qualification. No standards body certifies an organisation as "VAPT certified". It is your testing provider stating on the record what was tested, when, by whom, under what methodology, and what was closed.
TL;DR
- You receive three documents, not one: a technical report, an executive summary, and a retest attestation — the thing people call the certificate.
- There is no accredited VAPT certificate standard. Credibility comes from the scope statement, the methodology, the tester credentials, the test dates and the retest evidence — never from the design of the PDF.
- A certificate issued before remediation says only that testing happened. One issued after retest says the findings were closed. Only the second ends an enterprise security review cleanly.
- Most buyers and auditors treat 12 months as the practical shelf life, and a major release or architecture change invalidates it sooner.
- Auditors read the scope statement and the retest section first. Everything else is supporting material.
On this page:
- What do you actually receive after a VAPT engagement?
- What a VAPT certificate is — and what it is not
- Anatomy of a real VAPT report, section by section
- Why does the retest certificate matter more than the first one?
- Who asks for a VAPT certificate, and what do they check?
- How long is a VAPT certificate valid, and what invalidates it?
- Red flags that make a VAPT certificate worthless
- Handing the certificate to an auditor, a customer or a bank
What do you actually receive after a VAPT engagement?
The deliverables set is the least documented part of a VAPT purchase and the part procurement cares about most. A competent engagement hands over four or five documents, each written for a different reader. A provider who only sends a certificate has sold you a cover page; one who only sends a 90-page technical report has left your compliance team nothing they can forward.
| Document | Who reads it | What it contains | When it is issued | Typical validity |
|---|---|---|---|---|
| Technical report | Your engineers; the auditor's technical reviewer | Every finding with severity, CVSS score, evidence, reproduction steps and remediation guidance | Within about a week of testing ending | Point-in-time — the build and dates tested |
| Executive summary | Your leadership; a customer's security or procurement team | Risk posture in business language, themes rather than tickets, usually two to four pages | Bundled with the technical report | Same as the report |
| Retest report | Engineering and the auditor | Which findings were re-tested and closed, which remain open, and the accepted-risk rationale | After you ship fixes, usually 30–90 days later | Point-in-time as at the retest date |
| Certificate / attestation letter | Auditors, enterprise procurement, banks, marketplaces | Named legal entity, scope tested, methodology, test and retest dates, testing firm and signature | Usually issued after the retest | Commonly treated as 12 months |
| Evidence pack (on request) | Your engineers | Request and response captures, screenshots, tool versions, raw scanner output | On request | Point-in-time |
Two things are worth settling in the statement of work before you sign. First, is the retest included, or quoted separately? Second, will the certificate be issued after testing or after the retest? Those two answers determine whether the document you eventually hand a customer says "we tested this" or "we tested this and the issues are closed". If you are still scoping the engagement itself, our walkthrough of what a VAPT audit covers and how it runs is the better starting point; this guide picks up at the paperwork.
What a VAPT certificate is — and what it is not
Be clear on this before you promise anything to a customer. There is no accreditation scheme that issues VAPT certificates to the organisations being tested. ISO 27001 works differently: an accredited certification body issues your certificate. Nothing equivalent exists for penetration testing. What is accredited is the testers — CREST accredits member companies and certifies individual professionals, and hands-on offensive credentials such as the OSCP from OffSec qualify the people doing the work.
So a VAPT certificate is an attestation: a signed statement from a testing provider about work they performed. That is not a weakness, provided everyone reading it understands what it is. An attestation from a firm with named, credentialed testers, an explicit scope and dated retest evidence carries real weight in a security review. A one-page PDF with a gold seal and no scope statement carries none.
A credible attestation names all of the following:
- The legal entity tested — your company name as it appears on contracts.
- The scope — named applications, domains, IP ranges, API surfaces, mobile builds or cloud accounts. "The web application" is not a scope.
- The methodology — normally the OWASP Web Security Testing Guide for applications and NIST SP 800-115 for the wider process.
- The test window — testing start and end dates, and separately the retest date.
- Who tested — the firm, and ideally the testers' credentials.
- The remediation position — whether findings were re-tested and closed, and what remains open.
- A signature, reference number and contact so a third party can verify it.
Anything missing from that list is a question you will be asked later, usually by someone with the power to hold up a contract. Choosing a provider that produces this properly is a separate exercise, covered in our guide to how to choose a VAPT company in India.
Anatomy of a real VAPT report, section by section
The certificate is the summary; the report is the substance. NIST SP 800-115, the canonical technical guide to security testing, describes a four-stage penetration testing methodology in which "the reporting phase occurs simultaneously with the other three phases", and states that at the conclusion of a test "a report is generally developed to describe identified vulnerabilities, present a risk rating, and give guidance on how to mitigate the discovered weaknesses". The OWASP Web Security Testing Guide reporting chapter goes further and specifies the structure below almost line for line.
1. Scope and rules of engagement
The first section an auditor reads. It records exactly what was in scope, what was explicitly excluded, whether testing was authenticated or unauthenticated, black box or grey box, and what was off-limits — production data, denial-of-service, social engineering. OWASP also expects version control, the testing team, a timeline and a disclaimer here.
2. Methodology
Which framework the testers worked to, and how manual testing was layered over automated scanning. A report that cannot name its methodology cannot be defended in an audit.
3. Executive summary
Written for non-technical leadership. OWASP's guidance is that this covers test objectives, "key findings in a business context, such as possible compliance issues, reputation damage", and strategic recommendations in plain language. Two to four pages. This is the part that gets forwarded.
4. Findings summary and per-finding detail
A ranked table of every finding, then a full entry for each: a reference ID, likelihood or exploitability, impact, a risk rating, a description with reproduction steps, and specific remediation guidance. Severity is normally expressed with CVSS, whose v4.0 specification is maintained by FIRST, and mapped to a CWE class. Two elements separate a penetration test from a printed scanner run: proof-of-concept evidence (the request and response, the screenshot, the exploit chain) and business impact stated in your terms rather than the scanner's generic description.
5. Remediation guidance
Specific enough to act on without a follow-up call. "Implement proper input validation" is a scanner string. "Parameterise the query at OrderController.php line 214 and revoke the shared DB role granted to the reporting service" is remediation guidance.
6. Retest results
What was re-tested, what closed, what stayed open, and what was formally risk-accepted with a named owner. This is the section auditors and enterprise buyers go to first after the scope.
7. Limitations and disclaimer
The honest boundary of the exercise: the test window, the build tested, environments not covered, and the fact that the assessment reflects a point in time. Its absence is a warning sign, not a bonus.
Missing sections are not cosmetic. Each one is a question an auditor or a buyer's security reviewer will ask you to answer in writing later.
Why does the retest certificate matter more than the first one?
Because a report full of open critical findings is evidence that you tested something, not evidence that you are secure. The retest converts the exercise into something you can hand over.
Compliance frameworks are explicit about this. PCI DSS v4.0 requirement 11.4.4 states that exploitable vulnerabilities and security weaknesses found during penetration testing are corrected in accordance with the entity's risk assessment and that "penetration testing is repeated to verify the corrections". The retest is not a courtesy add-on; for a card-handling environment it is the requirement.
Settle three things up front:
- Is the retest in the price? It is the single most commonly excluded line item, and the one your auditor will ask about.
- How long is the retest window? Thirty to ninety days from report delivery is typical. Miss it and you are buying a fresh engagement.
- What gets re-tested? Usually critical and high findings. If you want mediums verified too, say so in the statement of work.
The constraint is rarely the tester — it is how quickly you can ship fixes into production before the window closes. Teams with a mature pipeline close a retest in a fortnight; teams that batch releases quarterly miss the window and pay twice. If remediation velocity is your bottleneck, that is a delivery problem rather than a security one, and it is what our DevOps consulting and CI/CD consulting services exist to fix.
Who asks for a VAPT certificate, and what do they check?
Four buyers, four different reading habits.
SOC 2 and ISO 27001 auditors
They check that the scope in the report matches the system description or ISMS boundary you declared, that the test dates fall inside the audit period, that the tester was independent, and that critical and high findings were remediated and re-tested before the audit closed. They are looking for evidence of a working vulnerability management process, not a clean scoreboard — a report with findings that were fixed and verified is stronger evidence than a report with none. Our guide to VAPT for SOC 2 and ISO 27001 covers how the testing requirement sits inside each framework.
Enterprise procurement and security questionnaires
They check recency first — usually "within the last 12 months" — then whether the scope covers the product they are buying rather than your marketing site, then whether any critical findings remain open. Most large buyers accept an executive summary plus the attestation under NDA rather than insisting on the full technical report, which is fortunate: circulating reproduction steps for your own application is not something to do casually.
Indian fintech, and RBI-regulated entities
The requirement here is written down. The Reserve Bank of India's Master Direction on IT Governance, Risk, Controls and Assurance Practices states that for critical information systems, and those in the DMZ having customer interface, "VA shall be conducted at least once in every six months and PT at least once in 12 months", that regulated entities shall conduct VA/PT "throughout their lifecycle (pre-implementation, post implementation, after major changes, etc.)", that VA/PT "shall be conducted by appropriately trained and independent information security experts/ auditors", and that entities shall put in place a documented approach covering scope, coverage and a vulnerability scoring mechanism. Separately, CERT-In publishes a public list of empanelled information security auditing organisations, and Indian government tenders and several regulated buyers commonly specify that the audit be performed by an organisation on that list. If you are selling into that market, confirm the empanelment question before the engagement rather than after.
Marketplaces, banking partners and insurers
Payment aggregators, banking partners onboarding an integration, cloud marketplace listings and cyber-insurance underwriters commonly ask for a recent test report at onboarding or renewal. These reviewers want the attestation, the scope and the date — not the findings. Give them exactly that and the review moves fast.
How long is a VAPT certificate valid, and what invalidates it?
No issuing body sets an expiry, because no issuing body exists. In practice, 12 months is the convention that auditors and enterprise buyers apply, and several frameworks anchor it there: PCI DSS requires external penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change, and the RBI direction quoted above sets six-monthly VA and annual PT for critical systems.
The date on the certificate is not the real question, though. The real question is whether the thing that was tested still resembles the thing you are running. These invalidate a certificate long before its first birthday:
- A major release that changes authentication, authorisation, the payment flow or the data model.
- An architecture or infrastructure change — a new cloud account, a migration, a new ingress path, a change in tenancy model.
- A new environment or region that was not in the tested scope.
- A new third-party integration that widens the attack surface.
- A security incident, after which the honest position is that the previous test predates what you now know.
This is the structural limit of the artefact. A VAPT certificate is offensive, point-in-time evidence about a specific build — precisely what VAPT services are for. It says nothing about the over-permissive IAM role someone attaches next Tuesday. Continuous posture management and misconfiguration detection are a different discipline, covered by cloud security services, and stopping the same class of finding from reappearing every year belongs in the pipeline — the remit of DevSecOps consulting. If your last three reports found the same class of issue, the problem is not test coverage.
Red flags that make a VAPT certificate worthless
Any one of these should stop you from forwarding the document to a customer:
- No scope statement, or one so vague it could describe any company.
- No test dates — only an issue date and an expiry date. A validity window without a test window is decoration.
- No methodology named. Without OWASP WSTG, NIST SP 800-115 or an equivalent, an auditor cannot assess it.
- Issued the same week testing started, which certifies a scan, not a test.
- "Zero vulnerabilities found" on a live production application. Reviewers read that as shallow testing, not strength.
- A certificate with no report behind it. Ask for the report; if there is not one, there was no test worth the name.
- No retest and no remediation statement. The document then says only that someone looked.
- The vendor's own accreditations presented as yours. Their ISO 27001 certificate is evidence about them, not your application.
- No named signatory or verification contact.
Handing the certificate to an auditor, a customer or a bank
Decide what each audience gets. Auditors need the full report plus retest evidence. Enterprise customers and banking partners usually need the attestation and executive summary under NDA. Reproduction steps for live vulnerabilities should not circulate freely, and a provider relaxed about that is telling you something.
Write the two-sentence answer once. Most security questionnaires ask a variant of the same question, and a prepared answer saves a fortnight: "An independent third-party penetration test was performed against [scope] between [dates] using OWASP WSTG methodology. All critical and high findings were remediated and verified in a retest on [date]; the attestation and executive summary are available under NDA."
Track distribution and dates. Keep a register of who received which version, and diarise the next engagement roughly ten months after the last test date so evidence never lapses mid-deal.
Do not over-claim. Calling yourself "VAPT certified" in marketing copy invites a reviewer to ask who accredited you, and the honest answer is nobody. "Independently penetration tested, findings remediated and re-tested [date]" is both stronger and defensible.
Cost is deliberately out of scope here: it is priced per asset and varies by an order of magnitude between a scan and a compliance-grade manual engagement. Our breakdown of VAPT cost in India has the current bands.
If you need a VAPT engagement scoped so the deliverables actually satisfy the auditor, customer or regulator asking — with the retest and the attestation written into the statement of work rather than quoted later — review our VAPT services or talk to our team. We will work backwards from the evidence you have been asked to produce.
