Compare FDE, TDE, field-level, and FPE methods for data at rest encryption. Map each to PCI DSS, HIPAA, and GDPR. Learn why encrypted PANs stay in PCI scope
Data at rest encryption protects stored data – in databases, file systems, backups, and storage media – by converting it into ciphertext that is unreadable without the correct decryption key.
It is a baseline control for any enterprise handling regulated data and is required or strongly referenced by PCI DSS 4.0.1, HIPAA, GDPR, and SOC 2.
However, data at rest encryption addresses a specific threat model: physical theft and unauthorized access to storage. It does not protect against authorized user abuse, application-layer compromise, or key mismanagement.
Under PCI DSS, encrypted Primary Account Numbers (PANs) remain in compliance scope because the mathematical relationship between plaintext and ciphertext is reversible.
For structured sensitive data, vaulted tokenization provides stronger scope reduction by removing the data entirely.
Most enterprises need encryption at rest as a foundational layer – and then must decide where to add tokenization or masking on top of it.
This guide covers the methods, the key management decisions that determine whether encryption actually works, the regulatory compliance mapping, and the operational question of when encryption alone is not enough.
Data at rest is any data housed on persistent storage – databases, data warehouses, file shares, object storage, backups, tapes, endpoints, and cloud storage buckets.
It includes both structured data (database columns, transaction records) and unstructured data (documents, images, logs). The defining characteristic is that the data is not actively moving across a network or being processed by an application at the time of protection.
Data at rest encryption converts stored data into ciphertext using cryptographic algorithms and keys. Only authorized entities with the correct decryption key can restore the plaintext.
The National Institute of Standards and Technology (NIST) SP 800-111 – "Guide to Storage Encryption Technologies for End User Devices" – provides the foundational federal framework for implementing these controls.
The threat model is specific.
Data at rest encryption protects against physical theft of storage media, unauthorized access to storage infrastructure, improper disposal of hardware, and certain insider access patterns in which an attacker can access raw storage but not the application-layer decryption.
It does not protect against an authorized database user running a query, an application compromised through SQL injection, or an administrator who already holds the decryption key.
In this vein, it is important to distinguish between data at rest and data in transit. Encryption in transit – using TLS, SSH, or VPN protocols – protects data as it moves across networks.
There are six primary methods for encrypting data at rest, each operating at a different storage layer. The choice depends on the threat model, the data type, and the compliance requirements.
No competitor on the current SERP provides a structured comparison – this section fills that gap.
Full Disk Encryption (FDE) encrypts entire disk partitions or volumes at the block level – BitLocker on Windows, LUKS (Linux Unified Key Setup) on Linux, FileVault on macOS.
It provides broad baseline protection with low performance overhead because modern CPUs include hardware-accelerated AES instructions.
That said, FDE protects only against physical theft and improper disposal. Once the disk is mounted and the operating system is running, the data is decrypted for any authenticated session.
Transparent Data Encryption (TDE) operates at the database layer – SQL Server, Oracle, PostgreSQL, MySQL, MariaDB, and IBM DB2 all support it natively.
TDE encrypts entire databases or tablespaces at the storage layer, transparent to applications. It requires zero code changes and protects against unauthorized access to backup files and raw database storage.
However, TDE does not protect against authorized database users – data is decrypted for any authenticated session, which means a compromised credential or SQL injection still exposes plaintext.
File and object encryption protects individual files, objects, or blobs – AWS S3 SSE, Azure Storage Service Encryption, and GCP default encryption all fall into this category.
All three major cloud providers now encrypt data at rest by default. The question for enterprise buyers is not whether encryption is enabled but who controls the keys.
Field-level and column-level encryption provides the granular control that TDE lacks. Instead of encrypting entire databases, you encrypt specific columns – a PAN column, an SSN column, a PHI field – while leaving non-sensitive columns unencrypted.
This reduces performance overhead and enables per-field access control. The trade-off is that field-level encryption typically requires application awareness and may necessitate schema modifications.
Application-level encryption encrypts data before it reaches storage. This provides the strongest protection against storage-layer threats because the storage system never sees plaintext. It also protects against access by cloud providers in multi-tenant environments.
However, it requires developer implementation and introduces key management complexity at the application tier.
Format-preserving encryption (FPE) – using NIST-approved FF1 or FF3-1 algorithms – encrypts data while preserving the original format and length.
A 16-digit PAN remains a 16-digit string after encryption. This is critical for legacy systems with rigid field-length constraints. However, FPE is functionally closer to vaultless tokenization than to traditional encryption – the relationship between input and output is algorithmic, and security depends on key custody.
DataStealth's position is that vaulted tokenization provides stronger separation than FPE for structured sensitive data.
The strength of encrypted data at rest depends entirely on key management. A compromised key renders encryption useless. A lost key renders data unrecoverable.
There are four key custody models available to enterprise buyers.
For enterprises with strict key custody requirements, Hardware Security Modules (HSMs) provide tamper-resistant physical key storage. Cloud KMS platforms – AWS KMS, Azure Key Vault, GCP Cloud KMS – provide managed key lifecycle services with HSM-backed options.
The choice depends on regulatory requirements, risk tolerance, and operational capacity. NIST SP 800-57 provides the foundational framework for key lifecycle management – i.e., generation, distribution, storage, rotation, archival, and destruction.
Critical practices include generating keys with FIPS 140-2 validated modules, storing keys separately from encrypted data, rotating keys on a defined cryptoperiod schedule, enforcing least-privilege access to decryption keys, logging all key access events, and supporting crypto-shredding – destroying the key to destroy the data at the end of the lifecycle.
DataStealth uses a policy-as-code model where protection rules – including key lifecycle – are managed through a declarative, Git-friendly pipeline with versioning and rollbacks, and integrates with external HSMs and cloud KMS via KMIP.
One can see enterprises increasingly adopting data discovery as a prerequisite to key management – you cannot define which data to encrypt if you do not know where sensitive data resides. Unintentional storage of PANs in logs, non-production environments, or shadow databases expands scope invisibly and creates unmanaged key dependencies.
Four major compliance frameworks reference or require data-at-rest encryption.
The specifics differ by regulation – understanding the mapping is essential for allocating the right controls to the right data.
Under PCI DSS 4.0.1, Requirement 3.4.1 mandates that PANs be rendered unreadable anywhere they are stored. Encryption with associated key management (Requirement 3.5) is one accepted method, alongside tokenization, truncation, and one-way hashing.
However, the PCI SSC treats encrypted PANs as in-scope cardholder data – the mathematical relationship between plaintext and ciphertext is reversible if the key is compromised.
This is the single most important compliance fact for CISOs evaluating at-rest controls. Only tokenization can take downstream systems out of PCI scope entirely.
Under HIPAA, the Security Rule (45 CFR § 164.312(a)(2)(iv)) identifies encryption as an "addressable" safeguard – not optional, but organizations must implement it or document why an equivalent measure is reasonable and appropriate.
HIPAA does not specify algorithms but references NIST guidelines. AES-128 or AES-256 is the de facto standard.
For data de-identification of PHI, HIPAA's Safe Harbor and Expert Determination methods apply separately from encryption.
Under GDPR, Article 32 requires "appropriate technical and organizational measures" including encryption of personal data as a security measure.
Article 34(3)(a) provides that encryption may exempt an organization from breach notification obligations if the data was rendered unintelligible to unauthorized persons. GDPR does not specify algorithms or methods – it defers to risk-based assessment.
For enterprises operating across jurisdictions, aligning at-rest controls with broader data security management ensures consistent protection.
Under SOC 2, Trust Services Criteria CC6.1 and CC6.7 require encryption for data at rest and in transit.
Encryption standards and key management practices are assessed during the audit. SOC 2 does not prescribe specific algorithms but expects documented policies and evidence of continuous enforcement.
This is where most enterprise at-rest encryption guides stop – and where the actual risk begins.
Encryption at rest protects against a specific set of threats: physical theft of storage media, unauthorized access to raw storage, and improper hardware disposal.
The compliance implication is significant.
Under PCI DSS, encrypted PANs remain in scope because the data can be recovered if the encryption key is compromised.
The PCI SSC Tokenization Guidelines explicitly draw the scope distinction: systems storing encrypted PANs are in scope; systems storing only vaulted tokens – where the token has no mathematical relationship to the original PAN – can be treated as out of scope if they cannot access the vault, keys, or detokenization service.
Thus, the enterprise at-rest protection pattern is layered. Encrypt at rest as a baseline – this satisfies defense-in-depth requirements and addresses the physical theft threat model.
Layer vaulted tokenization on top for structured sensitive data that requires compliance scope reduction – PANs, SSNs, PHI identifiers. Apply masking for non-production environments where original data is never needed.
This is the data-centric model that DataStealth's platform supports, built on a single policy engine.
The choice of at-rest encryption method depends on two dimensions: storage type and data sensitivity.
For endpoints – laptops, workstations, physical servers – full disk encryption (BitLocker, LUKS, FileVault) is the baseline. It is widely deployed, often enabled by default on modern operating systems, and carries minimal performance impact.
For databases, transparent data encryption is the starting point for broad coverage with zero application changes. Add field-level encryption for regulated columns – PANs, SSNs, PHI – where granular access control is required.
For cloud storage, all three major providers – AWS, Azure, and GCP – encrypt data at rest by default.
The enterprise question is key custody: platform-managed keys are sufficient for general business data; CMK or BYOK is appropriate for regulated data; HYOK is required where keys must never leave the customer's premises.
For legacy and mainframe environments, IBM Pervasive Encryption provides application-transparent at-rest coverage on z/OS.
However, for data leaving the mainframe – replication to analytics platforms, data feeds to cloud services, terminal access sessions – agentless tokenization at the network layer provides protection that host-based encryption cannot extend.
For data requiring PCI scope reduction, the decision is definitive.
Encryption does not reduce scope. Tokenization does.
Enterprises pursuing SAQ transition – from SAQ D (252 requirements) to SAQ A (31 requirements) – must tokenize cardholder data, not merely encrypt it.
Data classification determines which fields require which control, and a data security platform that supports encryption, tokenization, and masking from a single policy engine eliminates the need to stitch together point solutions.
Three enterprise deployments illustrate how data-at-rest protection operates across different environments and threat models.
A global insurance company needed to protect data at rest in non-production environments – development, testing, and training systems across mainframe, distributed, and cloud platforms.
Their existing randomized masking approach broke downstream systems because it did not preserve referential integrity or geographic accuracy.
DataStealth applied tokenization, masking, and encryption in-flight during SFTP file transfers from production to non-production.
Every system received protected data that behaved identically to production data – batch processes, actuarial calculations, and cross-system joins all continued to function.
DataStealth is a data security platform that applies encryption, tokenization, and masking at the data-element level through policy-driven rules.
DataStealth's field-level encryption and vaulted tokenization operate from a single platform – i.e., encrypt data at rest with AES-GCM or AES-CBC+HMAC, or replace sensitive fields with format-preserving tokens that have no mathematical relationship to the original values.
The right control is applied per field and per policy, based on data classification and compliance requirements.
Schedule a demo to see how DataStealth applies the right protection method at the data-element level, or explore the case studies to see how enterprises in financial services, insurance, loyalty, and transportation have deployed these controls in production.
Lindsay Kleuskens is a data security specialist helping enterprises reduce risk and simplify compliance. At DataStealth, she supports large organizations in protecting sensitive data by default, without interrupting user workflows.
