CERT-In + DPDP Breach Rules 2026: WhatsApp Business Playbook

A customer-data leak in your WhatsApp stack starts two clocks at once. The first belongs to CERT-In: India's national incident-response agency expects covered cyber incidents to be reported within six hours of your noticing them. The second belongs to the DPDP Act: as a data fiduciary you must notify the Data Protection Board of India and every affected user that their personal data was breached. Two regulators, two deadlines, two different documents — and most WhatsApp-first businesses discover the dual-clock problem at the worst possible moment, mid-incident at 2 a.m. This playbook lays both regimes side by side, translates "reportable incident" into WhatsApp-stack terms, gives you a 6-hour runbook you can rehearse on a calm Tuesday, and covers the part nobody writes about: telling your customers on WhatsApp itself without making it worse. One caveat up front — verify every specific against the current CERT-In directions and DPDP rules, because both evolve; this is operational guidance, not legal advice.

Two regimes, one incident: CERT-In vs DPDP at a glance

CERT-In's directions of April 2022, issued under Section 70B(6) of the IT Act, apply to service providers, intermediaries, data centres, body corporates and government organisations — which in practice means almost any business running digital systems in India, including a ten-person D2C brand with a WABA and a CRM. The headline obligations: report covered cyber incidents to CERT-In within six hours of noticing or being notified; maintain ICT system logs for a rolling 180 days within India; synchronise system clocks to NPL/NIC NTP servers; and designate a point of contact. (Verify the current directions, FAQs and reporting formats on cert-in.org.in — the annexures and channels are updated from time to time.)

The DPDP Act 2023 approaches the same incident from the data-subject side. Section 8(6) requires every data fiduciary to give intimation of a personal data breach to the Data Protection Board and to each affected data principal, in the prescribed form and manner. The DPDP rules add the operational detail: a plain-language notice to affected users without delay — what happened, the likely consequences, what you are doing about it, what they can do to protect themselves, whom to contact — and an intimation to the Board followed by a more detailed report (a 72-hour window for the detailed report has featured in the rules; verify the currently notified position and the Board's operational status before relying on it). The penalty schedule is the part that concentrates minds: amounts of up to ₹250 crore for failing to take reasonable security safeguards and up to ₹200 crore for failing breach-notification duties have been prescribed — again, verify the current schedule.

Why WhatsApp-first businesses are squarely exposed

Everything a WhatsApp-first operation holds is personal data under the DPDP Act. A phone number is an identifier by itself. Chat history routinely contains addresses, order values, payment confirmations and — for clinics, lenders, schools — far more sensitive context. Opt-in and consent records are personal data about personal data. There is no "it was only phone numbers" defence; phone numbers plus names plus purchase history is exactly the dataset phishing crews pay for.

The breach vectors are mundane, which is why they work. Leaked API tokens — a permanent WABA access token pasted into a public repo, a shared Postman collection, or a Google Doc with link-sharing on. Exported CSVs — a contact export made for one campaign, emailed to an agency, forwarded twice, and now sitting in three inboxes you do not control. Compromised team logins — shared seats, weak passwords, no 2FA, and the ex-employee whose account nobody deactivated. BSP-side incidents — your provider's infrastructure, your liability as fiduciary (more below). Leaky middleware — Sheets connectors and automation tools holding broad-scope keys. Unverified webhooks — payloads with message content flowing to an endpoint nobody audited since launch.

What actually counts as a reportable incident

CERT-In's annexure lists the covered incident types — around twenty categories including data breaches, data leaks, unauthorised access to IT systems or data, identity theft, spoofing and phishing attacks, ransomware, attacks on applications such as e-commerce and payment systems, and unauthorised access to social-media accounts (verify the current annexure; the list has been refined over time). Translated into WhatsApp-stack terms: a WABA takeover or unauthorised access to your number, token misuse to pull contact lists, a CRM or chat-database leak, a brand-impersonation phishing run executed over WhatsApp, or ransomware on the server hosting your conversation data — each maps onto a listed category.

DPDP's "personal data breach" definition is deliberately broader: any unauthorised processing or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access to personal data. That breadth matters operationally — a mis-uploaded CSV that broadcasts one segment's data to another, or a lost laptop with an unencrypted contact export, can qualify with no attacker anywhere in the story. The honest posture: when in doubt, assess the event against both definitions and write down why you concluded yes or no, with timestamps. The contemporaneous note is itself protective — it shows diligence even if your conclusion is later questioned.

The 6-hour runbook

Six hours is not enough time to investigate an incident. It is enough time to contain it, scope it roughly and file an initial report — which is what the regime actually anticipates: report with the information you have, supplement as the investigation matures. The same logic applies on the DPDP side, where the immediate intimation and the detailed report are separate steps. Here is the timeline to rehearse:

The customer notice deserves real design effort, and WhatsApp is the right channel for it — it is where your customers already talk to you, and a utility-category template carrying a security notice is precisely the kind of non-promotional, transactionally necessary message the category exists for. Write it honest and plain: what happened, what data was involved, what was not involved, what you did, what they should do, where to ask questions. No marketing voice, no minimising adverbs, no emoji.

The convergence problem: one incident, three documents

Here is where teams burn their six hours: CERT-In, the Board and your customers need different documents about the same event. CERT-In's format wants technical incident facts — affected systems, attack vectors, indicators of compromise, log extracts. The Board wants fiduciary facts — the nature and extent of the breach, data classes, how many principals are affected, your mitigation and the safeguards that were in place. Users need two plain paragraphs and one action. Teams that draft each notice from scratch under pressure contradict themselves across the three — and contradictions between your CERT-In report and your Board filing are the kind of thing that turns an incident into a proceeding.

The fix is one master incident document, started at T+0, from which every notification is an extract rather than a fresh writing job. Structure it once, today, as a template:

1. Incident ID, detection timestamp, who noticed and how.
2. Affected systems and data classes (numbers, chat content, consent records, payment context).
3. Affected-principal count — estimate plus the method behind it.
4. Containment log: timestamped actions (tokens rotated, sessions revoked, campaigns paused).
5. Root cause, as and when established.
6. CERT-In report copy + acknowledgement reference.
7. Board intimation + detailed report copies.
8. User-notice text as sent + send log (who, when, channel).
9. Remediation actions, owners, dates.

The prevention stack (and where your platform helps)

Everything above is cheaper if the breach never happens, or happens small. The full hardening walkthrough lives in our WABA security hardening guide; here is the breach-sized summary:

Data minimisation deserves the emphasis: the cheapest breach to notify is the one where the leaked table held first names and masked identifiers rather than full payment instruments and health context. Codify which variables are allowed in which templates — the green/mask-only/red list method is laid out in our conversation design system guide. And keep your consent trail clean and exportable from day one — the DPDP compliance checklist for WhatsApp businesses covers the consent-and-records layer that a breach filing will inevitably ask about.

On RichAutomate, the relevant posture is built in rather than bolted on: per-user role permissions so agents and admins see different surfaces, activity logs with last-login visibility so "who accessed what, and when" has an answer, and audit trails of account actions that feed straight into section 4 of your master incident doc. None of that makes you breach-proof — it makes you scopeable, which is what the six-hour clock actually demands.

Questions to ask your BSP before there is a breach

Under the DPDP Act you remain the data fiduciary even when the leak happens on your processor's side — a BSP-side incident does not transfer your notification duties, it just makes them harder to perform on time. Which is why breach terms belong in the procurement conversation, not the post-mortem. Ask: What is your incident-notice SLA to me, in hours? (It must land well inside your own 6-hour comfort zone — a provider that commits to "notification within 72 hours" has quietly made your CERT-In deadline impossible for provider-side incidents.) What details do you commit to provide — affected data classes, time window, principal counts? Will you cooperate on CERT-In and Board reporting where infrastructure is shared? Where does my data live, and how are tenants isolated? Are tokens scoped per tenant? Fold these into the scorecard from our BSP procurement and evaluation guide — and treat pricing transparency as part of the same diligence; a provider that publishes its pricing plainly (ours is at richautomate.in/pricing) tends to be a provider that answers breach-SLA questions plainly too.