CERT-In Audit, Explained

CERT-In audits have moved from a government and CII concern to a routine procurement item across Indian BFSI, listed companies, pre-IPO firms, and the SaaS vendors supplying them. The scope is wider than most teams expect, the empanelled-auditor model is misunderstood as often as not, and the 2022 directions keep extending the designated-entity list. This document is a plain-English explainer of what a CERT-In audit actually is, who needs one, what the empanelled auditor does, and how to prepare for the engagement.

What CERT-In Is

CERT-In is the Indian Computer Emergency Response Team, operating under the Ministry of Electronics and Information Technology (MeitY). It is the national CERT with statutory authority under the Information Technology Act, 2000, and the Information Technology (The Indian Computer Emergency Response Team and Manner of Performing Functions and Duties) Rules, 2013. CERT-In issues advisories, coordinates incident response, maintains the empanelled-auditor list, and — since April 2022 — issues directions that bind designated service providers and data-handling entities operating in India.

The confusion many teams have is between CERT-In as a national CERT (issuing advisories and coordinating response) and CERT-In as a regulator (issuing binding directions and maintaining the empanelled-auditor list). Both functions sit in the same organisation but produce different compliance obligations. The audit model falls under the regulator function.

The Empanelled Auditor Model

CERT-In maintains a panel of audit firms authorised to conduct cyber security audits that satisfy sector-specific regulatory requirements and designated-entity obligations. The panel is updated periodically; the current roster is published on CERT-In's website. Empanelment is granted to the audit firm (not to individual auditors), and the empanelled firm takes responsibility for the audit opinion delivered to the client.

A CERT-In audit is conducted by an empanelled audit firm against a scope defined by the client's applicable regulatory requirements. The audit output is signed by the empanelled auditor and is accepted by sector-specific regulators (RBI, SEBI, IRDAI, PFRDA) as evidence of the required cyber security audit. The empanelment is what gives the audit regulatory weight; the technical work can be shared between the empanelled firm and specialist pen testing platforms, but the audit opinion must come from the empanelled firm.

This split model — empanelled auditor for the audit opinion, specialist platform for the technical pen testing evidence — is now standard practice for larger audit scopes. The empanelled firm reviews, validates, and signs; the platform provides the technical scan evidence, exploitation validation, and remediation lifecycle data that the empanelled auditor would otherwise have to produce manually.

Who Needs a CERT-In Audit

The explicit CERT-In audit requirement applies to several categories. Government organisations and ministries use CERT-In empanelled auditors as the default audit path for cyber security assessments. Critical Information Infrastructure (CII) entities notified under Section 70 of the IT Act are required to undergo CERT-In audits. BFSI entities under RBI, SEBI, and IRDAI frameworks reference CERT-In empanelled auditor requirements for their annual VAPT and system audit obligations.

Beyond the explicit requirement, several categories now routinely obtain CERT-In audits as de-facto compliance. Listed companies increasingly obtain CERT-In audits as part of SEBI continuous disclosure and as evidence of cyber security maturity for institutional investors. Pre-IPO firms obtain CERT-In audits as part of pre-listing due diligence — the audit evidence is a routine item in investor-side cyber review. SaaS vendors supplying to Indian government, BFSI, or large enterprises obtain CERT-In audits to clear vendor procurement.

The 2022 directions widen the scope further. Service providers, intermediaries, data centres, body corporates, and government organisations in India are all designated to varying degrees under the directions, with specific obligations around incident reporting, log retention, and VAPT practice. The practical effect is that most medium-to-large organisations operating in India now have at least a touch-point with CERT-In audit expectations even without being explicitly in-scope.

The 2022 Directions

CERT-In's April 2022 directions (issued under Section 70B(6) of the IT Act) are the most significant extension of CERT-In authority in a decade. The directions impose specific obligations on service providers, intermediaries, data centres, body corporates, and government organisations operating in India. The four most material obligations:

First, incident reporting within 6 hours. Designated entities must report specified cyber security incidents to CERT-In within 6 hours of noticing. The incident categories are broad — ransomware, data breach, DDoS, phishing campaigns targeting the entity's systems, unauthorised access to critical systems. The 6-hour clock has been the most operationally painful part of compliance; most organisations have had to build dedicated incident-detection and escalation workflows to hit it.

Second, 180-day log retention. ICT system logs must be retained for 180 days within the Indian jurisdiction. Logs transferred offshore for storage or analysis need a mirror maintained in India. The retention obligation is independent of the incident; it applies continuously.

Third, time synchronisation. ICT systems must synchronise to NTP servers maintained by NIC (National Informatics Centre) or NPL (National Physical Laboratory). The timestamp integrity requirement is intended to support incident reconstruction and forensic analysis.

Fourth, KYC and transaction record retention. Virtual asset service providers (crypto exchanges, custodian wallet providers, virtual private network service providers for consumer-facing VPN) must retain KYC data and transaction records for 5 years. The 5-year retention is in addition to the 180-day log retention and applies specifically to this sector.

Enforcement has been uneven since the directions came into force, but CERT-In has signalled increasing intent to action non-compliance. Teams designated under the directions should treat these as binding obligations rather than guidance.

What a CERT-In Audit Actually Covers

CERT-In audit scope is defined by the client's applicable regulatory requirements and the empanelled auditor's methodology. The typical scope includes vulnerability assessment and penetration testing (VAPT) of public-facing applications, internal systems processing sensitive data, APIs, cloud workloads, mobile applications, and network infrastructure.

Secure code review is usually part of the scope — static analysis of application source code, library vulnerability scanning, and configuration review. For organisations under RBI, SEBI, or IRDAI oversight, segment-specific scope items are added (payment gateway security for payment aggregators, broker-trading system security for SEBI entities, policy-system security for insurance companies).

The audit methodology typically references OWASP (Top 10, API Top 10, MASVS for mobile), NIST (SP 800-115 for pen testing methodology), ISO 27001:2022 Annex A, and sector-specific guidance (RBI Master Direction, SEBI cyber security framework, IRDAI cyber security guidelines). The empanelled auditor's methodology document is reviewed as part of the client-side acceptance.

The Audit Deliverable

A CERT-In audit produces a signed report containing scope statement, methodology summary, vulnerability catalogue with risk rating, exploitation evidence, remediation guidance, and the empanelled auditor's opinion. Reports are typically delivered under NDA given the sensitivity of the findings; redacted executive summaries can be shared with regulators, boards, and procurement counterparties.

Post-report, a remediation and retest cycle follows. The empanelled auditor validates fixes and issues a closure report once all applicable findings are remediated to the auditor's satisfaction. The retest cycle is where consulting-only audit engagements run into friction; empanelled firms billing per retest cycle produce incentive misalignment with the client's remediation timeline. Platform-backed audits where retest is part of the continuous evidence stream avoid this.

Preparing for a CERT-In Audit

Teams anticipating a CERT-In audit should prepare in four areas. First, scope definition. Map the systems that will be in-scope — public-facing applications, internal sensitive-data systems, cloud workloads, APIs, mobile apps. Define the trust boundary and document it. The empanelled auditor's scoping conversation goes faster when the client arrives with a defensible scope.

Second, pre-audit pen testing. A pre-audit pen testing engagement using the same methodology the empanelled auditor will use surfaces the findings that would otherwise appear in the audit report. The pre-audit engagement is a cost-management exercise — fixing findings before the audit means they do not become audit observations, which shortens the audit cycle and reduces the retest-cycle count.

Third, continuous evidence. Between audit cycles, maintain continuous pen testing evidence. The empanelled auditor review cycle is faster when the client arrives with recent pen testing output rather than a 12-month-old engagement report. Regulators (RBI, SEBI, IRDAI) increasingly ask for between-audit evidence, so the continuous programme produces compliance value independently of the formal audit.

Fourth, deployment architecture. For CII, government, defence, and highly regulated BFSI environments, the audit scope may require on-premise or air-gapped pen testing. Confirm the empanelled auditor and any supporting platforms support the deployment architecture the audit requires — SaaS platforms that cannot operate air-gapped produce late-stage audit friction.

Platform-Backed CERT-In Audits

The split-model audit — empanelled firm for opinion, platform for evidence — is the operating pattern most mid-sized and larger CERT-In audit scopes now use. The economics work for both sides: the empanelled firm's senior pentester time concentrates on validation and opinion rather than mechanical VAPT, and the client avoids paying consultant rates for scan-and-report work that platforms produce faster and cheaper.

Platforms like TigerStrike that produce auditor-ready pen testing evidence integrate into empanelled firm workflows via auditor collaboration portals, standardised report formats, and continuous evidence streams. The empanelled firm reviews platform output, adds judgement and advisory commentary, and signs the final audit opinion. The result is a CERT-In audit deliverable that satisfies regulatory expectations while compressing the audit cycle time substantially.

For teams planning their first CERT-In audit, the practical recommendation is to engage both an empanelled firm and a platform early. The empanelled firm advises on scope and methodology; the platform runs continuous pen testing to produce the evidence base; the audit cycle begins with both already engaged rather than scrambling for either when a regulator or counterparty requests the audit.