Reporting to the Board and your users

Overview

Breach under the Digital Personal Data Protection Act, 2023 runs in three stages: the security safeguards Rule 6 requires, the logging, monitoring and awareness that tell a company something has happened, and then what the company has to say, to whom, and by when.

Rule 7 of the DPDP Rules creates two separate duties, and treating them as one causes trouble. Every affected person has to be told, in plain language, what happened and what they can do about it. The Data Protection Board has to be told as well, first with an immediate account and then with a detailed report within 72 hours. Neither duty waits for the other, and neither carries a threshold, so an incident touching a single individual triggers both.

Rule 7 is specific about what each message must contain. The 72 hours run from awareness, well before confirmation, containment or the end of the investigation. Reaching people is its own practical difficulty, because contact details may be out of date, or may themselves have been part of what was lost.

One point surfaces late in most planning: the 72 hour clock is rarely the only one running. Organisations covered by CERT-In's directions may owe a report within six hours, and sector regulators have their own timelines. Mapping which clocks apply to you is a short exercise, and it belongs in the planning stage. This is a practical reading of the Rules and does not constitute legal advice.

Two duties, three messages

What Rule 7 asks for

Rule 7 splits the obligation cleanly. On becoming aware of a personal data breach, a Data Fiduciary has to tell each affected Data Principal, and it has to tell the Board. Those are different messages, written for different readers, with different contents and different timing.

The message to individuals goes without delay, through the person's user account or a mode of communication they have registered with you. It has to be concise, clear and plain, and it has to cover:

• a description of the breach, including its nature, extent, timing and location;
• the consequences relevant to the person that are likely to arise from it;
• what the company has done, and is doing, to reduce the risk;
• the safety measures the person can take to protect their interests;
• business contact details of a person able to answer their questions.

The Board receives two messages. The first goes without delay and describes the breach, including its nature, extent, timing and location, and its likely impact. The second follows within 72 hours of becoming aware, or a longer period if the Board allows it on a written request, and it carries the fuller account. So there are three messages in all, each with its own reader and its own job. Companies planning for a single notification will meet none of the duties properly.

The penalty for failing to notify the Board or affected people can reach ₹200 crore. That sits alongside the separate penalty of up to ₹250 crore for failing to take reasonable security safeguards in the first place. The DPDP Rules, 2025 were notified on 13 November 2025, and the breach duties commence eighteen months later, around 13 May 2027; check for later amendments. Getting ready for them takes much of that time.

No threshold, and why that matters here

Rule 7 sets no floor of scale or severity. One affected individual triggers the full obligation, exactly as a hundred thousand would. Likely consequences form part of what the notice describes, and they play no part in deciding whether a notice is owed.

Two practical consequences follow. A company cannot keep a category of minor incidents handled quietly inside the business, because the Rules provide for no such category. And the small everyday incident becomes reportable: the email sent to the wrong customer, the report shared with a colleague who had no business seeing it, the file left in a shared folder for a week.

A related question comes up in every planning discussion: whether an internal mistake counts if the data never left the company. Somebody in accounts opening a colleague's salary record without cause has processed personal data without authority, and the definition covers that. Whether it needs a notice to the colleague and to the Board is a judgement on the facts. The safe position is to treat it as reportable, and to have decided that in advance, calmly, before any particular case arises.

That makes the volume question real. Companies that have never counted these events are often surprised by how many occur in a year, and each one now carries notification duties. The answer is a process that handles small incidents quickly and correctly, so that the routine case takes an hour and the serious one gets the attention it needs.

What affected people need to hear

Write for the person reading it

Rule 7 asks for concise, clear and plain language, and that instruction rules out most of what companies instinctively write in this situation. Legal review tends to produce careful phrasing designed to limit admissions, and careful phrasing usually fails the plain language test. A notice that leaves the reader unsure whether their own data was involved has not done its job, however defensible each sentence may be.

What the reader needs is direct. A good notice answers six questions, in this order, in the words an ordinary person uses:

• What happened, and when did it start and stop?
• Which of my information was involved?
• What could happen to me because of it?
• What has the company done about it?
• What should I do now?
• Who can I speak to?

Dates matter more than teams expect. Rule 7 asks for the timing and location of the breach, so a notice should say when the exposure began and ended and which system was involved. Readers use those dates. A customer of a D2C brand who sees that the exposure ran from 2 to 9 March knows whether the order placed on 5 March is in scope. Someone who ordered later is reassured without needing to call.

Vagueness is the common failure, and it does more harm than the honesty it avoids. "Some user information may have been accessed" leaves every reader guessing and floods the support team with calls. "Your name, phone number and delivery address were in the affected records. Your payment details were not" tells people where they stand, and fewer of them need to write in.

Language matters too. Write the notice in the language the person uses with you. A customer who always deals with you in Marathi or Gujarati should not receive their breach notice only in English, and the plain language test is hard to meet in a language the reader does not read comfortably.

The parts companies get wrong

Likely consequences need stating specifically. Leaked phone numbers raise the risk of fraud calls pretending to be from your company, so say that you will never ask for an OTP on a call. Leaked email addresses raise the risk of targeted phishing. Leaked identity documents raise the risk of impersonation, such as somebody opening a loan in the customer's name. Leaked payment details raise the risk of fraud. Naming the consequence lets the reader judge how much attention to give it. A generic warning about potential risks gives them nothing to act on.

The advice on protective steps has to match what was actually lost. Telling somebody to change their password makes sense where credentials were involved, and looks careless where the loss was a delivery address, because it signals a template. Where there is nothing useful the person can do, say so plainly and avoid inventing advice.

The contact in the notice needs to reach a person who knows about the incident. A notice pointing to a general support inbox staffed by agents who have not been briefed creates a poor experience at the worst moment, and complaints from that experience tend to reach the Board. Briefing the support team before the notice goes out, with a short account of what happened and what they may say, is part of the notification work.

Sending it, and proving you did

Notice goes to each affected person, which raises a difficulty the Rules do not solve. Contact details may be out of date. They may have been the very data that was lost or destroyed. Some people may have no reachable channel at all.

A defensible approach uses the channels the company holds, in the order most likely to reach the person: the user account or app, SMS, email, WhatsApp where the person has opted in. Record each attempt and its result. Where a channel fails, the record shows that. Where you genuinely cannot reach a group of people, a clear notice on your website and in your app helps them, though the Rules do not offer it as a substitute for direct notice, so your record should explain what you tried and why it failed. What matters is that the company can show what it attempted for each individual.

That record feeds straight into the report to the Board, because Rule 7 requires the detailed report to include a report on the intimations given to affected Data Principals. A company that sent notices without recording the sending has to describe that work from memory, in a document filed with the regulator.

What the Board receives

The first message

The first message to the Board goes without delay on becoming aware. It describes the breach, its nature, extent, timing and location, and its likely impact. Nothing in that list needs a finished investigation, and that is exactly why the Rules provide for two messages.

Companies often delay this message for a reason that feels sound. They want to know what happened before telling the regulator anything. The Rules ask for a description of the breach as currently understood, and the second report exists precisely because understanding develops. An honest early account, clearly labelled as preliminary, meets the duty and starts the relationship with the Board on the right footing.

In practice this means a short template prepared in advance, with the facts filled in when needed. Preparing it while nothing is happening takes twenty minutes. Drafting it from scratch during an incident, with legal review, while the technical team is still containing the problem, takes hours you will not have.

The detailed report within 72 hours

The second report carries the substance, and Rule 7 lists what it contains:

• updated and detailed information about the breach;
• the broad facts of the events, circumstances and reasons that led to it;
• the measures implemented or proposed to reduce the risk;
• any findings about the person who caused the breach;
• the remedial measures taken to prevent it happening again;
• a report on the intimations given to affected Data Principals.

Two of these ask for more than a technical summary. Findings about who caused the breach need an investigation into attribution. For an outside attack, that may be limited to what the evidence supports. For an insider, it may point to a role or an individual. Where the evidence does not establish who was responsible, the honest answer is to say so and describe what was examined.

The remedial measures item asks what the company has changed. A report describing an incident with no change attached reads poorly, and the Board is entitled to ask why the same thing will not happen again. Here the Rule 6 safeguards connect directly. A company with the Rule 6 safeguards already in place can describe one specific gap and one specific fix. A company without them faces a much wider question about its whole security posture.

Where your records do the work

Every item in the detailed report draws on records. The nature and extent of the breach come from logs. The timing comes from timestamps. The circumstances and reasons come from tracing activity across systems. Findings about who caused it come from access records tied to a named identity.

A company with a year of well formed logs writes this report from evidence. A company without them writes what it believes happened, in a document filed with the regulator. Which of those positions you are in was decided long before the incident, by whoever set your log retention.

That is also why the work runs in this order. Protection comes first, because it prevents. Detection comes second, because it decides what you can establish. Reporting comes last, because it can only describe what the first two made visible.

How the 72 hours are counted

From awareness

The period runs from the moment the Data Fiduciary becomes aware of the breach. Confirmation, containment, the end of the investigation and the point at which somebody finished deciding whether the incident really counted all come later, and none of them starts the clock.

This is where a deliberate record of the moment of awareness pays off. A company able to state when it became aware, supported by a record made at the time, controls the timeline. One reconstructing the moment afterwards is arguing about the fact everything else depends on, and a reconstruction carries less weight than a record made at the time.

The clock also runs straight through weekends and holidays. Seventy two hours from Friday evening ends on Monday evening, and nothing in the Rules pauses it. A response plan that depends on people being at their desks has a gap covering roughly a third of the calendar, and a long weekend around Diwali, Holi or Pongal makes it wider.

Running the work in parallel

Seventy two hours sounds generous until the work is laid out. Somebody has to establish which systems and records were involved. Affected people have to be identified, which means turning record IDs into names and contact details. Two documents have to be drafted and approved. Notices have to be sent and their delivery recorded. Customer support has to be briefed. All of this happens while the technical team is still containing the incident.

Done one after another, these tasks use up the window. Done in parallel, with a different owner for each, they fit comfortably. That requires knowing in advance who does what, and settling that allocation is the single most useful thing to do before an incident. A workable split for a mid-sized company might be:

• incident lead: owns the timeline, the awareness record and the decisions;
• technical lead: containment, scope and evidence;
• privacy lead: the notices to people and the messages to the Board;
• customer support lead: briefing, scripts and handling enquiries;
• an approver at leadership level, available at short notice.

Write the names down, with deputies, and test them in a tabletop exercise.

One task inside the window takes longer than teams expect. Identifying the affected people means going from a set of exposed records to a list of individuals with contact details. Companies whose customer data sits across several systems, say a loan management system, a CRM and a collections tool, find that slow. A company that has already built identity matching for its rights requests can produce the list in hours. One that has not assembles it by hand while the clock runs.

An extension is available. Rule 7 allows a longer period where the Board permits it on a written request. It is worth knowing about and unwise to rely on. The request itself takes drafting and a reason, and a company asking for more time because it had no plan is describing its own failure to the regulator it is asking a favour of.

The other clocks running at the same time

Six hours under CERT-In

Companies focused on the 72 hour figure sometimes miss a shorter one. CERT-In's directions of April 2022, issued under the Information Technology Act, require specified cyber security incidents to be reported to CERT-In within six hours of noticing them or being told about them. That duty applies to a wide range of organisations, separately from the DPDP Act.

A single event can therefore trigger both. A ransomware attack on a company holding personal data may be a cyber security incident reportable to CERT-In within six hours and a personal data breach to be notified to the Board without delay, with a detailed report within 72 hours. The two regimes have different recipients, different formats and very different timelines.

Six hours changes the shape of a response. Nothing careful happens in six hours without preparation. The format has to be known, the person who files it has to be named, and somebody has to be reachable at any hour. An organisation that learns of this duty during its first incident will report late.

Mapping your own obligations

Sector regulators add further duties. Banks, NBFCs, insurers, payment operators and listed companies each face reporting requirements from the RBI, IRDAI or SEBI, with their own definitions and periods. Companies serving customers abroad may owe notification under other data protection laws as well, on timelines that do not match India's.

The exercise worth completing is a single page listing every reporting obligation that could apply, with the trigger, the recipient, the deadline and the format for each. Most organisations need an hour with their legal and compliance teams to produce it. Very few have done so, and the gap only becomes visible during an incident, when somebody asks who else needs to be told and nobody has an answer.

Contractual duties belong on the same page. Enterprise customers often require notice of a security incident within a fixed period, frequently 24 or 48 hours, and those terms sit in agreements signed years ago by people who have since moved on. A company can meet every regulatory deadline and still breach a customer contract, which damages a commercial relationship at the worst moment.

That page then drives the response plan. Where the shortest clock is six hours, the plan is built around six hours, and the longer duties follow inside a window already under control. One investigation should feed every notice, so the facts stay consistent across them. A plan built around 72 hours that discovers the six hour duty later leaves the company in breach of the shorter obligation before it has finished reading its own procedure.

Bringing the three stages together

Three pieces of one obligation

Breach under the Act is one obligation in three stages, in the order the work has to happen. The first stage is the measures in Rule 6, each of which asks something specific of a real system. Choose a protection technique for each category of data in the inventory. Narrow every route into the data, including the direct and machine routes teams forget. Record activity and watch it. Keep the ability to carry on when data disappears, which comes down to restores somebody has actually tried. Hold the logs for a year. Push the same duties down to vendors, with quick notice from them written into the contract.

The second stage is detection, built on logging, because it is the measure that cannot be added late. The definition of a breach takes in data destroyed or altered as well as data seen. A record needs the right fields to answer questions later, the one year figure exists because intrusions surface late, and stored records find nothing on their own. The moment a company starts to know begins every reporting deadline and belongs in writing at the first credible sign.

The third stage is what a company says. Two duties under Rule 7, one to every affected person and one to the Board. Six things the individual needs to be told in plain language. An immediate account to the Board, followed by a detailed report within 72 hours covering the facts, the circumstances, the mitigation, the findings on attribution, the remedial measures and an account of the notices sent. A clock that runs from awareness and through weekends. And the other clocks, including a six hour duty that reaches many of the same companies.

What a prepared company looks like

Put together, preparedness here is unglamorous and specific. The protections are built, and the reasoning behind each is written down. Logs exist for every route to the data, tied to named people, timed from a common clock, held where the system they describe cannot erase them, and kept for a year. Rules watch for what would be unusual in this particular business, and what they raise reaches somebody who answers the phone at night.

Templates for both Board messages and the individual notice are drafted and legally reviewed while nothing is happening. Roles are assigned by name, with deputies. A single page lists every reporting obligation with its trigger, recipient and deadline. Contact data is current enough to reach people. Every processor contract carries a notice term. Support staff know they will be briefed. The whole chain has been walked through at least once against a plausible scenario, which is where companies find the archived alert channel and the retention setting nobody changed.

None of that prevents an incident. It decides whether a company reports accurately within its deadlines and can describe a specific fix, or files a document saying it cannot establish what happened. The work behind the first position is inexpensive, and it has to be done in advance.

Key points

Rule 7 creates two duties. Every affected person is told, without delay and in plain language, what happened, which of their information was involved, what could follow for them, what the company has done, what they can do and whom to contact. The Board is told twice: first with an immediate description of the breach, then with a detailed report within 72 hours covering the facts and circumstances, the mitigation, the findings on who caused it, the remedial measures and an account of the notices sent. Neither duty carries a threshold, so a single affected person brings both into play.

The 72 hours run from awareness, and they run through weekends. Fitting the work inside them means running scoping, drafting, notification and briefing in parallel, which means naming who does each in advance. A shorter clock reaches many organisations too, since CERT-In's directions require specified incidents to be reported within six hours, and a plan built around 72 hours will miss it. The three stages follow the order of the work for a reason. Protection prevents the breach, detection decides what you can establish about it, and reporting can only describe what the first two made visible.

For the duties in brief, see our guide to breach notification.