Encryption isn't a strategy. It's a key-management problem

"It's encrypted" ends a lot of conversations that should continue. Encryption moves the problem; it doesn't remove it. The question that matters is who can get the key, and whether you'd know.

What encryption actually does

It turns a data-protection problem into a key-protection problem. That's a good trade when the key is harder to reach than the data was. It's a bad trade when the key sits next to the data, in a config file, in a script, in a backup, or in the memory of a service that anyone with admin can read.

The questions to ask

• Where is the key, and what can read it?
• Who can request decryption, and is each request logged?
• If the application is compromised, can the attacker decrypt everything the application could?
• When was the key last rotated, and would rotation break anything?
• Can you prove, for a regulator, that a given record was encrypted with a key nobody else held?

Where this goes wrong

Most commonly at the application layer. The database is encrypted at rest, the storage is encrypted, the backups are encrypted, and the application that reads all of it runs with a credential that can decrypt every row. One compromised application and the encryption was theatre.

What good looks like

Keys held in a system built for holding keys, with access decisions made per request. Separation between the people who manage keys and the people who manage data. Rotation that's been tested. And a clear answer to "what would an attacker with full control of this server be able to read."

Encryption done this way is a real control. Encryption as a checkbox is a false sense of safety, and it's the kind that shows up in breach reports.

If your answer to "is it encrypted" is yes and your answer to "who holds the key" is a pause, that's worth a look.

Explore: More on privacy and cryptography · Work with me