GDPR (& CCPA)
July 1, 2020
Thanks to technology and digital-all-the-things, nonprofits’ mission fields have become extremely diverse and globalized. Although obviously important and beneficial, the primary downside is increased exposure to a wide variety of local/regional/national laws. As the locations of your donors, subscribers, program recipients, customers, etc. expand, so does your risks and liabilities when it comes to data. Regardless of an organization’s physical presence, any digital interactions are subject to various laws based on that individual’s residence.
It’s a good thing!
At first glance, the checkboxes you have to solve seem burdensome. But to be clear, the concepts are an overall good thing! Embrace the regulations (I can’t believe I just said that…)! For individuals, we frankly believe wholeheartedly that GDPR and CCPA are important and beneficial — and we hope to see similar concepts rolled out to more areas in the near future. But even in the absence of laws, your donors are investing in your organization and others trust you with their information. These common-sense rules protect them and you!
The catalyst for many of these changes started with the European Union’s General Data Protection Regulation (GDPR), which is now enforced as of May 2018. If your organization collects information from any individual living in an EU-member country, you’re impacted by the regulations. There are no exceptions due to an organization’s size or scope, meaning any nonprofit with an internet presence is affected.
In the following sections, we’ll provide an overview of the regulations and necessary steps:
Jurisdiction & Enforcement
- Any transaction, between any company/nonprofit and any individual residing in the EU (regardless of the organization’s physical location) resulting in data being collected.
- Play it safe! If your nonprofit has an internet presence that is used by EU residents in any way, assume it is subject to the GDPR. Even safer, assume that GDPR applies to any online presence!
- Enforced as of May 2018.
- Violations can result in 20 million euros, or 4% of your annual global “turnover”, whichever is greater.
- There are still many open questions about enforceability in the US, due to the nuances of treaties, EU-based entities and “representatives”, etc. However, don’t hide behind these! Again, these are best practices regardless. And as we’ll see later, the US now has its own set of related regulations (starting with CCPA).
Personally Identifiable Information (PII)
- Protected data is defined by the GDPR as information that could be used to directly or indirectly identify a natural person.
- Some information can point directly to a person on its own. Other pieces must be used collectively to identify a person, but they’re still considered PII.
- Examples (some may be surprising):
- Mailing address
- Email address
- Social media accounts
- IP address
- Bank numbers and other financial details
- Medical information
- Physical characteristics
- Location data (especially GPS coordinates)
- One of the primary concepts is the idea of explicit consent. Individuals must be able to clearly understand and explicitly consent to how you plan to use their information. Gone are the days of maintaining a list of email addresses and using them however you want.
- Consent is defined in extremely specific terms:
- Clearly/freely given.
- Granular and specific to a defined purpose.
- Informed and unambiguous.
- Given by an explicit act, as opposed to an omission (explicit opt-in, rather than ignoring an opt-out).
- Withheld by default, given only by an unambiguous act.
- Requested using clear, plain language (no long legal docs).
- Consent is never implied by other actions. As an example, information must be provided in order to make a donation online. However, that does not automatically give permission to use their info for other purposes, other than processing and communicating about the donation itself.
- An individual’s consent is kept in appropriate record keeping and proof is demonstrable.
Data Control Rights
- Individuals can easily request and receive any and all information you’re storing, as well as specific details about how it is being used.
- Individuals can easily correct/update any information.
- Individuals can easily opt-out and remove specific consent at any time, even if consent was previously given.
- Any and all data can be easily exported in a machine-readable format that can be migrated to other vendors.
- Individuals have the “right to be forgotten” and can easily request to have their information permanently deleted.
- “Need to know.” Limit access to staff with roles specifically requiring access to PII.
- The above also applies to software developer teams. Use finely grained controls for data access, rather than giving the keys to the kingdom by default.
- PII may be requested and stored only when it’s absolutely necessary and for a specific purpose.
- PII must be removed when no longer needed and no longer relevant.
- Encrypt PII when it is “at rest”, such as database storage. This at least prevents breaches from being able to do anything with it, provided that the attacker does not also have the decryption key.
- Primarily work with pseudonyms or unique identifiers for each individual. PII should be stored in an area that is fully separate from other user data. Ex: an individual’s donation history should be completely separate from their contact information. This makes it easier to delete PII in the future, as well as reduces the impact of data breaches.
- Less is more! Prevent the inclination to collect and store as much data as possible, “just in case”.
- Start projects with privacy rules as a primary objective, rather than trying to retroactively introduce rules after the fact.
The California Consumer Privacy Act (CCPA) is in the same vein as GDPR, specifically focused on California residents. Enforcement began in January 2020. It shares many similarities to GDPR, but with a few primary differences.
CCPA has no “prior consent” concept like GDPR, instead leaning more heavily on transparency and strong opt-out requirements.
More important, nonprofits are exempt. For this reason, we’re not diving into detail. However…
We firmly believe that similar laws will soon roll out to other states, possibly nation-wide. A lot hinges on FTC appointments, the 2020 election (both executive and legislative), etc. Further, CCPA always has the possibility of being amended.
For those reasons, we’d recommend using GDPR as a baseline, keeping an eye on CCPA, and being proactive now. Regardless of your current liability, it’s better to be steps ahead than steps behind!
Typical Blind Spots
In our work with nonprofits, we’ve seen the same set of gaps come up repeatedly. And that’s not to point fingers! You don’t know what you don’t know.
The following is a an overview of those areas:
- Not to throw anyone under the bus, but marketing teams are where we often see the most gaps, purely due to the nature of their work and data. A close second is fundraisers and donor development. Often, the inclination is to hyper focus on departments where security issues traditionally come up (especially finance and IT). But closer scrutiny is needed with teams focused on interacting with and tracking others.
- A lack of training for staff, ensuring they’re aware of regulations & best practices.
- No enablement or tools for staff, such as safe/encrypted file transfer, doc/spreadsheet tools, communication and collaboration platforms, etc.
- Staff using personal email, outside apps, or other platforms to handle data and docs.
- Inability to know and prove where data is stored, how it’s shared, and who has access.
- Collecting PII when you don’t actually need it, “just in case”.
- Collecting PII for a specific purpose, then later using it for other purposes without explicit consent. The standard example is storing donor email addresses, but sending them marketing messages without explicit consent.
- PII stored in various spreadsheets, both offline (Excel) and online (Google Sheets, Airtable, etc).
- Custom, in-house apps built without privacy-focused oversight. Even if things appear compliant, as an example, the app could be producing logs under-the-hood containing PII (unbeknownst to your team).
- Reliance on payment gateways (good) like Stripe, but still storing PII and financial data in-house (bad) rather than letting the gateways do their thing and purely storing the tokens they give you.
- Checked-by-default for any opt-in checkboxes. Or worse, not using opt-ins at all and instead displaying an opt-out checkbox.
- Over-reliance on “communication channel” platforms for storing a wide variety of customer data. One typical example: using Mailchimp as a source of record for contact data, rather than limiting it to a simple email pipeline and otherwise relying on a true CRM.
- Storing donor and transactional data in Quickbooks, rather than keeping donor data in your CRM and purely storing aggregate records in QB.
The Wrong Answer
Unfortunately, we also see nonprofits (and businesses) moving forward with the “wrong answer”. Although GDPR support seems insurmountable at first, it’s perfectly doable with a handful of best practices! However, the alternative is attempting to prevent EU citizens from using your services, subscribing, and donating. That’s obviously not ideal for your mission, especially if you feel called to serve Europe!
Even worse, shutting off that pipeline is extremely error prone. For example, it’s difficult to reliably determine someone’s location using an IP address or phone number. Even…worser?…both are fairly easy to circumvent using VPNs or digital phone services.
This isn’t much of an option anyway now that CCPA is in the mix. It’s hard enough to try and determine someone’s country. It’s impossible to reliably determine a state or region within the US.
Hopefully all this is a helpful starting point for auditing your own organization and implementing some urgent changes. However, if you’d like help, we’d love to partner with you.