What the ODPC actually asks for when it comes knocking

Most organisations we meet have done something about the Data Protection Act. They have registered with the Office of the Data Protection Commissioner, appointed somebody as data protection officer, and circulated a policy. Then the file closed. When a complaint arrives — and complaints, not inspections, are what usually starts this — they discover that registration was the easy part.

The Act obliges a controller to demonstrate compliance, not to assert it. That single word changes the work. Below is what “demonstrate” has meant in practice for the organisations we have supported through it.

A record of what you process, not a policy about it

The first request is almost always for records of processing activities. Not the policy. The record: what personal data you hold, why you hold it, whose it is, what lawful basis you rely on, who you share it with, where it goes, and how long you keep it.

Organisations that fail here usually fail for the same reason. The record was assembled once, by a consultant, from interviews. It described the systems of two years ago. Nobody updated it when the CRM was replaced, when a new analytics tool started receiving a nightly export, or when a department began keeping a spreadsheet because the system did not do what they needed.

A record that is accurate and thin beats a record that is comprehensive and stale. Start from the systems that actually hold personal data, confirm the flows with the people who operate them, and put a review date on it that somebody owns.

Lawful basis, chosen deliberately

Consent is the basis most organisations reach for, and it is frequently the wrong one. Consent must be freely given, specific and withdrawable. If your service cannot function when a customer withdraws it, you were not relying on consent — you were relying on contract, or on legitimate interest, and you should say so.

The practical test is simple: for each processing activity in your record, write the basis next to it, then ask what happens if the data subject objects. If the honest answer is “we would keep processing anyway”, the basis is wrong and the tick-box consent you collected is doing no work at all.

Impact assessments for the processing that warrants one

A data protection impact assessment is required where processing is likely to result in high risk to data subjects. In our client base that has meant biometric enrolment, credit scoring, large-scale profiling of subscribers, geolocation, and anything involving beneficiary data in a humanitarian context.

The assessment does not need to be long. It needs to show that you identified the risk, considered a less intrusive alternative, and decided consciously. A DPIA that concludes “risk is low, proceed” for every activity is evidence of a process that was not really run.

Contracts with everyone who touches the data

Every processor acting on your behalf needs a written agreement covering scope, duration, purpose, security measures, sub-processing, and what happens at the end of the relationship. This is where cross-border transfer usually surfaces, because the cloud service you assumed was local is not.

The gap we find most often is not a missing contract with a large vendor. It is the small ones: the SMS gateway, the payroll bureau, the marketing agency with a copy of the customer list, the former developer whose access was never revoked.

Breach notification you can actually execute

The Act requires notification to the Commissioner where a breach presents a real risk of harm, within 72 hours of becoming aware. Seventy-two hours is not long enough to decide who makes that call. It has to be decided in advance.

• Who declares that an incident is a personal data breach, and who deputises for them.
• What information the notification must carry, drafted as a template before you need it.
• How you will estimate the number of data subjects affected when logs are incomplete.
• Who informs data subjects, in what words, and through which channel.
• Where the decision and its reasoning are recorded, including a decision not to notify.

The last point matters more than it looks. A documented, reasoned decision not to notify is defensible. Silence is not.

Data subject requests with a clock on them

Access, correction, deletion and objection requests arrive by whatever channel the data subject chooses — including a message to a branch, or a comment on social media. If your process only recognises requests sent to a specific email address, the clock has been running for a while before you notice it started.

Build one intake point that every customer-facing team knows to route to, and keep a log with dates. The log is the evidence. Without dates, you cannot show you responded in time, even when you did.

What we would do first

1. Rebuild the record of processing from the systems, not from memory, and give it an owner.
2. Restate the lawful basis for each activity, and fix the ones that only work if nobody objects.
3. List every processor, then find the contracts. Start with the small suppliers.
4. Write the breach decision tree and name the people in it.
5. Run one data subject request end to end as a rehearsal, and time it.

None of this is exotic. It is ordinary control work applied to a domain that arrived recently enough that most organisations have not yet applied it. That is also why it goes quickly once somebody starts.

The regulator is not testing your intentions. It is testing whether you can produce the record on the day it is asked for.