Encryption at Rest: Definition and Use in Compliance

What is Encryption at Rest?

Encryption at rest is the practice of storing data in encrypted form so that any party who accesses the underlying storage medium without authorization sees only ciphertext. A cryptographic algorithm, typically AES-256, transforms the data before it's written to disk. Authorized processes retrieve the plaintext by presenting valid credentials and the correct decryption key.

The most important word in that definition is "unauthorized." The control doesn't prevent a database administrator with valid credentials from reading data. It neutralizes a specific threat: someone who obtains physical or low-level storage access without going through the application's authentication layer. That includes a stolen laptop, a decommissioned server sold without secure disk wiping, a backup tape shipped to the wrong facility, or a cloud storage misconfiguration exposing raw disk snapshots to unauthenticated requests.

Financial institutions accumulate decades of sensitive records. Transaction history, identity documents, personally identifiable information (PII), case notes from financial crime investigations, and regulatory filings all need protection from storage-layer exposure, not only from network-level attacks. A primary production database sits behind firewalls, authentication systems, and monitoring controls. The archived backups in a colocation facility often don't.

The threat isn't hypothetical. The 2015 OPM breach compromised 21.5 million records stored in a federal data center. A 2019 Office of Inspector General assessment found that OPM had failed to implement encryption at rest across multiple systems. Data sitting on readable storage required no additional cryptographic work for an attacker who had already breached the perimeter.

The control also matters for regulated recordkeeping environments. WORM storage prevents deletion and modification of records; encryption at rest adds the confidentiality layer. Together, they satisfy both integrity and confidentiality requirements in a single data management architecture, which is what examiners want to see for SAR files, audit logs, and other long-retention compliance records.

How is Encryption at Rest used in practice?

Banks and fintechs implement the control at multiple layers simultaneously: transparent data encryption at the database level, volume encryption at the storage layer, and file-level encryption for specific high-sensitivity archives. Defense-in-depth designs use all three rather than relying on any single one.

Transparent data encryption (TDE), available in Oracle, Microsoft SQL Server, MySQL, and PostgreSQL, encrypts data files and transaction logs on disk automatically. The application layer sees plaintext. Only direct storage access reveals ciphertext. Column-level encryption is more granular: fields like account numbers, social security numbers, and dates of birth are encrypted individually, so even a database administrator with read privileges sees masked values. Column-level is the right approach for customer identity records where strict access controls are required by regulation.

Key management is where implementations fail. Storing the decryption key in the same system as the data provides no real protection: anyone who can access the ciphertext can also access the key. Production environments separate all key operations into a hardware security module (HSM) or a cloud-managed key service. The HSM handles cryptographic operations without ever exposing raw key material, which is the audit property that examiners look for in a PCI DSS or SOC 2 evidence review.

Cloud deployments introduce additional choices. An S3 bucket can use AWS-managed keys, customer-managed keys in AWS KMS, or customer-provided keys uploaded at request time. Each option carries different audit implications. Customer-managed keys give the institution full visibility and control over rotation, usage logs, and revocation. AWS-managed keys are simpler but trade some auditability for convenience. Most regulated institutions use customer-managed keys for anything in scope of PCI DSS, GDPR, or GLBA.

Envelope encryption makes key rotation practical at scale. Data is encrypted with a data encryption key (DEK). The DEK itself is encrypted with a key encryption key (KEK) held in the HSM. Rotating the KEK takes seconds and doesn't require re-encrypting the underlying data, which removes the main operational objection to frequent rotation cycles.

Encryption at Rest in regulatory context

Three frameworks drive encryption at rest requirements in financial services, and they overlap in scope for most regulated institutions.

GDPR Article 32 requires data controllers and processors to implement "appropriate technical and organisational measures" to protect personal data, listing encryption as the first example. The European Data Protection Board's guidelines confirm that for financial institutions processing large volumes of customer data, encryption at rest is the expected baseline. A breach involving unencrypted personal data triggers the 72-hour notification requirement under Article 33. A breach involving encrypted data, with demonstrably secure key management, may satisfy the "unlikely to result in a risk to the rights and freedoms of natural persons" threshold and require no notification at all. That's a material operational difference.

The FTC Safeguards Rule (16 CFR Part 314), revised in 2021 and effective for most covered institutions from June 2023, explicitly requires encryption of customer information "in transit over external networks and at rest." The rule applies broadly to banks, credit unions, mortgage servicers, payday lenders, tax preparers, and auto dealers. Non-compliance exposes institutions to FTC enforcement, which has included multi-million dollar penalties in related data security cases.

PCI DSS v4.0, effective March 2024, makes Requirement 3.5 the primary storage encryption control for cardholder data environments. Primary account numbers must be encrypted with strong cryptography. The standard requires documented key management procedures, annual rotation as a minimum, and evidence that keys aren't stored alongside the data they protect.

FFIEC IT examiners review data classification, storage encryption coverage, and key management governance. An institution that encrypts its primary production database but not its analytics warehouse or developer test environments will receive a finding. Examiners also look for a complete audit trail for key access events: who retrieved a key, when, and from which system. The log is as important as the encryption itself.

Common challenges and how to address them

Encryption at rest is technically mature. AES-256 is in every major cloud platform and database engine. The hard part is consistent coverage and the audit evidence to prove it.

Inventory gaps. The most common finding in third-party audits is unencrypted data stores the security team didn't know existed. Encrypting the primary customer database while leaving the data warehouse, reporting extracts, and developer test environments unencrypted gives the same breach exposure as if nothing were encrypted. The fix is a complete data inventory tied to a classification policy that automatically triggers encryption requirements for any store classified as sensitive. Tokenization can reduce scope further: replacing sensitive values with tokens before they reach secondary systems means those systems may be entirely out of scope for cardholder data or PII requirements.

Key management sprawl. Organizations with dozens of applications end up with keys scattered across configuration files, environment variables, and internal wikis. This isn't theoretical: the 2020 Twitch source code leak exposed database credentials in plaintext. Centralizing key operations in an HSM or managed KMS eliminates this risk and produces the key access log that regulators expect.

Performance overhead. AES-256 adds latency. For most workloads, the overhead stays under 5%, and modern hardware processes AES operations at memory bandwidth using dedicated CPU instructions (Intel AES-NI, ARM Cryptography Extension). The latency argument against encryption rarely holds up when examined against actual benchmarks. The world's largest banks run their transaction databases with TDE enabled.

Key rotation friction. Full re-encryption of large data stores during rotation is operationally intensive. Envelope encryption solves this: rotate the KEK in the HSM (seconds), and the underlying data re-encryption requirement disappears.

Cloud coverage gaps. Cloud-native architectures create dozens of data stores: object storage, managed databases, data lakes, message queues, search indices. Each needs its own documented encryption posture. Teams that build encryption at rest into deployment standards as a baseline control find this manageable. Teams treating it as a post-hoc cleanup task consistently miss stores.

Related terms and concepts

Encryption at rest sits within a broader set of data-protection controls. These adjacent concepts appear together in regulatory frameworks and audit questionnaires, so knowing the relationships matters.

Encryption in transit protects data while it moves between systems: browser to web server, service to service, application to database. TLS 1.2 and TLS 1.3 are the standard implementations. The two controls address different threat models. Encryption in transit protects against network interception; encryption at rest protects against storage-layer access. Both are required. A system with only one of the two is still partially exposed.

Tokenization replaces a sensitive value with a non-sensitive token. Unlike encryption, it's not reversible without access to the token vault. For payment card data, tokenization often reduces PCI DSS scope more effectively than encryption alone: systems that only ever see tokens are frequently out of scope for cardholder data environment requirements. The token vault itself still needs encryption at rest.

Pseudonymization, defined under GDPR Article 4(5), replaces direct identifiers with artificial identifiers. It reduces breach impact and qualifies as a technical safeguard under GDPR's risk-based framework. It's weaker than full anonymization. Analytics platforms frequently use it to process behavioral data without directly exposing customer identities, but it's not a substitute for storage encryption where PII is present.

Hardware security modules are the gold standard for key storage. A FIPS 140-2 Level 3 certified HSM handles key generation, storage, and cryptographic operations without ever exporting raw key material. Physical intrusion triggers key deletion. PCI HSM v3.0 compliance requires HSMs for PIN protection and payment cryptography in financial services.

Data residency requirements interact with encryption at rest in cross-border deployments. If a regulator requires customer data to remain within a specific jurisdiction, the encryption keys must also be managed within that jurisdiction. Institutions deploying EU customer data to US cloud regions frequently discover that key management location determines whether data residency requirements are satisfied.