GDPR and Nonprofits: The Compliance Landscape

GDPR applies to nonprofit organisations in the same way it applies to commercial businesses. Being a registered charity or a values-led organisation does not reduce your obligations under UK GDPR and the Data Protection Act 2018. The ICO (Information Commissioner's Office) has investigated and fined charities. The most common failures are not sophisticated data breaches — they are basic compliance gaps that could have been addressed with a systematic review.

For nonprofits, the stakes of non-compliance extend beyond regulatory fines. Donor trust is a core asset. A data breach or an ICO investigation that becomes public damages the credibility that takes years to build. The Communications Director who oversees a data compliance failure at a nonprofit faces a very different institutional consequence than their counterpart at a commercial company — the damage is to the mission, not just the brand.

This checklist covers the website-specific compliance obligations that apply to most nonprofits. It is not a comprehensive GDPR audit covering all organisational data processing — that requires a Data Protection Officer or specialist legal advice. It is a structured review of the elements that a Webflow nonprofit site needs to have in place and be able to demonstrate.

Section 1: Privacy Policy

Every nonprofit website must have a privacy policy that meets the transparency requirements of UK GDPR Article 13 and 14. The policy must be accessible from every page — typically via a footer link.

Checklist

• Privacy policy is published on the website and linked from the footer
• The policy is written in plain English — not legal boilerplate that a service user or donor cannot understand
• The policy states who the data controller is: the organisation's full legal name, registered address, and charity number
• The policy names a Data Protection Officer or a data protection contact if applicable
• The policy lists each category of personal data collected (name, email, IP address, donation amount, etc.)
• For each category, the policy states the lawful basis for processing (consent, legitimate interests, legal obligation, etc.)
• The policy explains what the data is used for
• The policy states how long data is retained before being deleted or anonymised
• The policy explains data subjects' rights: access, rectification, erasure, restriction, portability, objection
• The policy explains how to exercise those rights — a contact email or process
• The policy states whether data is shared with third parties, and if so, which categories of third parties (email platforms, CRM providers, donation processors, analytics tools)
• If data is transferred outside the UK or EEA, the policy explains the basis for that transfer
• The policy includes a date and a "last reviewed" note — and is actually reviewed and updated when data practices change

Common failures on nonprofit privacy policies:

Using a template policy that doesn't reflect actual data practices. Listing data categories that the organisation doesn't actually collect, or omitting categories it does. Referencing a DPO contact that no longer exists. Never updating the policy after adding new third-party tools (a new CRM, a new donation platform, a new analytics tool).

Section 2: Cookie Consent

UK GDPR and the Privacy and Electronic Communications Regulations (PECR) require informed consent before placing non-essential cookies on a user's device. "Non-essential" means anything beyond cookies strictly necessary for the website to function — which includes analytics cookies (Google Analytics) and any advertising or tracking cookies.

Checklist

• A cookie consent banner or pop-up is present on the site and appears to new visitors before non-essential cookies are set
• The banner offers a genuine choice: Accept, Decline, and Manage Preferences — not just an Accept button
• Analytics and advertising scripts are blocked by default until the user consents (confirmed by testing in a browser with network monitoring, as described in R-05)
• Google Consent Mode V2 is implemented via GTM if the organisation uses Google Analytics or Google advertising (see R-05)
• A cookie policy page explains what cookies the site uses, categorised by type (Necessary, Functional, Analytics, Advertisement)
• The cookie policy is linked from the consent banner
• Consent records are logged — CookieYes or your chosen CMP stores a record of when consent was given and what choices were made
• The consent implementation is tested after any significant site change or addition of new third-party scripts
• Consent preferences can be changed by the user after initial choice — not just at first visit

The most common compliance failure: A cookie banner that appears to offer consent controls but doesn't actually block analytics scripts until consent is given. This is not compliant. R-05 covers how to verify correct implementation using browser developer tools.

Section 3: Forms and Data Collection

Every form on the nonprofit website — contact forms, newsletter sign-ups, donation forms, event registrations, service enquiries — collects personal data and must be compliant.

Checklist

• Every form states clearly what the data will be used for, either in a note adjacent to the form or via a clear link to the privacy policy
• Where consent is the lawful basis for processing (typically for marketing and newsletter subscriptions), there is an explicit, unticked opt-in checkbox — pre-ticked boxes are not compliant consent
• Where legitimate interests is the lawful basis (typically for contact and service enquiry forms), this is stated and the privacy policy explains the balancing test
• Donation forms comply with the requirements of the donation platform's privacy terms — Fundraise Up, Donorbox, and Enthuse each have their own data processing terms that the organisation must have accepted
• Data submitted through forms is not retained indefinitely — there is a defined retention period and a process for deleting or anonymising old form submissions
• Webflow native form submissions, if used, are reviewed and cleared on a regular schedule rather than accumulating indefinitely in the Webflow dashboard
• Where forms collect sensitive data (health information, safeguarding referrals, financial information), enhanced security and retention policies are in place

Section 4: Third-Party Tools and Data Processing Agreements

Every third-party tool that processes personal data on your behalf — Google Analytics, HubSpot, Mailchimp, CookieYes, your donation platform — is a data processor. UK GDPR requires a Data Processing Agreement (DPA) between your organisation (the data controller) and each data processor.

Checklist

• A list of all third-party tools used on the website that process personal data has been documented
• Data Processing Agreements are in place with each tool — most major platforms (Google, HubSpot, Mailchimp, Donorbox) provide standard DPAs that must be accepted in the platform's settings or terms of service
• Google Analytics: the DPA is accepted in Google Analytics account settings; data retention is set to the minimum appropriate period (14 months is the maximum before data is automatically deleted)
• Google Tag Manager: a DPA with Google is in place covering GTM's data handling
• HubSpot: the DPA is accepted in HubSpot account settings — this is a specific step in HubSpot's settings that many organisations skip
• Donation platform: the platform's data processing terms have been reviewed and accepted
• CookieYes or chosen CMP: the platform's data processing terms are in place
• The list of third-party processors is reflected accurately in the privacy policy

Why this matters: If the ICO investigates a complaint, one of the first things they check is whether data processing agreements are in place with the tools being used. An organisation that has GDPR-compliant consent mechanisms but no DPA with Google Analytics has a compliance gap that is straightforward to identify and difficult to justify. In Blueprint Audits, I check for DPA completion on every tool the site uses — the HubSpot DPA is the most frequently missing, because it requires a deliberate step in account settings that isn't part of the default onboarding flow.

Section 5: Data Subject Rights

Anyone whose personal data you hold has rights under UK GDPR: the right to access their data, correct it, have it deleted, restrict its processing, and object to processing based on legitimate interests. Your organisation must be able to respond to these requests.

Checklist

• There is a named person or role responsible for handling data subject access requests (DSARs)
• The contact email or process for submitting a DSAR is clearly stated in the privacy policy
• The organisation can fulfil a DSAR within one calendar month (the UK GDPR deadline)
• There is a process for deleting or anonymising an individual's data across all systems — CRM, email platform, form submissions, donation records — if a right to erasure request is made
• Staff who interact with website data are aware of their obligations when a data subject request is received

Section 6: Children's Data

For nonprofits working with children or young people — or whose website may be accessed by under-18s — additional obligations apply.

Checklist

• If the website is likely to be accessed by children under 13, the Age Appropriate Design Code (Children's Code) applies — this includes stricter requirements around consent, default settings, and data use
• Forms and registration processes that may be used by under-18s do not rely on parental consent mechanisms that are easy to circumvent
• If the organisation processes special category data relating to children (health, ethnicity, safeguarding information), a Data Protection Impact Assessment (DPIA) has been completed

Section 7: Breach Response

Data breaches must be reported to the ICO within 72 hours if they are likely to result in a risk to individuals' rights and freedoms. A breach doesn't have to be a hack — it can be an email sent to the wrong recipient, a spreadsheet shared with the wrong person, or a form submission database left unprotected.

Checklist

• There is a documented data breach response procedure — who is notified internally, who reports to the ICO, what information must be included in the notification
• Staff who manage website data know what constitutes a reportable breach and who to contact
• Contact details for the ICO's breach reporting portal are documented: ico.org.uk/report-a-breach

Section 8: Website-Specific Documentation

Beyond the privacy policy, two additional documents are expected on most nonprofit websites.

Cookie Policy

A cookie policy is separate from the privacy policy and specifically covers what cookies the site uses. Most CMP platforms (CookieYes) generate a cookie declaration automatically that can be linked from the site. Keep this updated — when new tools are added to the site, the cookie declaration should reflect the new cookies they set.

Accessibility Statement

While not a GDPR document, an accessibility statement is a legal requirement for public sector bodies and expected by funders. It belongs in the same footer cluster as the privacy policy and cookie policy. A template is provided in R-27.

What the ICO Expects From Charities

The ICO publishes specific guidance for charities and voluntary organisations. Key areas of emphasis in their charity-sector guidance:

Fundraising communications. Email fundraising requires genuine, freely given consent — pre-ticked boxes, bundled consent, or consent obtained as a condition of service access are not compliant. The ICO has investigated charities specifically for non-compliant fundraising consent practices.

Legitimate interests for contact and engagement. Many nonprofit communications to existing supporters, service users, and stakeholders can be based on legitimate interests rather than consent — but a legitimate interests assessment (LIA) should be documented and the right to object must be clearly communicated.

Transparency with beneficiaries. Organisations working with vulnerable people have heightened obligations around how they communicate data practices. Plain language, accessible formats, and proactive communication about data use are expected.

Further Reading

• How to Set Up CookieYes and Google Consent Mode V2 on a Webflow Nonprofit Website
• Charity Commission Compliance: UK Nonprofit Website Requirements
• Accessibility Statement Template for Nonprofits