CERT-In Empanelled Auditors: Choosing One

The founder asked for 'the best CERT-In auditor' the way one asks for a restaurant. A blog offered a top-seven list. A cousin offered a discount. The bid, two tabs away, asked for an application-security assessment by a CERT-In empanelled organisation, with a retest of critical findings, completed before go-live on an air-gapped build. None of the restaurant advice had mentioned air gaps.

CERT-In publishes a list of empanelled information-security auditing organisations and describes an empanelment process on cert-in.org.in. That list is the only ranking that matters for eligibility, and it is not a ranking. It is a pass/fail of empanelment, with validity periods and, in the official materials, scope-related information you must read rather than invent.

This guide is how we choose an auditor when a ministry, PSU or campus will rely on the report. It is not a league table. We will not name a favourite firm here. If a vendor names one for you without looking at your scope, they are selling a logo.

Start on the official list, on the day you shortlist

Open the CERT-In empanelment page and download or view the current list. Confirm the firm is present, the empanelment is unexpired, and the identity matches the legal name that will sign the report. A marketing brand that is not the empanelled legal person is a problem.

Empanelment lapses. Firms rebrand. Do not rely on a report from three years ago as proof that the same logo is still empanelled today. The list is the living fact.

CERT-In empanelment is not a product certification of your agent. It authorises the auditor to perform certain audits. Your application can still fail the audit. That is the point.

Choose by scope, or you have chosen a theatre review

Write the object in one sentence: web application, API, mobile, infrastructure, ISO-style ISMS, source-code review, red team, or a combination. Then ask each firm whether their empanelment and their team for this engagement cover that object.

An infrastructure-heavy firm that has never read an LLM tool-calling path will produce a clean report on ports and a silent miss on prompt injection into a tool that can write to a system of record. That report will look official. It will not have tested the thing that can hurt a citizen.

For air-gapped installs, ask how they work without a standing tunnel: on-site days, media in/out, their own laptop policy, and whether they will accept your jump-host rules. If their only method is a cloud scanner, they are not your auditor.

If you cannot fill the middle column, you are buying a PDF cover.

Selection factor	Question to ask on a call	Unacceptable answer
Live empanelment	Show us your current list entry and validity	'We were empanelled, the website is lagging'
Scope fit	Who, by name, has tested an app with tool-calling / RAG?	'Our generic web app checklist covers AI'
Independence	Do you also implement or resell the stack you would audit?	Silence, or 'we can do both at a discount'
Government fluency	Have you filed reports a NIC/SDC or PSU CISO accepted?	Only private-sector SaaS logos
Method on our network	How do you test without outbound from our VLAN?	We require a persistent remote bridge
Retest and ownership	Is retest of criticals priced, and who signs the letter?	Retest is a new project we will quote later

Independence is a control, not a vibe

Do not hire the implementer of the same stack as the only auditor of the same stack, unless the bid forces a named firm and you document the conflict. Buyers should not accept a report from a cousin company of the vendor without a hard look.

Do not let the auditor write your policies in the morning and certify them in the afternoon as if they had discovered them.

Do not shop for the firm that promises zero high findings. You want the firm that will find the tool-call that writes to the database, then retest the fix.

Put the engagement on paper the way a CISO will read it

Name environments (staging that mirrors air-gap rules, not a public demo). Name data rules: no production personal data in their laptops. Name the window. Name the deliverable: report, severity scheme, executive letter, retest letter.

Name confidentiality and whether the report can be shown to a department under NDA. Many bids want the report attached. If the auditor forbids sharing, you bought an unusable artefact.

Name CERT-In incident duties if their work discovers an incident that you must report. Do not discover the clock in a panic.

• Legal name on the contract equals legal name on the CERT-In list.
• Scope statement attached as a schedule, not a slogan.
• No production citizen data on auditor endpoints.
• Retest of critical and high findings included.
• A sharing clause that matches how government buyers consume reports.

What not to do while choosing

Do not publish a ranking. You do not have CERT-In’s scoring sheet, and this article will not invent one.

Do not pick only on price. A two-day generic scan of an agent platform is cheaper because it did not look.

Do not treat empanelment as optional if the bid named it. A brilliant boutique that is not on the list will not satisfy that row.

Do not confuse this with STQC product certification or GIGW website certification. Different counters.

How teams pick the wrong firm on purpose

These motives are understandable. They still produce a report you cannot defend.

Any empanelled firm is fine; the list already quality-assured them.

The list quality-assures a baseline of the firm, not the fit to your agent, your air gap, or your calendar. Empanelment is necessary where the bid says so. It is not sufficient.

We need zero findings for the bid.

Then fix findings and retest. A purchased clean page is a future incident. Buyers who know how to read reports look for method, not for emptiness.

The auditor should also fix the code; one throat to choke.

Then you have one throat and no independence. Split fix and verify, even if both happen quickly.

Government experience means they used to be a CISO.

Useful, not sufficient. Ask for the last three public-sector application reports they can describe without breaching confidentiality — objects, not gossip.

Seven days to a shortlist you can sign

Three firms is enough. Twenty firms is procrastination.

1. Day 1: write the one-sentence object, the environment constraints, the report-sharing need, the date the letter must exist.
2. Day 2: download the CERT-In list. Build a long list of currently valid firms.
3. Day 3: filter by willingness to work on-site / air-gap and by obvious conflicts.
4. Day 4: send the same scope note to three firms. Ask the table’s questions in writing.
5. Day 5: reference calls with a public-sector CISO if you can get one, without asking them to break confidentiality.
6. Day 6: compare retest pricing and calendar, not only day rates.
7. Day 7: sign the engagement with the schedule attached. Update the evidence-pack security drawer with the planned letter date.

What goes in the file — list, scope, letter, retest

Keep the dated CERT-In list extract, the engagement, the scope schedule, the report, the retest letter, and a note of what was out of scope. When a buyer asks 'were you audited', that folder is the answer.

If you are the buyer, file why you accepted this auditor — list presence, independence, scope — not 'they are famous'. Fame is not a GFR criterion.

CERT-In’s empanelled list and directions change. This guide is not an official ranking, not a substitute for the list on cert-in.org.in, and not legal or security-accreditation advice. Verify empanelment and scope on the official site the day you contract.

How to run the route without confusing the letterhead

“CERT-In Empanelled Auditors: Choosing One” is a route problem. A P5 GovTech Founder should know which legal person they are talking to — NIC, NICSI, a state IT corporation, iDEX, or a GeM buyer — and which paper that person can actually issue. Searching “CERT-In empanelled auditor” is not the same as being on a panel that can receive a work order.

The official list is on cert-in.org.in. Choose by scope, independence, government-domain fluency and calendar — not by a 'top 7' blog or a discount for a logo. Empanelment letters are not purchase orders. DPIIT recognition is not a technical score. Reserved startup seats, if a notice writes them, are local to that notice. IndiaAI compute empanelment is not NICSI application-software empanelment.

Keep a warm evidence pack: CIN, GST, DPIIT, Udyam, financials, work-completion letters, architecture one-pager, DPA draft. Renewals are lost by people who treat the panel as a trophy.

• Screenshot the live RFE paragraph you are relying on, dated.
• Match the bidding entity name across every certificate.
• Do not mix iDEX, TDF, NICSI and GeM clocks on one tracker cell.
• Record the validity end date 90 days before it dies.

Close this loop before the next CAB

Put “CERT-In Empanelled Auditors: Choosing One” on the next change-advisory or bid-opening agenda as a single line item with an owner. If it cannot earn a line item, it will not earn a control. The owner should be a P5 GovTech Founder, not “the vendor.”

Revisit the item when the model, the GeM term, the region, or the SI changes. “CERT-In empanelled auditor” is not a one-time workshop. It is a watch item. Date the last check. Unsigned watch items are souvenirs.