What PR.DS-01 data at rest requires and why it is hard to evidence
PR.DS-01 asks that the confidentiality, integrity and availability of data at rest are protected. If you have been told to show coverage for this Subcategory, your job is to prove that stored data is protected in every place it sits, not just to state that encryption exists. NIST's CSF 2.0 Core, published as CSWP 29 on February 26, 2024, describes the outcome in general terms and leaves the choice of methods to you. Stored data includes databases, file stores, virtual machine disk images, container images, laptop and tablet disks, and removable media. An unprotected copy in any of these places can expose records, let an attacker alter them unnoticed, or leave them unavailable when the business needs them.
Evidence is usually the hard part. Encryption is often in place somewhere, but it is rarely documented end to end, rarely verified after the last change, and inconsistent across the estate. One database may use transparent encryption while a replica does not. Endpoints may have full disk encryption enforced on new laptops but not on older builds. Container images may be pulled from registries without signature checks, and removable media rules may exist in policy but not in configuration. Start by building an inventory of data stores and storage locations, then record for each one the mechanism, the key owner, and the check that proves it is active.
Note that CSF 2.0 is voluntary. NIST does not offer certifications or endorsements and has no plans for a conformity assessment program, so no external body issues a PR.DS-01 certificate. The outcome is judged through your own assessment, or through a customer's, auditor's or regulator's review of the evidence you present. Confirm with each reviewer which artifacts they accept, such as configuration exports, key management logs, scan results or signed-image records, and collect them on a schedule rather than during the review.
Which systems, media and teams fall under PR.DS-01
PR.DS-01 reaches further than a database checkbox. NIST's Implementation Examples name files, databases, virtual machine and container images, endpoints, software artifacts and removable media, and each one changes who does the work and what evidence an assessor will ask for. The cards below separate the asset types from the scoping decisions that decide whether the work is complete.
Files and file stores
Files on file servers, collaboration platforms and network shares are the most common data at rest in scope. NIST's Implementation Examples call for encrypting files and using hashes or digital signatures to show they have not changed. For each store, confirm whether encryption covers file contents only or also file names and folder structure, because some server-side encryption modes protect contents and leave metadata visible. Nextcloud's server-side encryption, for example, does not encrypt file names or folder structure, so that gap must be recorded and accepted or closed.
Databases and their storage
Databases hold the data most likely to be named in an assessment. Implementation Examples cover encrypting database content and applying signatures or hashes where they fit. Scope should include the database files on disk, transaction logs, temporary files and replicas, since each can hold the same records. Ask who manages the database encryption keys and whether they sit on the same host as the data, because a key stored beside the data offers little protection against a stolen disk.
Virtual machine and container images
Virtual machine disk images and container images are data at rest that teams often overlook because they look like infrastructure. NIST names both explicitly. Images can carry customer data, credentials and configuration secrets baked in during a build. Include the image registry, the build cache and any templates. Confirm that images are encrypted where they are stored and that the registry controls who can pull or push them.
Endpoints: laptops and tablets
Full disk encryption on laptops and tablets is the Implementation Example that small organizations most often need first, and NIST's Small Business Quick-Start Guide cites PR.DS-01 for it. Scope every device that stores organizational data, including personal devices enrolled for work email or file sync. Your evidence is an inventory showing each device's encryption status and a report of exceptions, not a statement that devices are encrypted.
Software artifacts and signature validation
NIST includes validating software signatures in PR.DS-01, which brings build outputs, packages, firmware and third-party installers into scope. The question is where the signing keys live and who can sign. Scope the signing workflow, the verification step before deployment, and the trust store that holds accepted publisher keys. A signature that nothing checks protects nothing, so record where verification runs and what happens when it fails.
Removable media and key ownership
Removable media such as USB drives and external disks are in scope because NIST's examples call for restricting and physically securing them. Decide whether media is allowed at all, and if it is, whether it must be encrypted. Key management is the decision that changes the most work. Confirm whether the organization or a service provider holds the encryption keys, who can rotate them, and whether backups and archives are covered by the same key process. Backups and archives count as data at rest, so their encryption and key custody belong in the same scope as production stores.
How an assessor tests PR.DS-01
This table compares what an assessor does for each area of PR.DS-01 Data at rest, the evidence they ask for, and the gaps they most often record. Read each row as a test the organization should be able to pass with records it can produce on request. The main takeaway is that configuration settings alone rarely satisfy an assessor; they want proof that the settings cover every system in scope.
| Test area | Test approach and evidence requested | Common findings |
|---|---|---|
| Encryption configuration of stored data | Assessor selects storage locations in scope (databases, file stores, backups, object storage) and checks encryption settings against the documented standard. Evidence: configuration exports, cloud provider encryption reports, and screenshots or command output with dates. | Unencrypted secondary volumes, snapshots or replicas that inherit no encryption setting, and file stores where only some folders are covered. |
| Key management and rotation | Assessor reviews where keys live, who can use or export them, and whether rotation happens on the documented schedule. Evidence: key inventory, access lists for key administrators, rotation logs and the key lifecycle procedure. | Keys stored beside the data they protect, shared administrator accounts for key stores, and no record of rotation after initial setup. |
| Full disk encryption on endpoints | Assessor samples laptops, workstations and mobile devices and checks encryption status against the asset inventory. Evidence: MDM or endpoint management reports, recovery key escrow records and exception approvals. | Devices missing from the inventory, devices enrolled but not reporting status, and recovery keys not escrowed centrally. |
| Signature and hash validation of software | Assessor checks that software and images are verified before installation or deployment, and that hash or signature failures block the action. Evidence: verification logs, signing policy, trusted key list and sample deployment records. | Packages installed without verification, signing keys with no owner, and verification steps that log failures but do not stop the deployment. |
| Removable media restrictions | Assessor reviews the policy, the technical controls that restrict USB storage, and the exception register. Evidence: device control settings, exception approvals with expiry dates, and records of media handling or destruction. | Unmanaged USB exceptions that never expire, approvals given verbally, and no record of who holds the exception. |
| Sampling of systems | Assessor selects a sample across production, non-production, cloud and on-premises systems, and tests each sample against the same criteria. Evidence: the population list used for sampling and the reason each sample was chosen. | Samples drawn only from systems the organization already knows are compliant, and no population list to show what was left out. |
| Change and exception handling | Assessor compares the configuration history with approved changes to see whether storage or encryption settings changed without review. Evidence: change tickets, configuration baselines and exception records with owners. | Encryption disabled during troubleshooting and not restored, and exceptions remaining open after the system was retired. |
How to implement PR.DS-01 in sequence
This sequence moves an organization from unknown storage to protected data at rest, with each step producing a record an assessor can check. The order matters because key decisions depend on knowing where sensitive data sits and which platforms hold it.
Inventory data stores and endpoints
The platform or security team lists every place where data rests: file storage, databases, virtual machine disk images, container images, backup targets, laptops, tablets, and removable media. Each entry records the owner, the platform, the location (cloud account, data center, or air-gapped network), and whether the store is managed by the organization or a third party. The step is complete when the inventory is reviewed against the asset records maintained under the Identify Function, and every store has a named owner.
Classify which stores hold sensitive data
The data owner and security lead label each store with the classification scheme the organization already uses, such as public, internal, confidential, or regulated personal or payment data. Classification drives which controls apply first, so stores with the most sensitive contents receive encryption and monitoring earlier. The output is a classification register linked to the inventory, approved by the data owner. Ask the auditor which classification evidence they expect, because some contracts and regulations define their own categories.
Choose encryption methods for each store
For each classified store, the architect selects the encryption approach that fits the platform, such as server-side encryption for file storage, database-level encryption, or encryption of virtual machine and container images. Document what each method protects and what it does not. For example, some file-storage encryption schemes protect file contents but leave file names and folder structure visible, and the register should say so. The step is complete when each store has a documented method and a test showing that a sample object is unreadable without the key.
Set key management and rotation
The security and platform teams decide where keys live, who can use them, how they are backed up, and how often they rotate. Keys should be separated from the data they protect and held in a dedicated secrets or key management service where possible. Open-source options such as OpenBao's transit secrets engine can encrypt and decrypt application data without storing it, and support versioned keys with rotation. The output is a key management standard, a key inventory, and a rotation test that proves old data remains readable after rotation.
Enable full disk encryption and removable media controls
Endpoint administrators turn on full disk encryption on laptops and tablets, and apply policies that restrict or physically secure removable media. Recovery keys for encrypted endpoints are stored under the same custody rules as other keys. The endpoint team produces a compliance report showing which devices are encrypted, which are not, and the exception approvals for each gap. The step is complete when the report is reviewed and every unencrypted device has a documented exception or is remediated.
Add signature and hash checks for software and images
Engineers configure validation of software signatures before installation and record hashes or digital signatures for files, database exports, virtual machine disk images, and container images. Build pipelines should refuse artifacts that fail verification. The output is a verification log for a sample of deployed artifacts and a written procedure for what happens when a check fails. Confirm with the platform vendor which signing and verification mechanisms each product supports before you commit to a design.
Monitor stored data for unexpected changes
The security operations team sets up file integrity monitoring that records a baseline of checksums and attributes for monitored files and directories, then alerts on creation, modification, or deletion. Wazuh's file integrity monitoring is one open-source option that runs on a schedule or in real time and records who changed a file and when. Backup verification jobs, such as Bareos verify jobs, can also compare files against cataloged attributes. The step is complete when a deliberate test change produces an alert that reaches the on-call queue, and the response is recorded.
Self-hosted options for encrypting and monitoring data at rest
Application data at rest is often encrypted inside the application, with keys held apart from the data they protect. OpenBao, a self-hosted secrets manager licensed under MPL-2.0, offers a transit secrets engine for this. Applications send plaintext to the engine and receive ciphertext back, so the application stores encrypted values without holding the key material itself. The same engine can sign and verify data and supports versioned encryption keys with key rotation, which lets the team re-encrypt data under a newer key version over time.
- Encrypt and decrypt on request: Applications call the engine to encrypt and decrypt values, so keys stay inside the engine.
- Sign and verify: The engine can sign data and verify signatures, which supports the signature language in PR.DS-01.
- Versioned keys and rotation: Key versions let older ciphertext remain readable while new writes use a newer key.
- Access control on the engine: Policies determine which identities may use which keys, so the engine itself becomes a control point that needs its own access review.
Confirm with your team that the engine's key storage, high availability and backup design meet your recovery targets, and that your auditor accepts the key custody model.
For files stored on a self-hosted collaboration platform, server-side encryption is a common option. Nextcloud, licensed under AGPL-3.0-only, encrypts file contents at rest on local and external storage, and the server keeps the keys. This protects file contents on disks and external storage mounts, but it has a stated limit: file names and folder structure are not encrypted. A reader of the storage layer can still see how the data is organized, even when the contents are unreadable.
- Content protection: File contents are encrypted on configured storage, including external mounts.
- Server-held keys: Because the server keeps the keys, the control protects against stolen storage media more than against a compromised server.
- Metadata exposure: File names and folder structure stay in clear text and must be handled through access control or naming standards.
- Operational steps: Enabling encryption and managing recovery keys are administrative tasks that should be documented and tested.
Confirm the key recovery procedure, which storage backends your deployment uses, and whether file names in your environment could reveal sensitive information.
Encryption protects confidentiality, but PR.DS-01 also concerns the integrity and availability of stored data. Integrity monitoring detects when protected files change in ways no authorized process should cause. Wazuh, licensed under GPL-2.0-only, records a baseline of checksums and attributes for monitored files and directories, then raises an alert when a user or process creates, modifies or deletes a monitored file. Alerts can run on a schedule or in real time and record how and when a file changed and who changed it. Bareos, licensed under AGPL-3.0-only, offers a complementary method: verify jobs compare files against attributes cataloged at backup time, which helps detect changes after an incident.
- Baselines and alerts: Wazuh compares current state against a recorded baseline of checksums and attributes.
- Real-time or scheduled checks: The team chooses the monitoring cadence for each directory.
- Change attribution: Alert details show the actor and time of a change, which supports investigation.
- Verify jobs: Bareos verify jobs compare stored files with cataloged attributes, supporting detection of unexpected change.
Confirm that monitored paths cover the data in scope, that alert routing reaches the security team, and that baselines are updated through an approved change process.
What evidence passes an assessment and what it costs to keep current
An assessor testing PR.DS-01 will want evidence that shows three things: the protection is configured, it covers the whole data estate, and it has operated over time. For the configuration layer, collect the encryption settings for each stored data store, such as the server-side encryption configuration for file storage, database encryption settings, and the encryption setup for virtual machine and container images. Pair these with a key inventory that names each key, its owner and purpose, and a rotation record showing when keys were rotated and who approved it. For the coverage layer, produce a disk encryption report for endpoints, a list of software signature validation policies, and the removable media policy with its exception log. For the operation layer, keep samples of integrity alerts and their investigation tickets, plus signature validation logs that show untrusted software was blocked or reviewed. Mark which evidence is generated automatically and which must be assembled by hand, because that split drives most of the recurring effort.
Setup is mostly one-time work: designing the key hierarchy, enabling encryption on each store, building the baseline for integrity monitoring and writing the removable media policy. Upkeep is recurring and grows with the environment. The main cost drivers are the size of the endpoint fleet, the number of data stores and images that must be enumerated, how often keys rotate, and how many exceptions the organization approves each cycle. Ask any implementation partner to quote these items separately: initial configuration, key management design, evidence automation, and the periodic review that refreshes the inventory and reconciles it against the asset list. Confirm with the auditor in advance which sample sizes and time periods they will test, because that determines how far back the evidence must go. Note that the organization owns the controls and the assessor issues any conclusion; the partner's role is to prepare systems and evidence.
Evidence artifacts that satisfy PR.DS-01
PR.DS-01 asks whether data at rest stays confidential, intact and available. Assessors rarely accept a policy statement alone, so they look for dated exports, records and alert histories that show the protections were configured and operating over the assessment period. The six artifacts below cover the main protection types named in the Implementation Examples.
Encryption configuration exports
Export the encryption settings for each storage system in scope, including file storage, databases and virtual machine disk images. Record which keys protect which data stores, whether encryption is enabled, and where the keys are held. Note what is not encrypted, such as file names or folder structure in some platforms, and document the compensating control. Re-export after every configuration change and keep dated copies so an assessor can see the state for the whole period.
Key management records
Keep a register of encryption keys with their owners, creation dates, rotation history and access grants. For a transit or secrets engine, export the key versions and rotation log, and show who approved each rotation. Assessors test whether keys are separated from the data they protect and whether retired keys are handled properly. Confirm with your platform vendor how key versions are retained and what happens to data encrypted under an old version.
Endpoint encryption compliance reports
Produce a report showing which laptops, tablets and workstations have full disk encryption active, with the date each status was last checked. List every exception with the device owner, the reason and the approval. Reports from your endpoint management tool should be exported on a fixed schedule, not only before an audit. Unencrypted devices that hold regulated data are the finding assessors most often raise, so reconcile this report against the asset inventory.
Software signature and hash validation records
Keep logs showing that software packages, container images and binaries were checked against published signatures or hashes before deployment. Include the signing key used, the result of each check and the step that blocked any failed artifact. Retain the records for the systems in scope and tie them to change tickets. This evidence supports the signature validation Implementation Example and shows that unverified code was not allowed into production.
Removable media policy and exception register
Hold a written removable media standard that states which devices are allowed, how they are encrypted, and where they may be used. Pair it with an exception register listing each approved use, the business reason, the expiry date and the physical storage controls for media. Assessors compare the register against device control logs to confirm that exceptions were approved and reviewed. Review the policy and register at a defined interval and record each review.
File integrity monitoring baselines and alert history
Store the baseline of checksums and attributes for monitored directories, then keep the alert history showing each created, modified or deleted file, the time, and the user or process responsible. Show how alerts were triaged and closed. Baselines should be re-approved after authorized changes so that alerts stay meaningful. Assessors use this record to test whether unauthorized changes to stored data are detected and investigated.
What meeting PR.DS-01 costs in money and effort
This table lists the cost components of meeting PR.DS-01 Data at rest, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to structure a written scope and quote, since no figures in this table are fixed prices.
| Cost component | One-time or recurring | What drives it up or down |
|---|---|---|
| Tooling or licenses | Recurring for commercial products, one-time for setup | Open-source encryption, integrity and key management tools remove most license spend, but support subscriptions and hosting remain. Confirm each component's license terms in writing. |
| Engineering time | One-time, with recurring changes | Scope of systems to encrypt, number of databases, virtual machine images and endpoints, and how much key management must be built. Standardized build images reduce effort. |
| Evidence upkeep | Recurring | Frequency of configuration reviews, integrity reports, key rotation records and removable media logs. Automated collection of evidence lowers the manual effort each cycle. |
| External testing or review | Recurring, usually per engagement | Depth of configuration review, whether encryption is tested in the environment or only documented, and how many systems are in scope. Ask for the testing approach in the quote. |
| Auditor sampling | Recurring, set by the assessment cycle | Number of systems and keys the auditor samples, and how cleanly evidence is organized. The organization pays the auditor, and the auditor decides the sample. |
Where organizations usually fall short on data at rest
The most common shortfall under PR.DS-01 is encryption applied to some data stores but not to the rest. Teams often encrypt the primary database and file share, then overlook backups, replicas, log archives, search indexes and staging copies that hold the same records. An assessor who asks for a list of every location holding regulated data and then checks the encryption setting on each one will usually find gaps. To close this, build a data store inventory that includes replicas and backup targets, record the encryption state of each, and treat any unencrypted copy as a finding with an owner and a date. For Nextcloud deployments, confirm whether server-side encryption is enabled and note that it does not encrypt file names or folder structure, so that limit must be documented in the risk record rather than assumed away.
A second frequent gap is key material stored on the same host as the data it protects. When encryption keys sit in a configuration file beside an encrypted volume, anyone who obtains that host can read the data, so the encryption adds little protection against host compromise. Closing this gap means moving key custody to a separate service with its own access controls, audit logging and key rotation. Transit-style services such as OpenBao can encrypt and decrypt application data without storing it locally and support versioned keys with rotation, which lets an organization show who held keys, when they changed and how old data remains readable. Confirm with the vendor how each product handles key storage, backup of key material and recovery if the key service is lost, because a key recovery failure can make the data unreadable.
Laptops and removable media create the third and fourth gaps. Organizations often assume full disk encryption is on for every endpoint without a check, so the first step is a report from the endpoint management system showing encryption status per device, with exceptions tracked to closure. For removable media, the gap is usually an unmanaged policy: USB storage is permitted, no one records which devices are allowed, and no one can say where copies of data went. The fix is to restrict removable media by policy, limit it to approved and physically secured devices, and log its use. Finally, many teams deploy file integrity monitoring, such as Wazuh, without documenting the baseline of checksums and attributes it should compare against. Without a recorded and approved baseline, alerts cannot be judged, and an assessor cannot confirm that monitored files are the expected versions. Document what is monitored, who approved the baseline, when it is refreshed after authorized change, and who reviews alerts.
Who does what for PR.DS-01: your team, a partner and the auditor
Your organization owns PR.DS-01. NIST CSF 2.0 is a voluntary framework and NIST does not certify anyone, so the accountability for protecting stored data sits with your leadership, security function and data owners. Internal staff decide which data classes need encryption, which key management model is acceptable, who may hold keys, how long retention applies and what risk is accepted when a control cannot be applied.
- Data classification and scope: Decide which systems, databases, file stores, backups and container or VM images hold data that requires protection at rest.
- Policy and key ownership: Approve the cryptographic standard, key custody model and rotation expectations, and name the people accountable for key access.
- Risk decisions: Document exceptions, such as legacy systems that cannot be encrypted, with an owner, a compensating control and a review date.
- Operations and evidence: Run the controls day to day, review alerts from integrity monitoring and keep records of changes.
- Governance sign-off: Confirm that the PR.DS-01 outcome is mapped to your risk register and reported to leadership.
Before engaging anyone, confirm internally which of these decisions you can delegate in writing and which must stay with a named executive.
An implementation partner such as DeployOpen prepares the systems and evidence that support PR.DS-01 inside your own infrastructure, whether that is your cloud accounts, data centers or air-gapped networks. The partner works to the scope and design your organization approves. It does not own the controls, set your risk appetite or sign off that the controls work.
- Encryption configuration: Configure server-side encryption, key handling and disk encryption for self-hosted platforms, for example enabling server-side encryption for Nextcloud file storage and documenting its limits, such as file names and folder structure remaining unencrypted.
- Key and signing services: Deploy and harden a transit secrets engine such as OpenBao so applications can encrypt, sign and verify data with versioned keys and rotation.
- Integrity monitoring: Set up file integrity monitoring with Wazuh or verify jobs in Bareos so changes to monitored files are recorded with who changed them and when.
- Evidence assembly: Produce configuration exports, baseline reports, change logs and runbooks that your team and the assessor can review.
- Documentation handover: Deliver the procedures your staff need to operate and retest the controls after the engagement ends.
Under a fixed-scope agreement, ask the partner to list every system in scope and every item it will not touch, and confirm who holds administrator credentials after handover.
Only an independent auditor, assessor or certification body can test PR.DS-01 and issue a report or attestation. NIST states that it does not offer certifications or endorsements of CSF implementations or services and has no plans for a conformity assessment program. Any claim that a CSF 2.0 Subcategory is certified should prompt a question about who issued it and under which engagement.
- Independent testing: The assessor samples systems, reviews configurations and interviews staff, and reaches its own conclusions.
- Evidence review: The assessor checks whether encryption, signature validation and removable media controls operate as documented over a period, not only at the time of setup.
- Report issuance: Only the assessor issues the report or statement of results, scoped to the assessment agreed with your organization.
- Independence limits: A partner that configured a control should not be the party that tests it for the same report. Discuss this with the assessor before work begins.
- Your own records: Your organization keeps the final evidence package and decides how it is shared with customers.
Ask the assessor, before engagement, which evidence it expects for PR.DS-01 and whether any partner work creates an independence conflict.
Most organizations outsource the technical build and the evidence collection for PR.DS-01, while keeping the decisions and the operating accountability in house. Outsourcing does not transfer responsibility for the outcome, and the costs of outsourced work depend on the scope you agree in writing.
- Commonly outsourced: Initial deployment of encryption and key services, integrity monitoring configuration, removable media control setup and documentation of how each control is evidenced.
- Commonly retained: Classification of data, approval of key custody, acceptance of residual risk and the choice of assessor.
- One-time versus recurring: Initial build is typically one-time, while key rotation reviews, monitoring tuning and evidence refreshes recur. Ask the partner to separate these in any quote.
- Cost drivers: The number of systems in scope, the number of key types, the state of existing configurations and the amount of legacy data affect effort.
- Quote questions: Ask which deliverables are included, who performs acceptance testing, and what happens if the assessor requests additional evidence.
In your quote, confirm in writing which items are the partner's deliverables and which remain your team's obligations.
Common questions about PR.DS-01 cost, effort and evidence
How long does PR.DS-01 implementation take in practice?
No fixed duration applies, because NIST does not set one for PR.DS-01 and the effort depends on the environment it protects. The main drivers are:
- The number and variety of data stores in scope, such as file shares, databases, virtual machine disk images and container images, since each needs its own encryption or integrity approach.
- Endpoint count and device diversity, because older hardware, mixed operating systems and unmanaged laptops add testing and rollout work for full disk encryption.
- Key management, which is often the longest step: deciding who holds keys, how they rotate and how recovery works without weakening the control.
Change windows, approval steps and the number of teams involved also shape the schedule. Ask for a written plan that lists phases, dependencies and the systems that need a maintenance window, and confirm that its assumptions are stated.
Can an in-house team implement PR.DS-01 without an outside partner?
Yes, an in-house team can implement PR.DS-01. NIST's Small Business Quick-Start Guide, SP 1300, treats full disk encryption on laptops and tablets as a practical step for small organizations. The real question is whether the team has the skills and capacity for every part of the work at once. File storage encryption, database encryption, key handling, software signature validation and removable media controls each need a different owner and a different test. Teams that already run endpoint management and storage platforms usually cover the basics quickly, while key management and evidence collection are where gaps tend to appear. A useful self-check is to list each Implementation Example for PR.DS-01 and name the person who will build, test and document it. Any item without a name is a signal to consider outside help for design, a fixed-scope implementation or an independent review before an assessment.
What does the organization need to provide for PR.DS-01 work?
Plan to provide access, decisions and records as well as time. The organization owns its controls, so it must name a control owner for data at rest, set the encryption policy and approve key custody arrangements. Engineers need administrative access to storage platforms, hypervisors, container registries, endpoint management and any backup or logging systems that will be configured. The team should supply an inventory of data stores and device classes, because the work cannot start until it knows where data sits. Change approval, test environments and maintenance windows must be agreed in advance. For removable media, the organization must decide which device types are allowed and who may approve exceptions. Finally, confirm how the work will be documented. Evidence collected during the build is far easier to use than evidence reconstructed later for an assessor.
Does NIST certify that our organization meets PR.DS-01?
No. NIST does not certify organizations, products or services against the Cybersecurity Framework, and it has no plans for a conformity assessment program. Its CSF FAQs state that NIST does not offer certifications or endorsements of CSF-related products, implementations or services. An organization that says it meets PR.DS-01 is making its own statement, which an internal review or an independent assessor can test. When a customer or regulator asks for proof, the usual route is an independent assessment whose report comes from the assessor. Be cautious with any vendor or consultant who offers a NIST certificate for CSF alignment. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue audit reports, attestations or certifications. Only the independent assessor can make that determination.
What evidence does an assessor expect for PR.DS-01 data at rest?
An assessor expects evidence that the encryption, integrity and media controls exist, are configured as documented and keep operating over time. Useful artifacts include:
- A written data-at-rest standard and a register of encrypted stores, with algorithms and key owners recorded.
- Configuration exports showing encryption enabled on file storage, databases, disk images and container images.
- Full disk encryption status reports from device management, with exceptions and their approvals.
- Records of software signature validation during deployment, plus the removable media policy, device control settings and logs of blocked or approved events.
File integrity monitoring shows detection. Wazuh's file integrity monitoring documentation describes baselines of checksums and attributes with alerts on change. Key rotation records and restore tests show the controls persist. Map each artifact to the SP 800-53 controls that the CSF 2.0 Reference Tool lists for PR.DS-01, so every item traces back to a control.
How should we request a quote for PR.DS-01 work?
Start with a written scope, because a quote is only as precise as the scope behind it. A useful request lists the systems and data stores in scope, the endpoint count and operating systems, the storage and hypervisor platforms, the tools to be deployed or integrated, and the documentation, testing and handover deliverables. Cost components usually include planning and design, configuration, testing, documentation, knowledge transfer and any training. Some costs are one-time, such as the initial build, while others recur, such as key rotation support, monitoring tuning and evidence collection before each assessment, which a retainer may cover. Ask the provider to state its assumptions, exclusions, the client's responsibilities and its change-control process. DeployOpen plans most engagements as fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. It does not publish a price list, so a quote follows from that written scope.
Are the open-source tools for PR.DS-01 free to deploy?
The software is free to obtain under its license, but deploying and running it has costs. Nextcloud is licensed under AGPL-3.0-only, OpenBao under MPL-2.0, Wazuh under GPL-2.0-only and Bareos under AGPL-3.0-only. Each license carries obligations that legal and procurement teams should review against how the software is used and modified. Beyond licensing, the costs include infrastructure, key management hardware or services where needed, staff time to operate and patch the platforms, and support. Decide whether the organization will run the platform itself, buy a retainer for upgrades and support, or combine both. Check feature limits too. For example, Nextcloud's encryption configuration documentation describes server-side encryption that protects file contents at rest but does not encrypt file names or folder structure, so the organization must decide how to handle that gap. Confirm each capability in vendor documentation before relying on it.
How DeployOpen scopes and prepares PR.DS-01 evidence
The sequence below turns PR.DS-01 into a written scope, a set of protected data stores and endpoints, and a body of evidence that the client's own assessor can test. The client owns the controls throughout, and DeployOpen prepares the systems and evidence without issuing any audit report or certification.
Agree the written scope of data stores and endpoints
DeployOpen and the client list the data stores in scope, including file storage, databases, virtual machine disk images, container images, backup repositories and key stores, along with the laptops, tablets and other endpoints and the removable media those endpoints use. The client's data owners confirm which data is sensitive and which Subcategories and outcomes apply. The step closes with a signed scope document that names each asset, its owner and the PR.DS-01 Implementation Examples it must satisfy, so that nothing is protected by assumption.
Confirm the client's control ownership and assessor requirements
Before any build work starts, the client assigns an accountable owner for each PR.DS-01 control and confirms with its independent assessor, auditor or customer which framework and evidence format it expects. DeployOpen records these decisions alongside the scope so that the client can show who decided what. The step is complete when the control owners and the assessor's evidence expectations are written into the scope document.
Design encryption, key management and integrity baselines
DeployOpen proposes the design for encryption at rest, key custody, integrity checking and endpoint encryption, based on the scope and the client's infrastructure. Where the design uses open-source platforms, such as Nextcloud server-side encryption, OpenBao for transit encryption and signing, or Wazuh file integrity monitoring, the design states which keys are held where, who can rotate them and which files are monitored. The client reviews and approves the design in writing before deployment begins.
Deploy the platforms inside the client environment
DeployOpen installs and configures the approved self-hosted platforms in the client's own cloud accounts, data centers or air-gapped networks. Work covers encryption settings, key stores, monitoring baselines, full disk encryption policies for endpoints and removable media restrictions. The client keeps administrative control of its keys and infrastructure. The step closes when each in-scope asset is tested against the design and the test results are recorded in the change log.
Validate encryption, signatures and integrity monitoring
DeployOpen runs documented checks that confirm data at rest is encrypted, that signatures and hashes validate, that integrity monitoring raises alerts on unauthorized changes, and that verify jobs compare files against cataloged attributes. Results are recorded with the tool version, configuration and the person who ran each check. The step is complete when every check either passes or has an agreed remediation with an owner.
Assemble the evidence package for the client's assessor
DeployOpen compiles the configuration exports, key management records, monitoring baselines, validation results, endpoint encryption reports and removable media rules into an evidence package mapped to the PR.DS-01 Subcategory and the client's chosen framework. The client reviews the package and gives it to its own assessor. DeployOpen does not interpret the package as an opinion on compliance. The step closes when the client confirms the package is complete and traceable to each in-scope asset.
Document operating procedures and hand over to the client
DeployOpen writes the runbooks the client's staff need to operate the controls, including key rotation, alert handling, endpoint encryption enrollment and removable media exceptions. Training covers the people who will run them. The step is complete when the client's named operators have accepted the handover in writing and know where the evidence is stored.
Decide whether to add a retainer for upkeep
The client chooses between running the controls internally and adding a retainer for ongoing support, upgrades and continuous testing. Retainers are priced from the written scope and cover patching, configuration drift checks and evidence refreshes. The client should confirm in writing which tasks the retainer includes and how often evidence is refreshed. The step closes when the client has either accepted an ongoing support agreement or confirmed that its own team will maintain the controls.
