By mid-2008, encrypting data at rest was a solved technical problem. Database vendors shipped transparent encryption in their current releases, full-disk encryption for laptops was mature and commercially available, and the cryptography itself had been settled for a decade. It was also, in most enterprises, switched off. That gap between availability and adoption is one of the more instructive stories in enterprise security, because none of the reasons for it were about cryptography. They were about performance anxiety, key management, and the absence of anyone willing to own the consequences of getting it wrong.
The Four Objections
Performance. This was a legitimate concern in 2008 in a way it is not today. Commodity processors did not yet include dedicated instructions for accelerating the standard block cipher, so encryption consumed real CPU cycles on busy database servers. DBAs who had spent months tuning query performance were being asked to accept a tax on every read and write, and they said no. Hardware acceleration arrived in mainstream server processors shortly afterwards and quietly removed the objection, but by then the cultural position had set. Key management. The real blocker, then and now. Encrypting data is easy. Managing keys means deciding who holds them, how they are backed up, how they rotate, how they are separated from the database administrators who are meant to be constrained by them, and — the question that stops projects — what happens if they are lost. Losing an encryption key does not degrade your data. It destroys it. Dedicated key management appliances existed and were expensive, so most organizations chose the risk they already understood. Application compatibility. Column-level encryption broke applications that expected to search, sort and join on those columns. Teams discovered that encrypting the customer identifier meant rewriting reports, and the project stopped at the proof of concept. No forcing function. Nothing required it. Card industry rules required rendering card numbers unreadable, but general personal data sat unencrypted with no legal consequence.
What Changed the Economics
Breach notification law did, and it did so through a specific mechanism that deserves more credit than it gets: the encryption safe harbour. Under most notification regimes, losing encrypted data with the keys intact does not trigger the obligation to notify affected individuals. Losing unencrypted data does. That single asymmetry converted encryption from a technical preference into a straightforward financial calculation, because notification costs — mailing, call centres, credit monitoring, legal review, regulatory engagement and reputational damage — dwarf the cost of turning encryption on. Several US states then went further during this period, with Nevada and Massachusetts introducing requirements that personal information be encrypted when transmitted externally or stored on portable devices — the first general mandates rather than sector-specific rules. The device numbers made the same argument. Research from this era priced the average cost of a lost laptop at roughly $49,000, with encrypted machines costing materially less than unencrypted ones — because the encrypted loss was a hardware replacement and the unencrypted loss was a data breach.
What Encryption at Rest Does Not Do
This is where organizations then and now overestimate what they have bought. Encryption at rest defends against one specific class of threat: an adversary who obtains the storage rather than the system. It works well against:
- Stolen or lost laptops, phones and removable media
- Improperly decommissioned drives and returned failed disks
- Backup tapes and disks in transit or in third-party storage
- Direct theft of storage volumes or snapshot files
- Regulatory exposure, via the notification safe harbour It does essentially nothing against:
- An attacker who compromises the application and uses its legitimate database credentials
- An insider with valid access to the system
- SQL injection against a web application — which is precisely how the Heartland payment processor intrusion of 2008 began
- Ransomware, which does not need to read your data to hurt you
- Data in memory, in transit inside your network, or exported to a spreadsheet by an authorised user A system that decrypts transparently for any authenticated query is protected against theft of the disk and not against theft through the application. Both statements are true simultaneously, and security programmes get into trouble when they report only the first.
| Exposure | Boundary to review |
|---|---|
| Lost storage media | Encryption and recovery-key custody |
| Compromised application access | Permissions and application controls remain necessary |
| Copies and exports | Verify coverage separately from primary storage |
| Ransomware and interruption | Recovery capability remains necessary |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Where the Real Work Is Now
Default encryption at rest is now standard in every major cloud platform, which has moved the interesting questions elsewhere.
- Who can decrypt? Provider-managed keys mean the provider can technically access your data and may be compelled to. Customer-managed keys, and hold-your-own-key arrangements, change that calculus — and introduce operational risk you now own.
- Where do the keys live, legally? For organizations with data sovereignty obligations, key custody jurisdiction matters as much as storage location. In-country data under keys held by a foreign-controlled entity is a weaker position than most residency clauses acknowledge.
- What about the copies? Backups, replicas, exports, data warehouse extracts, and the production dataset someone loaded into a test environment last year. Primary storage is usually encrypted. The copies are where the exposure has migrated.
- Can you prove it for your SaaS vendors? "Encrypted at rest" appears in every vendor security page. Ask which components, under whose keys, with what access controls on those keys, and what is logged when a key is used.
- Is the sensitive subset protected differently? Full-volume encryption treats all data identically. Field-level encryption and tokenisation of the small number of genuinely sensitive attributes — identifiers, card data, health information, salary — defends against application-layer compromise in a way volume encryption cannot.
Practical Sequence
- Encrypt every endpoint and removable device, with centrally escrowed recovery keys. This is the highest-return control and it is essentially free on modern hardware.
- Encrypt backups and verify by performing a restore, including a restore in a key-loss scenario.
- Turn on database and storage encryption using platform capabilities rather than custom implementations.
- Move key custody away from the administrators of the encrypted systems, log every key use, and rehearse key rotation before you need it.
- Identify the genuinely sensitive fields and protect them at the application layer with encryption or tokenisation.
- Find and eliminate production data in non-production environments. This is consistently the largest unencrypted, unmonitored copy of your most sensitive data.
- State plainly in risk reporting what your encryption does and does not mitigate, so nobody mistakes it for application security.
Common Questions
Does encryption at rest prevent data breaches?
It prevents a specific category: loss or theft of the storage media itself. It does not stop attacks through the application, compromised credentials, insider misuse or ransomware.
Why does breach notification law care about encryption?
Most regimes treat properly encrypted data with intact keys as not exposed, so notification is not triggered. That safe harbour is usually the strongest financial argument for implementing it.
What is the hardest part of encrypting data at rest?
Key management — custody, separation of duties, rotation, backup and recovery. Losing keys destroys the data, which is why programmes stall at this stage rather than at the encryption itself.
Is cloud provider encryption sufficient?
For media-theft protection, generally yes. If your concern includes provider access, legal compulsion or sovereignty, you need customer-managed keys with documented custody and access logging.
Data Encryption Review — Outpace maps where your sensitive data actually rests — including backups, exports and test environments — and builds an encryption and key custody model that stands up to both an auditor and an attacker.