CERT-In's six-hour clock meets DPDP: one intake process, two notification deadlines

Six hours. That is what India gives you — not six hours to understand an incident, not six hours to confirm scope, but six hours from the moment someone notices something or is told about it, to the moment CERT-In has a report in hand.

That obligation has been live since 27 June 2022 and has not been amended since. What has changed is what now sits behind it. The Digital Personal Data Protection Rules, notified in November 2025, attach a second notification duty to the same incident — one running to the Data Protection Board and to every affected individual. Those provisions commence in May 2027.

So you have roughly eight months to build a single intake process that starts both clocks from one trigger. Most organisations are running this as two projects, owned by two teams, working from two different definitions of what counts as an incident.

What the directions actually require

The instrument is Directions No. 20(3)/2022-CERT-In, dated 28 April 2022, issued under sub-section (6) of section 70B of the Information Technology Act, 2000. The text states it becomes effective 60 days after issue. That lands on 27 June 2022.

Five obligations matter operationally:

• Six-hour reporting. Incidents listed in Annexure I must be reported within 6 hours of noticing such incidents or being brought to notice about such incidents. The channels named in the text are email to incident@cert-in.org.in, phone 1800-11-4949, and fax 1800-11-6969.
• Twenty categories. Annexure I runs from i to xx. It doubles the ten types in the 2013 CERT-In Rules. The additions are the modern ones: attacks on IoT devices, incidents affecting digital payment systems, malicious and fake mobile apps, unauthorised access to social media accounts, and attacks on cloud infrastructure. Category xix covers big data, blockchain, virtual assets, robotics, additive manufacturing and drones. Category xx covers artificial intelligence and machine learning systems.
• Logs for 180 days. All ICT system logs enabled and maintained securely for a rolling 180 days, within the Indian jurisdiction, produced to CERT-In on request or alongside an incident report.
• Clock synchronisation. ICT system clocks synchronised to the NTP servers of the National Informatics Centre or the National Physical Laboratory, or to servers traceable to them. Estates spanning multiple geographies may use another accurate standard source, provided it does not deviate from NIC and NPL.
• Subscriber records for five years. Data centres, VPS providers, cloud service providers and VPN service providers must register validated subscriber names, hire periods, allotted IPs, registration email and IP with timestamp, purpose of hire, validated address and contact numbers, and ownership pattern — held for five years after any cancellation or withdrawal of registration. Virtual asset service providers, exchanges and custodian wallet providers keep KYC and reconstructable transaction records for five years.

You must also designate a Point of Contact and send the Annexure II details to info@cert-in.org.in. CERT-In addresses all compliance correspondence to that named person. If yours left the company in 2023, deal with that before you read any further.

Non-compliance may attract punitive action under section 70B(7): imprisonment up to one year, a fine up to one lakh rupees, or both. CERT-In's own FAQ tempers this, saying the power will be exercised reasonably and on occasions where the non-compliance is deliberate.

What you file at hour four

Here is the part almost nobody gets right, and it is answered plainly in CERT-In's May 2022 FAQ.

Question 30 asks what happens if the information required by the incident reporting form is not available inside six hours. The answer is that entities may provide information to the extent available at the time of reporting, and that additional information may be reported later within reasonable time.

The six-hour clock is not a deadline for understanding the incident. It is a deadline for telling CERT-In that one is under way.

The reporting form itself reinforces this. Its notes state that it is not mandatory to fill in or sign the form, and that incidents may be reported by providing relevant information in the communication itself or in any other readable form. The section headed Basic Information of Affected System carries an instruction to provide information that is readily available.

So at hour four, with triage half finished, you send prose. Identify the reporting entity and the affected entity. Pick the closest Annexure I category and name it. Give the domain or URL, the IP addresses and operating system you have actually confirmed, the location of the affected system by city and country, and the network or ISP. Then supply the two fields the form deliberately separates: occurrence date and time, and detection date and time.

Those two timestamps are why clock synchronisation appears in the same document. Your detection timestamp is the evidence that you filed inside six hours. If your SIEM, your EDR and your firewall disagree about what time it was, you cannot demonstrate when the clock started, and you have handed a regulator a question you would rather not answer.

State what you do not yet know. An initial report saying root cause unknown, scope under assessment, containment in progress as at 14:20 IST is a compliant report. One filed at hour thirty because you wanted certainty is not.

The log requirement is narrower than most readings

The direction says logs shall be maintained within the Indian jurisdiction. The FAQ then qualifies that considerably. Asked whether a copy of logs must be stored in India only, CERT-In answered that logs may be stored outside India also, provided the obligation to produce them to CERT-In is met in a reasonable time.

Read together, that is a production obligation with a residency default — not an absolute localisation mandate for every log line. Financial records are treated more strictly: the same FAQ says any service provider offering services to users in the country must enable and maintain logs and records of financial transactions in Indian jurisdiction.

A scoping point that saves wasted work

CERT-In's FAQ states the VPN obligations do not extend to enterprise or corporate VPNs. For the purpose of the direction, a VPN service provider means an entity providing Internet proxy like services to general internet subscribers. Your remote-access concentrator is not caught by the five-year subscriber register.

Where the DPDP clock diverges

The DPDP Rules were notified in the Gazette in mid-November 2025. Published summaries differ on whether the operative date is 13 or 14 November, which matters only in that it shifts every downstream deadline by a day. Commencement is staggered. According to a published analysis by the firm ILF, Rules 1, 2 and 17 to 21 took effect immediately, Rule 4 on consent manager registration at twelve months, and Rules 3, 5 to 16 and 22 to 23 at eighteen months after publication. Rule 7, on intimation of a personal data breach, sits in that final tranche.

Two features of Rule 7 will change your runbook, as summarised by the legal commentaries tracking the rules — read the notified text before you rely on either. There appears to be no materiality threshold: the duty attaches to a personal data breach, not to a serious one. And the notice to individuals is not a summary: it must be concise, clear and plain, and carry the nature and extent of the breach, the likely consequences for that person, the mitigation you have applied, the steps they should take themselves, and a contact point for queries.

You cannot draft that at hour seventy-one.

One intake, two clocks

1. Build one trigger. When an analyst raises a suspected incident, the intake record captures detection timestamp in IST, a provisional Annexure I category, and a yes / no / unknown flag for personal data involvement. Treat unknown as yes for clock purposes.
2. Pre-authorise the filing. Name two people who can send the CERT-In report without a CISO signature. At 02:00 on a Sunday, an approval chain is what makes you late.
3. Template the hour-four email. Fixed subject line, fixed fields, blanks marked not yet established. Keep it in the runbook, not in somebody's drafts folder.
4. Fix time synchronisation first. Point every log source at NIC or NPL NTP, or a traceable source, and monitor drift. It is cheap, and it underpins both filings.
5. Verify the Point of Contact quarterly. Re-send Annexure II whenever the person changes.
6. Test log production, not log retention. Holding 180 days is easy. Producing a coherent, time-aligned set covering a named window on short notice is the thing that fails.
7. Write the data principal notice now. Two templates, credential exposure and document exposure, reviewed by counsel while nobody is on fire.

The genuinely awkward part is sequencing. A CERT-In filing at hour four is a statement to a government agency that you have a live incident, made before you know whether personal data is involved. From May 2027 that same filing will sit alongside a Board intimation and a notice to individuals, and any inconsistency between the three is discoverable. Write the hour-four report so the hour-seventy-two report can be its continuation rather than its correction.