Are All Public Bodies Data Controllers Under UK GDPR?

If you’re supplying products or services to a council, NHS Trust, university, or any other public sector client, you’ll quickly be asked the question: are you a data processor or a controller? That often leads to a related one: are all public bodies data controllers?

Getting this right matters. Your status drives which laws apply to you, what your contract must say, and the day‑to‑day compliance steps your business needs to take.

In this guide, we’ll demystify how UK GDPR treats public bodies, when they act as controllers, and what that means for small businesses working with them. We’ll also cover the contracts and policies you should have in place so you’re protected from day one.

What Does “Data Controller” Mean Under UK GDPR?

Under the UK GDPR and the Data Protection Act 2018, a “controller” decides why and how personal data is processed (the purposes and means). A “processor” acts on a controller’s documented instructions. You can also end up as “joint controllers” if two parties jointly decide the purposes and means.

In plain English:

• Controller = the decision-maker about personal data.
• Processor = the service provider processing data for someone else, on their instructions.
• Joint controllers = both parties decide together.

This isn’t about who physically holds the data or who has the biggest IT system. It’s about who decides the purpose and key parameters of the processing. The law looks at the reality of the relationship, not just the labels used in a contract.

Are All Public Bodies Data Controllers?

Generally, public bodies are controllers for the personal data they handle to carry out their statutory functions. Think of a local authority maintaining council tax records, an NHS Trust managing patient information, or a university running admissions. In each case, the organisation decides the purpose (“we need this data to perform our public task”) and sets the rules for processing. That is controller behaviour.

However, “public body” is not a magic badge that always equals controller in every scenario. There are nuances:

• Controllers by default for public tasks. When a public authority processes data to perform a legal or public function, it typically acts as a controller. Its lawful basis will often be “public task” or “legal obligation.”
• Joint controllers in collaborative programmes. If a public body and a supplier jointly determine why and how personal data is used (e.g., co-designing an analytics programme with shared decisions about purpose, data sets and outcomes), they may be joint controllers.
• Occasional processor roles. In limited cases, a public body might process data purely on another controller’s instructions (e.g., hosting data for a central department under strict instruction). It’s less common, but still possible-status is always fact-specific.

So, are all public bodies data controllers? No-not automatically in every relationship. They are usually controllers for their core activities, but your specific project could involve controller-to-controller sharing, joint controllership, or a processor arrangement, depending on who decides the purpose and means.

One more important point: as public authorities, many cannot rely on “legitimate interests” as a lawful basis when processing in the performance of their public tasks. They will typically rely on “public task” or “legal obligation” instead. As a private business, you don’t have that constraint-but your lawful basis still needs to fit the specific processing you’re doing.

What This Means If You Supply Or Partner With A Public Body

If you sell into the public sector, your data role will usually be one of the following:

• Processor (most common for software and service suppliers): the public body is the controller and you process personal data on its instructions to deliver your services.
• Controller-to-controller sharing: you each act as independent controllers for your respective purposes (for example, you receive a data feed to run your own analytics product and the public body uses your outputs for its own purpose).
• Joint controllers: you and the public body determine the purpose and means together (less common, but can occur where services are co-designed and both parties shape “why” and “how”).

Your status affects:

• Contracts: controller–processor relationships require a UK GDPR-compliant Data Processing Agreement with mandatory clauses. Controller-to-controller sharing works best with a clear Data Sharing Agreement. Joint controllers need a written arrangement setting out each party’s responsibilities and contact point for data subjects.
• Policies and transparency: controllers must tell people how their data is used. As a controller, you’ll need an up-to-date Privacy Policy and appropriate notices. As a processor, your transparency responsibilities are narrower, but your security and sub-processor obligations are strict.
• Handling rights requests: as a controller you own the response to subject access and other rights. As a processor you must assist your public-sector client to respond within statutory deadlines.
• Security and breach response: controllers handle breach notifications; processors must notify controllers without undue delay. Having a tested Data Breach Response Plan is good practice either way.

Bottom line: don’t assume your role. Map the data flows, agree who decides the purpose and key means, then document it correctly in your contracts and policies.

Controller-To-Controller Vs Processor: How To Decide

A simple, practical test for suppliers:

• Who decides “why” the data is processed? If the public body sets the purpose (e.g., operate a case management system under a statutory duty), that points toward them being controller.
• Who decides the “how” in substance? Controllers decide key means (types of personal data, categories of data subjects, retention, disclosures). Processors decide technical or operational details without changing the purpose (hosting choices, security tools, scaling architecture).
• Do you reuse the data for your own purposes? If yes, that indicates a controller role for that use.
• Do you only act on instructions? If your service follows the customer’s documented instructions with no independent purpose, that indicates a processor role.

Some quick examples to make this tangible:

• Cloud SaaS for a council’s CRM: The council decides who’s in the CRM, why and for how long (controller). You provide hosting, uptime, support, and implement the council’s retention instruction (processor). You need a Data Processing Agreement and a detailed processing schedule.
• Analytics platform using pseudonymised public health data for your R&D: You and the Trust each set purposes (their public health monitoring; your product improvement). That points toward controller-to-controller data sharing, documented with a Data Sharing Agreement and transparent notices on both sides.
• Joint service design lab: You and a university co-design a service, decide which cohorts to include and which outcomes to measure. You are likely joint controllers for that programme, and you’ll need a joint controller arrangement that describes who will handle SARs, transparency, and complaints.

If you’re still unsure, step back and ask: who would stop processing if they changed their mind about the purpose? That’s usually the controller.

What Contracts And Policies Should You Have In Place?

Public sector procurement teams will expect robust documentation. At a minimum, plan for:

1) A Controller–Processor Contract (If You’re A Processor)

UK GDPR requires specific clauses between controllers and processors. These include processing only on instructions, confidentiality, security measures, sub-processor controls, assistance with data subject rights, breach notification and return/deletion at contract end. This is typically captured in a Data Processing Agreement with a detailed Data Processing Schedule describing the processing details.

2) A Controller–Controller Agreement (If You’re A Controller)

Where you and the public body each act as controllers, use a clear Data Sharing Agreement. It should cover purpose, lawful basis, what data is shared, retention, accuracy, individuals’ rights, security, and who handles complaints and SARs.

3) Transparent User-Facing Documents

If you’re a controller for any part of the processing (including separate purposes like product analytics), you’ll need a public-facing Privacy Policy. If you run a website or app, also ensure your cookies are handled in line with PECR-clear consent for non-essential cookies, easy to reject and change preferences, and a compliant Cookie Policy. If you need help aligning banners and preference centres, this overview on cookie banners that comply is a good starting point.

4) Readiness For Data Subject Rights And Breaches

Public bodies have tight reporting obligations, and they’ll expect the same responsiveness from suppliers. Make sure you can promptly support requests and incidents. Familiarise your team with SAR timelines using this guide to subject access request deadlines, and have a practical Data Breach Response Plan ready to go.

5) A Proportionate Compliance Framework

Even as an SME, you’ll be assessed on governance. A focused toolkit-records of processing, DPIA templates, security policies, supplier due diligence-goes a long way. If you want an end‑to‑end setup, our GDPR Package can get your foundational documents in place efficiently.

Common Compliance Scenarios For SMEs Working With Public Bodies

Scenario 1: Handling Subject Access Requests (SARs) As A Processor

You operate a SaaS platform for a university. A student sends you a SAR. As a processor, you shouldn’t respond directly about the university’s data-you must inform the university and assist them. Build internal playbooks so frontline teams know to route SARs to your client contact quickly and capture the request date to help meet the response deadline.

Scenario 2: Using Service Data To Improve Your Product

You process personal data on behalf of an NHS Trust, but you’d like to analyse usage patterns to improve your product. That’s a separate purpose. Either aggregate/anonymise so no personal data is used, or treat that analysis as your own controller activity with appropriate transparency, lawful basis and (if data is shared) a proper Data Sharing Agreement. Don’t assume your processor contract lets you repurpose data.

Scenario 3: Telephone Support And Call Recording

Your support team handles calls with council staff or service users. If you record calls, ensure you have a lawful basis, clear notices, and strict access controls. You’ll also want to consider practical rules for voice data and deletion timelines. This overview on GDPR and business calls explains the key compliance points.

Scenario 4: Cookies On Your Supplier Portal

Even if the public body is the controller for the service you provide, your own website or portal still has to comply with PECR and UK GDPR. Make sure non-essential cookies (analytics, advertising, tracking) only fire after consent, with a banner that allows easy rejection, and keep your Cookie Policy aligned with what’s actually happening on the site.

Scenario 5: When UK GDPR Applies To Business Contacts

If you process public-sector staff details (names, work emails, call notes), that’s personal data-even when it relates to their work role. Your obligations still apply. This guide to when UK GDPR applies to business contacts can help you scope what’s in and out.

Scenario 6: Freedom Of Information (FOI) And Transparency

Public bodies may receive FOI requests. They’ll typically ask suppliers for input where disclosure might involve your information. FOI is a separate regime to data protection, but good contractual drafting and clear markings of confidential information will help the public body handle those requests properly without disclosing your trade secrets.

Practical Steps To Get Your Data Role Right First Time

To keep things simple and compliant, follow this sequence for each public-sector engagement:

1. Map the data flows. What personal data will be processed, by whom, for what purpose, and where?
2. Decide status based on reality. Controller, processor, joint controller, or a mix? Be specific for each processing activity.
3. Choose the right lawful basis. Public bodies often use public task/legal obligation. As an SME, you might rely on contract, legal obligation, consent, or legitimate interests depending on the processing.
4. Put the right contract in place. Use a GDPR-compliant Data Processing Agreement or a Data Sharing Agreement as appropriate, with a detailed processing schedule.
5. Align your policies and notices. Update your Privacy Policy, cookie tools and internal procedures to match what you’re actually doing.
6. Prepare for rights and incidents. Train staff on SAR triage and keep a Data Breach Response Plan ready.
7. Review regularly. Projects change-check your data map, roles and documents when scope or purpose evolves.

Frequently Asked Questions

Do Public Bodies Always Act As Controllers?

They usually act as controllers for their statutory/public functions. But roles are activity-specific. In some projects they may be joint controllers or, less commonly, processors. Always analyse the actual purpose and decision-making.

Can A Supplier Be A Controller And A Processor In The Same Engagement?

Yes. For example, you might be a processor for the public body’s core service data, but a controller for your separate product analytics. Document each role clearly and ensure you have appropriate lawful bases and transparency.

What If The Contract Labels Us A Processor But We Decide Some Purposes?

Labels don’t override reality. If you decide purposes, you’re a controller for those activities. Update the contract and your policies to reflect the true position-this protects both parties and reduces compliance risk.

Do We Need Consent To Record Support Calls?

Not necessarily-consent is one option, but other lawful bases may be more appropriate (e.g., legitimate interests for quality and training, provided you balance rights and give clear notice). Make sure your notices and retention rules are clear, and train staff accordingly.

Key Takeaways

• Public bodies are usually data controllers for their public functions-but not automatically in every relationship. Your status depends on who decides the purpose and key means of the processing.
• As a supplier, you’ll commonly be a processor; in other cases you may be a controller (or joint controller) for specific purposes. Map the data and decide status for each activity.
• Use the right legal instrument for the role: a UK GDPR-compliant Data Processing Agreement for controller–processor arrangements, or a Data Sharing Agreement for controller-to-controller sharing.
• If you act as a controller for any purpose, keep your Privacy Policy and cookie tools up to date, and ensure your lawful basis and retention are appropriate and documented.
• Be ready to support SARs and incidents-public bodies expect fast, compliant handling. A practical Data Breach Response Plan and clear SAR triage save time and reduce risk.
• Status is fact-specific and can change as projects evolve. Review roles and contracts when the purpose or scope shifts, and get tailored advice where needed.

If you’d like help clarifying your controller/processor status, drafting a Data Processing Agreement or setting up your GDPR foundations, you can reach us at 08081347754 or team@sprintlaw.co.uk for a free, no‑obligations chat.