Your data governance team encrypts, rotates keys, and checks compliance boxes. Yet, you might find your "protected" data readable in backup logs, your key management system granting access to too many people, or your encryption scheme not meeting Article 32 requirements.
These failures aren't due to ignorance. They occur because cryptography demands both technical precision and governance discipline. Often, teams focus on one and neglect the other. You encrypt data at rest but miss it in transit. You generate strong keys but store them next to the data they protect. You meet the letter of a regulation but create new exposure points.
Here's what goes wrong, why it keeps happening, and how to fix it before your next audit.
Treating Encryption as a Binary Control
You encrypt sensitive data and mark it as "implemented" in your compliance matrix. But encryption isn't just on or off. It's a system with multiple components: the algorithm, key strength, key storage, access controls, rotation policies, and cryptographic erasure procedures.
Why this happens: Regulations like GDPR Article 32 require "encryption of personal data" without specifying details. Teams interpret this as "turn on encryption" rather than "design a cryptographic system." They enable database-level encryption, assume compliance, and move on.
The consequence: Your database encrypts data at rest, but application logs capture plaintext values during processing. Backup systems store unencrypted copies. API responses leak data to third-party analytics tools. You've encrypted one component while leaving others exposed.
The fix: Map every location where restricted data exists: production databases, staging environments, logs, backups, data warehouse extracts, API responses, and temporary files. Document which cryptographic control protects each location, what key protects that control, and who can access that key. If you find gaps, address them with targeted controls: encrypt logs, sanitize backups, implement column-level security for sensitive fields, or apply data masking before extraction.
Storing Keys Alongside Encrypted Data
You encrypt customer records in your production database. The encryption keys are in a configuration file on the same server, protected by file system permissions.
Why this happens: Key management systems add complexity. They require integration work, access policies, rotation procedures, and monitoring. Storing keys locally feels simpler and still provides "encryption." Teams assume that file permissions and network segmentation provide sufficient protection.
The consequence: Anyone with server access can read both the encrypted data and the key. Database backups contain both. A compromised service account grants access to everything. You've created the illusion of protection without substance. Under GDPR, this may not qualify as encryption at all, because the Technical and Organisational Measures don't ensure confidentiality.
The fix: Separate key storage from data storage using a dedicated key management service or hardware security module. Implement role-based access so database administrators can't read encryption keys, and security teams can't read application data. Require dual authorization for key access. Enforce automatic key rotation every 90 days. Document the separation in your Article 30 records of processing, demonstrating that your encryption provides real protection.
Ignoring Cryptographic Erasure Requirements
Your retention rules delete personal data after three years. Your deletion script removes database records. But encrypted backups persist for seven years per your infrastructure Retention Rule, and those backups contain the "deleted" data.
Why this happens: Teams focus on production Data Purging and treat backups as infrastructure, not data subject to retention limits. They assume that encryption makes old backups irrelevant because "no one can read them anyway." They don't realize that keeping encrypted personal data beyond its retention period may violate Article 5(1)(e) storage limitation.
The consequence: A data subject exercises their Right to be Forgotten. You delete their production records but discover you can't remove them from encrypted backups without destroying the entire backup set. You're stuck between preserving business continuity and honoring a regulatory obligation. Worse, if those encryption keys are ever compromised, years of "deleted" data become readable again.
The fix: Implement cryptographic erasure: encrypt data with a unique key per retention cohort, store those keys separately, and destroy the key when the retention period expires. The encrypted data becomes permanently unreadable without requiring backup deletion. Document this approach in your Records Disposition Schedule. For data subject deletion requests, delete the production record and the associated encryption key. The backup data remains, but it's cryptographically erased and can't be reconstructed.
Selecting Encryption Strength Based on Compliance Minimums
Your team implements AES-128 because NIST lists it as acceptable and your compliance framework doesn't specify a higher standard. You've met the requirement.
Why this happens: Teams treat cryptographic standards as ceilings rather than floors. If a regulation doesn't mandate AES-256, they choose the computationally cheaper option. They optimize for current compliance, not future-proof security.
The consequence: AES-128 is currently secure, but cryptographic standards evolve. As computing power increases, weaker algorithms become vulnerable faster. When NIST or your Supervisory Authority updates guidance, you'll face an expensive re-encryption project. More immediately, if a breach occurs and investigators find you chose minimum-acceptable encryption, that choice becomes evidence of inadequate Technical and Organisational Measures.
The fix: Default to AES-256 for symmetric encryption and RSA-2048 or higher for asymmetric encryption. Use SHA-256 or SHA-3 for hashing. These provide substantial security margins without meaningful performance penalties on modern hardware. Document your rationale: you selected strong cryptography to ensure long-term data protection, not just minimum compliance. This documentation protects you during breach investigations and demonstrates the "state of the art" consideration required by Article 32.
Failing to Validate Third-Party Cryptographic Claims
Your vendor promises "end-to-end encryption" and "zero-knowledge architecture." You accept their security questionnaire at face value and sign the Data Processing Agreement.
Why this happens: Cryptographic validation requires specialized expertise. Most data governance teams can't audit encryption implementations, so they rely on vendor assertions and compliance certifications. They assume that SOC 2 reports or ISO 27001 certificates verify cryptographic controls.
The consequence: "End-to-end encryption" might mean the vendor can't read data in transit but can read it at rest. "Zero-knowledge" might apply only to passwords, not to the data you're actually protecting. When you discover the gap, you've already transferred sensitive data to a processor whose controls don't meet your requirements. You're liable under Article 28 for failing to ensure appropriate safeguards.
The fix: Require vendors to specify their cryptographic implementation in writing: which algorithms, what key lengths, where keys are stored, who can access them, and what data remains readable to vendor personnel. Ask whether they can decrypt your data for support purposes. Request architecture diagrams showing key management flows. Include these specifications in your Data Processing Agreement as binding obligations. If the vendor can't or won't provide details, that's your signal to find a different processor.
Prevention Checklist
Before you deploy cryptographic controls:
- Document where restricted data exists across all systems, including logs, backups, and temporary storage
- Specify the cryptographic algorithm, key length, and key storage location for each protected data store
- Separate encryption keys from encrypted data using a dedicated key management system
- Implement automatic key rotation every 90 days and document the procedure
- Design cryptographic erasure into your retention workflow so you can destroy data by destroying keys
- Default to AES-256 and document why you selected stronger-than-minimum encryption
- Require third-party processors to specify their cryptographic implementation in your Data Processing Agreement
- Test your deletion procedures against encrypted backups to verify you can honor Right to be Forgotten requests
- Review whether your encryption qualifies as a Technical and Organisational Measure under Article 32, or just creates the appearance of one
Cryptography protects data only when you implement it as a system, not a checkbox. The mistakes aren't technical failures. They're governance gaps.
