Reporting to the Board and Your Users

Abstract

This article closes a three part series on breach under the Digital Personal Data Protection Act 2023. The first article covered the six protections Rule 6 requires. The second covered logging, monitoring, and the moment a company becomes aware something has happened. This article covers what a company then has to say, to whom, and by when.

Rule 7 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 inside seventy two hours. Neither duty waits for the other, and neither carries a threshold, so an incident touching a single individual triggers both.

The article sets out the required contents of each message, because Rule 7 is specific about them. It covers how the seventy two hours are counted, since the period runs from awareness and not from confirmation, containment, or the end of the investigation. It deals with the practical difficulty of reaching people whose contact details may be stale or may themselves have been part of what was lost.

It also covers a point that surfaces late in most planning. The seventy two hour clock is rarely the only one running. Organisations covered by the national cyber security directions may owe a report within six hours, and sector regulators impose their own timelines. Mapping which clocks apply to you is a short exercise, and it belongs in the planning stage. The article closes by drawing the three parts of the series together.

1. Two Duties, Not One

1.1 What Rule 7 asks for

Rule 7 splits the obligation cleanly. On becoming aware of a personal data breach, a 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, in concise and clear plain language, and it has to set out how far the breach reached and what it involved, along with when and where it happened. It has to set out the likely consequences for the person. It has to say what the company has done to reduce the harm, and what the person can do to protect themselves. Contact details for somebody who will answer questions complete it.

The Board receives two messages. The first goes without delay and describes the breach, its nature and extent, and when and where it happened. The second follows within seventy two hours of awareness, or longer if the Board allows on written request, and it carries the fuller account. Companies planning for one notification will meet neither duty properly.

1.2 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 notification describes, and they do not decide whether a notification is owed.

Two practical consequences follow. A company cannot maintain a category of minor incidents handled internally, because the Rules provide for no such category. The small everyday incident also becomes reportable, which includes the email sent to the wrong customer, the report shared with a colleague who had no business seeing it, and the file left in a shared folder for a week.

A related question comes up in every planning discussion. Does an internal mistake count 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 it. Whether that requires a notification to the colleague and to the Board is a judgement on the facts, and the safe position is to treat it as reportable and to have decided that in advance instead of in the moment.

Which 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 lies in preparing a process able to handle small incidents quickly and correctly, so that the routine case takes an hour and the serious one gets the attention it needs.

2. What the Affected Person Has to Be Told

2.1 Writing for the person, not the file

Rule 7 asks for concise, clear, 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 complied, however defensible each sentence is.

What the reader needs is direct. What happened. Which of their information was involved. What could happen to them because of it. What the company has done. What they should do now. Who to contact. Six answers, in that order, in the words an ordinary person uses.

Timing inside the notice matters too. Rule 7 asks for the timing and location of the breach, so a notice should say when the exposure began and when it ended, along with the system involved. Readers use those dates. Somebody who can see that the window covers a period when they made a purchase understands their position, and somebody outside the window is reassured without needing to write in.

Vagueness is the common failure and it does more harm than the honesty it avoids. A notice saying that some user information may have been accessed leaves every recipient guessing and prompts a wave of enquiries the company then has to handle. A notice saying that a person’s name, email address, and delivery address were in the affected records, while payment details were not, tells them what to do and reduces the volume of questions.

2.2 The parts companies get wrong

Likely consequences need stating specifically. A breach of email addresses raises the prospect of targeted phishing, so the notice should say so. A breach of identity documents raises the prospect of impersonation, and a breach of payment details raises fraud. Naming the consequence lets the reader judge how much attention to give, and a generic warning about potential risks gives them nothing.

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 instead of a considered assessment. Where nothing useful can be done, say so honestly instead of inventing advice.

Contact details need to reach a person who knows about the incident. A notice pointing to a general support address staffed by people who have not been briefed produces a poor experience at the worst moment, and complaints from that experience 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.

2.3 Sending it, and proving you sent it

Notification goes to each affected person, which raises a difficulty the Rules do not solve. Contact details may be stale. 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 a company holds, in the order most likely to reach somebody, and records each attempt. Where a channel fails, the record shows that. Where a company genuinely cannot reach a group of people, a public notice on its website and app covers those it could not contact directly, and the record explains the reasoning. What matters here is a company able to show what it attempted for each individual.

That record supports the report to the Board, because Rule 7 requires the detailed report to include an account of 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.

3. What the Board Receives

3.1 The immediate message

The first message to the Board goes without delay on becoming aware. It describes the breach, its nature and extent, and when and where it happened. Nothing in that list requires a completed investigation, and the Rules provide for two messages precisely for that reason.

Companies delay this message for a reason that feels sound and is mistaken. 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. Sending an honest early account labelled as preliminary satisfies the duty and starts the relationship on the right footing.

Practically this means a short template prepared in advance, with the facts filled in when needed. Preparing that template while nothing is happening takes twenty minutes. Drafting it during an incident, with a legal review, while the technical team is still working, takes hours the company does not have.

3.2 The detailed report within seventy two 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 what happened, including the events, circumstances, and reasons leading to it. The measures the company implemented to reduce the harm. Its findings about the person who caused the breach. The remedial measures taken to prevent a recurrence. A report of the intimations given to affected individuals completes it.

Two of those items ask for more than the technical account. Findings about the person who caused the breach require the company to have investigated attribution, which for an external attack may be limited to what the evidence supports and for an internal act may name a role or an individual. Where the evidence does not establish who was responsible, saying so plainly and describing what was examined is the honest answer.

The remedial measures item asks what the company has changed. A report describing an incident with no accompanying change reads poorly, and the Board is entitled to ask why the same thing will not happen again. Here the first article in this series connects directly. A company that already had the Rule 6 measures in place can describe a specific gap and a specific fix. One without them faces a broader question about its whole posture.

3.3 Where the second article does the work

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

A company with a year of properly 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 two positions a company is in was settled earlier, by whoever set the logging retention.

Which is why the order of this series follows the order of the work. Protection first, because it prevents. Detection second, because it determines what you can establish. Reporting last, because it can only describe what the first two made visible.

4. How the Seventy Two Hours Are Counted

4.1 From awareness, not from certainty

The period runs from the moment the fiduciary becomes aware of the breach. Not from confirmation. Not from containment. Not from the end of the investigation, and not from the point at which the company finished deciding whether the incident qualified.

The second article in this series argued for recording that moment deliberately, and the reason lands here. A company able to state when it became aware, supported by a contemporaneous record, 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 contemporaneous record.

The clock also runs continuously. Seventy two hours from Friday evening expires on Monday evening, and no provision pauses it for weekends or public holidays. Any response plan that depends on people being at work has a gap covering roughly a third of the calendar, and Indian festival periods extend that gap further.

4.2 Using the window well

Seventy two hours sounds generous until the work is laid out. An incident needs scoping, so somebody has to establish which systems and which records were involved. Affected individuals have to be identified, which means resolving records to people. Two documents have to be drafted and reviewed. Notices have to be sent and recorded. The support function has to be briefed. Meanwhile the technical team is still containing the problem.

Running these in sequence exhausts the window. Running them in parallel, with different people on each, fits inside it comfortably. Which requires knowing in advance who does what, and that allocation is the single most useful thing to settle before an incident. Names against roles. The technical lead, the person drafting the Board report, the person handling individual notifications, the person briefing support, the person who signs off.

One task inside the window deserves separate mention because it takes longer than teams expect. Identifying the affected individuals means going from a set of exposed records to a list of people with contact details, and companies whose customer data sits across several systems find that resolution slow. A company that has already built identity resolution 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 permits a longer period where the Board allows it on written request. Worth knowing, and unwise to rely on. A request itself takes drafting and a reason, and a company that asks for more time because it had no plan is describing its own failure to the regulator it is asking a favour of.

5. The Other Clocks Running at the Same Time

5.1 Six hours, not seventy two

Companies focused on the seventy two hour figure sometimes miss a shorter one. The directions issued by the national computer emergency response team require certain cyber security incidents to be reported within six hours of noticing them, and that obligation applies to a wide range of organisations independently of the DPDP Act.

A single event can therefore trigger both. A ransomware attack on a company holding personal data is a reportable cyber security incident within six hours and a personal data breach reportable to the Board without delay, with a detailed report inside seventy two 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, which means the format has to be known, the account holder has to be identified, and somebody has to be reachable at any hour. An organisation that learns of this obligation during its first incident will report outside the six hours.

5.2 Mapping your own obligations

Sector regulators add further duties. Banks, insurers, payment operators, and listed companies each face reporting requirements from their own regulator, 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 functions to produce it. Very few have produced it, and the absence 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 frequently require notification of a security incident within a fixed period, often twenty four or forty eight hours, and those terms sit in agreements signed years earlier by people who have since moved on. A company can meet every regulatory deadline and still breach a customer contract, which affects a commercial relationship during an incident.

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. Building the plan around the seventy two hour figure and discovering the six hour duty later leaves a company in breach of the shorter obligation before it has finished reading its own procedure.

6. Bringing the Series Together

6.1 Three pieces of one obligation

This series has covered breach under the Act in the order the work has to happen. The first article took the six measures in Rule 6 and set out what each asks of a real system. Choosing a protection technique for each category in the inventory. Narrowing every route into the data, including the direct and machine routes teams forget. Recording activity and watching it. Keeping the ability to carry on when data disappears, which comes down to restores somebody has tried. Holding those records for twelve months. Pushing the same duties down to vendors, with quick notice from them written into the agreement.

The second article took logging further, because it is the measure that cannot be added late. It set out how far the statutory definition reaches, taking in data destroyed or altered as well as data seen. It described the fields a record needs to answer a question later, the reason behind the twelve month figure, and why stored records find nothing on their own. It also dealt with the point at which a company starts to know, which begins every deadline in this article and belongs in writing at the first credible sign.

This third article dealt with what a company says. Two duties under Rule 7, one to every affected person and one to the Board. Six things the individual needs told in plain language. An immediate account to the Board followed by a detailed report within seventy two 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. Then the other clocks, including a six hour duty that reaches many of the same companies.

6.2 What a prepared company looks like

Put together, preparedness here is unglamorous and specific. The The protections are built and the reasoning behind each is written down. Records exist for every route to the data, tied to named people, timed off a common clock, held where the system they describe cannot erase them, and kept twelve months. Rules watch for what would be unusual in this particular business, and what they raise reaches somebody who answers a 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. A single page lists every reporting obligation with its trigger, recipient and deadline. Support staff know they will be briefed. The whole chain has been walked through at least once against a plausible scenario, where companies find the archived alert channel and the retention setting nobody changed.

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

Conclusion

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 who to contact. The Board is told twice. First an immediate description of the breach, then a detailed report inside seventy two hours covering the facts and circumstances, the mitigation, the findings on who caused it, the remedial measures, and an account of the notices sent to individuals. Neither duty carries a threshold, so a single affected individual brings both into play.

The seventy two hours run from awareness, not from confirmation or containment, and they run through weekends. Fitting the work inside them means running scoping, drafting, notification and briefing in parallel, which in turn means naming who does each in advance. A shorter clock reaches many organisations as well, since the national cyber security directions require certain incidents to be reported within six hours, and a plan built around seventy two will miss it. The three articles in this series 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.