Skip to content
DPDP full enforcement in--days--hrs--min--sec
DPDP Hub

Module 6 of 9

0% complete · 62 min left

Module 6 of 9Section 8(6) and 8(7)7 min including the detail

Breach notification, retention and erasure

Two duties that both fail for the same reason: they need a decision made in advance, and most organisations make it during the incident.

Notify the Board, and notify the people

Both, not either. And a single incident can engage two penalties: one for not preventing it, one for not reporting it.

200Rs crore

the ceiling for failing to notify a breach

Separate from the safeguards penalty, which is why one incident can attract both.

The detail, if you want it

In the event of a personal data breach you must give intimation to the Data Protection Board and to each affected Data Principal. Both, not either. The obligation is not conditioned on a threshold of severity in the way people expect from other regimes, and the DPDP Rules set out the form and timing.

Failure here carries up to ₹200 crore. Note that this is separate from the safeguards penalty: a single incident can engage both, once for not preventing it and once for not reporting it.

The clock is not the hard part. The list is.

Naming who was affected is what defeats organisations. Write and test that query while nothing is on fire.

The detail, if you want it

The duty that defeats organisations is naming who was affected. That requires knowing, quickly, which people had which data in the affected system. If that answer takes a week of engineering, the notification duty cannot be met however good the process document is.

So the work is done before the incident: the query that answers who was affected, written and tested while nothing is on fire, and templates drafted in advance so the time is spent deciding rather than drafting.

Erasure is triggered by two things, and blocked by one

Withdrawal triggers it. Purpose served triggers it without anyone asking. Only a specific law blocks it.

Erasure, in three lines

  • Triggerthe person withdraws consent
  • Triggerit is reasonable to assume the purpose is no longer served
  • Blockretention actually required by law, naming a real period
The detail, if you want it

You must erase personal data when the person withdraws consent, and when it is reasonable to assume the specified purpose is no longer being served. You must also ensure your Processor erases it. The second trigger is the one with teeth, because it operates without anybody asking: data kept past its purpose is a live breach of section 8(7).

The single exception is retention required by law. That exception has to be specific. Naming an actual statutory retention period is compliance; a general belief that records might be needed one day is not.

The three things to remember

  • Breach intimation goes to the Board and to each affected person. Both, not either.
  • The hard part is naming who was affected. Write and test that query before you need it.
  • Data held past its purpose must be erased, whether or not anyone asks for it.

What good looks like

Evidence you could put in front of an auditor, not a policy statement.

  • A tested query, per system, that returns the affected people for a given data set.
  • Breach notification templates for the Board and for individuals, drafted and approved in advance.
  • A retention schedule per category of data, naming either the purpose that justifies it or the law that requires it, with deletion actually running.

Check what you took in

2 questions, and getting both right completes the module. Nothing is sent to us.

Educational, not legal advice. This module describes what the Act requires of organisations generally; it does not advise on your own circumstances. DPDP Act, 2023: a working foundation.