Encryption at Rest vs. In Transit: What Compliance Requires

Two Types of Encryption, Two Different Threat Models

Encryption is a fundamental security control for protecting personal data, but the term covers two distinct protections that address different risks. Encryption at rest protects stored data from unauthorized access to physical or logical storage. Encryption in transit protects data as it moves between systems over a network.

Understanding both is essential for building a compliant data protection strategy.

Encryption at Rest

What It Protects Against

Encryption at rest secures data stored on disk, in databases, on backup media, or in any persistent storage system. It protects against:

• Physical theft of servers or storage devices
• Unauthorized access to storage volumes by insiders or compromised accounts
• Exposure from decommissioned hardware that was not properly wiped
• Data leakage from backup tapes or exported database files

How It Works

Data is encrypted before being written to storage and decrypted when read by an authorized process. The encryption is transparent to the application in most implementations.

Common Approaches

Approach	Description	Use Case
Full disk encryption	Encrypts the entire storage volume	Server hard drives, laptop drives
File-level encryption	Encrypts individual files	Document storage, file shares
Database encryption (TDE)	Encrypts database files transparently	SQL Server, Oracle, PostgreSQL
Column-level encryption	Encrypts specific database columns	Sensitive fields (SSN, payment data)
Object storage encryption	Encrypts objects in cloud storage	S3, Azure Blob, GCS

Encryption Algorithms

• AES-256: The industry standard for data at rest. Required or recommended by virtually all compliance frameworks.
• AES-128: Acceptable under most frameworks but AES-256 is preferred for sensitive data.
• ChaCha20: Used in some specialized contexts but less common for at-rest encryption.

Key Management Considerations

The encryption is only as strong as the key management:

• Provider-managed keys: The cloud provider generates and manages encryption keys. Simplest to implement but you rely entirely on the provider's security.
• Customer-managed keys (CMEK): You control the encryption keys while the provider handles the encryption operations. Better control and audit capability.
• Customer-provided keys (CSEK): You provide the keys for each encryption operation. Maximum control but highest operational complexity.
• Hardware Security Modules (HSMs): Keys are stored and managed in dedicated hardware. Highest assurance level.

Encryption in Transit

What It Protects Against

Encryption in transit secures data as it travels over networks. It protects against:

• Man-in-the-middle attacks
• Network eavesdropping and packet capture
• DNS spoofing and session hijacking
• Data interception on public or shared networks

How It Works

Data is encrypted before transmission and decrypted upon receipt. The encryption is typically handled at the transport layer, transparent to the application data.

Common Protocols

Protocol	Description	Current Standard
TLS 1.3	Transport Layer Security	Current recommended version
TLS 1.2	Previous version, still widely used	Acceptable but 1.3 preferred
mTLS	Mutual TLS with client certificates	Service-to-service communication
IPSec	Network-layer encryption	VPN tunnels, site-to-site connections
SSH	Secure shell protocol	Remote administration, file transfer
HTTPS	HTTP over TLS	Web applications, APIs

Deprecated Protocols to Avoid

• TLS 1.0 and 1.1: Deprecated since March 2021. Known vulnerabilities.
• SSL 2.0 and 3.0: Severely compromised. Must not be used.
• Unencrypted HTTP: Never acceptable for transmitting personal data.

What Compliance Frameworks Require

GDPR

GDPR does not mandate specific encryption standards but requires "appropriate technical measures" to protect personal data (Article 32). Encryption is explicitly listed as an example. In practice, supervisory authorities expect:

• Encryption at rest for all personal data stores
• Encryption in transit for all data transmissions containing personal data
• Appropriate key management practices

Encryption also provides a safe harbor for breach notification: if encrypted data is breached and the keys were not compromised, the breach may not require notification to data subjects (Article 34(3)(a)).

PCI DSS

PCI DSS has specific encryption requirements:

• Strong cryptography on all transmission of cardholder data across open, public networks
• Render stored PAN unreadable using encryption, hashing, or truncation
• Document and implement key management procedures

HIPAA

The HIPAA Security Rule requires encryption as an "addressable" implementation specification:

• Encryption of ePHI at rest and in transit
• If encryption is not implemented, a documented risk assessment and alternative measures are required

SOC 2

SOC 2 Trust Services Criteria require encryption as part of the Common Criteria:

• Encryption of data in transit using current protocols
• Encryption of data at rest, particularly for sensitive information
• Key management controls

Best Practices for Both Types

At Rest

• Enable encryption for all storage volumes, databases, and object stores
• Use AES-256 as the default algorithm
• Implement customer-managed keys for sensitive workloads
• Rotate encryption keys on a regular schedule (annually at minimum)
• Ensure backup encryption matches or exceeds production encryption standards
• Test that data is actually encrypted by examining raw storage

In Transit

• Enforce TLS 1.2 or higher for all connections
• Prefer TLS 1.3 where supported
• Disable all legacy protocols (TLS 1.0, 1.1, SSL)
• Use strong cipher suites and disable weak ones
• Implement certificate pinning for mobile applications
• Use mTLS for internal service-to-service communication
• Monitor certificate expiration and automate renewal

For Both

• Separate encryption keys from encrypted data
• Implement access controls on key management systems
• Maintain audit logs for all key usage and management operations
• Test encryption in your disaster recovery procedures
• Include encryption requirements in vendor assessments

Common Mistakes

• Encrypting in transit but not at rest: Data is vulnerable when stored on disk, especially in multi-tenant environments.
• Encrypting at rest but not in transit: Data is exposed during transmission, negating the protection of at-rest encryption.
• Using default provider keys without understanding the trust model: Know who has access to your encryption keys.
• Ignoring internal traffic: Encrypt service-to-service communication, not just external-facing traffic.
• Treating encryption as a complete solution: Encryption protects confidentiality but does not address access control, integrity, or availability.

How GlobalDataShield Approaches Encryption

GlobalDataShield implements encryption at rest and in transit as baseline requirements for all hosted data. Combined with region-specific hosting that keeps data within defined geographic boundaries, this layered approach ensures that personal data is protected both from unauthorized access and from unintended cross-border exposure -- addressing two of the most significant compliance risk areas simultaneously.