Safe-to-Host, Security Audit Certificate and VAPT Report: Not the Same Thing.

Four names turn up in Indian tender documents as though they were synonyms. Three of them are different artefacts with different issuers, different contents and different purposes. The fourth is not an artefact at all — it is a property of whoever signed one of the other three.

The distinction that resolves most of them: a report carries findings, a certificate carries a conclusion, “safe to host” names the gate a certificate is being used to open, and “CERT-In empanelled” describes the organisation whose letterhead it sits on. Those are three different questions, and a single tender clause often answers only one of them.

A VAPT report is the technical deliverable that records what testing found. A security audit certificate is a short attestation, issued by the auditing organisation after remediation has been verified, that the named asset is clear as at that date. A safe-to-host certificate is that same certificate issued for one specific purpose — satisfying GIGW 3.0 guideline 5.3.1, which requires an audit clearance certificate before a government website, web application, web portal or mobile app is hosted in the production environment. And a “CERT-In empanelled audit report” is not a fourth document: it is any of the above, signed by an organisation that appears on CERT-In’s empanelment list. Indian tenders use all four names interchangeably, and the resulting confusion is expensive in a very ordinary way — bidders price one artefact and are evaluated against another, hosting slips because the certificate names a hostname nobody is hosting, and procurement teams ask for a “CERT-In certificate”, an artefact that does not exist in that form because CERT-In empanels auditors rather than certifying auditees.

Everything asserted here about CERT-In, GIGW, STQC or NIC comes from five published documents, linked at the foot of the page and in the text as they come up: the Comprehensive Cyber Security Audit Policy Guidelines, version 1.0 of 25 July 2025, the Terms and Conditions for Empanelment, version 7.2 of April 2024, the Guidelines for CERT-In Empanelled Information Security Auditing Organizations, version 3.0 of May 2018, and the GIGW 3.0 cybersecurity guidelines and attributes. The fifth is the CERT-In Directions of 28 April 2022. Where this page offers a rule that is not in one of them, it says so in the same sentence.

The reason the names blur is that they are not alternatives to each other. They sit on three different axes — who signed the document, what form the document takes, and which gate the document opens — and a clause can specify any one axis while leaving the other two silent. Once you read a requirement that way, most ambiguity resolves itself, and the residue becomes a short, specific question you can put to the buyer in the pre-bid window without sounding like you have never done this before. This page sets out what each artefact actually is, who may issue it, what it is and is not evidence of, how to decode the clause in front of you, and what goes wrong when the decoding is skipped.

A fully specified requirement pins all three: a security audit certificate and the report behind it, signed by a CERT-In empanelled organisation, covering the named assets, issued before the asset is hosted in the production environment. Most real clauses pin one axis and leave two open. The skill is noticing which two are open before you price the work, rather than after an evaluator has told you.

India has a published contents format for this artefact, and almost nobody cites it. It is Annexure II to CERT-In’s Terms and Conditions for Empanelment, version 7.2, headed “Audit Report content format”, and it opens with the words the formal information security audit report is a key audit output and must contain the following. Ten items follow. They are the floor. On top of them sit the quality rules in the Comprehensive Cyber Security Audit Policy Guidelines v1.0 of 25 July 2025 and the older auditor guidelines v3.0 of May 2018, set out below the format.

Annexure II tells you what sections exist. It does not tell you whether the work behind them was real. That is what the quality rules do, and they are considerably more specific than most people who cite “CERT-In guidelines” in a tender have read. Eleven of them, with the instrument each comes from:

The discouragement of solely tools-based testing is worth dwelling on, because it inverts the signal most buyers read. It is easy to produce a hundred-page report from a scanner and hard to produce twelve pages of findings that required a human to reason about the application’s authorisation model. Page count therefore tells you nothing. What tells you a report is real is the presence of findings a tool could not have reached — broken access control between tenants, a business-logic bypass in a multi-step workflow, an authorisation check enforced in the interface and absent from the API. The 2025 guidelines give the reason in their own words: automated processes overlook the non-automated and manual components of the estate and produce an incomplete view of the overall security. For the wider question of how testing supports a compliance programme rather than a tender, see penetration testing and SOC 2 and security questionnaires.

Three of those fields do most of the work: the asset list, the build identity and the severity threshold. Write the asset list as strings that can be compared character by character against what is being hosted — not as a project name, not as a product name, not as a description. Where the production hostname is not yet allocated at audit time, agree in advance with the auditor and the buyer what will appear on the certificate and how the mapping will be evidenced, rather than discovering the gap at the hosting gate.

The requirement has a clause number and it is short. GIGW 3.0, guideline 5.3.1, inside the cybersecurity chapter, reads: “Website, web application, web portal or mobile app have been Security Audited and an Audit Clearance certificate has been issued by NIC/ STQC/ STQC empanelled laboratory/CERT-In empanelled laboratory before hosting in production environment.” That sentence carries the whole of the safe-to-host regime. The document it calls for is a security audit certificate, and “safe to host” is the operational name for the gate it opens. The same guideline tells the evaluator what to do with it — the evaluator shall check that the website has a valid security audit certificate issued by NIC/STQC/Cert-IN empaneled laboratory fulfilling Cert-IN requirements — which is why the gate is a paperwork check with a technical precondition rather than the reverse.

Note what 5.3.1 does not say. It does not name a validity period, prescribe a methodology, or describe how the gate is enforced in any particular department’s hosting workflow. What it fixes is a precondition and an issuer set. Around it, GIGW tells the department to ensure the host service provider and the developer adhere to industry best practices such as ISO 27001, OWASP ASVS, the OWASP Top 10 and CIS benchmarks, but CERT-In’s own 2025 guidelines go further and say in terms that limited lists such as the OWASP Top 10 and SANS Top 25 should not be treated as standards or references for audits, pointing instead at ISO/IEC, CERT-In’s Cyber Security Audit Baseline Requirements, OSSTMM3, the OWASP Web Security Testing Guide, OWASP ASVS and the OWASP Mobile Security Testing Guide. Both can be true at once: cover the Top 10, but do not mistake covering it for having done an audit.

Because the gate sits immediately before go-live, this is the artefact most exposed to late change: a release shipped between the follow-up audit and the hosting request leaves a certificate naming a hash nobody is running. The sequence, the evidence and the common failure modes are set out in how to get a safe-to-host certificate and why applications fail safe-to-host. The quality, accessibility and lifecycle-management attributes that sit alongside it in GIGW 3.0 are covered in GIGW compliance before go-live.

The Terms and Conditions for Empanelment are unusually strict about how an empanelled organisation may describe the relationship, and reading that rule is the fastest way to understand what empanelment is. Under clause 4.1 an auditor may not use the CERT-In logo, nor refer to its association with CERT-In on publicity or promotional material or on a product, without prior written permission from CERT-In. Clause 4.2 sets out the permitted description, a single prescribed sentence — “This Organization is empanelled by CERT-In for providing information Security Auditing Service” — and no other words may be used to describe the relationship without written permission either.

The consequence for an auditee is severe. If the organisation that did the work is restricted to one sentence about its own empanelment, the organisation that received the work has no standing to describe itself as CERT-In anything at all. The correct construction in a submission is factual and boring: name the empanelled organisation that performed the audit and signed the report, and let the certificate speak.

Empanelment runs for a block period with annual review based on auditee feedback and a review of the auditor’s performance, and clause 9.1 of the terms lets CERT-In terminate it at any time — for breach, for degradation of performance or competence, for unreported changes in the organisation’s foreign tie-ups or manpower, for lapses in audit assignments or in submitting reports and metadata to CERT-In, or for testing without the target’s prior written consent. Clause 9.3 then requires a terminated auditor to stop making any claim that could be read as valid empanelment. The practical instruction is short: check the published list of empanelled organisations yourself, rather than a supplier’s statement about itself, and keep the evidence of the check with the engagement file. The list and the scheme documents sit on CERT-In’s Cyber Security Assurance pages.

On the empanelled route, yes — and this is the fact that most changes a supplier decision, so it belongs in the open rather than in an annexure. Clause 3.2.2 of the empanelment terms makes it mandatory for the auditor to share the audit report and audit metadata related to information Security audits within 5 days of completion of audit with CERT-In as per format provided by CERT-In, and mandatory in the same window to report all critical vulnerabilities along with auditee details where they were raised during the audit and not fixed by the auditee even during follow-up audits. Clause 3.2.1 states the standing duty in the same terms: details of each and every audit conducted, along with auditee details. The 2025 policy guidelines restate the five-day rule at §10.6 and add that the data submitted will be kept confidential.

The consent position is set out at clause 3.1.7 and is worth reading twice: the auditing organization should not share the client’s data without explicit written permission from auditee. However, CERT-In empaneled auditing organizations shall provide the audit reports and data to CERT-In without explicit permission of auditee organization. You should also have been told this before the engagement began — the 2025 guidelines require the auditing organisation to inform the auditee, prior to commencement, about the requirement to share audit metadata and reports with CERT-In within five days of completion. None of this is an argument against the empanelled route, which is the only route that satisfies a clause naming the list. It is an argument for closing criticals before the follow-up audit rather than after it.

Three drafting rules make the difference. Bundle your questions into one submission rather than trickling them, because each separate query costs the buyer an administrative cycle and they remember who made them do it. Propose an answer to every question, so the cheapest response the buyer can give is “confirmed”. And state what you will do in the absence of an answer, which protects you if no corrigendum is issued and quietly gives the buyer a reason to answer.

The practical consequence is that a certificate is a release-gated artefact, not a calendar-gated one. Teams that diarise it annually are surprised twice: once when a release in month three ends the clearance early, and again when the re-audit turns out to be an audit rather than a signature. Teams that treat it as release-gated put a computable question into the change process — does this release change the artefact whose hash is printed on the certificate? The published wordings in full, and how to build the change rule, are in safe-to-host certificate validity.

The pattern across all eight is the same: the artefact was defined after the work started rather than before it. Both instruments point at the same discipline from the auditor’s side. The 2018 guidelines require the deliverable structure to be agreed with the auditee before commencement and the expectation gap to be closed by explaining the process, the artefacts and the deliverables upfront. The 2025 guidelines turn that into a list to work through before commencement: the type of audit, the format of the reports, the standards or frameworks to be used, the assets covered, the handling and retention of auditee data, the timeline of the assessment phase, and the requirement to share audit metadata and reports with CERT-In. An engagement that starts by answering those seven rarely ends in any of the rows above.

Notice how rarely the answer is “produce more testing”. In almost every row the decisive move is definitional — establish which gate is in play, which assets it attaches to, and who has to sign. The testing itself is the same craft throughout. Two further situations carry a sequence worth walking through rather than tabulating:

Read as a set, these rows describe a profession rather than a market. A scope of work that assumes the opposite — load-testing on demand, staff substituted at will, findings that stay in the room — is not buying an audit. It is buying a document.

Only one of these requires security expertise — reading how severity was graded — and the rest are document checks a procurement officer can run without help. The two that catch the most are the asset-name match and the date pair, and both are pure clerical work. The three that most often get skipped are the build identity, the follow-up audit and the signer check, because each requires leaving the document to go and look something up.

We deliver CERT-In audits, end to end, with our CERT-In empanelled partners. See how a CERT-In audit runs with us.

The part of the work that decides the outcome is getting the artefact defined before the engagement starts. Which document the clause is asking for. Which assets will be named on it, as strings. Which empanelment list applies, in its current published version. Which environment the testing will run against and who is standing it up. When the retest happens relative to the release train and the submission date. Those decisions are made in the first week or they are made in the last week, and the difference between the two is usually the difference between a clean submission and a reissue.

For application, API, mobile, network and cloud penetration testing, see our testing practice. For the regulated cases where a supervisor rather than a procurement officer is the reader, the artefact question is the same question and the answer is usually a programme rather than a document.

The empanelled-organisation list and the scheme documents sit on CERT-In’s Cyber Security Assurance pages, with the list itself published as a document that is periodically revised. A certificate published on iica.nic.in is a useful worked example of the field set described above. Where any of those documents disagrees with a vendor page, including this one, they win.