Ask a team whether their data is secure and you will usually be told that it is encrypted at rest and in transit. Both statements are almost always true and neither one answers the question, because neither control addresses the way data actually leaks.

Security work on a data system only makes sense against a threat model, so start by writing down what you are defending against. The list is short and every entry has a different answer.

Physical media theft. Someone walks out with a disk, or a decommissioned drive is resold without being wiped. This is the threat that full-disk encryption was invented for, and against it, it works completely.

Backup and snapshot exposure. A database snapshot is shared to the wrong account, an S3 bucket holding dumps is made public, a backup tape leaves the building. Very common, very damaging, and full-disk encryption does nothing at all, because the snapshot is decrypted by the same automatic mechanism that decrypts the volume.

A compromised application. An SQL injection, a deserialization bug, a leaked API token. The attacker is now issuing queries through your application's own database connection, which is authenticated and authorized. Every encryption control in the system is transparently applying itself on the attacker's behalf.

Stolen credentials. A database password in a git history, a developer laptop with a .pgpass file, an over-broad IAM role. Same outcome: the attacker is a legitimate principal.

The malicious or careless insider. An engineer with production access runs a query no one asked for, or exports a table to a personal laptop for debugging. Authentication succeeds because it is supposed to.

The infrastructure provider. Your cloud vendor, or a subpoena served on them. This is the only threat model where client-side encryption with keys the provider never sees changes the answer.

What the grid shows

Line up the controls against the threats and a pattern appears immediately. Encryption at rest covers the first two rows and nothing below them. TLS covers an attacker on the network path and nothing else. Everything from the third row down, which is where essentially all real incidents come from, is stopped by authorization, by credential lifetime, and by auditing, not by cryptography.

This is not an argument against encryption. Encryption at rest is cheap, it is mandatory under most compliance regimes, and it genuinely closes the media-theft hole. It is an argument against treating it as the security work. A system with perfect encryption and one shared database superuser password in an environment variable is trivially compromised, and it passes the audit.

The controls that actually move the needle

Three properties do most of the work, and the rest of this lesson is about how to obtain them in a data system.

Short credential lifetime. A stolen password is valuable forever; a stolen fifteen minute token is usually worthless by the time it is found. Moving from static database passwords to short-lived tokens converts credential leakage from a breach into an incident.

Authorization that survives the application. If the database sees one principal for every human and every service, then all authorization lives in application code and is bypassed entirely by anyone who reaches the database. Pushing tenant and role boundaries into the data layer means a compromised application has a smaller blast radius than a compromised database.

Auditing that answers the read question. Most systems can tell you who changed a row. Very few can tell you who read it, and reads are what exfiltration looks like.

One more thing the grid exposes

The controls in a production database do not follow the data. When rows are replicated into a warehouse, exported to a lake, or loaded into a notebook, the row-level policies, the column grants, and the audit trail stay behind. A copy is a new system with a new and usually much weaker posture. That boundary is where the majority of sensitive-data exposure actually happens, and it is the subject of the last section of this lesson.