The People Your Breach Harms Are Not Your Employees

The people your breach harms are not your employees.

Most breach planning I have seen inside mission-driven organizations assumes the reverse. The tabletop exercise centers on the staff who will scramble to respond. The cyber-insurance conversation centers on the organization's own liability. The board briefing centers on reputation, on donor confidence, on whether the fall campaign goes out on schedule. Each of those concerns is legitimate, and every one of them is about us. Let me provide a different scenario:

A woman arrives at a family-violence shelter on a Tuesday night with two children and a bag she packed in four minutes. She gives the intake worker her old address, her new location, the name of the person she is hiding from, the school her children will quietly transfer into. She hands all of it over because the shelter cannot help her without it, and because she has decided, under conditions most of us will never face, to trust the organization in front of her. The details here are composited from more than one place, though the shape of it is ordinary. That intake record goes into a database that sits on the same network as the development team's mailbox, behind the same aging firewall as everything else the shelter runs.

If that database leaks, follow where the harm actually goes. A donor who reads about the breach can decide to give again next year or not. She cannot decide to un-disclose where she sleeps.

When a mission organization holds data about vulnerable people, a breach transfers harm onto the people that organization exists to serve. The damage to the organization is real, and it is secondary. That reordering changes what the security program is for. Our controls were never there to protect the organization. They are there to protect her.

We are used to thinking about breach cost in a particular way, because the language was built by industries where the stolen thing is money. When a retailer loses a million card numbers the harm is real, but it is bounded and it is reversible. A bank can cancel a card and issue a new one in short order. The fraud is generally reimbursed. The system is built to make the victim close to whole, and that model has quietly become the default picture of what a breach is, even in organizations whose data has nothing to do with cards.

The data a mission org holds does not behave that way. No one can reissue a survivor a new safe location. An immigration status, a diagnosis, a teenager's visit to a clinic their parents know nothing about: once those are exposed they stay exposed, and no process exists to put them back. The harm is the kind a person lives with afterward. A bank can send a new card. No one can send a person a new past.

This is where the internal math goes wrong. A resource-constrained organization does what responsible stewards are supposed to do, which is weigh the cost of a control against the loss it is protecting against. The intake system needs $15,000 of work to encrypt it properly and tighten who can reach it. Leadership models the realistic exposure, lands somewhere near $60,000 in legal review, notification, and staff time, decides the risk is survivable and the money does more good in programs, and moves on. Every step in that reasoning is careful, and it runs on a ledger with a column missing. The logic is sound. The inputs are wrong. Fifteen thousand dollars got weighed against sixty thousand dollars of institutional inconvenience, and what it costs her to be found appears nowhere in the calculation, because it never lands on the organization's books at all.

I have sat in versions of that meeting. Nobody in the room is careless. The finance lead is protecting program dollars that serve real people this quarter. The executive director is weighing a maybe against a certainty. The treasurer is asking exactly the question a treasurer is supposed to ask. What fails them is the framing, which seats the organization in the chair marked at-risk while the person actually at risk is sitting in the intake room three doors down. The conversation that would fix it takes about ninety seconds.

"What happens if the intake database gets out?"

"We notify. Lawyers, probably a regulator, a lot of staff time."

"What happens to the people in it?"

Silence is a fair answer to that question, because nobody has ever been asked to compute it. Change the ledger and $15,000 stops looking like overhead and starts looking like the price of keeping a promise.

Consent is the harder piece of this. We tell ourselves that the people in our databases agreed to be there, and technically that is true. But a woman choosing between disclosing her location and sleeping in her car did not consent the way a shopper consents to a loyalty program. A family handing immigration details to the one legal-aid office that returned their call did not shop around. Much of the most dangerous data a mission org holds was given under need, sometimes under duress, always with fewer alternatives than the word consent implies. The less freely someone could withhold their data, the more we owe them for holding it.

What changes, then? Three things, and none of them waits on a budget increase.

First, map your data by who gets hurt. Compliance frameworks sort information into categories that matter to auditors, which is useful, and which is a different question from what happens to a human being if this leaks. The records where the answer is that someone could be found by a person they are hiding from are your most sensitive holdings, whatever a regulatory schedule calls them. Fund those ahead of the systems that merely carry a label.

Second, put a person rather than a policy at the center of your incident planning. Most tabletops open with the sentence "the organization has been breached," and everything downstream of that sentence is about the organization. Try opening instead with the intake database exposed and four named people whose safety now depends on how fast and how honestly you act. That single change reorders every decision that follows it, including the notification decisions that organizations too often make to protect themselves rather than to warn the people who need warning.

Third, give your board the real stakes. The reason to fund security here is not to avoid a fine or a bad news cycle. It is that your mission is a promise made to specific people, and the data you hold is where that promise is kept or broken. A board that understands its exposure in those terms funds differently than a board managing reputational risk. They can carry the real version, and they deserve the chance to decide with the true number in front of them.

The woman who arrived on Tuesday night will never see your network diagram. She will never read your policy, or know whether the encryption project got funded, or hear the word tabletop. She trusted you with the one set of facts that could undo everything she did to get herself and her children somewhere safe.

So before your next board meeting, open the list of systems you run and find the one holding records that could locate a person who is hiding from someone. Price what it would take to protect it properly. Bring that number to the board with the reason attached, and say the reason plainly, because a board that hears it funds differently than a board that never got asked.

We are not protecting data. We are protecting her. Build the program as though that were the point, because it is.