Encryption at Rest — Architecture Patterns for Regulated Data

Encryption at rest protects data stored on persistent media — databases, file systems, object storage, backup media — from unauthorized access if the physical or logical storage is compromised. For regulated data, encryption at rest is mandatory under PCI DSS (Requirement 3), HIPAA (Technical Safeguard §164.312(a)(2)(iv)), GDPR (Article 32 appropriate technical measures), and most state privacy laws. The encryption architecture must address three layers: volume/disk encryption (full disk encryption using AES-256 on the underlying storage), database-level encryption (Transparent Data Encryption in SQL Server/Oracle, or native encryption in managed database services), and application-level encryption (field-level encryption for the most sensitive data elements, such as PAN, SSN, or biometric data). Each layer provides different protection against different threat models.

Engineering encryption-at-rest architecture for regulated systems requires making explicit decisions about key management that significantly affect both security and operational complexity. Volume encryption with platform-managed keys (AWS EBS default encryption, Azure disk encryption) provides protection against physical media theft with minimal operational overhead but limited cryptographic control. Customer-managed keys (CMKs) in a KMS provide stronger control — the data owner can revoke access by disabling the CMK — but require key management operations (rotation, backup, access control) that add operational burden. For the most sensitive data (PHI, PAN, SSN), application-level field encryption with keys managed outside the database provides the strongest isolation: even a database administrator with full database access cannot read the encrypted fields without the application encryption key.

A compliance nuance is the relationship between encryption at rest and data classification. Most regulated systems contain multiple data categories with different sensitivity levels, and applying the same encryption approach to all data is both over-engineered (for low-sensitivity data) and potentially under-engineered (applying only disk encryption to fields that warrant application-level encryption). A data classification policy that maps data categories to encryption requirements — and an architecture that implements layered encryption according to that policy — is more defensible in audit than a uniform approach. Backup encryption is frequently overlooked: the encryption controls that protect production data must extend to all backup copies, and backup media restoration processes must handle encryption key availability, or a key management failure can render backups unrestorable during a disaster.

We design layered encryption-at-rest architectures that apply encryption depth proportional to data sensitivity — volume encryption for all data, TDE for regulated databases, and application-level field encryption for high-sensitivity elements like PAN, SSN, and PHI. Our implementations include CMK lifecycle management, backup encryption continuity, and key availability testing to prevent encryption from becoming a recovery obstacle.

Compliance-Native Architecture Guide

Design principles and a structured checklist for building software that is compliant by default — not compliant by retrofit. Covers data architecture, access controls, audit trails, and vendor due diligence.