Data Encryption in the Cloud: Five Reasons to Care Past the Checkbox

Every major cloud provider will encrypt your data at rest and in transit by default. That's the checkbox most customers stop at, and the reason auditors keep finding problems. Default encryption protects you from exactly one threat: someone physically walking off with a disk drive. It does not protect you from the actual attacks that happen to cloud customers. If you want encryption to be a real security control rather than a compliance slide, you need to care past the checkbox.

Here are five reasons the distinction matters, and what we recommend customers actually do about each one.

1. Provider-managed keys mean the provider can decrypt your data

When you let the cloud vendor manage the encryption keys — which is the default in almost every service — the vendor has the technical ability to decrypt your data. They don't do it casually, and they have internal controls, but the capability exists. For some data, that's fine. For financial records, medical data, source code, legal documents, or anything subject to a subpoena, it is not.

The fix is customer-managed keys (CMK) stored in a key vault under your control. Every major cloud has a version of this: AWS KMS with customer keys, Azure Key Vault with BYOK, Google Cloud KMS with CMEK. When you use these properly, the cloud provider cannot decrypt your data without your key vault granting access, which means a subpoena, an insider threat at the provider, or a misconfigured service at the provider cannot leak your data.

The gotcha is that customer-managed keys come with operational responsibility. You have to back them up (but not insecurely), rotate them on a schedule, audit their usage, and make sure losing access to your key vault doesn't lock you out of your own data. This is real work, and it's a reason some customers choose not to do it. For most regulated industries, it's the only defensible choice.

2. "Encrypted at rest" doesn't mean what most people think it means

"Encrypted at rest" usually means the underlying disk is encrypted by the cloud provider at the storage layer. When your application reads the data, it reads it in plaintext — the decryption happens transparently below the application. Which means any attacker who gets access to your application (via a compromised credential, a vulnerable API endpoint, or a malicious insider) can read the data as if it were not encrypted at all.

The defense against this is application-level encryption for sensitive fields. Encrypt the credit card number, the Social Security number, the medical record, the customer secret — in the application, before it hits the database — with a key the database doesn't have. Now the attacker who compromises the database gets ciphertext. This is more work than storage-level encryption, and it constrains what you can query, but for specific high-value fields it's the only thing that actually protects the data from an application-layer compromise.

Teams that get this right use envelope encryption patterns: a data encryption key per record or per tenant, wrapped with a key encryption key from a key vault, and rotated without re-encrypting everything. Teams that don't get it right assume "encrypted at rest" covers them and are surprised when the breach post-mortem says it didn't.

3. TLS is not a one-time setup

Encryption in transit — TLS — is the other half of the checkbox, and it's where we see the most surprising amount of drift over time. A cloud environment that was set up correctly in 2021 with TLS 1.2, strong cipher suites, and valid certificates may be serving traffic in 2024 with expired certificates, weak ciphers, and TLS 1.0 still enabled on a load balancer nobody remembered.

The work here is ongoing: regular scans with tools like testssl.sh or SSL Labs, automatic certificate renewal through Let's Encrypt or the cloud provider's certificate manager, and a policy that forbids TLS 1.0 and TLS 1.1 enterprise-wide. Certificates are the single most common cause of expired-encryption incidents we see — someone's cert expires at 3am on a Saturday and takes down a customer-facing service, and the reason is always that nobody was tracking the expiration dates.

Automate renewal, monitor expiration, and scan your TLS posture regularly. Or expect the cert-expiration incident that we have watched happen to too many customers to count.

4. Encryption without key management is a false assurance

Almost every encryption failure we've investigated traces back to key management, not to the crypto itself. The math works. What doesn't work is:

• Keys stored in config files checked into source control.
• Keys rotated on a schedule that never actually happens because the rotation process is manual and painful.
• Keys with access permissions so broad that anyone with IAM access to the environment can read them.
• Keys that were "rotated" but the old key is still in use by services that never got updated.
• Keys stored in key vaults that themselves are protected by a single admin password shared by the team.

Good key management means: keys live in a purpose-built vault (never in code or config), access to the vault is audited and alerted, rotation happens automatically through the vault's API, and no single human being has both the ability to read keys and the ability to exfiltrate data. These are boring, operational controls, and they are the actual determinant of whether your encryption matters.

The test we apply: if an attacker got access to your production environment with an admin-level credential, what would it take them to get to your encryption keys? If the answer is "nothing, they're right there," your encryption isn't protecting you. If the answer is "they'd need a second credential with different permissions, and any attempt would trigger alerts," you have real defense in depth.

5. Regulatory exposure is asymmetric, and encryption is cheaper than the fine

For a lot of businesses, encryption is not primarily a security decision — it's a regulatory one. GDPR, HIPAA, PCI DSS, SOC 2, CCPA, state-level breach notification laws — all of them treat encrypted data differently from unencrypted data when it comes to breach disclosure and liability. A breach of encrypted data that keeps the keys separate is often not a reportable event at all. A breach of unencrypted data is a mandatory disclosure, a regulator investigation, and potentially millions of dollars in fines.

The cost of doing encryption properly — customer-managed keys, application-level field encryption for sensitive data, strong TLS everywhere, audited key management — is a few percent of an operations budget. The cost of a single regulator-reported breach is usually several years of that budget. The math is rarely close.

This is not a reason to add encryption as compliance theater. Compliance-driven encryption that doesn't actually protect data is worse than no encryption because it creates false confidence. It is a reason to stop treating encryption as optional and start treating it as infrastructure.

What we recommend

The baseline we bring to new customers looks roughly like this:

• Customer-managed keys for any workload handling regulated or sensitive data.
• Application-level encryption for high-value fields (PII, payment data, medical records).
• TLS 1.2 or higher everywhere, with automatic certificate renewal and weekly posture scans.
• Key management in a dedicated vault (Azure Key Vault, AWS KMS, HashiCorp Vault) with audit logging.
• Rotation schedules that happen automatically, not by calendar reminder.
• Separation of duties: the person who manages keys is not the same person who reads data.

This is not the most secure possible configuration. It is the configuration that actually gets implemented and stays implemented in real environments. Perfect encryption that nobody operates is worse than good encryption that actually runs.

Three Takeaways

1. Default encryption protects you from almost nothing. Customer-managed keys matter.
2. Key management is the real problem. The math is easy; the operations are hard.
3. Regulatory exposure is asymmetric. Encryption is cheaper than the fine, every single time.