How to Verify a CERT-In Audit Certificate Is Genuine.

A certificate is a conclusion. Verifying it means checking four separate things: the organisation that signed it, the words it uses about CERT-In, the audit report behind it, and whether the scope it covers is the scope you are relying on. The first check is the one everybody runs, but the fourth is the one that decides whether the document answers your question.

Start here: there is no public lookup for a CERT-In audit certificate number. CERT-In publishes a list of empanelled organisations, not a register of certificates — so verification is a four-way comparison you run yourself, and this page is that comparison.

There is no public lookup for a CERT-In audit certificate number. CERT-In publishes a list of empanelled information security auditing organisations, not a register of certificates — so verifying one means running a four-way comparison yourself. First, check that the signing organisation appears today in that published list. Second, check that the document describes its relationship with CERT-In only in the one sentence CERT-In permits, with no CERT-In logo. Third, check that an audit report exists behind it containing the scope, environment, versions, severity scoring, closure timelines, follow-up audit and signatures CERT-In’s guidelines require. Fourth, check that the asset, environment and dates on its face match the system you are relying on it for. Three of those four are checks on the document. The fourth is a check on you — on whether the reliance you are placing on the certificate is the reliance the auditor actually supported. It is the check nobody puts in a checklist, and it is the only one that can fail on a document in which every other field is correct. One step sits outside the four and is easy to miss: writing to the organisation that signed the certificate and asking it to confirm the document is its own. That is the only check that tests this certificate rather than the firm named on it, and it has its own section below.

Two instruments govern all of this and both are public. The Terms and Conditions for Empanelment (version 7.2, April 2024) bind the auditing organisation: what it may say about CERT-In, what it must send CERT-In and when, and what happens when its standing ends. The Comprehensive Cyber Security Audit Policy Guidelines (version 1.0, 25 July 2025) set out how an audit is scoped, performed, evidenced, reported and signed — and they are explicitly addressed to auditee organisations as well as auditors, which means a large part of the method below is simply CERT-In telling you what to check. Where a government website or app is involved, a third instrument applies: the Guidelines for Indian Government Websites and Apps (GIGW) 3.0, formulated by the National Informatics Centre with the STQC Directorate and CERT-In, whose guideline 5.3.1 is the safe-to-host requirement. Every requirement on this page carries the clause it comes from, and every instrument is named and linked in the references section at the foot of the page, so you can check us as well as the certificate.

CERT-In itself does not audit your application, issue your certificate, or countersign anybody else’s. It empanels organisations, receives the audit report and metadata within five days of completion, and acts on quality. A surprising number of documents in circulation imply otherwise, and that implication is the first thing worth testing.

The method runs on three clocks, which is worth knowing before you start. Steps one to five take under an hour and need nothing from the vendor except a name. Steps six and seven are two emails. Send them on day one so the wait runs alongside the desk work rather than after it. Steps eight to twelve need the audit report, which needs an NDA, which in practice means one to three weeks of elapsed time and very little of your own attention — and a decision about how much you care, worth taking deliberately rather than by default.

Step thirteen produces an artefact, and this is its shape. Seventeen fields, one page, kept with the contract rather than in an inbox. It exists so that the next person to ask “are we covered?” gets an answer with a date on it instead of a memory, and so that a disposition of “reliance withheld” is a recorded decision rather than an unfinished conversation.

Three of these rows do more work than the rest. “Date the list was read” gives the check a shelf life, which stops a verification done eighteen months ago from being quoted as current. “Issuer confirmation obtained” is the only row whose subject is the document rather than the firm. And “disposition” has exactly three permitted values — verified, verified with exceptions, reliance withheld — because a fourth value is always some version of “probably fine”, and that is the state this whole page exists to eliminate.

Three permitted values are only useful if it is settled in advance which findings produce which, because the last step of a method is where judgement quietly turns into preference. Read the rows top-down and stop at the first that matches: the reliance-withheld rows are not cumulative with the others, they end the question. Note that one disposition splits by reliance rather than by document — the same certificate can be adequate for a pre-production question and inadequate for a production one, and saying so precisely is more useful to the vendor than a flat refusal.

The failure-mode table further down uses this same vocabulary in its last column, so a signal you find there maps straight onto a disposition here without a second translation.

CERT-In publishes the list of empanelled information security auditing organisations on its own site, and the list states on its face that it is updated as soon as there is any change in it. The guidelines print the navigation path to it twice — at §10.2(vi) and §12.3(iii), both giving it as cert-in.org.in, then Cyber Security Assurance, then Empanelment by CERT-In — and §12.1(i) is explicit that the published snapshot information “should be utilized by the organizations or sectoral regulators to identify and select the auditing organizations by mapping their requirements with the competence of auditing organizations”. That is CERT-In telling procurement teams to do exactly this check. Nine things are worth confirming. The first — is the name there — is the one the check usually gets reduced to, and it is the weakest of the nine on its own.

The published list is a PDF, not a search box, and it runs to hundreds of pages. It opens with a numbered directory of empanelled organisations — for each one the registered name, postal address, website URL, telephone and fax, a named contact person and an email address — and then runs a second, much longer part: one snapshot of skills and competence per organisation. That second part is what makes the category check and the declared-manpower check executable rather than rhetorical.

Two limits are worth knowing before you go looking. The capability matrix is self-declared and phrased in each organisation’s own categories, so it will not always map cleanly onto the Section 6 names used in a tender — which means the honest reading of a matrix is “what this organisation says it does” rather than “what CERT-In has assessed it to do”. And the named manpower table is scoped to Government and critical-sector deployment, with an instruction to attach an annexure if required — so an individual working on a private-sector engagement may be declared to CERT-In without appearing in the published extract. The check is still executable. It just does not always terminate in the PDF.

Ask for a written representation rather than abandoning the check. Two sentences, from the head of the auditing organisation, on letterhead, attached to the contract as a numbered schedule:

“We confirm that each individual named in Schedule [n] is manpower declared to CERT-In in our Snapshot Information Form as at the date of this letter, and that the audit report and certificate for this engagement will be signed only by such declared manpower. We will notify you in writing of any change to the named team before it takes effect.”

That sentence is cheap for a compliant firm to sign and expensive for a non-compliant one, which is the whole point of asking for it in writing. Pair it with §12.2(iii): verify identity, official identity cards or government-issued documents and designations when the team actually arrives.

Section 6 of the Comprehensive Cyber Security Audit Policy Guidelines lists the types of audit and assessment that fall within its scope, “including, but not limited to” the twenty-six below. This is the list a tender is reaching for when it says “VAPT”, and the list a vendor is flattening when it says it is “empanelled” without saying for what. The same section opens with the annual-coverage expectation: auditee organisations “are expected to ensure a comprehensive audit covering all aspects of their Information and Communication Technology (ICT) systems at least once a year”, and may opt for additional assessments during the year.

Read the table as a procurement instrument rather than a glossary. Most disputes about coverage are really disputes about which row was bought: a tender that says “VAPT” is reaching for rows iii and iv, an app store release needs row xiii and not row xii, a cloud migration needs row xviii, a model in production is row xxiii, and a dependency-heavy build is row xxvi. Naming the row in the scope of work removes an argument you would otherwise have after the report arrives.

For the routes other than CERT-In empanelment — STQC, an STQC-empanelled laboratory, and NIC — and how each is checked, see who can issue safe-to-host certificates. A certificate from NIC or STQC is not a CERT-In certificate and is not checked against the CERT-In list at all, which is a distinction worth settling before you go looking for a name that was never going to be there. For how an organisation gets onto the list in the first place, see CERT-In empanelment explained.

This is the cheapest check in the set and it runs in seconds. Clause 4.2 of the empanelment terms permits one form of words and bars every other description of the relationship without CERT-In’s prior written permission. Clause 4.1 prohibits the logo and any reference to the association on publicity or promotional material or product on the same terms. Section 10.5 of the 2025 guidelines repeats both. Run the test on all five surfaces — the certificate, the report cover, the proposal, the covering email and the website — and record the result per surface rather than as a single pass or fail, because a document that is correct and a website that is not tell you two different things about the same firm.

Two cautions on how to use this. First, a wording failure is a governance signal, not proof that the audit was bad — plenty of competent firms have a careless marketing page. Treat it as a reason to read the report rather than as a reason to disqualify. Second, the test cuts both ways: a vendor whose website says nothing more than the permitted sentence is not being modest, it is being correct, and reading that as weakness is how buyers end up rewarding the firms that overclaim.

The certificate is the conclusion. The report is the work, and §16.1(ii) is unusually specific about what it must contain: it “should be clear, precise and comprehensive to include all details of audit process, detailed scope, duration of audit, methodologies/standard used, tools, manual process, findings, prioritization, sampling decisions, manpower involved, exemptions, limitations and other constraints”. That sentence alone converts most of the verification into a checklist. Thirteen fields carry almost all the signal, and each row below names the clause it comes from so you can check it yourself.

Environment, version and hash, and the follow-up audit carry more weight than the other ten together, because each one is what attaches the document to something real. Environment attaches it to a system: staging is the correct place to start under §15.2.3(ii), which is why so many reports say it, and §16.3(v) is what stops it being the place to finish. Version and hash attach it to a build, which is the only reason §9.5(i) asks the auditee to capture them rather than the auditor. And the follow-up audit attaches the word “closed” to a test rather than to an email.

Two practical notes that the clauses do not give you. Buy the follow-up audit at scoping rather than afterwards — §13.1.1(g) requires the scope of work to specify it, and a retest negotiated after a findings table has been marked closed is a different conversation at a different price. And when you take the hash, take the algorithm and the exact artefact hashed with it: published specimen certificates differ on this, one printing a sixty-four-character value with no algorithm named at all, which is a number nobody can reproduce a year later when it matters.

One line belongs in the contract before the engagement starts, because §18 makes it a request rather than an entitlement: the working notes and the evidence appendix. A contract that never asked is a report whose evidence is gone.

There is no single prescribed certificate template — the report format is agreed between auditee and auditor before the audit commences, and issuing bodies set their own wording. What is consistent is what a reader needs in order to rely on it. The figure below is an illustrative layout, not a reproduction of any issuer’s document and not an endorsement of any format. The numbers key to the eleven fields listed underneath it.

The validity line deserves its own attention, because it is the field most often assumed rather than read. There is no single market rule: published specimen certificates express it differently from one another, one tying validity to changes in the hash value or dynamic content and one stating a maximum of one year from the date of issue plus a re-audit on any change to the source of the tested application. Neither is a quotation from CERT-In or from GIGW — both are the issuing body’s own wording. For the rules that sit behind them, and what a major change actually means, see how long a safe-to-host certificate stays valid. And for what separates the certificate from the report, and both from a VAPT deliverable, see safe-to-host versus security audit certificate.

A picture of a signature on a PDF is a picture. A digital signature is a claim you can test, and testing it is the fastest check on this page — about ninety seconds against a document already in your hand. It answers a question none of the four checks reaches: whether the file you are holding is the file that was signed. Open the signature panel in the reader rather than looking at the image on the page, and read four things.

Two practical notes. Ask for the originally signed PDF rather than a print, a scan or a re-export, because each of those destroys the signature while leaving the picture of it intact — which is why a scanned wet signature and a stripped digital one look identical on the page. And where no verifiable signature exists, the document’s integrity rests entirely on the confirmation request to the issuer, which is the reason that check sits above this one rather than below it.

The first row is the one to read twice, because it is the only failure mode that survives every other check on this page and it is the only one that cannot be settled from the document’s own face. Below it sit the expensive ordinary failures, where the document is genuine and the claim around it is not. Each row separates what a signal proves from what it merely suggests, because treating a careless marketing page as fraud costs you good vendors, and treating a staging-only scope as a formality costs you a go-live. The last column is written in the same three dispositions as the decision table above, so a signal here maps straight onto an outcome there.

Two routes exist and both run through the same mechanism. Section 11(iii) of the guidelines makes auditee feedback to CERT-In both a right and a duty: feedback and complaints are kept confidential and acted upon, and the auditee feedback form may be requested from empanelment@cert-in.org.in. Section 11(iv) then says what happens with it — where adverse feedback is received or lapses in audit assignments are observed by or reported to CERT-In, actions under the deter-and-punish framework may be taken without reminder or notice. That framework is the graded ladder in §19: watch list, suspension, withdrawal of empanelment under the General Financial Rules, and penal and legal action, with breach of trust and digital break-in named in the last row.

What CERT-In does not do is adjudicate your contract. It will act on the auditing organisation’s standing, but it will not compel your vendor to re-audit, refund you, or accept your reading of the scope. Those live in the agreement between you and the party that gave you the certificate, which is why the verification record and a written list of unresolved items matter more than an escalation email. Where the certificate is fabricated outright and no empanelled organisation is involved at all, this is a misrepresentation question for your own legal advisers first.

A closing observation on fabrication, because it decides where the effort goes. Fabricating a certificate is easy and fabricating an organisation is hard — which is exactly why a fabricator borrows a real one rather than inventing a new one, and why the entity check has to be followed by an issuer confirmation rather than ended by one. Find the name in the published list and you have learned that the name is real. You have learned nothing about whether that organisation wrote this. The signals that catch a forgery are almost never in the document — they are in the failure to produce a registered entity reconcilable by CIN or GSTIN, an issuer who confirms the references and the build from its own record, a named lead auditor confirmed as declared manpower, a report that survives the thirteen-field read, and a delivery team whose email domain matches the signer. Ask for those five and a fabricated certificate stops being a document-forensics problem. For the application-side version of this — why a real audit ends without a certificate, and which finding classes actually withhold one — see why applications fail safe-to-host.

None of this is an argument for skipping the checks. It is an argument for knowing what you bought: four checks that reliably catch a document being asked to do something it cannot, and that do not, on their own, tell you whether the testing behind it was any good. The second question is answered by reading findings, not paperwork.

The same seventeen-field record, populated. It fits on one page, it names the gaps as assets rather than as adjectives, and it ends in a disposition somebody signed — which is the difference between a verification and a conversation.

The general lesson is worth extracting, because it generalises past CERT-In entirely. A certificate fails at the boundary between what it says and what you need it to say, and that boundary is invisible unless you write down the second half first. Every check in this page is a comparison. The document supplies one side. You have to supply the other, and you have to supply it before you start reading or the document will supply it for you.

Verification today is manual, and that is the honest position: you read a published list, you read a document, you write to the issuer, you compare. CERT-In has launched a platform called AMBAK for audit monitoring, benchmarking and analysis. Checked 22 September 2026: whether it becomes a public route for verifying an individual certificate is not stated by CERT-In, by MeitY or by the Press Information Bureau — so this page does not tell you it will, and neither should anyone else.

What the official record does confirm is set out below, drawn from two sources: the Press Information Bureau release of 29 April 2026 issued by the Ministry of Electronics and Information Technology (Release ID 2256581), and CERT-In’s own CERT-In Samvaad 2026 Conference Proceedings (2nd Edition), published on cert-in.org.in, at section 7.1 “Launch of AMBAK”.

Two claims about AMBAK circulate widely and neither appears in the press release or in the conference proceedings: that the platform is blockchain-enabled, and that audit reports and audit certificates become centrally verifiable through it from a specific date. Checked 22 September 2026: we have read both documents in full and cannot source either claim to CERT-In, MeitY or the Press Information Bureau, so this page does not assert them and you should not rely on a vendor page that does.

What can be said is the useful part anyway. CERT-In already receives the audit report and audit metadata for every audit an empanelled organisation completes, within five days of completion, and §10.6 says that data is collected to enable CERT-In to act on capacity building, the audit framework, benchmarking and quality control. A platform built for monitoring, benchmarking and analysis sits directly on top of that. If and when an official verification mechanism is published, it will supersede the issuer confirmation and leave the four checks exactly where they are: a central register can confirm that a certificate exists, but it cannot tell you whether the scope on it is the scope you needed. The negatives above are findings as at 22 September 2026 and no longer, so check cert-in.org.in for the current position rather than a secondary source.

For the full picture of what was launched at SAMVAAD 2026 and what the conference said about where audit practice is going — AI-driven red teaming, cloud, API and OT audits, the SBOM family and post-quantum readiness — see AMBAK and CERT-In SAMVAAD 2026, and for what CERT-In is and what statutory powers it holds, what CERT-In is.

Related reading: what CERT-In is, CERT-In empanelment explained, the rules an empanelled auditor works under, the CERT-In Directions of 28 April 2022, AMBAK and SAMVAAD 2026, who can issue safe-to-host certificates, how to get a safe-to-host certificate, safe-to-host versus security audit certificate, how long a certificate stays valid, GIGW compliance before go-live, and penetration testing and VAPT.