Coordinating a breach from detection to closure

A Tuesday evening at an edtech company

A support agent at an edtech platform in Bengaluru gets a call from a parent at 7.40 in the evening. The parent has found her daughter's term report, with marks, school name and the parent's phone number, by searching the child's name online. The agent posts in the engineering group. By 9 pm an engineer finds a storage bucket of report PDFs that was made public during a migration two weeks earlier. By midnight the security lead knows the bucket held about 18,000 files.

The next morning four people are working at once. Security is scoping. An engineer is reading access logs. Legal is asking whether this has to be reported. The head of customer support is drafting something for parents. Each is keeping their own notes, and each has a slightly different version of what happened.

A breach response works when those versions are kept as one record.

What the Act requires when a breach happens

Two notifications on one clock

The DPDP Act treats any unauthorised processing, disclosure or loss of access to personal data as a personal data breach. Under the Act and Rule 7 of the DPDP Rules, a breach creates two separate duties. Every affected Data Principal has to be told, without delay and in clear and plain language, what happened and what it may mean for them. The Data Protection Board has to be told as well, first without delay with a description of the breach, and then with a detailed report within 72 hours of becoming aware, or longer if the Board allows it on a written request.

Both duties run from the same moment: the point at which the organisation became aware. Neither waits for the other, and neither waits for the investigation to finish.

The Act sets no threshold of scale or severity. A breach affecting one person carries the same duties as one affecting a hundred thousand, so the small everyday incident is reportable alongside the serious one. An email sent to the wrong customer falls inside it.

These duties apply from around 13 May 2027 as notified, unless amended. The Schedule to the Act allows penalties of up to 200 crore rupees for failing to notify a breach, and up to 250 crore rupees for failing to take reasonable security safeguards. The Board decides the actual amount based on the nature, gravity and duration of the failure.

A short clock, two audiences and no threshold together make breach response a coordination problem before it is a technical one. Several people work in parallel under time pressure, and the quality of the outcome depends on whether they are working from the same account of events.

What the detailed report has to contain

The report to the Board within 72 hours covers the broad facts of what happened, the circumstances and reasons that led to it, the measures taken to reduce harm, any findings about the person who caused the breach, the remedial steps taken to prevent a recurrence, and an account of the messages sent to affected people.

Every one of those items draws on records. The nature and extent of the breach come from logs. The timing comes from timestamps. The circumstances come from tracing what happened across systems. Findings about who caused it come from access records that name a specific identity. Rule 6 expects logs and related data to be kept for at least one year, and a breach is usually when you find out whether yours were.

An organisation with those records writes the report from evidence. One without them writes what it believes happened, in a document that goes to a regulator and stays there.

The account of messages sent is the item organisations most often struggle with. It requires knowing exactly who was told, through which channel, on what date, and what the message said. That information exists only if somebody recorded it while the messages were going out.

Recording the incident as facts emerge

The moment of awareness

Every deadline counts from when the organisation became aware, so that moment has to be recorded deliberately. In TrustOS, opening an incident captures the time it was raised. You can then state when you became aware and support the statement.

The alternative is rebuilding the moment afterwards from chat histories and memory. A reconstruction carries less weight than a record made at the time, and it also tends to be less favourable, because the earliest sign of trouble is usually earlier than anyone later remembers.

Awareness belongs to the organisation as a whole. In the edtech example it began at 7.40 pm, when the parent called, and the security lead's confirmation of scope the next morning came well after. A support agent hearing a complaint starts the clock. So does a monitoring alert firing into a channel somebody should have been watching.

The practical answer is a quick route by which anybody who sees something can record it, and a named person who receives it. TrustOS holds that intake, and the record it creates carries the timestamp that governs everything afterwards.

Facts arriving in pieces

Nobody understands an incident in the first hour. The first hour gives a suspicion. The first evening gives a rough scope. By the next day somebody knows which systems were reached, and over the following day the extent of what was exposed becomes clearer.

That pattern is why a shared record matters, because several people are establishing different pieces at the same time. Security is scoping. Technology is checking logs. Legal is assessing whether the incident is reportable. Communications is drafting.

When each of them keeps separate notes, the picture splits apart, and somebody has to stitch it together before anything can be sent. When they all write into one incident record, the current understanding is visible to everyone and the stitching has already been done.

TrustOS records each fact as it is established, with the time it was added. That history matters later. When someone asks why the first message to the Board said 12,000 files and the report said 18,000, the record shows what was known at each point.

Working out who was affected

Notifying each affected person requires knowing who they are, and that step takes longer than most organisations expect. What you need is a list of people with contact details, and what the incident gives you is a set of exposed records. Turning 18,000 PDFs into a list of students and parents means matching records to individuals across systems.

An organisation that has already built identity matching for its rights requests can produce that list in hours. One that has not will be assembling it by hand while the clock runs, using up the time that drafting and sending needed.

TrustOS holds the affected people against the incident, so the notification work proceeds from a list. Where the list is still being confirmed, the record shows that clearly, which keeps an early message from going to a group that later turns out to be wrong.

Notifying the people affected

What the message has to say

The Rules ask for concise, clear and plain language, and they set out the content: the nature and extent of the breach, its timing and location, the likely consequences for the person, what you have done to reduce harm, what they can do to protect themselves, and contact details for somebody who will answer their questions.

Writing that plainly rules out much of what organisations instinctively produce in this situation. Careful legal wording designed to avoid admitting anything usually fails the plain language test. A notice that leaves the reader unsure whether their own data was involved has failed, however defensible each sentence is.

Being specific helps both sides. Compare two messages:

• "Some user information may have been accessed."
• "Your child's term report, including marks and school name, and your phone number were visible online between 2 and 16 September. Payment details and passwords were unaffected."

The first leaves every parent guessing and produces a wave of calls. The second tells the parent what happened and what they need not worry about, and it cuts the number of follow-up questions considerably.

The advice on protective steps has to match what was actually lost. Telling people to change their password makes sense when credentials were involved. When the loss was a term report or a delivery address, the same advice looks careless and signals a template.

Where the data belongs to children, parents or guardians are the people who need to hear from you and act.

Sending, recording and proving

Notification goes to each affected person, which raises a difficulty the Rules leave open. Contact details may be out of date, and in some incidents the contact details were part of what was lost.

A defensible approach uses the channels you hold, in the order most likely to reach people, and records each attempt with its outcome. Where you genuinely cannot reach a group directly, a public notice may cover them, with your reasoning written down.

TrustOS records each message against the person and the incident, with the channel, the date and the message version. That record supports the account of messages the Board report needs, and it answers a complainant who says they were never told.

Briefing the people who will handle the replies belongs in the same sequence. A notice that points to a support line staffed by people who have not been told what happened produces a poor experience at the worst moment, and complaints from that experience tend to reach the Board.

Reporting to the Board

The first intimation

The first message to the Board goes without delay. It describes the breach as you currently understand it: its nature, extent, timing and location. Nothing in that list requires a finished investigation, and the Rules provide for two steps for exactly that reason.

Organisations often delay this for a reason that feels sound and works against them. They want to know what happened before telling the regulator anything. The Rules ask only for a description of the breach as currently understood, and an accurate early account marked as preliminary meets the duty.

TrustOS holds a template for that message, so the facts can be pulled from the incident record. Preparing the template on a quiet day takes very little time. Writing it from scratch at 2 am, with legal review, while the technical team is still working, takes hours you do not have.

The 72 hour report

The detailed report draws on the incident record built over the preceding days: the facts as established, the circumstances, the steps taken to reduce harm, the findings on who caused it, the remedial measures and the account of messages sent.

Two of those items need more than a technical description. On who caused the breach, say what the evidence supports. For an outside attack that may be limited. If the evidence does not identify anyone, say so plainly and describe what you examined.

The remedial measures item asks what you have 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. TrustOS holds the remediation actions against the incident, so the report can name specific work with owners and dates.

Where you need longer, the Rules allow the Board to extend the period on a written request. It helps to know that provision exists. Relying on it is unwise, because a request for more time made because there was no plan describes your own failure to the regulator you are asking.

Remediation and closure

Turning findings into assigned work

An incident produces findings, and findings that stay in a report change nothing. TrustOS turns each one into an assigned action with an owner and a due date, held against the incident so the link between cause and fix stays visible.

Those actions vary in size. Some are configuration changes finished the same week, such as locking down the storage bucket and adding a check to the migration script. Some are access reviews across several systems. Some are architectural work spanning months. Recording them at their real size, with realistic dates, is more useful than marking them all as immediate.

The incident stays open while remediation is outstanding, and that is a deliberate choice. Organisations that close an incident once the messages go out lose the link between the breach and the work it caused. The work then competes with everything else for attention, with nothing to show why it was urgent.

What a closed incident leaves behind

A closed incident in TrustOS holds the whole sequence: when you became aware and how, the facts as they were established and when each was added, which people were affected and how the list was drawn up, what each of them was told and through which channel on what date, what went to the Board and when, and the findings, the remediation actions, their owners and their completion.

That record serves several later readers. An internal review asking whether the response worked. The Board following up. An enterprise customer asking in a security review whether you have had incidents and how you handled them. Counsel assessing exposure.

It also serves the next incident. An organisation that can see how its last three incidents were handled knows where its own response is slow. If notification always takes two days because identifying affected people is manual, that is a fixable problem, and it only becomes visible across incidents.

The other clocks and preparing in advance

Reporting duties beyond the Act

Teams focused on the 72 hour figure sometimes miss a shorter one. The CERT-In directions issued in 2022 require specified cyber security incidents to be reported within six hours of noticing them, and that duty applies to a wide range of organisations independently of the DPDP Act.

A single ransomware event can therefore trigger both, with different recipients, different formats and very different timelines. Sector regulators add their own duties, and enterprise customer contracts often promise notice within a fixed period that may be shorter than any regulatory one.

A single page listing every reporting obligation that could apply, with its trigger, recipient, deadline and format, takes about an hour with legal and compliance to produce. Very few organisations have one, and the gap shows during an incident when somebody asks who else needs to be told.

TrustOS holds those obligations against incident types, so the response plan works from the shortest clock, whichever one the team happens to know best.

Rehearsing before it matters

You can test breach response without waiting for a breach. Take a plausible scenario, walk it through the systems and the people, and note where it stalls.

Organisations running this for the first time usually find two or three breaks in the chain, and they are almost always mundane. An alert going to a channel that was archived. No way to reach the security lead at night. Identity matching that takes two days. A notification template nobody has written.

Each of those is a small fix found in an afternoon, and each would have cost days during a real incident. Repeating the exercise twice a year keeps them fixed, because systems change and a response plan quietly stops matching them.

Beyond the fixes, the rehearsal leaves you with people who know what they would do. That is what lets a team use the full 72 hours, and spare itself the first twenty spent deciding who is in charge.

Checklist

• Give staff one quick way to report a suspected incident, and name who receives it.
• Record the awareness time when the incident is opened.
• Keep one shared incident record with timed entries.
• Practise turning exposed records into a list of people with contact details.
• Prepare templates for messages to people and for the Board's first intimation.
• List every reporting obligation, including CERT-In, sector regulators and contracts.
• Turn findings into owned actions and keep the incident open until they close.
• Rehearse a scenario twice a year and fix what stalls.

See Breach response for how TrustOS runs an incident.