CERT-In Directions (Cyber Incident Reporting)

Introduction: The CERT-In Cyber Incident Reporting Directions

On 28 April 2022, the Indian Computer Emergency Response Team (CERT-In), operating under the Ministry of Electronics and Information Technology (MeitY), issued a set of Directions under sub-section (6) of Section 70B of the Information Technology Act, 2000. These Directions, formally numbered 20(3)/2022-CERT-In, fundamentally reshaped the cyber incident reporting and cyber-hygiene obligations of virtually every organisation that operates a computer system in or serving India. Unlike aspirational best-practice frameworks, the CERT-In Directions are legally binding, carry penal consequences for non-compliance, and impose some of the shortest breach-notification timelines in the world.

This guide is an auditor-grade deep-dive intended for Chief Information Security Officers (CISOs), Data Protection Officers, IT and infrastructure heads, managed service providers, data centres, cloud and VPS providers, virtual asset service providers, and the compliance and internal-audit teams that assure them. It walks through the letter and the operational intent of the Directions, the accompanying Frequently Asked Questions (FAQ) that CERT-In published on 18 May 2022, and the practical control set an assessor must verify. The aim is to help you move from a vague awareness that a six-hour reporting rule exists to a defensible, evidence-backed compliance posture that can withstand scrutiny during a CERT-In audit or a post-incident inquiry.

What are the CERT-In Directions?

CERT-In is the national nodal agency for responding to cyber security incidents, designated under Section 70B of the IT Act, 2000. That section empowers CERT-In not only to collect, analyse and disseminate information on cyber incidents, but also to issue directions and call for information from service providers, intermediaries, data centres, body corporates and any other person. The April 2022 Directions are the most consequential exercise of that power to date, because they convert a previously discretionary and often-ignored reporting regime into a mandatory, time-bound and audit-enforced obligation.

The Directions are best understood as six distinct but interlocking obligations bundled into a single instrument. First, mandatory reporting of a specified list of cyber incidents to CERT-In within six hours of noticing or being brought to notice. Second, mandatory synchronisation of all ICT system clocks to the Network Time Protocol (NTP) servers of the National Informatics Centre (NIC) or the National Physical Laboratory (NPL), or to traceable NTP sources synchronised with them. Third, mandatory retention of ICT logs for a rolling period of 180 days within Indian jurisdiction. Fourth, an obligation on data centres, virtual private server (VPS) providers, cloud service providers and virtual private network (VPN) service providers to maintain specified customer registration (Know-Your-Customer style) data for five years. Fifth, an obligation on virtual asset service providers, virtual asset exchange providers and custodian wallet providers to maintain KYC and transaction records for five years. Sixth, the appointment and registration of a point of contact (PoC) with CERT-In to interface on these matters.

The Directions came into force sixty days from issuance, that is on 27 June 2022, giving entities a short runway to operationalise them. For micro, small and medium enterprises (MSMEs) and for certain aspects, CERT-In subsequently extended timelines to 25 September 2022 through a clarification. The reporting, clock-synchronisation and PoC obligations, however, applied broadly from the outset.

Who must comply?

The scope of the Directions is deliberately broad. CERT-In cast the net over the entire connected ecosystem rather than a narrow category of critical entities. In broad terms, the reporting, clock-synchronisation, log-retention and PoC obligations apply to every service provider, intermediary, data centre, body corporate and government organisation. The five-year customer-data retention obligations apply to a narrower set of infrastructure and virtual-asset providers. The table below summarises the principal categories and which obligations bite for each.

Two points on scope deserve emphasis. First, there is no small-organisation carve-out from the core reporting and hygiene duties; a start-up with a single production server is as bound to report a ransomware event within six hours as a large bank. Second, the obligations follow the system, not merely the corporate headquarters, so foreign entities operating computer resources located in, or offering services to users in, India fall within reach.

Structure of the CERT-In Directions

The Directions are not organised into numbered control families in the manner of ISO 27001 Annex A or the NIST Cybersecurity Framework. Instead they comprise a preamble grounded in Section 70B, followed by a series of operative paragraphs, each imposing a specific duty, together with an Annexure listing the reportable incident types. For assessment purposes it is useful to reframe these operative paragraphs into logical control domains. The table below presents that reframing, mapping each domain to the underlying Direction and to the principal obligation it creates.

These eight domains form the spine of the master assessment checklist that follows. An assessor should treat each as a discrete area requiring its own evidence, control owner and test procedure.

Master assessment checklist

This is the operational heart of the guide. For each control domain we set out the specific requirements an auditor must verify and the typical evidence that demonstrates conformance. Every domain in the structure above is covered; none is skipped. Where a requirement applies only to a subset of entities (for example the five-year KYC retention for infrastructure providers) that is called out. Assessors should record for each line item a status of Compliant, Partially Compliant, Non-Compliant or Not Applicable, with a supporting evidence reference.

D1 - Incident reporting within six hours

D2 - Reportable incident taxonomy (Annexure)

The Annexure to the Directions lists the categories of incidents that are mandatorily reportable. This list is significantly broader than a traditional 'material data breach' threshold; it includes many events that other regimes would treat as informational. The assessor must confirm that the organisation's incident classification logic maps cleanly to every Annexure category so that reportable events are not misclassified as internal-only.

D3 - Clock synchronisation to NIC/NPL NTP

D4 - Log retention within Indian jurisdiction (180 days)

D5 - Point of contact and cooperation with CERT-In

D6 - Data centre / VPS / cloud / VPN customer data retention (5 years)

This domain applies specifically to data centres, VPS providers, cloud service providers and VPN service providers. Assessors working with such entities must verify accurate, validated customer records are captured and retained for five years, even after a customer relationship ends.

D7 - Virtual asset KYC and transaction records (5 years)

This domain applies to virtual asset service providers, virtual asset exchange providers and custodian wallet providers. It aligns closely with financial KYC/AML expectations.

D8 - Ongoing cooperation, safeguards and directions

Scoping the assessment

Scoping a CERT-In Directions assessment is about determining which of the eight domains apply, and to which systems and business units. Because the core reporting, clock, log and PoC duties apply universally, the scoping question is rarely 'do the Directions apply?' but rather 'which additional obligations apply and where do the in-scope ICT systems sit?'.

• Establish the legal footprint: identify every computer resource operated by, or on behalf of, the entity that is located in India or serves Indian users, since the Directions reach both.
• Classify the entity type: general body corporate versus data centre / VPS / cloud / VPN provider versus virtual asset service provider, to determine whether D6 or D7 apply.
• Inventory all ICT systems that generate security-relevant logs and require clock synchronisation, including cloud workloads, SaaS-adjacent infrastructure, OT/ICS and IoT where present.
• Map data flows and storage locations to confirm log data and customer records can be retained within Indian jurisdiction and produced on order.
• Identify outsourced and managed services (MSSPs, hosting, cloud) and confirm contractual flow-down of reporting, logging and cooperation duties.
• Define what is out of scope with documented justification (for example, personal devices not connected to corporate systems), avoiding under-scoping that would leave reportable systems uncovered.
• Confirm ownership: for shared-responsibility cloud models, document which party (customer or provider) is responsible for each control.

Implementation approach

A structured, phased implementation converts the Directions from a compliance shock into an embedded operating capability. The following four phases move an organisation from unaware to audit-ready, each with concrete activities and deliverables.

Phase 1 - Discover and baseline (Weeks 1-3)

• Activities: confirm entity classification and applicable domains; inventory ICT systems, log sources and time sources; assess current reporting readiness against the six-hour standard; identify data-residency gaps for logs and customer records.
• Deliverables: applicability determination memo; ICT and log-source inventory; NTP/time-source map; gap-assessment report against all eight domains; risk-ranked remediation backlog.

Phase 2 - Foundational controls (Weeks 3-8)

• Activities: designate and register the PoC and alternate with CERT-In; configure NTP synchronisation to NIC/NPL across the estate; enable and centralise logging; establish 180-day retention within Indian jurisdiction; draft the incident-reporting SOP with the six-hour trigger.
• Deliverables: CERT-In PoC registration acknowledgement; NTP architecture implemented and monitored; centralised log store with retention configured; approved incident-reporting SOP and Annexure-mapped classification taxonomy.

Phase 3 - Operationalise and rehearse (Weeks 8-14)

• Activities: integrate detection with the reporting workflow; define out-of-hours escalation and reporting authority; run tabletop and live-fire drills that exercise the six-hour clock; implement five-year customer/KYC and transaction retention where D6/D7 apply; establish the CERT-In advisory intake process.
• Deliverables: reporting playbooks per incident type; completed tabletop reports with timing metrics; validated retention archives; advisory register and action tracker.

Phase 4 - Assure and sustain (Ongoing)

• Activities: conduct internal audits against the master checklist; track KPIs; review and re-register PoC changes; maintain evidence continuously; brief the board on obligations and penal exposure; refresh training.
• Deliverables: periodic internal audit reports; KPI dashboard; refreshed evidence pack; management review minutes; sustained readiness state.

Maturity and capability model

Although the Directions impose a binary legal duty, a maturity lens is useful for tracking the journey and prioritising investment. The following five-level model helps an assessor characterise the current state of each domain and set improvement targets. Note that Levels 1 and 2 represent legal non-compliance; Level 3 is the minimum defensible state.

Assessment and audit approach

A rigorous assessment follows a repeatable sequence that combines documentation review, technical inspection and interview, and culminates in an evidenced findings report.

1. Confirm applicability and scope: determine entity classification and which of the eight domains apply, and enumerate in-scope ICT systems and business units.
2. Review governance artefacts: obtain the incident-reporting SOP, log-retention policy, NTP architecture, PoC registration and (where applicable) KYC/retention policies.
3. Test D1-D2 reporting: walk through the reporting workflow, review past incident records and CERT-In acknowledgements, and verify Annexure-to-classification mapping.
4. Inspect D3 clock synchronisation: sample device configurations and NTP query output to confirm traceability to NIC/NPL and monitor for drift.
5. Inspect D4 logging: verify log sources, retention duration, Indian-jurisdiction storage, integrity controls and producibility.
6. Verify D5 PoC and cooperation: confirm registration currency, alternate coverage and past cooperation with CERT-In requests.
7. Verify D6/D7 retention where applicable: sample customer/KYC and transaction records for completeness, validation and five-year retention.
8. Test D8 ongoing cooperation: review the advisory register and evidence of directed actions being implemented.
9. Perform an operational drill: run or review a tabletop exercise measuring the elapsed time from simulated detection to CERT-In report, targeting well under six hours.
10. Consolidate findings: rate each line item Compliant / Partial / Non-Compliant / Not Applicable, attach evidence references, and produce a prioritised remediation plan with owners and dates.

Evidence request list

Assemble the following categorised evidence in advance of any assessment or CERT-In inquiry. A well-organised evidence pack dramatically shortens both audits and post-incident response.

• Governance and policy: incident-reporting SOP with six-hour trigger; log-retention policy; NTP/time-synchronisation policy; CERT-In obligation register; delegation-of-authority for out-of-hours reporting.
• Point of contact: PoC and alternate appointment memos; CERT-In registration submission and acknowledgement; change records for PoC updates.
• Incident reporting: incident register with detection and reporting timestamps; copies of submitted CERT-In reports; CERT-In acknowledgement emails / ticket numbers; Annexure-mapped classification taxonomy.
• Detection and monitoring: SIEM configuration; alerting rules; on-call rota; mean-time-to-detect and mean-time-to-report metrics.
• Clock synchronisation: NTP architecture diagram; device configuration samples; ntpq/chronyc output; time-drift monitoring evidence.
• Log management: log-source inventory; retention configuration; data-residency attestation; log-integrity controls (WORM/hashing); log-export/producibility procedure and sample export; backup and restore-test evidence for log data.
• Customer / KYC retention (D6/D7 entities): onboarding and validation SOP; sample customer/KYC records with mandated fields; IP allocation register; transaction ledgers; five-year retention archive including terminated customers.
• Cooperation and advisories: CERT-In advisory register with closure status; correspondence archive; evidence of directed actions implemented.
• Assurance: internal audit reports; tabletop exercise reports with timing metrics; management review minutes; training and awareness records; board briefing on penal exposure.

Roles and responsibilities

KPIs to track

• Mean time to detect (MTTD) a reportable incident, trended over time.
• Mean time to report to CERT-In from detection, with the six-hour threshold as a hard ceiling.
• Percentage of reportable incidents reported within six hours (target 100%).
• Percentage of ICT systems synchronised to NIC/NPL NTP with zero unexplained time drift.
• Percentage of in-scope log sources with 180-day retention within Indian jurisdiction (target 100%).
• Log-integrity assurance rate (proportion of log stores with tamper-protection verified).
• PoC registration currency (days since last verification/update; alternate coverage confirmed).
• Number and closure rate of CERT-In advisories actioned within target timeframe.
• For D6/D7 entities: percentage of customer/KYC records validated and retained for the full five years.
• Tabletop/drill cadence and the elapsed detection-to-report time achieved in each exercise.
• Number of overdue remediation items from the last internal audit.

Readiness checklist

• Entity classification and applicable domains formally determined and documented.
• CERT-In Point of Contact and alternate appointed and registered with CERT-In; acknowledgement retained.
• Incident-reporting SOP with a six-hour trigger approved, published and rehearsed.
• Incident classification taxonomy mapped to every category in the CERT-In Annexure.
• Detection and monitoring capability sufficient to make six-hour reporting realistic and measured.
• Out-of-hours escalation and reporting authority defined so no report stalls awaiting sign-off.
• All ICT system clocks synchronised to NIC/NPL NTP with drift monitoring in place.
• Logging enabled across all ICT systems and centralised.
• Logs retained for 180 days within Indian jurisdiction with integrity protection and producibility.
• Backup and restore of log data validated to protect the 180-day window.
• For D6/D7 entities: validated customer/KYC and transaction records captured and retained for five years, including terminated customers.
• CERT-In advisory intake and action-tracking process operating.
• Evidence pack maintained continuously and internal audit performed against the master checklist.
• Board briefed on obligations and Section 70B(7) penal exposure.

Common gaps

• No registered PoC, or a PoC whose details have gone stale after a personnel change, leaving CERT-In unable to reach the organisation.
• Reporting procedures that quote the six-hour rule but lack the detection capability to notice an incident within a timeframe that makes six hours achievable.
• Treating the Directions as a personal-data breach obligation and under-scoping non-data events like DDoS, defacement and social-media compromise that are nonetheless reportable.
• Logs retained for less than 180 days, or stored exclusively outside Indian jurisdiction with no producible copy in India.
• Clock synchronisation configured to arbitrary public NTP pools with no traceability to NIC/NPL, undermining forensic timestamp correlation.
• Log integrity unprotected, so logs could be tampered with and would not withstand scrutiny.
• Out-of-hours reporting blocked by an approval bottleneck, causing the six-hour clock to expire before sign-off.
• For infrastructure and virtual-asset providers, self-declared (unvalidated) customer data, or retention that purges records on customer exit rather than holding them for five years.
• No rehearsal: the first time the reporting workflow is exercised is during a real incident, and timings blow past six hours.
• Advisory fatigue: CERT-In advisories received but not tracked to closure, leaving directed safeguards unimplemented.

CERT-In Directions mapped to other frameworks

The CERT-In Directions do not exist in isolation. Most obligations can be satisfied by extending controls an organisation may already operate under ISO 27001, the NIST Cybersecurity Framework, the Digital Personal Data Protection Act 2023 and, for regulated entities, RBI or SEBI cyber frameworks. The table below maps each CERT-In domain to the nearest analogue in these frameworks to help teams reuse existing controls and evidence.

Frequently asked questions

Need help with CERT-In Directions?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.