A lot of nonprofit privacy policies start life as a for-profit template with the company name swapped out. That approach misses what's actually distinct about how a nonprofit collects data: donations, recurring giving, mailing lists built from donor and volunteer records, and a legal landscape where the usual assumptions about which laws apply don't hold the same way they do for a business.
Are nonprofits even covered by privacy law?
The answer depends entirely on which law you're asking about, and it splits in a way that surprises a lot of nonprofit staff.
CCPA generally doesn't apply. Cal. Civ. Code 1798.140 defines a covered "business" as an entity organized for the profit or financial benefit of its shareholders or owners. A genuine 501(c)(3) doesn't meet that definition, and the statute doesn't carve out a separate nonprofit category the way some other laws do, it simply falls outside the definition entirely for most day-to-day fundraising and outreach activity. Narrow exceptions exist, a nonprofit operating a for-profit subsidiary, or in a joint venture with a covered business, but a standard donation-and-newsletter operation sits outside CCPA by default.
GDPR runs the opposite direction: there is no nonprofit exemption anywhere in the regulation. If your organization processes the personal data of anyone located in the EU or EEA, a recurring donor in Berlin, an international newsletter subscriber, a volunteer coordinator based in Dublin, GDPR can apply exactly the same way it would to a for-profit business. Mission, size, and revenue don't factor into GDPR's scope test at all. A purely domestic US nonprofit with no EU-connected donors, subscribers, or volunteers may genuinely sit outside both laws, but that's an increasingly narrow position once a newsletter or a crowdfunding campaign reaches an international list.
An international affiliate structure adds another layer worth checking directly rather than assuming. A US nonprofit with a sister organization, chapter, or program office operating in the EU is, in most structures, a separate legal entity from that affiliate, but the two often share a donor database, a CRM, or a shared email platform. If donor or supporter data actually flows between the US organization and an EU affiliate, that data-sharing relationship needs its own honest look under GDPR, independent of whether the US entity has any direct EU donors of its own.
Where nonprofits actually collect data
Walking through a typical nonprofit's data flows usually surfaces a shorter, more specific list than a generic business template assumes: donation forms (name, email, address, and payment details handled by the processor), recurring giving or subscription management, a donor CRM used for stewardship and reporting, email or mailing list tools used for newsletters and appeal campaigns, volunteer and event signup forms, and grant application data if the organization also applies for or administers grants.
Name your donation processor and CRM specifically
The same rule that applies to naming a checkout processor on an e-commerce site applies here, just with different vendors. "We use trusted third-party services" tells a donor nothing. Naming Stripe, PayPal Giving Fund, Classy, Givebutter, or Network for Good, whichever platform actually processes the transaction, tells them exactly who handles their card or bank details, since that's usually the platform, not the nonprofit itself, that stores the sensitive payment data.
A separate donor CRM used for stewardship, Salesforce Nonprofit Cloud, Bloomerang, Neon CRM, DonorPerfect, is a distinct data recipient from the payment processor and needs its own mention, since it typically holds donation history, contact preferences, and engagement notes that never touch the payment processor at all.
Larger nonprofits running major-gift or capital campaigns often add a category smaller organizations don't have at all: prospect research and wealth screening tools like DonorSearch or WealthEngine, used to estimate a potential major donor's capacity and giving history before an ask is made. This is a meaningfully different kind of data processing from a standard donation form, since it involves compiling information about a person, sometimes drawn from public records and third-party data brokers, that they never directly handed over. A policy that only describes what happens after someone chooses to donate says nothing about that earlier research step, initiated by the organization rather than the prospect, and organizations that use these tools should name them specifically rather than folding prospect research into the same generic language used for the CRM.
What a nonprofit policy needs beyond a standard commercial one
What a nonprofit policy needs beyond a standard commercial one
| Standard policy | Nonprofit addition | |
|---|---|---|
| Payment handling | Names the checkout processor | Also names the donation platform |
| Tax records | Not usually applicable | Explains tax receipt retention |
| Recipient database | Customer or user database | Donor CRM like Bloomerang or Salesforce |
| Mailing list handling | Newsletter signup checkbox | Appeal emails bundled at donation time |
| Volunteer and event data | Not applicable | Volunteer signup and event tools |
Mailing lists and appeal emails need their own disclosure
Most nonprofits fold every new donor and subscriber into recurring appeal emails automatically, often through the same form used to process a one-time gift. That needs its own honest disclosure. Under CAN-SPAM, every marketing and appeal email needs a working unsubscribe link that's honored promptly. For any EU-connected subscribers, the lawful basis matters and needs to match reality: a soft opt-in based on an existing donor relationship is a different legal footing than affirmative consent for cold outreach, and claiming "opt-in only" while a newsletter checkbox is pre-checked at the donation form isn't an accurate description of what's actually happening.
This matters even for organizations that never intended to build a "marketing list" in the first place. A donor who gives once, gets added to a general newsletter by default, and starts receiving quarterly appeals has been enrolled in ongoing marketing communication as a side effect of donating, whether or not anyone on staff thought of it that way. The policy should describe that actual behavior, one-time gift leads to ongoing appeal emails unless the donor opts out, rather than a more cautious-sounding line about only emailing people who "signed up for updates," if that's not really how the mailing list gets built in practice.
Keep the effective date current
A nonprofit's vendor list tends to grow the same way a business's does: a new giving platform for a specific campaign, a peer-to-peer fundraising tool for an annual event, a ticketing vendor for a gala. Each of those is a new data recipient the policy needs to name, and treating the vendor list as a living document, revisited whenever a new tool touches donor or volunteer data, avoids ending up with a policy that accurately described last year's stack and nothing since.
Board turnover and staff transitions are a quieter version of the same problem. A policy that names a specific data protection contact, a development director, an operations lead, whoever fields data requests in practice, needs that name or role kept current when the person changes, and the effective date at the top should move whenever anything substantive in the document does, not just on an annual schedule set arbitrarily in advance. A nonprofit's real advantage here is usually a smaller, more stable vendor list than a growth-stage business has, which makes keeping the policy honest a lighter lift once the initial version accurately reflects the actual fundraising and communication stack.
Our Privacy Policy Generator builds a policy around the data your organization actually collects, including donation processors, donor CRMs, and mailing list tools, so the document matches your real fundraising setup rather than a generic commercial template. For more on structuring a policy around a specific document or process, see our step-by-step mobile app privacy policy guide or our section-by-section anatomy of a compliant privacy policy.
The information in this article is for informational purposes only and should not be construed as legal advice on any matter, and does not create a lawyer-client relationship.
