July 17, 2026
Data Is Cash
Why your security problem is really an economics problem.

By happyelf
3 min read
The Timeless Laws: Data Is Cash
—
Revenue is vanity, profit is sanity, but cash is king. — Business proverb
The first time I truly understood that data is money, someone had just stolen a pile of it from a company under my watch, and it took me longer than I care to admit to even see where it had gone.
It was my first real security incident, and the timing was pointed. I was still new to the position, handed the title after years on the technical side, still quietly certain that security was a problem you solved by deploying the right tools. An attacker compromised an interface I did not know existed. I learned of it only when the CTO mentioned it, almost in passing, while reporting the incident, as though its existence were obvious to everyone but me. The environment had been tested not long before; this interface had simply never entered the scope. We had checked the doors we knew about, and the thief walked through one we didn't. There was no dramatic break-in, no malware with a clever name. What they walked out with were redeemable codes, though the word makes them sound more solid than they were. What they actually took were numbers.
Here is the thing about those numbers. Once you hold the number, you hold the value. You can spend it, sell it cheap to someone who will, or redeem it for a product and resell that. Every exit ends in money. The number was not a record of value sitting somewhere else. It behaved less like a record and more like a banknote that happened to live in a database.
That was the moment the idea I had been working by collapsed. I had been taught, like everyone in the field, to protect "information assets," a phrase vague enough to mean everything and therefore nothing. What had just happened made it concrete. A specific number, worth a specific sum, had been taken from a system I was responsible for protecting, and the loss was as concrete as if someone had opened the cash register and cleaned out the drawer.
The sum was almost trivial on the books, tens of thousands of dollars, material to a person but barely visible to a company that size. That was exactly what unsettled me. It was not the size of the loss that kept me up; it was how little friction there was between a string of digits and spendable cash. If this much could leak through a door no one had thought to lock, the real question was how much more sat behind doors we had never counted.
Data is cash.
Once you see data that way, a lot of questions that felt like engineering problems turn out to have an economic question sitting upstream of them. The engineering does not go away. But before you can decide how to protect something, you have to decide what it is worth, and to whom. Most of us were trained to do the first and skip the second.
So ever since that incident, there is a question I ask in the first hour of any risk assessment, and it almost always produces an uncomfortable silence: what is your data worth? Not "is it important." Everyone says it's important. I mean the number. A business expects its cash to be measured, reconciled, and reported. Very few can say the same about their data. The same people who would investigate a thousand dollars missing from petty cash will let entire databases sit ungraded and unpriced, because somewhere along the way the industry taught them that data is a technical asset to be protected, rather than something to be valued first.
That incident quietly changed how I worked. I stopped assuming I knew the shape of the thing I was defending, and started asking, of every system I touched, what else was out there that no one had told me about. Because here was the uncomfortable part: the interface was known somewhere in the organization. That knowledge had simply never reached the person whose job was to weigh its risk. The lesson was not that someone had failed to tell me. It was that our entire way of knowing what existed depended on someone remembering to mention it.
And even once you can see everything, "protect the data" is still not a real instruction, because not all cash is worth the same. A US dollar and a Vietnamese dong are both money; no one confuses the two, and no one guards them the same way. Data is exactly like this. A table of anonymized timestamps and a table of unencrypted payment details can sit in the same database, behind the same firewall, and still be worth wildly different amounts to whoever is trying to take them. The real work begins the moment you stop protecting all of it the same way and start asking, asset by asset, what this one is worth, and to whom.
None of which makes you safe. It makes you a target. The moment something is worth taking, someone, somewhere, starts working out how to take it, and they are reading the same balance sheet you are: the valuation that tells you what to protect is the one that tells them what to steal. That is where this goes next. But it starts here, with the question I still lead with, and still watch land in silence. Of everything you hold, do you actually know what you are there to protect?
Next, I want to talk about why treasure always means war, and why the job is not to fight harder but to fight fewer battles.
— -
Author's note: This essay is based on real events. Some details have been changed to protect confidentiality.