Encryption at rest & in transit
Encryption at rest and in transit is really two controls that auditors and attackers judge very differently: is the data unreadable if the storage layer itself is stolen or copied, and is it unreadable while it moves between services and clients. The hard part is almost never "is encryption turned on" — the major providers now enable at-rest encryption by default across object storage, block volumes, and managed databases — it is key custody and transport enforcement. Who holds the keys, how narrowly key use is granted, whether keys rotate, and whether plaintext connections are refused rather than merely discouraged are what decide whether encryption actually contains an incident. This page focuses specifically on those mechanics for AWS, Azure, and Google Cloud, rather than on where sensitive data lives or whether a store is publicly exposed, which the parent data-security domain covers.
Overview
What this check looks like in practice
Encryption is table stakes, but the details decide whether it actually protects you: which keys, who controls them, and whether transport is enforced or merely available. Default provider-managed encryption covers the baseline, yet regulated data often calls for customer-managed keys with tight key policies and rotation. We verify that stores are encrypted, that key access follows least privilege, and that plaintext transport is refused rather than tolerated.
Why it matters
At-rest encryption defends a narrow but real threat: a leaked snapshot, a shared disk image, a decommissioned volume, or raw media leaving the provider's control. It does nothing against a valid credential, which is why key custody is the part that matters — a customer-managed key you can disable turns a data-exposure event into a non-event, while a key whose decrypt permission is granted account-wide provides almost no isolation. Auditors do not accept "encryption is on" as evidence; they ask who can use the key, whether duties are separated between key admins and data admins, and whether rotation and key-usage logging exist. In transit, an on-path attacker, a misrouted request, or a compromised host on a "private" network can still read plaintext, and a permissive TLS policy allows silent downgrade to weak ciphers. Because HIPAA, PCI-DSS, and most contracts mandate protection of data both at rest and while transmitted, a gap in either half is simultaneously a security exposure and a direct control failure.
What we assess
What we look for
- Stores, block volumes, and managed databases running on default provider-managed keys where a framework or contract actually requires customer-managed keys (CMK/CMEK) and documented custody
- Key policies, grants, or IAM that allow broad or cross-account use of encryption keys — wildcard principals or account-wide kms:Decrypt that defeat the point of encryption
- Automatic key rotation disabled, and a single key protecting many unrelated sensitive datasets so its blast radius is the whole regulated estate
- Object stores, queues, and topics whose resource policies do not explicitly deny non-TLS requests (for example a missing aws:SecureTransport deny), leaving plaintext transport possible
- Databases and load balancers that permit plaintext listeners or TLS versions below 1.2, or that offer weak cipher suites instead of a modern/restricted policy
- Backups, snapshots, and read replicas that inherit weaker key custody or transport enforcement than the source they were copied from
- No separation of duties between the people who administer keys and those who administer the data, and no key-usage logging to make decrypt operations auditable
- Key deletion protection and soft-delete/purge protection left disabled, so an accidental or malicious key removal could render data permanently unrecoverable
Across your clouds
AWS, Azure & Google Cloud
AWS
We check whether stores use AWS-managed keys or customer-managed KMS CMKs, and review each key's key policy and grants for over-broad or cross-account kms:Decrypt, plus whether automatic rotation is enabled. On the transport side we look for S3/EBS/RDS/DynamoDB encryption with the intended key, bucket and SQS/SNS policies that deny requests where aws:SecureTransport is false, RDS force-SSL settings (rds.force_ssl / require_secure_transport), and modern TLS security policies with ACM certificates on ALB and CloudFront.
Azure
We verify Storage Service Encryption and SQL/managed-disk Transparent Data Encryption using Microsoft-managed versus customer-managed keys held in Key Vault or Managed HSM, along with key rotation policy and Key Vault soft-delete and purge protection. For transit we confirm 'Secure transfer required' and a minimum TLS version on storage accounts, TLS enforcement on Azure SQL and Azure Database for PostgreSQL, and hardened TLS policies on Application Gateway and Front Door.
Google Cloud
We check Google-managed default encryption versus CMEK (optionally backed by Cloud HSM or an external EKM) through Cloud KMS across Cloud Storage, BigQuery, Persistent Disk, and Cloud SQL, including the configured key rotation period and any org-policy constraint requiring CMEK (constraints/gcp.restrictNonCmekServices). For transit we review load balancer SSL policies (MODERN or RESTRICTED) and Cloud SQL SSL mode / 'require SSL' so plaintext client connections are refused.
Example finding
One customer-managed key encrypts every regulated dataset, with decrypt granted account-wide
Risk: The stores are technically encrypted, but the key policy grants kms:Decrypt to a broad principal, so any role in the account can read every protected dataset, and because a single key covers unrelated data domains its blast radius is the entire regulated estate. Encryption at rest is providing almost no isolation, and there is no way to cut access to one dataset without breaking all of them.
Fix: Split keys by data domain and sensitivity so each key's exposure is bounded, scope each key policy and grant to the specific roles that genuinely need decrypt, remove wildcard and cross-account principals, enable automatic rotation, and turn on key-usage logging so every decrypt is auditable.
Remediation
How to close it
- 1 Inventory every store, block volume, and managed database and confirm at-rest encryption is enabled; turn it on wherever it is off.
- 2 Move regulated or contract-bound stores from provider-managed keys to customer-managed keys, and segregate keys by data domain so one key never covers unrelated sensitive datasets.
- 3 Tighten key policies and IAM to least privilege: scope decrypt to specific roles, remove cross-account and wildcard grants, and separate the people who administer keys from those who administer the data.
- 4 Enable automatic key rotation, key deletion protection (and soft-delete/purge protection), and key-usage logging so custody is both durable and auditable.
- 5 Enforce TLS everywhere: deny non-TLS requests on object stores, queues, and topics, require SSL on databases, and set a minimum of TLS 1.2 with a modern cipher policy on load balancers and public endpoints.
- 6 Re-check that backups, snapshots, and replicas inherit the same key custody and transport enforcement as their source, and add a periodic drift check so new resources do not regress.
Questions
Do we actually need customer-managed keys, or is default encryption enough?
Default provider-managed encryption satisfies the baseline 'is it encrypted' control and is appropriate for plenty of data. Customer-managed keys matter when a framework or contract requires key custody, separation of duties, revocation, or a defined rotation schedule — and when you want the ability to cut access to a specific dataset by disabling one key. We flag where CMK or CMEK is required and unmet rather than pushing it onto everything.
Traffic inside our VPC is already private — why enforce TLS internally?
A private network reduces exposure but does not make traffic confidential or tamper-evident; a compromised host, a misconfigured peering, or a logging sidecar can still observe plaintext. Enforcing TLS and refusing plaintext listeners means the control no longer depends on the network staying perfectly segmented, which is exactly the assumption PCI-DSS and HIPAA transmission requirements are built to remove.
How do you assess keys and encryption without touching our data?
The review is read-only and looks at configuration and policy: which key type protects each store, the key policy and IAM around it, rotation and deletion settings, and whether endpoints refuse plaintext connections. We never decrypt or read the data itself — the finding is about custody and enforcement, not contents.
See where you stand
A health check finds and prioritizes real exposure. It is not a certification or a promise you will never be breached — closing the findings is what changes your risk.
Related domain surfaces
The rest of what we assess
The same read-only assessment covers every domain — see what else it looks at.
