Compliance requirements drive many of the architectural decisions we make in key management systems. It’s not enough to build something secure - we need to build something demonstrably compliant with regulations like PCI-DSS, HIPAA, and various data protection laws. After spending months working through compliance requirements for our CipherTrust platform, I want to share what I’ve learned about building compliant key management systems.
Why Compliance Matters
Compliance isn’t just about avoiding fines, though those can be substantial. It’s about demonstrating to customers, auditors, and regulators that you’re handling sensitive data responsibly. For Thales, many of our customers are in heavily regulated industries: finance, healthcare, government. They can’t use our products unless we can prove compliance.
The challenge is that compliance requirements are often written in general terms - “implement appropriate technical safeguards” - that require interpretation. What makes a safeguard “appropriate”? How do you prove it to an auditor? This is where things get interesting.
PCI-DSS Key Management Requirements
PCI-DSS (Payment Card Industry Data Security Standard) has specific requirements for cryptographic key management. Requirement 3.6 states that key management processes must include:
- Key generation using approved methods
- Secure key distribution
- Secure key storage
- Key rotation at defined intervals
- Destruction of keys when no longer needed
- Split knowledge and dual control of keys
- Prevention of unauthorized substitution of keys
Each of these requirements shapes our architecture. Let me break down a few:
Split knowledge and dual control: No single person should have access to complete cryptographic keys. We implement this using M-of-N authentication schemes. Generating a new master key might require 3 out of 5 security officers to authenticate. The HSM enforces this - even with full system access, you couldn’t generate a master key alone.
Key rotation: PCI requires cryptographic keys to be retired after a defined period. We’ve built automated key rotation that generates new keys, re-encrypts data keys under the new master keys, and securely destroys old key material. The entire process is logged for audit purposes.
Secure key storage: Keys must be stored encrypted under separate keys, in physically secure locations. HSMs provide this - key material is always encrypted inside the HSM, and the HSMs themselves are physically tamper-resistant.
HIPAA Requirements
HIPAA (Health Insurance Portability and Accountability Act) is less prescriptive than PCI-DSS. It requires “appropriate” encryption but doesn’t specify exact requirements. This flexibility is both good and bad.
The key HIPAA requirements affecting key management are:
Access controls: Only authorized personnel can access encryption keys. We implement role-based access control (RBAC) where permissions are granted based on job function, not individual identity.
Audit trails: Every access to protected health information must be logged. For key management, this means logging every key operation: who requested encryption/decryption, when, for what purpose, and whether the request was approved or denied.
Integrity controls: Mechanisms to ensure ePHI hasn’t been improperly altered or destroyed. Our key management system maintains cryptographic checksums over key metadata and validates integrity before operations.
Transmission security: Keys transmitted between systems must be protected. We use mutually authenticated TLS for all key management communications, with certificate-based authentication to prevent man-in-the-middle attacks.
Audit Logging Architecture
Compliance requirements universally require comprehensive audit logging. But what should we log, and how do we ensure logs aren’t tampered with?
We log every key operation with these details:
- Operation type (encrypt, decrypt, generate, rotate, destroy)
- Key identifier
- Requesting user or service account
- Source IP address
- Timestamp
- Operation result (success or failure with error details)
- For policy-based operations, which policies were evaluated and their results
These logs are written to an append-only store. We’re using Elasticsearch for log storage and analysis, which I’ll cover in detail in future posts. The key property is that logs can’t be modified or deleted after writing - essential for compliance.
Logs are also written to immutable storage (write-once media) periodically for long-term retention. Many compliance frameworks require retaining audit logs for years.
Separation of Duties
A common compliance requirement is separation of duties - the principle that critical operations require multiple people. This prevents both accidental errors and malicious insider actions.
We implement separation of duties at several levels:
Administrative separation: Different teams manage different parts of the infrastructure. The team that operates HSMs is different from the team that manages access policies.
Operational separation: Sensitive operations require approval from multiple people. Rotating a master key requires approval from security officers in different organizational units.
Technical separation: Even with full system privileges, certain operations are impossible without multiple credentials. The HSM enforces this through hardware controls that can’t be bypassed by software.
Policy Management for Compliance
Compliance isn’t just about the key management system itself - it’s about enforcing policies on how keys are used. We’re building a comprehensive policy engine that enforces rules like:
- Payment card data must be encrypted with keys that rotate every 90 days
- Healthcare data encryption keys can only be accessed by HIPAA-trained personnel
- Keys protecting European customer data can’t be accessed from US data centers (data residency requirements)
- Audit logs must be reviewed weekly, with escalation for suspicious patterns
These policies are expressed in a domain-specific language and enforced by the platform. Applications can’t bypass the policies - they’re enforced at the key management layer.
Proving Compliance to Auditors
Building compliant systems is one thing; proving it to auditors is another. We’ve learned to design with auditability in mind:
Evidence generation: The system automatically generates evidence of compliance. Want to know if keys are being rotated per policy? There’s a report for that. Need to prove who accessed which keys last quarter? Query the audit logs.
Configuration validation: Automated checks verify that system configuration matches compliance requirements. For example, verify that all master keys have dual control enabled, that session timeouts match policy, that encryption algorithms meet minimum strength requirements.
Compliance dashboards: Real-time visibility into compliance status. If a configuration drift occurs that impacts compliance, alerts fire immediately rather than discovering it during an annual audit.
The Documentation Burden
Compliance requires extensive documentation. We maintain:
- System architecture diagrams showing data flows and trust boundaries
- Detailed procedure documents for key operations
- Change logs showing when configurations changed and who approved them
- Incident response procedures specific to key compromise
- Business continuity and disaster recovery plans
- Training records showing who has been trained on key management procedures
This documentation must be kept current. When we change the architecture, we update the diagrams. When procedures change, we update the documentation. Stale documentation fails audits.
Compliance in Multi-Cloud Environments
Multi-cloud architectures complicate compliance. Different cloud providers have different compliance certifications. AWS might be PCI-certified in us-east-1 but you’re deploying in a newer region without certification yet.
Our approach is to build compliance controls into the key management layer rather than relying solely on cloud provider compliance. If we enforce encryption with compliant key management practices, we reduce dependence on the cloud provider’s compliance status.
We also implement geographic controls. If compliance requires that European customer data stays in Europe, we enforce this through key management policies. Keys protecting European data are only available in European data centers. Applications can’t accidentally (or intentionally) decrypt European data in US data centers because the keys simply aren’t available there.
FIPS 140-2 Validation
Many compliance frameworks require FIPS 140-2 validated cryptographic modules. This is a NIST standard for cryptographic hardware and software. The HSMs we use are FIPS 140-2 Level 3 validated.
FIPS validation is expensive and time-consuming. The certification process takes months and costs hundreds of thousands of dollars. But for compliance, it’s often non-negotiable. Government agencies won’t use non-FIPS validated cryptography. Many enterprises require it for PCI compliance.
The challenge is that FIPS validation applies to a specific hardware and firmware version. If we update HSM firmware, strictly speaking, we need re-validation. In practice, vendors maintain validation for firmware updates that don’t change cryptographic functionality, but it’s something to track carefully.
Compliance Automation
Manual compliance checking doesn’t scale. We’re building automation that continuously monitors compliance:
- Automated scans verify cryptographic configurations
- Policy compliance is checked in real-time, not just during audits
- Anomaly detection identifies unusual key access patterns that might indicate compromise
- Automated remediation for certain classes of compliance drift
The goal is “continuous compliance” where we always know our compliance status rather than discovering issues during annual audits.
Looking Forward
Compliance requirements continue to evolve. GDPR (General Data Protection Regulation) is coming from Europe and will have significant implications for key management. The right to be forgotten means we need to securely destroy keys on demand. Data portability means encrypted data might need to be decrypted and moved between systems.
We’re also watching industry-specific regulations. Financial services regulations around encryption are getting more stringent. Healthcare is seeing new requirements for breach notification. Each new regulation creates new requirements for key management systems.
Key Takeaways
For teams building compliant key management systems:
- Design for auditability from the start - retrofitting audit logging is painful
- Implement separation of duties and dual control for sensitive operations
- Automate evidence generation - manual compliance checking doesn’t scale
- Maintain comprehensive documentation and keep it current
- Use FIPS 140-2 validated HSMs when compliance requires it
- Build policy enforcement into the platform, not into applications
- Plan for compliance requirements to evolve and change
Compliance shapes architecture in profound ways. It’s not something you can bolt on at the end. The teams that succeed in building compliant systems are the ones that design for compliance from the start, understanding how regulations will constrain technical decisions.
It’s challenging work, but it’s essential. Getting compliance right protects customers, protects the business, and ultimately protects the sensitive data we’re all trying to secure.