Personal data breach response under the DPDP Act

A breach response plan written after the breach is mostly a diary.

For Indian organisations, a personal data breach response workflow now needs to connect privacy, security, product, vendor and communications work. The Digital Personal Data Protection Act, 2023 places breach handling inside the wider obligations of a Data Fiduciary, while the notified DPDP Rules, 2025 describe practical breach notification expectations. CERT-In directions may also apply where the event is a cyber incident, data breach or data leak. The result is not one heroic email. It is a timed operating routine with facts, owners, evidence and calm escalation.

What to review

Start with the incident definition used inside the organisation. A privacy event may begin as a lost laptop, misdirected export, exposed storage bucket, compromised account, vendor alert or suspicious download pattern. The first question is whether digital personal data is involved. The second is whether the organisation is the Data Fiduciary, a processor acting under instructions, or both for different datasets.

Review the current incident plan against the DPDP Act duties to protect personal data, respond to breaches and keep affected Data Principals informed where required. Then compare the security incident process with CERT-In reporting triggers, especially unauthorised access, data breach, data leak, attacks on applications, cloud incidents and digital payment incidents. Many organisations miss the overlap because privacy teams and security teams use different ticket queues.

The plan should also identify who can authorise external notification, who owns customer support scripts, who preserves logs, who coordinates vendor facts and who keeps the board or founders briefed. These names should be roles, not heroic individuals.

Implementation steps

Build a single breach intake form for security, privacy and vendor alerts. Capture the date and time noticed, reporting source, affected system, suspected personal data categories, number or range of affected individuals, business owner, processor or sub-processor involvement, containment status and evidence already preserved.

Create a triage matrix for three decisions. First, is personal data affected or reasonably suspected to be affected? Second, is this also a cyber incident that falls within CERT-In reportable categories? Third, what immediate communication is needed for affected individuals, regulators, customers, insurers, processors or enterprise clients? The matrix should avoid legal conclusions in the incident ticket. Use working classifications that can change as facts improve.

Preserve evidence early. CERT-In directions require relevant logs to be maintained securely for a rolling period of 180 days, and incident response work is hard without time-synchronised logs. Product and infrastructure teams should know which systems hold access logs, audit trails, authentication events, export histories, API traces and administrator changes. Privacy teams should know which records map system identifiers back to Data Principals.

Prepare notification templates before they are needed. The DPDP Rules expect breach communications to affected individuals to be clear, timely and practical, including what happened, likely consequences, mitigation steps and contact details. A good template leaves blanks for verified facts but does not leave the team inventing tone at midnight.

Set a vendor drill. Processors should be required to notify the organisation promptly, preserve evidence, support root-cause analysis and avoid contacting Data Principals unless instructed. The contract clause is only useful if procurement, security and privacy teams know how to activate it.

Finally, run a tabletop exercise twice a year. Use a realistic scenario such as exposed customer support exports, compromised HR credentials or an analytics misconfiguration. Measure not only response speed, but whether the team can produce a clean chronology and decision log.

Common mistakes

• Treating every incident as either security-only or legal-only, which delays the shared fact base needed for DPDP and CERT-In decisions.
• Waiting for perfect root-cause analysis before preserving logs, assigning owners and drafting holding communications.
• Forgetting processors, SaaS tools and cloud administrators when mapping who noticed the breach and who can contain it.

How DataNuance can help

DataNuance helps Indian organisations convert breach obligations into incident-room workflows that security, legal, privacy and product teams can actually use. We map personal data systems, design breach intake forms, align CERT-In and DPDP decision points, prepare notification templates and build board-ready evidence packs.

For teams preparing for launch, audit or enterprise customer review, we can test whether the current process answers the awkward questions: who noticed the event, what personal data is involved, when the clock started, which logs prove the position, who approves notification and what the organisation tells affected people. To convert this into a working response playbook, contact DataNuance through the /contact page.

FAQs

Is every security incident a personal data breach under the DPDP Act?

No. The organisation should first establish whether digital personal data is affected or reasonably suspected to be affected. Some malware, outage or probing events may not involve personal data, but they can still require security response or CERT-In analysis.

Can the DPDP breach process and CERT-In process use the same evidence pack?

Yes, if the pack is designed carefully. The same chronology, logs, containment notes and owner decisions can support both workflows, while the legal tests and recipients remain distinct.

Who should own breach response in an Indian company?

Ownership should be shared but clear. Security usually leads containment and forensics, privacy or legal leads personal data assessment and notification analysis, and business owners confirm customer, vendor and operational facts.

How often should a breach playbook be tested?

At least twice a year for organisations processing meaningful volumes of personal data. Test after major product launches, vendor changes, cloud migrations or customer support workflow changes.

Sources

• India Code, Digital Personal Data Protection Act, 2023.
• Press Information Bureau and MeitY material on the notified Digital Personal Data Protection Rules, 2025.
• CERT-In Directions dated 28 April 2022 on cyber incident prevention, response and reporting.