Data Breach Response Under DPDP: What to Prepare Before an Incident

Use a broad internal definition for response planning. If personal data may have been accessed, shared, altered, lost, exposed or used without proper authority, treat it as an incident until checked.

• customer list sent to the wrong email;
• CRM access left active after employee exit;
• public folder link containing KYC or documents;
• vendor account compromise;
• laptop or phone lost with personal data;
• malware or ransomware affecting records;
• wrong WhatsApp group receiving customer documents;
• app or website database exposure.

Incident noticed
        ↓
Record time, source and affected system
        ↓
Stop further exposure if possible
        ↓
Inform internal breach owner
        ↓
Identify affected personal data and users
        ↓
Check vendor / IT logs / access records
        ↓
Review DPDP reporting duties from latest official rules
        ↓
Prepare notice, mitigation and evidence file

1. Do not delete evidence. Keep screenshots, emails, logs and timestamps.
2. Stop the leak. Disable link, revoke access, reset password, remove wrong recipient or pause affected tool.
3. Identify data type. Was it name, phone, email, KYC, financial data, health data, employee data or child data?
4. Estimate affected persons. One person, one client group, all leads, all employees or unknown?
5. Check vendor role. If a vendor system is involved, ask for logs and written incident details.
6. Review legal notification duty. Check latest DPDP Rules and official notification position before deciding reporting content and timeline.
7. Record action taken. Keep an incident register even for smaller incidents.

• name and phone number of internal breach owner;
• list of systems containing personal data;
• vendor contact list for CRM, hosting, payment gateway, cloud storage and marketing tools;
• admin access details held securely by authorised person;
• standard incident register format;
• draft internal escalation message;
• template for affected-person communication, subject to legal review;
• latest DPDP reporting checklist maintained from official sources.

• Deleting logs because the team wants to "clean" the system.
• Waiting for management approval before stopping a public link.
• Not checking vendor access.
• Not recording who knew about the incident and when.
• Sending a public message before facts are checked.
• Assuming a small leak does not matter because only phone numbers were exposed.
• Not reviewing legal reporting duties under the latest DPDP Rules.

Should every incident be reported?

Do not guess. Record every incident internally, then check the latest DPDP Rules, official notification and legal position to decide reporting duties.

Who should handle breach response?

At minimum, assign one business owner, one IT/system person and one compliance/legal reviewer. In small businesses, the owner may handle the first role.

What if a vendor caused the breach?

Ask the vendor for written facts, logs, affected data details, mitigation steps and access records. Vendor contracts should include data incident cooperation clauses.

Can a WhatsApp mistake be a data incident?

Yes. If personal data is sent to the wrong person or group, record it and assess the risk. Do not ignore it because it happened outside email or CRM.

• Create incident register format.
• Assign breach owner.
• Map systems and vendors.
• Review admin access monthly or at least after employee exit.
• Prepare first-response steps.
• Keep latest DPDP reporting notes in the compliance file.
• Train staff on what not to do after an incident.

The first few hours matter. If the team knows who owns the incident and where data is stored, the response becomes calmer and more useful.