What Is Data Encryption and Why Do You Need It? A Complete Guide

In 2023, a ransomware group exfiltrated 8.9 million patient records from a US healthcare network and published them when the ransom was refused. The records contained names, Social Security numbers, dates of birth, insurance information, and medical history. Every person in that dataset is now permanently at elevated risk of identity fraud. The organization paid penalties under HIPAA and spent years in litigation. The data in that breach was not encrypted at rest.

Encryption does not prevent attackers from breaking into systems. It prevents the data they take from being usable. An attacker who exfiltrates a database of properly encrypted records has taken a file of meaningless ciphertext. Without the decryption key, the records cannot be read. The breach still happened, but its consequences are contained.

This is the core value proposition of data encryption: it converts the outcome of a breach from catastrophic to manageable. It protects data from the people who access systems without authorization, whether through external attack, accidental insider exposure, lost hardware, or misconfigured access controls. This article explains what data encryption is, how it works, the three states data exists in and why each needs different protection, and the specific operational and regulatory reasons encryption is not optional for any organization handling sensitive information.

What Data Encryption Is

Encryption is the process of transforming readable data (plaintext) into an unreadable format (ciphertext) using a mathematical algorithm and a key. The ciphertext can only be converted back to plaintext by someone who possesses the correct decryption key. Without the key, the ciphertext reveals nothing about the original content.

Two types of encryption keys are in widespread use, each suited to different purposes:

In practice, symmetric and asymmetric encryption are used together in a pattern called hybrid encryption. Asymmetric encryption solves the key distribution problem by securely exchanging a symmetric key. The symmetric key then encrypts the actual data. TLS, the protocol securing every HTTPS connection, is a hybrid system: the TLS handshake uses RSA or ECDH (asymmetric) to negotiate a shared session key, and AES (symmetric) encrypts all subsequent HTTP traffic using that session key.

The Three States of Data and Why Each Requires Protection

Data does not exist in a single state. During its lifecycle, it moves between being stored, moving across networks, and being actively processed. Each state presents different vulnerabilities and requires different encryption approaches.

Data at rest: stored data

Data at rest is information stored on physical or virtual storage: hard drives, SSDs, databases, backup tapes, cloud storage buckets, USB drives, and any other persistent storage medium. When an attacker steals a server, finds an unprotected backup, gains unauthorized database access, or takes a laptop, they encounter data at rest.

Encryption at rest converts stored data to ciphertext so that physical or logical access to the storage medium does not yield readable information without the decryption key. Full disk encryption (BitLocker on Windows, FileVault on macOS, LUKS on Linux) encrypts the entire storage volume. Database encryption (Transparent Data Encryption in SQL Server, MySQL InnoDB encryption) protects database files. File-level and column-level encryption protect specific files or database fields rather than entire volumes.

The appropriate granularity depends on the data and the threat model. Full disk encryption protects against device theft. Database-level or column-level encryption protects against database credential compromise while leaving non-sensitive data accessible to applications that need it.

Data in transit: moving data

Data in transit is information moving across networks: from a browser to a web server, between microservices inside a data center, from a mobile device to a cloud API, through email delivery chains, or between storage systems during backup replication. Data moving across networks is exposed to interception at every network hop.

TLS (Transport Layer Security) is the dominant protocol for data in transit encryption. Every HTTPS connection uses TLS. Every modern email server uses TLS between mail server hops. VPNs use TLS or IPsec to encrypt all traffic traversing an insecure network. The SSL certificates discussed throughout this site are the certificates that authenticate servers and enable TLS to be established with verified identity. The certificate proves the server is who it claims to be; the TLS handshake derives session keys; AES encrypts the data through the session.

mTLS (mutual TLS) extends this to authenticate both parties, not just the server. Service-to-service communication inside a microservices architecture, API connections between organizations, and IoT device connections increasingly use mTLS to verify that both the sending and receiving parties are authorized.

Data in use: actively processed data

Data in use is information being actively processed by applications: in CPU registers, in RAM, in application memory, or in database query execution. Traditionally, data must be decrypted before it can be processed, which means it exists in plaintext in memory during computation. This creates a vulnerability window: an attacker with access to running system memory can capture decrypted data even when storage and transit are encrypted.

Confidential computing is an emerging approach to encrypting data in use. Technologies including Intel Software Guard Extensions (SGX), AMD Secure Encrypted Virtualization (SEV), and ARM TrustZone create hardware-protected enclaves where data can be processed without being exposed to the host operating system, hypervisor, or cloud provider infrastructure. The data remains encrypted even in memory; only the enclave can decrypt and process it.

Confidential computing is not yet universally deployed, but it is increasingly available in cloud environments (Azure confidential computing, AWS Nitro Enclaves, Google Confidential Computing) and is required for the most sensitive data processing scenarios where neither the cloud provider nor the infrastructure operator should be able to access plaintext data.

Most organizations today have data at rest encryption (required by nearly every compliance framework) and data in transit encryption (HTTPS is universal for web traffic) but have limited or no data in use protection. The combination of all three creates layered protection. The absence of any one layer creates a window: an attacker who cannot read stored data might be able to capture it from memory during processing if data in use protection is absent.

The Real Challenge: Key Management

Encryption algorithms are not where security fails. AES-256 has not been broken. TLS 1.3’s cipher suites are not the vulnerability. The dominant failure mode in real-world encrypted systems is key management: how encryption keys are generated, stored, accessed, rotated, and revoked.

A database encrypted with AES-256 where the encryption key is stored in a plaintext configuration file in the same directory as the database provides no protection: an attacker who accesses the database file also accesses the key. Disk encryption where the recovery key is stored in an unprotected cloud note provides no protection if the cloud account is compromised. The strength of the encryption algorithm is irrelevant if the key is accessible alongside the data.

Key storage hierarchy

Secure key management separates keys from the data they protect through a hierarchy. Data Encryption Keys (DEKs) encrypt the actual data. Key Encryption Keys (KEKs) encrypt the DEKs. The KEK is stored in a hardware security module or a dedicated key management service. This hierarchy means that even if the encrypted data storage is compromised, the attacker has encrypted data and encrypted keys, but not the KEK needed to decrypt the keys. The KEK’s security rests on the HSM or KMS, which has its own access controls, audit logging, and tamper resistance.

Cloud providers offer managed key management services: AWS KMS, Azure Key Vault, Google Cloud KMS. These services store keys in FIPS 140-2 Level 2 or Level 3 validated hardware, enforce access policies, log all key operations for audit, and support automated key rotation. Using a cloud KMS rather than managing keys in application configuration is a meaningful security improvement for any organization using cloud infrastructure.

Key rotation

Keys should be rotated periodically. A key that has been in use for years has been exposed to more access events, more potential for extraction, and more opportunity for an attacker who captured the ciphertext to attempt cryptanalysis. Rotating keys limits the blast radius: if an old key is compromised, only data encrypted with that key is at risk.

Automated key rotation is offered by major KMS services and should be enabled for all long-lived encryption keys. Application-level keys (keys used to encrypt database fields, session tokens, or user data) should follow documented rotation schedules. Certificate rotation for TLS is the public-facing manifestation of this principle: certificates expire and must be renewed with new key material.

Storing encryption keys in the same location as the data they protect eliminates the security benefit of encryption. Common mistakes include: database encryption keys in database connection strings in source code, TLS private keys in public repositories, AWS access keys in application configuration files committed to Git. Key management hygiene (secrets managers, HSMs, KMS services, never committing keys to version control) is the operational foundation of effective encryption.

Key Encryption Algorithms: What Is Used and Why

The encryption algorithm determines the mathematical transformation applied to the data. Algorithm selection matters for both security and performance, though for standard applications the choice is typically straightforward.

Data Encryption and SSL Certificates: How They Connect

The SSL certificates discussed throughout this site are a specific, standardized mechanism for implementing data encryption in transit for web traffic. The relationship between data encryption as a broad concept and SSL certificates as a specific tool is direct.

When a browser connects to an HTTPS website, it performs a TLS handshake. The server presents its SSL certificate, which contains the server’s public key and is signed by a trusted Certificate Authority. The browser uses the public key for asymmetric key exchange to establish a shared symmetric session key. All HTTP traffic (the web page, form submissions, API calls, authentication tokens) then travels encrypted using AES with the session key. This entire process is data in transit encryption, implemented through the TLS protocol, authenticated through the SSL certificate.

An SSL certificate without HTTPS serving content does not encrypt anything: the certificate is the authentication mechanism, and TLS is the encryption mechanism. They work together, but the certificate alone does not protect data. Similarly, a TLS connection with an invalid certificate (expired, wrong domain, or from an untrusted CA) may encrypt the data but cannot prove the server’s identity, which means the encryption could be protecting a connection to the wrong server.

The same AES-256 algorithm used for HTTPS session encryption is also used for disk encryption, database field encryption, and file storage encryption. The same asymmetric PKI infrastructure that issues SSL certificates also issues S/MIME certificates for email encryption and code signing certificates. Data encryption is the unified concept; SSL certificates, TLS, AES disk encryption, and database encryption are applications of that concept in specific contexts.

Why Regulations Require Encryption and What Happens Without It

Encryption is required or strongly incentivized by every major data protection regulation because the consequences of unencrypted data breaches are materially worse than encrypted ones. Regulators recognize this by treating the encryption status of breached data as a factor in penalty calculations and notification requirements.

The GDPR Article 34 provision is practically significant: organizations that can demonstrate the breached data was properly encrypted may avoid the mandatory notification to affected individuals. This is not a way to avoid regulatory obligations, but it represents a substantial practical benefit: individual notification is expensive, reputationally damaging, and often legally risky. Encryption provides a safe harbor that purely access-control-based approaches do not.

Frequently Asked Questions

What is data encryption?

Data encryption is the process of transforming readable data (plaintext) into an unreadable format (ciphertext) using a mathematical algorithm and a key. The ciphertext can only be converted back to readable form by someone with the correct decryption key. Encryption protects data from unauthorized access: even if an attacker gains access to storage systems, network traffic, or hardware containing the data, they see only meaningless ciphertext without the key. It is the primary technical control protecting sensitive data at rest (stored), in transit (moving across networks), and increasingly in use (during processing).

What is the difference between data at rest and data in transit encryption?

Data at rest encryption protects stored data on hard drives, databases, cloud storage, and backup systems. AES-256 is the standard algorithm. It protects against physical theft, unauthorized storage access, and database credential compromise. Data in transit encryption protects data moving across networks, using TLS/HTTPS for web traffic, email transmission, and API communication. It protects against network interception, packet sniffing, and man-in-the-middle attacks. Both are required: storing data securely without protecting it in transit leaves it exposed when it moves; protecting data in transit without securing storage leaves it exposed when it rests. Most data breaches exploit one or the other gap rather than breaking the encryption algorithm itself.

Is HTTPS the same as data encryption?

HTTPS is a specific implementation of data in transit encryption for web traffic. It uses TLS to encrypt HTTP traffic between browsers and web servers, authenticated through SSL certificates. All HTTPS connections use data encryption (specifically AES-256-GCM or ChaCha20-Poly1305 for session data in TLS 1.3). But data encryption is a broader concept: disk encryption, database encryption, email encryption, file encryption, and API security all use encryption without being HTTPS. HTTPS is the visible, browser-facing application of data encryption that site visitors encounter daily; the same underlying cryptographic principles apply to all other forms.

Why is key management the hardest part of encryption?

The security of encrypted data is only as strong as the security of the key. An encryption key stored in the same place as the data it protects provides no protection: an attacker who accesses the data also accesses the key. Keys must be stored separately from the data they protect, in hardware security modules or dedicated key management services, with strict access controls and audit logging. Keys must be rotated periodically. Access to keys must be limited to only the processes and people that need them, and revocable when access should be removed. Most real-world encryption failures are not algorithmic breaks: they are key management failures, from hardcoded keys in source code to unrotated old keys to improperly secured key backups.

Does encryption prevent data breaches?

Encryption does not prevent unauthorized access to systems: that is the domain of access controls, authentication, network security, and vulnerability management. What encryption does is make data useless to an attacker who obtains it without authorization. An attacker who exfiltrates an encrypted database has taken ciphertext they cannot read. A stolen laptop with full disk encryption contains data the thief cannot access. This transforms the consequence of a breach from catastrophic (exposed sensitive data that can be used for fraud, published, sold, or held for ransom) to contained (encrypted data that cannot be used without the key). For regulated industries, this distinction is the difference between a notifiable breach and an encrypted data exposure that may not require individual notification.