A personal data breach: the first 72 hours

What Kenya's Data Protection Act expects after a personal data breach, what the ODPC's form asks, and an incident checklist for the first days.

By Achekam · 11 October 2026 · 5 min read · For Running a business businesses in Kenya

It usually starts with something small. A payroll spreadsheet sent to the wrong e-mail address. A laptop left in a matatu. A shared link to a folder of customer ID copies that turns out to be open to anyone who has it. Someone in the business notices, and the question is suddenly: what do we have to do, and by when?

Kenya's Data Protection Act answers that question with a clock. Once a business, acting as a data controller, becomes aware of a breach that poses a real risk of harm, it has seventy-two hours to tell the Data Commissioner. That is not long when you are still working out what happened. This article explains the duty, what the Office of the Data Protection Commissioner (ODPC) will ask, and how to organise the first few days.

Real risk of harm and the seventy-two hours

Section 43 of the Data Protection Act requires a data controller to notify the Data Commissioner of a personal data breach that poses a real risk of harm. The notice must be made without delay, and within seventy-two hours of the controller becoming aware of the breach. If notification comes later than that, the controller must give reasons for the delay.

Three points are worth drawing out:

• The clock starts with awareness, not with the end of your investigation. You may need to notify while facts are still emerging.
• The test is real risk of harm. Not every slip will meet it, but the decision needs to be made quickly and recorded either way.
• Late is not the same as never. If you miss the window, notify anyway and explain why.

If your business processes personal data on behalf of another organisation, as a data processor, it has duties of its own; see a processor's breach duties.

What the ODPC form asks

The ODPC's report a data breach page holds the online form that data controllers and data processors, or people acting for them, use to notify a breach under section 43. The ODPC notes that complaints about an organisation's misuse of data go through a separate formal complaint process.

According to the ODPC, the form asks:

• when the breach occurred and when it was discovered;
• whether it is being reported after 72 hours of discovery;
• what caused it;
• the categories and number of data subjects affected;
• the types of personal data involved;
• what remedial action the organisation is taking;
• whether the affected data subjects have been told;
• what steps individuals should take to reduce the risk of serious harm;
• which other regulators have been notified.

Supporting documents, such as an incident response policy, can be attached. The ODPC says it will respect the confidence of commercially sensitive information. Gathering the answers to that list is, in practice, the first job of whoever leads the response.

Telling the people affected

The Act also requires the controller to tell the affected data subjects in writing, within a reasonably practical period. The duty falls away only where safeguards make that unnecessary, which is a judgement to make carefully and record.

A useful notice is plain and specific: what happened, what data was involved, what the business has done, and what the person should do now, for example watching for messages that pretend to come from the business. Coordinate it with the steps you give the ODPC, so people do not get conflicting advice.

Recording every breach

Section 43(8) requires a data controller to record the facts of every personal data breach, its effects and the remedial action taken. That applies to all breaches, including those you decide do not meet the real-risk test and are not notified.

A simple breach register with one entry per incident is enough: what happened, when it was discovered, who decided whether to notify and why, what was done, and when it was closed. The register is also how you show, later, that a decision not to notify was considered rather than overlooked.

Revoking shares and reading the trail in Achekam

Many breaches involve a document shared too widely. In Achekam, a document can be shared by e-mailing a personal link with an expiry, an optional one-time code, and downloading allowed or not, and the share can be revoked. Staff sharing a document from the vault with a named person can block downloading, require a code and revoke the link, and every view and download of that share is recorded. Shares last seven days by default.

When a link has gone to the wrong person, two things help: revoke it at once, then look at the record of views and downloads to see whether it was opened. That record tells you whether the document was seen, which feeds straight into the ODPC's questions about cause and scope.

Record Governance keeps a log of changes to governed records, showing who did what, when and with what result, and the log can be filtered and checked for an unbroken chain. It needs the audit-log viewing permission, and it covers records under record governance, not every screen, so treat it as one source among several when piecing together what happened.

An incident checklist

On discovery

1. Stop the leak: revoke links, change passwords, recover the device or mailbox where possible.
2. Name one person to lead the response and one to keep the record.
3. Write down the time the business became aware. The seventy-two hours run from here.

Before the seventy-two hours run out

1. Establish what data, whose, how many people and how it happened, as far as you can.
2. Decide whether there is a real risk of harm, and record who decided and why.
3. If there is, submit the ODPC form, saying what you know and what you are still investigating.

Afterwards

1. Tell affected people in writing, with practical steps they can take.
2. Notify other regulators where relevant, and note them on the ODPC form.
3. Complete the breach register entry and fix the cause.

A business that has not yet registered with the ODPC should check whether it needs to; see who must register with the ODPC. Payroll files are a frequent source of breaches, and protecting employees' personal data covers that area.

Write your checklist now, while nothing is wrong, and put the name of the person who will lead the response at the top.

General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.