Rule 7 - Intimation of personal data breach

Rule 7 establishes the communication and regulatory-reporting obligations that arise once a Data Fiduciary becomes aware of a personal data breach. It requires two separate streams of intimation:

1. an intimation to each affected Data Principal, without delay; and

2. an intimation to the Data Protection Board of India, first without delay and then through a more detailed submission within seventy-two hours, unless the Board permits additional time.

Rule 7 must principally be read with Sections 2(u), 8(6), 27, 28 and 33 of the DPDPA, Rule 6 on reasonable security safeguards, and the penalty Schedule. The final Rule was notified as part of the DPDP Rules, 2025.

Commencement position: Rule 7 and Section 8(6) are scheduled to come into force on13 May 2027. The Rule is final but not yet operational as of 1 September 2026. Organisations should use the transition period to establish breach-identification, escalation, investigation, notification and evidence-preservation procedures.

1. The function of Rule 7

A personal data breach may affect an individual in several ways. It may expose confidential information, permit identity fraud, alter important records, prevent access to essential services or reveal personal information to an unintended recipient. Rule 7 ensures that the breach is not treated merely as an internal cybersecurity issue.

The Rule serves two different purposes.

The intimation to the Data Principal enables the affected individual to understand the incident and take protective action. The intimation should therefore focus on what happened to her data, what consequences may follow, what the Data Fiduciary is doing and what she can do herself.

The intimation to the Board serves a regulatory purpose. It enables the Board to assess the incident, require urgent remedial or mitigation measures, inquire into the breach and, where the statutory conditions are met, impose a monetary penalty. Under Section 27, the Board may act upon receiving a breach intimation and may direct urgent measures to address the incident.

The two communications are therefore related but not interchangeable. A notice written for the Board may contain technical, investigative or evidentiary information that is unsuitable for an individual. A communication to an affected Data Principal may appropriately simplify technical details but would not, by itself, provide the full regulatory information required by Rule 7(2).

1.1 Relationship with Section 8(6)

Section 8(6) creates the underlying duty to notify. It requires a Data Fiduciary to intimate the Board and each affected Data Principal of a personal data breach in the form and manner prescribed.

Rule 7 provides that prescribed form, manner, timing and minimum content.

The relationship is:

• Section 2(u) determines whether an event constitutes a personal data breach;

• Section 8(6) creates the obligation to intimate the Board and affected Data Principals;

• Rule 7(1) governs the Data Principal intimation;

• Rule 7(2)(a) requires the initial Board intimation without delay;

• Rule 7(2)(b) requires the detailed Board submission within seventy-two hours;

• Rule 6 supplies the logs, monitoring, investigation and remediation capabilities needed to understand and manage the breach;

• Section 27 empowers the Board to direct urgent remedial or mitigation measures and inquire into the breach; and

• Section 33 and the Schedule provide the penalty framework for a significant notification failure.

Rule 7 is therefore the reporting stage of a broader breach-management process. It cannot be implemented effectively unless Rule 6 security controls provide timely detection, reliable evidence and the ability to determine which data and Data Principals were affected.

1.2 What is a personal data breach?

The DPDPA defines a personal data breach broadly. It covers unauthorised processing of personal data and accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access that compromises the confidentiality, integrity or availability of personal data.

This extends beyond conventional cyberattacks.

A breach may arise from:

• hacking;

• ransomware;

• phishing;

• stolen credentials;

• unauthorised employee access;

• misdirected email;

• accidental publication;

• loss of an unencrypted device;

• alteration of records;

• deletion of a database;

• loss of encryption keys;

• exposure by a Data Processor;

• insecure cloud configuration;

• disclosure through an AI system;

• physical loss followed by digitisation or unauthorised access; or

• inability to access personal data required for an essential service.

CERT-In similarly describes computer security incidents by reference to confidentiality, integrity and availability, reinforcing that cyber incidents are not confined to unauthorised disclosure.

1.3 Confidentiality breach

A confidentiality breach occurs when personal data is accessed or disclosed without authority.

Example

Examples include:

• an employee sends payroll records to the wrong recipient;

• a hospital database becomes publicly accessible;

• an attacker downloads customer identity documents;

• a vendor uses customer information outside its instructions;

• an employee views records without a business need;

• a generative AI service reproduces information from confidential prompts.

1.4 Integrity breach

An integrity breach occurs where personal data is altered, corrupted or destroyed without authority.

Example

Examples include:

• an attacker changes bank-account details;

• medical information is incorrectly modified;

• attendance records are manipulated;

• consent records are altered;

• a database becomes corrupted;

• an employee deliberately changes customer information.

Integrity incidents can be serious even if the information is never disclosed externally. An altered medical allergy record or changed bank credential may directly affect an individual’s interests.

1.5 Availability breach

An availability breach occurs where authorised users lose access to personal data.

Example

Examples include:

• ransomware encrypts patient records;

• a database is accidentally deleted;

• a system outage prevents access to payroll information;

• encryption keys are lost;

• a Processor’s failure makes essential customer records unavailable;

• an attack prevents an individual from accessing her account.

An ordinary short service interruption may not always amount to a personal data breach. The issue is whether there has been a loss of access compromising the availability of personal data, viewed in the factual and operational context.

1.6 The trigger: “On becoming aware”

Both parts of Rule 7 are triggered when the Data Fiduciary becomes aware of a personal data breach.

This phrase makes the time of awareness legally important. Organisations should establish a clear and evidence-based process for recording:

• when the first suspicious event was detected;

• when it was reported internally;

• when the security team began investigation;

• when sufficient evidence existed to identify a personal data breach;

• who made that determination; and

• when the legal and privacy teams were informed.

1.7 Suspicion is not always awareness

A security alert does not automatically establish that a personal data breach has occurred. A failed login attempt may be blocked successfully. Malware may be detected before it reaches a system containing personal data. An email-security tool may quarantine a malicious attachment before delivery.

The organisation may need a short factual assessment to determine whether personal data was actually affected.

However, “investigation” cannot become a device for postponing awareness. Once the available facts reasonably establish unauthorised processing or compromise of confidentiality, integrity or availability, the Data Fiduciary should not delay the notification clock by withholding internal confirmation.

1.8 Illustration: Exposed cloud database

A security researcher tells a company that a customer database is available on the internet without authentication. The company confirms within two hours that the database is publicly accessible.

The company should ordinarily treat itself as aware of a personal data breach when it has confirmed the exposure. It should not wait several days to establish whether a particular external person downloaded every record before beginning the Rule 7 process.

1.9 Illustration: Suspicious login

An automated system detects a login from an unusual location. The account was protected by multifactor authentication, the login failed and no personal data was accessed.

The alert requires review, but the facts may establish an attempted intrusion rather than a completed personal data breach. The organisation should document the conclusion and retain the supporting evidence.

1.10 Awareness through an employee or Processor

A Data Fiduciary cannot avoid awareness merely because senior management or the legal department was not informed.

Awareness may arise when information reaches an employee, function or Processor responsible for receiving or investigating security incidents. Internal reporting failures should not be allowed to postpone the external obligation.

Processor contracts should therefore require prompt reporting of:

• confirmed breaches;

• suspected compromise affecting the Data Fiduciary’s information;

• unauthorised access;

• loss or corruption;

• ransomware;

• material security incidents; and

• requests for further information.

The Data Fiduciary remains responsible for the Rule 7 notifications even where the incident occurred in a Processor’s environment.

1.11 No general risk threshold for notification

Rule 7 does not state that notification is required only where the breach creates a high risk, material harm or likely serious consequence.

Once a personal data breach occurs and the Data Fiduciary becomes aware of it:

• each affected Data Principal must be intimated under Rule 7(1); and

• the Board must be intimated under Rule 7(2).

This structure differs from regimes that permit an organisation to withhold regulatory notification for low-risk breaches or individual notification unless a high-risk threshold is met.

Risk remains important, but for different purposes. It affects:

• the urgency and content of safety advice;

• containment priorities;

• severity classification;

• the Board’s response;

• whether urgent directions are required;

• whether the breach is significant for enforcement;

• and the amount of any penalty.

It does not appear in Rule 7 as a general exemption from notification.

1.12 Identifying an “affected” Data Principal

The obligation is owed to each Data Principal whose personal data was implicated in the breach.

An individual is not necessarily affected merely because she uses the same service or appears in the same general database. The Data Fiduciary must determine whether the incident affected her personal data.

1.13 Illustration: Segmented compromise

An attacker accesses one database shard containing records of 20,000 customers. The service has two million customers in total.

The notification obligation to Data Principals applies to those whose data was affected, not automatically to every customer. However, the Data Fiduciary must have reliable evidence supporting the affected population and should address uncertainty in its Board report.

1.14 Illustration: Uncertain affected population

A compromised administrator account could access the entire database, but incomplete logs prevent the organisation from determining which records were viewed.

The absence of evidence may be the result of inadequate security logging. The organisation should not automatically assume that nobody was affected. It must make a reasonable assessment using the best available information and explain the uncertainty to the Board.

1.15 Intimation to affected Data Principals

Rule 7(1) requires the Data Fiduciary to intimate each affected Data Principal:

• to the best of its knowledge;

• in a concise, clear and plain manner;

• without delay; and

• through the Data Principal’s user account or a registered mode of communication.

These qualifications shape both the timing and quality of the communication.

1.16 “To the best of its knowledge”

The Data Fiduciary is not required to have complete forensic certainty before communicating. The phrase recognises that investigations develop over time.

The notice should use the best verified information available at the time. It should distinguish between:

• known facts;

• reasonable assessment;

• matters still under investigation; and

• steps that will follow.

The phrase does not permit careless speculation. Nor does it permit indefinite delay until every technical detail is established.

A responsible initial notice may state that:

• unauthorised access has been confirmed;

• specified categories of data are known to be involved;

• the exact access period remains under investigation;

• protective steps should be taken immediately; and

• further information will be provided if material facts change.

If the investigation later establishes that the first notice was materially incomplete or inaccurate, a supplementary communication should be provided.

1.17 Concise, clear and plain communication

The notice should help the individual act. It should not resemble a forensic report or a defensive legal statement.

Poor notification language often includes expressions such as:

• “an anomalous cyber event occurred”;

• “a third party may have interacted with certain information”;

• “some data may have been impacted”;

• “we take security seriously”; or

• “there is no evidence of misuse.”

These expressions may obscure what actually happened.

A clear notice should explain, where known:

• what system or activity was compromised;

• what personal data relating to the recipient was affected;

• when the incident occurred;

• what the likely implications are;

• what the organisation has done;

• what the individual should do;

• and whom she may contact.

Technical detail should be translated into practical meaning. Instead of merely saying that an “authentication token was exfiltrated,” the notice should explain whether the token could permit another person to access the user’s account and whether the user’s active sessions have been closed.

1.18 “Without delay”

Rule 7 does not assign a fixed numerical period for individual notification. It requires notice without delay.

The Data Fiduciary may need limited time to:

• confirm that a breach occurred;

• identify affected individuals;

• understand the categories of data;

• contain the incident;

• prevent a misleading communication;

• prepare accurate protective advice;

• and establish a support channel.

But delay must be connected to legitimate operational needs.

Delay is unlikely to be justified merely because the organisation wishes to:

• avoid reputational harm;

• wait for media interest to reduce;

• complete every forensic question;

• obtain approval from multiple business executives;

• prepare a public-relations strategy;

• negotiate with the attacker;

• or avoid customer complaints.

Where immediate protective action is necessary, the communication should be sent as soon as the organisation has enough information to provide useful warning. A later update can supply further detail.

1.19 Required content of the Data Principal notice

1.20 Description of the breach

The notice must describe the nature, extent and timing of the occurrence.

1.21 Nature

“Nature” explains the kind of incident.

The notice may need to state whether the breach involved:

• unauthorised access;

• phishing;

• ransomware;

• misdirected communication;

• accidental publication;

• employee misuse;

• vendor compromise;

• loss of a device;

• alteration of records;

• or loss of access.

The explanation should clarify whether confidentiality, integrity or availability was affected.

1.22 Extent

“Extent” concerns the scope of the breach as relevant to the individual.

It may include:

• categories of personal data;

• systems or services involved;

• duration of exposure;

• whether data was merely accessible or known to be copied;

• whether account credentials were involved;

• and whether any information remained protected through encryption or masking.

The notice should avoid overwhelming the recipient with organisation-wide statistics unless those statistics help her understand the incident.

1.23 Timing

The notice should state, to the best of the Data Fiduciary’s knowledge:

• when the breach occurred;

• the period over which exposure continued;

• when it was detected; or

• where exact timing remains unknown.

If an organisation discovered the breach long after it began, that fact may be significant because it affects the individual’s understanding of possible misuse.

1.24 Illustration: Misdirected employee file

An HR employee emails a spreadsheet containing the salary and bank details of one employee to another employee with a similar name.

The affected person’s notice should explain that:

• the spreadsheet was sent to an unintended internal recipient;

• the information included specified salary and bank details;

• the email was sent at the relevant time;

• the recipient was contacted and instructed to delete it;

• access or forwarding is being investigated;

• and appropriate protective steps are being taken.

Saying only that “some employee information was inadvertently shared” would not provide a fair account.

1.25 Likely consequences relevant to the Data Principal

The notice must explain the consequences relevant to the recipient that are likely to arise from the breach.

This requires an individual-centred assessment. The Data Fiduciary should not limit the analysis to direct financial loss.

Depending on the information involved, likely consequences may include:

• account takeover;

• identity theft;

• fraudulent transactions;

• phishing;

• impersonation;

• unauthorised password resets;

• loss of confidentiality;

• misuse of identity documents;

• discriminatory treatment;

• exposure of medical information;

• reputational consequences;

• physical-security concerns;

• alteration of benefits or account information;

• loss of service;

• or targeting through social engineering.

1.26 Illustration: Password hash exposure

If protected password hashes were exposed, the relevant consequence may be an increased risk of password cracking, particularly where the same password was reused elsewhere.

The notice should not merely state that the data was “hashed.” It should explain whether the account password should be changed and whether reused passwords on other services may also be at risk.

1.27 Illustration: Health record alteration

If a medical record was altered, the principal danger may not be public disclosure. The risk may be that treatment decisions are made using inaccurate information.

The notice should advise the individual to verify the relevant record with the healthcare provider and should explain what steps the provider is taking to restore integrity.

1.28 Avoiding unqualified reassurance

A Data Fiduciary should be cautious when stating that there is “no evidence of misuse.”

That statement may mean:

• the investigation found no misuse; or

• the organisation lacks logs capable of detecting misuse.

The notice should provide the relevant context. Absence of evidence is not always evidence that the information was not accessed or copied.

1.29 Measures implemented or being implemented

The Data Fiduciary must describe measures already implemented and measures still being implemented to mitigate risk.

This may involve:

• disabling compromised accounts;

• forcing password resets;

• revoking active sessions;

• patching vulnerabilities;

• rotating cryptographic keys;

• restricting access;

• removing exposed files;

• restoring accurate records;

• suspending a compromised integration;

• obtaining deletion confirmation from an unintended recipient;

• isolating systems;

• monitoring affected accounts;

• appointing forensic investigators;

• notifying financial institutions;

• or engaging law-enforcement or cybersecurity authorities.

The notice should distinguish completed measures from proposed measures.

It should not overstate remediation. If full containment has not yet been confirmed, the Data Fiduciary should not claim that the incident has been completely resolved.

1.30 Illustration: Cloud exposure

A company discovers that a cloud-storage repository containing customer identity records was available through a public link.

Its intimation may explain that it:

• disabled the public link;

• revoked the relevant credentials;

• restricted the repository to approved accounts;

• began reviewing access logs;

• engaged an external forensic specialist;

• and is implementing additional controls over storage configuration.

This information helps the individual understand whether the exposure is continuing and whether the company is taking meaningful action.

1.31 Safety measures for the Data Principal

The notice must state what the Data Principal may do to protect her interests.

The advice should be tailored to the affected data.

Depending on the breach, appropriate steps may include:

• changing the relevant password;

• avoiding password reuse;

• enabling multifactor authentication;

• reviewing account activity;

• contacting a bank;

• blocking a card;

• monitoring credit or loan activity;

• treating unexpected communications with caution;

• refusing to share OTPs;

• verifying identity-related requests;

• reviewing medical or employment records;

• changing account recovery details;

• downloading and preserving relevant records;

• or contacting the designated support channel.

1.32 Illustration: Payment-card breach

Useful advice may include:

• review recent transactions;

• contact the card issuer;

• block or replace the card if advised;

• ignore calls requesting OTPs or PINs;

• and report unauthorised transactions promptly.

Generic advice to “remain vigilant” is unlikely to be sufficient on its own.

1.33 Illustration: Email-address exposure only

If the breach involved names and email addresses but not credentials or financial information, the notice should not create unnecessary alarm by instructing every person to freeze bank accounts. It should offer proportionate advice, such as caution regarding phishing communications impersonating the organisation.

1.34 Business contact information

The notice must provide business contact information for a person capable of responding on behalf of the Data Fiduciary.

The contact should be functional and adequately supported.

It may be:

• the Data Protection Officer, where applicable;

• a privacy office;

• a designated breach-response contact;

• a dedicated email address;

• a helpline;

• or another authorised person.

The contact mechanism should be able to answer questions such as:

• Was my information involved?

• What data was affected?

• What should I do?

• Has my account been secured?

• Can I obtain further information?

• How do I raise a grievance?

• How do I correct inaccurate information created by the breach?

Providing a general customer-support number whose personnel have no information about the incident may not meaningfully satisfy the requirement.

1.35 Method of communication

Rule 7 permits communication through:

• the Data Principal’s user account; or

• any communication method registered by her with the Data Fiduciary.

This may include:

• in-app notification;

• account inbox;

• registered email;

• registered mobile number;

• SMS;

• or another registered channel.

1.36 The communication should reasonably reach the individual

A notice hidden within a general privacy-policy update is unlikely to be effective.

The communication should be sufficiently prominent to indicate that it concerns a security incident affecting the recipient’s personal data.

Where the registered channel itself may be compromised, the Data Fiduciary should consider another available registered channel.

1.37 Illustration: Compromised email account

If the breach itself involved takeover of the user’s registered email account, sending the only notice to that account may expose the communication to the attacker. Where available, the Data Fiduciary should consider the user account, registered mobile number or another secure channel.

1.38 Multiple communications may be necessary

Rule 7 does not prohibit staged communication.

A Data Fiduciary may send:

1. an initial notice containing confirmed facts and immediate safety measures;

2. an update where the affected data or consequences materially change; and

3. a closure communication explaining completed remediation where useful.

The initial notice cannot be empty or meaningless. Staging is appropriate where it balances speed with accuracy.

1.39 Intimation to the Board

Rule 7(2) creates a two-stage reporting structure.

1.40 Stage one: initial intimation without delay

The initial Board intimation must provide a description of:

• the nature of the breach;

• its extent;

• its timing;

• its location; and

• its likely impact.

This report should allow the Board to understand the event sufficiently to determine whether urgent intervention may be necessary.

1.41 Nature

The initial report should identify the kind of breach and the systems or processing involved.

1.42 Extent

The Data Fiduciary should provide the best available estimate of:

• number or categories of affected Data Principals;

• volume of records;

• categories of personal data;

• affected systems;

• Processor involvement;

• and whether the incident is continuing.

If the exact number is unknown, the Data Fiduciary should provide a reasonable range or clearly state that the scope is under investigation.

1.43 Timing

The report should explain:

• when the incident began, if known;

• how long it continued;

• when it was detected;

• and when the Data Fiduciary became aware that personal data was affected.

1.44 Location

“Location” may concern the place or environment in which the breach occurred, such as:

• a particular office;

• data centre;

• cloud region;

• Processor facility;

• employee device;

• application;

• database;

• network segment;

• or overseas processing environment.

The purpose is to identify where the compromise occurred and which infrastructure or jurisdiction may be involved. It should not be reduced to the organisation’s registered office address where the incident occurred in a different technical environment.

1.45 Likely impact

The initial report should assess:

• potential consequences for Data Principals;

• effect on confidentiality, integrity and availability;

• critical services affected;

• likelihood of fraud or misuse;

• continuing exposure;

• and operational impact.

The assessment may initially be provisional, provided the Data Fiduciary clearly says so and supplies updates in the detailed report.

1.46 Stage two: detailed report within seventy-two hours

Rule 7(2)(b) requires further information within seventy-two hours of awareness.

This is not a substitute for the immediate Board intimation. A Data Fiduciary should not ordinarily wait until the seventy-second hour and submit one combined report if doing so would defeat the requirement to notify the Board without delay.

The reporting structure is:

• report the core known facts without delay;

• investigate continuously;

• submit updated and detailed information within seventy-two hours.

1.47 Updated and detailed description

The second report should refine the initial understanding of:

• nature;

• extent;

• timing;

• location;

• affected data;

• affected Data Principals;

• systems involved;

• exposure period;

• and likely impact.

It should identify any material difference from the initial report and explain why the understanding changed.

Investigations commonly evolve. An initial report may describe suspected access to one application, while the later report establishes lateral movement into two databases. The Data Fiduciary should explain the development rather than silently replacing the original account.

1.48 Events, circumstances and reasons

The detailed report must describe the broad facts surrounding the event and the reasons leading to the breach.

Relevant facts may include:

• exploitation of a vulnerability;

• phishing;

• weak authentication;

• employee error;

• insider misconduct;

• cloud misconfiguration;

• compromised vendor credentials;

• unsupported software;

• improper access allocation;

• unpatched systems;

• defective code;

• loss of a device;

• failure of a backup;

• or malicious activity by an external actor.

The report should distinguish:

• confirmed root cause;

• contributing factors;

• preliminary hypotheses; and

• matters still under investigation.

The obligation to provide “broad facts” does not necessarily require disclosure of every forensic detail, security secret or protected legal communication. But the report must be candid enough for the Board to understand how the breach occurred and whether systemic failures are involved.

1.49 Mitigation measures

The detailed report must identify measures already implemented or proposed to reduce risk.

This may include:

• containment;

• credential reset;

• key rotation;

• account monitoring;

• card replacement;

• restoring accurate data;

• shutting down compromised services;

• restricting vendor access;

• notifying affected parties;

• and strengthening protection around the affected information.

The Board can then assess whether further urgent measures are necessary under Section 27.

1.50 Findings regarding the person who caused the breach

Rule 7 requires any findings concerning the person who caused the breach.

The term “person” may refer, depending on the facts, to:

• an external attacker;

• employee;

• contractor;

• Processor;

• vendor personnel;

• recipient of a misdirected disclosure;

• or another involved entity.

The Data Fiduciary should avoid unsupported accusations. Where attribution remains uncertain, it should describe:

• the evidence available;

• whether the actor is known or suspected;

• the role or account involved;

• and whether law enforcement or another authority has been engaged.

This requirement does not mean that the Data Fiduciary must conclusively identify an anonymous attacker within seventy-two hours. It must report any findings it has.

1.51 Illustration: Compromised employee account

Logs show that an employee’s credentials were used from an unknown foreign IP address. There is no evidence that the employee knowingly participated.

The report should state that the employee account was compromised and used by an unidentified actor. It should not accuse the employee of causing the breach unless evidence supports that conclusion.

1.52 Measures preventing recurrence

Rule 7 distinguishes risk mitigation from recurrence prevention.

Mitigation limits the effects of the present incident. Recurrence prevention addresses the underlying weakness.

If the breach arose from password-only privileged access, recurrence prevention may require multifactor authentication and privileged-access reform.

If it arose from a publicly exposed cloud repository, recurrence prevention may require:

• secure configuration standards;

• automated scanning;

• approval controls;

• continuous cloud-security monitoring;

• and training.

If it arose through a Processor, recurrence prevention may require:

• contractual enforcement;

• access restriction;

• audit;

• technical remediation;

• replacement of the Processor;

• or stronger oversight.

The Board should be able to tell whether the Data Fiduciary has merely closed the immediate incident or has corrected the condition that made it possible.

1.53 Report on intimations to Data Principals

The detailed Board submission must report on the intimations sent to affected Data Principals.

It should explain:

• number of affected Data Principals identified;

• number notified;

• method of communication;

• time of communication;

• content or template used;

• delivery failures;

• persons not yet reached;

• alternative communication attempts;

• updates issued;

• and support arrangements.

This requirement enables the Board to assess whether the individual-notification duty was discharged in substance rather than merely authorised internally.

1.54 Extension beyond seventy-two hours

The Board may allow a longer period where the Data Fiduciary makes a written request.

The extension is discretionary. The Data Fiduciary should not assume that filing a request automatically suspends the deadline.

A persuasive request should explain:

• why the information cannot reasonably be completed within seventy-two hours;

• which parts are unavailable;

• what investigation is underway;

• steps taken to obtain the information;

• whether a Processor or outside authority controls relevant evidence;

• the additional time requested;

• and the date by which the report will be submitted.

An extension may be appropriate where:

• forensic reconstruction is technically complex;

• a Processor has not yet supplied essential logs;

• several jurisdictions or systems are involved;

• restoration must occur before reliable scope analysis;

• law enforcement has temporarily restricted disclosure of particular information;

• or evidence has been corrupted.

An extension should not ordinarily be sought merely because:

• internal approvals are slow;

• the responsible team was unavailable;

• the organisation lacked a pre-existing response process;

• management wished to avoid disclosure;

• or the Data Fiduciary had not contractually required timely Processor assistance.

Even where additional time is permitted for the detailed report, the initial Board intimation remains due without delay.

1.55 Processor breaches

A breach occurring at a Data Processor can trigger the Data Fiduciary’s Rule 7 obligations.

The Data Fiduciary must therefore require its Processor to provide information necessary to determine:

• whether personal data was affected;

• when the incident occurred;

• when the Processor became aware;

• systems and locations involved;

• Data Principals affected;

• categories of data;

• likely consequences;

• containment measures;

• root cause;

• subprocessors involved;

• attribution findings;

• and recurrence-prevention measures.

1.56 Processor notification is not the statutory substitute

A Processor informing the Board or communicating with affected persons does not automatically discharge the Data Fiduciary’s statutory duty unless the arrangement and communication clearly operate on the Data Fiduciary’s behalf and satisfy Rule 7.

The Data Fiduciary should remain in control of:

• legal assessment;

• accuracy of the notification;

• identification of affected persons;

• communication strategy;

• Board reporting;

• and follow-up.

1.57 Illustration: Payroll vendor breach

A payroll provider suffers ransomware affecting employee names, bank details and salary records for several client companies.

Each employer remains responsible for assessing and fulfilling its obligations as Data Fiduciary in relation to its employees. The payroll provider must supply information promptly, but it should not issue a generic notice that obscures which employer, records and individuals are affected.

1.58 Internal governance and escalation

Rule 7 requires rapid coordination across technical, legal, privacy, operational and communications functions.

A breach process should establish who is responsible for:

• receiving incident reports;

• determining whether personal data is involved;

• preserving evidence;

• recording awareness;

• identifying affected Data Principals;

• drafting individual notices;

• submitting Board reports;

• contacting Processors;

• deciding protective measures;

• dealing with law enforcement;

• monitoring delivery failures;

• and approving updates.

1.59 Employees must know how to report incidents

An employee who sends information to the wrong recipient should report the incident immediately, not attempt to conceal or resolve it privately.

A reporting culture should distinguish prompt error reporting from deliberate misconduct. If employees believe every honest mistake will automatically result in punishment, they may delay reporting, increasing harm and jeopardising compliance.

1.60 Breach assessment record

For each suspected incident, the Data Fiduciary should record:

• date and time of detection;

• reporter;

• facts known;

• systems involved;

• personal data involved;

• assessment of whether a breach occurred;

• date and basis of awareness;

• affected population;

• notifications sent;

• decisions regarding timing;

• mitigation;

• outstanding investigation;

• and final closure.

Where the organisation concludes that an event was not a personal data breach, it should retain the reasoning and evidence supporting that conclusion.

1.61 Relationship with CERT-In reporting

Rule 7 operates in addition to cybersecurity reporting requirements under the Information Technology Act and CERT-In directions.

CERT-In is India’s national agency for cyber incident response and performs functions including collection and analysis of cyber-incident information, emergency response, coordination and issuance of security guidance. Its 28 April 2022 directions prescribe separate cybersecurity reporting and related requirements for covered entities.

A single incident may therefore require communications to:

• affected Data Principals under Rule 7(1);

• the Data Protection Board under Rule 7(2);

• CERT-In;

• a sectoral regulator;

• law enforcement;

• contractual counterparties;

• insurers;

• and internal governance bodies.

These reports differ in purpose, trigger, recipient, content and timing. Reporting to CERT-In does not substitute for notifying the Board, and notifying the Board does not automatically satisfy CERT-In requirements.

The incident-response procedure should maintain an obligation matrix rather than assuming that one general report satisfies every legal framework.

1.62 Law-enforcement considerations

A Data Fiduciary may be investigating an attack with law-enforcement or national cybersecurity authorities. In some cases, an authority may be concerned that public communication could alert an attacker or compromise an active operation.

Rule 7 does not contain an express general law-enforcement exception to the requirement to intimate affected Data Principals without delay. Any delay based on an official request should therefore be approached cautiously and documented precisely.

The Data Fiduciary should record:

• the authority making the request;

• legal basis;

• scope;

• date;

• duration;

• persons covered;

• and whether partial or protective communication remains possible.

A broad informal request to “avoid publicity” should not automatically displace a statutory notification obligation.

1.63 Special categories of breach

1.64 Credential compromise

Where passwords, authentication tokens, recovery questions or session identifiers are affected, the Data Fiduciary should consider:

• forced password reset;

• session termination;

• token revocation;

• multifactor authentication;

• warning against credential reuse;

• monitoring for account takeover;

• and clear explanation of whether actual credentials or protected representations were involved.

1.65 Financial information

Where bank or payment information is affected, the response may require:

• coordination with financial institutions;

• card replacement;

• transaction monitoring;

• fraud alerts;

• protection against OTP scams;

• and rapid individual notification.

1.66 Identity documents

Where passports, Aadhaar-related records, PAN details or other identity information are exposed, the harm may continue for longer than the immediate incident because identifiers are difficult or impossible to change.

The notice should address risks of impersonation, fraudulent onboarding and targeted phishing and provide realistic protective advice.

1.67 Children’s personal data

A breach affecting children requires communication designed for the relevant audience and circumstances. Depending on the processing arrangement, communication may need to reach the parent or lawful guardian.

The Data Fiduciary should account for:

• the child’s age;

• nature of the service;

• likely consequences;

• risk of profiling, manipulation or physical harm;

• who provided the consent;

• and whether the child can independently understand the notice.

1.68 Health information

Health-data exposure can create confidentiality, social, employment, insurance and personal-security consequences. If health records were altered, the Data Fiduciary must also address clinical integrity and corrective verification.

1.69 Location information

A breach involving live or historical location data may create physical-safety concerns. The notice should avoid revealing further sensitive location information and should provide appropriate safety guidance.

1.70 AI-related breach

An AI system may expose personal data through:

• prompts;

• model outputs;

• retrieval from private repositories;

• memorisation;

• insecure connectors;

• training-data access;

• or vendor use of submitted data.

The Data Fiduciary should investigate not only the visible output but also:

• whether other users could reproduce the information;

• what sources the model accessed;

• whether the output was logged;

• whether the vendor retained prompts;

• whether the information entered training pipelines;

• and whether access permissions were bypassed.

1.71 Avoiding common notification failures

1.72 Waiting for complete certainty

Rule 7 anticipates evolving knowledge. The initial Board report and Data Principal notice can be based on the best confirmed information available, followed by updates.

Waiting for a final forensic report may make the notification unlawfully late.

1.73 Using one generic notice for everyone

Different individuals may have different data and consequences. A general notice stating that “customer information may have been affected” may be insufficient where the organisation can identify more specific categories for each person.

Templates may be used, but they should allow meaningful personalisation.

1.74 Overloading the notice with legal language

A notice should not begin with extensive disclaimers or arguments denying liability. The Data Principal needs understandable facts and protective steps.

1.75 Minimising the incident

Expressions such as “minor incident,” “limited event” or “no cause for concern” should be used only where supported by evidence.

1.76 Exaggerating the incident

The Data Fiduciary should also avoid causing unnecessary alarm. Safety advice and consequence descriptions should correspond to the actual data and likely risk.

1.77 Treating a website announcement as individual notification

Rule 7 requires intimation to each affected Data Principal through her user account or registered communication mode. A public website notice alone may not satisfy this requirement.

1.78 Assuming the Processor will handle everything

The Data Fiduciary remains responsible for statutory notification. Processor reporting and assistance must feed into the Data Fiduciary’s compliance process.

1.79 Failing to update

If material facts change, the earlier notice may become misleading. The Data Fiduciary should provide corrections or supplementary information.

1.80 Enforcement consequences

Failure to intimate the Board or an affected Data Principal under Section 8(6) carries a maximum monetary penalty of ₹200 crore under the Schedule.

The Schedule separately provides up to ₹250 crore for failure to take reasonable security safeguards under Section 8(5). The same incident may therefore involve separate findings concerning:

• inadequate security safeguards; and

• inadequate or delayed breach intimation.

The maximum amounts are not automatic. The Board must conduct an inquiry, find a significant breach, provide an opportunity of hearing and apply the factors in Section 33.

In evaluating a notification failure, relevant circumstances may include:

• length of the delay;

• number of affected Data Principals;

• nature of the personal data;

• quality and accuracy of the communication;

• whether the delay prevented protective action;

• whether information was concealed;

• whether the Data Fiduciary cooperated;

• whether the failure was repeated;

• and whether the Data Fiduciary improved its process.

A short delay caused by genuine difficulty in identifying affected persons may be treated differently from a deliberate decision to suppress the incident for reputational reasons.

The Board may also direct urgent remedial or mitigation measures when it receives a breach intimation and may inquire into the breach under Section 27.

1.81 Comprehensive interpretation

Rule 7 establishes a breach-notification model based on five principles.

First, notification begins with awareness, not completion of forensic investigation.

Second, the Rule does not establish a general harm threshold below which a personal data breach may remain unreported. The Board must be informed, and each affected Data Principal must receive the prescribed intimation.

Third, notification is dual-track. The affected individual receives a concise and practical communication, while the Board receives immediate regulatory information followed by a detailed report.

Fourth, the framework is progressive. The Data Fiduciary reports the best information available without delay and submits updated detail within seventy-two hours.

Fifth, notification is part of a larger security process. The Data Fiduciary must contain the breach, investigate it, mitigate consequences, prevent recurrence, preserve evidence and maintain communication with affected persons and the Board.

The practical legal sequence is:

1. identify and escalate the suspected incident;

2. determine whether personal data is affected;

3. record when awareness occurred;

4. contain continuing exposure;

5. identify affected Data Principals;

6. intimate those individuals without delay;

7. intimate the Board without delay;

8. continue the investigation;

9. submit the detailed Board report within seventy-two hours or obtain an extension;

10. update affected persons where material facts change;

11. implement recurrence-prevention measures; and

12. preserve evidence of every decision, communication and remedial step.

Key point

Rule 7 does not permit a Data Fiduciary to remain silent until it knows everything. It requires timely communication based on the best information available, followed by investigation, correction and transparent updating. The central objective is to give affected individuals a genuine opportunity to protect themselves while enabling the Board to supervise the incident, require urgent action and determine whether the Data Fiduciary complied with its statutory obligations.