SaaS data encryption and key management: a practical guide
Choose encryption layers from a data threat model, protect and rotate keys through their lifecycle, separate key access from stored data, and test recovery.
In this guide
What should SaaS encryption protect?
Encryption changes readable information into ciphertext that requires a key to recover. Its protection depends on where encryption happens, who can use the key, how the application handles plaintext and what an attacker can reach. Start by reducing the data you retain and mapping its sensitivity and movement. Encryption at rest or in transit does not by itself prevent an authorized but misused account, a compromised application or a poorly controlled key from exposing data.
Map sensitive data and the threat each layer addresses
Record where customer data is collected, processed, stored, backed up, exported and deleted. Decide whether the main concern is network interception, stolen disks, a database copy, a compromised cloud account, overly broad operator access or another threat. Encryption at the network, disk, database or application layer addresses different risks; select layers from the threat model instead of treating one setting as a complete answer.
Use modern, maintained cryptographic libraries and protocols
Use vetted platform libraries and managed services with secure defaults. Do not design a custom cipher, key exchange or password-encryption format. Set current protocol and algorithm choices through a maintained standard or provider configuration, and plan how to update them as guidance changes. Passwords are a special case: store them with a password-hashing function designed for that purpose, not reversible encryption.
Separate key permissions from ordinary application permissions
Keep long-term keys in a managed key service or hardware-backed vault where available, and restrict who or what can request each cryptographic operation. Separate key administration from routine service administration, require strong authentication for sensitive key changes and record key usage. A key vault adds controls, but poor identity permissions can still expose its operations.
| Data / location | Threat addressed | Encryption layer | Key owner / access | Rotation and recovery test |
|---|---|---|---|---|
| Production database | ||||
| Backups and exports | ||||
| Application secrets |
How should SaaS teams design key storage and rotation?
Consider envelope encryption for sensitive stored data
A common pattern uses a data-encryption key (DEK) for the data and a separately protected key-encryption key (KEK) to protect the DEK. A managed key service can perform or control the wrapping operation while the application stores the encrypted data key with its record. Design access and tenant boundaries carefully; envelope encryption does not help if the same compromised workload can freely decrypt every customer’s data.
Keep an inventory and define the complete key lifecycle
Record each key’s purpose, algorithm, owner, storage location, permitted services, creation date, rotation or cryptoperiod policy, backup or recovery method and destruction plan. Plan generation, distribution, activation, rotation, revocation, compromise response and deletion before production use. Do not place encryption keys in source control or alongside unprotected production data.
Rotate with a migration and rollback plan
A key change may require rewrapping data keys, re-encrypting records, updating certificates or refreshing dependent services. Test how old ciphertext remains readable during a migration and how access to a retired key is limited. Keep old keys only as long as a documented recovery need requires; rotation without an inventory can make data permanently unreadable.
How do you audit encryption and recover from key incidents?
Log and review key events without logging key material
Record who or which workload requested a key operation, which key identifier was involved, when it happened and whether it succeeded. Never log plaintext keys, access tokens or decrypted sensitive values. Alert on unusual decrypt volume, unexpected identities, disabled audit trails, policy changes and key deletion attempts.
Test key backup, restoration and compromise response
Encrypted data can become unavailable if the required key is lost. Test protected backup or recovery paths, separation of duties and restoration in a controlled environment. If a key may be compromised, identify the data and keys it protected, restrict or revoke access, rotate or re-encrypt as appropriate, preserve evidence and assess customer impact.
Match encryption claims to the actual boundary
Describe which data is encrypted, at what layer, who can decrypt it and whether the service processes plaintext. Do not claim ‘end-to-end encryption’ if the provider can access decrypted content. Distinguish encryption at rest, transport encryption, tenant-specific keys and customer-managed keys so buyers can compare the protection they actually need.
SaaS encryption and key management questions
Does encryption at rest protect data from a compromised application?
Usually not if the compromised application has permission to request decryption. It can help against some storage-media or database-copy threats, but application identity, authorization, monitoring and key separation determine what a live attacker can do.
Should the key and encrypted data be stored together?
Keep key-encryption authority separate from the data store where the architecture allows it. Envelope encryption may store a wrapped DEK beside ciphertext while protecting the KEK in a separate service. Access to both still needs to be tightly controlled and audited.
Does rotating a key require encrypting every record again?
It depends on the design. Rewrapping DEKs under a new KEK can avoid re-encrypting all data, while a compromised DEK or an architecture without envelope encryption may require broader re-encryption. Test the migration and retain only the historical keys required for recovery.
Can a SaaS provider promise that no employee can read customer data?
Only if the architecture and operational controls support that exact claim. Many services must process plaintext to provide features or support. Explain access boundaries and customer-managed or end-to-end options accurately, and do not imply that encryption removes all privileged access.
Related practical guides
Related issue guides
Sources and publication record
Draft prepared 27 September 2026; engineering, security and editorial review pending · Sources checked .
- OWASP Cryptographic Storage Cheat SheetOWASP Foundation
- NIST SP 800-57 Part 1 Revision 5: Recommendation for Key ManagementNational Institute of Standards and Technology