Encryption at rest protects data while it is stored. Encryption in transit protects it while it moves between systems. Most compliance questions ask about both, because they defend against different attacks.
The short answer
Data at rest is data sitting in a database, a disk, an object store or a backup. Data in transit is data moving across a network. At rest is protected by disk or database encryption with managed keys; in transit is protected by TLS. Neither protects data while an authorised application is using it.
On this page
Where each one applies
Encryption at rest
At rest encryption defends against someone obtaining the storage itself: a stolen laptop, a copied snapshot, a decommissioned disk, an exposed backup. Cloud providers offer it as a setting, which is why the real work is key management rather than the encryption itself.
| Layer | What it protects against |
|---|---|
| Full disk or volume | Physical theft and access to the underlying storage |
| Database | Copies of database files and snapshots taken outside the application |
| Field level | Exposure of specific sensitive columns even to database operators |
| Backups | The copy most often forgotten, and most often left readable |
The question that follows
Every security questionnaire asks who holds the keys and how often they rotate. Encryption where the same platform stores both the data and an unrotated key protects far less than the checkbox suggests.
Encryption in transit
In transit encryption protects data while it travels. Without it, anyone able to observe the network path, on shared wifi, at an internet provider or inside a compromised network, can read the traffic or alter it.
TLS does the work. When a client connects, the two sides agree on encryption keys and verify the server’s certificate, so the client knows it is talking to the real server and not an impostor. Current practice is TLS 1.2 as the minimum, TLS 1.3 preferred, and SSL along with TLS 1.0 and 1.1 switched off.
| Connection | Usually encrypted? | What to check |
|---|---|---|
| Browser to your app | Yes | HTTPS enforced everywhere, old TLS versions disabled |
| App to database | Often not | Require TLS on the database connection, not just allow it |
| Service to service | Often not | Mutual TLS, so both sides prove who they are |
| App to third-party APIs | Yes | Certificate validation is actually on, not disabled for convenience |
The gap is nearly always internal. External traffic is encrypted because browsers demand it. Traffic between your own services often is not, on the assumption that a private network is safe, which is exactly the assumption zero trust removes.
What frameworks require
| Framework | What it expects |
|---|---|
| PCI DSS v4.0 | Requirement 3 for stored account data and Requirement 4 for transmission across open networks. |
| ISO 27001:2022 | Annex A 8.24 use of cryptography, supported by a documented key management policy. |
| HIPAA | Encryption is an addressable implementation specification, meaning you either implement it or document why an equivalent measure is used. |
| DPDP Act, 2023 | Encryption is named among the reasonable security safeguards expected of a data fiduciary. |
How Osto covers it
Osto manages the transit side directly: SSL and certificate lifecycle management keeps TLS current across your domains, and the WAF terminates and inspects traffic before it reaches origin. On the storage side, cloud posture management flags unencrypted volumes, databases and snapshots across AWS, Azure and GCP, and file access DLP governs who can reach the data once it is decrypted for use.
Free security assessment
Prove your encryption story to a buyer
Certificate lifecycle management, cloud encryption posture and file access controls, with the evidence mapped for you.
Get a free security assessment Book a platform walkthroughTLS kept current · Unencrypted storage flagged · One platform, everything
Frequently asked questions
What is the difference between encryption at rest and in transit?
At rest protects stored data on disks, databases, object storage and backups, defending against someone obtaining the storage itself. In transit protects data moving across a network using TLS, defending against interception. Most frameworks require both.
Is encryption at rest enough on its own?
No. Once an authorised application decrypts the data to use it, encryption at rest offers no protection. An attacker with valid application credentials sees plaintext, which is why access control, MFA and data loss prevention sit alongside it.
What is data in use?
The third state: data loaded in memory and being processed. It is not covered by either at rest or in transit encryption. Confidential computing addresses it, but it is rarely required of a startup today.
Which TLS version should we use?
TLS 1.2 as a minimum, with TLS 1.3 preferred, and SSL along with TLS 1.0 and 1.1 disabled. Scanners and security questionnaires both check for the older versions, so leaving them enabled tends to surface quickly.