Blog
Six hours: preparing your SOC for CERT-In reporting and DPDP breach duties
CERT-In's six-hour reporting window and the breach duties under India's DPDP Act leave no time to assemble evidence after the fact. Here is what to have ready before the incident.
Indian organisations work to some of the shortest incident-reporting clocks anywhere. Six hours is not enough time to find out who owns the decision, gather evidence from five tools and agree the wording of a report. Those things have to be settled before the incident.
This post sets out the obligations, then a practical list of what a SOC should have ready. It is operational guidance, not legal advice; read the current texts with your counsel.
The obligations
CERT-In directions, 28 April 2022. Issued under section 70B(6) of the Information Technology Act, 2000, the directions apply to service providers, intermediaries, data centres, body corporates and government organisations. Among other things, they require:
- specified cyber incidents to be reported to CERT-In within six hours of being noticed or brought to notice
- logs of ICT systems to be kept securely for a rolling 180 days, within Indian jurisdiction
- system clocks to be synchronised with the NTP servers of the National Informatics Centre or the National Physical Laboratory, or servers traceable to them
- a named point of contact for CERT-In
The text and the list of reportable incident types are published on the CERT-In website.
Digital Personal Data Protection Act, 2023. When a personal data breach occurs, the Data Fiduciary must inform the Data Protection Board and each affected Data Principal. The DPDP Rules, 2025 set out the form and timing, including a detailed report to the Board within 72 hours of becoming aware of the breach. The Act and Rules are published by the Ministry of Electronics and Information Technology.
Sector regulators can add their own requirements on top. Banks and other regulated entities should map those too.
What the six hours actually contain
Work backwards from the deadline. In six hours your team has to:
- recognise that an incident meets a reportable category
- decide, and record, that it is reportable
- gather the facts the report asks for
- have the report approved by the right person
- submit it, and keep proof of when
If any of those steps depends on finding someone, or exporting data from several tools, it will be late.
A readiness checklist
Decide the trigger in advance
The clock runs from when the incident is noticed. Agree in writing what "noticed" means in your SOC. The first alert? The analyst's confirmation? Whatever you choose, record the time consistently and be ready to explain it.
Name the roles
Who classifies an incident as reportable? Who writes the report? Who approves it? Who submits it? Name a primary and a deputy for each, for every shift. Put the names where the analyst on duty will see them.
Make the clock visible
Everyone working the incident should see how much time is left, without asking. A deadline in someone's head is a deadline that slips.
Keep the evidence in one place
The report will ask what happened, which systems were affected, what indicators were seen and what has been done. If the case record already holds the timeline, the affected assets, the indicators and the actions taken, the report is a summary. If not, it is an excavation.
Check log retention and time sync now
Confirm that the logs CERT-In expects are kept for at least 180 days, and where they are held. Confirm your systems synchronise time as the directions require. Both are easier to fix on a quiet Tuesday than during an incident.
Record the decision
Whether the answer is "reportable" or "not reportable", record who decided, when, and on what evidence. A decision not to report is the one most likely to be questioned later.
Rehearse
Run a tabletop exercise against the clock at least twice a year. Use a realistic scenario and a real shift. Note every point where someone had to ask a question.
For DPDP, think beyond the SOC
A personal data breach involves people outside security: the data protection officer, legal, communications and the business owner of the data. Agree how the SOC hands over the facts, and how quickly. The SOC's job is to make sure the facts exist, are accurate and can be shown.
How kymeer approaches this
kymeer's regulator deadline dashboard makes reporting clocks visible to everyone working an incident. It tracks CERT-In (6 hours), RBI (6 hours), NIS2 (24 hours) and GDPR (72 hours), and each clock runs from detection. The dashboard records, per incident and per regulator, whether and when the notification was filed.
Cases keep an append-only activity timeline next to the evidence, and the per-tenant audit log is linked by SHA-256 hashes, so the record of who decided what is kept as it happens.
Daily log review is recorded as evidence. The dashboard shows, per day, how much was ingested and whether an analyst signed off, and flags missed days. Analyst roles can sign off; the Auditor role cannot. A monthly PDF or CSV roll-up is refused rather than produced if the sign-off record for that month would be truncated.
Event retention defaults to 30 days hot, 90 days warm and 365 days in total, configurable per tenant. An optional retention lock can only lengthen retention, never shorten it. If logs must stay inside your own walls, kymeer can be installed on-prem, inside your environment.
kymeer supports your compliance work; it does not certify you. Read more in the compliance and reporting guide, or see Compliance and reporting.