Donor data privacy under GDPR and CCPA: what advancement teams need to know

If your organization holds personal data about donors who are EU or UK residents (GDPR/UK GDPR) or California residents (CCPA/CPRA), those laws very likely apply to your donor data regardless of where your organization itself is based. These regimes follow the person, not your headquarters. Here’s what advancement teams need to know, in plain terms, and where good data practice already does most of the work.

This is a general educational overview, not legal advice. For your specific obligations, consult counsel.

Does GDPR or CCPA apply to donor data?

Often, yes. The trigger isn’t where your nonprofit sits; it’s whose data you hold and, sometimes, your scale of activity. If you have EU/UK donors in your CRM, GDPR concepts likely reach that data; if you have California donors and meet CCPA’s thresholds, it likely reaches theirs. Many advancement shops are surprised to learn they’re in scope (an alum who moved to Berlin, a major donor in Los Angeles) without ever having targeted those regions.

The core obligations, in plain terms

Both regimes differ in detail but rhyme on principle. The donor-facing essentials:

• A lawful basis / right to opt out. GDPR wants a lawful basis (often consent or legitimate interest) to process personal data; CCPA centers a right to opt out of sale/sharing. Either way: you need a defensible reason to hold and use the data, and a way for people to say no.
• Access & portability. People can ask what you hold about them and, under GDPR, get it in a portable form. You have to be able to find and produce one person’s data.
• Deletion. People can ask you to delete their data (“right to erasure” / “right to delete”), subject to some exceptions. You have to be able to honor it.
• Data minimization & retention. Hold only what you need, only as long as you need it. Indefinite “keep everything forever” is increasingly hard to defend.

What this means for day-to-day advancement work

You don’t need to become a privacy lawyer to be in reasonable shape. Practically:

• Capture consent/preferences as real, reliable fields, not a note someone typed. Opt-outs have to be enforceable by every system and every AI tool that touches the record (this is where it meets AI governance).
• Be able to assemble one donor’s full record to answer an access request, which is just a constituent 360 view pointed at a different purpose.
• Set retention schedules instead of keeping everything forever.
• Know what you share with vendors, because sending donor data to a third party is exactly the movement these laws scrutinize.

Why “raw data never leaves your walls” helps directly

This is where good architecture becomes a compliance asset. Privacy-preserving analytics keeps the computation with your data and lets only aggregates out, so you can analyze and even benchmark against peers without the cross-border data transfer that triggers the hardest GDPR/CCPA questions.

A practical starting checklist

1. Map what you hold and roughly where your donors are (any EU/UK or California residents?).
2. Make consent and opt-out real fields, enforced everywhere, including by AI tools.
3. Be able to produce and delete one person’s data on request.
4. Set retention schedules and stop hoarding by default.
5. Audit vendor data-sharing and minimize what leaves your walls.

What you get

A donor-privacy posture you can explain to a board or a regulator without panic, far less exposure because less data ever leaves your control, and (not coincidentally) a cleaner, better-governed database, since most of what these laws ask for is just good data practice with legal teeth.

For the security/governance picture, see How It Works; to locate your gaps, take the self-assessment.

General educational overview, not legal advice. Examples use synthetic data; the standard is open and early. Treat current releases as drafts.