Data Breach Incident Register

What this tool does

CM8-168 is a working register of personal data breaches. You record what happened, when you found out, what data and how many people were involved, how you rated the risk, what you did to contain it and whether it was reported. The tool measures the elapsed hours that matter, rates the risk from your own likelihood and severity assessments, shows whether each report was made inside the deadline you have set, and prints a register you can put in front of a board, an auditor or a client.

Everything runs inside this one file. There is no account, no upload and no network request of any kind, so descriptions, names and volumes never leave the computer you are using. That matters more here than in most tools: a breach register is itself a concentration of sensitive information about your worst days.

The clock starts at awareness

The consequence catches people out in both directions. It is generous, because the weeks a breach sat undetected do not eat your deadline. It is unforgiving, because the deadline starts the instant somebody in your organisation has enough information to have a reasonable degree of certainty that a breach has occurred — usually well before anyone has established the full extent. Waiting until you know everything is the most common way a deadline is missed.

That is why the time discovered is a required field. A date alone cannot measure hours, and a register that records only dates cannot tell you whether you met a deadline expressed in hours. If you genuinely do not know the time, record your best evidenced estimate — the timestamp on the alert, the ticket, the call log — and say in the description where the estimate came from.

Record the date the breach occurred as well, when you know it. The gap between the two is your detection lag, and a long lag is a finding in itself even when the breach turns out to be minor.

What to record

Log every suspected personal data breach, not only the ones that turn out to be reportable. A register that contains only the reported breaches cannot show that you assessed the others, and being able to show the assessment is usually as valuable as the assessment itself.

• Reference, dates and times — a reference you can quote, the discovery date and time, and the date it happened where that is known.
• How it came to light — staff, a data subject, a monitoring alert, a third party, an audit, the media. A register where nothing is ever found by monitoring is telling you something about your monitoring.
• Description — a sequence of events in plain words, without adjectives and without blame. It may be read years later by somebody who was not there.
• Data and volumes — the categories of personal data, whether any of it is special category or otherwise sensitive, and the approximate number of data subjects and records.
• Assessment — likelihood and severity of harm, and the reporting decision.
• Response — containment action and its timestamp, root cause, corrective action, an owner and a status.

Confidentiality, integrity, availability

A personal data breach is not only a leak. The three classic failure modes are all breaches:

• Type — What has gone wrong — Typical example
• Confidentiality — Data seen, taken or disclosed by the wrong people — Email to the wrong recipient; compromised mailbox
• Integrity — Data altered or corrupted without authority — A release writes records against the wrong identifiers
• Availability — Data lost, destroyed or made inaccessible — Ransomware; a deletion with no working backup
• Combination — More than one of the above at once — A stolen unencrypted device: the data is both exposed and gone

Availability breaches are the ones most often left out of registers, because nothing escaped. If people cannot get at their own data, or you cannot get at it to serve them, that is still a breach and it still needs assessing.

The risk rating

You assess two things separately: how likely it is that the people affected suffer some harm, and how severe that harm would be if it happened. The register multiplies them.

Keeping the two apart is the whole point. An encrypted stolen laptop can be high severity and low likelihood; a misdirected mailing list can be near-certain disclosure of something trivial. Collapsing them into a single gut-feel rating loses the reason for the answer.

Judge harm to the people, not embarrassment to you. Identity fraud, financial loss, loss of control over sensitive information, discrimination, damage to reputation or relationships, physical safety. Special category and otherwise sensitive data usually pushes severity up, which is why it has its own checkbox and why the register shows it beside the reference in the reporting timeline.

The reporting deadline

Set the deadline in hours on the Settings tab. The default of 72 is a common figure, but it is only a setting: check what applies to you, to your sector and to any contract you have signed, because some contracts require notice to a customer far sooner than any regulator expects notice from you.

For a breach marked reportable but not yet reported, the register counts forward from the discovery timestamp to now and shows the hours remaining, or the hours by which it is already overdue. Nothing here is a submission: this tool does not report anything to anybody. It records that you did.

If your assessment is that a breach is not reportable, record it as such and keep the reasoning in the root cause and description fields. The decision not to report is a decision you may have to justify, and an empty row justifies nothing.

Clock hours or working hours

By default every hour counts — nights, weekends and holidays included. That is the safe assumption and the one most regimes use for a deadline expressed in hours.

If the rules you follow genuinely stop the clock outside working days, switch the basis to working hours and set which days are non-working. The register then counts only the minutes that fall on working days:

Two honest limitations. There is no holiday calendar, so public holidays are counted as working days wherever you are. And the working-hours basis excludes whole non-working days rather than the hours outside an office day, because a breach response does not stop at five o'clock. If you are unsure which basis applies, leave it on clock hours — it is the stricter of the two and it will never flatter you.

Telling the people affected

Reporting to a regulator and telling the people affected are separate decisions with separate triggers. The second is usually reserved for breaches likely to cause serious harm. Set the risk rating at which you assume notification is necessary in the Settings tab, and the register flags every breach at or above it that has not yet been notified, in the Tell subjects column and in the headline tiles.

That flag is a prompt, not a decision. It cannot see whether the data was encrypted, whether the risk was eliminated by your containment, or whether telling people would cause disproportionate effort or harm. Your own assessment overrides it — mark the row as "not required" and record why in the description.

Containment and hours to contain

Containment is the point at which the breach stops getting worse: the account is disabled, the link is withdrawn, the server is isolated, the recipient has confirmed deletion. It is not the point at which the investigation finishes or the corrective action is delivered.

The average is taken only over breaches with both a discovery time and a containment time, and the tile says how many that is. If half your register has no containment timestamp, the average describes the half you measured — treat a figure built on two or three breaches as an anecdote, not a metric.

Counting subjects and records

Data subjects and records are different counts and the register keeps them apart. One compromised mailbox might hold 3,000 messages about 1,200 people; a misdirected payroll file might hold exactly one record each for 340 people. Reporting the larger of the two because it sounds more thorough is a good way to alarm everybody unnecessarily.

Both are explicitly approximate. Early figures are almost always wrong, usually low, and you should update the row as the investigation firms them up rather than waiting for certainty before recording anything. The tiles sum whatever is in the register at the time, so a register full of first estimates produces a total made of first estimates.

Cause analysis

The cause list is deliberately about conditions rather than people. "Human error" is where an investigation starts, not where it stops: somebody sent the wrong file, but why was the wrong file reachable, why was there no template, and why did nothing check it on the way out? Keep asking why until you reach something you can change, and put that in the root cause field.

The cause chart and the cause analysis table rank causes by frequency and show the data subjects behind each one, because the two rankings often disagree. Ten small misdirected emails and one supplier failure affecting thousands need different responses, and a register sorted by date will not show you which is which.

Printing and sharing

Print Report produces a report from whatever the current filter shows: header, headline figures, the four charts, the reporting timeline, the cause analysis, the full register and your closing notes. Print to PDF to circulate it. The scope line under the title states the filter in force, so clear the filters before issuing anything described as the complete register.

Because the register concentrates sensitive information, treat every export as confidential and think before circulating one. Consider whether the recipient needs the descriptions at all, or only the counts and the timings.

Saving your work

Breaches, settings and the report header are written to this browser's local storage as you type, and the toolbar shows the time of the last save. That storage belongs to one browser on one computer: another browser, a private window, a second machine or a clean-up tool that clears site data will not have it.

Treat Export .json as the real save — one file containing everything, which Import .json restores anywhere. Export CSV gives you the register for spreadsheet work, including every hidden field and every derived figure for the whole filtered set, not only the rows drawn on screen. Reset asks twice, then erases everything this tool has stored. There is no undo.

Accuracy & disclaimer

This register records what you enter and calculates from it. It cannot tell whether a breach is reportable, who has to be told, how long you have, whether your likelihood and severity ratings are defensible, or whether the timestamps are the real ones — and every figure on the screen depends on all of those.

Deadlines, thresholds, notification duties and record-retention periods differ by country, by sector and by contract. The deadline here is the number you typed into the settings and nothing more. This is an internal record-keeping and calculation aid, not legal advice, not a regulatory submission, and not a substitute for competent advice on the rules that apply to you.