A simple way to think about protecting data throughout its lifecycle
Imagine walking into your local bank and encountering:
- Cash scattered on counters within reach of anyone
- Transfers placed in paper bags for unchecked couriers
- Safe-deposit boxes that don’t have registered owners
- Nobody is entirely sure what’s in the vault, yet some guy named Steve still has the keys to everything in this bank because he needed access for a project 6 years ago
You’d be insane to trust your money at this bank! Yet this is how many organizations manage their data.
We spend enormous effort securing networks, applications, infrastructure, and environments. All of that matters. But ultimately, those things exist to store, process, move, and protect data.
And data rarely stays put. So what if we treated data security a little more like a real bank treats money?
Welcome to the Data Bank
Before a bank can protect its assets, it needs to know what it’s protecting.
Who owns each asset? Where is it? What’s it worth?
That sounds obvious when we’re talking about money.
It should be equally obvious for data.
Data security starts with discovery and inventory. Know what data you have, where it came from, where it lives, who owns it, and how it’s being used.
You can’t protect something you don’t know exists.
And “we’re pretty sure that’s everything” isn’t an inventory.
Checking, Safe-Deposit, or Vault?
Once you know what you have, you can decide how much protection it needs.
Banks don’t treat every asset the same way:
Neither should we.
Some data is like a checking account. It’s used routinely. People need access to it. It still needs protection and accountability, but we don’t need three guards and a retinal scanner every time somebody checks the balance.
More sensitive data belongs in the safe-deposit box. Fewer people need access. Access should have a purpose. And we should probably know when somebody opens the box.
Then there are the crown jewels.
Those go in the vault.
This is the data where loss, manipulation, or exposure could have serious consequences. Give it the strongest protections available.
The goal isn’t to put everything in the vault. The goal is to know what deserves to be there.
Making a Withdrawal
Now somebody needs the data.
This is where things get interesting.
Being allowed to access an asset isn’t necessarily the same as being allowed to take it somewhere else.
Imagine a bank saying:
“Steve was authorized to enter the vault, so wherever he drove afterward was really none of our business.”
That’s not much of a security model, yet data access can work surprisingly close to this.
Someone may have a legitimate reason to access information. That doesn’t automatically mean they should be able to copy it anywhere, send it to anyone, or move it into an environment with weaker protections.
Access and release are different decisions.
Are you allowed to see it?
Are you allowed to take it?
Those are different questions.
Call the Armored Car
Eventually, data needs to move.
It might move between applications. Between environments. Between organizations. Across security boundaries. Maybe all the way to the tactical edge.
The moment cash leaves the bank, the vault can’t protect it anymore.
That’s why banks invented armored cars.
The protection should match the value of what’s moving.
For data, that might mean encryption, secure connections, identity verification, integrity checks, logging, and additional safeguards for particularly sensitive information.
But protecting the vehicle isn’t enough.
The route matters too.
You wouldn’t send an armored truck through somewhere you don’t trust just because Google Maps says it’s six minutes faster.
Data shouldn’t casually pass through places with weaker protections either.
Valuable data deserves an armored car, not a paper bag.
The vault protects a place. Good security protects the asset wherever it goes.
Where Are You Taking That?
There’s another important detail about armored cars.
They have destinations.
You don’t load a truck with cash, lock the doors, and tell the driver, “Looks secure to me. Good luck out there!”
The destination matters just as much as the journey.
Before sensitive data leaves one place, we should know where it’s going and whether that destination is authorized and prepared to protect it.
Permission to withdraw something isn’t permission to deliver it to any address you choose.
Are you allowed to take this data?
Are you allowed to take it there?
Keep the Receipt
Banks are obsessive record keepers.
Deposits. Withdrawals. Transfers. Recipients. Dates. Amounts.
There’s a reason for that.
Knowing where an asset is right now is useful.
Knowing how it got there is better.
Important data should have a story we can follow.
Where did it originate? Who accessed it? Where did it move? Was it changed along the way? Who ultimately received it?
When something goes wrong, “We think Steve sent it somewhere Tuesday” isn’t much of a chain of custody.
Closing the Account
Eventually, some data reaches the end of its useful life.
Maybe it needs to be archived. Maybe retention requirements say we need to keep it for a while. Maybe it’s time to destroy it.
Keeping everything forever because storage is cheap isn’t a strategy.
Every unnecessary copy becomes another asset somebody has to discover, classify, protect, monitor, and eventually deal with.
Yesterday’s useful dataset can become tomorrow’s forgotten liability.
When the lifecycle ends, retire the data deliberately.
Shred happens.
Protect What Matters
Data security doesn’t need to mean putting everything behind the biggest lock we can find.
It means understanding what we’re protecting and applying safeguards that make sense throughout its lifecycle.
Discover it.
Classify it.
Store it according to its value.
Control who can access it.
Protect it when it moves.
Verify where it’s going.
Track the journey.
Retire it deliberately.
Not everything needs a vault.
Not everything needs an armored car.
But the crown jewels probably shouldn’t be sitting in an unlabeled paper bag under Steve’s desk.





