A CERT-In empanelment is a threshold, not a complete buying decision. It confirms that an auditing organisation appears on the current official panel; it does not tell you whether the assigned team has tested your platform, whether the scope matches your regulator, or whether the report will survive remediation and review. Use the official list to verify eligibility, then compare delivery evidence with the scorecard below.
Start with the audit outcome, not the provider list
Define who will consume the report: a regulator, bank, customer, certification body, tender committee or internal risk owner. Then identify the exact scope, reporting format, submission date and closure artifact they expect. A broad infrastructure VAPT, a web application security assessment, a source-code review and a regulatory system audit require different teams even when the same organisation can contract all four.
| Criterion | Weight | What good evidence looks like |
|---|---|---|
| Current official status | Pass/fail | Provider is present on the current official empanelment page |
| Scope expertise | 20% | Similar technologies, asset types and test depth in the delivery plan |
| Regulatory fit | 20% | Deliverables mapped to the named regulator or relying party |
| Technical evidence | 15% | Reproducible findings, validation, severity rationale and affected assets |
| Independence and QA | 15% | Tester-reviewer separation, conflict handling and sign-off workflow |
| Closure support | 15% | Defined remediation review, retest and final closure artifact |
| Data governance | 10% | Evidence location, access, retention, deletion and subcontractor controls |
| Delivery certainty | 5% | Named team, milestones, dependencies and escalation path |
CERT-In auditor selection scorecard
What empanelment proves — and what it does not
- The organisation is listed by CERT-In at the time of verification
- The provider can be considered for work that explicitly requires an empanelled auditor
- The legal entity in the proposal matches the entity on the official list
- The final sign-off can follow the provider's approved audit governance
- The assigned team has relevant technology and sector experience
- The proposed depth, tester-days and deliverables match your scope
- The report format meets the relying regulator's current expectation
- Retest, closure, evidence handling and deadlines are contractually clear
The six documents to request
- A proposal that maps every in-scope asset, environment, role, location and exclusion to a testing activity.
- An anonymised sample report for the same type of assessment, not an unrelated policy audit or scanner export.
- A delivery-team matrix naming roles, relevant qualifications, reviewer responsibility and availability during your window.
- Rules of engagement with authorization, test windows, prohibited actions, emergency contacts and stop conditions.
- An evidence-handling statement covering collection, encryption, storage location, access, retention, deletion and breach notification.
- A closure plan stating remediation-support hours, retest eligibility, retest deadline and the final report or letter produced after fixes.
Match the auditor to the actual requirement
| Requirement | Capability to verify | Useful next page |
|---|---|---|
| Application or infrastructure VAPT | Manual validation, exploit evidence and regulator-format closure | VAPT services |
| Regulatory cyber audit | Control interpretation, sampling, evidence traceability and report governance | CERT-In empanelled audit |
| Web application assessment | Role and tenant testing, business logic, API and authentication depth | Web application security |
| Source-code review | Language expertise, taint analysis, authz review and developer-ready fixes | Source code review |
| Cloud assessment | Provider-specific IAM, network, logging, encryption and data-residency review | Cloud security |
Use the detailed CERT-In empanelment process to understand how the panel works, and the CERT-In empanelled audit guide to structure the engagement. For a proposal, compare the CERT-In audit scope and VAPT deliverables against the requirement you received.
Questions to ask in the technical evaluation
- Which version and date of the regulator or customer requirement did you use to design this scope?
- Which findings will be manually validated, and when is exploitation unsafe or unnecessary?
- How do you preserve auditor independence when your team also helps remediate a control?
- Who performs technical quality review and who is authorized to sign the final deliverable?
- What evidence will be redacted in the management report but retained in the technical annex?
- How will scope changes, inaccessible assets and client dependencies appear in the final opinion?
- What exactly is issued after remediation: an updated report, retest report, closure letter or all three?
Common procurement mistakes
- Selecting on empanelment alone and discovering later that the delivery team lacks the platform expertise.
- Sending different scopes to different bidders, then comparing prices as though the offers cover the same work.
- Leaving the regulator, report format or submission deadline out of the request for proposal.
- Assuming remediation advice, retesting and closure documentation are included without written terms.
- Contracting the brand presented in the pitch without confirming the legal entity and team that will perform and sign the work.
Start with the relying regulator, required evidence, asset inventory and deadline. The audit team can turn those inputs into a comparable scope with explicit testing, reporting and closure terms.