Every year, new state privacy laws pass. California did it first with the CCPA, Colorado followed with the CPA, then New York, Virginia, and others. Each law is slightly different, with different thresholds and different timelines, and the result is a patchwork rather than a standard. If you operate nationally you might fall under California law, Colorado law and New York law simultaneously, each with its own requirements. This lesson gives you a practical framework rather than a legal treatise: which laws apply to you, what they require when they do, and what you can do once that covers you across most of them.

The Basic Question: Does This Law Apply to My Nonprofit?

Most state privacy laws exempt nonprofits from some or all of their requirements, which is genuinely good news, but the exemption is not uniform and reading it as uniform is where organizations get into trouble. The word "nonprofit" does different work in each statute. In some it depends on your registration status, in others on what you do with the data, and in at least one it does not appear as an exemption at all.

• CCPA (California): Nonprofits are generally exempt if they are registered 501(c)(3). But if you sell or license donor data, you are not exempt.
• CPA (Colorado): Nonprofits are exempt if registered and operating as a nonprofit.
• NY SHIELD Act: Applies to all, including nonprofits. No exemption.
• Virginia Consumer Data Protection Act: Nonprofit exemption if registered.

The practical rule that comes out of those four lines is this: if you are a registered 501(c)(3) nonprofit that does not sell personal information, you are exempt from most state privacy laws, with New York as the exception. If you are not registered, or if you sell or license data, you are subject to these laws. Two conditions therefore decide your position, and both of them are facts about your own organization rather than judgment calls: your registration status and whether data ever leaves your hands for value.

Your action is correspondingly concrete. Verify your 501(c)(3) status rather than assuming it, and confirm with your state attorney general whether you fall under their privacy law. That second step matters because the exemptions are drafted at state level and interpreted at state level, and the office that would enforce the law against you is also the office best placed to tell you whether it reaches you.

For Nonprofits Subject to Privacy Law

If you are subject to state privacy law, whether because you are in New York, because you sell data, or for any other reason, the requirements sort into a small matrix. The table below covers the three laws this lesson sets out in detail. Virginia's Consumer Data Protection Act carries the nonprofit exemption described above for registered organizations, and is included in the exemption list rather than the requirements table because its separate obligations are not detailed here.

Read down the requirements column and a pattern appears. California and Colorado are about transparency and individual rights: telling people what you hold and honoring their requests about it. New York is about security and breach response: having reasonable protections in place beforehand and telling people promptly when those protections fail. They are two different kinds of obligation, and an organization can be strong on one and completely unprepared for the other. That distinction is what drives the strategy in the next section.

One Practical Solution: Do California and New York

If you are compliant with the California CCPA on data protection and the New York SHIELD Act on breach notification, you are mostly covered across the states. The reasoning is straightforward. CCPA sets the strictest privacy protections, the SHIELD Act sets the fastest breach notification, and other states usually land at similar or less strict requirements. Building to those two ceilings means you are not maintaining a separate compliance program per jurisdiction, which is the trap organizations fall into when they try to satisfy each law on its own terms.

What that looks like in practice is a short list, and it is short enough to hold in your head:

1. Have a privacy policy that says what data you collect, how you use it, and how long you keep it.
2. Provide a way for people to request access or deletion, for example a published address such as [email protected].
3. Respond to requests within 45 days.
4. Have a breach response plan that includes notifying people within 30 days if data is breached.
5. Have reasonable security, which is the subject of Cybersecurity for Nonprofits: The Essential Checklist.

Those five things carry most of what these state laws ask of you. They are not a legal opinion and they do not substitute for checking your own position with counsel or your attorney general, particularly if you sell data, hold sensitive categories of information, or operate in a state not discussed here. But they are the practical core, and an organization that has done all five is in a fundamentally different position from one that has done none of them.

Practical Implementation

Spread the work over months rather than attempting it in a week, because most of it involves finding out what you actually do rather than deciding what you would like to do. Month 1: audit your data. What personal information do you collect? What states are your supporters in? Do any state laws apply to you? This is the month that answers the applicability question with evidence instead of assumption, and it frequently surprises people, because the systems that quietly accumulate personal data are rarely the ones anybody thinks of first.

Month 2: write or update your privacy policy and make it public on your website. It should cover what data you collect, how you use it, how you protect it, how long you keep it, and how people request access or deletion. The retention question is the one most policies dodge, and it is worth answering honestly, because a stated retention period you actually follow is more defensible than an unstated one you never examine.

Month 3: establish processes for access and deletion requests. Create an address such as [email protected] where people can send them, and document a process for responding: pull the record, send it to the requester, and delete it if that is what was asked. The point of documenting it is that the request will arrive on a week when the person who knows how to do it is away.

Month 4: document your breach response plan, which is developed in full in Incident Response Planning: What to Do When You Get Breached. Month 5 and onward is ongoing: respond to requests within 45 days, monitor for breaches, and update your privacy policy when your practices change. That last clause is the one that quietly fails, because practices change through ordinary decisions, a new CRM or a new email platform, and nobody thinks of those as privacy events.

Common Pitfalls

Pitfall 1: assuming the nonprofit exemption covers everything. It does not cover New York. It does not cover data sales. Those are two specific gaps in an exemption that otherwise does a lot of work for registered 501(c)(3)s, and both of them are easy to walk into without noticing. Check your specific situation rather than relying on the general shape of the rule.

Pitfall 2: burying the privacy policy so nobody can find it. It should be easy to locate, with a footer link and a clear label. People should be able to read it and understand what you do with their data in about two minutes. A policy written to be technically complete but practically unreadable satisfies nobody, and it particularly fails the donor who went looking for it because something already made them uneasy.

Pitfall 3: not responding to access requests. A donor asks what data you hold and the email goes unanswered. That violates these laws where they apply to you and it is bad practice everywhere else. Respond within 45 days. The organizations that miss this are rarely refusing on purpose; the request simply arrives in an inbox with no owner and no process behind it, which is exactly what month three is for.

Pitfall 4: keeping data longer than you need it. If someone has not given in five years and is not a prospect, delete them, or truly anonymize the record. Keeping data "just in case" is extra liability with no matching benefit: every record you hold is a record that can be requested, breached, or misused, and the ones you no longer have a use for carry all of the risk and none of the value.

Anti-Patterns

• Treating "we are a nonprofit" as a complete answer. The exemption depends on registration and on whether you sell or license data, and New York's SHIELD Act does not offer one at all.
• Writing the privacy policy from a template without checking it against practice. A policy that promises a retention period nobody follows is worse than no stated period, because you have now documented the gap yourself.
• Having a privacy address that nobody owns. Publishing [email protected] without deciding who reads it and what they do converts a compliance measure into an unanswered inbox.
• Planning for requests but not for breaches. California-style rights and New York-style breach notification are different obligations. Doing one well does not prepare you for the other.
• Collecting data because the form field exists. Everything you collect is something you have to disclose, protect, produce on request and eventually delete.
• Letting practice drift away from the published policy. New tools and new integrations change what you collect and where it goes; the policy has to be updated when they do.
• Treating "just in case" retention as free. Old records carry the same breach exposure and the same access obligations as current ones.

Practice Prompts

• Write down your registration status and whether your organization has ever sold, licensed, rented or exchanged personal information for value. Those two facts decide most of your exposure, so record the evidence, not the impression.
• List the states where your supporters actually live, then check that list against the laws described here and against anything your attorney general publishes for your state.
• Read your current privacy policy end to end and mark every sentence you cannot demonstrate is true today.
• Time yourself locating the privacy policy on your own website starting from the homepage, then ask someone who does not work for you to do the same.
• Draft the access request process on one page: who receives it, what they pull, what they send, in what format, and how it is logged.
• Take the last data access request you received, if you have had one, and reconstruct how many days passed before it was answered.
• Identify every record of a supporter who has not given in five years and is not a prospect, and decide, in writing, whether it is being kept for a reason or by inertia.

Reflection

Imagine a donor emails tomorrow asking for everything you hold about them, and then imagine the same week bringing a breach notification from one of your systems. Both scenarios test the same underlying question, which is whether your organization knows where personal data actually lives. Most nonprofits discover that they can describe their data practices at the level of the CRM and lose the thread beyond it: the spreadsheet on somebody's laptop, the event registration platform used once, the mailing list that predates the current database. Compliance work does not begin with policy language, it begins with that inventory, and the honest version of it is usually longer than expected.

Glossary

• CCPA. The California Consumer Privacy Act. Registered 501(c)(3) nonprofits are generally exempt, unless they sell or license donor data.
• CPA. The Colorado Privacy Act. Nonprofits are exempt if registered and operating as a nonprofit.
• NY SHIELD Act. New York's law covering data security and breach notification. It applies to all organizations that do business in New York and collect personal information, including nonprofits, with no exemption.
• Virginia Consumer Data Protection Act. Virginia's state privacy law, carrying a nonprofit exemption for registered organizations.
• Personal information. Name, address, email, phone, IP address, donation amount, transaction history: anything that can identify an individual.
• Anonymized data. Data with no way to identify the individual, even with additional data. It is not personal information.
• Pseudonymized data. Data where identifiers are replaced by a code while you still hold the mapping. It usually counts as personal information.
• Access request. A person's request to know what data you hold about them, answered by compiling their record and sending it, within the applicable timeline.
• Deletion request. A person's request that you delete the data you hold about them.
• Data Processing Agreement (DPA). The agreement with a vendor governing how they handle your data, including their security obligations and their duty to notify you of breaches.
• Reasonable security. The standard of protection the SHIELD Act requires you to have in place before anything goes wrong.

Related Lessons

The security measures these laws assume you already have are set out in Cybersecurity for Nonprofits: The Essential Checklist, and the breach response plan referenced in month four is developed in Incident Response Planning: What to Do When You Get Breached. For the ethical dimension of the same duties, and the donor-facing commitments that go beyond the legal minimum, see Donor Data Privacy: Your Legal and Ethical Obligations. Vendor obligations, including the Data Processing Agreement discussed in the final question below, are covered in Third-Party Vendor Risk: Protecting Data Across Your Tool Chain. If you have supporters outside the United States, GDPR for Nonprofits with International Supporters adds a separate regime, and if you are putting personal data through AI systems, Data Privacy and AI: A Nonprofit Compliance Guide covers what that changes. The staff behaviors underneath all of it are in Staff Cybersecurity Training: The 1-Hour Program That Sticks.

Closing

State privacy law is complex, but for most nonprofits it boils down to four commitments: be transparent about what data you collect, protect it, respect people's rights to access and delete it, and notify quickly if you are breached. Most nonprofits, and especially 501(c)(3)s that do not sell data, are exempt from most of these laws, so much of this is not strictly required of you. Adopt the practices anyway. They are the same practices that make a donor comfortable telling you something personal, and the same ones that mean a bad week involves a plan rather than an improvisation. You are building trust, reducing liability, and doing right by your supporters, and only one of those three depends on which state you happen to be in.

Key Takeaways

• Most state privacy laws exempt nonprofits, but the exemption varies by statute and is not a general immunity.
• CCPA generally exempts registered 501(c)(3)s unless they sell or license donor data. Colorado's CPA exempts registered nonprofits. Virginia's CDPA carries a nonprofit exemption for registered organizations.
• The NY SHIELD Act applies to all organizations doing business in New York that collect personal information, including nonprofits, with no exemption.
• Verify your 501(c)(3) status, and confirm with your state attorney general whether their privacy law reaches you.
• CCPA and CPA both allow 45 days to respond to requests. The SHIELD Act requires notification without unreasonable delay, and within 30 days of discovering a breach.
• Building to California-level privacy practice plus New York-level breach notification covers most of what other states ask, without running a separate program per jurisdiction.
• The practical core is five things: a privacy policy stating collection, use and retention; a route for access and deletion requests; responses within 45 days; a breach plan with 30-day notification; and reasonable security.
• Implement over months: audit the data, publish the policy, build the request process, document the breach plan, then maintain all four.
• The recurring pitfalls are assuming the exemption covers everything, hiding the policy, ignoring access requests, and retaining data with no reason to hold it.

Frequently Asked Questions

Do we need a lawyer to comply with state privacy laws? For a first draft privacy policy, no, you can write one yourself from a template. For complex situations, such as selling data or holding sensitive data, yes, consult a lawyer. For a nonprofit with standard donor data, doing the basics of a privacy policy, an access request process and breach notification is doable in-house.

If we operate in multiple states, do we follow all state laws or the strictest one? Legally, you follow all applicable laws. Practically, if you follow California and New York, the strictest on their respective dimensions, you are mostly compliant with the others, and it is far easier than running ten different compliance programs. So adopt California-level practices and New York breach notification, and you are covered in most places.

What counts as "personal information" for these laws? Name, address, email, phone, IP address, donation amount, transaction history: anything that can identify an individual. Fully anonymized data, where there is no way to identify the person even with additional data, is not personal information. Pseudonymized data, where the record says ID 12345 but you hold the mapping, usually counts as personal information.

How do we handle a data access request? Pull their record from your CRM and compile everything you hold about them: name, address, email, phone, donation history, volunteer history, event attendance. Send it by email or a secure portal. Respond within 45 days. Keep a log of requests recording when each was received, what was sent, and when it was sent.

Are we liable if a vendor gets hacked and donor data is exposed? It depends on your Data Processing Agreement with them. If they suffered a breach despite reasonable security, having done everything right and still been hacked, you are probably okay. If their security was negligent, with no encryption, no backups, and warnings ignored, you might be liable. Have agreements in place requiring vendors to maintain reasonable security and to notify you of breaches.

How long should we keep donor data? Long enough to serve the purpose you collected it for, and no longer. The worked example in this lesson is the supporter who has not given in five years and is not a prospect: delete that record, or truly anonymize it. State in your privacy policy how long you keep data, and then actually follow what you stated.