"Is customer data encrypted at rest and in transit?" appears on almost every security questionnaire, and almost every company answers yes. The yes is usually true. It is also usually incomplete, because the question hides several separate decisions: which layer, which copies of the data, which network paths, and who can read the plaintext.
Auditors and experienced buyers know this. Their follow-up questions go to the gaps: the analytics export, the backup in another account, the hop between the load balancer and the application.
This article sets out what each kind of encryption protects against, the layers where it applies, what the frameworks actually require, and the evidence that answers the follow-up questions. Key management, which decides whether any of this is meaningful, gets its own treatment.
What each one protects against
Being clear about the threat stops you from overstating the control.
Encryption at rest protects data from someone who obtains the storage without going through your access controls: a stolen laptop, a discarded drive, a snapshot shared to the wrong account, a backup file copied out of a bucket. It does not protect against anyone who reaches the data through the application or with valid database credentials. The storage layer decrypts transparently for every authorized request, including a malicious one.
That is the honest concession. Provider-managed encryption at rest in the cloud addresses a narrow threat, physical media and raw storage access, which the provider already controls tightly. It is worth having, and it is not the same as protecting data from people.
Encryption in transit protects data from interception and tampering on the network. TLS also lets the client verify it is talking to the real server. It does nothing for data once it arrives at either end.
The layers of encryption at rest
The useful question is not "is it encrypted" but "who can read the plaintext". Each layer answers that differently.
| Layer | What it covers | Who can read the plaintext | Typical use |
|---|---|---|---|
| Disk or volume | Everything on the device or volume | Any process or user on the running host | Laptops, virtual machine disks |
| Storage service or database | Objects, tables, backups and snapshots | Anyone with access to the service or database | The default for managed cloud services |
| Application or field level | Specific fields chosen by you | Only code that holds the key | Payment data, government identifiers, sensitive health fields |
Most cloud services now encrypt at the storage layer by default. Laptops are a separate problem with their own controls, covered in full-disk encryption on every laptop.
Field-level encryption is the only layer that protects against someone with database access. It costs you search, sorting and some indexing on those fields, which is why it is usually reserved for the data whose exposure would do the most harm.
The copies people forget
Encryption settings follow resources, and data does not stay in one resource. Check these explicitly:
Backups, snapshots and read replicas, especially any copied to another region or account
Exports to object storage, often as CSV files for a one-off analysis
Data warehouse and analytics copies
Logs that capture request bodies or identifiers
Non-production environments seeded with production data
Encryption in transit: what good looks like
For external traffic, the settled baseline is:
TLS 1.2 as the minimum, TLS 1.3 where supported. SSL and TLS 1.0 and 1.1 should be disabled. The IETF formally deprecated TLS 1.0 and 1.1 in RFC 8996, and PCI DSS does not treat SSL or early TLS as strong cryptography.
Modern cipher suites with forward secrecy, so a key compromised later cannot decrypt traffic recorded earlier.
Certificates that renew automatically, with an owner and an expiry alert for anything that cannot.
HTTP Strict Transport Security on web properties, so browsers refuse to connect over plain HTTP.
Internal traffic is where most gaps sit. "It never leaves our private network" was a reasonable argument when the network was a building. In the cloud, the private network is shared infrastructure you configure, and a single misconfigured route or compromised workload changes the picture.
Look at three paths in particular. First, the hop between a load balancer that terminates TLS and the application behind it. Second, connections from services to databases and caches, where many managed services can enforce TLS-only connections with a setting. Third, service-to-service calls inside a cluster. Decide for each whether traffic is encrypted, and write the decision down. An auditor can accept a documented, reasoned exception. An unexamined one reads as a gap.
What the frameworks actually say
The frameworks agree on the outcome and differ on how prescriptive they are.
PCI DSS v4.0 is the most specific. Requirement 3 covers stored account data, and Requirement 3.5.1 requires the primary account number to be rendered unreadable wherever it is stored. Requirement 4.2.1 requires strong cryptography when it crosses open, public networks. See the PCI DSS framework page for the wider structure.
HIPAA lists encryption as an addressable implementation specification, for data at rest under 45 CFR 164.312(a)(2)(iv) and in transmission under 164.312(e)(2)(ii). Addressable does not mean optional, as explained in addressable vs required HIPAA encryption. HHS has proposed revisions to the Security Rule, so confirm the current text.
GDPR Article 32 names encryption as an example of an appropriate technical measure. Article 34(3)(a) removes the duty to notify individuals of a breach when the data was rendered unintelligible to anyone not authorized to access it, for example by encryption. Confirm how that applies to a specific incident with counsel.
ISO 27001:2022 Annex A 8.24 (use of cryptography) asks you to define and implement rules for cryptography, including key management.
SOC 2 covers encryption within CC6.1 and, for data being transmitted or moved, CC6.7.
Evidence an auditor accepts
The auditor's question is completeness. One encrypted bucket proves nothing about the other forty. A set that holds up:
An encryption standard: approved algorithms, minimum protocol versions, where field-level encryption is required, and a reference to key management.
Configuration exports for every in-scope data store, showing encryption status, pulled from the cloud provider's API rather than captured as screenshots.
Account-level defaults, such as default encryption for new volumes or buckets, which show that new resources start compliant.
Database settings that enforce TLS for client connections.
External TLS scan results for public endpoints, showing accepted protocol versions and certificate validity.
A certificate inventory with owners and expiry dates.
An exceptions register for documented decisions, such as an internal hop left unencrypted, with the compensating control and an approver.
Where teams usually fall short
The recurring findings are rarely about algorithms. They are about scope.
An unencrypted copy created for a one-time task and never deleted.
Plaintext between the load balancer and the application, never decided, only inherited.
Non-production environments holding production data with weaker settings.
Encryption described in the policy as universal, with no export showing it.
Secrets used to reach encrypted stores kept in the wrong places, which undoes the encryption; see secrets management for engineering teams.
How TrustLynce helps
TrustLynce continuous monitoring runs control checks against the cloud systems you connect and routes failures to their owners, so a data store that drifts from your encryption standard surfaces between audits. The device agent reports disk encryption on laptops, so the endpoint layer of the table above is evidenced alongside the cloud.