Category: Cryptography & Encryption
Data at Rest
Also known as: DAR, Stored Data, Data-at-Rest
Simply put
Data at rest is information that is stored somewhere rather than actively moving across a network or being processed in memory. Examples include files saved on a hard drive, records in a database, backups, and objects held in cloud storage. Protecting it generally involves controls such as encryption so that the data cannot be read if the storage device or storage service is accessed by someone unauthorized.
Formal definition
Data at rest refers to digital data persisted in non-volatile storage for any duration, as distinguished from data in transit (moving between locations) and data in use (loaded into memory or being processed). It encompasses data held in block storage, object storage, file hosting services, databases, data warehouses, backup systems, and cloud platforms. A common protection mechanism is encryption at rest, which in many implementations operates at the disk or storage layer so that data is unintelligible if the underlying media or storage service is accessed without authorization; specific safeguard requirements and encryption standards depend on the applicable framework, impact level, and data type (for example, CUI or classified information), which the reader should verify against the current authoritative text.
Why it matters
Data at rest is often the largest and most persistent concentration of an organization's sensitive information. Unlike data in transit, which is exposed only momentarily as it moves between locations, stored data may sit in databases, backups, file shares, and cloud object storage for months or years, making it an attractive target. If storage media or a storage service is accessed by an unauthorized party, unprotected data at rest can be read directly, which is why encryption at rest is a foundational safeguard in most data protection programs.
For defense and public sector environments, the stakes are shaped by the type of data involved. Requirements for protecting Controlled Unclassified Information (CUI) generally differ from those for classified information, and specific encryption standards, impact levels, and tailoring depend on the applicable framework. Compliance officers should treat protecting data at rest not as a single control but as a category of safeguards whose exact requirements must be verified against the current authoritative text for the system and data type in question.
Who it's relevant to
Information System Security Managers (ISSMs) and system owners
ISSMs are typically responsible for ensuring stored data is protected in accordance with the applicable control baseline. This includes identifying where CUI or other sensitive data is persisted, across databases, backups, and cloud storage, and confirming that encryption at rest and related safeguards meet the requirements for the system's impact level. The precise standards should be verified against the current authoritative text rather than assumed.
Compliance officers and auditors
Those assessing a system need to evaluate whether data-at-rest protections are implemented and documented, and to distinguish stored-data controls from those addressing data in transit and data in use. Because specific encryption and safeguard requirements vary by framework, data type, and tailoring, assessors should anchor findings to the applicable current requirements rather than to general practice.
Government contractors handling CUI
Contractors that store CUI on their own systems or in cloud platforms must protect that data where it is persisted, including in databases, file storage, and backup systems. Requirements for CUI generally differ from those for classified information, and the applicable encryption expectations should be confirmed against the governing text and contract terms.
Cloud and infrastructure teams
Teams operating block storage, object storage, and cloud platforms configure and manage encryption at rest at the disk or storage layer. They should understand that encryption at rest protects against unauthorized access to the underlying media or storage service but does not by itself address data in use or data in transit, which require separate controls.
Inside DAR
Stored Data Scope
Data at rest refers to data that is stored on persistent media rather than actively moving across a network (data in transit) or being processed in memory (data in use). This includes data on hard drives, solid-state drives, removable media, backup tapes, databases, file shares, and cloud storage repositories.
Encryption of Stored Data
A primary protection mechanism for data at rest is cryptographic protection. Federal and DoD guidance generally emphasizes the use of validated cryptographic modules; practitioners should confirm applicable requirements, such as FIPS 140-validated cryptography, against current authoritative sources for their system's categorization and impact level.
Applicable Control Sources
Protection of data at rest is addressed within control catalogs such as NIST SP 800-53 (maintained by NIST) for federal systems and NIST SP 800-171 for Controlled Unclassified Information (CUI) in nonfederal systems. The specific controls, enhancements, and baselines applicable depend on the system's categorization and any agency-specific tailoring, and should be verified against the applicable revision.
Information Type and Sensitivity
The required protections for data at rest generally scale with the sensitivity and categorization of the information, such as CUI under NIST SP 800-171, national security information under other authorities, or data supporting systems categorized under the RMF. Scope boundaries between federal civilian, defense, and classified environments affect which requirements apply.
Key Management
Effective protection of data at rest depends not only on encryption but on the management of cryptographic keys, including generation, storage, rotation, and destruction. Weak key management can undermine otherwise compliant encryption implementations.
Common questions
Answers to the questions practitioners most commonly ask about DAR.
Does encrypting data at rest by itself make a system compliant?
No. Encrypting data at rest is a single protective measure, not a substitute for compliance. Compliance frameworks such as NIST SP 800-53, NIST SP 800-171, and DoD RMF implementations generally treat data-at-rest protection as one control among many, and satisfying it does not demonstrate that access controls, audit logging, key management, or continuous monitoring requirements are met. Compliance should not be equated with security more broadly; both must be addressed. Confirm the specific control requirements and how they are assessed against the current authoritative text applicable to your system.
Is data at rest the same thing as data in transit or data in use?
No. These are generally treated as distinct data states. Data at rest refers to information stored on media or in storage systems, data in transit refers to information moving across networks, and data in use refers to information being actively processed. Controls, and in many frameworks the applicable protection expectations, differ for each state. Do not assume that a control satisfying protection for data in transit also addresses data at rest, and verify how each state is scoped in the governing publication or agency tailoring that applies to you.
How do I identify which stored data must be protected as data at rest?
Begin by scoping the information your system stores and its sensitivity, such as whether it includes Controlled Unclassified Information (CUI), classified information under the NISPOM, or other categorized data. The applicable protection expectations often depend on the data type, the system's categorization, and the framework in scope, which may differ between federal civilian systems under FISMA, DoD systems under the RMF, and non-federal systems handling CUI. Confirm scoping decisions against the current authoritative guidance and any agency-specific tailoring, since these determinations drive which controls apply.
What role does encryption key management play in protecting data at rest?
Key management is generally integral to data-at-rest protection, because encryption provides limited assurance if keys are poorly generated, stored, or controlled. Frameworks commonly address key generation, storage, distribution, rotation, and destruction as related requirements rather than treating encryption in isolation. The specific expectations, including any requirements for validated cryptographic modules, vary by framework, impact level, and revision. Verify the applicable cryptographic and key management requirements against the current authoritative text before finalizing an implementation.
How should data-at-rest protections be reflected in system documentation and assessment?
Data-at-rest controls are typically documented in a system security plan or equivalent artifact and are subject to assessment as part of the authorization process. Keep in mind that assessment and authorization are distinct: an assessment evaluates whether controls are implemented and effective, while authorization is the decision to accept residual risk. Document how the protection is implemented, how it maps to the applicable control, and how it is evaluated. Confirm documentation and assessment expectations against the framework and revision that govern your system.
Are data-at-rest protections a one-time implementation or an ongoing obligation?
They are generally an ongoing obligation. An Authority to Operate (ATO) is time-bound and subject to continuous monitoring, so data-at-rest protections and their supporting elements, such as key management, are expected to be maintained and monitored over the system's lifecycle rather than validated once. Changes to the system, data types stored, or applicable requirements may trigger reassessment. Verify the continuous monitoring expectations that apply under your framework and any agency-specific interpretation.
Common misconceptions
Encrypting data at rest means the data is fully secured and compliance is achieved.
Encryption of data at rest is one control among many, and compliance is not the same as security. Data at rest protection must be combined with access controls, key management, media protection, and continuous monitoring. Additionally, encryption alone does not address data in transit or data in use, and the strength of protection depends on proper implementation and key handling.
Any encryption satisfies federal or DoD requirements for data at rest.
Federal and DoD requirements generally call for validated cryptography appropriate to the system's categorization, and requirements differ across federal civilian systems (FISMA), DoD systems (RMF), CUI environments (NIST SP 800-171), and classified systems. Practitioners must confirm the specific cryptographic and control requirements against the current authoritative text rather than assuming any encryption method suffices.
Data at rest only refers to data on local hard drives.
Data at rest encompasses all persistent storage, including removable media, backup media, databases, file shares, and cloud storage. Overlooking backups, removable media, or cloud repositories can leave significant portions of stored data unprotected.
Best practices
Inventory all locations where sensitive data is stored, including endpoints, servers, databases, removable media, backups, and cloud repositories, so that no persistent storage is left out of scope.
Apply cryptographic protection appropriate to the data's categorization and impact level, and verify cryptographic module and standard requirements against the current authoritative sources applicable to your environment.
Establish and document key management practices covering key generation, storage, rotation, and destruction, recognizing that weak key management undermines encryption.
Map data at rest protections to the applicable control set and revision, such as NIST SP 800-53 for federal systems or NIST SP 800-171 for CUI, and account for any agency-specific tailoring.
Extend protections consistently to backups and removable media, which are commonly overlooked forms of stored data.
Treat data at rest controls as part of continuous monitoring rather than a one-time configuration, and confirm that protections remain effective as systems, revisions, and requirements change.