Your encryption is only as secure as the keys protecting it. This template provides a policy framework to enforce physical and logical separation between encryption keys and the data they protect.
Purpose of This Template
This policy template sets mandatory controls for encryption key storage, access, and lifecycle management. It's designed to prevent breaches like the Modu-ui Changup incident, where encryption keys were exposed through an API alongside the encrypted data they were meant to protect.
Adapt this template for PCI DSS Requirement 3.6, GDPR Article 32, or HIPAA's encryption requirements under the Security Rule. The core principle is that keys must be separate from data.
Prerequisites
Before implementing this policy, ensure you have:
- Executive sponsorship for architectural changes (some applications may need refactoring)
- A dedicated Key Management System (KMS) or Hardware Security Module (HSM) that meets FIPS 140-3 Level 2 or higher
- An inventory of all systems currently storing encryption keys
- Role-Based Access Control (RBAC) capability in your KMS
- Audit logging infrastructure to capture key access events
If you're still hard-coding keys in application config files, environment variables, or database tables, this policy will require you to redesign those systems.
The Template
ENCRYPTION KEY MANAGEMENT POLICY
Version 1.0
1. SCOPE
This policy applies to all Data Encryption Keys (DEKs) and Key Encryption Keys (KEKs)
used to protect cardholder data, personally identifiable information, protected health
information, or any data classified as confidential or higher.
2. KEY STORAGE SEPARATION (MANDATORY)
2.1 Physical Separation
Encryption keys SHALL NOT be stored on the same physical server, storage volume, or
database instance as the encrypted data they protect.
2.2 Logical Separation
Encryption keys SHALL be stored in a dedicated KMS or HSM that:
- Requires separate authentication credentials from application databases
- Maintains independent access control policies
- Logs all key access requests with requester identity and timestamp
2.3 Prohibited Storage Locations
Encryption keys SHALL NOT be stored in:
- Application source code or compiled binaries
- Configuration files (including .env, .config, .ini, .yaml, .json)
- Database tables or stored procedures
- API responses or request bodies
- Container images or orchestration manifests
- Version control repositories
- Backup archives unless the backup itself is encrypted with a separately managed key
3. KEY ACCESS CONTROLS
3.1 Runtime Access Only
Applications SHALL request decryption keys from the KMS only when processing a specific
data element. Keys SHALL NOT be cached in application memory beyond the duration of a
single transaction.
3.2 Service Account Authentication
Key requests SHALL use service accounts with:
- MFA-protected credentials rotated every 90 days
- IP address restrictions limiting requests to known application servers
- Time-based access windows (if applicable)
3.3 [Least Privilege](/glossary/least-privilege)
Each application SHALL have access only to the specific keys required for its function.
A payment processing application SHALL NOT have access to HR database encryption keys.
4. KEY LIFECYCLE MANAGEMENT
4.1 Key Generation
All encryption keys SHALL be generated within the KMS/HSM using [NIST SP 800-108](/glossary/nist-sp-800-108)
compliant key derivation functions. Keys SHALL NOT be generated externally and imported.
4.2 Key Rotation
DEKs protecting cardholder data SHALL be rotated every 12 months or after any suspected
compromise. KEKs SHALL be rotated every 24 months.
4.3 Key Revocation
When a key is revoked:
- All data protected by that key SHALL be re-encrypted with a new key within 72 hours
- The revoked key SHALL be retained in a "decommissioned" state for 90 days to support
forensic analysis
- Access logs for the revoked key SHALL be reviewed for unauthorized access
5. AUDIT AND MONITORING
5.1 Key Access Logging
The KMS SHALL log:
- Key identifier
- Requesting service account and source IP
- Timestamp (UTC)
- Operation type (encrypt, decrypt, rotate, revoke)
- Success or failure status
5.2 Alert Triggers
Security Operations SHALL be notified immediately when:
- A key is accessed from an unauthorized IP address
- A single service account requests the same key more than 1,000 times per minute
- Any key access occurs outside defined maintenance windows (if applicable)
6. INCIDENT RESPONSE
6.1 Key Compromise Procedure
If a key is suspected of being compromised:
1. Revoke the key immediately in the KMS
2. Generate and deploy a replacement key
3. Re-encrypt all affected data within 72 hours
4. Review all access logs for the compromised key for the prior 90 days
5. Notify affected data subjects if PII/PHI was protected by the compromised key
7. COMPLIANCE VALIDATION
7.1 Quarterly Review
Security Engineering SHALL verify quarterly that:
- No encryption keys exist in prohibited storage locations
- All key access follows the service account authentication requirements
- Key rotation schedules are being met
7.2 Annual Penetration Test
Annual penetration tests SHALL include specific scenarios testing:
- Ability to extract keys from API responses
- Ability to retrieve keys from application memory dumps
- Ability to access keys without proper service account credentials
Customization Options
For PCI DSS environments: Add references to Requirement 3.6.1 (key strength), 3.6.4 (key storage), and 3.6.5 (key component separation for dual control). If you use split knowledge for KEK management, document custodian roles in Section 3.
For cloud-native architectures: Replace "physical server" in Section 2.1 with "cloud availability zone or region." Specify which cloud KMS service you're using (AWS KMS, Azure Key Vault, Google Cloud KMS) and reference its FIPS 140-3 certification status.
For regulated healthcare data: Add HIPAA references to Section 1 and include a data breach notification timeline in Section 6.1 that aligns with the 60-day requirement under 45 CFR 164.408.
For high-transaction environments: Adjust the alert threshold in Section 5.2 based on your transaction volume. A payment processor handling 10,000 transactions per second will need different thresholds than a monthly billing system.
For legacy systems: If you have applications that can't be refactored immediately, create an exception process in Section 2 requiring compensating controls (network segmentation, enhanced monitoring, accelerated rotation) and executive sign-off with a remediation deadline.
Validation Steps
After deploying this policy, validate its effectiveness:
Week 1: Run a configuration scan across all application servers. Search for encryption key material in environment variables, config files, and database connection strings. You should find zero instances. If you find keys, those systems need immediate refactoring.
Week 2: Review your KMS access logs. Verify that every key request includes a valid service account identifier and originates from an expected IP address. Investigate any requests from unknown sources immediately.
Week 4: Attempt to retrieve an encryption key through your public-facing APIs using techniques similar to those in the Modu-ui Changup incident. Send API requests and examine all response bodies for key material. A properly separated architecture will not expose keys in API responses.
Month 3: Simulate a key compromise. Revoke a non-production key and measure how long it takes your team to complete the re-encryption process in Section 6.1. If it takes longer than 72 hours, improve your automation.
Quarter 1: During your quarterly compliance review, pull a random sample of 10 encryption keys from your KMS. Verify that the encrypted data resides on a different system than the key itself. Document the physical or logical separation in your compliance evidence.
This policy won't prevent every breach, but it will prevent the specific architectural failure that exposed 5,000 applicants' data in South Korea: encryption keys traveling alongside the data they're supposed to protect.
