How to Choose a CERT-In Empanelled Security Auditor
CERT-In empanelment narrows the candidate list, but it does not pick a winner. Here is what to actually evaluate when shortlisting auditors for a regulated engagement.
On this page (12)
- What CERT-In empanelment actually verifies
- Eight questions worth asking
- 1. How long have you been empanelled, continuously?
- 2. What is your team retention rate?
- 3. Walk me through your methodology end to end.
- 4. Show me a sample report — anonymised, recent, in our industry.
- 5. What does your retesting process look like, and is it included?
- 6. How do you handle scope discovery?
- 7. Who actually does the testing?
- 8. Can I speak to a reference client in my regulator's footprint?
- Red flags
- What this looks like at Security Brigade
CERT-In maintains a list of empanelled information security auditing organisations. For regulated workloads — government, BFSI, critical infrastructure — empanelment is functionally a prerequisite. But more than 150 firms hold the certification, and they vary enormously in capability. Empanelment is a floor, not a quality signal.
This post is the rubric we wish more procurement teams used.
What CERT-In empanelment actually verifies
The empanelment process certifies that a firm has documented processes, qualified personnel, technical capability across application and network testing, and reporting standards that meet CERT-In's expectations. Renewals are periodic. Empanelment can be revoked.
What it does not verify: depth of expertise in your specific industry, retention of senior staff, quality of remediation guidance, willingness to push back when scope discovery surfaces something the procurement team didn't anticipate. Those qualities you have to evaluate yourself.
Eight questions worth asking
1. How long have you been empanelled, continuously?
Empanelment lapses happen. A firm empanelled since 2008 (which we are) has been audited multiple times across multiple panel cycles. A firm empanelled in the most recent cycle is still building its cumulative track record.
2. What is your team retention rate?
Penetration testing is delivered by people, and those people accumulate institutional pattern-matching. A firm where senior consultants have worked together for five years will catch things a freshly assembled team won't. Ask for tenure ranges of the actual L2/L3 reviewers.
3. Walk me through your methodology end to end.
Anyone running a real engagement should have a documented methodology that goes beyond "we'll scan and write a report." Ask about scoping, reconnaissance, manual versus automated testing, business-logic coverage, exploitability validation, and quality review layers.
4. Show me a sample report — anonymised, recent, in our industry.
The sample report tells you everything. Look at the depth of finding descriptions, the clarity of remediation guidance, the presence of exploit reproduction steps, and the structure of the executive summary. If the report is largely scanner output, you'll be paying for that.
5. What does your retesting process look like, and is it included?
The right answer is "retesting is included for all findings within a defined window." If retesting is extra, you've discovered a hidden cost line.
6. How do you handle scope discovery?
A test of "the customer portal" usually surfaces a third more attack surface than was originally scoped — APIs, admin paths, integration endpoints. The right vendor flags this in the kickoff and either renegotiates scope or proceeds with documented gaps. The wrong vendor silently misses things.
7. Who actually does the testing?
Some firms route the engagement through senior staff for the kickoff and reporting, but the testing itself is done by junior consultants with limited supervision. Ask explicitly: who tests, who reviews, who signs off, and what are their certifications.
8. Can I speak to a reference client in my regulator's footprint?
Procurement teams ask this too rarely. A CERT-In auditor with strong BFSI references will provide them. One without will deflect.
Red flags
- The vendor cannot produce a sample report.
- Retesting is unbundled.
- Pricing is dramatically below market without an explanation rooted in scope.
- The scoping conversation is rushed.
- Reporting timelines are vague.
- The team handling your engagement doesn't have OSCP, CRTP, or equivalent credentials.
What this looks like at Security Brigade
We've held CERT-In empanelment continuously since 2008. Engagements run through our Lemon platform with documented L1 / L2 / L3 review on every finding. Reports include exploit reproduction steps, business-impact framing, and remediation code. Retesting is included. We're happy to walk procurement teams through our methodology before they commit — request a scoping call and we'll set it up.
Written by
Security Brigade Editorial Team
Continue reading
All articles →RBI Cybersecurity Framework: A 2026 Compliance Guide
What the RBI Cybersecurity Framework actually requires of banks, NBFCs, and payment system providers in 2026 — translated from circular language into an action plan.
OWASP Top 10 Explained for Business Leaders
A non-technical walk through the OWASP Top 10 — the ten classes of web application risk that account for the bulk of breaches we see in real engagements — and what each one actually costs your business.
VAPT vs Penetration Testing: Which Do You Actually Need?
The terms get used interchangeably in Indian procurement RFPs, but they describe different things. Here is what the distinction means for scoping, cost, and the kind of report you walk away with.