Incident management,
with the deadlines that start at detection.

• Incidents by severity with an incident commander, timeline and status from detection to post-mortem
• Mean time to detect, contain and remediate, computed only from recorded timestamps
• DPDP breach register with the 72-hour Board report clock
• Closure blocked until the Board and affected Data Principals are recorded as notified
• Free breach deadline calculator for CERT-In, GDPR and sector clocks

Auditors look for a documented response process, evidence that it was followed for real incidents, and metrics that show it working: how long incidents took to detect, contain and fix. SOC 2 CC7.3 to CC7.5 and ISO 27001 Annex A 5.24 to 5.28 ask for exactly this. A runbook with no incident records against it is a plan, not a control.

The metrics here are computed from timestamps entered as the incident happens. If a field is blank, the metric is blank; nothing is estimated.

1. Declare the incidentRecord what happened, when it was detected and its severity: critical, high, medium or low. Assign an incident commander who owns the response until it closes.
2. Move it through the stagesAn incident moves from detected to triaged, investigating, contained, remediated and post-mortem. Each change is timestamped, which builds the timeline without anyone writing it up afterwards.
3. Record who was toldNote each regulator, customer or partner you notified and when. The platform records the notification; it does not send it, because each regulator has its own channel.
4. Open a breach record if personal data is involvedIn the DPDP breach register, recording a personal data breach starts the 72-hour clock for the detailed report to the Data Protection Board. The record cannot close until the Board and affected Data Principals are recorded as notified.
5. Close with a post-mortemDraft and publish the post-mortem against the incident. Metrics for detection, containment and remediation are computed from the timestamps you recorded.

Several, and the shortest usually expires before the facts are known. CERT-In expects listed incidents within six hours of noticing them; the DPDP Rules expect a full report to the Data Protection Board within 72 hours; sector regulators add their own. The breach deadline calculator gives each timestamp, and CERT-In vs DPDP explains how they interact. The platform's DPDP breach register tracks the Board clock for you.

Incident response is auditable when there is a written plan, a record of real incidents handled under it, and evidence of what was learned. SOC 2 CC7.3 to CC7.5 ask you to evaluate events, respond to incidents and recover from them; ISO/IEC 27001:2022 Annex A 5.24 to 5.28 ask for planning, assessment, response, learning and evidence collection.

Auditors test this by sampling incidents from the period and tracing each one: when was it detected, who decided its severity, when was it contained, who was told and when, and whether a post-mortem changed anything. A runbook with no incidents recorded against it shows a plan, not a working control.

Recording small incidents matters for the same reason. A year with no incidents at all reads as a process nobody uses. A year of low-severity incidents handled and closed on time shows the process running.

Mean time to detect, contain and remediate are computed only from timestamps recorded on each incident: when it started, when it was detected, when it was contained and when it was remediated. If a timestamp is missing, the metric for that incident is left blank rather than estimated.

That makes the numbers defensible. An auditor or a board member can trace any average back to the incidents behind it. It also means the metrics are only as good as the recording, so the habit to build is updating the status as it changes, not reconstructing it the next day.

The CERT-In deadline is the hardest because six hours from noticing an incident is usually before you know what happened, how far it spread or whether personal data was involved. The Directions expect a report anyway, with what is known, completed later.

Two other CERT-In requirements decide whether you can investigate at all: logs of ICT systems must be kept for 180 days within India, and system clocks must be synchronised to NTP sources. Without them, the timeline an auditor or CERT-In asks for cannot be built. The CERT-In Directions guide covers the full list, and CERT-In vs DPDP explains how the two reports differ.

The platform does not run an automatic CERT-In clock today. Use the breach deadline calculator at the moment of detection, and record the notification on the incident when it is made.

The DPDP breach register enforces the 72-hour report by starting the clock when the breach is recorded and refusing to close the record until both the Data Protection Board and the affected Data Principals are recorded as notified. That turns section 8(6) from a reminder into a condition the record cannot get past.

Rule 7 of the DPDP Rules 2025 asks for an intimation without delay and a detailed report within 72 hours, covering what happened, the likely consequences, the measures taken and the contact for questions. The breach notification templates follow that structure. A breach that is overdue for its Board report shows as overdue until it is resolved.

• The incident response plan, approved and dated; the incident response plan template is a starting point
• A list of incidents in the period, with severity and status
• For a sample: detection, containment and resolution times, and who was responsible
• Evidence of notifications made, to whom and when, against each deadline that applied
• Post-mortems and the changes they led to
• Evidence the plan was tested, such as a tabletop exercise, at least once a year

• It does not send notifications to CERT-In, the Data Protection Board, regulators or customers; it records them
• It does not run an automatic CERT-In six-hour clock; use the free calculator for that deadline
• It does not detect incidents on its own; incidents are declared by your team or raised from findings
• It does not estimate missing timestamps; a blank field gives a blank metric
• It does not decide whether an incident is a reportable breach; that judgement stays with your team and counsel

Every result here is a control result on the same graph as the rest of the platform, so it reaches each framework that asks for it without being gathered again. Coverage lists the regimes.

Related reading: the incident response plan template and breach notification templates.