Introduction
Most organisations preparing for the Digital Personal Data Protection Act, 2023 (“DPDP Act”) have concentrated on what an auditor would ask to see including privacy notices, consent flows, retention schedules and policy documents. A personal data breach tests something different. It asks whether the organisation can detect an incident, contain it, assess it and notify the right parties within the statutory timelines, and whether it can show that its safeguards existed and worked before the incident occurred. The Digital Personal Data Protection Rules, 2025 (“DPDP Rules”) were notified in November 2025, and the substantive part of the DPDP Act is scheduled to come into force in May 2027, eighteen months after the commencement notification of 13th November, 2025. Organisations therefore have a limited window in which to prepare for that test.
Security Safeguards and Breach Notification: Distinct Statutory Duties
A breach engages two separate obligations. Section 8(5) of the DPDP Act requires a Data Fiduciary to protect personal data in its possession or under its control, including in respect of processing undertaken on its behalf by a Data Processor, by taking reasonable security safeguards to prevent a personal data breach. Section 8(6) requires it to give the Data Protection Board of India (“Board”) and each affected Data Principal intimation of the breach, in the form and manner prescribed.
The Schedule to the DPDP Act provides for a penalty that may extend to Rs 250 crore for a breach of Section 8(5), and to Rs 200 crore for a breach of Section 8(6). These are ceilings and not automatic fines. Under Section 33, the Board may impose a penalty only if it determines, on conclusion of an inquiry, that the breach is significant, and after giving the person an opportunity of being heard. In fixing the amount, it must have regard to the factors listed in Section 33(2), which include the nature, gravity and duration of the breach and the timeliness and effectiveness of any mitigation. Since the two contraventions are distinct, a business whose safeguards were inadequate and which then fails to give the required intimation may nonetheless face exposure under both.
The Timelines and Obligations for Breach Notification
Rule 7 of the DPDP Rules operationalises Section 8(6) through two parallel tracks. On becoming aware of a breach, the Data Fiduciary must, to the best of its knowledge, intimate each affected Data Principal without delay, in a concise, clear and plain manner, through her user account or any mode of communication registered by her. The intimation must describe the breach, its nature, extent and timing, the consequences likely to arise for her, the mitigation measures taken, the safety measures she may adopt and the contact details of a person who can respond to her queries.
Towards the Board, the Data Fiduciary must first describe the breach without delay, including its nature, extent, timing, location and likely impact. Within 72 hours of becoming aware of the breach, or such longer period as the Board may allow on a written request, it must provide updated and detailed information, the broad facts and circumstances leading to the breach, the mitigation measures, any findings regarding the person who caused the breach, the remedial measures taken to prevent recurrence, and a report regarding the intimations given to affected Data Principals.
Two points deserve attention. First, the 72-hour period applies to the detailed information given to the Board and not to the process as a whole, so “without delay” is the more demanding standard. Second, Rule 7 applies to “any personal data breach”, and unlike the General Data Protection Regulation it does not, on its text, apply a risk threshold, which suggests that every personal data breach is reportable.
Translating Security Safeguards into Operational Controls
Rule 6 gives content to the expression “reasonable security safeguards” by prescribing minimum measures. These include securing personal data through encryption, obfuscation, masking or virtual tokens, controlling access to the computer resources used, and maintaining logs, monitoring and review so that unauthorised access can be detected, investigated and remedied.
They also include reasonable measures for continued processing if the data is compromised, such as data backups, and the retention of logs and personal data for one year unless any other law requires otherwise. A post-breach inquiry is likely to examine whether these controls existed and operated in practice, and a policy document alone would not answer that question.
Beyond Access Control: Detecting Insider Threats
Not every incident involves an obviously compromised account. An employee with a legitimate need to access customer records may, with valid credentials, suddenly download an unusually large volume of personal data, connect from an unfamiliar location or move data to an unauthorised external destination. The credentials are genuine, yet the behaviour signals risk. This is where the logging, monitoring and review contemplated by Rule 6 become decisive, because an organisation must be able to see how access to personal data is being used, and not merely who has been granted it.
Practices such as role-based access, least privilege, periodic access reviews and multi-factor authentication are the usual means of evidencing such control, although Rule 6 itself speaks in more general terms, and the choice of measures would depend on the organisation and the risk.
Data Mapping as the Foundation of Breach Readiness
An organisation cannot assess a breach quickly if it does not know what personal data it holds, where it is stored, why it is processed, who has access to it, which Data Processors handle it, how long it is retained and how it is finally erased.
A data discovery and mapping exercise is therefore the logical first step, followed by identifying processors, assessing existing controls and fixing accountability within the organisation. Without this, the Rule 7 requirement to describe the nature, extent and likely impact of a breach, within the time allowed, may be difficult to meet.
Third-Party Breaches and Concurrent Reporting Obligations
Under Section 8(1) of the DPDP Act, a Data Fiduciary is responsible for compliance in respect of any processing undertaken by it or on its behalf by a Data Processor, irrespective of any agreement to the contrary. A compromise at the vendor’s end is therefore the Data Fiduciary’s concern for the purposes of notification.
Rule 6 also requires appropriate provisions in the contract with the Data Processor for taking reasonable security safeguards. Processing contracts should accordingly go further and fix incident-reporting timelines, forensic cooperation and access to logs, so that the Data Fiduciary does not lose critical hours waiting on its vendor.
The DPDP timeline also runs alongside existing obligations. The directions issued by CERT-In on 28 April 2022 under Section 70B (6) of the Information Technology Act, 2000 require specified cyber incidents to be reported to CERT-In within six hours of noticing them, and sectoral regulators such as the Reserve Bank of India and the Securities and Exchange Board of India impose their own reporting requirements. A single incident can thus start several clocks at once, which is why a unified response plan is important.
AMLEGALS Remarks
The first real test of DPDP Act compliance is likely to arrive through an incident and not through a scheduled audit. The question for businesses is not only whether a framework exists on paper, but whether they can demonstrate that their controls are implemented and operating effectively when a breach occurs.
Businesses would be well advised to treat breach response as a core compliance function: mapping their data, documenting and testing their safeguards, rehearsing the notification workflow, and aligning vendor contracts with the timelines under Rule 7. With Rules 6 and 7 scheduled to take effect from May 2027, the intervening period is best used to arrive with controls that are already in place, tested and operational, so that the first occasion on which they are used is not a live breach.
For any queries or feedback, feel free to connect with mridusha.guha@amlegals.com or Khilansha.mukhija@amlegals.com