Data Security & Protection

Perimeter security answers "who's allowed in." Data security answers a different question: if someone gets in anyway — a stolen credential, a misconfigured bucket, a rogue insider — what do they actually walk away with? Those are not the same program, and treating them as one is why so many breaches involve data that was sitting in a system everyone assumed was already protected by something else.

Data-centric protection means the control travels with the data itself: encrypted at rest, encrypted in transit, tokenized where the raw value isn't needed, and access-logged regardless of which system, cloud, or OT network it happens to be sitting in that day.

The Data Protection Lifecycle

Five stages, looping back every time a new data store shows up — which, in practice, is constantly.

Where the Controls Map

NIST SP 800-53 and ISO 27001 Annex A describe most of the same controls in different language — useful when one audience asks for one framework and another asks for the other.

Encryption vs. Tokenization — the Distinction That Actually Matters

Encryption and tokenization both make sensitive data unusable to someone who shouldn't see it, but they solve different problems. Encryption is reversible by design — anyone holding the right key gets the original value back, which is exactly what you want for data that has to be reconstructed later. Tokenization replaces the value with a reference that means nothing outside the vault that issued it — the systems using the token never need the ability to reverse it at all. That's why cardholder data environments lean on tokenization: a breached system full of tokens has nothing a card network can charge, while a breached system full of ciphertext is only as safe as the key it never should have had access to in the first place.

How I'd Build the Program

• Classify before you buy anything. Encryption and DLP tools applied to an unclassified data estate protect a guess, not the actual sensitive data.
• Separate key custody from data custody. Whoever administers the database should not also hold the keys that decrypt it — that split is what makes the encryption mean something.
• Tokenize before you replicate. Every copy of raw sensitive data — into a data warehouse, a test environment, a partner feed — is another surface to protect; tokenize before the copy exists, not after.
• Extend the same controls to OT/IoT. A historian or PLC network holding operational data isn't exempt just because it predates the cloud program that protects everything else.
• Instrument for misuse, not just breach. A credentialed insider exporting an unusual volume of records looks nothing like an external attacker, and needs its own detection logic.

Where These Programs Actually Fail

• Encryption without key hygiene. Data "encrypted" with a key that never rotates and is readable by half the engineering org isn't meaningfully protected.
• Classification that stops at a spreadsheet. A data classification policy that never gets wired into scanning tools or access controls is documentation, not protection.
• Shadow copies outside the program's view. Exports to spreadsheets, ad hoc reporting databases, and personal cloud drives routinely hold more exposure than the systems everyone is busy securing.
• Treating OT/IoT as out of scope. Operational data often carries as much risk as anything in the cloud estate, with far fewer controls applied to it.
• No plan for key or certificate expiry. An expired key or certificate that takes down production teaches everyone to fear rotation instead of relying on it.