What is data at rest? Data at rest is data that is stored and not currently being moved across a network or actively processed by an application. It sits on a hard drive, in a database, in a cloud storage bucket, on a backup tape or on a USB drive, waiting to be used. Because so much sensitive information spends most of its life in this state, protecting data at rest is one of the most important parts of data security.
This guide explains the meaning of data at rest in plain language, gives everyday examples, compares it with data in transit and data in use, and shows the practical controls that protect stored data. Whether you manage a small business system or you are simply trying to understand a security report, you will finish with a clear picture of what to protect and how.
Data at Rest, Defined Simply
Security professionals usually describe data in three states. Data in transit is data moving from one place to another, such as an email travelling to a server or a file being uploaded. Data in use is data being read, edited or processed in memory by an application. Data at rest is everything else: data that is stored, stable and not moving. A customer database on a server, a spreadsheet saved on a laptop, photos in cloud storage and archived emails are all data at rest.
The phrase can be confusing because stored data is rarely completely still. A database may be queried many times a day, and a file may be opened and closed. The key point is the state between those actions: when the data is written to storage and sits there, it is at rest, and it needs protection in that location. If someone steals the drive, copies the database or gains access to the storage account, they can read the data without needing to intercept it in transit.
Data at rest also includes data that is not obviously a file. Application settings, system logs, cached copies, database backups and even deleted files that have not been overwritten can contain sensitive information. A complete protection plan therefore covers primary storage, backups, archives and temporary copies, not just the main database.
Everyday Examples of Data at Rest
Consider a small online shop. Its customer names, addresses and order history sit in a database. Its product images sit in object storage. Its invoices sit in an accounting system. Its staff rota sits in a shared drive. All of that is data at rest. On a personal level, the same idea applies: photos on a phone, documents on a laptop, messages stored by an app and files in a cloud drive are all at rest when they are not being sent or edited.
In larger organisations, examples multiply. A hospital stores patient records in an electronic health record system and in backups. A bank stores account data, transaction history and scanned documents. A school stores pupil records and safeguarding notes. A software company stores source code, API keys and customer data. Each store has a different risk profile, but the same question applies: who can read it, copy it or change it while it sits there?
Cloud storage does not change the definition. When you upload a file to a cloud provider, it becomes data at rest on the provider’s disks, even though you access it over the internet. The provider may replicate it across several data centres for durability, which means your data at rest exists in more than one physical location. That is why cloud settings, access controls and encryption matter so much.
Data at Rest vs Data in Transit vs Data in Use
| State | What it means | Main risks | Key protection |
|---|---|---|---|
| At rest | Stored on disk, in a database or in cloud storage | Stolen devices, copied databases, exposed storage | Encryption at rest, access control, backups |
| In transit | Moving across a network | Interception, man-in-the-middle attacks | TLS, VPNs, secure protocols |
| In use | Being processed in memory or by an application | Memory scraping, insecure applications | Access control, secure coding, endpoint protection |
Many breaches involve more than one state. An attacker might first steal credentials, then access a database at rest, then exfiltrate the data in transit. Protecting only one state leaves the others open. Good security therefore uses layered controls: encrypt data at rest, encrypt it in transit, limit who can access it, and monitor for unusual activity.
Why Data at Rest Is a Target
Stored data is attractive because it is concentrated and often complete. A single database can contain years of customer records, while a single backup can contain a snapshot of an entire system. Attackers also have time on their side: if they copy a database, they can work on it offline, trying to crack weak passwords or extract useful fields at leisure.
Common ways stored data is exposed include misconfigured cloud storage buckets left public, old databases with default passwords, lost or stolen laptops and drives, and former employees or contractors whose access was never removed. Ransomware also targets data at rest, encrypting files and backups so the owner cannot access them. In each case, the damage is worse when the stored data is unencrypted, over-shared or poorly inventoried.
Regulation adds another reason to take this seriously. Laws such as GDPR, HIPAA and PCI DSS, as well as customer contracts, often require reasonable protection for stored personal and payment data. Encryption at rest, access logging and prompt breach notification are not just good practice; they can be legal and contractual obligations.
How to Protect Data at Rest
Encryption is the headline control. Encryption at rest scrambles stored data so it is unreadable without the correct key. There are several layers: full-disk encryption protects a whole drive if it is stolen; database and file encryption protect specific data sets; and application-level encryption protects individual fields, such as a card number or a health record, even if the database is copied. The strength of encryption depends on key management: keys must be stored separately from the data, rotated regularly and accessible only to authorised systems and people.
Access control is equally important. Only people and systems that need the data should be able to read it, and their access should be reviewed regularly. Enterprise data security practices apply this principle at scale, combining classification, least-privilege access and monitoring so that sensitive stores are not open to everyone by default. For a small team, the same idea can be simple: shared folders with named permissions, database accounts per application, and no shared admin passwords.
Other essential controls include secure backups, patching and monitoring. Backups should themselves be encrypted and stored separately, and they should be tested by restoring them, because an untested backup is only a hope. Storage systems should be patched, and cloud storage should be scanned for public exposure. Finally, data minimisation helps: if you do not need to keep old data, delete it securely, because data you no longer hold cannot be stolen.
Encryption at Rest in the Cloud
Most major cloud providers offer encryption at rest by default for storage services, often with provider-managed keys. That is a good baseline, but it is not the whole story. You should check whether encryption is enabled for every bucket, database and disk, who manages the keys, and whether you can bring your own keys for sensitive data. You should also check access: a bucket can be encrypted and still be publicly readable if its policy is wrong.
For sensitive workloads, consider customer-managed keys, separate keys per environment or per customer, and logging of key use. Also consider tokenisation or masking for highly sensitive fields: instead of storing a real card number, store a token that is useless outside your system. These techniques reduce the value of a copied database and limit the blast radius of a breach.
Data loss prevention tools add another layer by watching for sensitive data leaving authorised stores or being copied to unapproved locations. DLP is not a replacement for encryption, but it helps catch the human errors and insider actions that encryption alone cannot prevent. Likewise, data integrity controls, such as checksums and audit logs, help you detect whether stored data has been altered, not just whether it has been read.
A Practical Checklist
Start by inventorying where your data at rest lives: servers, laptops, phones, cloud buckets, databases, backups and archives. Classify each store by sensitivity, then check the basics for each one: is it encrypted, who can access it, is access logged, and is it backed up? Remove public access from cloud storage, disable default accounts, and revoke access for people who no longer need it.
Next, set a retention policy. Decide how long each type of data should be kept, then delete or archive it on schedule. Test a restore from backup at least quarterly. Finally, rehearse a simple incident plan: if a laptop is lost or a bucket is exposed, who do you notify, how do you revoke keys and access, and how do you assess what was exposed? A short, practised plan beats a long document nobody has read.
Common Mistakes to Avoid
Common mistakes include assuming cloud storage is automatically private, encrypting the main database but leaving backups unencrypted, storing encryption keys alongside the data, sharing one database account across applications, and never testing restores. Another mistake is focusing only on external attackers while ignoring insider access and misconfiguration, which are frequent causes of stored-data exposure.
Also avoid over-collecting data. Every extra field you store, and every extra copy you keep, increases risk and compliance burden. Collect what you need, protect what you keep, and delete what you no longer need, securely and on schedule.
Frequently Asked Questions
What is data at rest?
Data at rest is data that is stored and not currently moving across a network or being processed. Examples include files on a hard drive, records in a database, data in cloud storage and backups.
What is the difference between data at rest and data in transit?
Data at rest is stored data, while data in transit is data moving across a network, such as during an upload, download or email delivery. They need different protections: encryption at rest for stored data and TLS or a VPN for data in transit.
Is data in cloud storage considered data at rest?
Yes. Once a file or record is stored by a cloud provider, it is data at rest on that provider’s systems, even if you access it over the internet. You should check encryption, access policies and key management for every cloud store.
Does encryption at rest protect data if an attacker logs in with valid credentials?
Not fully. Encryption at rest protects against theft of the physical storage or a raw copy of the data, but an authorised application or user who can decrypt the data through normal access can still read it. Access control, monitoring and least privilege are also needed.
How can a small business protect data at rest cheaply?
Enable full-disk encryption on laptops, turn on default encryption in cloud storage, use strong unique passwords and multi-factor authentication, limit shared-folder access, encrypt backups, and delete data you no longer need. These steps cover most everyday risk at low cost.
