Securing Data at Rest

Why at-rest protection matters

Data does not stop being sensitive once it is written to disk. Backups are copied, drives are decommissioned, snapshots are shared, and databases are occasionally exposed by misconfiguration. Encryption at rest ensures that if the underlying storage is obtained by someone who should not have it, the contents remain unreadable without the keys.

Think of it as defence in depth. Network controls and access rules are your first lines, but at-rest encryption is the layer that still protects you when those fail or are bypassed entirely — for instance, when a backup file ends up somewhere it should never have been.

Layers of encryption

At-rest protection works at several levels. Full-disk or volume encryption guards against physical media being stolen or improperly disposed of. Database or filesystem encryption protects the stored files themselves. Field-level encryption protects individual sensitive values — so even a user with broad database access cannot read the most sensitive fields without a separate key.

The right combination depends on what you store and how sensitive it is. The most sensitive data — credentials, identifiers, and personal details — deserves the strongest, most granular protection, layered on top of the broader disk and database encryption beneath it.

Keys live elsewhere

Encryption is only as strong as the secrecy of its keys, so keys must never sit beside the data they protect. Storing the key in the same database, or hard-coding it in source, is equivalent to leaving the safe unlocked. Use a dedicated secret manager or key-management service that controls access, supports rotation, and audits use.

# keys come from a managed store, never the repo
key = secret_manager.get('records-field-key')
record = decrypt(stored_blob, key)

Rotate keys periodically and on any suspected compromise, and keep their access logs as part of your audit trail.

Store less, expire more

The safest data is the data you never stored. Before persisting a sensitive value, ask whether you truly need it; data minimisation shrinks both your obligations and the damage any breach can do. Where you must store something, set a retention period and delete it when that lapses rather than keeping everything forever.

This pairs with handling personal information responsibly: the less you hold and the shorter you hold it, the smaller your exposure. Combine minimisation with strong encryption and disciplined key management, and stored data becomes a managed risk rather than an open liability.