Cyber-attacks targeting websites have become more frequent and more sophisticated over recent months. A significant driver behind this shift is the use of AI by attackers, who can now scan websites for vulnerabilities and exploit them automatically, at a scale and speed that wasn’t previously possible.
For chambers, law firms and membership or subscription websites, this raises a specific risk: sensitive data submitted through website forms, which may be stored in your site database.
Collecting personal data
Many of the forms hosted on these websites collect information that goes well beyond basic contact details. This can include:
- General contact forms, which often include free text fields where members of the public may (intentionally or not) include sensitive personal information
- Recruitment and pupillage forms, where applicants may share sensitive information as part of their application
- Public access forms, which typically ask for case details and background information about a legal matter
- Membership application forms, which may ask for professional history, qualifications, and other personal details submitted as part of assessing an applicant’s eligibility
- Event booking forms, which typically collect contact alongside reasonable adjustments and dietary requirements, information that can reveal health conditions or religious and cultural practices
- File uploads and attachments, such as CVs, covering letters, case documents, or ID scans often carry more sensitive content than the form fields themselves, and which can be easy to overlook.
If a website vulnerability means an attacker gains access to your website dashboard or database, then any of this data becomes available to the attacker – even if it’s of no interest to them. (This is often the case: an automated bot seeking to inject malware into your website may spend no time investigating the content of your site.)
Your reporting obligations if a breach occurs
If an attacker gains unauthorised access to your website through an exploited vulnerability and personal data is compromised, this counts as a personal data breach under UK data protection law. Whether you need to report it, and to whom, depends on the level of risk to the people whose data is involved.
The Information Commissioner’s Office (ICO) offers a self-assessment tool for data breaches, to help you determine if you need to report it to them. It may grade the incident as follows:
- No or low risk to individuals: no need to notify the ICO or those affected, though the incident should still be logged internally
- A risk to individuals: the breach must be reported to the ICO within 72 hours of the organisation becoming aware of it
- A high risk to individuals: the breach must be reported to the ICO within 72 hours, and the individuals concerned must also be told directly, without undue delay
Whether a breach sits at “risk” or “high risk” comes down to two things: how likely the harm is to happen, and how serious it would be if it did. The ICO’s own guidance illustrates this with a simple contrast: the theft of a customer database that could be used for identity fraud would need reporting, given the likely impact on those affected, but losing a staff telephone list normally would not.
The same logic applies to the forms on your website. A leaked vacancy or pupillage application, which may include an address, career history, and sometimes health or financial information disclosed for reasonable adjustments, sits much closer to the “customer database” end of that scale than a general enquiry with just a name and email address. The more sensitive or identifying the information, the higher the likely risk, and the more likely notification becomes.
These are tight timeframes, and they apply from the moment of discovery, not from the moment the form was submitted, or the vulnerability was first exploited. The less data sitting on a website at any given time, the smaller the potential scope of any breach, and the more manageable the response.
Source: ICO, personal data breaches: a guide
Data retention
Data retention means how long you keep information before deleting it. UK data protection law doesn’t prescribe fixed periods for most purposes, but it does set a principle, usually called storage limitation: personal data should be kept only for as long as you need it for the purpose you collected it.
That qualification is the important part. The test isn’t how long the data might conceivably be useful, it’s how long it serves the purpose it was gathered for. Once that purpose has been met, the reason for holding the data falls away, and what’s left is exposure.
For website forms, it helps to treat this as two separate questions:
- How long does the organisation need this information? A general enquiry may be finished with in days. A pupillage or vacancy application may need to be kept for years, both for equality monitoring and in case a selection decision is later questioned. Many chambers’ own recruitment policies already commit to a retention period, and those commitments should drive the answer.
- How long does it need to sit on the website? Almost always, far less time.
These two questions get conflated, and that’s where sites end up holding years of applications in the database. A pupillage application that needs to be retained for several years doesn’t need to be retained on the website for several years. Once it has been exported to wherever recruitment records are properly kept, the website copy is a duplicate, sitting on a public-facing server, protected only by the security of the site. Clearing it down doesn’t shorten your retention period. It just moves the data somewhere more appropriate.
It’s also worth checking that deletion is actually deletion. Data often persists in places that a retention setting doesn’t reach:
- Entries sitting in the form’s trash or spam folder rather than being permanently removed
- Uploaded files, which may remain in the site’s uploads folder after the entry itself has gone
- Database backups, which may hold copies for weeks or months after deletion. If you keep 90 days of backups, your real retention period is 90 days. That said, your website backups are almost certainly highly secure.
- Copies pushed to connected services, such as a mailing list, CRM or case management system
None of these are reasons not to set a retention period. They’re just the difference between a policy that works and one that only looks like it does.
You should also consider a documented retention policy. Setting a policy that covers the site as a whole, rather than form by form, means these decisions don’t need to be revisited each time a new form is added.
Regulatory context
Most organisations using website forms, whether a chambers, a law firm, or a membership or subscription body, already work within some form of existing regulatory, professional, or confidentiality obligation, be that a regulator, a governing body, or a code of conduct specific to the sector. Website data handling isn’t a separate concern sitting alongside those duties, it’s an extension of them. The same standard of care that already applies to how member, client, or applicant information is handled should apply equally to how it’s collected, stored, and retained on your website.
Why not delete immediately?
You can set a website form to send its submissions to you by email and not save any data at the website’s end. But here are a few practical issues with that.
- Emails can go astray, get missed in an Inbox or accidentally deleted. This can lead to missed enquiries, applications or lost income. Having a second place to check for the submissions gives you a chance to look for anything missing.
- Even worse, emails can get lost silently. Here’s a situation we’ve encountered many times: we set up a website form for a client and email notifications are working fine. A year or two later, the client changes IT company. The new IT firm migrates the client to a new mail platform and sets up new security rules. Emails sent from the website to the client are suddenly diverted into a quarantine folder… and nobody is told about it.
- If storing entries in the website, you can download them in bulk to a spreadsheet. If receiving each email individually, the data collation task is yours.
- Email itself isn’t a secure medium.
A short retention period on the website itself acts as a safety net for these situations, without leaving data sitting there indefinitely.
Our recommendation
Given this, we recommend holding form submission data, including any attached files and data synced to connected platforms, on your website for as short a time as reasonably possible. Most organisations find that retaining general enquiries for around 15 to 30 days strikes a workable balance. This gives enough time to conduct a scheduled check of the website copies and pick up any submissions that may not have arrived correctly in your email inbox, while keeping the amount of data held on the site itself to a minimum.
For application processes you may wish to keep data on the website for longer, because of the benefits it gives you (such as an online committee moderation system) – but you should balance these benefits against the risk of keeping data on the website.
Other best practices
Reducing how long data sits on your site is one part of the picture. A few related practices are worth considering at the same time:
- Data minimisation. Only ask for what’s genuinely needed on each form. A field that isn’t collected can’t be breached.
- Keep the form questions low-risk, and ask for confidential data to be sent by other means. (Ask us, or your agency, for advice on such methods.)
- Access control. Review who internally can see submitted form data, and whether that access is limited to those who actually need it.
- Keeping software patched. Prompt updates to WordPress core, plugins, and themes are the main defence against the kind of vulnerability exploitation described above.
- Two-factor authentication. This should be enabled on all admin accounts for the website. You may also decide to restrict access to your WordPress dashboard to certain network IP addresses.
