Breach Register
An internal log of every security incident and breach, what happened, and what was done.
A breach register is your internal logbook of every security incident and personal data breach: what happened, how you judged it, whom you told and what you fixed.
Meaning of Breach Register
The Act does not require a register by name, but keeping one helps to show how you assessed and handled each incident, including near misses and incidents you decided not to report.
A breach register is a structured record, usually a spreadsheet, database or ticket queue, in which an organisation logs every incident that touched or might have touched personal data. Each entry carries a date and time of discovery, a description, the systems and data types involved, the number of people affected, the assessment of harm, the decision on notification and its reasoning, the actions taken, and the date the matter was closed. Near misses and false alarms belong in it too, because they show how your detection works.
Neither the Act nor the Rules require a register by that name. But Section 8(5) expects reasonable security safeguards, Section 8(6) and Rule 7 require intimation of breaches to the Board and affected people, and the Board can call for information under Section 36 and the related Rules. Rule 6 also expects logs and records to be kept for at least a year. A register is the simplest way to hold all of that together and to answer questions long after the people involved have moved on.
The register is not the same as the incident response plan, which is the instruction manual, or the Rule 7 report, which is the external notice. It is the continuing internal record behind both. It also differs from raw security logs, which capture machine events. The register summarises what humans decided about them. Restrict access: it may describe vulnerabilities and name individuals, so treat it as confidential and minimise the personal data inside it.
A register is most valuable when it records reasoning for decisions not to notify. Suppose a laptop with strongly encrypted storage is lost. The entry should say why you concluded that confidentiality was not compromised, who agreed, and what evidence you relied on. If the Board later disagrees, a contemporaneous record of careful thought is far better than a recollection.
Examples of Breach Register
A company logs a lost phone with customer emails, the decision to notify, the dates and the fix.
A start-up's support agent emails a user's invoice to a different customer. She logs it in the register within the hour. The privacy lead records what was exposed, confirms deletion by the recipient, decides to notify the affected user, and notes the training fix.
A payments company notices a rise in failed logins. The register captures the suspected credential-stuffing event, the controls added, the decision to notify affected users and the date the Board report was filed, giving auditors a single clear timeline.
A school administrator loses a USB stick holding an old admission list. The register records that the drive was encrypted, the assessment that no readable data was exposed, and the sign-off by the head, so the reasoning is on record.
Why Breach Register matters
When something goes wrong, memory is unreliable and deadlines are tight. A register lets you build the 72-hour Board report from facts already captured, and it shows patterns: repeat misdirected emails from one team, recurring vendor lapses, or the same unpatched system appearing again. Such patterns point to the control that needs fixing. Without a register, each incident looks isolated.
It also matters when penalties are assessed. Section 33 directs the Board to weigh the nature, gravity and duration of a breach, how repetitive it is, and the steps taken to mitigate it. A tidy register that shows consistent handling over years helps you make that case. Gaps, inconsistent entries or missing decisions can suggest weak governance, even if the underlying events were minor.
How it works in practice
- 1Set a clear definition of what to log: any actual or suspected event involving loss, theft, unauthorised access, accidental disclosure or alteration of personal data, plus significant near misses. Tell staff that reporting is expected and blame-free.
- 2Design standard fields: unique ID, discovery date and time, reporter, description, data categories, number and type of people affected, systems, cause, severity, regulator and individual notification decisions with dates, remedial actions, owner and closure date.
- 3Assign an owner, usually the privacy lead or Data Protection Officer, who reviews each entry for completeness within a few days and chases open actions.
- 4Hold a monthly or quarterly review with security, legal and business heads to spot trends and decide on control improvements. Record the decisions and track them to completion.
- 5Keep entries for a defined period, aligned with your legal retention needs and at least the one-year logging expectation in Rule 6, and protect the register with access control and audit logs.
Where it appears in the DPDP Act and Rules
Common mistakes to avoid
Logging only incidents that were reported to a regulator. Include contained events and near misses, since they reveal weaknesses before they become breaches.
Writing vague entries such as "email issue, resolved". Record data types, numbers, decisions and dates so that someone else can understand the matter years later.
Putting the full personal data of affected people into the register. Refer to systems and counts, and keep samples separately under tighter control.
Keeping several separate trackers in different teams. Use one central register, even if teams feed it, so that the picture is complete.
Compliance tips
Pair every entry with a time-stamped decision about notification and the name of the person who made it, as that is the first thing a reviewer will ask.
Review closed incidents for root cause at least quarterly and feed recurring themes into training and vendor reviews.
Test your register by reconstructing a past incident from it alone. If you cannot, add the missing fields.
Common questions about Breach Register
Is a breach register mandatory under the DPDP Act?
The Act and Rules do not name a register. However, Sections 8(5) and 8(6) and Rule 7 require safeguards and breach intimation, and the Board can ask for information. A register is the practical way of proving what you did, so it is widely treated as good practice.
What should a breach register contain?
At least the date and time of discovery, description, data and people affected, cause, severity, notification decisions and dates, remedial actions, owner and closure date. Add the reasoning behind any decision not to notify, and links to evidence.
Should near misses be recorded in a breach register?
Yes. Near misses show weaknesses before real harm occurs and demonstrate that your detection and reporting culture works. Tag them differently from confirmed breaches so that counts and notifications stay accurate.