Breach response

A personal data breach is any security incident that leads to personal data being lost, destroyed, changed, disclosed or accessed without permission. The clock starts when we become aware of it. This page is the runbook. Read it now, not during the incident.

How it works

Timelines, as of October 2026

	GDPR	DPDP Act and Rules
Report to the regulator	Within 72 hours of becoming aware, unless unlikely to result in a risk to people (Art. 33). If late, give reasons	Every breach. A description without delay, then a detailed report within 72 hours, or longer if the Board allows (Rule 7)
Tell the people	Without undue delay if likely to result in a high risk (Art. 34)	Without delay, every affected person, through their account or registered contact (Rule 7)
Processor to controller	Without undue delay (Art. 33(2))	The fiduciary is responsible for its processors' breaches
Record	Document every breach, reported or not (Art. 33(5))	Keep logs that let you investigate; Rule 6 asks for at least one year of logs
In force	Since 2018	Rule 7 applies from about 13 May 2027. The Act's breach duty (s.8(6)) exists, but the Rules set the mechanics
Max penalty	Up to EUR 10m or 2% of worldwide turnover for these duties (Art. 83(4))	Up to INR 200 crore for failing to notify; up to INR 250 crore for failing reasonable security safeguards

Sources: GDPR on EUR-Lex, EDPB Guidelines 9/2022 on breach notification, EDPB Guidelines 01/2021, breach examples, DPDP Act, DPDP Rules 2025.

Proposed change in the EU

The European Commission's "Digital Omnibus" proposal (COM(2025) 837, November 2025) would report only breaches likely to cause a high risk, within 96 hours, through one EU entry point. As of October 2026 it is not law. Keep using 72 hours. See Staying current.

The DPDP Board's own reporting channel was not confirmed when this page was written. Verify before relying on this, and keep the current address in the runbook.

How to build it

1. An incident record from minute one

create table breach_incident (
  id                   uuid primary key,
  detected_at          timestamptz not null,
  aware_at             timestamptz not null,   -- the clock starts here
  regulator_due_at     timestamptz not null,   -- aware_at + 72 hours, set when the record is opened
  summary              text not null,
  data_elements        text[],                 -- keys from the data map
  people_affected      integer,
  countries            text[],
  risk_level           text,                   -- none, risk, high
  contained_at         timestamptz,
  notified_regulator_at timestamptz,
  notified_people_at   timestamptz,
  root_cause           text,
  decision_log         jsonb                   -- who decided what, and why
);

Use the data map to answer "which data, whose, where" in minutes, not days.

2. Who does what

Role	Job
Incident lead (on call engineer)	Contain, preserve evidence, open the record
DPO	Decide whether and whom to notify; write the notice
Legal	Regulator contact, contracts, law enforcement
Comms	User message, support script
Service owner	Root cause and fix

3. Contain first, carefully

• Rotate the leaked secret, revoke tokens, close the public bucket, disable the account.
• Preserve evidence before you clean: copy logs, snapshot the resource, write down times.
• Do not delete the evidence trail as part of "fixing" it.

4. Write the notice

A regulator notice states: what happened, categories and approximate number of people and records, the likely consequences, what you did and will do, and a contact point. You can send it in phases if facts are still coming in. Do not wait for perfect information to miss the deadline.

5. Learn

Every breach, including near misses, ends with a fix that makes it impossible or visible next time: a redaction rule, a lint check, an alarm, a test.

Rules

Rule

The clock starts when anyone in the company becomes reasonably sure personal data was affected, not when the investigation finishes. Tell the DPO in the first hour.

Rule

Record every breach, even the ones you decide not to report. The record and your reasoning are what a regulator asks for later.

Rule

A secret or token that appeared in logs or a repository is burned. Rotate it. Removing the log line does not un-leak it.

Mistakes we made

• Tokens and an internal key in application logs. A routine log scan found user tokens in URL query strings and a service key in a header, written on every call. The fix was redaction at the logger plus a key rotation. Run a scan like this on a schedule.
• A fixed review login code committed to a repository. A store-review bypass code was in a committed document and the review email shipped inside the app binary. Treat committed codes as permanently burned, use the stores' demo-account fields, and switch the bypass off after review.
• No audit trail or threat detection at first. Some accounts had no account-wide audit trail or threat-detection service when the first scan ran. Without them you cannot answer "what was accessed" inside 72 hours. Turn them on before launch.

Checklist

• Runbook, roles and regulator contacts written down and reachable offline.
• Incident record template ready, with the 72-hour due time computed.
• Data map can answer "which data, how many people, which countries".
• Audit trail and threat detection on in every account; logs kept at least one year where DPDP applies.
• Secret rotation runbook for each key type.
• Processor contracts require them to tell us without undue delay.
• User notice template, in the languages of your users.