DPDPA Breach Notification: Automating SIEM Alerts to Legal Workflows

A practical engineering guide to automating breach detection, classification, and dual notification under India's Digital Personal Data Protection Act with accurate rule references and production-ready patterns.

Key Takeaways

• Section 8(6) requires a Data Fiduciary to intimate every personal data breach to the Data Protection Board and to each affected Data Principal; Rule 7 sets how.
• Rule 7 runs two clocks from the moment you become aware: "without delay" to Data Principals (7(1)) and to the Board (7(2)(a)), then a detailed Board report within 72 hours (7(2)(b)).
• The 72 hours can be extended only by the Board, on a written request.
• Breach intimation is Rule 7, not Rule 13. Rule 13 covers Significant Data Fiduciary duties such as the annual DPIA and audit.
• Automation needs three things built in advance: a PII asset inventory linked to the SIEM, a Section 2(u) classifier, and pre-approved templates for all three intimations.
• Failing to intimate can attract a penalty of up to ₹200 crore (Schedule item 2); failing to take reasonable security safeguards, up to ₹250 crore (item 1).
• Rule 7 applies from 13 May 2027.

Key terms. Data Fiduciary: the person who determines the purpose and means of processing personal data (S.2(i)). Data Principal: the individual the personal data relates to (S.2(j)). Data Protection Board: the Data Protection Board of India (S.2(c)), which receives breach intimations. Personal data breach: any unauthorised processing, or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access, that compromises the confidentiality, integrity or availability of personal data (S.2(u)). Significant Data Fiduciary (SDF): a Data Fiduciary notified under S.10, with extra duties under Rule 13. SIEM / SOAR: the security monitoring and orchestration platforms that detect incidents and drive the response playbook.

Contents

1. What the law actually says
2. The dual notification structure: Rule 7
3. The notification timeline decoded
4. Building the breach notification pipeline
5. Step 1: SIEM detection and triage
6. Step 2: Classification against Section 2(u)
7. Step 3: Parallel notification dispatch
8. Penalty exposure and mitigation evidence
9. Pre-incident checklist
10. What do engineers ask about DPDPA breach notification?

Your SIEM fires at 2:47 AM on a Saturday. An anomalous exfiltration pattern of 47,000 records from a database containing personal data of Indian users. Two clocks start running simultaneously: your security clock and your regulatory clock under Section 8(6) of the Digital Personal Data Protection Act, 2023.

Most organisations discover during an actual incident that their IR playbook has a gap between "alert detected" and "notification dispatched." That gap is exactly what this article addresses with engineering patterns and, critically, accurate references to the law as it is written.

1. What the law actually says

Section 8(6) — DPDPA 2023

The statutory obligation



"In the event of a personal data breach, the Data Fiduciary shall give the Board and each affected Data Principal, intimation of such breach in such form and manner as may be prescribed."

Two audiences. Two notification tracks. The phrase "as may be prescribed" delegates the mechanics to the DPDP Rules 2025, specifically Rule 7.

What counts as a "personal data breach": Section 2(u)

Section 2(u), DPDPA 2023



"personal data breach" means any unauthorised processing of personal data or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access to personal data, that compromises the confidentiality, integrity or availability of personal data;

This definition covers all three CIA dimensions, not just exfiltration. Ransomware that locks access to a personal data store is a breach. Accidental sharing of a user export to the wrong recipient is a breach. Unauthorised modification of health records is a breach. Your SIEM triage logic must account for all three.

⚠️ Common misconception: Breach notification is in Rule 13. It is not. Rule 13 covers additional obligations of Significant Data Fiduciaries (SDFs) — things like Data Protection Impact Assessments and algorithmic audits. The breach notification rule is Rule 7: Intimation of personal data breach.

The security safeguards foundation: Rule 6

Rule 6 governs the security measures a Data Fiduciary must maintain to prevent breaches. It mandates encryption and obfuscation of personal data, access controls on computer resources, logging and monitoring to detect unauthorised access, data backups for continuity, and critically, retention of logs and personal data for a minimum of one year to enable investigation. Rule 6 is the foundation that makes SIEM infrastructure a legal requirement, not optional hygiene.

2. The dual notification structure: Rule 7

Rule 7 splits the notification obligation into two tracks that run in parallel from the moment of awareness.

🏛️ Data Protection Board [Rule 7(2): Two-step process]



1. Initial intimation (Rule 7(2)(a)): Without delay, nature, extent, timing, location, likely impact



2. Detailed report (Rule 7(2)(b)): Within 72 hours (or longer if the Board permits), an updated description, facts, causes, mitigation measures, findings on who caused it, remedial steps, and Data Principal notification log

👤 Affected Data Principals [Rule 7(1): Without delay]



1. Description of the breach, including its nature, extent and timing of occurrence (Rule 7(1)(a))



2. Likely consequences relevant to them (Rule 7(1)(b))



3. Mitigation measures implemented or underway (Rule 7(1)(c))



4. Safety measures the individual can take (Rule 7(1)(d))



5. Contact information of a person who can answer queries (Rule 7(1)(e))

Notice the asymmetry: the Data Principal notification (Rule 7(1)) has five required elements and must go out without delay. The Board notification has two stages, a quick initial alert without delay (Rule 7(2)(a)), followed by a comprehensive 72-hour report (Rule 7(2)(b)). This two-stage Board process is what your SOAR playbook needs to model.

3. The notification timeline decoded

⏱️



The 72-hour deadline exists, but it applies specifically to the detailed Board report. Rule 7(2)(a) requires an initial Board intimation "without delay." Then Rule 7(2)(b) gives 72 hours for the comprehensive follow-up (or longer if the Board grants an extension in writing). This is different from GDPR's 72-hour window, which starts a single clock. Under DPDPA, there is an earlier "without delay" obligation that fires before the 72-hour clock even matters.

T = 0



Awareness confirmed. Your SIEM or security team confirms a personal data breach under Section 2(u). Both notification clocks start now, not from when the breach occurred, but from when your organisation becomes aware.

Without delay



Initial Board intimation + Data Principal notification. Rule 7(2)(a): Send initial alert to the Data Protection Board — nature, extent, timing, location, likely impact. Rule 7(1): Notify affected Data Principals through their registered user account or communication channel. Both go out simultaneously.

Within 72 hours



Detailed Board report. Rule 7(2)(b): Submit the comprehensive report, updated description, root cause, measures taken, findings on the responsible party, steps to prevent recurrence, and a log of all Data Principal notifications sent. The Board can grant a longer period on written request.

The practical implication: you need two Board notification templates, not one. Pre-build both before an incident occurs. The initial intimation should be automatable from SIEM data alone. The 72-hour detailed Board report (Rule 7(2)(b)) requires forensic input, which is why the SOAR orchestration must begin evidence collection the moment a breach is confirmed.

4. Building the breach notification pipeline

The pipeline connects three layers: detection, classification, and notification dispatch. Here is the overall flow before we go step by step.

1. SIEM Detection: Does this involve personal data? Correlation rules fire on exfiltration, unauthorised access, data modification, and availability loss. A PII asset inventory lookup determines whether the affected system contains personal data under Section 2(t). Without this lookup, your SIEM cannot distinguish a DPDPA-reportable breach from a general security event.
2. Classification Engine: Does it meet Section 2(u)? A programmatic classifier applies the Section 2(u) definition: Was the processing unauthorised or accidental? Which CIA dimension is affected? What breach type (acquisition, disclosure, alteration, loss of access)? Uncertain cases escalate to your privacy lead (the DPO, where you have one; a DPO is mandatory only for Significant Data Fiduciaries).
3. Parallel Dispatch: Three simultaneous tracks. Track A: Data Principal notifications (Rule 7(1)), five required fields, via user account or registered channel. Track B: Initial Board intimation (Rule 7(2)(a)) without delay. Track C: Evidence collection begins for the 72-hour Board report (Rule 7(2)(b)).
4. Evidence Retention: Rule 6(1)(e) and Rule 8(3). Rule 6(1)(e) requires you to retain logs and personal data for one year to enable detection of unauthorised access, its investigation and remediation (unless another law requires otherwise); Rule 8(3) sets a one-year minimum for personal data, traffic data and processing logs. The Rules do not prescribe a separate breach-record register, but your incident case file is the evidence that the Rule 7 intimations were made, so retain it alongside those logs.

5. Step 1: SIEM detection and triage

The prerequisite for any DPDPA breach detection capability is a maintained PII asset inventory, a register of every system, database, and service that processes personal data. Without it, correlation rules cannot determine whether an alert is DPDPA-relevant.

# Splunk correlation rule (adapt for Sentinel / QRadar / Elastic)
# dpdpa_breach_detection.conf
# Tags events involving personal data assets for DPDPA triage

[dpdpa_breach_detection]
search = index=security sourcetype IN (aws:cloudtrail, azure:activity, firewall, dlp)
  (action=DataExfiltration OR action=UnauthorizedAccess
   OR action=DataModification OR action=DataDeletion
   OR action=AccessDenied_Anomalous)
  # PII asset inventory lookup — maps asset_id to personal data flag
  | lookup pii_asset_inventory.csv asset_id OUTPUT
      contains_personal_data, data_classes, data_principal_count
  | where contains_personal_data="true"
  | stats count as event_count,
          values(data_classes) as affected_classes,
          dc(src_ip) as unique_sources,
          min(_time) as first_seen
    by asset_id, action
  | where event_count > 5
  | eval cia_dimension=case(
      action="DataExfiltration",    "confidentiality",
      action="DataModification",    "integrity",
      action="DataDeletion",        "availability",
      action="AccessDenied_Anomalous", "availability",
      1=1, "unknown")
  # Route to SOAR for Section 2(u) classification
action.webhook.param.url = https://soar.internal/api/v1/dpdpa-triage

The pii_asset_inventory lookup is the most important infrastructure piece. It should map each asset ID to a personal data flag, the categories of data it holds, and an approximate count of Data Principals. Keep it current; stale inventory means missed DPDPA obligations.

6. Step 2: Classification against Section 2(u)

Once the SIEM flags a potential personal data incident, a classification engine determines whether it meets the legal definition. The logic mirrors the Section 2(u) test exactly.

# DPDPA breach classifier (simplified)
"""
dpdpa_breach_classifier.py
Applies the Section 2(u) test to a confirmed security incident.
Section 2(u): unauthorised processing OR accidental disclosure /
acquisition / sharing / use / alteration / destruction /
loss of access — that compromises CIA of personal data.
"""

from enum import Enum
from dataclasses import dataclass
from typing import Optional

class BreachType(Enum):
    UNAUTHORISED_ACQUISITION = "unauthorised_acquisition"  # exfiltration
    ACCIDENTAL_DISCLOSURE    = "accidental_disclosure"
    UNAUTHORISED_ALTERATION  = "unauthorised_alteration"   # integrity
    LOSS_OF_ACCESS           = "loss_of_access"             # availability
    DESTRUCTION              = "destruction"
    UNAUTHORISED_USE         = "unauthorised_use"

class ClassificationResult(Enum):
    CONFIRMED_BREACH     = "confirmed_breach"
    NOT_A_BREACH         = "not_a_breach"
    ESCALATE_TO_DPO      = "escalate_to_dpo"

ACTION_MAP = {
    "exfiltration":         BreachType.UNAUTHORISED_ACQUISITION,
    "data_leak":            BreachType.ACCIDENTAL_DISCLOSURE,
    "unauthorised_access":  BreachType.UNAUTHORISED_USE,
    "data_modification":    BreachType.UNAUTHORISED_ALTERATION,
    "data_deletion":        BreachType.DESTRUCTION,
    "ransomware":           BreachType.LOSS_OF_ACCESS,
}

def classify(incident: dict) -> ClassificationResult:
    # Gate 1: Does it involve personal data?
    if not incident.get("contains_personal_data"):
        return ClassificationResult.NOT_A_BREACH

    # Gate 2: Was access authorised?
    if incident.get("is_authorised"):
        return ClassificationResult.NOT_A_BREACH

    # Gate 3: Can we classify the breach type?
    action = incident.get("action", "").lower()
    breach_type = ACTION_MAP.get(action)

    if breach_type is None:
        return ClassificationResult.ESCALATE_TO_DPO  # DPO triage

    return ClassificationResult.CONFIRMED_BREACH

7. Step 3: Parallel notification dispatch

Notification content: what each template must contain

💡 Design principle: The Data Principal notification and the Board initial intimation share overlapping fields, nature, and likely impact. Use a single source-of-truth incident record and render audience-specific templates from it. The 72-hour detailed Board report then draws on the same record plus forensic enrichment gathered in the hours after the breach is confirmed.

Delivery channel — Rule 7(1)

Data Principal notifications must go through "her user account or any mode of communication registered by her with the Data Fiduciary." This means your notification service must integrate with your user management system. Sending to a generic email address when the user's registered channel is a mobile number is non-compliant. Build channel priority: in-app → registered email → registered mobile.

8. Penalty exposure and mitigation evidence

The DPDPA Schedule specifies penalty caps across different categories of default. Two are directly relevant to breach response:

₹250 Cr



Failure to take reasonable security safeguards to prevent the breach — Section 8(5)



Schedule, Item 1

₹200 Cr



Failure to notify the Board or affected Data Principals of a breach — Section 8(6)



Schedule, Item 2

The Board determines actual penalty amounts based on factors including the nature and gravity of the breach, the type of personal data involved, and critically, whether the organisation took timely and effective mitigation actions (Section 33(2)). Automated, timestamped breach notification is direct evidence of the latter. An automated pipeline that dispatches notifications within minutes of breach confirmation is a stronger mitigating argument than a manual process that took days.

Rule 6(1)(e) requires you to retain logs and personal data for one year "for enabling the detection of unauthorised access, its investigation, remediation to prevent recurrence", and Rule 8(3) sets a one-year minimum for processing logs. The Rules do not prescribe a separate breach-record register, so your SOAR platform's case record is your evidence of the Rule 7 intimations and of mitigation under Section 33(2)(e). Retain it with those logs, and make it immutable and timestamped.

9. Pre-incident checklist

The worst time to draft a notification template is at 2:47 AM during an active breach. Every item below should be completed before an incident occurs:

✅ Pre-incident readiness checklist

• PII asset inventory built, linked to SIEM, and updated on a regular cadence
• SIEM correlation rules distinguish personal-data events from general security events
• Section 2(u) classifier configured and tested with tabletop scenarios covering all three CIA dimensions
• Data Principal notification template built with all five Rule 7(1) required fields, in clear and plain language
• Board initial intimation template (Rule 7(2)(a)) pre-populated with org details; auto-fills nature/extent/impact from SIEM data
• 72-hour detailed Board report template (Rule 7(2)(b)) covering all six items (i)–(vi); forensic integration wired to populate fields 6–9
• Notification delivery channels mapped to the user account primary, registered email/mobile fallback
• DPO on-call rotation documented; escalation path for uncertain classifications defined
• SOAR playbook tested end-to-end with a simulated breach scenario
• Security logs and personal data retained for one year (Rule 6(1)(e)); processing logs for a one-year minimum (Rule 8(3)); breach case records kept with them
• Board extension request template drafted for Rule 7(2)(b) if 72 hours is insufficient

10. What do engineers ask about DPDPA breach notification?

Does DPDPA give you 72 hours to notify a personal data breach?

Not for the first notices. Rule 7(1) and 7(2)(a) require intimation to each affected Data Principal and to the Board "without delay". The 72 hours under Rule 7(2)(b) apply only to the detailed follow-up report to the Board.

When do the Rule 7 clocks start?

On becoming aware of the personal data breach. Both Rule 7(1) and Rule 7(2) begin "On becoming aware", and the 72 hours in Rule 7(2)(b) run from that same moment, not from when the breach happened.

Who must be notified?

The Data Protection Board and each affected Data Principal (Section 8(6)). Data Principals are told through their user account or a communication mode they registered with you (Rule 7(1)).

What must the Data Principal notice contain?

Five items under Rule 7(1): a description of the breach; the likely consequences for her; your mitigation measures; the safety measures she can take; and business contact details of someone who can answer her queries.

Can the 72-hour deadline for the detailed Board report be extended?

Yes, but only by the Board. Rule 7(2)(b) allows "such longer period as the Board may allow on a request made in writing". Keep an extension-request template ready; don't assume an extension will be granted.

Is breach notification in Rule 13?

No. That numbering came from older, unverified sources. In the notified Rules, breach intimation is Rule 7. Rule 13 sets the additional obligations of Significant Data Fiduciaries, such as the annual DPIA and audit.

When do these obligations apply?

Section 8(6) and Rule 7 apply from 13 May 2027. Build and test the pipeline before then: a tabletop exercise will expose gaps that a real incident would turn into penalties.