DPDP Breach Response Setup Guide
Structure your internal data breach response and notification workflows to meet Indian DPDP requirements for evidence and reporting. Get expert help.
Discuss this page with an LLM
DPDP Action Sheet
Use this before your next workflow goes live. It keeps the useful parts visible and turns DPDP into checks your team can actually answer.
For DPDP Breach Response Setup Guide, the DPDP question is how personal data enters the workflow, where it is stored, which tools touch it, what purpose was explained, and how deletion or withdrawal will work.
1. Lead Forms
Check:
- What data are you collecting?
- Is the purpose clear at the point of collection?
- Is marketing consent separate from service communication?
- Can the user withdraw consent later?
Common mistake: one checkbox that silently covers newsletters, sales calls, partner sharing and remarketing.
2. Email and WhatsApp
Check:
- Who is on the list?
- Where did consent come from?
- Is the list imported from a vendor, event, webinar, scrape or old CRM?
- Can you prove the source of consent?
Common mistake: treating every lead as permanently marketable.
3. Ads and Retargeting
Check:
- Are pixels or ad platforms receiving identifiable user behavior?
- Are audiences built from customer lists?
- Are lookalike or remarketing audiences using personal data?
Common mistake: assuming "the ad platform handles it" means your company has no DPDP responsibility.
4. Website Analytics
Check:
- Which tools run on the site?
- Are IP address, device identifiers, session IDs or form fields being captured?
- Is analytics used only for measurement, or also for profiling and targeting?
Common mistake: installing tools first and asking privacy questions later.
5. Vendor List
Make a quick list:
- CRM
- Email platform
- WhatsApp provider
- Analytics
- Ad pixels
- Form tool
- Landing page builder
- Webinar tool
For each vendor, answer: what data goes there, why, who can access it and how deletion works.
6. This Week's Action
Map one campaign from first click to final follow-up. Mark every place personal data is collected, enriched, shared, uploaded or used for targeting.
If your team cannot answer where the data came from and where it goes next, start with a data flow map before rewriting policy copy.
Book a DPDP clarity callWant all of this handled, end to end? Sanctum is the all-in-one DPDP compliance programme behind this site: legal position, data map, gap analysis, implementation, tooling, training, readiness opinion, and breach cover under one accountable owner. How all-in-one DPDP compliance works or see the Sanctum programme.
Logging and Evidence Management
DPDP requires proof of how a breach happened and what data was involved. You must maintain tamper-proof logs of system access, file downloads, and database queries. Store these logs on a separate, secure server to prevent attackers from deleting evidence during an incident. If you cannot show when a breach started or ended, the Data Protection Board will assume the largest possible scope of damage. Your evidence must include the specific categories of personal data accessed, such as Aadhaar numbers or financial records.
Notification Hierarchy
Your response plan must define who speaks to the Board and who notifies the users. Notifications must describe the nature of the breach, the data categories leaked, and steps taken to stop the leak. You cannot wait for a full investigation to report the incident. Start with a preliminary report as soon as you confirm unauthorized access. Ensure your customer support team has scripts ready to handle inquiries from affected individuals once the public notification is sent.
Breach Response Workflows
| Stage | Data Involved | DPDP Risk Level |
|---|---|---|
| Detection | System logs, IP addresses, login timestamps | Medium |
| Containment | Admin credentials, user access tokens | High |
| Triage | Customer names, phone numbers, PII types | Very High |
| Reporting | Contact lists for Board and individuals | High |
| Forensic Review | Memory dumps, hard drive images | Medium |
The Investigation Conflict
The biggest conflict in breach response is the timeline. Forensic experts often need weeks to find the root cause, but the DPDP Act requires rapid notification. You must separate your “notification workflow” from your “remediation workflow.” You must report the breach based on the facts available in the first 24 to 72 hours, even if the full technical details are not yet clear.
This Week
Draft a one-page “Breach Triage Sheet” that lists the emergency contact details for your IT lead, legal counsel, and the Data Protection Board’s reporting portal.
Now think about your work. Where does personal data enter your workflows? Where does it sit? Who else touches it?
Frequently asked questions
Do we notify the Board for minor technical glitches?
You only notify the Board if personal data was actually compromised. A simple server outage with no data exposure or unauthorized access does not require a DPDP breach report.
How long do we have to report a breach?
The DPDP Act requires notification to the Board and affected individuals. While specific timelines depend on final Rules, your response plan should aim for notification within 72 hours of discovery.
What happens if a vendor loses our data?
The vendor must inform you immediately. You, as the Data Fiduciary, are legally responsible for notifying the Data Protection Board and the affected users, regardless of who caused the leak.