UK GDPR and DPIAs for public sector software projects: a practical guide

Most public sector software handles personal data. Case management, booking, payments, referrals, contact forms and staff systems all involve information about real people, and often about people in vulnerable circumstances.

UK GDPR and the Data Protection Act 2018 set the legal framework. A Data Protection Impact Assessment, or DPIA, is one of the most practical tools for applying that framework to a specific project. Done well and done early, it shapes the design, the contract and the way the service runs.

This guide shares how we approach data protection as a delivery team. It is not legal advice. Every organisation should involve its Data Protection Officer and follow current guidance from the Information Commissioner's Office.

Controller and processor roles

The first thing to settle is who is responsible for what.

The controller decides why and how personal data is processed. In most public sector software projects, the public body is the controller.
The processor processes personal data on the controller's behalf and on its instructions. A supplier building, hosting or supporting a system is usually a processor.

The roles are not always clean. If a supplier makes its own decisions about how data is used, it may become a controller for that processing. Where two organisations jointly decide the purposes and means, they may be joint controllers.

Getting this right matters because it determines who carries which obligations. The contract between controller and processor needs to include the terms that UK GDPR requires, covering matters such as acting only on documented instructions, confidentiality, security, use of sub-processors, assisting with data subject rights, and deletion or return of data at the end of the contract.

When a DPIA is required

UK GDPR requires a DPIA where processing is likely to result in a high risk to individuals. The ICO publishes guidance and examples of processing that is likely to need one, such as large-scale processing of special category data, systematic monitoring, innovative technology, and processing that could affect access to services or benefits.

In public services, many projects fall into these categories. Children's services, health and social care, housing, education and anything involving vulnerable people will often need a DPIA.

Even where a DPIA is not strictly required, we recommend doing one. It is the clearest way to think through risks and document decisions, and it gives the buyer a record that it took data protection seriously.

What goes in a DPIA

The ICO provides a template, and many public bodies have their own. The core content is similar:

Describe the processing

What personal data is collected, including any special category or criminal offence data
Whose data it is, such as residents, service users, children, carers or staff
Where the data comes from and where it goes
How it will be used, stored, accessed and deleted
Which systems, suppliers and integrations are involved

Assess necessity and proportionality

The lawful basis for processing, and any additional condition for special category data
Whether each data item is actually needed for the purpose
How individuals will be told about the processing
How data subject rights will be supported

Identify and assess risks

Consider risks to individuals, not just to the organisation. Examples include unauthorised access, data being used for a purpose people would not expect, inaccurate records leading to wrong decisions, and data being kept longer than needed.

Identify measures to reduce risk

Set out the controls: access controls, encryption, audit logging, data minimisation, retention schedules, staff training, testing and supplier assurance.

Sign-off and review

Record who approved the DPIA, the DPO's advice, and when it will be reviewed. A DPIA is a living document. Revisit it when the service changes.

Sub-processors

Suppliers rarely deliver everything themselves. Cloud hosting, email delivery, SMS, payment providers, monitoring tools and support platforms may all process personal data.

Each of these is a sub-processor. The controller should know who they are, what data they handle, where they process it and what safeguards are in place. Under UK GDPR, a processor needs the controller's authorisation to engage sub-processors and must pass on equivalent data protection obligations.

We maintain a clear list of sub-processors for each service and notify clients before making changes.

Hosting location

Where data is stored and accessed from matters. Transfers of personal data outside the UK are restricted unless an adequacy decision applies or appropriate safeguards are in place.

Many public sector buyers prefer or require UK hosting. Even when hosting is in the UK, check where support staff are located and where sub-processors process data, because remote access can also count as a transfer. Record the position in the DPIA.

Data sharing agreements

Public services often share data between organisations: councils, health bodies, schools, police and voluntary sector partners. A data sharing agreement sets out what is shared, why, on what lawful basis, how it is protected and how long it is kept.

The ICO's Data Sharing Code of Practice is the main reference. Software should support the agreement, for example by limiting which fields are shared and logging who accessed what. Our work on young carers and early help services is a good example of where this kind of careful design matters.

Retention

Personal data should not be kept longer than necessary. Retention periods depend on the purpose and on any statutory or sector requirements, and many public bodies have a retention schedule.

Build retention into the system from the start. That means automated deletion or anonymisation, clear handling for records under legal hold, and reporting so the buyer can show what has been deleted and when.

When to do it: before the contract

The best time to start a DPIA is before the contract is signed. Ideally, the buyer begins it while defining the requirement, and the shortlisted or chosen supplier contributes technical detail.

Doing it early means:

Hosting, sub-processor and security requirements are in the specification
Data processing terms are agreed as part of the contract, not as an afterthought
Design decisions such as data minimisation are made before build begins
Go-live is not delayed by an assessment that should have happened months earlier

How we support buyers

We provide the technical information buyers need for their DPIA: data flows, hosting, sub-processors, security controls and retention. We design systems around the outcome of the assessment. You can read more about our data and AI services and how we approach public sector work.

Talk to us

If you are planning a project that handles personal data and want a supplier who engages properly with data protection from the start, get in touch.