ODPC compliance audits are no longer rare: how to get ready before one lands on your desk

Until this year, almost every data protection engagement we were called in for started the same way: a specific complaint, an employee who left on bad terms and took a customer list with them, a vendor who mishandled personal data, or a breach that finally forced a conversation nobody wanted to have. That pattern is changing. The Office of the Data Protection Commissioner has been visibly moving from a complaints-driven regulator into one that runs its own compliance audits, flags corporate failures running into the millions of shillings in exposure, and issues compensation orders to complainants in batches rather than one at a time. If your business has treated data protection as something you deal with only when something goes wrong, this is the year that assumption gets tested.

Why the ODPC is auditing rather than waiting

A complaints-only regulator is limited by definition: it can only act on what people report, and most data subjects never file a complaint even when their information has clearly been mishandled. A regulator that runs its own audits doesn't have that limitation. It can select sectors it considers high risk, such as financial services, health, telecoms and digital lending, and examine them directly, whether or not a single complaint has landed on its desk. That shift matters because it removes the one thing a lot of businesses were quietly relying on: the assumption that if nobody complains, nobody checks.

What a compliance audit actually looks at, and how it differs from an investigation

An investigation responds to a specific allegation and narrows in on it. A compliance audit is broader and more structural. In our experience preparing clients for this kind of scrutiny, an ODPC-style review typically wants to see four things: a current data inventory showing what personal data you hold and why, a documented legal basis for each category of processing, evidence that data subject rights requests (access, correction, deletion) actually get answered and within what timeframe, and proof that any data shared with third parties, payment processors, cloud hosts, marketing platforms, is covered by a proper data processing agreement. None of this is exotic. It's the basic paperwork a functioning data protection programme should already have. The problem is that most businesses built their programme around a registration certificate and a privacy policy on the website, and stopped there.

The gap between “registered” and “compliant”

We still meet businesses that believe registering with the ODPC as a data controller or processor is the finish line. It isn't, it's the entry requirement. Registration confirms you exist and that you've told the regulator what category of processing you do. It says nothing about whether your staff are trained on data handling, whether your retention periods are actually enforced or just written down, or whether a breach last year was logged, assessed and reported within the statutory window. An audit tests the second set of questions, not the first, and that's exactly where most Kenyan businesses we've assessed have the biggest gap between what's on paper and what actually happens day to day.

A self-audit checklist worth running this month

Before an external audit forces the issue, it's worth working through this with whoever currently owns data protection in your business, even if that's an informal responsibility rather than a named role:

1. Data inventory. Do you have a current, accurate list of what personal data you collect, where it's stored, and who inside the business can access it?

2. Legal basis documentation. For each type of processing, consent, contract, legitimate interest, can you point to where that basis is actually recorded, not just assumed?

3. Data subject rights process. If a customer emailed today asking what data you hold on them, do you have a defined process and timeline for responding, or would it be improvised?

4. Third-party agreements. Does every vendor who touches customer or employee data, payroll providers, cloud storage, marketing tools, have a signed data processing agreement in place?

5. Breach response readiness. If a breach happened tomorrow, does anyone know the 72-hour notification clock starts immediately, and who is responsible for making that call?

6. Staff awareness. Have the people who actually handle personal data day to day, not just management, received any training on what that means in practice?

What happens when a gap is found

The honest answer is that it depends on the gap and how the business responds once it's identified. Regulators generally distinguish between a business that was clearly trying, with some documentation gaps, and one with no programme at all. A written remediation plan with real deadlines, produced before enforcement forces it, carries weight. Scrambling to backfill paperwork after a notice arrives does not land the same way, and by then you're negotiating from a weaker position with less time.

Where to start if this checklist made you uneasy

If working through that list left you with more questions than answers, the sensible next step is a short gap assessment against the Data Protection Act's actual requirements, not a generic template. That gives you a prioritised list of what to fix first, based on your actual exposure, rather than guessing at what an auditor might ask. We run these assessments for businesses across financial services, healthcare, hospitality and SACCOs, and the findings are rarely a surprise once they're laid out, the fixes just hadn't been prioritised yet.

Book a free consultation