Data at Rest

Security teams split the data lifecycle into three states. Each state faces different attackers using different techniques, so each needs its own controls.

The states are not one-time stages. The same record usually sits at rest for most of its life, moves in transit during a few transfers, and is in use only for the seconds an application works on it. A strategy that covers one state leaves the other two open.

Data at rest is any storage medium that holds data while nothing is actively reading or writing it. In practice, that covers locations with very different levels of exposure.

The common thread is persistence. Data stays recoverable from the medium long after the application that created it has closed. That is why storage-level controls are necessary, not optional. Typical locations include:

• Local storage: disks in servers, workstations, and laptops, including temporary files, swap space, and hibernation images
• Databases: relational and NoSQL systems, on-premise or hosted, including raw data files on disk
• Removable and portable media: USB drives, external disks, CDs and DVDs, and memory cards
• Backups and archives: tape libraries, backup appliances, and snapshots, often kept for years
• Cloud storage: object storage buckets, file shares, and managed databases, where the customer usually sets up access

Three properties make stored data attractive to attackers and insiders. Transient data lacks them.

The first is volume. A database or backup collects records over months or years, so one successful access can expose far more data than intercepting a single transmission.

The second is time. Data in transit is exposed for milliseconds. Data at rest stays exposed for as long as it is stored, which can mean months or years if a misconfiguration goes unnoticed.

The third is physical exposure. A storage medium can be stolen, lost, discarded, or resold, and it carries its data with it regardless of network protections.

Regulations reflect this distinction. Many data protection laws and standards require encryption, or an equivalent compensating control, specifically for stored records, separate from any requirement that covers transmission.

No single control fully protects stored data. The standard approach layers several controls, so a failure in one is caught by another.

The right mix depends on how sensitive the data is, where it is stored, and what a specific regulation or contract requires. Encryption and access control are the two baseline controls that almost every framework expects.

In Anexet, the stored volume is visible on the Central Server overview, which lists each database with its data size and record count. The Reports Server sets where collected data is kept and for how long.

A retention period sets how long a record stays exposed at rest, so it should match how sensitive the data is. Review it together with the DLP software setup, so storage and blocking rules follow the same classification.

1 / 2

• 
• 

Encrypting a database or drive does nothing for data once an authorized application decrypts it to display, process, or export it. At that point the data has left the at-rest state, and the relevant risks become data in use and data exfiltration.

Encryption at rest also does not stop a legitimate, authenticated user from copying data to an unencrypted location, emailing it outside the company, or printing it.

Protecting data at rest is therefore one layer of a wider data protection program. That program must also cover all three states and the rules for how people use data after it is unlocked.

Start with the storage locations that hold the most sensitive data, then look for copies nobody tracks: old backups, unmanaged removable drives, and exports left in shared folders. Policies written for every file at once end up blocking work and get switched off.

Further reading: Encryption, coding and hashing – what is the difference?; Information Security of Databases.