How to Get a Safe-to-Host Certificate: The Process End to End

A safe-to-host certificate is issued after an eligible auditing organisation has tested your application on the staging or testing environment provided by your hosting service provider, you have closed the findings, and the auditor has retested them. Every scheduling decision on the project follows from that one sentence.

The rule that reshapes your release plan: the audit is performed on the staging server or testing environment provided by the hosting service provider before the certificate issues, and GIGW 3.0 statement 5.3.1 requires the audit clearance certificate to have been issued before hosting in the production environment. Two test events, one development cycle in between, and the go-live date on the far side of all three. Every instrument this page relies on is linked at the point it is used.

You get a safe-to-host certificate by appointing an eligible auditing organisation — NIC, STQC, an STQC-empanelled laboratory or a CERT-In-empanelled laboratory — agreeing the scope in writing, letting that organisation test the application on the staging or testing environment your hosting service provider supplies, fixing what the findings report raises, and having the auditor retest and confirm closure. The certificate is issued on the strength of that retest, and it is issued before the application is hosted in production, not after. There is no application form, no portal and no government approval step in the middle. The certificate is a deliverable of an audit engagement between you and an eligible auditing organisation. What makes it official is who signed it, and what they were required to do before signing.

Who this path is for. This is the GIGW route, and GIGW binds Indian government websites and applications at any organisational level, central and state, including district administrations and local governments — with browser-based intranet applications recommended to follow it too. If you are a private company and a tender asks you for “safe to host”, you are almost always being asked for a security audit certificate from an empanelled auditing organisation: the same engagement shape, the same staging rule, the same retest, without GIGW statement 5.3.1 sitting behind it. That distinction is worked through in safe-to-host versus a security audit certificate, and it is worth settling before you write a scope.

The instrument that requires it is GIGW 3.0 — the Guidelines for Indian Government Websites and Apps. The National Informatics Centre formulated the first GIGW in 2009 and the Department of Administrative Reforms and Public Grievances made it part of the Central Secretariat Manual of Office Procedure. Version 3.0 was formulated jointly with the STQC Directorate of MeitY and CERT-In, and its chapter on cybersecurity was formulated by CERT-In. Statement 5.3.1 states the requirement plainly: 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. The evaluator action under the same statement closes the loop: the evaluator shall check that the website, web application, web portal or mobile app under evaluation has a valid security audit certificate issued by one of those bodies, fulfilling CERT-In requirements. And GIGW’s own page on what is new in 3.0 uses the working name in its own voice — government organisations must continue to obtain a “safe to host” certificate issued by the cybersecurity auditors empanelled by CERT-In or STQC, or the auditors of STQC or NIC. For what the certificate is and is not, see the safe-to-host certificate explained. For who may sign one, see who can issue safe-to-host certificates.

Chapter 5 of the GIGW manual carries three cybersecurity statements: 5.3.1 the audit clearance certificate, 5.3.2 the hosting environment, 5.3.3 the security, privacy and contingency policies. The published web page mis-numbers the third as 5.3.2, so “5.3.2” appears twice on that page. Cite the manual, and if a tender or an evaluator quotes 5.3.2 at you, check which of the two they mean.

Three consequences reshape a release plan. The staging environment becomes a hard dependency with its own owner and date: no staging, no audit, no certificate, no hosting. Go-live moves to the far side of a sequence you only partly control — you own the remediation window, the auditor owns both test windows. And the environment tested has to be the environment you ship, because a certificate issued against a build you subsequently changed describes something that no longer exists.

There is a benefit hiding inside the constraint, worth saying out loud to a board that sees only delay. On staging the auditor can test properly: nobody holds back on authentication testing because the system is carrying live citizen traffic, and a broken test does not become an incident. The 2025 guidelines make the trade-off explicit for live systems — in critical environments where availability is a top priority, testing should be conducted in a passive manner to avoid downtime or service disruption. Passive testing is thinner testing. Staging is how you avoid having to choose.

One sentence in the 2025 guidelines cuts the other way and deserves reading before you book anything. Under 16.3, the final audit report is to be issued after closure of vulnerabilities and completion of the follow-up audit of the application hosted on the production environment. Where the audit scope is limited to the staging platform, the report must explicitly state that the audit was not conducted on the production environment. For a pre-go-live certificate there is no production yet, so expect that sentence to appear in your report — and agree at award what post-go-live confirmation looks like, rather than discovering the gap when an evaluator asks.

Take that run and remove a single item. None of these is a technical failure and none of them is unusual, but each one moves the whole tail of the plan.

Draw the plan as four blocks rather than as one bar labelled “audit”: staging readiness, the first test window, the remediation window, the retest window. Two of them respond to effort and two do not. Procurement and remediation compress when you start them early and name owners. The auditor’s two windows and the hosting provider’s change process do not compress at all, which is why a board that understands the split stops asking for the wrong compression.

Every one is a dependency on somebody outside the engineering team — procurement, legal, the hosting service provider, a sandbox owner, an accepting authority — and each becomes expensive because it was never on the plan as a task with an owner and a date.

One planning assumption is worth writing into the schedule rather than hoping for: allow one spare remediation-and-retest cycle. Not as a prediction about your application — as the difference between a plan that absorbs an ordinary outcome and one that escalates to a project board because of it.

“This Organization is empanelled by CERT-In for providing information Security Auditing Service”

That wording appears identically in three instruments: clause 4.2 of the empanelment terms, section 10.5 of the 2025 audit policy guidelines, and the 2018 auditor guidelines. All three add that no other words shall be used to describe the auditor’s relationship with CERT-In without prior written permission — for which the proposed wording and presentation must be submitted to CERT-In first — and that the CERT-In logo may not be used on publicity material, promotional material or a product without that permission either. Use it as a procurement filter: a firm advertising itself as CERT-In approved, CERT-In accredited or CERT-In authorised is describing a relationship in words the instrument does not permit, and doing it in public.

One clause in that list catches organisations by surprise more than the rest. The contract must expressly permit not only the auditor’s access to the system, but the association of representatives of CERT-In during audit assignments where needed — and clause 8.1 of the empanelment terms lets CERT-In review audit work and qualifications, carry out sample analysis, depute representatives to witness an audit, and seek the opinion of auditee organisations, because continued empanelment status depends on the quality of auditing services rendered. The auditor guidelines put the same point from the other side: CERT-In can be part of the audit team to assess the quality and maturity of the audit, and that should be communicated to the auditee. None of this makes CERT-In a party to your contract — clause 2.1 excludes that expressly — but it does mean your standard IT services template probably needs a clause it does not have.

One question deserves a deliberate answer rather than a default: whether staging holds real data. The comfortable answer is synthetic or masked data at realistic volume. The moment a production database is restored into staging, the auditor’s data-handling duties — India-only storage, encryption, forensic-grade wiping, a deletion certificate — attach to an environment that was probably not built for them. Those obligations are the auditor’s, but the decision to make them necessary is yours, and it should be recorded with a name against it.

The guideline says “hosting service provider” and stops there — it names a role, not a body. The four rows below are our own operational reading of what that role turns out to be on an Indian government project, offered as a planning aid rather than as anything published: each has a different request path, a different nodal owner and a different set of things it will not do. Work out which one you are dealing with before you promise a date.

Run this two working days before the window opens, not on the first morning. Everything on it is owned by somebody who is not in the audit meeting, which is precisely why it fails at the worst possible time when it is left to the day.

Two of those need a decision rather than a configuration change, and both should be recorded. Relaxing the web application firewall for the auditor’s sources is a deliberate choice: leave it blocking and the audit measures your firewall rather than your application. Turn it off entirely and you have tested an application that will never run that way. Detection-only for the auditor’s addresses, with the WAF itself reviewed separately, is the honest middle. And the same reasoning applies to rate limiting: a throttled scan produces a thin report, and a thin report produces a limitations section an evaluator will read.

The 2025 policy guidelines address the case directly. Where a website is hosted on a web server owned by another organisation, responsibility for auditing the web server, its operating system, the web hosting application software and the backend database software lies with the organisation that owns and operates the server. The website content owner remains responsible for ensuring the website data and software are audited by a CERT-In empanelled information security auditing organisation. That is the division, and writing it down is most of the work.

Three consequences follow for a tenant. First, your scope is the content, the configuration you control and any custom code or modules you own — not the platform. Say that in the scope document, because a report that is silent about it looks like a report with a gap. Second, a platform-level finding is raised through the platform’s own process and fixed on the platform’s own timeline, which you do not control. Ask the operator at the start what audit coverage already exists for the platform layer and get the answer in writing, because you may otherwise buy testing that is somebody else’s obligation. Third, the same guidelines set out what the report should explicitly certify in this situation: that the audited web application, including backend databases and scripts, is free from vulnerabilities and malicious code that could be exploited to compromise or gain unauthorised access — including escalated privileges — to the web server hosting the website. Read that sentence in your draft report before you accept it. It is the sentence that makes a tenant certificate mean something to the platform operator.

The practical failure mode is a department that assumes the platform’s certificate covers its own site, and a platform operator that assumes each tenant audits its own content. Both assumptions are reasonable and together they produce a live site nobody audited. Ask the question in writing and keep the answer with the evidence pack.

Read the first two rows together and you have the plainest procurement test in the whole instrument set: a published expectation that testing is not tool output, and a published warning against treating the OWASP Top 10 as a standard. Between them they give you a basis for rejecting a methodology section that is a list of scanners, without having to argue taste. For the adjacent question of what testing a non-government organisation buys under the same umbrella, see safe-to-host versus a security audit certificate, and for the testing service itself, penetration testing and VAPT.

Contents are one thing. Quality is another, and the published expectations cover that too. These eight come from the process expectations in the auditor guidelines, the auditee expectations at Annexure I of the empanelment terms, and the reporting section of the 2025 policy guidelines. They are the difference between a report you can act on and a report you have to interpret.

The closure-timelines rule is the one most often misreported elsewhere, so it is worth one precise sentence. The instruments require the timelines to be stated, but they publish no table of days per severity, and any page presenting one as a CERT-In requirement is inventing it. Settle your own numbers in procurement while they are abstract, because settling them after the findings exist turns a policy question into a negotiation about one specific embarrassing finding.

A retest goes faster when every finding arrives with the evidence of its own closure attached, and the shape of that evidence is the same whatever the finding class. Four artefacts per finding. The change itself — a code diff, a configuration export, a version manifest. The staging deployment reference that proves the change is in the environment the auditor will test. A reproduction of the auditor’s original request now failing, captured as request and response. Where a fix changed behaviour, a note of what to regression-check. Assemble these during remediation, not after the retest is booked.

The finding classes themselves — what recurs before go-live, why, and what closes each one — are worked through on why applications fail safe-to-host, which is the page to hand your development agency on the day the report lands.

Two sequencing notes save more time than any individual fix. First, batch the configuration findings and deploy them together on day one of the remediation window: headers, cookie attributes, error handling, banner suppression and default-path renaming are usually one change request between them, and closing eight findings on day one makes the remaining list legible. Second, start the architectural findings immediately even though they finish last, because an authorisation redesign discovered on day one of a three-week window is survivable and the same finding discovered on day twelve is not. The order that feels natural — easiest first, hardest last — is exactly backwards for anything that needs design time.

Every page tells you to write a risk acceptance and almost none of them says what goes in one or who may sign it. The signature is settled by the 2025 policy guidelines: risk treatment must be authorised and accepted by the head of the auditee organisation, and exceptions authorised by the head of the organisation, who is the owner of the application. The rest is a template — this one, with an example in each field.

A pre-audit review is not a rehearsal of the audit and it is not a second opinion. It is a deliberately narrow pass over the six defect classes that need design time rather than a patch, run early enough that finding one is a planning event rather than a crisis. It has no standing in any instrument. Its only justification is arithmetic. A finding that needs three weeks of design, discovered before the audit, costs three weeks of development. The same finding discovered in the findings report costs three weeks of the launch date.

One boundary to hold while doing it. CERT-In’s 2025 guidelines define conflict of interest to cover the same entity implementing controls and auditing them, or auditing while responsible for remediation. A pre-audit review sits firmly on the remediation side of that line, which is exactly why the organisation that runs it must not be the organisation that later signs the certificate. Where the two are the same, you have bought a rehearsal marked by the examiner.

The validity condition is where a project either builds a habit or builds a problem. The duty sits on the developer under GIGW 5.3.1, quoted exactly: conduct periodic auditing of Web Application — at least once in a year or as and when any changes are done in the source code, whichever is earlier. Published specimen certificates express the same rule from the certificate’s own side, as validity until a change in the hash value or the dynamic content, or one year from issue, whichever is earlier. Either way the trigger is not only the calendar — it is your release process. Put the source-code-change test into the change-approval checklist, because a re-audit nobody scheduled is a certificate that has quietly stopped describing what is running. The validity page works through the change-classification question in detail.

Two of those rows are answered by your hosting provider rather than by your development team, which is exactly why they should be asked during the audit window rather than at handover. A third is answered by your change board: the annual and source-code-change re-audit triggers belong in the release process, not in a diary. And the third statement in the GIGW cybersecurity chapter is worth a line of its own — the website must have a security policy, a privacy policy and a contingency management plan clearly defined and approved by the government organisation, with the Web Information Manager ensuring their implementation through the lifecycle. An evaluator compares the policies in the website quality manual against the ones published on the site, and then asks for the records the implementation generated. See GIGW compliance before go-live for the wider conformity picture, of which the safe-to-host certificate is one part.

One filing note, because it is easy to get wrong. The delivery rule that governs the report does not stop at delivery: a pack that enumerates your own vulnerabilities, including the ones you accepted, does not belong in a shared drive or a generic inbox because that was convenient during the project.