Data security in crisis situations

Information is flying around fast and loose as you try to help people in need. Anyone who has capacity to help has been added to a spreadsheet tracking needs. If you’re in the thick of it, this piece isn’t for you yet. But even in those moments, be careful about who you share sensitive data with – there are big ramifications later if you get it wrong.

But when you can come back and slow down a little bit to think about the longer-term ramifications of data, you should come back and investigate this. Because while getting people the immediate help they need as quickly as possible is more important than keeping their data safe, the long term impacts of a data leak could put people already in harm’s way further in harm’s way. Example: collecting immigration status when determining which shelters will work for which folk could open you up to a subpoena or backdoor that leaks the data.

So far, I don’t know of any data breaches from community-led crisis response, but it’s frankly a second disaster waiting to happen. People offer admin access to EVERYONE involved in order to feel equitable. People are then scared to remove admin access to things because they don’t want to upset anyone. This leaves a very large attack surface for something to go wrong even beyond the flaws of the tool itself. So limit how many administrators you have, and have a regular cadence to check in on who has access as an admin and otherwise. Set up an impersonal rubric to remove access (“hasn’t accessed this data in x days” or “we’ll only have 3 admins, and we talk monthly about who is best in those roles” are two examples). 

To limit the impact of a data breach, collecting ONLY necessary data is the best way to design. You don’t need to be collecting demographic data unless you’re running an equitability study later. Example: address and risk level shouldn’t be cross referenced unless absolutely vital. 

Do not use one shared login for vital or administrative accounts. Most tools worth their salt will allow you to have multiple accounts log in for the same view, so set people up with individual accounts so the account access can be managed. Any person with a shared login will be able to change it for everyone else. 

Retrofitting later is a pain, but is worth the pain. If you’re in a place where you can migrate to a new tool for a longer-term vision, I’d recommend mapping out tool options against group considerations. I do a grid with rows for technical options, and columns for things I care about. Things like longevity of data, alignment of the org with your group’s politics, who the data is visible to, if the data can be sold to external parties, relationship with law enforcement, etc. I then indicate how aligned with my goals each option is, and discuss the resulting grid with the rest of the tech team. Here’s an example grid for picking which messaging platform to use with each other:

If you’re able to turn on multifactor authentication (MFA), that’s another point where you can limit who the admins are. Doing this can slow some things down and be at odds with people being able to take the day off, but it’s another vector along which security can be tightened up as things slow down in the response. 

What else should folks be doing?