Nonprofit Data Protection: Beyond the GDPR Checklist

GDPR compliance is the floor, not the ceiling

Most nonprofits approach data protection as a compliance exercise. There is a privacy policy on the website, a cookie consent banner was installed at some point, and someone once completed a GDPR awareness training. The organisation ticked the boxes. The boxes are not the point.

The broader governance question, the one most organisations have not answered, is whether the website actively creates data protection risks that the Board has not been made aware of and has not approved. These risks do not live in the privacy policy. They live in the website itself: in the third-party scripts loading on every page, in the case study photographs used to illustrate programme impact, in the form submissions routing to shared inboxes, and in the contact details of beneficiaries that appear on programme pages without explicit consent for that use.

The ICO does not distinguish between intentional and negligent breaches when determining whether to investigate. And while the regulator's enforcement posture has shifted in recent years, with only two UK GDPR fines issued in 2024/25 compared to more than 200 in the same period in both Germany and Spain, reduced enforcement activity does not mean reduced organisational risk. It means that reputational damage from a breach, rather than a regulatory fine, is now the more immediate consequence for most charities. Donor trust is not recoverable in the same way a fine can be paid.

The governance risks that checklists miss

Beneficiary data on programme pages

Programme pages often include photographs, case studies, and quotes from beneficiaries. These are legitimate and important: they demonstrate impact, build emotional connection with funders, and communicate the organisation's work at a human level.

The data protection risk lies in how this content was gathered and what it was gathered for. A photograph taken at a community event in 2019 for use in a grant report is not automatically consented for ongoing display on a public website. A quote from a service user that was captured for a newsletter is not automatically transferable to a prominent homepage feature. The consent obtained for the original purpose may not cover the current use, and the safeguarding implications of identifying vulnerable individuals on a publicly indexed website are significant, regardless of the original consent obtained.

Most organisations have no documented process for reviewing whether the consent obtained for a photograph or case study covers its current use. This is a governance gap, not a technical one.

Third-party script data leakage

A typical nonprofit website loads between 10 and 30 third-party scripts on every page: analytics tools, advertising pixels, social media embeds, chat widgets, fundraising platform integrations, and cookie consent management layers. Each of these scripts has access to the page and, in some configurations, to data entered into forms on the same page.

If cookie consent is not correctly configured to block non-essential scripts before consent is given, all of those scripts are running on every page visit, including on pages where sensitive personal data is being entered. A donation form page that loads a Facebook pixel before consent is a data protection failure, regardless of whether the organisation intentionally configured it that way.

The configuration of cookie consent is not a one-time task. It requires regular review as new scripts are added, as platform updates change how scripts are loaded, and as new integrations are installed. The question is not whether cookie consent is installed. It is whether it is currently working correctly for every script on every page.

Form submissions and data retention

Contact forms, volunteer enquiry forms, grant reporting forms, and event registration forms all collect personal data. Where does that data go? In most small-to-medium nonprofits, the answer is an email inbox, often a shared one with no clear access controls and no documented retention period.

UK GDPR requires that personal data is not kept longer than necessary for the purpose for which it was collected. An email inbox containing five years of contact form submissions does not satisfy that requirement. Nor does a situation where three current staff members and two former employees still have access to a shared inbox containing enquiries that include personal, financial, or health-related information.

The governance requirement is to document where form data goes, who can access it, how long it is retained, and how it is deleted. That documentation does not need to be complex. It needs to exist and be reviewed periodically.

Informed consent for case studies and testimonials

Beyond beneficiary photographs, case studies and testimonials create specific consent obligations that are frequently misunderstood. Consent under UK GDPR must be freely given, specific, informed, and unambiguous. A blanket media consent form signed on joining a programme does not satisfy the specificity requirement for ongoing use in a website case study. The individual must know what they are consenting to, in sufficient detail to make a genuine choice.

This is particularly important for organisations working with vulnerable populations: people experiencing homelessness, survivors of abuse, individuals with mental health diagnoses, or people with insecure immigration status. For these groups, the safeguarding implications of online identification extend beyond data protection into personal safety. The Board has a governance responsibility to ensure that the policies governing case study use adequately reflect those risks.

The Board's data governance responsibility

Under UK GDPR, the organisation is the data controller. The Board of Trustees, as the governing body, holds ultimate responsibility for ensuring that the organisation fulfils its obligations as a data controller. This is not a delegatable responsibility in the sense of making it someone else's problem. The Board can delegate the operational management of data protection, but it cannot delegate the accountability.

In practice, this means the Board should receive an annual data protection review that covers: the categories of personal data the organisation holds through its website, the third-party processors involved (including those embedded in the website), the current state of cookie consent implementation, and any known risks or gaps. Most Boards do not receive this. Most Communications Directors do not prepare it, because no one has asked them to.

What good website data governance looks like

Good data governance at the website level is not complicated, but it requires deliberate decisions rather than inherited assumptions.

It starts with a data mapping exercise: identifying what personal data the website collects, where it goes, who has access, and for how long it is retained. This should cover form submissions, analytics data, cookie data, any user account systems, and the third-party processors involved in each.

It requires a consent policy for case studies and beneficiary content: who can give consent, what they are consenting to, how consent is documented, how long it remains valid, and what happens when a case study needs to be removed because someone withdraws consent or circumstances change.

It requires a cookie consent configuration review at least annually, and whenever new scripts or integrations are added. The review should confirm that non-essential scripts are blocked before consent, that the consent log is being maintained, and that the cookie policy accurately reflects what the site currently uses.

And it requires a clear process for responding to data subject requests: individuals asking to see the data held about them, requesting deletion, or withdrawing consent. That process should be documented, tested, and known to anyone who might receive such a request.

These are not technical requirements. They are governance requirements that happen to have a technical expression on the website.

The connection to funder credibility

Institutional funders, particularly those operating under their own governance obligations, are increasingly alert to data protection standards in the organisations they fund. A grant-maker that processes personal data in partnership with a funded organisation has its own accountability obligations. If they cannot satisfy themselves that the organisation manages data appropriately, that becomes a due diligence concern at the application stage, not just a compliance matter after funding is secured.

For more on how funders assess organisational credibility through the website, the nonprofit website funder credibility post covers the specific elements institutional funders look for. The cookie consent and GDPR compliance post addresses the technical configuration requirements in detail. And the GDPR compliance checklist in the Resources section provides a structured review tool for the website-specific obligations.

FAQ

Question 1: Does GDPR apply differently to charities and nonprofits than to commercial organisations?

The obligations are substantively the same. Charities are data controllers and must comply with UK GDPR in the same way as commercial organisations. The ICO has historically applied a more lenient enforcement posture toward charities and public bodies, particularly for one-off breaches without serious harm. However, that leniency does not reduce the legal obligation, and it does not protect against reputational damage, donor trust loss, or the operational disruption caused by a breach. The Data (Use and Access) Act 2025 introduced a new ‘charitable purpose soft opt-in’ for email marketing, but this does not affect the broader data protection framework for website operations.

Question 2: What is the biggest data protection risk most nonprofit websites have right now?

In practice, the most common gap is third-party script management: analytics, social media pixels, and fundraising integrations that are loading before cookie consent is given, or that are loading on pages where sensitive data is being entered. The second most common gap is undocumented consent for beneficiary photographs and case studies, particularly for content that has been on the website for several years and was originally gathered for a different purpose. Both are governance failures rather than technical ones, and both can be addressed without technical expertise once the problem is clearly identified.

Question 3: Does the Board need to be involved in website data protection decisions?

Yes. The Board holds ultimate accountability as the governing body of the data controller. In practice, this does not mean the Board makes every data protection decision. It means the Board should receive an annual summary of the organisation's data protection position as it relates to the website: what data is collected, who processes it, what the current risks are, and what governance policies are in place. If a significant breach were to occur, the question asked by the ICO and by funders would be what steps the Board had taken to ensure appropriate governance. An annual review, recorded in Board minutes, demonstrates that oversight was being exercised.

If your organisation is uncertain about the data protection risks in your current website, the Blueprint Audit includes a review of cookie consent configuration, third-party integrations, and governance document completeness as part of the assessment. Learn more about the Blueprint Audit.