Who Can Issue a Safe-to-Host Certificate: CERT-In, STQC and NIC.
Three routes are eligible, one guideline names them, and the difference between them decides whether your project goes live. The harder question is not which routes exist — it is how you check that the organisation in front of you genuinely belongs to one of them, using the register the government actually publishes.
The governing sentence: GIGW 3.0 guideline 5.3.1 requires that a website, web application, web portal or mobile 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.
Plain-English explainer · Sourced to GIGW 3.0, CERT-In empanelment terms v7.2 (April 2024), Comprehensive Cyber Security Audit Policy Guidelines v1.0 (25 July 2025), STQC and NIC · Every instrument linked in the source register · Last reviewed September 2026
Three kinds of organisation can issue the security audit clearance that Indian government projects call a safe-to-host certificate: a CERT-In empanelled information security auditing organisation, STQC or a testing laboratory STQC has empanelled, and NIC. No fourth route exists — not a certification body, not a testing firm holding an ISO certificate of its own, not your hosting provider, and not your development vendor. The requirement is stated in the Guidelines for Indian Government Websites and apps. GIGW 3.0, guideline 5.3.1, puts it in one sentence: 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 is four named issuers across three routes.
That settles eligibility. It does not settle the question every department and every vendor manager actually faces, which is how to tell a genuinely empanelled organisation from one that describes itself that way. The answer is unusually concrete for this subject, and it is the reason this page exists. CERT-In publishes one PDF — titled EMPANELLED INFORMATION SECURITY AUDITING ORGANISATIONS by CERT-In — which contains both the numbered list of empanelled organisations and, for each one, a thirteen-field snapshot of its skills and competence, stamped with the date that organisation supplied it. CERT-In’s terms and conditions for empanelment permit exactly one sentence of self-description and prohibit the logo. And CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines — which state that they are binding on all CERT-In empanelled auditing organisations and auditee entities covered under the relevant provisions — set out who may sign a report, who may be deployed, and what an auditee is expected to verify. Every claim below is linked to one of those documents, and the ones that could not be linked are not here.
Key Takeaways
- GIGW 3.0 guideline 5.3.1 names four issuers across three routes: NIC, STQC, an STQC empanelled laboratory, and a CERT-In empanelled laboratory. The audit clearance has to exist before the application is hosted in the production environment.
- CERT-In publishes the register. One PDF on cert-in.org.in, under Cyber Security Assurance, carries the numbered list of empanelled organisations and a thirteen-field snapshot for each — capability by category, audits in the last twelve months by sector, named technical manpower for Government and critical sector audits, tools, and foreign tie-ups. 236 organisations were numbered on it when this page was last reviewed.
- Empanelment attaches to an organisation, not to a person. Individual auditors appear in the organisation’s snapshot information declared to CERT-In, and an auditor who changes employer does not carry empanelment across.
- An empanelled organisation may use one sentence about its relationship with CERT-In: “This Organization is empanelled by CERT-In for providing information Security Auditing Service.” The CERT-In logo, or any other wording, needs prior written permission. It is the cheapest integrity test in the whole evaluation.
- Audit reports shall be signed only by manpower declared to CERT-In, with a designated reviewer outside the audit team and the head of the organisation also signing. The audit certificate carries both the lead auditor and the head.
- Empanelment is reviewed and can be withdrawn. CERT-In operates graded actions from a watch list with warning through suspension to withdrawal of empanelment and penal action, so standing is a fact about today rather than a permanent attribute — check it at award and again at issue.
- Most searches for “CERT-In empanelled auditor” do not come from GIGW departments at all. SEBI’s CSCRF and UIDAI’s AUA/KUA requirements both demand CERT-In empanelled auditors, and in neither case is the deliverable called a safe-to-host certificate.
- We deliver CERT-In audits, end to end, with our CERT-In empanelled partners.
The three routes that can issue a safe-to-host certificate
Read the three rows below as three different kinds of organisation rather than three brands of the same thing. One is a private firm that has cleared a government process and can lose that status. One is a government testing body and the laboratories it has empanelled. One is the government’s own IT organisation, working inside its own estate. They issue different documents, they are verified differently, and they are not interchangeable in every project.
| Route | What the body is | What it issues | Where it is named | Where it is accepted |
|---|---|---|---|---|
| CERT-In empanelled information security auditing organisation | A commercial auditing organisation that has cleared CERT-In’s empanelment process and appears on the list CERT-In publishes. It is a private firm, not a government body — CERT-In empanels it, is not a party to your contract with it, and can suspend or de-empanel it. | A security audit report and, where the engagement is an application audit, an audit certificate — the document commonly called the safe-to-host certificate. | GIGW 3.0 guideline 5.3.1 names a “CERT-In empanelled laboratory”, and the GIGW 3.0 release notes name “cybersecurity auditors empanelled by CERT-In”. | The widest acceptance of the three. Government departments, NIC National Cloud onboarding, and effectively every tender or regulator mandate that names a route at all names this one. |
| STQC, or an STQC Empanelled Testing Laboratory (SETL) | STQC — the Standardisation Testing and Quality Certification Directorate, an attached office of the Ministry of Electronics and Information Technology — plus the testing laboratories it has empanelled. SETL stands for STQC Empanelled Testing Laboratory, and each one holds a defined scope. | Evaluation and test outputs from an STQC laboratory or a SETL. Certificates under the Website Quality Certification Scheme are issued only by STQC Directorate, never by the laboratory that did the testing. | GIGW 3.0 guideline 5.3.1 names “STQC/ STQC empanelled laboratory”, and STQC’s own Website Quality Certification page names both routes. | Government projects pursuing STQC Website Quality Certification, and departments that prefer a government testing body. The scheme also accepts a security audit performed by STQC, a SETL, NIC or a CERT-In empanelled agency. |
| NIC — the National Informatics Centre | The government’s own IT services organisation. Its Security division performs security audits for government applications, typically those NIC hosts or builds, and NIC National Cloud is operated as per the security guidelines and policies issued by CERT-In and the Cyber Security Group of NIC. | A security audit clearance for the application, issued inside government rather than sold as a commercial deliverable. | GIGW 3.0 guideline 5.3.1 names “NIC”, and the NIC National Cloud terms name the NIC Security division alongside third-party agencies. | Applications inside the NIC estate — NIC hosting, NIC National Cloud, NIC-developed systems. Not available to private-sector applicants, and not something a commercial vendor can sell you. |
Two clarifications save a great deal of argument. First, CERT-In does not itself audit your application, and it is not a party to the contract between you and the auditor — clause 2.1 of the terms and conditions for empanelment states that an auditor is contracted by a customer directly and that CERT-In is not a party to such contracts. Second, none of these routes produces a certificate that certifies your organisation. What is issued is a clearance for an audited build of an application, which is why its validity is tied to that build rather than to a calendar year alone.
Who cannot issue one, and what they can give you instead
Most of the confusion on this subject is not about the three eligible routes. It is about the organisations a buyer reasonably assumes are eligible and are not. None of the bodies below can issue a safe-to-host certificate. Several of them produce something genuinely useful, which is why the second column matters as much as the first — the answer to “can my ISO 27001 auditor issue this?” is no, and the follow-up question is what to do with the ISO auditor instead.
| Body | Why it cannot issue | What its output is genuinely good for |
|---|---|---|
| An ISO/IEC 27001 or ISO/IEC 27701 certification body | It certifies a management system against an international standard under an accreditation scheme. It is not named in GIGW 3.0 guideline 5.3.1, and an ISO certificate says nothing about whether a specific application build is safe to host. | A genuine, useful certificate of a management system — and evidence your organisation has a governance structure. Keep it. It answers a different question. |
| A chartered accountancy or company secretary firm | Statutory audit and secretarial audit are different professions with different empanelment. Unless the same group holds CERT-In empanelment in its own name as an information security auditing organisation, it cannot issue this. | Assurance over financial reporting and statutory compliance. Ask which legal entity holds the empanelment — group branding is not empanelment. |
| A global consultancy that is not on the CERT-In list | Scale, brand and offshore accreditations are irrelevant to eligibility. The list is the test, and the entity on it must be the entity signing. | Often excellent testing, threat modelling and remediation advice. Buy that on its merits, and route the signature separately. |
| Your hosting provider or cloud service provider | The provider furnishes the staging or testing environment the audit runs on. Auditing the application it hosts, and certifying it, is not its role — and for NIC National Cloud the terms require the audit to come from the NIC Security division or a CERT-In empanelled agency. | The staging environment, infrastructure evidence, and its own compliance artefacts. Ask for the environment, not the certificate. |
| Your development vendor or systems integrator | Beyond eligibility, there is an independence problem in letting the party that wrote the code select and instruct the party that judges it. CERT-In’s policy guidelines put the whole process on the owner of the information infrastructure and say the responsibility must not be delegated. | Remediation, secure development practice, and the hash values and version numbers the audit needs. Let them fix, but do not let them choose. |
| An individual consultant describing themselves as “CERT-In empanelled” | Empanelment attaches to an organisation. Individuals appear in that organisation’s snapshot information declared to CERT-In. They do not hold the status personally and do not carry it to a new employer. | Skilled individual testing, usually. The question to ask is which empanelled organisation employs them and whether they appear in its declared manpower. |
| A bug-bounty platform or crowdsourced testing programme | Neither is an empanelled organisation, and a bounty programme cannot produce a signed audit report against a defined scope with a declared team and a named reviewer. | Continuous, adversarial coverage between audits — genuinely valuable, and a good complement. It is not the instrument a go-live gate asks for. |
| Your own internal audit function | CERT-In’s guidelines do expect continuous internal audits and assessments — but as internal assurance, not as the clearance an external eligible issuer provides. | The internal monitoring programme that keeps you audit-ready, and the evidence base an external auditor will want to see. |
| An STQC laboratory or SETL, on its own letterhead | STQC is explicit: STQC labs and SETLs can only perform evaluation and shall not issue certificates. Under the Website Quality Certification Scheme, only STQC Directorate at Electronics Niketan issues the certificate. | The evaluation and test report that the STQC certification body reviews. A certificate arriving on laboratory letterhead is the finding, not the deliverable. |
| A foreign testing laboratory or overseas accreditation body | GIGW 5.3.1 names four issuers, all Indian. Separately, CERT-In’s auditor guidelines require that there be no mirroring of audit data outside the country and no sharing with an overseas partner unless specifically authorised by the auditee. | International certification useful to international customers. For an Indian go-live gate it does not substitute, and the data-location rules cut against it. |
Where the requirement comes from: GIGW 3.0 guideline 5.3.1
Most pages on this subject cite nothing. The requirement has a home, a number and a structure, and quoting it correctly is the difference between an argument you win in a project meeting and one you do not.
GIGW 3.0 · guideline 5.3.1 · Statement
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.
GIGW is the Guidelines for Indian Government Websites and apps, published by the National Informatics Centre with the Department of Administrative Reforms and Public Grievances, and now in version 3.0. Each guideline is set out in five parts — Statement (the requirement itself), Benefits, Government organisation action, Developer Action and Evaluator Action. That structure matters when you are assigning work, because it distinguishes what the department must do from what the developer must do and what the evaluator will check. Guideline 5.3.1 also carries expectations about adherence to the OWASP Top 10 and to industry practice such as OWASP ASVS and OWASP MASVS during development, which is the standard your auditor is likely to test against.
“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.”
Note the word continue. The safe-to-host requirement is not new in GIGW 3.0. Note also the vocabulary problem hidden in these two sentences, because it produces more wasted procurement time than any other feature of this subject. The guideline statement calls the document an audit clearance certificate, the release notes call it a safe to host certificate, and CERT-In’s audit policy guidelines call it an audit certificate. All three name the same deliverable. When a tender uses one term and a vendor quotes for another, the words are rarely the real disagreement — the scope usually is. For the document itself, see what a safe-to-host certificate is and how it differs from a security audit certificate.
One terminological knot, untied
GIGW says “CERT-In empanelled laboratory”. CERT-In’s own documents say “empanelled information security auditing organisation”. These name the same thing. CERT-In empanels organisations, not laboratories, and there is no separate CERT-In laboratory empanelment to look for. The word laboratory in GIGW 5.3.1 is doing work on the STQC side of the sentence, where laboratories genuinely are what is empanelled — a SETL is an STQC Empanelled Testing Laboratory. If a bidder offers you a “CERT-In empanelled lab certificate” as though it were a distinct credential, it is not. The thing to check is whether the organisation appears on the list CERT-In publishes.
CERT-In, STQC and NIC compared, route by route
Eligibility is the easy half. What separates these routes in practice is who signs, how you verify the signature, and what standards the work is held to.
| Axis | CERT-In empanelled organisation | STQC / SETL | NIC |
|---|---|---|---|
| What the body actually is | A commercial auditing organisation empanelled by CERT-In. The published empanelment process runs in four steps: a documentation review round, an offline practical skill test, a VA/PT practical skill test, and a personal interaction session at CERT-In. | A government testing and certification body — an attached office of MeitY — plus the testing laboratories it has empanelled (SETLs), each holding a defined scope. | The government’s own IT organisation. Its Security division audits government applications, largely inside the estate NIC builds and hosts. |
| What it issues | An audit report and an audit certificate for the audited application build, signed by the lead auditor and the head of the organisation. | Evaluation and test outputs from an STQC laboratory or SETL. Certificates under the Website Quality Certification Scheme come only from STQC Directorate. | An internal security audit clearance for the application, as a government function rather than a commercial deliverable. |
| Who may sign | Only manpower declared to CERT-In. The report is signed by the auditors who conducted it, reviewed and signed by a designated reviewer outside the audit team from mid-management, and authorised and signed by the head of the organisation. The certificate carries the lead auditor and the head. | The STQC certification body, on the recommendation of its certification process. Laboratories evaluate and report, but they do not certify. | NIC, internally. There is no commercial counterparty and no marketable certificate. |
| How you verify it | Against the list and the thirteen-field snapshot CERT-In publishes in one PDF, plus identity verification of the deployed team on arrival. | Against the scheme’s published rules: the laboratory’s scope, the issuer, and the certification body’s validator oversight. Scope-and-issuer verification, not name-on-a-list verification. | Through the department’s own NIC channel. If a private vendor claims it can arrange “NIC certification” for you, that claim is the finding. |
| Standards it works to | CERT-In’s auditor guidelines and the Comprehensive Cyber Security Audit Policy Guidelines, which state that they are binding on all CERT-In empanelled auditing organisations and auditee entities covered under the relevant provisions. | The Website Quality Certification Scheme, with SETL testing aligned to ISO/IEC 17025 competence requirements, assessed against GIGW conformity. | The security guidelines and policies issued by CERT-In and the Cyber Security Group of NIC, under which the National Cloud is operated and managed. |
| Where it is typically accepted | Broadest. Government departments, NIC National Cloud onboarding, and tenders or regulator mandates that specify empanelment. | Government projects seeking Website Quality Certification, and departments that specifically ask for the STQC route. | Inside the NIC estate. Private-sector organisations cannot obtain it and should not be sold it. |
CERT-In empanelled auditing organisations
This is the route most projects take and the only one a private organisation can buy on the open market, so it deserves the most detail. Empanelment is a status CERT-In confers on an organisation, holds under review, and can take away.
What CERT-In empanelment actually is
CERT-In is the national nodal agency for cyber security incidents under section 70B of the Information Technology Act, 2000. Alongside incident response it empanels information security auditing organisations to undertake audits — including vulnerability assessments and penetration testing of computer systems, networks and applications — of organisations of the Government and of other sectors. In CERT-In’s own framing in the policy guidelines, empanelled organisations agree to provide cyber security auditing services in accordance with the commercial contract entered into with the auditee, and to abide by all the conditions of empanelment as well as service delivery.
The process itself is published. CERT-In’s empanelment page sets out the steps as separate documents: Step 1 is a Documentation Review Round, Step 2 an Offline Practical Skill Test, Step 3 a Vulnerability Assessment / Penetration Testing Practical Skill Test, and Step 4 a Personal Interaction Session at CERT-In. Applications open in announced windows rather than continuously. That sequence is worth knowing for one reason: it tests an organisation’s people and process at a point in time, which is exactly why the status carries an annual review and why the published snapshot matters more than the badge.
What an empanelled organisation has signed up to
Two documents form the rulebook: the Terms and Conditions for Empanelment, version 7.2, April 2024, and the Comprehensive Cyber Security Audit Policy Guidelines, version 1.0, 25 July 2025. The second states in its own words that it is binding on all CERT-In empanelled auditing organisations and auditee entities covered under the relevant provisions — which is unusual and useful, because it means an auditee can hold a vendor to it and quote it in a tender. Among the obligations that change what you should expect from an engagement:
- The audit report goes to the auditee directly in the format at Annexure II of the terms, and the audit outcome is communicated only to the specified point of contact, shared only by secure methods such as passwords or encryption, and sent only from official email addresses.
- Responsibility for client data preserved by the auditing organisation remains with that organisation. Retained data must be encrypted with access only on a need-to-know basis, and the organisation should not share the client’s data without explicit written permission from the auditee.
- There is one published carve-out to that confidentiality, and buyers should know it rather than discover it: CERT-In empanelled auditing organisations shall provide the audit reports and data to CERT-In without explicit permission of the auditee, and clause 3.2.2 makes it mandatory to share the audit report and audit metadata with CERT-In within five days of completion of the audit, along with critical vulnerabilities pointed out during the audit that the auditee did not fix even during follow-up audits.
- CERT-In may associate its experts in audit assignments to gain first-hand knowledge of the quality of audits being carried out, and may carry out sample analysis, depute representatives to witness an audit in progress, or seek the opinion of auditee organisations.
- Empanelled organisations should not engage in sub-letting or outsourcing of an audit assignment, digital break-in, violating the terms and conditions of empanelment, or unethical business transactions.
“Empanelled” is not one competence
Section 6 of the policy guidelines enumerates the engagement types within scope, and the list runs from i to xxvi — twenty-six of them. Compliance audits, risk assessments, vulnerability assessment, penetration testing, network infrastructure audits, operational audits, IT security policy review, information security testing, source code review, process security testing, communications security testing, application security testing across web, mobile and APIs, mobile application security auditing, wireless security testing, physical security testing, red team assessment, digital forensic readiness assessment, cloud security testing, ICS and OT security testing, IoT and IIoT security testing, log management and maintenance audits, endpoint security assessment, AI system audits, vendor risk management audits, blockchain security audits, and SBOM, QBOM and AIBOM auditing.
Two entries in that list are worth pausing on, because they are where this hub meets the rest of the estate. Red team assessment is defined as an exercise reflecting real-world conditions, conducted as a simulated attempt by an adversary to attack or exploit vulnerabilities — not a longer penetration test, which is why buying “VAPT” and expecting an adversary simulation disappoints both sides. AI system audits are defined as evaluation of AI systems for security, ethical alignment, transparency, data integrity and resilience to adversarial manipulation, alongside AIBOM auditing. That is not an isolated gesture: CERT-In’s directions of 28 April 2022 already make attacks and malicious or suspicious activities affecting systems related to artificial intelligence and machine learning a mandatorily reportable class of incident.
The practical consequence for selection is direct. A tender that says “CERT-In empanelled auditor” and nothing else has specified the issuer and left the work undefined. Name the categories you are buying, and then check them against the published snapshot — which is what the next two sections are about.
Where each register lives, and what it actually publishes
Almost every page on this subject tells you to check the published list and then does not say where it is, what it is called, or what is in it. Here is the answer for all three routes, so the instruction is one you can follow rather than one you have to take on trust.
EMPANELLED INFORMATION SECURITY AUDITING ORGANISATIONS by CERT-In
Indian Computer Emergency Response Team, Ministry of Electronics and Information Technology
cert-in.org.in → Cyber Security Assurance → Empanelment by CERT-In
Format
A single PDF. The header states that the list “is up-to-date valid list of CERT-In Empanelled Information Security Auditing Orgnisations” and that it “is updated by us as soon as there is any change in it” — so it carries no issue date of its own, and the date that matters is the date you read it.
What each entry carries
Each entry is numbered and carries the organisation’s name prefixed “M/s”, postal address, website URL, telephone and fax, a named contact person and often their designation, a mobile number, and an email address written with [at] in place of the @ sign.
Scale, and the caveat
236 organisations were numbered on the list as at 18 September 2026. Treat that number as a reading, not a constant: entries are added and removed without a version bump.
Website Quality Certification (the Website Quality Certification Scheme pages)
Standardisation Testing and Quality Certification Directorate, MeitY
stqc.gov.in → Certification → Website Quality Certification
Format
A scheme page with linked rules, procedures and notices as PDFs, including the operations document for STQC Empanelled Testing Laboratories and technical oversight.
What each entry carries
The scheme pages state who may evaluate and who may certify, the scope condition on a laboratory (a SETL must hold GIGW evaluation in its scope), the certification mark, validity and surveillance regime, the prerequisite review report, and how charges are paid.
Scale, and the caveat
STQC publishes the scheme and its rules rather than a single numbered roster of the kind CERT-In publishes, so verification here is scope-and-issuer verification rather than name-on-a-list verification.
National Cloud of NIC — Terms and Conditions
National Informatics Centre
cloud.gov.in → Terms and Conditions
Format
A terms page, not a register.
What each entry carries
It states who may perform the pre-hosting security audit, the CERT-In empanelment condition on any third-party agency, the exigency provision, and the security policy regime the estate runs under.
Scale, and the caveat
There is nothing to look an auditor up in, because there is nothing to buy. A NIC audit is arranged through the department’s own NIC channel. If a vendor offers to sell you one, that offer is the finding.
One navigation note, because it comes from CERT-In rather than from us. The policy guidelines themselves spell the path out when directing auditees to the empanelment criteria: cert-in.org.in → Cyber Security Assurance → Empanelment by CERT-In. That is the same section the list, the terms and conditions, the guidelines for applying for empanelment and the secure application design guidelines all sit under. If a vendor sends you a link to anything on this subject that is not on cert-in.org.in, stqc.gov.in or a government domain, you are reading marketing.
The snapshot CERT-In publishes, and what each field tells you
Every organisation on the list is followed, in the same document, by a page headed Snapshot of skills and competence of CERT-In empanelled Information Security Auditing Organisation. It runs to thirteen numbered fields. The policy guidelines say this information is there to be used — it should be utilised by organisations or sectoral regulators when selecting an auditor. Almost nobody opens it. Here is what is in it, and what each part is actually worth.
| 1–2 | Name and location of the organisation, and the year it has been carrying out information security audits since | The reconciliation point for the entity name. The name here is the entity CERT-In holds — compare it against the name on the proposal, the NDA and the draft certificate before anything else. |
| 3 | Capability to audit, category wise — a Yes/No against each category the organisation lists | The closest thing an auditor has to a scope statement. Categories are self-declared and vary between organisations, so read the actual entry rather than assuming a standard taxonomy. |
| 4–5 | Information security audits carried out in the last twelve months, split Government / PSU / Private, and the category-wise count over the same period | Recency and sector familiarity in two fields. A firm with no government-sector audits in a year will be learning your constraints on your timeline. Category-wise counts are where a red-team or cloud capability shows up as a practice rather than a brochure line. |
| 6 | Technical manpower deployed for information security audits, by qualification — CISSPs, ISO 27001 lead auditors, CISAs, DISAs/ISAs, other qualifications, and a total | Bench size and shape. Useful mainly as a sanity check against the size of the engagement you are proposing to give them. |
| 7 | Details of technical manpower deployed for information security audits in Government and Critical sector organizations — a named table of employee, duration with the organisation, experience in information security and qualifications | The single most useful field on the page, and the one almost nobody opens. This is where you check that your named lead auditor exists, how long they have actually been with the firm, and what they are qualified in. |
| 8–9 | The largest project handled, with scope and project value, and the list of audit tools used, split commercial, freeware and proprietary | A reality check against CERT-In’s own rule that solely tools-based testing should be discouraged. A long tool list is a floor, not a methodology — ask what is done by hand. |
| 10–13 | Whether the organisation outsources projects to external auditors or experts, whether it has foreign tie-ups, whether it is a subsidiary of a foreign-based organisation, and the locations of any overseas headquarters or offices | Four declarations that matter more than they look. Outsourcing is separately prohibited for audit assignments, and unreported changes to foreign tie-ups or manpower are grounds for de-empanelment. A “No” here that conflicts with what the sales team told you is worth a question. |
The single most important thing to understand about the snapshot is that it is self-declared. Each one ends with a line in the form Information as provided by [organisation] on [date], and those dates range across years. It is not an audit of the auditor. It is the auditor’s own statement, published by CERT-In, with a date attached — which makes it excellent evidence of what the organisation was willing to put in writing to the regulator, and weak evidence of what is true today. Read the date first, then the content.
How to verify CERT-In empanelment before you award
Eleven steps, in the order a procurement process actually runs them. Steps one to five belong at evaluation, six to eight at award and kick-off, and nine to eleven run continuously. None of them requires a relationship with CERT-In or any privileged access — everything below is published.
- 01 Get the organisation’s name in writing, as registered — the legal entity that will sign the certificate, not the brand on the proposal. Empanelment attaches to an organisation, and organisations trade under names that differ from the ones CERT-In holds. If the proposal, the NDA and the draft certificate carry three different names, settle that before anything else: the certificate is worth exactly as much as the entity signing it.
- 02 Open the published list yourself and find that entity. The document is titled “EMPANELLED INFORMATION SECURITY AUDITING ORGANISATIONS by CERT-In” and sits on cert-in.org.in under Cyber Security Assurance, in the Empanelment section, as a single PDF. Search it for the registered name, not the brand. Do not accept a screenshot, a PDF extract or a certificate image from the vendor — the whole point of a published list is that you read the publisher’s copy.
- 03 Read that organisation’s snapshot, which is published in the same document. Every listed organisation is followed by a “Snapshot of skills and competence of CERT-In empanelled Information Security Auditing Organisation” running to thirteen numbered fields. CERT-In’s policy guidelines say in terms that the information on the CERT-In website helps an auditee evaluate manpower and skillset, relevant experience, categories of audit conducted, audits carried out in the last twelve months by sector, category-wise counts, technical manpower deployed with details, and tools used.
- 04 Check the as-at line at the foot of the snapshot. Each one ends with a note in the form “Information as provided by [organisation] on [date]”. The snapshot is self-declared by the organisation and stamped with the date it was supplied, and those dates vary widely across the list. A snapshot last refreshed two years ago is not evidence about this year’s bench, and saying so politely during evaluation usually produces a current one.
- 05 Map the categories you are buying to what the organisation actually does. CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines enumerate twenty-six kinds of engagement, from vulnerability assessment and penetration testing through source code review, cloud security testing, mobile application security auditing, red team assessment and AI system audits. The snapshot records capability category-wise and volume category-wise. “Empanelled” is not a single competence, and the gap between the two lists is where scope disputes start.
- 06 Name the people before the kick-off, not at delivery. Audit reports may be signed only by manpower declared to CERT-In in the organisation’s snapshot information — that is an unqualified rule. A separate rule governs who may be deployed: for Government and critical sector audits the organisation must deploy manpower declared to CERT-In in the snapshot information form. So ask for the named lead auditor and team, and check each name against field 7 of the snapshot, which is specifically the Government and critical sector manpower table.
- 07 Ask the exclusion question explicitly. The policy guidelines state that auditing organisations should not field freelancers, interns, freshers, moonlighters, third-party consultants or employees serving their notice period, and that auditee organisations should verify compliance. They also say the auditee must verify the identity, official identity cards or government-issued documents, and designations of the audit team. Put both into the contract and ask for a declaration. This is the commonest gap between the firm you bought and the team that turns up.
- 08 Check the movement rule if a named auditor recently changed employer. Where an employee moves between CERT-In empanelled organisations, a no-objection certificate or relieving letter from the previous organisation is required as part of the background check. A lead auditor who joined six weeks ago and does not yet appear in the snapshot is a question to ask before the kick-off, not a discovery to make at signature.
- 09 Confirm standing today, and again at award. The terms and conditions make empanelment valid for a defined block with annual review based on feedback from auditee organisations and review of the auditor’s performance. CERT-In may also temporarily withdraw or put empanelment on hold where audit quality falls short, and may terminate it outright. A list you downloaded last year is evidence about last year.
- 10 Read their own marketing as an integrity test. An empanelled organisation may use exactly one sentence about its relationship with CERT-In and may not use the CERT-In logo without prior written permission. A vendor that puts the logo on a proposal has either not read the terms it signed or decided they do not apply to it — and either answer tells you how it will treat the audit guidelines.
- 11 Ask how audit data will be handled, and where. The auditing organisation carries responsibility for client data it holds. Retained data must be encrypted with access on a need-to-know basis. The organisation must not share client data without explicit written permission from the auditee. CERT-In’s auditor guidelines require that data be wiped so it cannot be retrieved by any known forensic technique, with no mirroring outside the country. Ask for the destruction commitment in the contract — the instruments require the wipe, so the artefact evidencing it is yours to negotiate.
Verifying an STQC or SETL claim
The STQC route is not verified by looking a name up on a roster. It is verified by checking scope and issuer, because the scheme separates the two: the laboratory tests, and the Directorate certifies. Everything below comes from STQC’s own Website Quality Certification pages and the operations document for SETLs and technical oversight.
- Confirm the laboratory’s empanelment scope includes GIGW evaluation. STQC describes a SETL for this purpose as one of “STQC’s empaneled Labs (SETL) which have scope of GIGW evaluation”. Empanelment as a testing laboratory is not by itself authority to evaluate against GIGW, and scope is the check.
- Confirm who will issue, before you confirm who will test. STQC states that STQC labs and SETLs can only perform evaluation and shall not issue certificates, and that only STQC Directorate at Electronics Niketan can issue Website Quality Certificates. A certificate arriving on laboratory letterhead is the finding.
- Confirm the certification body’s oversight is in place. Under STQC’s operations document for SETLs, the STQC Certification Body may nominate a validator to review the testing approach, monitor the process on a sample basis and, where needed, visit the testing site for re-testing or additional testing — and the SETL is required to inform the certification body in time for that nomination.
- Confirm the route for the security-audit component separately. The scheme accepts a security audit conducted through STQC, a SETL, NIC or a CERT-In empanelled agency. If a CERT-In empanelled agency is doing it, you still run the full CERT-In verification sequence on that agency — the STQC scheme does not verify it for you.
- Confirm the prerequisite is met. STQC has notified a mandatory requirement of an IAAP certified auditor review report — IAAP being the International Association of Accessibility Professionals — as a pre-requisite for organisations applying for GIGW evaluation. It is an accessibility prerequisite, not a security one, and projects routinely discover it late.
- Confirm what you are actually buying. The Website Quality Certification Scheme grants the Certified Quality Website mark, valid for three years with annual surveillance and surprise surveillance audits, and charges are deposited in advance through the Bharatkosh portal. That is a different instrument, on a different clock, from an audit clearance for a build.
Verifying a NIC claim
The NIC route is the shortest to verify because there is almost nothing to verify and a great deal to disbelieve. It is arranged inside government, not procured.
- Establish that it is arranged, not bought. A NIC audit is obtained through your department’s own NIC channel. There is no register to look an auditor up in and no commercial counterparty, so the verification is that the request exists inside government and has a reference you can quote.
- Ask for the NIC reference rather than a vendor letter. If the document you are being offered originates with a private firm and merely asserts NIC acceptance, you are being sold a third-party audit under a government label.
- For anything going onto NIC National Cloud, read the condition on third parties. The terms state that security audit by the third party audit agency or by the NIC Security division should be completed prior to hosting of application on cloud, and that a third party audit security agency should be CERT-In empanelled agency only. That sentence converts a NIC hosting decision into a CERT-In verification exercise.
- Treat the exigency provision as a recorded risk acceptance, not a workaround. The terms provide that in case of exigencies, provision will be made to host sites without security audit for a limited period of time, that this hosting will be at owner’s risk, and that NIC will not be responsible for any issue arising as a result of hosting an application prior to completion of audit. That is a decision for whoever owns the risk, in writing, with an end date.
What a bad empanelment claim actually looks like
A state department is procuring a security audit for a citizen-facing mobile application before go-live. Two bids arrive. The evaluation committee runs five steps of the sequence above against the lower-priced bidder. Every check returns something. The scenario below is assembled from the failure patterns the published instruments are written to prevent — it is not an account of any real engagement or organisation.
| Step 1 — the name | What the check returned. The proposal, the covering letter and the CVs all carry a short brand name. Asked for the registered entity, the bidder supplies a differently named private limited company and explains that it is “the same group”. The draft certificate in the annexure carries a third name. | Why it matters. Empanelment attaches to one legal entity. Until the entity that will sign is named and matched, nothing else on the list can be checked. This is the cheapest finding on the page and the one most often skipped. |
| Step 2 — the list | What the check returned. Searching the published PDF for the registered name returns nothing. Searching for the brand returns nothing. Searching for the third name — the one on the draft certificate — returns a numbered entry with a different postal address and a different contact person. | Why it matters. The bidding entity is not the empanelled entity. Whether the arrangement is a group company, a channel partner or an outright resale, it collides with the prohibition on sub-letting or outsourcing an audit assignment, and it means the department has evaluated a firm that will not do the work. |
| Step 3 — the snapshot | What the check returned. The snapshot for the empanelled entity is dated more than two years earlier. Field 3 shows a Yes against web application and network security audit. There is no mobile application entry at all, and field 5 shows no category-wise count for mobile work. | Why it matters. The engagement is a mobile application audit. The record does not evidence that category. The organisation may well be capable. The point is that it has not said so to CERT-In, and the tender is the place to require category-level evidence rather than a status. |
| Step 6 — the people | What the check returned. The named lead auditor does not appear in field 7, the Government and critical sector manpower table. Asked directly, the bidder says he joined six weeks ago from another empanelled firm and the snapshot is “due for update”. | Why it matters. Audit reports shall be signed only by manpower declared to CERT-In. A lead auditor absent from the declared manpower cannot sign the report you are buying. There is also a background-check question on the move between empanelled organisations, and a snapshot refresh CERT-In expects the organisation to keep current. |
| Step 10 — the marketing | What the check returned. The bidder’s website carries the CERT-In logo in its footer and the phrase “CERT-In certified security auditors” on its services page. | Why it matters. Neither is permitted. The logo requires prior written permission with wording and presentation submitted to CERT-In first. The only sentence allowed without permission is the one in clause 4.2, and “certified” is not a status CERT-In confers. On its own it is a marketing lapse. Arriving fifth, after four substantive findings, it stops looking like carelessness. |
The note to file, as written
Empanelment verified against the list published at cert-in.org.in (Cyber Security Assurance → Empanelment by CERT-In), read on [date]. Entity as listed: [registered name, serial number on the list]. Bidding entity: [name] — not the listed entity. Clarification sought on [date]. Categories evidenced in the published snapshot (dated [date]): [list]. Categories required by this tender: [list]. Named audit team checked against snapshot field 7 (Government and critical sector manpower): [confirmed / not confirmed, with names]. Standing re-confirmed at award on [date].
Six lines, written once, at evaluation. It is the artefact a reviewing authority asks for two years later when somebody queries the certificate, and the reason to write it is that reconstructing it afterwards is not possible — the published list changes without a version number, so the only record of what it said on the day you read it is the one you made.
How long empanelment lasts, and how you tell it is still current
Clause 1.1 of the terms and conditions states that empanelment is valid for a defined block, unless otherwise specified, with annual review based on feedback from auditee organisations and review of the auditor’s performance, and that it is eligible for renewal on the same date as per the process prescribed at the time. Two practical things follow, and a third that the instruments do not answer.
First, the published list does not carry a per-organisation validity field. Each entry gives name, address, contact details and the snapshot. There is no “valid up to” column to read. The list’s own header does the work instead: it states that this is the up-to-date valid list and that it is updated as soon as there is any change. In other words, presence on the list as at the date you read it is the evidence of standing, and there is no second field to corroborate it with.
Second, a suspension does not appear as an annotation. CERT-In’s graded actions include moving an organisation to a watch list, suspending it, and withdrawing empanelment, and clause 8.2 allows CERT-In to temporarily withdraw or put the empanelment status on hold. None of those states has a published label on the list. What you can observe is presence or absence. So the operational rule is a two-moment check: read the list at award, and read it again at the moment the certificate is issued. If an organisation appeared on a copy you saved last year and does not appear on today’s page, do not treat that as a formatting change — ask the organisation, in writing, to state its current status, and ask CERT-In’s empanelment group if the answer is unsatisfactory.
The question nobody answers, answered honestly
Does an already-issued certificate survive the auditor’s later suspension or de-empanelment? The published instruments do not say. GIGW, the empanelment terms and the policy guidelines all address who may issue and what happens to the auditor, but none of them addresses the status of a certificate already in the auditee’s hands when the issuer’s standing later changes. Anyone who tells you otherwise should be asked for the clause. What the instruments do give you is the shape of the conservative practice, and it is the one we would follow: verify standing at award and again at issue, keep a dated note of both, and where the status changes between those two moments, do not argue that it was valid when the work was done — use the exit clause the policy guidelines recommend, and have the report re-issued by an organisation whose standing is current. The cost of doing that is a re-audit. The cost of not doing it is discovering the question for the first time in front of somebody else’s auditor.
STQC and STQC empanelled testing laboratories
STQC is the Standardisation Testing and Quality Certification Directorate, an attached office of the Ministry of Electronics and Information Technology. It is a government testing and certification body — not a commercial auditor — and the route it offers is shaped by that.
The first thing to get right is the vocabulary. SETL stands for STQC Empanelled Testing Laboratory. For website work specifically, STQC describes the relevant labs as STQC’s empaneled Labs (SETL) which have scope of GIGW evaluation — so empanelment alone is not the qualification. The laboratory’s scope has to include GIGW evaluation. A SETL’s testing work is expected to meet the competence requirements of ISO/IEC 17025, and the STQC Certification Body may nominate a validator to review the approach, monitor the process on a sample basis and, where necessary, visit the testing site for re-testing or additional testing.
The second thing to get right is who issues. STQC states it plainly: STQC labs and SETLs can only perform evaluation and shall not issue certificates, and STQC Directorate at Electronics Niketan only can issue Website Quality Certificates. That single sentence is the most useful verification tool on this route, because it converts a vague question — is this laboratory legitimate? — into a concrete one you can answer from a document: is the body proposing to sign the certificate the Directorate, or the laboratory that did the testing? If it is the laboratory, stop.
The Website Quality Certificate is not the safe-to-host certificate
This is the commonest category error on the STQC route, and it survives a long way into projects. STQC’s Website Quality Certification Scheme assesses conformity with GIGW and grants the Certified Quality Website mark. The certificate remains valid for three years with annual surveillance and surprise surveillance audits, and evaluation charges are deposited in advance through the Bharatkosh portal. It is a certification of a website and the processes behind it, on a three-year cycle.
The audit clearance or safe-to-host certificate is a different instrument on a different clock: it speaks to a security audit of a specific application build and, as worded on specimen certificates published on government websites, lapses when the application hash value or dynamic content changes, or one year from the date of issue, whichever is earlier. A project can genuinely need both. Neither substitutes for the other, and the two validity periods are not comparable. See how long a safe-to-host certificate stays valid for the detail, and GIGW compliance before go-live for where both sit in a launch plan.
Two more scheme details catch departments out. The security-audit component under the scheme may be conducted through STQC, a SETL, NIC or a CERT-In empanelled agency — so choosing STQC for certification does not decide who does your security audit, and if the answer is a CERT-In empanelled agency you still run the full CERT-In verification sequence on it. And STQC has notified a mandatory requirement of an IAAP certified auditor review report — IAAP being the International Association of Accessibility Professionals — as a pre-requisite for organisations applying for GIGW evaluation. It is an accessibility prerequisite rather than a security one, it sits upstream of everything else, and projects routinely find out about it after the security work is finished.
NIC — the route you cannot buy
The National Informatics Centre is the government’s own IT services organisation. GIGW 3.0 guideline 5.3.1 names it as an eligible issuer, and for a great many government applications it is the practical answer — because NIC built the application, hosts it, or both.
What makes this route different is that there is no market in it. A NIC security audit is arranged through a department’s own NIC channel as a government function. There is no register of NIC auditors to check, no commercial contract to negotiate, and no certificate a vendor can offer to obtain on your behalf. That last point is the one worth carrying away: if a private firm offers to arrange NIC certification for you, the offer itself is the finding, and the honest translation is usually that it intends to perform a third-party audit and describe the result as NIC-accepted.
What the NIC National Cloud terms actually require
For anything being onboarded to NIC National Cloud, the governing document is the National Cloud of NIC terms and conditions, and it says three things a project team needs to know before it plans a go-live date.
- A security audit by the third party audit agency or by the NIC Security division should be completed prior to hosting of application on cloud — the audit is a precondition of hosting, not a task that runs alongside it.
- A third party audit security agency should be CERT-In empanelled agency only. If you are not using the NIC Security division, the NIC decision has just become a CERT-In verification exercise, and the whole sequence earlier on this page applies.
- In case of exigencies, provision will be made to host sites without security audit for a limited period of time. This hosting will be at owner’s risk, and NIC will not be responsible for any issue arising as a result of hosting of an application prior to completion of audit.
The exigency provision deserves a sentence of its own, because it is routinely misunderstood in both directions. It is not a loophole — it is a named, limited-period risk acceptance that transfers responsibility explicitly to the application owner and explicitly away from NIC. And it is not a secret — it is published in the terms every department accepts. The correct use of it is a written decision by whoever owns the risk, with an end date and a committed audit date. The incorrect use is a project manager invoking it verbally to protect a launch date, which leaves an application live, an audit outstanding, and no record of who accepted what.
One further framing point. The terms state that the National Cloud is operated and managed as per the security guidelines and policies issued by CERT-In and the Cyber Security Group of NIC. That is why the CERT-In instruments cited throughout this page govern an estate NIC runs: it is not that CERT-In supervises NIC, but that NIC has adopted CERT-In’s security guidance as the operating standard for the cloud, which is also why a third-party agency working there has to be empanelled.
When a regulator, not GIGW, is why you need an empanelled auditor
Most searches for “CERT-In empanelled auditor” do not come from government departments at all. They come from regulated private companies whose sectoral instrument names CERT-In empanelment, and from suppliers whose enterprise customer has written the phrase into a contract. GIGW does not apply to any of them. The table below keeps every row traceable to a named instrument, and the last column is the one that saves the most time — because in most of these situations “safe-to-host certificate” is simply the wrong word for what is being asked for.
| Sector | Mandating instrument | What it actually requires | What is actually submitted | Is “safe-to-host” the right word? |
|---|---|---|---|---|
| Government websites, portals and mobile apps | GIGW 3.0, guideline 5.3.1 | That the application 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. | The audit clearance certificate, to the hosting provider or the department’s own gate. | Yes — this is the setting in which “safe to host” is the correct term. |
| Applications hosted on NIC National Cloud | National Cloud of NIC — Terms and Conditions | A security audit completed before hosting, by the NIC Security division or by a third-party audit agency. A third-party audit security agency should be a CERT-In empanelled agency only. | The completed audit, to NIC, before the application is hosted. | Yes, and the exigency provision is the only documented exception. |
| SEBI regulated entities — exchanges, depositories, intermediaries, AMCs and others | Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities, August 2024 | VAPT conducted by third-party CERT-In empanelled agencies, with the agency’s CERT-In empanelment validity certificate submitted to SEBI. | VAPT reports and audit reports on the periodicity the framework sets, to SEBI — not a safe-to-host certificate. | No. Calling the deliverable a safe-to-host certificate here will confuse your own compliance team. |
| Aadhaar authentication and e-KYC user agencies (AUA/KUA and Sub-AUA/Sub-KUA) | UIDAI compliance checklists and AUA/KUA agreements | Audit of client applications and SDKs by a CERT-In empanelled auditor before go-live in production, before every major release and at least annually — covering VAPT, source code review and information security audit — with operations audited annually by a CERT-In empanelled audit agency. Cloud infrastructure audits require an agency authorised for cloud security audit. | Audit reports and signed compliance checklists, to UIDAI. | No. The instrument is an information security audit report against UIDAI’s checklist. |
| A private company asked by a customer for a “CERT-In certificate” | No instrument at all — a contractual ask, usually copied from a template | Whatever the contract actually says, which is usually an audit report from a CERT-In empanelled organisation rather than a certificate. Nothing in GIGW applies to a private application that is not a government website. | Most often a VAPT report on letterhead plus a remediation summary. Get the requirement in writing before you buy anything. | Almost never. Ask what document closes the clause. Half of these requests are satisfied without a certificate. |
Two things are worth saying plainly, because almost nobody says them. First, there is no general legal requirement for an Indian private company to use a CERT-In empanelled auditor. The requirement arises from a sectoral instrument, a government hosting arrangement, or a contract — and if none of those applies to you, empanelment is a quality signal you may reasonably want rather than a rule you must follow. Second, where the requirement does apply, it is usually specified as an audit by an empanelled agency rather than as a certificate. SEBI’s framework asks for VAPT by a third-party CERT-In empanelled agency and for that agency’s empanelment validity certificate, while UIDAI asks for audits on a defined cadence against its own checklist. Neither asks for a safe-to-host certificate, and asking your auditor for one will produce a confused conversation. If a customer has asked you for a “CERT-In certificate”, the first move is to read the clause — safe-to-host versus a security audit certificate walks through exactly that request.
Which route your tender or hosting provider will accept
Eligibility under GIGW is one question. What your specific project will accept is another, and it is usually decided by the hosting provider, the tender wording or a regulator rather than by the guideline.
| The project | Route that applies | What to settle first, in writing |
|---|---|---|
| A Government of India or state department website, portal or mobile app going live | Any of the three. GIGW 3.0 guideline 5.3.1 states the audit clearance certificate may be issued by NIC, STQC, an STQC empanelled laboratory or a CERT-In empanelled laboratory. | Which route your hosting provider and your department’s own IT policy will accept, in writing, before the tender is drafted. |
| An application being onboarded to NIC National Cloud | The NIC Security division, or a third-party agency — and the terms state a third party audit security agency should be CERT-In empanelled agency only. | Whether an exigency hosting window applies. The terms allow limited-period hosting without the audit, at the owner’s risk, which is a decision to take deliberately rather than discover. |
| A department pursuing STQC Website Quality Certification | Evaluation by an STQC laboratory or a SETL whose scope covers GIGW evaluation. The security audit component may be conducted through STQC, a SETL, NIC or a CERT-In empanelled agency. | Who issues. Only STQC Directorate issues the certificate, and the IAAP certified auditor review report is a prerequisite for GIGW evaluation. |
| A tender or regulator mandate that names CERT-In empanelment | Only a CERT-In empanelled organisation. STQC and NIC do not satisfy a clause that names CERT-In empanelment. | For the clause itself. “CERT-In empanelled auditor required” in an email is not the same as the wording in the tender document, and the wording decides the route. |
| A SEBI regulated entity, an AUA/KUA, or another entity under a sectoral mandate | A CERT-In empanelled organisation, on the cadence the instrument sets — and, for Aadhaar cloud infrastructure, one authorised for cloud security audit. | For the empanelment validity evidence your regulator expects you to hold, and the audit categories the instrument names, written into the scope. |
| A critical or high-user-reach application under continuous change | A CERT-In empanelled organisation on a multi-year engagement — the policy guidelines say contracts for such applications should be awarded for a period of two to three years to enable continuous audits at a defined frequency. | How re-audits after each significant release are priced, because the certificate is tied to the build that was tested. |
The exact words an empanelled organisation may use about CERT-In
This is the cheapest integrity test in the whole evaluation, and it takes about thirty seconds. Section 4 of the terms and conditions for empanelment permits one sentence and prohibits the logo. Read what a bidder has written about itself, then read the clause. A firm that gets this wrong on its own website has either not read the instrument it signed or decided it does not apply — and either answer predicts how it will treat the audit guidelines.
| The claim | Verdict | Why, and where it comes from |
|---|---|---|
| “This Organization is empanelled by CERT-In for providing information Security Auditing Service” | Permitted, exactly as written | Clause 4.2 of the empanelment terms and conditions (v7.2, April 2024) allows this sentence and no other. Any other words describing the relationship need prior written permission from CERT-In, with the proposed wording and presentation submitted first. |
| The CERT-In logo on a website, deck, proposal or report cover | Prohibited without prior written permission | Clause 4.1 of the same terms: the auditor shall not use the CERT-In logo, nor make any reference to its association with CERT-In on any publicity material, promotional material or product, without prior written permission. Clause 4.3 adds that the logo may never be used in a way that brings CERT-In into disrepute. |
| “CERT-In certified”, “CERT-In accredited”, “CERT-In approved”, “CERT-In partner”, “in association with CERT-In” | Not a real status, and not permitted wording | CERT-In empanels organisations. It does not certify, accredit, approve or partner with them. Clause 4.2 bars other words, and clause 2.1 is explicit that an auditor is contracted by the customer directly and CERT-In is not a party to such contracts — so it cannot be projected as one. |
| “Our auditors are CERT-In empanelled” | Category error | Empanelment attaches to the organisation. Individuals appear in the organisation’s snapshot information declared to CERT-In, and an auditor who leaves an empanelled firm does not carry empanelment with them. |
One postscript that applies after the relationship ends. Clause 9.3 of the same terms requires an auditor whose empanelment has been terminated, for whatever reason, to return documents and materials to CERT-In and to refrain from advertisement or making any claim regarding the status of empanelment that can be viewed or interpreted as valid empanelment. So a firm still displaying the claim is not merely out of date — it is in breach of a clause it agreed to. That is worth knowing when you are comparing a bidder’s website against a list it does not appear on.
Who has to sign the report and the certificate
Section 9.5 of the Comprehensive Cyber Security Audit Policy Guidelines sets out a chain with four links. It is short, it is specific, and it is the part of the instrument a reviewing authority is most likely to check — because unlike scope or methodology, it is visible on the face of the document.
The auditors who conducted the audit
They sign the report. Each must be manpower declared to CERT-In in the organisation’s snapshot information — which is why you asked for names before the kick-off and not at delivery.
A designated reviewer from mid-management, outside the audit team
Reviews and signs, to ensure an unbiased and quality review. A report reviewed by the person who wrote it has not met the requirement, however senior that person is.
The head of the auditing organisation
Authorises and signs — the guidelines give director, partner or CEO as examples — certifying the completeness, accuracy and integrity of the audit findings and recommendations. This is the signature that makes the organisation, not an individual, answerable.
The certificate itself
The audit certificate must be signed by both the lead auditor and the head of the auditing organisation. A certificate with one signature, an unnamed signatory or a scanned block with no designation is the first thing a reviewing authority notices.
The rule that gates all four is the first sentence of the clause: audit reports shall be signed only by the manpower declared to CERT-In, as listed in the organisation’s snapshot information available on the CERT-In website. Note that this is unqualified — it applies to every engagement, not only government work. A related but narrower rule governs deployment: CERT-In’s auditor guidelines require that for Government and critical sector audits, the organisation must deploy manpower declared to CERT-In in the snapshot information form. Keeping those two straight matters in a negotiation, because a vendor will sometimes concede the deployment point for a government engagement while quietly reserving the signing point. The signing point is the one that is universal.
What happens when an empanelled organisation falls short
Section 19 of the policy guidelines publishes a deter-and-punish matrix. It is worth reading for two reasons: it tells you what standing can be lost and how, and it tells you that auditee feedback is a live input rather than a courtesy. Feedback and suggestions go to the empanelment group at CERT-In, and adverse feedback from an auditee on technical competency is named as an indicative parameter for suspension.
| Grade | Indicative parameters | Action |
|---|---|---|
| Move to watch list, with warning and written commitment | Inadequate closure of non-compliances. Lack of relation between working notes and issues raised. Inadequacy of sample details, issues covered or conclusions. Violating the terms and conditions with minor impact. A first adverse report missing up to two vulnerabilities. Conflict with the auditee. A first instance of non-compliance with CERT-In’s data collection framework. | CERT-In issues a show cause, obtains a corrective action report from the auditing organisation, and issues a warning along with a written commitment. |
| Suspension | Adverse feedback from the auditee on technical competency and auditor attributes. Repeated failure in audit planning or coverage highlighted in CERT-In’s analysis. Issues appearing soon after an audit was conducted. Violations with major impact, multiple adverse reports of missing vulnerabilities, or multiple instances of non-compliance with the data collection framework. | Suspension, to be revoked based on satisfactory submission of corrective actions and witnessing, if needed. |
| Withdrawal of empanelment | Auditing malpractices, substandard services, failure to cover the scope of work. | Actions as per the General Financial Rules and O.M. No. F.1/20/2018-PPD dated 2 November 2021 of the Department of Expenditure, alongside de-empanelment by CERT-In. |
| Penal and legal actions | Breach of trust, digital break-in, damage and attempted damage to auditee interests and infrastructure. | As per applicable penal and legal acts and laws. |
Separately from the matrix, clause 9.1 of the terms and conditions lets CERT-In terminate empanelment where the auditor breaches the terms, where performance or competence degrades on CERT-In’s assessment, or where a change affecting qualifying status is not brought to CERT-In’s immediate notice — with the terms noting that failure to report changes in foreign tie-ups or manpower may lead to blacklisting along with de-empanelment. That is the clause that gives fields 11 to 13 of the snapshot their weight. Clause 9.2 requires CERT-In to give an opportunity to remedy a breach capable of remedy before terminating.
How these engagements actually go wrong
Naming a risk is easy. What decides whether it hurts is when it surfaces and who is holding it at that point. These four are the ones worth designing your process around, and the third column is the reason to run the verification sequence at evaluation rather than at award.
| What happens | When it surfaces | Who notices | What it costs to fix at that point |
|---|---|---|---|
| The team that arrives is not the team that bid | Kick-off, or the first working session — occasionally not until the report names a signatory nobody recognises. | Whoever runs the kick-off call, if they were given the bid team’s names. Nobody, if they were not. | Cheap at kick-off: you name the gap, the organisation substitutes a declared auditor, the schedule slips days. Expensive at report review: the report may have been signed by someone outside declared manpower, and the fix is a re-review and re-signature at best. |
| The certificate is issued on a staging build and production has since moved on | Go-live, or months later when a reviewing authority compares the hash on the certificate against what is running. | Usually nobody at the time. Later, an internal auditor, a departmental review, or the next tender’s evaluation committee. | At go-live, a re-audit of the changed components and a short delay. A year later, a clearance that no longer evidences anything, a live application with no current audit position, and a conversation about who approved the release. |
| The development vendor selected the auditor | Bid evaluation, if anyone reads the procurement trail. Otherwise at the first uncomfortable finding. | The reviewing authority, the internal audit function, or the regulator — rarely the project team. | The findings are not wrong, but their independence is arguable, and arguing it is not a position a department wants to be in. Re-procuring the audit under the owner’s own selection is the clean answer and costs a full cycle. |
| Empanelment lapses or is suspended between award and issue | At issue, if you re-check. Otherwise never — until someone else checks. | Whoever verifies the certificate downstream: the hosting provider, the sectoral regulator, or the next auditor. | This is the one the instruments do not resolve, and the reason the exit clause exists. The conservative practice is a two-moment check — standing at award and standing again at issue — and if the answer changes between them, the honest response is to have the report re-issued by an organisation whose standing is current rather than to argue that it was current when the work was done. |
For the wider set of reasons applications do not clear this gate — scope gaps, unclosed findings, environments that do not match — see why applications fail safe-to-host.
Six things in a proposal that should stop the evaluation
The CERT-In logo on a proposal, website or report cover
Using the logo, or referencing the association on publicity or promotional material or a product, requires prior written permission, with the wording and presentation submitted to CERT-In first. Assume it was not.
“CERT-In certified auditors”, “CERT-In approved”, “CERT-In partner”
None of these statuses exists. CERT-In empanels organisations, and clause 4.2 permits one sentence and no other. The phrasing usually travels with a reseller who has never read the terms and conditions.
A certificate offered before any testing is scheduled
A certificate is an output of an audit performed on a stated build in a stated environment. Quoted turnaround that assumes a clean result is quoting the document, not the work.
Fees payable on issue of the certificate
Payments contingent on the outcome of the audit, or tied to the submission or approval of closure reports, are precisely what the policy guidelines identify as compromising impartiality.
The proposal names no individual auditor
Reports may be signed only by manpower declared to CERT-In. If the firm will not name the team, it cannot demonstrate that the team is declared — and you cannot check field 7 of its snapshot.
The audit will be “handled end to end” by your development vendor
The policy guidelines put the whole process — defining scope, selecting the auditing organisation, providing access, ensuring closure — on the owner of the information infrastructure, and say the responsibility must not be delegated except where a regulator, government or relevant stakeholder specifically mandates otherwise.
The situations that come up once the engagement is live
Five scenarios the sections above do not already cover, each with what the published instruments actually say about it. These are the moments where a department decides, under pressure, whether it is running a process or performing one.
The organisation is empanelled, but not in the category you are buying
Empanelment is not a single competence. The policy guidelines enumerate twenty-six engagement types, and the published snapshot records, category by category, both what an organisation says it can audit and how many audits of each category it completed in the last twelve months. An organisation with deep web-application experience and no operational technology work is a poor fit for an ICS audit even though it is genuinely empanelled, and your tender is the place to say so. Ask for category-level evidence, not a status.
Findings are graded by adjective rather than by score
Auditors are required to implement both CVSS and EPSS within their audit reports: severity categorised under the Common Vulnerability Scoring System, supplemented with the Exploit Prediction Scoring System for real-world exploitation likelihood, with mapping to Common Weakness Enumeration and Common Vulnerabilities and Exposures. A report that says “medium” with no score, no weakness class and no evidence is not something your own team can triage, prioritise or defend to a reviewer a year from now.
You are asked for a certificate for an application still being built
The guidelines are blunt: an application developed without any secure design and development practices should not be considered for assessment and audits, the same should be informed to the auditee organisation in writing with a copy marked to CERT-In, and both parties must confirm that the application is designed and developed with secure practice prior to commencing any assessment. They also expect auditee organisations to make “Secure by Design” principles and secure application development practices mandatory requirements in their own RFPs and tenders. An audit is not a substitute for a secure development lifecycle.
The Website Quality Certificate is offered as the safe-to-host certificate
They are different instruments on different clocks. STQC’s Website Quality Certification Scheme grants the Certified Quality Website mark, valid for three years with annual surveillance and surprise surveillance audits, and it is issued by STQC Directorate alone. The audit clearance or safe-to-host certificate speaks to a security audit of a specific build and, as worded on specimen certificates published on government websites, lapses when the application hash value or dynamic content changes, or one year from issue, whichever is earlier. A project can need both. Neither substitutes for the other.
The audit team wants to keep a copy of everything afterwards
Responsibility for client data preserved by the auditing organisation remains with that organisation. Where data is retained after sign-off it must be encrypted with access provided only on a need-to-know basis, and the organisation should not share the client’s data without explicit written permission from the auditee. CERT-In’s auditor guidelines require that data be wiped so it cannot be retrieved by any known forensic technique and that there be no mirroring of data outside the country. One carve-out is published and worth knowing: empanelled organisations provide audit reports and data to CERT-In itself without the auditee’s explicit permission, and are required to share the report and audit metadata with CERT-In within five days of completion of the audit.
What to ask for in a tender response
Fourteen asks, each one traceable to a published obligation rather than to preference. That is what makes them usable: a bidder cannot reasonably object to a clause that restates a rule it has already agreed to. Where an item below is a recommendation rather than an obligation, the third column says so, because writing a preference into a tender as though it were a requirement is its own kind of error.
| Ask for | What good looks like | Why it is defensible |
|---|---|---|
| The empanelment declaration, in CERT-In’s own words | The sentence “This Organization is empanelled by CERT-In for providing information Security Auditing Service”, with the registered entity name, and nothing more decorative than that. | It is the only wording clause 4.2 of the terms and conditions permits without prior written permission. A bidder who writes it correctly has read the instrument. A bidder who embellishes it has not. |
| The named audit team, mapped to declared manpower | Lead auditor and team members by name and designation, each traceable to the organisation’s snapshot information published by CERT-In, with a commitment not to substitute without written notice. | Audit reports shall be signed only by the manpower declared to CERT-In, and for Government and critical sector audits the organisation must deploy manpower declared in the snapshot information form. Names are the control. A headcount is not. |
| A declaration on who will not be deployed | A signed statement that no freelancers, interns, freshers, moonlighters, third-party consultants or notice-period employees will be deployed, and that you may verify identity documents and designations on site. | The policy guidelines state this directly and place the verification duty on the auditee. Without the clause you have no contractual hook when a stranger joins the call. |
| The audit categories being bought, written out | The specific engagement types from the policy guidelines — application security testing, source code review, cloud security testing, network infrastructure audit, red team assessment — rather than the word “VAPT” alone. | Scope drift is the commonest dispute in these engagements, and the twenty-six-category list is a shared vocabulary you and the auditor can both point at. |
| Methodology, and the tools behind it | A written methodology with manual testing described, the standards referenced, the tool list, and evidence that a separate verification team re-checks the testing team’s work. | CERT-In’s auditor guidelines require industry-standard methodologies and discourage solely tools-based testing, and the policy guidelines ask for a maker-checker arrangement in which a separate verification team validates the audit team’s work. |
| Where the testing will happen | A statement that the application will be tested on the staging server or testing environment provided by the hosting service provider before the audit certificate is issued, and that the environment tested — Test, Development, UAT, Pre-Production or Production — will be stated in the report. | Both are explicit requirements. The second is the one people forget, and it is what stops a report being read as broader than the work. |
| Artefacts that pin the build | Application hash values and version numbers obtained from you and included in the report, with timestamps, and carried onto the certificate. | The guidelines require hash values and version numbers to be obtained from the auditee and included in the audit report, and recommend that hash values, versions and timestamps be prominently featured in the certificate and reports. They are what makes a certificate checkable months later. |
| Findings scored the way CERT-In expects | Every observation carrying a CVSS severity, an EPSS likelihood, and a mapping to CWE and, where applicable, CVE. | The policy guidelines require auditors to implement both CVSS and EPSS within their audit reports — CVSS for severity, EPSS for real-world exploitation likelihood — with mapping to CWE and CVE. A bid that does not mention EPSS is usually reusing a template written before July 2025. |
| Closure timelines and the follow-up audit | Timelines for closure by severity, a follow-up audit priced inside the scope, and the final report issued after closure and follow-up audit of the application hosted on production. | The guidelines say follow-up audits should be included within the scope or RFP proposal. Buying the first audit and not the re-test is how a department ends up with findings and no clearance. |
| Data handling, retention and destruction | Audit data held in India, encrypted, accessible on a need-to-know basis, shared only with your named point of contact by secure means from official email addresses, and destroyed on completion — with written confirmation of destruction as a contractual ask. | Encryption, need-to-know access, no sharing without your explicit written permission, secure delivery and forensic-grade wiping are auditor obligations. The written confirmation is not. It is a reasonable thing to negotiate for, and worth labelling as your ask rather than their duty. |
| Commercial independence | Fees fixed against predefined scope, deliverables and timelines — explicitly not contingent on the outcome of the audit, nor tied to the submission or approval of any closure reports. | The policy guidelines treat that arrangement as compromising impartiality and creating a conflict of interest. A bidder offering “payment on certificate” is proposing the exact structure the guidelines warn against. |
| Contract length and an exit | For critical or high-user-reach applications, a two to three year engagement enabling continuous audits at a defined frequency, plus a clause letting you stop the audit and choose another auditing organisation within a reasonable time if credibility becomes unclear. | Both are set out in the policy guidelines under contractual guidelines and contingencies, and the exit clause is the one nobody writes until the first time they need it. |
| No sub-letting of the assignment | A clause that the empanelled organisation performs the audit itself and does not sub-let or outsource the assignment. | Sub-letting or outsourcing an audit assignment is named among the activities an empanelled organisation should not engage in. It is also how an unverified team ends up inside your environment. |
| The NDA and the escalation path | A legally enforceable NDA signed before the project commences, a named point of contact on both sides, and agreement on how disputes and pressure on findings get escalated. | An NDA before commencement is required, and the guidelines expect an auditor facing pressure tactics, coercion or undue influence from the auditee to escalate the matter promptly to CERT-In. Better to have agreed the path while everyone is calm. |
If you want a template for the deliverable itself rather than the procurement, Annexure II of the terms and conditions publishes the audit report content format CERT-In expects: identification of the auditee with address and contact information, dates and locations of audit, terms of reference as agreed (including the standard for audit), the audit plan, explicit reference to key auditee documents by date or version, additional mandatory or voluntary standards applicable, a summary of findings (including identification tests, tools used and results), analysis of vulnerabilities and issues of concern, recommendations for action and follow-up audits, and the personnel involved in the audit, including identification of any trainees. Quoting that list in an RFP does more work than three paragraphs of your own drafting.
What people actually say when this comes up
“Everyone says they are CERT-In empanelled. How am I supposed to tell?”
By reading the publisher’s copy rather than the vendor’s. CERT-In publishes one PDF titled “EMPANELLED INFORMATION SECURITY AUDITING ORGANISATIONS by CERT-In” under Cyber Security Assurance on its own site, and it contains both the numbered list of organisations and, for each one, a thirteen-field snapshot of skills and competence stamped with the date the organisation supplied it. The policy guidelines say the information on the CERT-In website should be used by organisations or sectoral regulators when selecting an auditor. Ten minutes in that document settles a claim a procurement cycle would otherwise carry to award.
“The bidder is on the list. Is that not enough?”
It is the floor, not the answer. Presence tells you the organisation cleared the process, but it does not tell you it has done your category of work, that the people who will run your engagement are declared to CERT-In, or that its standing is current. Empanelment carries an annual review against auditee feedback and performance, and CERT-In operates graded actions from a watch list through suspension to withdrawal. Verify the category, the people and the date — not just the name.
“Our hosting provider says any CERT-In certificate will do.”
Then get that in writing, with the route named, because the routes are not interchangeable in every project. GIGW 3.0 allows NIC, STQC, a SETL or a CERT-In empanelled laboratory. NIC National Cloud requires a third-party agency to be CERT-In empanelled. A tender clause naming CERT-In empanelment is satisfied only by a CERT-In empanelled organisation. The cheapest moment to discover which rule governs your project is before the tender, not at go-live.
“Can we not just use our existing penetration testing vendor?”
You can, for testing — and you should keep testing on a normal cadence regardless. What that vendor cannot do, unless it is empanelled, is issue the certificate a government project needs, because eligibility attaches to the issuer rather than to the quality of the work.
“We are a private company. Does any of this apply to us?”
GIGW does not — it governs Indian government websites and apps. What may apply is a sectoral instrument or a contract. SEBI’s Cybersecurity and Cyber Resilience Framework requires VAPT by third-party CERT-In empanelled agencies and asks for the agency’s empanelment validity certificate. UIDAI requires AUA/KUA client applications and operations to be audited by CERT-In empanelled auditors on a defined cadence. And a large customer may simply have written “CERT-In empanelled auditor” into your contract. In none of those cases is the deliverable properly called a safe-to-host certificate — so the first move is to read the clause and find out what document actually closes it.
We deliver CERT-In audits
We deliver CERT-In audits, end to end, with our CERT-In empanelled partners. See how a CERT-In audit runs with us.
If you are working out which route your project needs, or you want a second pair of eyes on a bid you are evaluating, talk to a compliance advisor. If you are running the process yourself, the verification sequence above is the same one we would run, and it is deliberately written so that you do not need us to use it.
Every instrument cited on this page, by its published title
Each of these was read directly. Where a claim could not be traced to one of them it was removed rather than softened, which is why a few things you may have read elsewhere — on empanelment fees, pass rates, turnaround times or headcounts — do not appear here.
- Guidelines for Indian Government Websites and apps (GIGW) 3.0 — security guidelines and attributes National Informatics Centre with the Department of Administrative Reforms and Public Grievances Guideline 5.3.1 and the structure each guideline is written in.
- New features of GIGW 3.0 National Informatics Centre The “safe to host” formulation and what carries forward from the previous version.
- Terms and Conditions for Empanelment, Version 7.2, April 2024 Indian Computer Emergency Response Team (CERT-In), MeitY Clauses 1.1 duration, 2.1 contracting, 3.1 and 3.2 responsibilities and reporting, 4.1–4.3 advertising, 8 quality, 9 termination. Annexure I auditee expectations, Annexure II audit report content format.
- Comprehensive Cyber Security Audit Policy Guidelines, Version 1.0, 25 July 2025 Indian Computer Emergency Response Team (CERT-In), MeitY Section 4 applicability, 6 scope of engagements, 7 basic principles, 9 auditee responsibility, 10 auditor responsibility, 12 selection of auditor, 15 performance of the audit, 16 reporting, 19 consequences of non-compliance.
- Guidelines for CERT-In Empanelled Information Security Auditing Organizations, Version 3.0, May 2018 Indian Computer Emergency Response Team (CERT-In), MeitY People, technical, and process obligations, including staging testing, data handling and the deployment rule for Government and critical sector audits.
- EMPANELLED INFORMATION SECURITY AUDITING ORGANISATIONS by CERT-In Indian Computer Emergency Response Team (CERT-In), MeitY The published list, and the thirteen-field snapshot of skills and competence for each organisation.
- Directions under sub-section (6) of section 70B of the IT Act, 2000, dated 28 April 2022 Indian Computer Emergency Response Team (CERT-In), MeitY The six-hour incident reporting obligation and the 180-day log retention within Indian jurisdiction.
- Website Quality Certification Standardisation Testing and Quality Certification Directorate (STQC), MeitY Who evaluates and who certifies, SETL scope, the Certified Quality Website mark, validity and surveillance, the IAAP prerequisite and payment via Bharatkosh.
- National Cloud of NIC — Terms and Conditions National Informatics Centre Pre-hosting security audit, the CERT-In empanelment condition on third-party agencies, the exigency provision, and the governing security policy regime.
- Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities, August 2024 Securities and Exchange Board of India VAPT by third-party CERT-In empanelled agencies, and submission of the agency’s empanelment validity certificate.
- Compliance checklist for certifying compliance with controls that the AUA/KUA is required to have in place Unique Identification Authority of India Audit of AUA/KUA applications and operations by CERT-In empanelled auditors, and the cadence that applies.
Frequently Asked Questions
Who can issue a safe-to-host certificate in India?
How do I verify that an auditor is genuinely CERT-In empanelled?
Can an individual be CERT-In empanelled?
Is “CERT-In certified” or “CERT-In approved” a real status?
What is the difference between CERT-In empanelment and STQC empanelment?
Does an STQC Website Quality Certificate count as a safe-to-host certificate?
Can NIC issue a safe-to-host certificate for a private company?
Who has to sign the audit report and the certificate?
Can our development vendor or systems integrator arrange the audit for us?
How long does CERT-In empanelment last, and can it be withdrawn?
Does an already-issued certificate survive the auditor being de-empanelled later?
Can we host the application before the audit is finished?
Does being empanelled mean an organisation can do every kind of audit?
We are a private company. Do we need a CERT-In empanelled auditor at all?
Related Reading
What a Safe-to-Host Certificate Is
The audit clearance certificate GIGW 5.3.1 requires before a government application is hosted in production.
Read moreCERT-In Empanelment Explained
What an empanelled auditing organisation may claim, must do, and can be de-empanelled for.
Read moreHow to Verify a CERT-In Audit Certificate
Check the issuer, the signatures, the environment and the hash — before you accept the document.
Read moreHow 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 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 moreVAPT / Penetration Testing
Manual-first web, API, network and mobile testing with retest included.
Read more