What UK GDPR asks of your data: ROPA, DPIAs and DSARs

This is a practical orientation written for people running a data operating model, not legal advice. Where a decision turns on your specific circumstances, take advice — and read the ICO's own guidance, which is unusually readable.

The ROPA, and the exemption that does not apply to you

Article 30 requires a record of your processing activities. There is an exemption for organisations under 250 employees, and it is narrower than its reputation: it falls away where processing is likely to result in a risk to people's rights, where it is not occasional, or where it includes special category or criminal offence data.

Payroll is not occasional. Neither is a customer database. In practice almost every business of 50 people or more is in scope for at least part of what it does, which is why "we're under 250" is a position that tends not to survive the first serious question.

What a ROPA contains, per processing activity: the purpose, the categories of individuals and of data, who it is disclosed to, any transfers outside the UK, the retention period, and a description of the security measures. Between fifteen and forty activities is normal at this size.

The thing worth doing differently: build it from the dataset register rather than as a separate spreadsheet. Two documents describing the same reality will disagree within a quarter, and the ROPA is the one that gets stale, because nothing in the business depends on it day to day.

DPIAs, and the point of them

A DPIA is required for processing likely to result in high risk — large-scale profiling, systematic monitoring, special category data at scale, some uses of new technology, combining datasets in ways individuals would not expect. The ICO publishes a list of processing types that always require one.

The mistake is treating it as a form filled in after the decision. A DPIA that has never changed a plan is being used as a receipt. Done properly it is a short structured argument: what are we doing, what could go wrong for the people in this data, how likely and how bad, what are we changing to reduce that, and what residual risk are we accepting and who is accepting it.

Two triggers that catch mid-market businesses off guard. Introducing an AI feature that profiles customers is one, and the arrival of the EU AI Act has made this a live question for anyone selling into the EU. Deploying employee monitoring — productivity tracking, vehicle telematics that identify drivers, call recording used for performance — is the other, and it is the one most likely to arrive as a fait accompli from an operations team who bought a tool.

DSARs: the clock is the problem

An individual can ask for the personal data you hold about them. You normally have one month, extendable by two further months for complex or numerous requests, and you cannot charge except in narrow circumstances.

The principle is manageable. What kills organisations is the search. If nobody can say which systems hold personal data about a customer, the first three weeks go on finding out, and the extension gets used to cover an inventory problem rather than a genuinely complex request.

So the preparation is not a DSAR procedure. It is the register, plus one specific thing: for each system holding personal data, know what you would search on. Customer email address, employee number, phone number. Write it in the register. A DSAR then becomes a list of named searches rather than an investigation.

Two practical points. Emails and free-text notes are in scope, and they are usually where the uncomfortable material is — a manager's candid note about a former employee is personal data and is disclosable. And third-party data has to be considered before disclosure, which is a judgement, not a redaction rule.

Breach reporting: what eats the 72 hours

A personal data breach likely to risk people's rights must be reported to the ICO within 72 hours of becoming aware of it. In an actual incident, the security work is usually well in hand within a day. The question that stalls is "what was in that system?"

That is a register question, not a security question, and it is the strongest practical argument for a register that most technical teams have never heard made. If your dataset entries carry what personal data they contain and roughly how many individuals, the notification is a paragraph. If they do not, it is a week of archaeology conducted against a deadline.

The four things worth doing, in order

1. Register what you hold, with a personal-data flag, a special-category flag, and the field you would search on for a DSAR. This one artefact underpins the other three.
2. Record a lawful basis per processing activity, before processing rather than after a complaint. Switching basis later is deliberately difficult, so "we'll say legitimate interests if asked" fails on first challenge — and where it is legitimate interests, do the balancing test and keep it.
3. Set retention periods with triggers, per the retention guide. Storage limitation is the principle most often breached by accident.
4. Name who reviews. Most businesses of this size are not required to appoint a DPO, so name whoever does the review instead — and make sure it is never the same person who registered the dataset.

Where this overlaps with everything else

Nearly all of the above is the operating model you would build anyway for commercial reasons. The register, the ownership, the classification, the retention periods and the audit trail are the same artefacts; compliance just gives you a second reason to have them and a deadline for producing them.

That is worth saying to a sceptical board, because "we need to do this for GDPR" is a sentence that buys a grudging budget, and "we need to know who owns our numbers, and it happens to also answer the ICO" buys a better one.