Discovering a Personal Data Breach

Abstract

This article is the second in a three part series on breach under the Digital Personal Data Protection Act 2023. The opening article set out the six protections the Rules call for, and closed on the single one a company cannot install after the event. This article takes that item up. Logging, monitoring, and the year of retained records the Rules ask for.

A company that never notices a breach cannot report one. That sentence looks obvious and it carries the whole subject, because every duty in the third article of this series begins at the moment somebody becomes aware. Awareness is not automatic. It arrives through records that were already being written and somebody paying attention to them, and a company without either can hold personal data for months while somebody else reads it.

The article covers what the Act treats as a breach, a definition wider than a leak that takes in loss and destruction. It covers what to log and what those logs need to contain to be useful. It covers the step teams skip, turning stored records into actual detection through monitoring and review. It deals with the awareness moment itself, since that timestamp governs everything that follows, and with the question of who inside a company can trigger it.

One asymmetry runs underneath the whole article and shapes the priorities. Almost every other control can be strengthened after an incident, and a company that discovers weak encryption can encrypt. Logs work differently. A record nobody was writing on the day cannot be produced afterwards, so the investigation, the report to the Board, and any account of what happened are all limited by decisions taken earlier.

1. What the Act Counts as a Breach

1.1 Wider than a leak

The Act defines a personal data breach broadly. Any unauthorised processing of personal data counts, as does accidental disclosure, acquisition, sharing, use, alteration, destruction, or loss of access. In each case the confidentiality, integrity, or availability of personal data has been compromised. Reading that slowly is useful, because it covers more ground than people generally assume when they hear the word breach.

Confidentiality covers the familiar case. Somebody who should not see the data has seen it. Integrity covers alteration, so records changed without authority fall inside the definition even where nobody saw them. Availability covers loss and destruction, which means a company that loses data it cannot recover has suffered a breach without anybody outside ever seeing a record.

Several everyday situations therefore qualify. A database left reachable from the internet. An employee emailing a customer list to a personal account. A ransomware event that encrypts records and exfiltrates nothing. A failed disk with no working backup. An engineer running an update against the wrong environment. A vendor mishandling data you sent them. Companies that plan only for the external attacker will miss most of these, and several are more likely than the case they planned for.

1.2 No threshold to hide behind

Some frameworks require notification only where a breach carries a risk to the people involved. The Act takes a different approach. Rule 7 obliges a fiduciary to inform each affected data principal and the Board on becoming aware of any personal data breach, and the text sets no threshold of scale or severity.

Read plainly, a breach affecting one person carries the same duties as one affecting a million. Assessing likely consequences remains part of what the notification has to describe, and that assessment does not decide whether to notify. Companies used to working under a risk based test will find this stricter, and a policy that says minor incidents are handled internally does not fit the Act as written.

This raises the practical stakes on definition. A company needs a clear internal answer to the question of what counts, applied consistently, because the alternative is a judgement made under pressure by whoever happens to be handling the incident. Writing that answer down in advance, with examples drawn from your own systems, is a short piece of work that prevents a category of expensive error.

2. The Logs the Rules Require

2.1 What Rule 6 asks for

Rule 6 requires appropriate logs, monitoring, and review, along with measures able to detect unauthorised access and to address the incidents that follow. It then requires those logs and the personal data they concern to be retained for one year, unless some other law directs otherwise. Two obligations sit there, and they are separate. Records have to be produced, and records have to be kept.

The one year period gives a company a defined target and answers a question teams argue about. Default retention in many logging tools runs to thirty days, sometimes seven, because storage costs money and nobody set a longer figure. Under the Rules that default fails the requirement. Anyone reviewing a logging arrangement should start by checking the retention setting, since it is the single fastest thing to get wrong and the single fastest to correct.

Why a year and not a month is worth understanding, because the answer changes how a company treats the requirement. Intrusions are often discovered long after they begin, and an attacker inside a system for four months leaves a trail that only makes sense across the whole period. Thirty days of logs would show the last few weeks of activity and nothing about how the access started or what was taken early on. A year gives an investigation room to establish the shape of what happened.

2.2 What each record needs to contain

A log entry that cannot answer a question is storage without value. Useful entries carry a small set of fields. Who performed the action, meaning a specific identity and not a shared account. What they did, in terms specific enough to distinguish reading one record from exporting the table. Which data was involved. When it happened, from a clock synchronised across systems. Where the request came from. Whether it succeeded matters too, since failed attempts often reveal more than successful ones.

Clock synchronisation deserves its own mention because it undermines otherwise good logging. An investigation assembles events from an application, a database, a firewall, and a cloud provider into one sequence. Where those systems disagree about the time by even a few minutes, the sequence becomes unreliable, and the report to the Board depends on that sequence. Running time synchronisation everywhere costs nothing and prevents an unpleasant discovery later.

The identity field carries a similar trap. Logs recording an action against a shared administrator account establish that somebody did something and nothing about who. Companies that give each administrator a named account, and reserve shared credentials for nothing at all, keep the ability to answer the first question a regulator asks. That question is who, and a log full of shared accounts cannot answer it.

2.3 Where the logs themselves live

A detail with real consequences concerns where logs sit. Records held on the same system they describe are reachable by anyone who compromises that system, and removing evidence is a routine step for an attacker. Logs shipped promptly to separate storage, with permissions that allow writing but not deletion, survive.

The same reasoning covers accidents. An engineer who deletes the wrong environment removes its logs along with everything else, and a company investigating the deletion then has nothing describing it. Separation protects against both cases and costs very little to arrange.

One more question follows from Rule 6, and companies find it awkward. Logs about people are personal data, so a year of access records falls under the Act like any other holding. It needs the protections from the first article, it belongs in the data inventory, and its retention rule is the one year the Rules set. Treating log storage as a technical concern outside the compliance programme leaves a significant holding of personal data ungoverned.

3. Turning Records Into Detection

3.1 Storage is not detection

A company can satisfy the letter of the logging requirement and still learn about a breach from a journalist. Rule 6 asks for logs, monitoring, and review, and the second and third words carry most of the weight. Records nobody examines describe an incident perfectly and tell nobody about it, and companies with excellent logs are sometimes the last to know.

What converts storage into detection is a small set of rules describing what abnormal looks like, checked continuously, with an alert going to somebody who acts. Nobody reads a year of logs. A system compares activity against expectations and raises the exceptions.

The rules that earn their place are specific to how a business actually works. Access to personal data outside working hours. A single account reading more records in an hour than any person needs. An export of a whole table. A login from a country where the company has no staff. Repeated failures followed by a success. Access to records of people with no connection to the person accessing them. Each of these describes something a legitimate user rarely does, and each is straightforward to express as a rule.

3.2 Alerts that reach a person who acts

Detection ends at a human being, and that last step fails more often than the technical work in front of it. An alert arriving in a channel nobody owns has produced no detection. Neither has an alert arriving at three in the morning to a team that starts at nine, if nothing carries it forward. Nor has an alert lost among two hundred others that fire every day and get ignored as noise.

Alert fatigue undoes good engineering. A team receiving forty alerts a day stops reading them, and the significant one arrives alongside thirty nine that are not. Fewer rules, tuned carefully, with the false positives removed as they appear, produce more actual detection than a full set nobody trusts.

Ownership needs naming, not assuming. Somebody is accountable for reviewing what comes in. Somebody is reachable outside office hours. Somebody has authority to declare an incident without waiting for permission. Companies that leave these unassigned discover during an incident that everyone believed somebody else was watching.

3.3 Review as a scheduled activity

Rule 6 names review alongside monitoring, and the two are different things. Monitoring is continuous and automated. Review is periodic and human, and it catches what rules were never written for. A person examining last month’s access patterns notices the account that has been reading a little more each week, which no individual day would flag.

A monthly review needs an hour and a short agenda. Which accounts touched the most personal data and does that match their role. Which permissions were granted and by whom. Which alerts fired and how each was resolved. Whether any dormant account came back to life. Whether logging stopped anywhere without anyone noticing, which happens after deployments more often than teams expect.

That last check earns its place. Logging failures produce no error. A configuration change, a new service, a permission adjustment, and records stop being written while every dashboard looks healthy. Companies that verify the presence of logs on a schedule find these gaps in weeks. Companies that do not find them during an investigation, at the point where the gap has become permanent.

4. The Moment You Become Aware

4.1 Why the timestamp governs everything

Every duty in the third article of this series runs from awareness. Notification to affected people, the first message to the Board, and the detailed report due within seventy two hours all count from the moment the fiduciary became aware. That single timestamp decides whether a company met its obligations or missed them.

Which means the moment has to be recorded deliberately. A company able to state that it became aware at a particular hour on a particular day, with a record supporting the statement, controls its own account of events. A company reconstructing the moment later from memory and message histories is arguing about the one fact everything else depends on.

The practical arrangement is a small one. When somebody first suspects unauthorised access, that suspicion gets recorded with a timestamp in a place designated for the purpose. Not a chat message that scrolls away. A ticket, an incident record, or a log entry, created at the time, that establishes when the company started to know something.

4.2 Who can become aware

A question with real consequences concerns whose knowledge counts. Awareness sits with the fiduciary, meaning the organisation and not a particular individual, so a company cannot argue that a breach was known only to a junior engineer and therefore not known to it.

Two situations follow from that. A support agent who notices something odd and mentions it to a colleague has started the organisation knowing. An alert firing into an unwatched channel is arguably known to the company from the moment it fired, since the company chose that arrangement. Neither position is comfortable, and both argue for the same response, a route by which anybody who sees something can report it and be sure it reached somebody accountable.

Processors raise the same question one step removed. A breach in a vendor system is a breach of data you are responsible for, and your clock starts when you learn of it. That is why the first article recommended a contract term requiring fast notification from processors, because a vendor taking a week to tell you leaves you explaining a delay you did not cause.

4.3 Suspicion, confirmation, and not waiting

A tension appears in the first hours of an incident. Suspicion arrives before certainty, and a team naturally wants to establish what happened before telling anybody. The Rules ask for notification on becoming aware of a breach, and a company that waits for a complete picture may spend three days investigating and then report late.

The workable position has three parts. Treat the first credible sign as the start of the clock. Begin the notification process alongside the investigation. Use the initial message for what it is, a description of the breach and its likely impact as currently understood. The third article covers what that message contains and how the detailed report follows it.

Which places a demand on the escalation path. If the person who first notices takes two days to reach anybody with authority, the company has lost two days it needed. A short path, named in advance, with somebody reachable at any hour, is what keeps the response inside the window. Rehearsing that path is the subject of the final section.

5. What You Cannot Reconstruct Later

5.1 The asymmetry that sets the priorities

Almost everything in a compliance programme can be improved after an incident. A company that finds its encryption weak can encrypt. One that finds access too broad can narrow it. Thin processor contracts can be renegotiated. Each of those repairs is expensive and each is possible.

Logs are the exception. Nothing recreates an entry that was never written on the day. No investigation, budget, or expert recovers it. The company simply does not know what happened during that period and never will.

Those consequences reach past the technical. A report to the Board has to describe the nature and extent of the breach, when and where it occurred, and the circumstances leading to it. A company with a year of logs can answer those questions and support the answers. A company holding thirty days of logs against a four month intrusion has to tell the Board that it cannot establish what happened during most of the period. That statement goes into the report, and it reflects the company’s own record keeping.

5.2 Where the gaps usually sit

Companies auditing their logging tend to find the same gaps. Retention set to a default well under a year. Logging enabled on the main application and absent on the database beneath it, or the reverse. Nothing recording direct database access, the highest risk route of all. Nothing recording administrative actions in the cloud console, where permissions get changed. No logging on file storage, so nobody can tell whether an exposed bucket was ever read.

Two more appear regularly. Logs that record an action without recording which records it touched, so an investigation knows somebody ran a query and not what the query returned. Logs sitting only on the system they describe, which the earlier section covered.

Working through that list against your own environment takes a day or two and produces a specific set of fixes. Every one of them is cheap now. Every one of them is impossible to apply retrospectively once an incident has happened, which makes this the piece of the programme that most rewards being early.

6. Rehearsing the Discovery

6.1 The exercise that tests the whole chain

Detection can be tested without waiting for a real incident. Take a plausible scenario, walk it through the systems and the people, and record where it stalls. A useful version runs like this. An engineer’s credentials are used from an unfamiliar location at two in the morning to export a table of customer records. Now trace it.

Would anything have logged the export, and would that log still exist in ninety days. Would a rule have flagged the location, the hour, or the volume. Where would the alert have gone, and who would have seen it before morning. How long from the alert to somebody with authority to declare an incident. Could the company establish which records left, and identify the individuals in them. What time would go in the record as the moment of awareness.

Companies running this the first time usually find two or three breaks in the chain, and the breaks are almost always mundane. An alert routing to a channel that was archived. A retention setting nobody changed. No route to reach the security lead at night. Logs that record the query and not its result. Each of these is a small fix found in an afternoon, and each would have cost days during a real incident.

6.2 Making it a habit

One exercise finds the current gaps. Repeating it keeps them closed, because systems change and detection stops matching them. A new service arrives without logging. A rule stops firing after a schema change. Somebody leaves and their alerts route nowhere. Two exercises a year, each taking half a day, hold the arrangement together at very low cost.

Vary the scenario so the exercise keeps finding things. An external attacker. A departing employee copying a client list. A misconfigured storage bucket exposed for a month. A processor reporting a breach in their systems. A ransomware event. Each tests a different part of the chain, and the last two test parts that a purely technical exercise never reaches.

What all of this produces, beyond the fixes, is a company that knows what it would do. The third article in this series covers the notifications the Act requires and the seventy two hour clock they run against, and every hour of that clock is easier to use when the discovery itself has been practised.

Conclusion

A company that does not notice a breach cannot report one, and noticing depends on records that were already being written. The Act defines a breach widely, covering loss and destruction and alteration alongside the familiar case of somebody seeing data they should not. Rule 7 sets no threshold either, so an incident affecting one person carries the same duties as one affecting many. Rule 6 asks for logs, monitoring and review, with a year of retention, and the year matters because intrusions are usually found long after they start. Useful records name a specific person, describe the action precisely enough to matter, identify the data involved, carry a synchronised timestamp, and sit in storage the described system cannot delete.

Storage alone detects nothing. What turns records into detection is a small set of rules tuned to how the business actually works, alerting to a named person who is reachable and able to act. A monthly review then catches the slow patterns no rule anticipates. Every duty in the next article runs from the moment of awareness, so that moment should be recorded deliberately when the first credible suspicion appears, and the notification process should begin alongside the investigation and not after it. Behind all of it sits one asymmetry that should shape the order of work. Encryption, access control and contracts can all be strengthened after an incident. A log that was not running cannot be recovered, which makes logging the item to fix first and the one where being early pays most.