DPAs, sub-processors and the ICO: the data protection homework most SaaS skips

There's a particular kind of silence that follows the question "so, who's your data processor for that?" in a meeting. Everyone looks at the form. The form does not answer.

If your organisation collects personal data — names, emails, referral details, anything that identifies a person — through a third-party tool, you've taken on legal responsibilities under UK GDPR whether or not anyone's mentioned them out loud. The good news: the homework is smaller than it sounds. It's mostly three things.

1. The Data Processing Agreement (DPA)

Under UK GDPR, when you (the controller) let someone else (a processor) handle personal data for you, Article 28 says there must be a contract governing it. That contract is the DPA. It's not a nice-to-have or a formality you can wave through — without it, the arrangement isn't lawful.

A DPA sets out the boring-but-vital stuff: what the processor may do with the data, that they'll only act on your instructions, that they'll keep it secure, that they'll help you with data subject requests, and what happens when the relationship ends.

When you're choosing any tool that touches personal data, the question to ask is simply: do you offer a DPA, and can I see it? A vendor that takes data protection seriously will have one ready.

2. Know your sub-processors

Here's the bit that catches people out. Your processor almost certainly uses other companies to deliver their service — cloud hosting, email delivery, analytics, payment handling. Those are sub-processors, and under UK GDPR your processor needs your authorisation to use them, plus a flow-down of the same data protection obligations.

What that means in practice: you should be able to find out, in writing, who the sub-processors are and what they each do. A well-run SaaS lists them — often in the privacy policy or a dedicated sub-processor page.

This is exactly why, at FormGenius, the sub-processors are named in our Privacy Policy and Terms, data is hosted in London, and there's a DPA in place with our AI provider including Standard Contractual Clauses. Not because it's glamorous — because when someone asks, the form should answer.

3. ICO registration (and the fee)

In the UK, most organisations that process personal data must register with the Information Commissioner's Office and pay an annual data protection fee. It's a self-assessment, the fee is tiered by size and turnover, and for most small organisations and charities it's at the lower end — currently starting around £40 a year.

There are some exemptions (a few not-for-profits and very limited processing can qualify), but assume you need to register unless you've checked the ICO's self-assessment and confirmed otherwise. Registration is cheap, public, and exactly the kind of thing a careful partner or funder will look for.

Where forms fit into all this

Forms are where personal data enters your organisation, so they're the natural place to get this right. Before you publish a form that collects personal data, it's worth running a quick mental checklist:

1. 1

   Confirm a DPA is in place

   With whoever processes the submissions on your behalf.

2. 2

   Know where the data goes

   The tool, its hosting, and any sub-processors — and ideally the country it's stored in.

3. 3

   Collect only what you need

   Data minimisation isn't just principle, it's protection: the less you hold, the less you can lose.

4. 4

   Tell people what you're doing

   A clear privacy notice on or near the form, and a lawful basis for the processing.

None of this requires a legal department. It requires asking a few direct questions and writing down the answers.