Donor Data Privacy and Security for Nonprofit Websites

Nonprofits collect unusually sensitive information for organizations of their size. A donor record can reveal religious affiliation, political sympathy, health interest or immigration status simply by existing. A beneficiary record can reveal that someone used a domestic violence service or a food bank. And the organizations holding this data are frequently running on a handful of staff and a website built by whoever was available.

This is not an argument for alarm. It is an argument for a few specific decisions made deliberately rather than by default, because the defaults on a typical nonprofit website are worse than most boards realise.

Know what you are actually collecting

Start with an inventory, because most organizations underestimate this. Donation forms collect names, addresses, payment details and often employer information. Volunteer applications collect availability, references and sometimes background-check consent. Programme enquiry forms can collect health, family or immigration information. Newsletter signups collect email. Event registrations collect dietary requirements, which reveal religion and health.

Then ask a harder question for each field: what happens to the organization if this is exposed, and would we collect it if we had to justify it publicly? A dietary field on an event form is reasonable. Asking every enquirer for a date of birth because the form template had one is not.

Collect less

The most effective privacy control is not collecting the data. Every field you remove is a field that cannot leak, cannot be subpoenaed, and does not need protecting for the next decade.

Go through each form and delete anything you do not have a current use for. "We might want it later" is not a use. This single exercise usually removes a third of the fields on a nonprofit site and improves conversion at the same time, because shorter forms get completed more often.

Let the payment processor hold the payment data

Card details should never touch your server. Use a hosted or embedded payment field from a reputable processor so the sensitive data goes directly to them, and your site stores only a transaction reference.

This is not just risk reduction — it removes an entire category of compliance obligation from your organization. If a vendor proposes storing card data on your own infrastructure to give you a smoother checkout, treat that as a serious warning sign about the rest of their proposal, as covered in how to evaluate proposals.

Know where the data goes after the form

This is where most nonprofits lose track. A donation form might send data to a payment processor, a CRM, an email platform, an analytics tool, a fundraising plugin and a Google Sheet somebody set up in 2021. Each is a copy of the data and each is a place it can leak.

Map it once: for each form, list every destination and who at your organization can access it. The exercise commonly surfaces at least one integration nobody remembers configuring, and old integrations with live credentials are exactly what gets exploited.

Be careful with analytics and advertising tags

Third-party tags on pages that reveal something about the visitor deserve real thought. A tracking pixel on a "get help with domestic violence" page or an addiction service page is sharing behavioural data about vulnerable people with an advertising platform.

Decide deliberately which pages carry which tags. It is entirely reasonable to run analytics on your donation funnel and none at all on your crisis-service pages. Similarly, take care that URLs do not carry personal data in query strings, because those end up in analytics, in server logs and in referrer headers sent to other sites.

Write a privacy policy that describes what you actually do

Most nonprofit privacy policies were copied from a template and describe practices the organization does not follow. That is worse than no policy, because it is a written record of a commitment you are breaching.

A useful policy states plainly what you collect, why, who you share it with, how long you keep it and how someone asks for their data to be removed. Write it after the data-flow mapping, so it describes reality. Keep a version history — being able to show what your policy said in a given year is genuinely useful.

Decide how long you keep things

Retention is the control nonprofits most often skip. Donation records generally need keeping for financial and tax reasons. Volunteer applications from people who never volunteered, seven-year-old event registrations and abandoned form submissions usually do not.

Set a retention period per data type, write it down, and actually delete on schedule. A breach of data you no longer needed is entirely self-inflicted, and it is the version boards find hardest to explain.

Control access like it matters

The most common real-world exposure is not a sophisticated attack. It is a former staff member or volunteer whose CRM login still works, or a shared password in a document everyone can read.

Individual accounts, not shared ones. Two-factor authentication on anything holding donor or beneficiary data. A named person responsible for removing access when someone leaves, and a check that it happened. Accounts registered to the organization rather than to individuals — which is one reason it belongs in handover documentation.

Have a plan before you need one

Decide in advance who is called if donor data is exposed, who talks to the board, and who talks to affected people. Notification obligations vary by jurisdiction and by data type, and the middle of an incident is a poor time to research them.

The plan can be one page. Its value is that someone has thought about it while calm.

What to ask a web vendor

If you are procuring a rebuild, put these in the requirements: payment data never stored on your infrastructure; a documented data flow for every form; per-page control over third-party tags; no personal data in URLs; account and access model documented at handover; and a retention approach agreed rather than assumed.

Those requirements cost little at build time and are expensive to retrofit. We build to them as part of nonprofit website design, and the CRM side is covered in our guide to donor-retention CRM design.