Work With Us
Resources

9 Ways To Keep Your Community’s Sensitive Data Away From Danger

Updated:

Written by Design Action Collective

Time to read:

16–24 minutes

This article is adapted from a workshop we presented at the Nonprofit Technology Conference in 2026 alongside our friends from Sassafras Tech Collective, titled “Keep Sensitive Community Data Safe: Avoid Knocks from the Feds and Being Doxxed.”

May First Movement Technology raises the power of the 99% by providing community organizers with servers for databases and email. They are an incredibly important partner in the fight for collective liberation, and they are the steward of a large amount of sensitive information about our community. So… what happens when law enforcement asks them to have a peek?

In 2014, law enforcement did just that. The US government issued May First a subpoena to turn over personally identifying information about members of the Athens Indymedia Center (Athens IMC)1. But May First was concerned that the information could be used to take criminal action against the Athens IMC. So with the support of their lawyers from the Electronic Frontier Foundation, they refused the request. And they were successful.

This isn’t the first or the last time our community will be at risk of losing sensitive information to bad actors. And no one succeeds in blocking these leaks 100% of the time. So if you were issued a subpoena, then, as the steward of your community’s data, how do you keep them safe?

The best way to ensure that you don’t pose a risk to your community is simply to not collect data in the first place. But for several reasons, you may need to. In this article we talk about the actors who want information about your community, the reasons you collect this data, and 8 principles you can use to keep your people safer.

Table of Contents

3 actors who may want data about your people

We can slot these bad actors into a few categories: Doxxers, ransomware gangs and law enforcement.

Doxxers (trolls and political vigilantes)

Sometimes the people after your community data are trying to cause emotional distress.

Remember when Milo Yiannopoulos reportedly planned to out U.C. Berkeley students who were undocumented? This information could have put a target on the students, both from other right-wing actors as well as law enforcement. But where did he get his information from? If he had access to your databases would he be able to put other immigrants at risk?

Ransomware gangs

Ransomware gangs may not be politically motivated but they sure are looking for money. Here’s how their basic scheme works:

  1. They get access to sensitive information in your database.
  2. They threaten to release the data unless you pay.

A report by Nonprofit Tech For Good stated that 27% of nonprofit organizations worldwide fell victim to a cyber-attack in 2023. Breaches like these don’t just threaten your funding; if bad actors access your databases or web services, they can sell sensitive data while eroding your community’s trust. Or they can shut down your digital infrastructure and completely halt your digital organizing. Read more about the harm hackers can cause.

Law enforcement

When law enforcement wants your information, they have a few special tools at their disposal: subpoenas and search warrants.

Even organizations that don’t want to give up information may be required to or risk serious legal action. Sometimes, as in the example from May First, they successfully fight a request. But that doesn’t always work.

For example, Proton Mail was ordered to provide information to the Swiss government about an individual suspected of being linked to an action at Stop Cop City. In this case, Proton was compelled to provide bank information about one of their customers, which the U.S. government used to build a case against the activist.

Email content was not shared, nor was meta-data about the emails. But it was still enough to cause damage.

How could a Proton client stay safe from this kind of leak?

This leak was able to happen because Proton had financial information stored about their client. If you need to keep your identity separate from your payment information, consider using one of these anonymous methods: cash, prepaid debit cards, bitcoin.

What threat actors are you concerned about, and are there any that aren’t listed here? Share what you see with us by writing to info@designaction.org.

4 Reasons You Collect Data About Your People

Despite the dangers posed by those bad actors, there are still 4 reasons why we might collect sensitive information. Which of these apply to you?

Process payment information

If you handle money, donations, and purchases online, then you will need to collect sensitive information. Period. For example if you accept bank payments, then you will need someone’s name and banking information. There’s no getting around that unless they pay you in cash, a prepaid debit card, or cryptocurrency.

You use a community relationship manager (CRM)

If you use a community relationship manager then you certainly collect information about your people. Here are some reasons why this might be useful or necessary:

  • You are part of homeless and housing services, and your wrap-around care team tracks details about their visit with clients.
  • You provide free STI testing and you need to be able to tell the recipient their test results once the results arrive.
  • You organize donors, track their level of engagement, their funding interests and how often they give.
  • You organize a community to show up at actions and send them information via email and text message.
  • You want to segment your audiences in your CRM in order to send information that is more relevant to each person.

You want or need to show the efficacy of your work

You may be in a situation where someone else requires that you collect data. If you receive funds from a foundation or from the government, they may ask you to provide information about your community.

But even if you don’t have a funder asking to prove the efficacy of your work, you may want to know that information for yourself.

For example, if you will want to know if you are allocating your program resources effectively, then you may have outlined some measures of success for each work area, including some details about your community engagement.

You are looking for other insights

Finally, there are a lot of other reasons you might collect sensitive information:

  • To understand the places where your programs are difficult for people to access.
  • To get inspiration about the kinds of content to create for your website, newsletter and social media.
  • To understand why some people stop volunteering with you.
  • To know how easy it is for people to find information on your website.
  • To develop stronger personas in order to ensure that your community is centered in the work you do.

There are a lot of reasons we collect information. So let’s make sure we know how to keep it safe.

Best case scenarios when bad actors come looking for information

When bad actors get their hands on your data, how useful will it be for them?

Scenario A – The best case scenario

You have no information to give them.

Also known as the, “I didn’t hear nuttin’, officer,” scenario.

Scenario B – The best case scenario if a vendor you work with is compromised

If you do store information, then the organization who stores your information (like your host, or Google) could be compromised by hackers or by law enforcement.

But in this scenario you have a special defense: encrypted disks and decryption keys.

If your data is encrypted and the vendor doesn’t have the decryption keys, then what the bad actors get may be nothing but gibberish

48656e7279204d617263656e676572
42616e676572404a6f73682e636f6d
333033302031397468204176652c20506561726c736574746572204741203833383239

This happened to May First in April 2012. Under a search warrant issued to May First, the FBI seized a server containing information from their client, Riseup. But since the server was encrypted and May First didn’t have the decryption keys, the FBI got nothing but gibberish.

Scenario C – The best case scenario if your encrypted data and the decryption keys are compromised

But if a bad actor gets your encrypted data and the decryption key, then what?

If the data you collected is aggregated and anonymized, then that might impede the bad actor from doing anything that would put your people in danger.

We’ll cover aggregating and anonymizing in the next section.

9 Principles to minimize leaking sensitive information about your community to hackers and law enforcement

We are our community’s data stewards. They trust us to protect their sensitive information from political vigilantes, ransomware gangs and law enforcement. So our goal is to get as close to the scenarios A, B, and C as we can: from storing no data all the way to storing data that’s useless as a threat.

Here are 9 principles we can use to help us move closer to that goal.

Principle 1: Challenge every data point you plan to collect

I recently heard Lisa Jervis, co-founder of Bitch Magazine, use a funny term when referring to the data we keep and do nothing with: aspirational data. Aspirational data is the information you store with no clear purpose, but you hold onto it because you’re afraid you might someday need it. You dream of running a complex analysis using the “robust” data in your set, but you don’t have the time and you don’t even know what questions the data will help you answer.

This is aspirational data, and you should probably delete it.

And going forward, consider challenge every data point you plan to collect by asking: “What analysis requires this information?” and “Can I achieve the same results with less detailed data?” Because if you have the data, then someone else could get the data.

Principle 2: Secure your personal and work accounts so that community data doesn’t leak through you

Even if your work account is protected with strong passwords and multi-factor authentication, your private account may be the way a hacker breaks in.

This is how Last Pass was hacked in 2022 in a breach that affected 1.6 million people. Through an employee’s personal Plex account, A hacker was able to gain access to the Last Pass codebase by hacking into an employee’s personal Plex.tv account.

Want to know if any of your accounts are at risk? Go to haveibeenpwned.com and see.

The bad news is that most of us have had data breached. The good news in that a little over an hour you can take several steps to keep your accounts safer.

Read our data privacy recipe for a step-by-step guide. It’s totally free and it will help protect you from hackers looking for a weak link.

Principle 3: Ask for consent and be transparent about what you do with your people’s data

When you collect data, provide some context, give options and build trust.

  • What data you’re collecting?
  • How will you use it?
  • Who has access to it (and who do you share it with)?
  • What measures are in place to protect your community’s data?
  • And when will you delete it, or how can they request it be deleted?

Whether you use a web analytics tool like Matomo, collect information at an event using a sign up form, or are conducting a usability study, providing context empowers your people to make the right decisions for themselves about their data.

Depending on the kind of information you collect, you may also be required by law to manage the data and provide particular kinds of consent to store or share it.

If you store medical information, collect information about people in the European Union or California, then you may be required to follow special regulations. If you think a law may affect you, consult a lawyer to ensure you are properly managing your community’s data.

This is a non-exhaustive definition of personally identifiable information and sensitive information, as defined by the HIPPA, CCPA, GDPR, PCI DSS, and NIS2 frameworks.

  • Name and surname.
  • Email address.
  • Phone number.
  • Home address.
  • Date of birth.
  • Race.
  • Gender.
  • Political opinions.
  • Credit card numbers.
  • Data held by a hospital or doctor.
  • Photograph where an individual is identifiable.
  • Identification card number.
  • A cookie ID.
  • Internet Protocol (IP) address
  • Location data (for example, the location data from a mobile phone).
  • The advertising identifier of your phone.
  • Medical records, like test results and examination notes.

HIPPA regulations may apply to you if collect information about people’s health.

“The Privacy Rule standards address the use and disclosure of individuals’ protected health information (PHI) by entities subject to the rule. These individuals and organizations are called “covered entities.”

“The Privacy Rule also contains standards for individuals’ rights to understand and control how their health information is used. It protects individual health information while allowing necessary access to health information, promoting high-quality healthcare, and protecting the public’s health. The Privacy Rule permits important uses of information while protecting the privacy of people who seek care and healing.”

Learn more about the HIPPA.

This may apply to you if you collect information about people in California.

The California Consumer Privacy Act (CCPA) is a law that gives California residents more control over their personal information, including rights to know what data is collected and to delete it. Personally Identifiable Information (PII) refers to any data that can be used to identify an individual, such as names or social security numbers.

This includes:

  • The right to know about the personal information a business collects about them and how it is used and shared
  • The right to delete personal information collected from them (with some exceptions)
  • The right to opt-out of the sale or sharing of their personal information including via the GPC.

Learn more about the California Consumer Privacy Act.

This may apply to you if people from the European Union visit your website.

The General Data Protection Regulation (GDPR) is a European Union law that protects individuals’ personal data and privacy. It establishes rules for how personal data can be collected, processed, and stored, giving individuals more control over their information.

Here are examples of PII defined by GDPR:

  • Name and surname
  • Email address
  • Phone number
  • Home address
  • Date of birth
  • Race
  • Gender
  • Political opinions
  • Credit card numbers
  • Data held by a hospital or doctor
  • Photograph where an individual is identifiable
  • Identification card number
  • A cookie ID
  • Internet Protocol (IP) address
  • Location data (for example, the location data from a mobile phone)
  • The advertising identifier of your phone

This may apply to you if you process financial information.

PCI DSS is a global security standard that sets requirements for organizations that handle credit card information to ensure the protection of cardholder data. It aims to reduce credit card fraud and improve data security by establishing guidelines for storing, processing, and transmitting sensitive payment information. [From Wikipedia]

We’ve heard of some organizations that store donor information inside of unencrypted emails on Google’s servers––how secure is that?

This may apply to you if you provide communications infrastructure within the European Union.

NIS2 aims to enhance the security of network and information systems within the EU by requiring operators of critical infrastructure and essential services to implement appropriate security measures and report any incidents to the relevant authorities.

Learn more about the NIS2 directive.

Principle 4: Aggregate data to hide information about individuals

If a hacker gets access to your unencrypted information, one way you can protect your people is by aggregating sensitive data about them.

By aggregating data, you can still store important information while protecting individual’s privacy. For example:

When aggregating, don’t store “Sally is homeless. Henry is not.”

Instead, do store “50% of people who use our services are homeless at the time of receiving the service.”

When aggregating, don’t store “We interviewed Lola 15 years ago and here’s everything she said verbatim.”

Instead, do store “We conducted a usability study 15 years ago and here are the pain points, themes, and insights that we learned…”

When aggregating, don’t store “What is your specific age and address?”

Instead, do store “Please tell us which age range you are in. And could you share your zip code? Thank you.”

Aggregating data is a way to make it harder to identify a specific person, which makes your community safer.

Thinking about the data you collect and why, are there opportunities for you to aggregate data instead of storing information that can be linked to individuals? Can you aggregate the data at the time of collecting it, or would you need to process entries about individuals and then delete the original?

Principle 5: Anonymize data related to sensitive information

A second powerful way to prevent a hacker from getting useful information about your community is by anonymizing the data.

Let’s say for example you want to gather usability feedback about your program, and you decide to interview 6 people. You can anonymize their data by giving them fake names. And once you are done with the analysis, you can aggregate the data, saving just themes identified rather than the raw information.

Look for opportunities to anonymize data considered personal identifiable.

Principle 6: Keep your data encrypted and practice the principle of least privilege

Scenario B shows that by encrypting your data at rest, someone who gets the hard disk but doesn’t have the decryption keys get nothing but gibberish, with names, addresses and emails looking something like this:

48656e7279204d617263656e676572
42616e676572404a6f73682e636f6d
333033302031397468204176652c20506561726c736574746572204741203833383239

Unless you’re a technical person, knowing whether your data is encrypted may be easier said than done. So here is an email you can send to the people who manage your hard disks.

Who do you need to send this letter to?

Subject: Database Encryption at Rest – Configuration and Security Details

Hi [Host Support Team/Technical Contact],

I’m writing to request information about your encryption at rest capabilities for databases hosted on our account. We’re conducting a security review of our CRM/website database and need to understand your current encryption implementation.

Could you please provide the following details:

Encryption Status: Is Transparent Data Encryption (TDE) or similar encryption at rest enabled by default on MySQL instances, or does it need to be manually enabled? If manual, what’s the process?

Encryption Scope: What exactly is encrypted at rest (database files, log files, temporary files, etc.)?

Key Management: How are encryption keys generated, stored, and managed? Are keys stored separately from the encrypted data? Who has access to the keys?

Backup Encryption: Are database backups also encrypted at rest? How are backup encryption keys managed?

Performance Impact: Are there any known performance implications of enabling encryption at rest that we should be aware of?

Documentation: Do you have any technical documentation or guides on your encryption implementation that you can share?

We want to ensure our sensitive community data is properly protected, so any details you can provide would be helpful.

Thank you,

[Your Name]

Encryption protects in cases where the hard disks are stolen. But if a hacker gets your CRM credentials and gets into your account that way, how much damage can they do?

One great way to protect against this is to practice the principle of least privilege. In a phrase, this means that you restrict who has access to sensitive information. If 10 people have access to sensitive financial information, then that is 10 people who, if hacked, can leak that information. But if only one person on your team needs to process the sensitive financial information, and only they have access, then your community’s information is that much safer.

Principle 7: Make it a habit to avoid AI systems that you don’t own or control

If you can’t easily and permanently delete your data from an AI chatbot like ChatGPT, treat it like a billboard and only put in there the information that you would want shared to every passing driver on a highway.

If you purchase an AI plan, consider working with organizations that share our values of collective liberation and who actually give you the ability to delete your data.

Plus, setting up a AI model on your machine might be easier than you think. Using tools like Ollama, you can host open source AI models on your computer.

Principle 8: Delete data when you are done with it

After years of being an organization, you likely have information that has long become irrelevant.

When you ask, “Do I still need this information in order to complete a specific task?” If you have no clear answer, consider deleting the data. You can’t leak data that doesn’t exist, and I’m sure your community would appreciate the extra security.

  • Delete contact information once participant communication is complete.
  • Remove audio recordings after a transcription is verified.
  • And do you really need website traffic data from 20 years ago?

Principle 9: Run data privacy workshops with your people

One great way to keep sensitive data from leaking out of your servers is to help your community give you misinformation or no information.

For example, when the local free medical clinic runs STI tests, they need a name to connect the results to. But they don’t need a real name. So instead they give their community the option to share a pseudonym.

Please take our step-by-step data privacy recipe, use it to help your community improve their own security, and look for places where you can help your community make the right decisions about their data.

Together we keep us safe!

References

  1. More about May First Movement Technology’s history of protecting community data, and the steps May First takes to protect community data. ↩︎