Data protection and encryption

Perimeter and identity controls protect access to data. These controls protect the data when those have already failed, which is the scenario worth designing for.

Classify before you protect, because you cannot protect everything equally

A short scale beats a detailed one — three or four levels that people can apply without a manual. What matters is that each level carries concrete handling rules: where it may be stored, who may access it, whether it may leave the environment, and how long it is kept.

Find it before you classify it. Sensitive data is rarely only where the architecture says it is: it accumulates in exports, analytics environments, test databases seeded from production, support tickets, and log files.

Know what each kind of encryption actually defends against

This is where claims get made loosely and expectations diverge from reality.

• In transit protects against interception on the network. Enforce it everywhere, including internal service-to-service traffic, and prefer a modern configuration over one accumulated over years.
• At rest, provider-managed protects against physical media theft and disk disposal. It does not protect against an application bug, a compromised credential, or an over-broad query — the storage layer decrypts transparently for anything with legitimate access. Full-disk encryption on a running server protects almost nothing about that server.
• Application-level or field-level protects specific fields from anything below the application, including database administrators and backups. It costs you searchability and indexing on those fields, which is a real design constraint rather than a footnote.

Choose deliberately. "Encrypted at rest" as a blanket assurance usually means the first of these, and answers far less than the person asking believes.

Keys are the whole control

Encryption moves the problem to key management; it does not remove it. A key stored beside the data it protects provides documentation, not protection.

• Use a managed key service or hardware-backed store. Keys in configuration files, environment variables committed to a repository, or application code are the common real-world failure.
• Separate duties so the people who administer the data are not the people who administer the keys.
• Plan rotation before you need it, including how you re-encrypt existing data. Rotation nobody has practiced is a policy, and the moment you need it is after a suspected exposure.
• Know what key destruction means. Deleting a key makes the data unrecoverable, which is either a deletion mechanism you designed for or an outage you did not.

Secrets are the credential case of the same problem

Application secrets — database passwords, API keys, service tokens — belong in a secret manager, injected at runtime, scoped narrowly, and rotated on a schedule and on staff departure.

Scan for committed secrets in CI and pre-commit, and treat any secret that has ever reached a repository as compromised. Removing the commit does not un-publish it; rotation is the only remediation.

Minimize, de-identify, and delete

The most reliable protection is not holding the data.

• Collect what the purpose needs. Every extra field is a permanent liability with no owner.
• Do not seed test environments from production without de-identification. This is one of the most common exposures and one of the easiest to fix.
• Understand that removing names is not anonymization. A combination of ordinary fields often re-identifies people; treat de-identified data as still sensitive unless someone has actually tested that it is not.
• Delete on a schedule you can evidence, and confirm deletion reaches backups, replicas, analytics copies and archives — where it usually does not.

Never

• Describe data as encrypted without saying against which threat.
• Store a key or secret in the same place as the data or code it protects.
• Rotate credentials without confirming the old ones stop working.
• Copy production data into a test environment without de-identifying it first.