A single piece of information can move through all three data states in seconds.
A customer record may begin at rest in a database, become in transit when an application requests it, and become in use while the application processes it in memory.
The state matters because one control rarely protects every part of that path.
Fast rule: Stored data points to at-rest protection. Network movement points to in-transit protection. Active processing points to in-use protection.
1. Three data states at a glance
| State | What the data is doing | Examples | Common protections |
|---|---|---|---|
| At rest | Stored for later access | Disk, database, backup, object storage, removable media | Storage encryption, access control, key management, tokenization, media protection |
| In transit | Moving between systems or locations | HTTPS session, VPN traffic, API request, file transfer, database connection | TLS, IPsec, SSH, VPNs, certificate validation, secure protocols |
| In use | Being processed by a running system | Application memory, CPU processing, active query results, decrypted working data | Least privilege, process isolation, memory protections, trusted execution, application controls |
2. Data at rest
Data at rest is stored rather than actively moving between systems.
Examples include:
- files on a workstation or server
- database records on storage
- cloud object storage
- backups
- snapshots
- archives
- removable media
- an offline laptop drive
Common protections include:
- full-disk encryption
- file or folder encryption
- database or storage-layer encryption
- access controls
- key management
- tokenization where appropriate
- secure backup and media handling
What storage encryption protects
Storage encryption helps when someone obtains the storage without the normal authorization path. A stolen laptop, removed drive, copied backup, or improperly accessed storage volume may be less useful to an attacker when the data is encrypted and the key is protected separately.
Storage encryption does not automatically prevent an authorized application or logged-in user from reading data after the storage has been unlocked.
Exam clue: A stolen powered-off laptop or lost backup media points strongly toward protection for data at rest.
3. Data in transit
Data in transit is moving between systems, networks, or security boundaries.
Examples include:
- browser to web server
- application to application programming interface (API)
- workstation to remote server
- database client to database service
- site-to-site network traffic
- file transfer between hosts
Common protections include:
- Transport Layer Security (TLS)
- Internet Protocol Security (IPsec)
- Secure Shell (SSH)
- virtual private networks (VPNs)
- secure application protocols
- certificate validation
- mutual authentication when appropriate
Encryption protects confidentiality while the data crosses an untrusted or partially trusted path. Integrity and endpoint authentication also matter. A protected tunnel to the wrong endpoint does not solve the identity problem.
Channel protection has boundaries
TLS can protect data between two endpoints while it travels. Once the receiving application decrypts and processes the data, the information has entered the in-use state.
A secure transport protocol therefore does not replace storage protection or application security.
4. Data in use
Data in use is actively being processed.
This can include:
- plaintext in application memory after decryption
- data being transformed by a program
- query results being evaluated
- credentials or keys loaded into memory for an operation
- information displayed to an authorized user
- data inside a running virtual machine or workload
This state is difficult because many useful operations require the system to access the meaningful contents of the data.
Common protections include:
- least privilege
- process and workload isolation
- memory protections
- secure coding
- application authorization
- data minimization
- trusted execution environments or confidential-computing features
- careful handling of secrets and cryptographic keys
Why encryption at rest is not enough
An encrypted database can still expose sensitive information through a compromised application if the application is authorized to decrypt and use the records.
The disk encryption is doing its job. The problem has moved to the application, identity, access-control, or in-use layer.
5. One record can use all three states
Consider an employee opening a payroll record in a web application.
- The record sits encrypted in database storage. At rest.
- The database sends the record to the application over a protected connection. In transit.
- The application decrypts and evaluates the record in memory. In use.
- The application sends the result to the employee's browser over HTTPS. In transit.
- The browser or endpoint might cache information locally. That copy may become at rest again.
This is why data protection should follow the lifecycle rather than stopping at one encryption checkbox.
6. Match controls to the state
| Requirement | Best first association | Control direction |
|---|---|---|
| Protect a lost laptop drive | At rest | Full-disk encryption with protected keys |
| Protect a backup copied from storage | At rest | Backup or storage encryption plus access control |
| Protect credentials sent to a web application | In transit | TLS with correct certificate validation |
| Protect traffic between two sites | In transit | IPsec or another appropriate protected tunnel |
| Reduce exposure between running workloads | In use | Isolation, least privilege, trusted execution, application controls |
| Limit what an application can read after decryption | In use | Authorization, process isolation, data minimization |
Key management crosses every state
Encryption is only as useful as the protection around its keys.
Key controls can include:
- access restrictions
- hardware-backed storage
- rotation
- backup and recovery
- revocation
- separation of duties
- lifecycle tracking
A perfectly chosen algorithm cannot compensate for a key stored beside the encrypted data with no meaningful protection.
7. Work through common scenarios
Scenario 1: Stolen backup drive
A portable drive containing database backups disappears during transport.
The data on the drive is at rest. Encryption of the backup plus strong key separation directly addresses the confidentiality concern.
Scenario 2: Credentials crossing public Wi-Fi
A user signs in to a web service over an untrusted wireless network.
The credentials are in transit while crossing the network. TLS protects the connection when correctly configured and validated.
Scenario 3: Malware reads application memory
An application correctly uses TLS and disk encryption, but malicious code running with sufficient access reads sensitive information after the application decrypts it.
The exposed information is in use. Stronger process isolation, endpoint security, least privilege, and application protections become relevant.
Scenario 4: Encrypted laptop while logged in
A laptop uses full-disk encryption, but an attacker gains control of an already unlocked user session.
Full-disk encryption still protects the powered-off storage. The active session can access in-use data through the authorized operating environment, so endpoint, session, and access controls matter.
Scenario 5: Database replication
Two database servers replicate records over a network.
The stored records are at rest on each server. During replication, the records are also in transit. The design may need both storage encryption and protected transport.
8. Common exam traps
Trap: encrypted means protected in every state
Storage encryption protects stored copies. Transport encryption protects movement. Neither automatically protects an authorized process that is actively using the plaintext.
Trap: HTTPS protects the database file
HTTPS protects the application traffic over the network. Database storage requires its own at-rest controls.
Trap: backups are in transit because they may be moved
A backup sitting on media or in object storage is data at rest. It becomes data in transit while it is transferred.
Trap: data in use always means visible on a screen
Data can be in use inside memory, a processor, a running workload, or an active application even when no person sees it.
Trap: encryption solves authorization
Encryption protects confidentiality under defined conditions. Authorization decides who or what is allowed to access the data after the system can use it.
9. Rapid review grid
| Question clue | Think |
|---|---|
| Disk, backup, database, archive, removable media | Data at rest |
| HTTPS, VPN, file transfer, API connection | Data in transit |
| Memory, CPU, running process, active query | Data in use |
| Stolen powered-off laptop | At-rest encryption |
| Protect traffic across an untrusted network | Transport encryption |
| Compromised application reads decrypted records | In-use protections |
| Stored copy plus network replication | At rest + in transit |
| Encrypted storage after the application decrypts a record | The working copy is in use |