Nonprofit Data Protection: Beyond the GDPR Checklist
Key takeaways
- A GDPR-compliant privacy policy and cookie banner are the floor, not the ceiling; the real risks live in the website itself rather than in the policy.
- Consent gathered for one purpose, such as a photograph taken for a grant report, does not automatically cover ongoing display on a public website, and identifying vulnerable individuals carries safeguarding as well as data protection risk.
- A typical site loads many third-party scripts, and if cookie consent does not block non-essential ones before consent is given, they run even on pages where sensitive data is entered.
- Form submissions routed to a shared inbox with no access controls or retention period do not meet the requirement to keep personal data no longer than necessary.
- Valid consent for case studies must be specific and informed; a blanket media consent form signed on joining a programme does not cover a particular website use.
- The Board is the data controller and can delegate operational management but not accountability, so it should receive an annual review of website data, third-party processors, and cookie consent.
Summary
Most nonprofits have a GDPR-compliant privacy policy on their website. Fewer have thought carefully about what that policy actually says, whether it accurately describes the data the website collects, how it is processed, and where it goes. And fewer still have connected the privacy policy to the data governance infrastructure that GDPR actually requires: records of processing activities, data processing agreements with third-party platforms, retention policies, and a clear process for responding to subject access requests.For nonprofits, the stakes of data governance failure extend beyond the GDPR fines that receive the most public attention. Beneficiary data — particularly for organisations working with vulnerable populations, survivors of abuse or conflict, or individuals with sensitive health or immigration status — is a safeguarding obligation as much as a data protection one. A data breach that exposes beneficiary information is a governance failure with consequences that extend well beyond regulatory penalties.This post covers website data governance for nonprofits: how to audit what data the website actually collects and processes, including data collected by third-party scripts and embedded forms that may not appear in the privacy policy; how to write a privacy policy that accurately describes the actual data processing rather than using generic template language; how to configure cookie consent so that data is only collected when consent is genuinely given; how to establish the processing agreements with third-party platforms that GDPR requires; and how to connect website data governance to the broader organisational data protection framework so that the Board can be assured the organisation is meeting its obligations.
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
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.
Frequently asked questions
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.
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.
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.
