Every UK business that collects or processes personal data needs to consider UK GDPR — and for a custom software build, that's a set of decisions made at design time, not something bolted on after launch. Here's what tends to actually come up during a build, in plain terms.

Data minimisation

Collect only the data the system genuinely needs to function, not everything that might be useful someday. Every additional field you store is additional risk if there's ever a breach, and additional obligation to justify if a user asks why you have it.

Data protection by design

The ICO's guidance frames this as considering data protection from the start of a project, not retrofitting it — access controls, encryption, and minimisation should be part of the initial architecture, not a later patch. This is the single biggest reason GDPR should be discussed during scoping, not after the system is built.

Storage location

Where personal data is physically stored and processed matters under UK GDPR, particularly if any part of your infrastructure sits outside the UK or EU. This affects hosting provider choice and needs to be a deliberate decision, not an accident of which cloud region a developer happened to pick by default.

Retention

Personal data shouldn't be kept indefinitely by default — you need a defined retention period, tied to why you collected it, with a process for deleting it once that reason no longer applies. "We'll just keep everything forever" is not a defensible retention policy.

Consent and subject access requests

Where consent is the legal basis for processing, it needs to be specific, informed, and as easy to withdraw as it was to give. Separately, the system should be able to support a subject access request — someone asking what data you hold on them — without that being a manual, ad hoc scramble through the database.

What's changed recently

Following the Data (Use and Access) Act 2025, UK data protection guidance now includes specific provisions around protections for children's data, and automated decision-making and AI governance are receiving increased regulatory scrutiny. If your system uses any automated decision-making that affects users, that's worth flagging explicitly during scoping.

Supply chain

It's no longer enough to ensure your own systems are compliant — you also need visibility into your processors' and sub-processors' compliance (your hosting provider, any third-party APIs handling personal data). This is increasingly a documented, auditable requirement rather than an informal assumption.

This is not legal advice

This is a starting checklist for the conversations to have during a software build, not a compliance certification. UK data protection law has real teeth and real nuance — for anything beyond the basics, particularly around lawful basis, automated decision-making, or cross-border data transfers, consult a data protection specialist or solicitor before launch.