Coordinating a Breach from Detection to Closure

The Digital Personal Data Protection Act 2023 and the Rules made under it create two separate duties when a personal data breach occurs. Every affected individual has to be told, without delay and in clear plain language, what happened and what it may mean for them. The Data Protection Board has to be told as well, first with an immediate description and then with a detailed report inside seventy two hours of the company becoming aware.

Both duties run from the same moment, meaning the point at which the company becomes 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, which means the small everyday incident is reportable alongside the serious one. An email sent to the wrong customer falls inside this.

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

The report to the Board within seventy two hours covers the broad facts of what happened, the circumstances and reasons that led to it, the measures the company implemented to reduce harm, its findings about the person who caused the breach, the remedial steps taken to prevent a recurrence, and an account of the notifications given to affected individuals.

Every one of those items draws on records. The nature and extent of the breach comes 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 naming a specific identity.

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

The notification account is the item companies most often struggle with, because 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 notifications were going out.

Every deadline in this article counts from the moment of awareness, so that moment has to be recorded deliberately. TrustOS captures it when the incident is created, which means the company can state when it became aware and can support the statement.

The alternative is reconstructing the moment afterwards from message histories and recollection, and a reconstruction carries less weight than a record made at the time. It also tends to be less favourable, because the earliest sign of trouble is usually earlier than anybody remembers.

Awareness sits with the company and not with an individual, and that distinction matters more than it appears. A support agent who notices something odd has started the company knowing. So has a monitoring alert firing into a channel somebody should have been watching.

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

An incident is not understood all at once. The first hour produces a suspicion. The second produces a rough scope. By the end of the day somebody knows which systems were reached, and by the second day the extent of what was taken becomes clearer.

That pattern makes a shared record valuable, because several people are establishing different pieces simultaneously. The security lead is scoping. Technology is checking logs. Legal is assessing whether it is reportable. Communications is drafting.

Where each of them keeps notes separately, the picture fragments and somebody has to assemble it before anything can be sent. Where they all write into one incident record, the current understanding is visible to everyone and the assembly has already happened.

TrustOS records the facts as they are established, with the time each was added. That history matters afterwards, because a question about why the first notification said one thing and the report said another is answered by showing what was known at each point.

Notifying every affected individual requires knowing who they are, and that step takes longer than companies expect. Going from a set of exposed records to a list of people with contact details means resolving records to individuals across systems.

A company that has already built identity resolution for its rights requests can produce the list in hours. A company that has not will be assembling it by hand while the clock runs, which consumes the time the drafting and sending needed.

TrustOS holds the affected individuals against the incident, so the notification work can proceed against a list instead of an estimate. Where the list is still being established, the record shows that, which prevents an early notification going out to a set of people that turns out to be wrong.

The Rules ask for concise, clear and plain language, and they specify the content. The nature and extent of the breach, its timing and location, the likely consequences for the individual, the measures the company has taken to reduce harm, the steps the individual can take to protect themselves, and contact details for somebody who will answer questions.

Writing that plainly rules out most of what companies instinctively produce in this situation. Careful legal phrasing designed to limit admissions usually fails the plain language test, and a notice that leaves the reader unsure whether their own data was involved has not complied however defensible each sentence is.

Specificity helps both sides. A notice saying that some user information may have been accessed leaves every recipient guessing and generates a wave of enquiries. A notice saying that a person name, email address and delivery address were involved while payment details were not tells them what to do and reduces the volume of questions considerably.

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.

Notification goes to each affected individual, which raises a difficulty the Rules do not resolve. 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 the company holds, in the order most likely to reach somebody, and records each attempt with its outcome. Where a company genuinely cannot reach a group of people, a public notice covers those it could not contact directly, and the record explains the reasoning.

TrustOS holds each notification against the individual and the incident, with the channel, the date and the message version. That record supports the account of notifications the Board report requires, and it answers the question a complainant raises when they say they were never told.

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

The first message to the Board goes without delay and 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 for a reason that feels sound and works against them. They want to know what happened before telling the regulator anything. What the Rules ask for is a description of the breach as currently understood, and an honest early account labelled as preliminary satisfies the duty.

TrustOS holds a template for that message so the facts can be filled in from the incident record instead of drafted from nothing. Preparing the template while nothing is happening takes very little time. Drafting it during an incident, with legal review, while the technical team is still working, takes hours the company does not have.

The detailed report draws on the incident record built over the preceding days. The facts as established, the circumstances, the mitigation applied, the findings on attribution, the remedial measures, and the notification account.

Two of those items ask for more than a technical description. Findings about who caused the breach require the company to have investigated attribution, which for an external attack may be limited to what the evidence supports. 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. TrustOS holds the remediation actions against the incident, so the report can name specific work with owners and dates.

Where the company needs longer, the Rules allow the Board to permit it on written request. Knowing that provision exists is useful, and relying on it is unwise, since a request for more time because the company had no plan describes its own failure to the regulator it is asking.

An incident produces findings, and findings that stay in a report change nothing. TrustOS turns each of them into assigned actions with owners and due dates, held against the incident so the connection between the cause and the fix stays visible.

Those actions vary in size. Some are configuration changes completed the same week. Some are access reviews across several systems. Some are architectural work spanning months. Recording them at their real size, with honest dates, is more useful than recording them all as immediate.

The incident stays open while remediation is outstanding, and that is a deliberate choice. Companies that close an incident when the notifications go out lose the connection between the breach and the work it caused, and the work then competes with everything else for attention without the incident behind it.

A closed incident in TrustOS holds the whole sequence. When the company became aware and how. The facts as they were established, with the time each was added. Which individuals were affected and how the list was determined. What each of them was told, through which channel, on what date. What went to the Board and when. The findings, the remediation actions, their owners and their completion.

That record serves several later readers. An internal review asking whether the response worked. A regulator following up. An enterprise customer asking during a security review whether the company has had incidents and how it handled them. Counsel assessing exposure.

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

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 duty applies to a wide range of organisations independently of this Act.

A single ransomware event can therefore trigger both, with different recipients, different formats and very different timelines. Sector regulators add further duties, and enterprise customer contracts frequently require notification 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 an hour with legal and compliance to produce. Very few companies have produced it, and the absence becomes visible during an incident when somebody asks who else needs to be told.

TrustOS holds those obligations against the incident type so the response plan works from the shortest clock and not the most familiar one.

Breach response can be tested without waiting for a breach. Take a plausible scenario, walk it through the systems and the people, and record where it stalls.

Companies running this the first time usually find two or three breaks in the chain, and they are almost always mundane. An alert routing to a channel that was archived. No route to reach the security lead at night. Identity resolution that takes two days. A notification template nobody has drafted.

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 closed, because systems change and a response plan quietly stops matching them.

What the rehearsal produces, beyond the fixes, is a company where the people involved know what they would do. That is the difference between using the seventy two hours and spending the first twenty of them deciding who is in charge.

TrustOS is a DPDPA compliance platform developed and operated by Code Colonies Private Limited. It gives privacy, legal, security, technology, operations and audit teams a single system for personal data records, purposes and notices, consent and withdrawal, requests and grievances from individuals, retention and erasure, breach response, processor oversight and compliance evidence. Every obligation is connected to a responsible owner, turned into assigned work, tracked through to completion, and left with the records that an audit or a regulatory response will call for.

The platform can be deployed inside infrastructure that you control, and the agreed scope can include source code handover, environment setup, security configuration, technical documentation, integration support and knowledge transfer. A scoped gap assessment establishes your current position, the responsible teams, the priority gaps, the technical dependencies and a practical order in which to implement.

To see the platform or to discuss your requirements, continue to the product overview or start a gap assessment. To learn more about our consulting and engineering work, visit codecolonies.com. To start a conversation, write to us at consulting@codecolonies.com.