What a Safe-to-Host Certificate Is, and Who Can Issue One
A safe-to-host certificate is the audit clearance an Indian government website, web application, portal or mobile app must hold before it is placed in a production hosting environment. It is signed by an independent auditing body, it names a specific build, and it says that the findings of a security audit have been closed and verified. It is not a security guarantee, and it is not the audit report.
The instrument behind the phrase: GIGW guideline 5.3.1 requires that the site or app has been security audited and an audit clearance certificate issued by NIC, STQC, an STQC-empanelled laboratory or a CERT-In empanelled laboratory — before hosting in the production environment. MeitY’s own GIGW 3.0 note calls the same thing a “safe to host” certificate.
Plain-English explainer · GIGW 3.0 · CERT-In Comprehensive Cyber Security Audit Policy Guidelines v1.0, 25 July 2025 · Empanelment terms v7.2, April 2024 · Last reviewed September 2026
A safe-to-host certificate is a signed statement from an independent auditing body that a named application, at a named version, has been security audited, that the vulnerabilities found have been closed and the closure verified, and that in the auditor’s opinion it is fit to be placed in a production hosting environment. It is issued by NIC, by STQC, by an STQC-empanelled laboratory, or by an information security auditing organisation empanelled by CERT-In — and by nobody else. The requirement is written in the Guidelines for Indian Government Websites and Apps, and the phrase is MeitY’s own. When a project authority asks for a safe-to-host certificate, the artefact they need is the audit clearance certificate GIGW describes.
“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.”
“Government organisations must continue to obtain a ‘safe to host’ certificate issued by the cybersecurity auditors empanelled by CERT-In/STQC or the auditors of STQC or NIC.”
Those two sentences settle a question the rest of the internet gets wrong in both directions. “Safe to host” is not a made-up vendor phrase: MeitY uses it. Nor is it a separate statutory instrument with its own registration, form or fee. There is one requirement — the audit clearance certificate at guideline 5.3.1 — under two names. One wording difference is worth noticing: GIGW writes “CERT-In empanelled laboratory”, while CERT-In’s own instruments and its published panel say empanelled information security auditing organisation. Same body, different drafting.
Everything difficult about these certificates follows from one property: the certificate is about a build, not about an organisation. An ISO 27001 certificate is about a management system and lasts three years with surveillance. A safe-to-host certificate is about the software you are deploying this week, so it expires the moment that software meaningfully changes. CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines (v1.0, 25 July 2025) put it as a two-part rule: every change goes through formal change management and is classified minor or major. Minor changes do not need an audit, major changes must undergo one before implementation — with an annual floor underneath both. A department that treats the certificate as an annual formality is out of compliance by its third release.
Key Takeaways
- A safe-to-host certificate is an audit clearance certificate: a signed opinion that a named application build was security audited, that findings were closed and verified, and that it may go into production. GIGW guideline 5.3.1 is the requirement behind the phrase.
- Four bodies may issue one — NIC, STQC, an STQC-empanelled laboratory, or a CERT-In empanelled organisation — across three routes. An internal security team cannot.
- The certificate is not the report. The certificate is circulated and carries a conclusion, while the report is restricted, follows the Annexure II content format in CERT-In’s empanelment terms, and is the only document that tells you how good the audit was.
- It attests a build at a point in time under a defined scope — not that the application is secure, that the hosting platform is hardened, or that anything outside the scope was examined.
- CERT-In empanelment is a standing, not an endorsement. CERT-In permits one sentence of description and prohibits its logo without prior written permission, so "CERT-In certified" is a phrase no compliant auditor uses.
- Validity is driven by change. Published specimens say one year from issue or until the hash or source changes, whichever is earlier. The guidelines set an annual floor and require an audit before any major change.
- The audit runs on the staging environment the hosting service provider supplies, and the final report issues only after closure of vulnerabilities and the follow-up audit.
Who it applies to, and what imposes it
Answered by organisation type. Every row names the instrument, because “our hosting provider says so” is not a requirement, and neither is a vendor’s opinion.
| Who you are, what you are hosting | Clearance required before go-live | Which document imposes it |
|---|---|---|
| Central government ministry, department or attached office | Yes, before hosting in production. This is the core case. | GIGW guideline 5.3.1. Where the application is critical and handles sensitive personally identifiable information, section 8 additionally makes MeitY’s 282-control-point Comprehensive Audit Program Checklist the default mandatory audit scope. |
| State department, directorate or district administration | Yes. The guideline covers Indian government websites and apps and is not limited to the Union government, and state data centres apply the same gate. | GIGW guideline 5.3.1, plus whatever the state IT or data-centre policy adds on top. |
| PSU, statutory body or autonomous body with a citizen-facing portal | Yes in practice. Whoever hosts applies the gate — a National Data Centre, a state data centre or an empanelled cloud service provider asks for the clearance before opening production. | Guideline 5.3.1 as applied by the hosting provider, plus the frequency and change rules in section 13.1.2 once live. |
| Private system integrator or product vendor building a government application | The certificate belongs to the department — but handing over a testable build, the staging environment, the version and hash, and the SAST output usually sits in your work order. | Guideline 5.3.1 reaches the department. Sections 9.4 and 13.1.3 put Secure by Design into the build RFP and require the developer supplying critical application software to perform SAST. |
| Application on a web server owned and operated by someone else | Split. Auditing the web server, its operating system, the web hosting software and the backend database software is the server owner’s responsibility, because the content owner has no access to them. | Section 13.1.5. The content owner still has to get the website data and software audited by a CERT-In empanelled organisation, and the report should certify that the audited application, backend databases and scripts are free from vulnerabilities and malicious code exploitable against the hosting web server. |
| Internal-only government application with no public URL | Still a production hosting decision, and departments treat it as in scope. The guideline speaks of hosting in production, not of public reachability. | Guideline 5.3.1, plus the annual floor in section 6: a comprehensive audit covering all aspects of the organisation’s ICT systems at least once a year. |
| Mobile app plus the API tier behind it | Yes, and as one scope. Guideline 5.3.1 names the mobile app. The APIs are a separate asset class that has to be enumerated or it will be missed. | Guideline 5.3.1 for the app. Section 6 treats mobile application security auditing and API security testing as distinct engagements, and section 13.1.1 requires the scope to cover APIs and databases. |
| Private company with no government customer | Not by that name. There is no safe-to-host gate for a commercial product, but the audit behind it frequently is required anyway. | The Directions of 28 April 2022 apply to service providers, intermediaries, data centres, body corporate and government organisations alike, and section 15.2.1 requires compliance with them to be verified in every audit assignment. |
The row most often got wrong is the fifth. Where an application sits on infrastructure the department does not own, section 13.1.5 splits the responsibility: two audits, two owners, one go-live date — and if nobody draws the line at scoping, each assumes the other has it.
One guideline, four documents behind it
People argue about safe-to-host certificates because they are arguing from four different documents without knowing it. The four sit in a chain, and the chain settles most of the disputes that reach a project review.
1. The Information Technology Act, 2000, section 70B
CERT-In exists because section 70B says it does. The Government appointed it as the national agency by notification dated 27 October 2009 under sub-section (1). Sub-section (4) prescribes its functions, sub-section (6) empowers it to call for information and give directions to service providers, intermediaries, data centres, body corporate and any other person, and sub-section (7) attaches punitive consequences. Section 2 of the audit policy guidelines sets out this chain.
2. The IT (CERT-In and Manner of Performing Functions and Duties) Rules, 2013
Notified on 16 January 2014 under sub-section (5). The audit policy guidelines state the position in terms: rule 9 of these Rules, among other things, prescribes the activity of information security assurance and audit to CERT-In. That is the rule under which CERT-In empanels information security auditing organisations at all, and the reason an empanelled auditor is a creature of subordinate legislation rather than of a commercial accreditation scheme.
3. GIGW — the Guidelines for Indian Government Websites and Apps
Published at guidelines.india.gov.in under MeitY. Guideline 5.3.1 carries the audit clearance requirement, and 5.3.2 separately requires the hosting environment to be secured for confidentiality, integrity and availability. GIGW 3.0 incorporates a chapter on cybersecurity formulated by CERT-In, to be read with CERT-In’s advisories as they are issued — which is why the GIGW wording and the CERT-In audit machinery read as one system. The same page tells departments where an identified web-application security incident goes: to NIC-CERT and CERT-In immediately, with CERT-In’s toll-free number alongside the two incident mailboxes.
4. CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines, v1.0, 25 July 2025
The newest and most operationally detailed of the four, and the one most people have not read. Section 2 states that it is issued in discharge of CERT-In’s statutory authority and is binding on all CERT-In empanelled auditing organisations and auditee entities covered under the relevant provisions. Section 6 lists twenty-six classes of engagement — from vulnerability assessment and penetration testing through cloud, OT and ICS, red teaming and AI system audits to SBOM, QBOM and AIBOM auditing. Read alongside the Terms and Conditions for Empanelment (version 7.2, April 2024) and the Guidelines for CERT-In Empanelled Information Security Auditing Organizations (version 3.0, May 2018), it is the closest thing India has to a professional standard for this work.
Two things follow from the chain. First, a safe-to-host certificate is not a statutory licence and CERT-In does not issue, approve or countersign one — it is a professional opinion produced under a contract between an auditee and an auditor, which a hosting provider then relies on. Clause 2.1 of CERT-In’s Terms and Conditions puts this beyond doubt: an auditor is contracted by a customer directly to perform information security audits, and CERT-In is not a party to such contracts. Second, the standing that makes the opinion acceptable belongs to the organisation, not to any individual in it, and it comes with rules about how it may be described.
“An Auditor may use the words ‘This Organization is empanelled by CERT-In for providing information Security Auditing Service’. No other words shall be used to describe the Auditor’s relationship with CERT-In without the prior written permission of CERT-In.”
That single sentence is the most useful vendor-screening tool in this field. An organisation that has read the terms it signed describes itself in exactly those words. One that puts the CERT-In emblem on a slide, or calls itself “CERT-In certified”, has either not read the terms or decided they do not apply to it — and you are about to rely on its judgement about your production systems. More on verification on who can issue safe-to-host certificates.
Every claim on this page, and the document behind it
Each row is a document we read in full, with the clauses this page relies on and a link to the official copy. Where these disagree with anything written here, they win.
- Guidelines for Indian Government Websites and Apps (GIGW 3.0) · MeitY. Guideline 5.3.1 (audit clearance before hosting in production), 5.3.2 (securing the hosting environment), and the NIC-CERT and CERT-In incident addresses. guidelines.india.gov.in/security-guidelines-and-attributes
- GIGW 3.0 — new features note · MeitY. The sentence that uses the phrase buyers search for, and the statement that GIGW 3.0 carries a cybersecurity chapter formulated by CERT-In. guidelines.india.gov.in/new-features-of-gigw-3-0
- Comprehensive Cyber Security Audit Policy Guidelines · CERT-In, MeitY — Version 1.0, 25 July 2025. Sections 6 to 19: the twenty-six classes of engagement, independence, applicable standards, auditee and auditor responsibilities, the signature architecture, the five-day reporting duty, selection of the auditor, scope and frequency, the change rule, staging and environment rules, CVSS and EPSS, closure and follow-up, and the consequences of non-compliance. cert-in.org.in/PDF/Comprehensive_Cyber_Security_Audit_Policy_Guidelines.pdf
- Terms and Conditions for Empanelment · CERT-In — Version 7.2, April 2024. Clause 2.1 (CERT-In is not a party to the contract), 3.1.7 and 3.2.2 (reporting to CERT-In), 3.1.10 (model NDA), 4.1 and 4.2 (logo and the one permitted sentence), 9.1 (grounds for termination), Annexure I (auditee expectations) and Annexure II (audit report content format). cert-in.org.in/PDF/termscon.pdf
- Guidelines for CERT-In Empanelled Information Security Auditing Organizations · CERT-In — Version 3.0, May 2018. Background checks and the no-objection rule when auditors move firms, declared manpower on government and critical-sector audits, staging-environment testing, the DDoS and flood-testing restrictions, and data handling inside India. cert-in.org.in/PDF/Auditor_Guidelines.pdf
- Directions under section 70B(6) of the IT Act, 2000, dated 28 April 2022 · CERT-In, No. 20(3)/2022-CERT-In. Directions (i) to (vi) and Annexure I: NTP synchronisation, six-hour incident reporting, the point of contact, 180 days of logs within Indian jurisdiction, and the twenty reportable incident classes. cert-in.org.in/PDF/CERT-In_Directions_70B_28.04.2022.pdf
- List of empanelled organisations and snapshot information · CERT-In. The published panel and the declared-manpower snapshot to check a bidder against before award. cert-in.org.in/PDF/Empanel_org.pdf
- Cyber Security Audit Baseline Requirements · CERT-In. The baseline section 8 says auditees and auditors should use to build the audit programme. cert-in.org.in/PDF/CyberSecurityAuditbaseline.pdf
Four bodies, and no fifth
GIGW names them as a list, and the list is closed. You will see it counted two ways and both are right: four named issuers across three organisational routes — the CERT-In route, the STQC route (STQC itself or a laboratory on its panel), and NIC. Use the four-way count in a contract, because the signature block will name one of the four. The column that matters when you are about to sign a work order is the last one.
| Issuer | What it is | When it is used | What to check before you award |
|---|---|---|---|
| NIC National Informatics Centre The NIC route | The technology partner of the Government of India under MeitY, mandated to design and develop IT systems for government and provide its ICT infrastructure. It runs its own security auditing and its own CERT — NIC-CERT, which GIGW names alongside CERT-In for reporting a web-application security incident. | Applications hosted on NIC infrastructure, where the hosting provider and the auditor sit inside one organisation, so audit and hosting approval move through one queue. | NIC audits what NIC hosts. If the application is moving to a private cloud, a state data centre or an empanelled cloud service provider, settle at scoping which body will sign — the certificate has to match the environment tested. |
| STQC Standardisation Testing and Quality Certification Directorate The STQC route | An attached office of MeitY, describing itself as a leading organisation for quality assurance in electronics and information technology. Its published services cover IT security testing, software testing and e-governance assessment, certification schemes including ISO 27001 and Common Criteria, and laboratory empanelment. | Projects where the department wants a government testing body rather than a commercial one, and procurements whose RFP names STQC. It is also the route for GIGW conformity assessment. | STQC and an STQC-empanelled laboratory are two different issuers in GIGW’s own list. If a bidder says STQC but means a laboratory on the panel, the distinction belongs in the contract, because the signature block will say which one it was. |
| STQC-empanelled laboratory A laboratory on the STQC panel The STQC route | A commercial testing laboratory that STQC has assessed and placed on its panel for a defined scope of conformity assessment. It is not STQC, and it does not become STQC by being on the panel. | Where a department wants the STQC lineage but needs commercial capacity and turnaround. | Panel membership has a scope and a period. Confirm both against the current STQC listing before award, and confirm the panel scope covers the testing this application needs. |
| CERT-In empanelled organisation An information security auditing organisation empanelled by CERT-In The CERT-In route | A commercial auditing organisation that has passed CERT-In’s empanelment process and accepted the Terms and Conditions, which empanel it to undertake audits including vulnerability assessment and penetration testing for government and other sectors. It is a standing, not a government appointment: clause 2.1 says an auditor is contracted by a customer directly and CERT-In is not a party to such contracts. | The route most RFPs name, and the only one of the four the private sector uses at scale. Section 12.1 says CERT-In’s snapshot information should be used by organisations or sectoral regulators to select auditing organisations. | Empanelment sits with the organisation, not the consultant who walks into the room — and sections 9.5, 10.3 and 16.1 say audit reports shall be signed only by manpower declared to CERT-In in the snapshot information. An empanelled firm also may not describe its CERT-In relationship in any words beyond the one sentence permitted, so a bid deck full of CERT-In logos is itself a finding. |
What empanelment means
CERT-In empanels information security auditing organisations to undertake audits including vulnerability assessment and penetration testing, for government and other sectors. It is reviewable: under clause 8.1 CERT-In may review the audit work and the qualifications of the people doing it, sample-analyse audit work, depute representatives to witness an audit in progress, and seek the opinion of auditee organisations. Continued empanelment depends on the quality of the services rendered.
What it does not mean
It is not an endorsement of a particular engagement, a guarantee of quality on your project, or a government warranty of the firm. Section 19 sets out a graded ladder for poor-quality audits and breaches of the terms: a watch list with warning and written commitment, suspension, debarment under the General Financial Rules and de-empanelment, and penal and legal action. That ladder is why empanelment is worth something, and why it is not a substitute for checking the firm yourself.
One nuance trips up procurement teams repeatedly. Sections 9.5, 10.3 and 16.1 all say the same thing: audit reports shall be signed only by the manpower declared to CERT-In, as listed in the organisation’s snapshot information on the CERT-In website. Section 10.2 adds that an organisation must only deploy manpower so declared. So the question in a bid evaluation is not whether the firm is empanelled but which declared auditors will be on the engagement and which declared Lead Auditor will sign. Where an auditor moves between empanelled organisations, section 12.3 requires a no-objection or relieving letter from the previous organisation and revised snapshot information to be communicated to CERT-In.
An opinion about a build, not a promise about a system
Most of the trouble these certificates cause comes from the gap between the two columns below. Departments read the certificate as an assurance that the application is safe. It is deliberately narrower, and the narrowness is what makes it meaningful.
What it attests
- That a named application, website, portal or mobile app — at a stated version, usually pinned by a hash — was security audited by the issuing organisation.
- That the audit ran against a stated methodology and standards, and that the environment tested is named — test, development, UAT, pre-production or production, as section 15.2.3 requires.
- That the vulnerabilities found have been closed and the closure verified, because section 16.3 requires the final report to issue after closure and completion of the follow-up audit on production.
- That in the issuer’s opinion the audited build carries no open finding above the severity threshold the parties agreed, and is fit to be placed in production hosting.
- That the people who signed did the work. Section 16.1 requires the certificate to be signed by the Lead Auditor and the head of the auditing organisation, and the report by the auditors, a mid-management reviewer outside the audit team, and the head of the organisation.
- That the audit verified compliance with the CERT-In Directions of 28 April 2022 — verification section 15.2.1 requires in every audit assignment, with findings and evidence in the report.
What it does not attest
- That the application is secure. It is an opinion about a build at a point in time, from a defined scope by a defined method. Section 9.1 puts responsibility for the posture on the auditee, not the auditor.
- That anything outside the agreed scope was looked at. Assets left off the asset inventory are assets the auditor never saw. A certificate is exactly as wide as the scope document behind it.
- That the hosting environment is secure. GIGW treats the audit clearance (5.3.1) and the securing of the hosting environment (5.3.2) as separate guidelines.
- That the department’s processes, staffing or governance are adequate. Those are audited when they are in scope and not otherwise.
- That the build in production is the build that was tested. Version numbers, hashes and timestamps carry that link — which is why section 9.5 says the developer should avoid code changes after issuance.
- That CERT-In, STQC or NIC has endorsed the application. None of them signs your certificate unless NIC or STQC did the audit, and CERT-In does not countersign individual certificates.
- That it is a licence, registration or statutory approval. It is a professional opinion under a contract, which a hosting provider relies on as a condition of go-live.
Section 9.1 is unusually explicit about responsibility: while audits are essential for identifying vulnerabilities and ensuring compliance, the responsibility for maintaining an efficient and robust cyber security posture ultimately rests with the auditee organisation, not the auditor. Section 8 adds that the audit should be viewed as a tool for continual improvement rather than a formality, and must not be conducted solely to fulfil a regulatory requirement. A department that procures a certificate as a box to tick will get one, and nothing else.
What a sound certificate says, field by field
There is no single national template — each issuing body writes its own — but published specimen certificates on government sites are consistent about which fields appear, and CERT-In’s guidelines dictate several outright. Work down the red-flag column on any certificate you are handed.
| Field | What a sound certificate states | Red flag |
|---|---|---|
| Auditee identification | The legal name and address of the body that owns the application, matching the work order and the entity that will host it. | A programme name, a project code, or the system integrator’s name. A certificate issued to the builder does not travel with the application. |
| Asset identification | Application name, hosting URL or hostname, mobile package identifier, and the API base paths if the API tier was in scope. | One URL, on a system with an admin console on a second hostname and an API on a third. Whatever is not named was not covered. |
| Version and hash | A version string and a cryptographic hash of the tested artefact with its algorithm. Sections 9.5 and 15.2.3 require them to be obtained from the auditee and prominently featured on the certificate. | No hash, or a hash with no algorithm and no record on the department’s side of how it was computed. The certificate then reconciles with nothing that is running. |
| Environment tested | A plain statement of test, development, UAT, pre-production or production. | Silence. If the certificate does not say, the report must — and where the scope was limited to staging, section 16.3 requires the report to say the audit was not conducted on production. |
| Audit period and issue date | A start and end date for the testing, and a separate date of issue. Weeks between the two is normal: that is the remediation and follow-up window. | A single date. |
| Standards and methodology | The methodologies used against the asset type, and the tools. Section 8 says limited lists such as the OWASP Top 10 are not standards for an audit, so a serious certificate names a testing guide. | “Industry best practices”, or the OWASP Top 10 alone. Either says the report will not map findings to a named test. |
| The conclusion sentence | A clear opinion that the audited build is fit to be hosted. Where a website sits on someone else’s web server, section 13.1.5 says the report should certify that the audited application, backend databases and scripts are free from vulnerabilities and malicious code exploitable against the hosting server. | A conclusion wider than the scope — a sentence about the system or the department where the scope covered one application. |
| Validity statement | An explicit validity line. Published specimens write it as one year from issue, or until a change to the hash or to the source of the tested application, whichever is earlier. | No validity line, or one that survives source-code changes. |
| Signatures | Two on the certificate: the Lead Auditor and the head of the auditing organisation, both declared to CERT-In in the snapshot information. | A single signature, an account manager’s signature, or a name absent from the declared manpower. A defect in the instrument, not a formality. |
| Report reference and the empanelment line | A pointer to the report the certificate summarises, by number or date. On a CERT-In-route certificate, the empanelment in the one permitted form. On an STQC-route one, the panel scope. | A CERT-In logo, or the words certified, approved, accredited or partner. And a certificate offered as the whole deliverable, with no report behind it. |
Two fields carry more weight than the rest: the hash, the only thing connecting the certificate to software, and the validity line, the only place it says when it stops being true. Reading a certificate you have been handed is a twenty-minute job with the report beside it — work down the red-flag column, then check both signatories against the issuing organisation’s declared manpower, verify the issuer using the sequence below, and read the report’s limitations and exemptions, which is where a thin audit confesses.
Two documents, two audiences
A safe-to-host engagement produces at least two deliverables and they are routinely confused. The certificate is short, conclusive and meant to be shared. The report is long, restricted, and the only place you can tell whether the audit was any good. More in safe-to-host versus security audit certificate.
| Axis | The certificate | The audit report |
|---|---|---|
| What it is | A one- or two-page signed instrument naming the auditee, the audited asset and version, the audit period, the standards used and the conclusion that it is fit to host. The hosting provider files it. | The full output: scope, duration, methodology, standards, tools, manual procedures, findings, prioritisation, sampling decisions, manpower involved, exemptions, limitations and constraints. The engineering team works from it. |
| Who signs it | The Lead Auditor and the head of the auditing organisation — director, partner or CEO — under section 16.1. | The auditors who conducted the audit, a mid-management reviewer who was not on the team, then the head of the organisation, authorising completeness, accuracy and integrity. Only declared manpower may sign. |
| What it contains | Identification, version and hash, the environment tested, the standards applied, the conclusion, the signatures, and — on every published specimen we have read — a validity statement. | The Annexure II content format in CERT-In’s empanelment terms: identification of the auditee, dates and locations, terms of reference including the standard used, the audit plan, explicit reference to key auditee documents by date or version, other applicable standards or regulations, a summary of findings including tests and tools used and results, an analysis of vulnerabilities, recommendations for action and follow-up audits, and the personnel involved including any trainees. |
| Who may see it | Circulated — to the hosting provider, the project authority, often the tender file. Written to be shared, which is why it carries a conclusion and not a vulnerability list. | Restricted. Communicated only to the specified point of contact, only by secure means, only from official email IDs. It is a map of how to attack the system until every finding is closed. |
| Where CERT-In sees it | Not filed with CERT-In. It is an artefact of a contract CERT-In is not a party to. | Reported. Clause 3.2.2 of the empanelment terms and section 10.6 of the 2025 guidelines both require the report and audit metadata to reach CERT-In within five days of completion, in the format CERT-In provides, and clause 3.1.7 adds that this happens without the auditee’s explicit permission. |
The five-day obligation in the bottom rows surprises most auditees. Section 10.6 makes it mandatory for the auditing organisation to give CERT-In information about the audits it carries out within five days of completion, in the prescribed format, and says that data is kept confidential. Clause 3.2.2 adds a second limb: critical vulnerabilities identified during the audit but not fixed even during follow-up audits must be reported, with auditee details, inside the same five days. Clause 3.1.7 closes the consent question — empanelled organisations provide reports and data to CERT-In without the explicit permission of the auditee.
The consequence is not that you should be wary of the audit: it is that an unfixed critical vulnerability has an escalation path built into the system. Section 16.6 adds the other half — auditee data must not be disclosed to any overseas entity or partner unless the auditee authorises it in writing.
The standard behind the signature
“Tested against industry best practices” is not a methodology statement. Section 8 names the references an audit programme is built from, and a competent report names the ones it used against the asset type. Start with the asset you are hosting.
| Asset type | Methodology the auditor should cite | What most often gets missed |
|---|---|---|
| Public web application or portal | OWASP Web Security Testing Guide for the testing, ASVS for the control set, and CERT-In’s Cyber Security Audit Baseline Requirements. | Authenticated testing at every privilege level. One read-only account removes the entire authorisation class of findings. |
| Admin console or back-office module | The same web guides against the administrative role matrix, plus a configuration audit of the hosting stack. | The console lives on a different hostname or port, never enters the asset inventory, and so never enters the scope. |
| Mobile application | OWASP Mobile Security Testing Guide, named in section 8, and mobile application security auditing is its own class of engagement in section 6. | The binary is tested and the rest is not. A mobile audit has to reach the binary, its local storage, its transport security and the APIs behind it. |
| API tier | API security audit, named in section 13.2.3 as an audit type and in section 6 inside application security testing for web, mobile and APIs. | The APIs belong to a different system integrator, so each scope assumes the other covered them. Enumerate base paths as assets with owners. |
| Cloud account and configuration | CSA Cloud Controls Matrix, named in section 8 for cloud security, with cloud security testing as its own class of engagement. | The shared-responsibility boundary is never drawn, so findings land on the side that cannot remediate them. |
| CI/CD pipeline | OWASP DevSecOps Maturity Model, named in section 8 for pipeline security. | Skipped entirely. This is why a certificate can be true about a build and not survive the next deployment. |
| Database | Database configuration audit, which section 13.1.3 requires for databases the auditee identifies as critical. Critical applications additionally require DAST and SAST. | Identification. The duty to identify critical databases sits with the auditee, and an unidentified one is out of scope. |
| Source code | Source code review, a named class of engagement, with SAST required of the developer in the procurement. | The integrator offers a binary and calls the code proprietary. Code review leaves the scope while staying in the certificate’s list of methods. |
Underneath the asset table sits the stack section 8 names: CERT-In’s Cyber Security Audit Baseline Requirements, ISO/IEC standards, the CSA Cloud Controls Matrix, OSSTMM 3 and the four OWASP guides above. Three rules in that section decide whether a report is worth reading. Limited lists such as the OWASP Top 10 and SANS Top 25 should not be considered standards or references for an audit. Solely tools-based testing is to be discouraged, and section 15.2.5 backs that with a maker-checker structure — a separate verification team reviewing the audit team’s work — so a bid that does not price a reviewer has not priced the guideline. And for critical applications, databases or platforms of ministries, departments, secretariats and offices where sensitive personally identifiable information is involved, section 8 makes MeitY’s Comprehensive Audit Program Checklist — 282 control points — the default mandatory audit scope. Most departments do not know it exists.
There are also things the auditor is required not to do. Under the 2018 guidelines and Annexure I of the empanelment terms, auditors refrain from distributed denial-of-service testing over the Internet and any flood testing, and from exploiting high-risk vulnerabilities. The 2025 guidelines require explicit written permission before any DoS, DDoS or flood testing, and say testing should be passive where availability is the priority. Social engineering must target only employees inside the agreed scope, by anonymised or statistical means, and must not involve customers, partners or vendors without specific written consent. Auditee data stays in India, encrypted on auditor laptops, and is wiped afterwards beyond any known forensic technique.
The 2022 Directions are inside your scope already
Section 15.2.1 requires every audit assignment to verify compliance with the Directions of 28 April 2022, with findings and relevant evidence in the report, and points at CERT-In’s published method-of-verification note. That holds whether or not your RFP mentions it. In practice the auditor asks for five things: (1) NTP configuration showing synchronisation to NIC or NPL or sources traceable to them, (2) an incident runbook that can deliver a report to CERT-In within six hours and that enumerates the twenty reportable classes at Annexure I rather than gesturing at them, (3) a current designated point of contact, because the Directions treat failure to furnish information as non-compliance, (4) log retention evidencing a rolling 180 days within Indian jurisdiction, across infrastructure and access logs and not only application logs, and (5) where the auditee is itself a data centre, cloud or VPN provider, the five-year records under Directions (v) and (vi).
One item deserves separate attention from anyone building with machine learning. The twentieth and last class at Annexure I covers attacks or malicious or suspicious activities affecting systems, servers, software or applications related to artificial intelligence and machine learning — so an AI incident is already mandatorily reportable. Section 6 lists AI system audits among its twenty-six classes of engagement.
Five decision points that decide the outcome
The engagement has many steps, but five change the result, set out here in the order CERT-In’s guidelines put them. Most delayed go-lives fail at the first or the last — a scope written from memory, or a follow-up audit nobody contracted for. The full walkthrough is on how to get a safe-to-host certificate.
- 01 Derive the scope from the asset inventory, and have it vetted Section 13.1.1 requires the scope to be derived from the consolidated and updated asset inventory, and the scope given to the auditor to be vetted by internal audit in consultation with the CISO. It should cover the whole cyber infrastructure — systems, web and mobile applications, network infrastructure, OT and ICS, cloud architecture, APIs, databases and hosting infrastructure, code review and incident-response testing — across testing, UAT, development and production. Critical databases attract a configuration audit, and critical applications attract DAST and SAST. This step decides whether the certificate is worth anything.
- 02 Select on evidence, and structure the commercials so the opinion cannot be bought Panel membership is a floor, not a recommendation. Section 12.2 puts the burden on the auditee to check the domain of audits conducted, methodology, tools and relevant-domain experience, to interview the resources, to verify identity and designations, and to confirm that freelancers, interns, freshers, moonlighters, third-party consultants and employees serving notice are not fielded. Then section 7: payments must not be contingent on the outcome of the audit, nor tied to the submission or approval of any closure report. A milestone that pays on certificate issued is how a department quietly destroys its own audit.
- 03 Sign the NDA and fix the terms of engagement in writing An NDA must be signed before any audit activity and be legally enforceable, and CERT-In publishes a model NDA that may be customised per project. The terms go into an engagement letter signed by both sides, fixing the audit criteria and standards, the plan and timelines, the deliverable structure and its secure handling, an escalation matrix for repeated vulnerabilities, and a clause to revalidate observations after the compliance window in the department’s own audit policy. Section 13.2.1 also requires the auditor to tell you, before the assignment starts, that the report and metadata reach CERT-In within five days of completion.
- 04 Test on the staging environment the hosting provider gives you Section 15.2.3 requires the auditor to test the website on the staging server or testing environment provided by the hosting service provider before issuing the certificate, to state the environment tested, and to obtain hash values and version numbers from the auditee for the report. Critical and high findings are notified during the audit as and when found, not held for the draft report.
- 05 Close, retest, issue — and freeze the build Patching is the auditee’s responsibility. Risk treatment is authorised by the head of the auditee organisation, and any exception by the head of the organisation that owns the application. Follow-up audits belong in the scope from the outset, and the auditor must revalidate the previous cycle’s observations. The final report issues after closure and the follow-up audit on production, and where the scope was limited to staging, it must say so. After the certificate issues, the developer should avoid code changes to the audited application or infrastructure.
Also named by the audit policy guidelines and worth open when you write a scope: the model NDA and the secure application design guidelines. §15.2.1(iv) also names a third, the “Method of verifications to compliance with CERT-In Directions issued on 28.04.2022”, which is deliberately not linked here: the cert-in.org.in path the guidelines print for it served the CERT-In home page rather than a document when it was last checked. Institutional descriptions come from stqc.gov.in and nic.in.
The closure threshold, severity by severity
“No open findings at the agreed severity threshold” is the sentence the whole engagement turns on, and almost nobody defines it. The scoring basis is fixed: CVSS for severity, supplemented with EPSS for real-world exploitation likelihood, every observation mapped to a CWE and a CVE. The authorisation is fixed too, and it is not the auditor’s.
| Severity | Scoring basis | Required state before the certificate issues | Who authorises a deviation | Where it shows |
|---|---|---|---|---|
| Critical | CVSS 9.0–10.0, with EPSS indicating a high probability of exploitation in the wild. | Closed and verified in the follow-up audit before the certificate issues. Section 16.3 requires critical findings to be notified as and when found, and repeated in the final report. | Nobody. There is no route by which the auditor waives a critical finding. | Nothing on the certificate once closed. The report carries the finding, the remediation and the retest result. |
| High | CVSS 7.0–8.9. Discovered breaches, known-high exploitation rates and unmonitored access are reported immediately on discovery under section 16.4, with a recommended solution. | Closed and verified. A high left open is the finding that stops a hosting provider opening the gate. | In principle the head of the organisation that owns the application, by written exception. In practice this is the band where a department should expect to be told no. | If accepted rather than fixed, the acceptance and its authorisation belong in the report, and the certificate should not imply closure that did not happen. |
| Medium | CVSS 4.0–6.9, weighted by EPSS. A medium with a high exploitation probability is not a medium in practice — which is what section 16.2 requires EPSS for. | Closed, or formally risk-accepted. Section 16.3 requires the report to state closure timelines by severity, so an open medium carries a date. | Risk treatment accepted by the head of the auditee organisation, and an exception on the application authorised by the head of the organisation that owns it. | The report names the item, the accepted risk, the authorising office and the closure timeline — the normal shape of a certificate issued with residual findings. |
| Low and informational | CVSS below 4.0, or observations with no score — configuration hygiene, missing headers, verbose errors. | Tracked with a timeline. Not a go-live blocker alone, but they return as repeat observations next cycle. | The department, through its normal risk register. | The report. A certificate does not enumerate them. |
Say the underlying rule out loud, because it removes most of the negotiation from month three: the auditor does not waive findings. Section 9.2 puts risk treatment on the head of the auditee organisation, and any exception on the head of the organisation that owns the application. A finding is closed, or accepted by a named office in writing with a closure timeline in the report. There is no third state.
Sixty-six days, and one hotfix
An illustrative composite, not a client. A state department takes a citizen-facing portal with an admin console and three APIs through a CERT-In-route audit, then discovers what a change-classification gate is for. The figures illustrate, but the rules behind each step do not.
| 6 Apr 2027 Scope frozen | The asset inventory is reconciled and the scope derived from it: 4 hostnames (public portal, admin console, file service, identity endpoint), 6 application roles from citizen to super-administrator, 3 API base paths, 1 database, and the staging environment the hosting provider will supply. Internal audit and the CISO vet it. |
| 13 Apr 2027 Engagement letter and NDA | NDA signed before any activity. The engagement letter fixes standards, plan, deliverable structure, escalation matrix and revalidation clause. Payment sits on three milestones — mobilisation, report, retest — none contingent on the finding count. |
| 20 Apr 2027 Staging handed over | Staging is stood up by the hosting provider with the payment integration pointing at a sandbox rather than stubbed out, and test accounts at all 6 roles. The build is tagged and the department records the artefact hash and its algorithm. Elapsed from scope freeze: 14 days. |
| 21 Apr – 12 May 2027 First test pass | Three weeks of testing, manual work alongside tooling. 31 observations scored on CVSS and supplemented with EPSS: 2 critical, 5 high, 11 medium, 13 low. Every observation mapped to a CWE, and 9 carry a CVE. |
| 28 Apr 2027 A critical, notified the day it was found | An authorisation defect on the admin console — a role check enforced in the interface and not in the controller — is reported the day of discovery with a recommended fix. The developer has it 14 days before the report lands. |
| 26 May 2027 Remediation build | One release closes both criticals, 4 of the 5 highs and 7 mediums. The fifth high is a session-fixation issue in a shared identity component the department does not own. It is escalated to the component owner and tracked separately. New build tag, new hash, recorded against the change register. |
| 2–5 Jun 2027 Follow-up audit | The retest confirms closure of both criticals and 4 highs. The remaining high is fixed by the component owner on 4 June and retested on 5 June. 2 mediums are risk-accepted in writing, authorised by the head of the department as owner of the application, each with a closure timeline. The rest go to the risk register with dates. |
| 11 Jun 2027 Report, then certificate | The final report issues after closure and the follow-up audit, signed by the two auditors, the mid-management reviewer and the head of the auditing organisation — all declared manpower. The certificate follows, naming the application, the hosting URL, the hash of the build retested on 5 June, the environment tested, the methodologies, and a validity line of one year or until the source changes, whichever is earlier. Scope freeze to certificate: 66 days. |
| 25 Jun 2027 The hotfix that ends the validity | Two weeks after go-live a hotfix changes the password-reset flow. The change board classifies it major — it touches authentication — so it does not ship on the Thursday release. It goes to the auditor as a delta re-audit of that flow, tested 1 July, certificate re-issued 3 July naming the new hash. |
What made it sixty-six days and not six months. The asset inventory existed before the tender, so the scope took a week. Staging was real, so no class of finding was silently excluded. The retest was priced in the original work order, so nothing waited on a variation approval. And the critical found on 28 April reached the developers the same day: fourteen days of remediation happened before the report existed.
What the department has to produce
The auditor cannot manufacture any of it. Seven things are the department’s to hand over: (1) the dated asset inventory and the scope derived from it, vetted by internal audit and the CISO, (2) the build identity, a version and a hash with its algorithm, (3) a staging environment from the hosting provider that replicates production, with accounts at every privilege level, (4) written approvals before penetration tests, tool installation and anything touching denial of service, process testing or social engineering, (5) remediation evidence per finding, (6) evidence for the 2022 Directions, and (7) last cycle’s report and closure record. Add one clause while you are there: section 18 tells auditees to seek the auditor’s working notes and the audit evidence as an appendix to the final report. The full list is on how to get a safe-to-host certificate.
Validity is driven by change, not by the calendar
Five triggers govern when you need a fresh audit and only one of them is a date. The detail, including how to read the validity line on a certificate you already hold, is on safe-to-host certificate validity.
| Time At least once a year | Sections 6 and 13.1.2 state that a cyber security audit should be conducted at least once in a year, and that auditees are expected to ensure a comprehensive audit covering all aspects of their ICT systems annually. Sectoral regulators may increase that frequency. |
| Source or build change Whichever comes first | Published specimen certificates tie validity to the tested artefact as well as the date — until a change to the hash value or to the source of the tested application, or one year, whichever is earlier. On that wording the clock is per release, not annual. |
| Major versus minor change Classify every change formally | Section 13.1.2 requires all changes to go through formal change management, classified minor or major. Minor changes — low risk, non-critical — need standard change management but not an audit. Major changes — system overhauls, technology migrations, or configuration adjustments affecting sensitive data or critical infrastructure — must undergo an audit before implementation. |
| No change at all Still audit periodically | Audits should be performed even with no major change, at intervals set by asset criticality, to remediate risk from new vulnerabilities. |
| The next contract Two to three years, not one engagement | Section 12.4 says contracts for critical or high-user-reach applications should run two to three years, enabling continuous audits at a defined frequency. |
Where the one-year figure comes from. Not from a single national rule. Published specimen certificates state it on the face of the document: one is valid until no additional changes in the hash value or dynamic contents are carried out, or one year from issue, whichever is earlier. Another gives a maximum validity of one year and adds that the opinion holds only while the source of the tested application is unchanged. The 2025 guidelines reach the same place from the other direction. Because the issuing body sets the wording, read the validity line on the certificate you hold.
Classifying a real change as minor or major
“System overhauls, technology migrations, or configuration adjustments that affect sensitive data or critical infrastructure” is the guideline’s own definition of a major change, and nobody can classify a pull request from it. Here is the same rule at engineering resolution. The classification is made by the formal change management process section 13.1.2 requires, not by the developer who wrote the change — and the classification record is what evidences that the certificate is still valid.
| Change | Minor or major | Audit before implementation | Evidence retained |
|---|---|---|---|
| Content, copy, CSS or template change with no logic change | Minor | No. Standard change management applies, provided nothing server-side moved with it. | The change record, the diff, and the classification decision. |
| Dependency patch bump, no interface change | Minor in most cases | No — unless the dependency sits in the authentication, cryptography or data-access path, in which case classify it up. | The updated dependency manifest and the build hash, so the delta from the audited build is provable. |
| Dependency major-version or framework upgrade | Major | Yes, before implementation. A technology migration in the guideline’s own language. | Fresh scope note, the new build hash, the re-audit report. |
| New public API endpoint, or a new field on an existing one | Major | Yes. New attack surface on a tier the certificate named. | The updated API inventory with base paths, and the audit covering the new endpoint. |
| Change to authentication, session handling or password policy | Major | Yes, before implementation. | Design note, the re-audit, and the risk sign-off if anything is accepted rather than fixed. |
| RBAC or role-matrix change | Major | Yes where it affects access to sensitive data. Authorisation defects are the class most often missed, because they need authenticated testing at every role. | The before-and-after role matrix, and the authenticated test coverage in the re-audit. |
| TLS, cipher suite or reverse-proxy configuration change | Major | Yes — a configuration adjustment affecting sensitive data or critical infrastructure is the guideline’s own example. | The configuration baseline, the change record, a configuration audit of the changed tier. |
| New third-party SDK, analytics tag or payment gateway | Major | Yes. It is also a third-party risk item, which section 13.1.1 puts in the audit scope. | The vendor assessment, the updated asset inventory, the re-audit. |
| Database schema change touching personal data | Major | Yes, and for a critical database a configuration audit alongside the application testing. | The migration script, the data-classification note, the database configuration audit. |
| Migration to a new hosting environment or region | Major | Yes. The certificate named an environment, and a new one has not been tested, and guideline 5.3.2 on securing the hosting environment is a separate requirement again. | The new environment’s configuration baseline and a fresh clearance for the new hosting. |
| Feature behind a flag turned on for all users | Major if the code path was never tested | Yes where the flag exposes code the auditor could not reach. An unchanged build hash does not mean an unchanged reachable surface. | The flag register, with a note of which flags were on during testing — the detail almost nobody keeps. |
The classification decision, not the change itself, is the artefact an auditor or a hosting provider asks for next year — record who classified it, against which criterion, on what date. And be honest about the borderline rows: a dependency bump inside the authentication path is a change to authentication, whatever the package manager calls it.
Where this goes wrong
Seven patterns, each with a written rule behind it that somebody did not apply, ordered so the first four are the ones that most often block go-live. Read them as a pre-mortem before the work order goes out. The application-level version — the technical findings that block a certificate — is on why applications fail safe-to-host.
| Failure mode | Surfaces at | How you know | Cost of catching it later |
|---|---|---|---|
| The certificate names a build nobody can find No hash, no version, or a version string matching no tag in the repository. The certificate is unfalsifiable in both directions. | Hosting gate, or the first incident after it | You ask which build the certificate describes and get a date instead of an identifier. | A fresh audit. Build identity cannot be retrofitted onto a test that has already happened. |
| The audit ran on staging and the report does not say so Section 15.2.3 requires the environment tested to be stated, and 16.3 requires the report to say explicitly that the audit was not conducted on production where the scope was limited to staging. | Findings report | The environment line is blank or reads “as provided”. Production configuration, data volumes and integrations appear nowhere in the findings. | A production-side pass, or a certificate the department cannot honestly represent. |
| The APIs were a separate contract, so they were in nobody’s scope The front end is audited under one work order, the API tier belongs to a different system integrator, and each scope assumes the other covered it. | Scoping — discovered at the findings report | The API base paths appear in no scope annexure. The mobile findings are all client-side. | A second engagement, a second procurement, and a go-live date that moves by a quarter. |
| Nobody planned for the follow-up audit The work order covers one audit, so when findings come back there is no contractual basis for the retest. Section 9.3 puts follow-up audits in the scope or RFP. | Retest | The auditor quotes for the retest. That quote is the signal. It should have been in the original price. | A variation order, a finance approval cycle, and weeks of slip on a committed date. |
| Code changed after the certificate was issued A hotfix goes out and the certificate describes a build that no longer exists. Section 9.5 says the developer should avoid code changes after issuance, and 13.1.2 requires an audit before a major change is implemented. | The next release | The deployed hash no longer matches the certificate, and no classification record exists for the change that moved it. | A delta re-audit if caught at the change board, or a full re-audit at the annual review. |
| Payment was tied to the certificate being issued The most damaging error and the least visible: where the final milestone pays on issuance, every finding costs the auditor money. Section 7 tells auditors to escalate undue influence to CERT-In. | Scoping, and it never surfaces at all | A milestone worded “on issuance of certificate” or “on closure report approval”. | Nothing visible, which is the problem. You get a clean certificate and buy none of the assurance. |
| The application was never securely designed in the first place Section 8 says an application developed without secure design and development practices should not be considered for assessment and audit, and that the auditee must be told in writing with a copy marked to CERT-In. | First test pass, when the finding count arrives | Thirty-plus findings on a first pass, clustered on authorisation and input handling, with no threat model and no SAST run. | Remediation that is a rewrite. Put Secure by Design into the build RFP, as section 9.4 requires. |
Checking the issuer, in six steps
Everybody says verify the issuer, but almost nobody says where, what to match, or what to do when it does not match. This is the sequence, and it takes twenty minutes before award.
- 01 Start on CERT-In’s own site, not the bidder’s. CERT-In publishes the list of empanelled organisations and the snapshot information behind each one, and section 12.1 says that information should be used to select auditing organisations. For an STQC-route bidder, the equivalent is STQC’s panel listing.
- 02 Match the exact legal entity — the name that will sign the contract and the certificate, against the name in the listing, character for character. The common failure is a brand name, a trading name, a subsidiary, or a group company that is empanelled while the bidding entity is not.
- 03 Check the cycle and the categories. Confirm the empanelment is current, and read the categories of audit the snapshot declares against the testing your asset needs — web application, mobile application, API, configuration, process, cloud, source code review. Section 12.1 also lists what else CERT-In publishes and a department can evaluate for free: manpower and skillset details, relevant experience, audits in the last twelve months sector-wise, category-wise counts, technical manpower deployed and tools used.
- 04 Get the declared names who will run and sign it — the auditors, the Lead Auditor who signs the certificate, the mid-management reviewer. Reports may be signed only by declared manpower, so a firm that cannot tell you who will sign has a staffing answer it does not want to give.
- 05 Read the wording the bidder uses about CERT-In. One sentence is permitted, and anything else is outside the terms the bidder signed.
- 06 When a check fails, record it and ask. Where an auditor has moved between empanelled organisations, section 12.3 requires a no-objection or relieving letter from the previous organisation and revised snapshot information to be communicated to CERT-In — ask for that position in writing, and record the outcome in the evaluation. Never award on a screenshot, a scanned letter or a bidder-printed certificate number.
The entity-name step catches the real problems. An empanelment belongs to a legal person: if the entity signing your contract is not the entity on the listing, you do not have an empanelled auditor, however honestly everyone believes you do.
Three clauses that decide whether the certificate is worth anything
Quality is mostly decided before a single test is run, by the tender. Many clauses help, but three change the outcome, and all three come out of CERT-In’s audit policy guidelines.
Name the issuer class, not a firm — and put the scope in the tender
Write the requirement the way GIGW writes it: security audited and an audit clearance certificate issued by NIC, STQC, an STQC-empanelled laboratory or a CERT-In empanelled laboratory before hosting in production. Then enumerate, from the asset inventory, every asset the bidder must test — hostnames, package identifiers, API base paths, databases, network devices, cloud accounts and hosting infrastructure. Bidders price what they can see, and a vague scope produces a cheap bid and an expensive variation.
Decouple payment from the finding count
Milestones against scope, deliverables and timelines. No milestone should pay on a clean result, on certificate issuance, or on approval of a closure report, because section 7 says fees must not be contingent on the audit outcome. This clause does more for audit quality than any technical requirement in the tender, and it is the one a finance reviewer will try to remove.
Buy the retest and the continuity, not one engagement
The scope of work should specify follow-up audits, and the contract should carry the clause to revalidate observations after your own compliance window. For critical or high-user-reach applications, section 12.4 says contracts should run two to three years, with a provision letting the department switch auditor where credibility becomes unclear. That looks like reduced competition, but what it buys is an auditor who knows the application well enough to notice what changed.
Four more belong in the tender. Name the declared manpower. Say who provides the staging environment, because the obligation otherwise falls between two contracts. Put Secure by Design into the build RFP with SAST required of the developer, and require the auditor to notify any change in empanelment status immediately. Model wording is on GIGW compliance before go-live.
What project teams argue about
These arrive in real project reviews, usually late and usually with a go-live date attached. In every case the answer that works cites the document rather than asserting the conclusion.
“Our hosting provider says they need a safe-to-host certificate. Is that real, or their internal policy?”
Real, with a written source. Guideline 5.3.1 requires the website, portal or app to have been security audited and an audit clearance certificate issued by NIC, STQC, an STQC-empanelled laboratory or a CERT-In empanelled laboratory before hosting in production. Hosting providers enforce it because they are the last gate.
“Can our internal security team issue it? We have better people than the bidders.”
No. GIGW names the permitted issuers and an internal team is not among them. Internal assessment is separately expected — section 9.4 says continuous internal audits should be carried out by auditee entities — but the instrument a hosting provider accepts must come from one of the four. Section 5 names the reason: the same entity implementing controls and then auditing them, or auditing while responsible for remediation, is a conflict of interest that must be disclosed and managed.
“Our system integrator says they will handle the whole audit for us.”
That is the one thing the guidelines say cannot be delegated. Section 9.6 states that the complete audit process must be undertaken by the auditee organisation itself, except where a regulator, government or relevant stakeholder mandates otherwise — and that the entire process, from defining the scope to selecting the auditing organisation to ensuring closure of all observations, must be carried out by the owner of the information infrastructure and must not be delegated. External support may be sought for specialised expertise while the department retains accountability. A department that hands the exercise to its builder has asked the builder to pick the auditor who will judge the build.
We deliver CERT-In audits
We deliver CERT-In audits, end to end, with our CERT-In empanelled partners. The safe-to-host audit this page describes is one of them. See how a CERT-In audit runs with us.
For our VAPT practice, see penetration testing and VAPT. For the wider assurance stack that these engagements usually sit inside — ISO 27001, SOC 2 and the DPDP Act — the same evidence base does a great deal of double duty once it is organised properly.
Frequently Asked Questions
What is a safe-to-host certificate?
Who can issue a safe-to-host certificate in India?
Is a safe-to-host certificate mandatory?
What does a safe-to-host certificate look like, and what is the format?
How long is a safe-to-host certificate valid?
What is the difference between the certificate and the audit report?
How much does a safe-to-host certificate cost in India?
How long does it take to get one?
Is VAPT the same as a safe-to-host certificate?
Do we need a safe-to-host certificate for a mobile app, and does it cover the APIs?
Does CERT-In issue or approve safe-to-host certificates?
What happens to our certificate if the auditor’s empanelment lapses or is suspended?
Who pays for the retest?
Do we need a separate certificate for each environment, region or server?
What does the auditor test against?
Can the audit be done on the live production site?
Related Reading
How to Get a Safe-to-Host Certificate
Eleven stages end to end — eligible auditor, staging, first pass, remediation, retest, issue — plus what drives duration and cost.
Read moreWho Can Issue Safe-to-Host Certificates
NIC, STQC, an STQC empanelled laboratory, or a CERT-In empanelled laboratory — and how to check before award.
Read moreHow Long a Safe-to-Host Certificate Lasts
One year, or the next source-code change — whichever comes first, and how to classify the change.
Read moreSafe-to-Host vs Security Audit Certificate
Indian tenders use the names interchangeably. They are not the same artefact — a decision table for an ambiguous clause.
Read moreGIGW Compliance Before Go-Live
The wider conformity picture — quality, accessibility, cybersecurity and lifecycle — of which safe-to-host is one part.
Read moreVAPT / Penetration Testing
Manual-first web, API, network and mobile testing with retest included.
Read more