Someone in your organisation needs a form added to your website. It might be for enquiries, applications, registrations, or internal processes. On the surface, it sounds like a straightforward web task, and it often gets treated that way. But the moment that form starts collecting sensitive information, it stops being “just a form”. It becomes a data processing system, and the risk profile changes.
Once you’re collecting things like health information, identity documents, or anything that can meaningfully affect someone if it’s exposed, you’re into a very different category of work. That matters for the end client, it matters for the agency building it, and it matters for the suppliers and freelancers implementing it. If something goes wrong, it rarely lands solely on one party.
Let’s look at what “sensitive” means in practice, and why the legal and security bar is higher than most people expect.
Why the data type changes everything
Special category data needs more protection because of the harm it could cause if it is mishandled or exposed. Under UK GDPR, organisations must identify a lawful basis for processing personal data (Article 6). If the data is special category, they also need a separate condition that specifically allows them to process that category of data (Article 9). In practice, that means the question is not just “can we collect this?”, but “are we allowed to collect this, and can we justify collecting it in this way?”
This is also where a DPIA often comes in. A DPIA is a Data Protection Impact Assessment. It is a structured way of thinking through a processing activity before you implement it, so you can identify the risks to the individuals whose data you are collecting and decide what controls are proportionate. You do not do one because it feels bureaucratic. You do one because it forces the project to make the risk visible while there is still time to change the design.
Are we allowed to collect this?
Can we justify collecting it this way?
That is not red tape for the sake of it. It is the practical recognition that, when the data could cause real harm if exposed, the bar for how you design, store, secure, and retain it should be higher than the bar for a contact form on a brochure site.
This is also why reassurance alone does not close the loop. Even if everyone involved is acting in good faith, the moment the website stores sensitive data you have increased the attack surface and multiplied the places that data can persist. That is before you factor in backups, logs, email notifications, spam folders, or plugin-specific storage quirks.
The shared risk between client, agency, and developer
From a governance point of view, the client is usually the controller because the client decides why the data’s being collected and what it’s used for.
Agencies, consultants, and suppliers often operate as processors when they build or host systems that process personal data on the client’s behalf, and that has practical implications for responsibilities, contracts, and how security decisions are made. The ICO’s guidance on controllers and processors is useful here because it explains how to think about the roles, and why it matters when something goes wrong.
Risk can become invisible when it becomes distributed.
What I see happen in real projects is that the risk can become “invisible” because it’s distributed. The client assumes the agency will handle it because they’re the technical experts. The agency assumes the client will set the compliance direction because it’s their data. The developer assumes the plugin defaults are fine because they work for typical projects or perhaps they haven’t been included in relevant discussions. Nobody is acting irresponsibly as such, the system just drifts into a risky place through circumstance and blurred lines of responsibility.
Start by minimising collection and retention
If you want a practical starting point that almost always improves the situation, it’s this: collect less, and keep it for less time.
Collecting less is the most powerful lever because the safest data is the data you never collect. If a form is collecting special category data, it’s worth challenging whether every field is truly necessary at that stage of the process. In many organisations, forms slowly accrue “useful” fields over time because it’s easy to add another question. That creates risk without anyone explicitly choosing it.
Retention is where websites quietly become long-term liabilities. UK GDPR’s storage limitation principle is essentially the idea that personal data shouldn’t be kept for longer than necessary. In a web context, the difference between “we’ll delete it later” and “it will definitely be deleted” comes down to whether deletion is engineered into the system, whether it’s tested, and whether someone is accountable for it.
The safest data is the data you never collect.
Don’t store sensitive data on the website if you can avoid it
If you can design the system so the website doesn’t store the sensitive data at all, that’s usually the cleanest option. Other than not asking for the data in the first place of course!
In an ideal world, submissions go directly into the organisation’s internal systems, or into a specialist provider built for handling that type of data, with the website acting as the collection interface rather than the storage layer. That reduces duplication and makes it far less likely that sensitive information ends up scattered across plugin tables, file systems, email inboxes, and server backups.
I realise some organisations can’t support that pattern because their IT teams are trying to remove complexity and don’t have the capacity to build or expose endpoints. That’s a real constraint, and it’s one reason these projects can be tricky. But even when you can’t hit the ideal, it’s still useful because it gives you a direction of travel: reduce storage, reduce duplication, reduce persistence.
If you do store it, deletion has to be designed and verified
If temporary storage is unavoidable, the project needs to include a retention method that actually works in practice, not just on paper. This is particularly important on WordPress, because many form plugins don’t store everything in one obvious place. It’s easy to delete an “entry” and still leave uploaded documents on disk, or to purge a table while copies remain in email notifications, spam bins, logs, or backups.
That’s why I’m cautious when a retention plan is described in vague terms like “we’ll delete submissions after 30 days”. Unless the team has confirmed exactly where the data is stored, and what “deletion” really removes in that specific setup.
This is also the point where the conversation usually shifts from build to maintenance. If the form is collecting high-risk data, it can’t be treated as a one-off deliverable. It needs patching, monitoring, access reviews, and periodic checks that retention controls still function after plugin updates and configuration changes. This is where website management and maintenance stops being a “nice to have” service and becomes the thing that prevents the same problem reappearing in two years.
Where Cyber Essentials fits in the conversation
In sensitive-form projects, the security conversation often gets simplified into a question of standards. Cyber Essentials is one of the first things that gets referenced in the UK, because it is a recognised scheme and it maps to a set of common technical controls. The NCSC describes Cyber Essentials as a minimum standard aligned to five controls designed to help protect against the most common internet-based threats.
It is also worth remembering the broader context. The UK government’s Cyber Security Breaches Survey 2025 reports that 43% of businesses and 30% of charities identified at least one cyber security breach or attack in the last 12 months. That is not a guarantee you will be breached, but it is a useful reminder that “we won’t be a target” is not something you can build a plan around when the data involved is sensitive.
43% of businesses and 30% of charities identified at least one cyber security breach or attack in the last 12 months.
The part that is easy to miss is that certification does not automatically mean the controls are sufficient for every processing scenario. The ICO explicitly notes you may have to go beyond Cyber Essentials depending on your processing activities, because it is only intended to provide a base set of controls and will not address the circumstances or risks posed by every processing operation.
So, it can be part of a sensible security posture, but it does not replace the form-specific work: being deliberate about what data you collect, where it is stored, who can access it, how long it persists, and how those controls hold up after updates and staff changes.
A litmus test that keeps everyone honest
If you want one question that cuts through ambiguity, it’s this: if this exact dataset leaked, would everyone involved still be comfortable explaining the storage and retention choices to the people who submitted the form?
If the answer is “I’m not sure”, that’s not a failure. It’s a sign you’ve found the real work, and it’s worth slowing down long enough to design the data handling properly before building anything.
Want an outside perspective?
If you are about to add or replace a form that collects anything sensitive, and you want a calm second pair of eyes on the practical risks, I’m happy to help. I spend a lot of time in the real-world edge cases where websites, plugins, hosting, and internal processes collide.
I’m not a substitute for a data protection professional and I don’t provide legal advice, but I can help you stress-test the real-world implementation: what you are collecting, where it may be stored, and how retention is likely to work in practice.
If that would be useful, feel free to get in touch. Sometimes a short review at the start prevents a painful clean-up later. Get in touch by calling me directly on 01903 527927 or via my contact page.
Appendix: links mentioned
- ICO: Special category data (lawful basis, conditions, DPIA context)
https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/lawful-basis/special-category-data/ - ICO: What is special category data?
https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/lawful-basis/special-category-data/what-is-special-category-data/ - ICO: Lawful basis (Article 6) overview
https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/lawful-basis/ - ICO: Rules on special category data (Article 9 context)
https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/lawful-basis/special-category-data/what-are-the-rules-on-special-category-data/ - ICO: Data Protection Impact Assessments (DPIAs)
https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/ - ICO: Controllers and processors guidance
https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/controllers-and-processors/ - ICO: Storage limitation principle (Article 5)
https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/storage-limitation/ - NCSC: Cyber Essentials overview
https://www.ncsc.gov.uk/cyberessentials/overview - ICO: Data security guidance (incl. Cyber Essentials as a starting point)
https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/security/a-guide-to-data-security/ - UK Government: Cyber Security Breaches Survey 2025
https://www.gov.uk/government/statistics/cyber-security-breaches-survey-2025








