Discovering a personal data breach

Overview

Rule 6 of the DPDP Rules sets out the security safeguards a Data Fiduciary must take under the Digital Personal Data Protection Act, 2023. One of them cannot be installed after the event: logging, monitoring and the year of retained records the Rules ask for.

A company that never notices a breach cannot report one. The point is simple and it governs the whole subject, because every reporting duty begins at the moment somebody becomes aware. Awareness does not arrive by itself. It comes through records that were already being written and somebody paying attention to them. A company with neither can hold personal data for months while somebody else reads it.

The Act treats a breach far more widely than a leak. Logs have to contain the right fields to be useful. Stored records only become detection through monitoring and review, the step teams skip. The moment of awareness governs everything that follows, and so does the question of who inside a company can trigger it. This is a practical reading of the Rules and does not constitute legal advice.

One asymmetry sets the priorities. Almost every other control can be strengthened after an incident. 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.

What the Act counts as a breach

Wider than a leak

Ask most people what a data breach is and they describe a leak: customer records posted on a forum, or a database offered for sale. The Act uses a much wider definition. A personal data breach is any unauthorised processing of personal data, or any accidental disclosure, acquisition, sharing, use, alteration or destruction of it, or loss of access to it, that compromises its confidentiality, integrity or availability.

Each part of that definition carries weight. Confidentiality covers the familiar case, where 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 outside 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 relationship manager at an NBFC emailing a spreadsheet of borrowers to a personal Gmail account;
• a bug in a hospital's patient portal that shows one patient another patient's lab report;
• a script that overwrites delivery addresses with wrong values for a day;
• ransomware that locks an edtech platform's student records, even if nothing is copied out;
• a cloud storage bucket that anyone with the link could read;
• a failed disk with no working backup behind it;
• a vendor mishandling data you sent them.

Companies that plan only for the outside attacker will miss most of these, and several are more likely than the case they planned for.

No threshold to hide behind

Some laws require notification only where a breach carries a risk to the people involved. The DPDP framework takes a different approach. Rule 7 asks a Data Fiduciary, on becoming aware of any personal data breach, to inform each affected Data Principal and the Data Protection Board without delay, with a detailed report to the Board within 72 hours. The text sets no threshold of scale or severity.

A breach affecting one person therefore carries the same duties as one affecting a million. The likely consequences form part of what the notification has to describe, and they do not decide whether to notify. Companies used to a risk based test will find this stricter. A policy that says minor incidents are handled internally does not fit the Rules as written.

This raises the stakes on definition. A company needs a clear internal answer to the question of what counts, applied the same way every time. Otherwise the decision gets 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 an expensive kind of error.

It also makes detection the quiet foundation of the whole duty. You cannot report what you never noticed, and you cannot describe what you cannot see. Whether you meet your reporting duties is largely settled before any incident, by the logging and monitoring you set up.

The logs the Rules require

What Rule 6 asks for

Rule 6 lists, among the reasonable security safeguards, appropriate logs, monitoring and review of access to personal data, so that unauthorised access can be detected, investigated and remediated. It then asks for those logs, and the personal data concerned, to be retained for one year, unless another law requires otherwise. Two obligations sit there, and they are separate. Records have to be produced, and records have to be kept.

Two consequences follow. Logging is a security duty in its own right, so a failure here falls under the safeguards duty and its penalty of up to ₹250 crore, whether or not a breach happens. And the one year period gives a company a defined target, which settles an argument teams have had for years. Default retention in many logging tools and cloud services runs to thirty days, sometimes seven, because storage costs money and nobody set a longer figure. Under the Rules that default falls short. Anyone reviewing a logging arrangement should start with the retention setting. It is the quickest thing to get wrong and the quickest to put right.

Why a year matters is worth understanding, because the reason changes how a company treats the requirement. Intrusions are often discovered long after they begin. 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 what actually happened.

What each record needs to contain

A log that says "user accessed customer table" helps nobody. A useful entry answers six questions:

• who acted, as a named person or a specific service account, never a shared login;
• what they did, precisely enough to tell reading one record apart from exporting the whole table;
• which data was involved, ideally which records or at least which customers and how many;
• when it happened, from a clock synchronised across systems;
• where the request came from: the device, network address or application;
• whether it succeeded, since failed attempts often reveal more than successful ones.

Clock synchronisation needs its own mention, because it quietly 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. If six people in a call centre in Pune share one login for the loan servicing system, the log can show that something happened and never who did it. The same is true of a shared administrator account on a server. Companies that give each person a named account, and stop using shared credentials altogether, keep the ability to answer the first question a regulator asks. That question is who, and a log full of shared accounts has no answer to it.

Where the logs themselves live

Where logs sit has real consequences. Records held on the same system they describe can be reached 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 and forbid deletion, survive. The people being logged should have no ability to change the logs.

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 that describes it. Separation protects against both cases and costs very little to arrange.

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

Turning records into detection

Storage alone detects nothing

A company can satisfy the letter of the logging requirement and still learn about a breach from a journalist or a customer complaint. 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. Companies with excellent logs are sometimes the last to know.

What turns 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. Start with a short list:

• access to customer data outside working hours, or from a new location;
• a single account reading far 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 failed logins followed by a success;
• a service account suddenly reading tables it has never touched;
• a spike in password reset or SIM change requests;
• a staff member opening records of customers with no connection to their work.

Each of these describes something a legitimate user rarely does, and each is straightforward to express as a rule once logs are in one place.

Alerts that reach a person who acts

Detection ends with a human being, and that last step fails more often than the technical work before it. An alert arriving in a channel nobody owns has detected nothing. 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. An unwatched alert carries an extra risk, because it can later be argued that the company knew.

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

Ownership needs naming. Somebody is accountable for reviewing what comes in. Somebody is reachable outside office hours, including the Diwali weekend. Somebody has authority to declare an incident without waiting for permission. Each alert should also carry a short note on what to do first. Companies that leave these unassigned discover during an incident that everyone believed somebody else was watching.

Review as a scheduled activity

Rule 6 names review alongside monitoring, and the two are different activities. 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 single day would flag, or the vendor account used more often every month.

A monthly review needs an hour, a named owner 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.

Record the findings each time. A review that leaves no record is hard to prove later.

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

The moment you become aware

Why the timestamp governs everything

Every reporting duty runs from awareness. Telling affected people, the first message to the Board and the detailed report due within 72 hours all count from the moment the Data Fiduciary became aware of the breach. That single point in time decides whether a company met its obligations or missed them.

So the moment has to be recorded deliberately. A company that can say "we became aware at 9.40 pm on Thursday, and here is the record" controls its own account of events. A company that rebuilds the moment later from memory and message histories is arguing about the one fact everything else depends on.

The practical arrangement is small. When somebody first suspects unauthorised access, that suspicion is recorded with a timestamp in a place set aside for the purpose. A WhatsApp message that scrolls out of sight does not count. A ticket, an incident record or a log entry, created at the time, establishes when the company started to know something.

Whose knowledge counts

Whose knowledge counts is a question with real consequences. Awareness sits with the Data Fiduciary, meaning the organisation as a whole. A company cannot argue that a breach was known only to a junior engineer and therefore unknown to it.

Two situations follow. 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 point to the same response: a clear route by which anybody, in any team, can report a suspected incident and be sure it reached somebody accountable. Publish it on the intranet, include it in induction and repeat it often.

Processors raise the same question one step removed. A breach at your payroll provider or messaging vendor is a breach of data you are responsible for, and your clock starts when you learn of it. That is why processor contracts should carry a term requiring fast notice. A vendor taking a week to tell you leaves you explaining a delay you did not cause.

Suspicion, confirmation and not waiting

The first hours of an incident create a tension. Suspicion arrives before certainty, and teams naturally want to establish what happened before telling anybody. The Rules ask for notification on becoming aware of a breach. 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 work alongside the investigation. Use the first message to the Board for what it is, an account of the breach and its likely impact as currently understood. The detailed report exists precisely because understanding improves, and Rule 7 sets out what each message contains.

This places a demand on the escalation path. If the person who first notices takes two days to reach anybody with authority, those are two days the company needed. A short path, named in advance, with somebody reachable at any hour, keeps the response inside the window.

What you cannot reconstruct later

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 vendor 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 can recover it. The company simply does not know what happened during that period and never will.

The consequences reach past the technical. The detailed report to the Board has to describe the breach, the events and circumstances that led to it, and findings about who caused 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 that period. That sentence goes into a report filed with the regulator, and it reflects the company's own record keeping.

Where the gaps usually sit

When companies audit their logging, the same gaps keep appearing:

• retention left at a default well short of a year;
• logging on the application and none on the database beneath it, or the reverse;
• no record of direct database access, the highest risk route of all;
• no record of administrative changes in the cloud console, where permissions get changed;
• no logging on file storage, so nobody can say whether an exposed bucket was ever read;
• entries that record that a query ran without recording which records it returned;
• logs kept only on the system they describe.

Working through this 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 part of the programme that most rewards being early.

Rehearsing the discovery

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 note where it stalls. One useful version: an engineer's credentials are used from an unfamiliar location at two in the morning to export a table of customer records. Another: a collections agency reports that a list of your borrowers is circulating on Telegram.

Then ask practical questions:

• 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 people in them?
• Does it hold current contact details for those people?
• What time would go in the record as the moment of awareness?
• Who drafts the first message to the Board?

Companies running this for 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 way to reach the security lead at night. Logs that record the query and not its result. Each is a small fix found in an afternoon, and each would have cost days during a real incident.

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, plus one after any major change to systems or vendors, hold the arrangement together at very low cost. Keep a short record of what each exercise found and what was fixed.

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

A note on other reporting regimes

The DPDP Act is rarely the only rule that applies. CERT-In's directions of April 2022 require specified cyber security incidents to be reported within six hours of noticing them, and sector regulators such as the RBI, IRDAI and SEBI may have requirements of their own. Map which apply to you before an incident, so that one investigation and one set of logs can serve all of them.

What all this produces, beyond the fixes, is a company that knows what it would do. The notices the Rules require run against a 72 hour clock, set out in reporting to the Board and your users, and every hour of that clock is easier to use when the discovery itself has been practised.

Key points

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, destruction and alteration alongside the familiar case of somebody seeing data they should not. The Rules set no threshold, 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, identify the data involved, carry a synchronised timestamp, and sit in storage the described system cannot delete.

Storage alone detects nothing. A small set of rules tuned to how the business works, alerting a named person who is reachable and able to act, turns records into detection, and a monthly review catches the slow patterns no rule anticipates. Every reporting duty runs from the moment of awareness, so record that moment when the first credible suspicion appears and start the notification work alongside the investigation. Behind all of it sits one asymmetry. 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.

For how the 72 hour report works in brief, see our guide to breach notification.