3 Data encryption is one of those terms that appears in every compliance framework, every security audit checklist, and every vendor sales deck — yet it’s frequently misunderstood at the level that actually matters for regulated organizations. Most teams know encryption is required. Far fewer have a precise understanding of what it does, where it must be applied, what it doesn’t protect against, and how encryption decisions at the storage layer affect compliance posture across GDPR, HIPAA, FIPS, NIS2, and DORA. This guide is written for compliance officers, public sector IT leads, and storage architects who need to move beyond the surface definition and understand encryption in the context of enterprise data storage — where the practical decisions live and where compliance exposure is created or closed. What Data Encryption Actually Does At its core, data encryption is the process of transforming readable data — plaintext — into an unreadable format — ciphertext — using a mathematical algorithm and an encryption key. Only someone with the correct decryption key can reverse the process and read the original data. The purpose is straightforward: if encrypted data is accessed by an unauthorized party — through a breach, an insider threat, a misconfigured permission, or a seized storage device — the data is unreadable without the key. Encryption doesn’t prevent unauthorized access. It renders that access useless. This distinction matters for compliance. Regulations don’t require that breaches never happen. They require that when data is accessed without authorization, the harm is minimized. Encryption is the primary technical control that satisfies this requirement. Under GDPR Article 32, for example, encryption is explicitly named as an appropriate technical measure to protect personal data. Under HIPAA, encryption of protected health information at rest and in transit is a recognized addressable implementation specification that, in practice, most covered entities implement as a requirement. Understanding what encryption does — and what it doesn’t do — is the starting point for building a storage architecture that genuinely satisfies compliance obligations rather than just appearing to. Encryption at Rest vs. Encryption in Transit There are two primary contexts in which data encryption applies to enterprise storage, and compliance frameworks treat them differently. Encryption at rest protects data that is stored on physical media — disk drives, SSDs, tape, or any persistent storage. If a drive is removed from a data center, stolen, or decommissioned without proper sanitization, encryption at rest ensures the data on it is unreadable. It also protects against unauthorized access to raw storage infrastructure below the application or API layer. Encryption in transit protects data as it moves between systems — between a client and a storage platform, between data centers, between on-premises infrastructure and cloud environments. Without encryption in transit, data moving across networks can be intercepted and read. TLS (Transport Layer Security) is the standard mechanism for encryption in transit in modern storage environments, typically enforced over HTTPS for all S3 API communications. Most compliance frameworks require both. Compliant S3 storage for regulated environments enforces encryption at the object level at rest and requires all data in transit to traverse encrypted connections. Treating either as optional creates a compliance gap that auditors will find. The Encryption Standard That Actually Matters: AES-256 When enterprise storage documentation references encryption, it almost always means AES — the Advanced Encryption Standard — and specifically AES-256, which uses a 256-bit key length. AES-256 is the global standard for encrypting sensitive data at rest. It is approved by NIST, required by FIPS 140-2 and FIPS 140-3 for US federal workloads, and accepted by every major compliance framework including GDPR, HIPAA, PCI-DSS, and NIS2. The 256-bit key length means there are 2²⁵⁶ possible keys — a number so large that brute-force attacks are computationally infeasible with any foreseeable technology. One practical advantage for enterprise storage environments is that modern processors include hardware acceleration for AES operations, meaning AES-256 encryption can be applied universally across petabyte-scale storage without meaningful performance overhead. Encryption doesn’t need to be selectively enabled for sensitive data categories — it can and should be enforced by default across all objects. This eliminates the operational risk of unencrypted data existing in the environment because someone forgot to enable the setting. Encryption Modes in S3-Compatible Storage For organizations using S3-compatible object storage — which now covers the majority of enterprise data environments — encryption is exposed through three standard server-side encryption modes. Understanding the differences is essential for compliance architecture decisions. SSE-S3 (Server-Side Encryption with platform-managed keys) is the baseline mode. The storage platform encrypts every object automatically using AES-256. Keys are generated and managed internally. For many workloads, this provides strong encryption with minimal operational complexity. The limitation is that the storage platform holds both the data and the keys — which may not satisfy compliance requirements that mandate separation of key management from data storage. SSE-KMS (Server-Side Encryption with an external Key Management System) introduces external key governance. Encryption keys are managed by a separate KMS, which can be on-premises or cloud-hosted. This enforces a critical security boundary: the storage system holds encrypted data, but the keys that decrypt it live in a separate, independently controlled system. This separation aligns directly with zero-trust architectural principles and satisfies the compliance requirement that organizations maintain control of their own encryption keys. It also enables crypto-shredding — the ability to render data permanently unreadable by deleting the encryption key rather than the data itself, which is valuable for GDPR right-to-erasure obligations. SSE-C (Server-Side Encryption with customer-provided keys) gives the customer complete control, providing the encryption key with each API request. The storage platform performs the encryption but never retains the key. This model offers maximum key control at the cost of significantly higher operational complexity, and is typically reserved for specific high-security use cases. For most regulated enterprises, SSE-KMS with an external Hardware Security Module (HSM) represents the right balance — strong encryption, independent key control, and an auditable key management chain that compliance teams can demonstrate to regulators. Why Key Management Is Where Compliance Is Won or Lost Encryption itself is a well-solved problem. AES-256 is cryptographically robust. The implementation is standardized. The performance overhead is manageable. What separates organizations with genuinely strong encryption posture from those with a compliance checkbox is key management. Encryption keys must be protected with at least the same rigor as the data they protect. If keys are stored alongside the data they encrypt, an attacker who gains access to the storage environment gains access to everything. If keys are never rotated, a single historical compromise may expose all data encrypted under that key. If key access is not audited, there is no way to demonstrate to regulators that encryption controls operated as intended. For compliance officers, the key management questions that matter most are: Who holds the keys? Can the organization demonstrate that key access is logged and auditable? Are keys rotated on a defined schedule? Is there a procedure for key revocation and crypto-shredding when data must be deleted? Can the organization demonstrate key separation from storage infrastructure during an audit? FIPS 140-2 and FIPS 140-3 compliance — required for US federal workloads and defense programs — applies specifically to the cryptographic modules that perform encryption and key management operations, not to storage systems as a whole. Understanding this distinction matters during procurement: a storage platform is not universally FIPS certified. The specific cryptographic components within it must be validated, and the deployed configuration must match the validated environment. This is where technical evaluators and compliance teams need to work together carefully. Encryption and Immutability: Two Controls That Must Work Together A common misconception in compliance architecture is that encryption alone is sufficient to protect regulated data. It isn’t — and the gap becomes visible in ransomware scenarios. Ransomware attacks increasingly target backup and storage infrastructure specifically because attackers know that destroying an organization’s ability to recover is more valuable than stealing the data. When an attacker gains administrative access to a storage environment, they can delete or overwrite data that isn’t immutably protected — even if that data is encrypted. The encryption protects data from being read by the attacker. It does nothing to prevent the attacker from destroying it. This is why S3 Object Lock immutability and encryption must be applied together as complementary controls. Immutability enforced at the object level ensures that data cannot be deleted or overwritten for a defined retention period, regardless of what credentials an attacker holds. Encryption ensures that data accessed without authorization is unreadable. Together they address the two primary threat vectors that compliance frameworks are designed to protect against: unauthorized access and unauthorized destruction. Compliant S3 storage for regulated sectors treats these two controls as inseparable. Object-level compliance locking prevents deletion. AES-256 encryption prevents unauthorized reading. The combination creates what is effectively a logical air gap — data that cannot be read by unauthorized parties and cannot be destroyed even by parties with administrative credentials. Encryption Obligations Across Key Compliance Frameworks For compliance officers managing obligations across multiple regulatory regimes, it’s useful to understand how encryption requirements differ in emphasis across frameworks. GDPR requires appropriate technical measures to protect personal data, explicitly naming encryption as an example. More specifically, it requires that organizations be able to demonstrate that these measures were applied — meaning audit trails of encryption configuration, key access logs, and evidence of encryption enforcement are as important as the encryption itself. GDPR data storage requirements go beyond encryption to encompass retention, deletion, and the ability to honor data subject rights at scale. HIPAA requires covered entities to implement encryption of protected health information at rest and in transit as an addressable specification — meaning organizations must either implement it or document a justified alternative. In practice, the documentation burden of justifying non-encryption is far higher than simply implementing AES-256, and most auditors treat it as effectively mandatory. FIPS 140 governs the specific cryptographic modules used for encryption in US federal and defense environments. It applies to the implementation of encryption, not just its presence — meaning the algorithms used, the key lengths, and the operational configuration must all conform to validated standards. FIPS compliance is particularly relevant for public sector IT leads procuring storage for federal agency workloads. NIS2 and DORA both require that organizations implement appropriate technical measures to protect data and maintain operational resilience. Encryption is a baseline expectation under both frameworks, with NIS2 particularly emphasizing the need for encryption of data in transit across network boundaries — relevant for hybrid cloud environments where data moves between on-premises and cloud infrastructure. What Encryption Compliance Looks Like in Practice For a compliance officer reviewing an organization’s encryption posture for a storage audit, the evidence that matters is not whether encryption is theoretically enabled — it’s whether it is enforced by default, consistently applied, independently auditable, and integrated with immutability and access controls into a coherent security architecture. That means AES-256 encryption applied to all objects at ingest, not selectively. It means encryption keys managed externally and independently of the storage platform. It means TLS enforced on all data in transit. It means key access logs that can be produced for auditors. It means zero-trust IAM controls that enforce the principle of least privilege on who can access encryption configuration. And it means immutability enforced at the object level so that encrypted data cannot be destroyed even if administrative credentials are compromised. Storage platforms that enforce all of this by default — rather than leaving it as a configuration option — dramatically reduce compliance risk, because the human error of misconfiguration is eliminated. Compliance posture should not depend on someone remembering to enable encryption on a new storage bucket. Further Reading AES Encryption for Enterprise Data Security Compliant S3 Storage for Regulated Data FIPS Compliance Guide for Secure Storage GDPR Data Storage Requirements for IT and Storage Teams S3 Object Lock: Immutability and WORM What Is Immutable Storage? Definition, Benefits, and How It Works Zero Trust Security Best Practices: Never Trust, Always Verify What Is NIS2? The EU Cybersecurity Directive Explained Digital Operational Resilience Act (DORA) Explained What Is the NIST Cybersecurity Framework? See how Scality enforces AES-256 encryption by default across on-premises and hybrid cloud storage — with external key management, S3 Object Lock immutability, and audit-ready compliance controls built in. Request a personalized demo →
