CERT-In Empanelled Audit: The Complete Guide (2026)

A CERT-In empanelled audit is an information-security audit performed by an organisation officially empanelled by CERT-In — the Indian Computer Emergency Response Team, the national nodal agency for cyber security under the Ministry of Electronics and IT. Empanelment is India's benchmark of auditor competence: the RBI, SEBI and IRDAI, government tenders, and the CERT-In Directions of 2022 increasingly require security testing by an empanelled auditor. This guide covers who needs one, what it covers, the 2022 Directions, the report format, timelines and how to verify empanelment.

It is written for the person accountable for passing the audit — a CISO, IT head, compliance officer or founder who has been asked by a bank, a regulator, a government tender or an enterprise customer to produce a CERT-In empanelled audit report. We keep it concrete: what the credential really means, exactly who is on the hook, what auditors test, and how to avoid the failures that send organisations back for a re-audit.

What is CERT-In and what does empanelment mean?

CERT-In (the Indian Computer Emergency Response Team) is the national agency for responding to cyber-security incidents, operating under Section 70B of the Information Technology Act, 2000. Among its statutory functions, it empanels information-security auditing organisations: firms that pass CERT-In's technical assessment are added to an official list and authorised to conduct security audits for government bodies and critical sectors. Empanelment is therefore not a marketing badge — it is a government vetting of an auditor's technical competence, valid for a defined period, and published on the CERT-In website.

What is a CERT-In empanelled audit?

A CERT-In empanelled audit is a structured security assessment — typically VAPT plus configuration and process review — carried out by an empanelled auditor and delivered in CERT-In's expected report format, with the auditor's attestation. In practice it is the report a regulator, tender authority or enterprise customer will accept as independent proof that your systems were tested competently and that findings were remediated. The empanelled entity's name and attestation on the report are what give it weight.

Who needs a CERT-In empanelled audit?

The requirement usually arrives through a regulator, a contract, or a tender rather than from CERT-In directly. The common drivers:

What are the CERT-In Directions of 2022?

Issued under Section 70B(6) and in force since 28 June 2022, these directions set baseline obligations that empanelled audits routinely check for. The headline requirements:

• Report any of 20 specified classes of cyber incident to CERT-In within 6 hours of noticing them.
• Enable and securely maintain ICT system logs for a rolling 180 days, stored within India.
• Synchronise all system clocks to the NTP servers of NIC or NPL (or traceable equivalents).
• Data centres, VPS, cloud and VPN providers must retain subscriber / KYC records for at least 5 years.
• Virtual-asset and exchange providers must maintain KYC and transaction records.

What does a CERT-In empanelled audit cover?

Scope is agreed up front, but a typical empanelled audit spans:

• Network and infrastructure VAPT — external (internet-facing) and internal.
• Web and API application security testing (OWASP Top 10 / API Top 10).
• Mobile application testing where in scope (OWASP MASVS).
• Configuration and hardening review against CIS Benchmarks.
• Cloud security review (AWS / Azure / GCP posture and IAM).
• Source code review where the engagement calls for it.
• Incident-readiness and compliance with the 2022 Directions (logging, time sync, 6-hour reporting).
• Policy and process review — the governance around the technology.

The testing itself follows the same discipline as any professional engagement — see our penetration testing and VAPT guide for the underlying methodology and how findings are scored.

How does a CERT-In empanelled audit work?

A well-run empanelled audit moves through clear stages so the final report holds up under regulator inspection:

1. Scoping and empanelment confirmation — agree the asset list, test windows and report format; confirm the empanelled entity that will attest the report.
2. Information gathering and architecture review — understand the environment, data flows and trust boundaries.
3. Vulnerability assessment — authenticated and unauthenticated scanning across the agreed scope.
4. Manual penetration testing — human-led exploitation to prove real impact, the part that distinguishes an audit from a scan.
5. Configuration and compliance review — check hardening and the 2022 Directions controls against CERT-In / ISO / CIS baselines.
6. Reporting in CERT-In format — findings rated by CVSS with evidence, remediation and compliance mapping.
7. Remediation support and closure retest — verify that fixes work; regulators check closure, not just the first report.
8. Auditor attestation — the empanelled entity signs the report and, where applicable, issues a safe-to-host certificate.

What does the audit report look like?

The deliverable a regulator or customer will accept should include:

• Executive summary and overall risk posture in business language.
• Scope and methodology, naming the standards applied.
• Detailed findings — each with CVSS score, CWE, evidence and specific remediation.
• Compliance mapping to CERT-In expectations and any relevant framework (ISO 27001, PCI-DSS, RBI/SEBI).
• Closure / retest status confirming remediation.
• A signed attestation from the empanelled auditor.

CERT-In vs ISO 27001 vs SOC 2 — when do you need which?

These are often confused because organisations end up needing more than one. They answer different questions:

For a detailed comparison of the two most-confused options, read CERT-In empanelled vs ISO 27001. Many BFSI and SaaS organisations end up maintaining all three, because they serve regulators, enterprise buyers and global customers at once.

How long does a CERT-In audit take, and what drives cost?

As with any security engagement, effort is driven by scope, not a fixed licence. The main drivers are the number of applications, hosts and cloud environments; the depth of source-code review; whether a closure retest is included; and the compliance mapping required. A typical mid-sized engagement runs about one week of scoping, one to three weeks of testing, one week of reporting, and a short retest window — but a large BFSI estate can run considerably longer.

How do you verify a provider's CERT-In empanelment?

Do not take a logo on a website at face value. Empanelment is public and time-bound:

Common reasons organisations fail a CERT-In audit

• Unpatched internet-facing services and known CVEs left open.
• No defined process to report a qualifying incident within 6 hours.
• Logs not retained for 180 days, or stored outside India.
• Weak authentication and missing MFA on admin and remote access.
• Exposed admin panels, default credentials and management interfaces.
• System clocks not synchronised to NIC / NPL time sources.
• Known findings from a prior test never remediated — closure is checked.