Encrypting data at rest: what it means for your website's database
What encryption at rest protects against, what it does not, and the layers of it that matter for a business application's data.
The short answer
Encryption at rest means data is scrambled as it sits on disk, so that anyone who obtains the physical storage, a discarded server, a copied disk image or a backup file cannot read it without the key. It is a real protection, it is expected by privacy rules and client questionnaires, and managed database and storage services provide it by default. What it does not do is protect data from anyone who reaches it through the front door: an attacker who logs into the application with a stolen credential, exploits an injection flaw, or gains database access, sees data as the application does, decrypted. Data breaches happen that way. The layers beyond the default that matter are encrypting backups wherever they are stored, encrypting the few most sensitive fields so that even database access does not reveal them, and controlling who holds the keys. Confirm encryption at rest is on, then spend the attention on access control, because that is where data is actually lost.
What each layer protects against
| Layer | Protects against | Does not protect against | Who provides it |
|---|---|---|---|
| Disk or volume encryption | Stolen or discarded hardware, copied storage | Anyone with access to the running system | The provider, by default |
| Database encryption at rest | Copied data files, storage snapshots | Queries by anyone with database credentials | The managed database service |
| Encrypted backups | Leaked or misplaced backup files | Restoring with the key | Configuration; must be checked |
| Field-level encryption | Database access without the application key | Application-level compromise | The application; for the few most sensitive fields |
| Encryption in transit | Interception on the network | Anything at either end | HTTPS and encrypted database connections |
| Key management | Provider or third party decrypting without you | Misuse by whoever holds the keys | Provider key service, or one you control |
What to do
- Confirm encryption at rest is enabled on the database, file storage and backups; get it in writing from the provider or the settings.
- Confirm connections to the database are encrypted in transit.
- Identify the few fields whose exposure would be a serious incident and encrypt those at field level.
- Keep application keys in secret storage with access limited to the running application and named people.
- Decide on key control: provider-managed by default; customer-managed keys where requirements demand.
- Test a restore of an encrypted backup, because a backup whose key was lost is no backup.
- Then focus on access control, logging and least privilege, which prevent the breaches encryption at rest cannot.
Where it fits in the whole
Encryption at rest is a baseline: expected, easy on modern platforms, and worth confirming. Field-level encryption is a targeted measure for the data that would hurt most. Access control, input validation, secret management, logging and monitoring are where most of the work and most of the protection are. A questionnaire that asks only about encryption at rest is asking the easy question; a business that can also answer who can access what, and how it would know, is the one that is actually protected.
What this means for you
Make sure your database, storage and backups are encrypted at rest and your connections are encrypted in transit, encrypt the handful of fields that would cause a serious incident if exposed, and keep the keys in proper storage. Then put the attention where breaches actually happen: access control, secrets, logging and the way the application is built. Encryption at rest protects the disk; the rest protects the data.
Frequently asked questions
Our provider says data is encrypted at rest. Are we covered?
Covered against one category of loss: physical media, decommissioned hardware and copied storage files. It is a genuine protection and a common requirement in privacy rules and client questionnaires. It does nothing against an attacker who logs into the application, exploits an injection flaw or uses a stolen credential, because the application decrypts data to work with it. Breaches happen that way, which is why access control matters more.
Should we encrypt specific fields as well?
For the most sensitive values, yes: identity numbers, health details, financial identifiers, anything whose exposure would be a serious incident. Field-level encryption means those values are unreadable even to someone with database access unless they also have the application's key. It adds complexity, so it is applied to the few fields that justify it, not to everything.
Who should hold the encryption keys?
The provider's key management by default, which is properly built and audited. For higher requirements, keys managed in a key service you control, so the provider cannot decrypt your data without you. In either case the application's own keys for field-level encryption live in secret storage with strict access, and never in code or configuration files.
Sources
- OWASP Cheat Sheet Series: Cryptographic Storage Cheat Sheet (accessed 2026-09-12)