Encryption is one of the most important technical controls available to protect sensitive data, but it is also widely misunderstood. Organizations that believe their data is “encrypted” are sometimes surprised to discover that their encryption provides far less protection than they assumed — because the keys used to encrypt the data are stored alongside it, because the algorithms they rely on are outdated and broken, or because their certificates have expired and traffic is flowing unprotected. Encryption is only as strong as the key management practices behind it.
An Encryption and Cryptographic Key Management Policy defines what your organization encrypts, how it encrypts it, which algorithms are approved and which are prohibited, and how the cryptographic keys that make encryption work are generated, stored, rotated, and destroyed. Without this policy, individual teams make ad hoc encryption decisions, deprecated algorithms accumulate across legacy systems, and keys end up stored in ways that undermine the protection encryption is meant to provide.
The business case for this policy extends beyond technical security. State breach notification laws in most US states include “safe harbor” provisions that reduce or eliminate notification obligations when breached data was encrypted with a sufficiently strong algorithm. Cyber insurers increasingly ask about encryption practices during underwriting. And regulators under HIPAA, PCI DSS, and GDPR all expect organizations to be able to demonstrate that sensitive data is protected by encryption that meets defined standards.
What Is an Encryption and Key Management Policy?
This policy establishes the standards and procedures your organization uses to protect data through cryptography. It covers both the encryption of data (the process of rendering it unreadable without the correct key) and the management of the keys used to encrypt and decrypt that data. It applies to all sensitive data handled by the organization, including personal information, protected health information, financial data, and confidential business information.
The policy applies across the technology stack: endpoints and laptops, servers and databases, cloud storage, data transmitted over networks, backup files, and any other location where sensitive data resides. It governs not only the technical controls but the processes and governance around those controls, including who may manage cryptographic keys, what approval is required to use a non-standard algorithm, and how key compromise is handled.
Core Principles of Cryptographic Protection
The first principle is algorithm selection. Not all encryption algorithms provide equivalent protection, and some that were once considered strong have since been demonstrated to be weak or broken. Your policy must specify approved algorithms for each use case and explicitly prohibit algorithms that are no longer considered safe. This is not a set-it-and-forget-it decision — cryptographic standards evolve as computing power increases and vulnerabilities are discovered, and the policy should be reviewed whenever NIST or other standards bodies update their recommendations.
The second principle is key separation. Keys should never be stored alongside the data they protect. If an attacker obtains both the encrypted data and the key, encryption provides no protection. Key storage should be separate from data storage, with access to keys controlled through dedicated systems and access management policies distinct from data access.
The third principle is key lifecycle management. Keys are not permanent. They should be generated with sufficient randomness, distributed securely, rotated on a defined schedule, revoked promptly when compromise is suspected, and destroyed at end of life in a way that prevents recovery. A key management program that only addresses key generation and storage — without addressing rotation, revocation, and destruction — is incomplete.
What the Policy Must Cover
Approved Cryptographic Algorithms
For symmetric encryption (where the same key is used to encrypt and decrypt), AES-256 is the current standard. AES-128 is also acceptable for lower-risk use cases, but AES-256 should be the default for any sensitive data. DES and 3DES are both deprecated and must be prohibited — 3DES in particular remains in use in some legacy payment systems despite being vulnerable to the Sweet32 attack.
For asymmetric encryption (where a public key encrypts data that only the corresponding private key can decrypt), RSA with a minimum key length of 2048 bits is the current minimum, with 3072 or 4096 bits preferred for new implementations. ECDSA (Elliptic Curve Digital Signature Algorithm) with curves such as P-256 or P-384 provides equivalent security with smaller key sizes and is preferred for performance-sensitive applications. RSA-1024 is prohibited.
For hashing (one-way cryptographic functions used for integrity verification and password storage), SHA-256 is the current minimum, with SHA-384 and SHA-512 preferred for high-sensitivity applications. MD5 and SHA-1 are both cryptographically broken and must be prohibited for any security-sensitive use. They remain in widespread use in legacy systems and must be actively identified and replaced. For password storage specifically, modern password hashing algorithms such as bcrypt, scrypt, or Argon2 should be used rather than general-purpose hashing functions.
Data at Rest Encryption
All endpoints (laptops, workstations, and mobile devices) must use full-disk encryption. On Windows systems, BitLocker satisfies this requirement. On macOS, FileVault 2 is the appropriate control. Mobile device management (MDM) systems should enforce encryption as a device enrollment requirement. Full-disk encryption protects data if a device is lost or stolen — without it, a lost laptop is a data breach.
Databases containing sensitive data should be encrypted at rest using database-native encryption features or transparent data encryption (TDE). Cloud storage buckets and object storage must be configured to require encryption for all stored objects. Server-side encryption with customer-managed keys (SSE-C or SSE-KMS in AWS terminology) provides a higher level of control than provider-managed encryption because it allows the organization to revoke access to data by revoking access to the key.
Data in Transit Encryption
All data transmitted over public networks must be protected using TLS 1.2 or higher. TLS 1.3 is the current standard and should be the default for new implementations. TLS 1.0 and TLS 1.1 are deprecated and must be disabled. SSL (all versions) is broken and must be prohibited. The policy should also address internal network traffic — while it may be acceptable to relax requirements for purely internal communications on isolated network segments, the trend toward zero-trust architectures is toward encrypting all traffic regardless of network location.
TLS certificate management is a distinct but closely related requirement. Certificates must be obtained from trusted certificate authorities, must use approved key lengths and algorithms, and must be monitored for impending expiration. Certificate expiration — a preventable operational failure — has caused significant outages and security incidents. Automated certificate lifecycle management tools (such as Let’s Encrypt with ACME protocol automation, or enterprise certificate management platforms) are the practical solution to certificate expiration risk at scale.
Cryptographic Key Lifecycle Management
Key generation must use cryptographically secure random number generators (CSPRNGs). Keys must never be generated using predictable or weak randomness sources. The policy should specify approved key generation methods and tools.
Key storage is where many organizations fail. Keys must not be stored in application code, configuration files checked into source control, or databases alongside the data they protect. The approved approaches are hardware security modules (HSMs) for the most sensitive keys, cloud key management services (AWS KMS, Azure Key Vault, Google Cloud KMS) for cloud-native environments, and dedicated secrets management tools (such as HashiCorp Vault) for application secrets. Each of these approaches provides a secure key store with access logging, access controls, and audit trails.
Key rotation refers to the practice of periodically replacing encryption keys with new ones and re-encrypting data with the new keys. Rotation schedules should be defined based on the sensitivity of the data and the risk of key compromise. Annual rotation is a common baseline for most data encryption keys, with more frequent rotation for highly sensitive data or in high-threat environments. Cloud KMS services often support automatic rotation, which should be enabled where available. Asymmetric key pairs used for TLS certificates are effectively rotated at certificate renewal.
Key revocation must be possible and must be tested. When a key is believed to have been compromised — or when a person with access to the key leaves the organization — the key must be revoked and the data re-encrypted with a new key. The process for emergency key revocation should be documented, tested, and understood by the team responsible for key management. A revocation that takes weeks to execute provides little protection.
Key destruction at end of life must be irreversible. Cryptographic erasure is a technique that leverages key destruction as a proxy for data destruction: if the keys used to encrypt data are securely destroyed, the data is rendered permanently inaccessible. This approach is valuable in cloud environments where overwriting physical storage is not possible. The policy should define approved key destruction methods and require a record of destruction.
Hardware Security Modules
Hardware security modules are dedicated hardware devices designed specifically to generate, store, and manage cryptographic keys in a tamper-resistant environment. Keys stored in an HSM cannot be exported — the HSM performs cryptographic operations on behalf of applications without ever revealing the key material. HSMs are appropriate for the most sensitive key management needs, including certificate authority private keys, master keys in a key hierarchy, and keys protecting large volumes of regulated data. Cloud providers offer HSM-as-a-service options (AWS CloudHSM, Azure Dedicated HSM) for organizations that need HSM security without managing physical hardware.
Encryption vs. Tokenization
Tokenization is a technique that substitutes sensitive data values with non-sensitive placeholder tokens. Unlike encryption, tokenization does not produce ciphertext that can be decrypted with a key — the original value is stored in a secure token vault, and the token is meaningless outside that system. Tokenization is commonly used for payment card numbers (PAN tokenization in PCI DSS environments) and social security numbers. The policy should distinguish between encryption and tokenization and specify when each is appropriate, since they serve different purposes and the compliance treatment differs.
Regulatory and Compliance Drivers
HIPAA addresses encryption as an “addressable” implementation specification under the Security Rule, which is frequently misunderstood. “Addressable” does not mean optional — it means that covered entities must either implement the specification or document a risk-based reason for not implementing it and implement an equivalent alternative measure. In practice, OCR’s enforcement posture and the realities of the current threat environment mean that failing to encrypt ePHI is difficult to justify on risk grounds. Organizations that experience breaches of unencrypted ePHI will face scrutiny over their decision not to encrypt.
PCI DSS Requirement 3 addresses the protection of stored cardholder data and requires that primary account numbers (PANs) be rendered unreadable wherever they are stored. This can be accomplished through strong one-way hash functions, truncation, index tokens, or strong cryptography with associated key management processes. PCI DSS is explicit that key management must include access controls, procedures for changing compromised keys, key retirement procedures, and restrictions on cleartext key components.
GDPR Article 32 lists encryption as an example of an appropriate technical measure for protecting personal data. While GDPR does not mandate encryption in all circumstances, the standard of care for sensitive personal data in the current environment effectively requires it. More importantly, GDPR’s breach notification obligations under Article 33 include a provision that notification may not be required when the personal data was rendered unintelligible by encryption — making encryption a direct mechanism for limiting breach notification exposure.
SOC 2 auditors examine encryption practices as part of their evaluation of Common Criteria CC6.1 (logical access controls) and CC6.7 (transmission controls). The auditor will ask for evidence of encryption for data at rest and in transit, documentation of approved algorithms, and key management procedures. State breach notification safe harbors for encrypted data exist in many jurisdictions (including California, New York, and Texas) and follow a similar logic to GDPR: encryption that renders data unreadable eliminates or reduces notification obligations.
Common Implementation Mistakes
Storing keys alongside encrypted data effectively defeats the purpose of encryption. This mistake occurs most often when developers implement encryption quickly without consulting the security team, storing the encryption key in the same database record, configuration file, or environment variable that is accessible alongside the encrypted data. A policy that specifies approved key storage mechanisms and makes HSMs or cloud KMS the default — rather than leaving key storage to individual developers — prevents this mistake.
No key rotation schedule means that old keys remain in use indefinitely. Keys that have been in use for years have had more opportunity for exposure, and rotating them reduces the window of risk. More critically, organizations with no rotation process have no defined procedure for what to do when key compromise is suspected — they are forced to improvise during an incident.
Use of deprecated algorithms persists because legacy systems are not reviewed against current standards. An annual review of cryptographic implementations should identify any use of MD5, SHA-1, DES, 3DES, or TLS 1.0/1.1 and document a remediation plan. The policy should include a prohibition on deprecated algorithms along with a process for identifying and remediating their use.
TLS certificate expiration is an entirely preventable failure. Certificate monitoring tools and automated renewal processes (available through most major certificate authorities and cloud platforms) can eliminate this risk entirely. Organizations that rely on manual certificate renewal processes inevitably experience expirations. The policy should require automated monitoring with advance alerts and automated renewal where possible.
Finally, many organizations have no documented process for responding to key compromise. When a developer accidentally commits a private key to a public code repository, or when a cloud credential is leaked, the organization must move quickly to revoke the key, rotate to a new key, assess what data may have been exposed, and remediate the root cause. Without a pre-defined process, this response is disorganized and slow.
Building and Maintaining the Policy
Policy development should begin with an inventory of where sensitive data resides and how it currently flows through the organization. This data mapping exercise reveals the encryption gaps that the policy needs to address. Without this foundation, the policy will be written in the abstract and may not address real risks in your specific environment.
Policy ownership for cryptographic standards typically rests with the IT security team, with input from application development and infrastructure teams who implement those standards. A cryptography working group or security architecture review process can help ensure that new implementations comply with the policy before they go into production, rather than requiring remediation after the fact.
Training needs for this policy are primarily technical — developers, system administrators, and cloud architects need to understand the approved algorithms and key management requirements and know how to implement them correctly. Developer training on cryptographic best practices, paired with code review requirements and security testing that checks for common cryptographic mistakes, is the most effective mechanism.
Review cycles should be aligned with cryptographic standards updates from NIST and other bodies. NIST’s transition away from older algorithms has created real work for organizations that are tracking the guidance — the post-quantum cryptography standards being finalized by NIST will eventually require organizations to update their algorithm choices again. Building a review process that monitors these developments is essential.
How It Connects to the Broader Policy Library
The Encryption Policy intersects with several other policies in your library. The Data Destruction Policy relies on cryptographic erasure as a method for rendering data unrecoverable, particularly in cloud environments. The Backup Policy must address encryption of backup files, since backups often contain sensitive data and are frequently stored in locations with different security controls than production systems. The Information Classification Policy determines which data requires encryption and to what standard, since encryption requirements should scale with data sensitivity. The Secure Development Policy incorporates cryptographic requirements for application-level encryption and key handling, ensuring that developers implement cryptography correctly from the start. Together, these policies create a coherent framework for protecting data through its entire lifecycle.