How to report a data breach to the ODPC, and what happens next

Most organisations meet section 43 of the Data Protection Act for the first time in the middle of an incident, at which point the question is not "what does good look like" but "do we have to tell the regulator, and by when". This is that decision, laid out so it can be made in an hour rather than a day.

First: is it a personal data breach at all?

The Act defines a breach broadly. It is not limited to an attacker exfiltrating a database. It covers a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data.

So each of these qualifies:

• A ransomware event that encrypts a file server, even if nothing left the building. Loss of availability is a breach.
• An email with a client list sent to the wrong recipient.
• A departing employee copying a customer database to personal storage.
• A misconfigured cloud bucket that was publicly readable for two days, whether or not you can prove anyone read it.
• A lost, unencrypted laptop.

The last three are the ones organisations argue themselves out of, usually on the grounds that no harm was demonstrated. Demonstrated harm is not the test.

Second: the decision tree

Personal data involved?
  No  → not a section 43 event. Still log it; the pattern matters.
  Yes ↓

Real risk of harm to the data subject?
  No  → no notification required. Record the assessment and who made it.
  Yes ↓

Notify the Commissioner within 72 hours of becoming aware.
Communicate to affected data subjects in writing.

Two branches deserve more than a box.

"Real risk of harm." This is your assessment to make, and the Act expects you to be able to defend it. The factors that move it: the sensitivity of the data, whether it was encrypted to a current standard, whether the data identifies people directly, how many people are affected, and whether the data enables onward fraud — national ID numbers, phone numbers tied to mobile money, health records. A single encrypted laptop with a strong passphrase is a different judgement from a plaintext export of KYC documents.

The "no" branch is not a free pass. If you decide notification is not required, write down the decision, the reasoning, the date, and the name of the person who made it, on the day. An undocumented decision not to notify is indistinguishable, a year later, from a failure to notify.

When the clock starts

At awareness. Not at containment, not at root cause, and not at the point your incident manager is confident in the scope.

In practice that is usually earlier than an organisation's instinct, because awareness sits with the organisation, not with the executive. A support engineer who reads a ticket describing customer data visible to the wrong account has made the organisation aware. If that ticket sits in a queue for four days, you have used four days of a three-day window.

This is a process problem, not a legal one, and it has a process fix: one named channel for anything that might be a personal data breach, with a defined escalation time measured in hours.

What to put in the notification

Check the current form and fields on the ODPC site before you file, because the portal has changed. Regardless of format, have these ready:

• What happened, in plain language, and when you became aware
• Categories of personal data involved, and roughly how many data subjects
• Likely consequences for those data subjects
• Measures taken or proposed — containment, remediation, and what you are doing to prevent recurrence
• Whether data subjects have been informed, and if not, when they will be
• Your contact point — a named person who can answer follow-up questions

You are permitted to notify with incomplete information and follow up. A partial notification inside 72 hours is a far better position than a complete one on day five.

Telling the affected people

Section 43 also requires communication to the data subject where the breach is likely to result in real risk to their rights and freedoms. Write it for the reader, not for your lawyer:

• What happened, and what data of theirs was involved
• What the specific risk to them is — "someone may call you claiming to be from our support team" beats "there may be a risk to your personal information"
• What you have done
• What they should do, concretely, with the two or three most useful actions first
• A real contact channel that a person answers

If you cannot identify the affected individuals, public communication may be the only route. Decide in advance who signs that off.

What happens after you file

Expect one of three things, and plan for the second:

1. Acknowledgement and no further action, where the notification is clear and the response was evidently adequate.
2. A request for further information. This is the common outcome, and it is usually specific: your DPIA for the affected system, your retention schedule, evidence of the security controls you claimed, your register entry for the processing activity. Organisations that had those documents before the incident answer in a day. Organisations that did not spend three weeks writing them under scrutiny, which is the worst possible condition for writing them.
3. An investigation, which may lead to an enforcement notice or a penalty notice.

The pattern is consistent: the regulator's follow-up questions are about your programme, not your incident. The incident is only what caused them to look.

The unglamorous conclusion

Every part of this is easier if it was written down before it was needed — a sentence you have read before and probably discounted. The concrete version: the notification above takes about two hours to assemble if you have a processing register and a breach playbook, and about two days if you do not. The window is 72 hours, and you will be spending most of it on containment.

Next step

If you have a live incident, the priority is preservation, not paperwork: isolate affected systems rather than powering them off, and stop deleting anything. Then call us on +254 740 658 068 — see Digital Forensics & Investigations.

If you do not have an incident, this is the week to build the playbook. See what Incident Response Advisory covers, and pair it with the processing register from Data Protection & Privacy — between them, those two documents answer most of the ODPC's follow-up questions.