PR.DS-10 data in use: what the requirement asks for and why it is hard
If you must show that data in use is protected under NIST CSF 2.0, the outcome you are accountable for is that the confidentiality, integrity and availability of data while it is processed are protected. NIST's two Implementation Examples for PR.DS-10 describe the two practical halves of that outcome: removing confidential data from processors and memory once it is no longer needed, and isolating data in use from other users and processes on the same platform. PR.DS-10 is a Subcategory of the Data Security (PR.DS) Category in the PROTECT Function, and it absorbs part or all of CSF 1.1 PR.DS-5, so teams that mapped PR.DS-5 under version 1.1 should check which of their existing evidence still applies.
The risk is easy to describe and hard to prove. Sensitive values can persist in process memory, swap or dump files, crash logs and cached buffers after a task ends, and a later process or administrator may read them. On a shared host, containers, virtual machines or multi-tenant services can expose data to co-resident workloads through misconfigured privileges, shared kernels or debugging interfaces. Unlike data at rest or in transit, data in use rarely leaves a clear artifact, so an assessor cannot simply inspect a file or a network capture and move on. Expect to rely on configuration baselines, process isolation settings and tests that show residue is not recoverable.
Before you plan any work, confirm with your platform owners which systems process confidential data in memory, which of them run on shared hosts, and what the vendor documents about memory handling and tenant isolation for each product. Ask for the Implementation Examples text in the NIST CSF 2.0 Core and check how your own controls map to the informative references, which list standards such as SP 800-53 controls for this Subcategory. Those mappings are a starting point for your evidence plan, not proof that a control works in your environment.
Which systems, data and teams fall under PR.DS-10
PR.DS-10 applies wherever confidential data is processed, not only where it is stored or transmitted. Scoping starts by listing the applications, platforms and teams that touch that data in memory, then extending the boundary to hypervisors, containers and third parties that share the same compute.
Applications that process confidential data
Start with the business applications that decrypt, parse, compute on or display confidential records, including analytics jobs, reporting services and internal tools. For each one, record which data classes it handles while running and where intermediate results land. An application that encrypts data at rest but decrypts whole datasets into memory for every query is in scope for the in-use outcome. Ask each application owner to confirm which fields are loaded in plain form and for how long.
Hosts, hypervisors and containers
Physical hosts, virtual machines, hypervisors and container nodes all hold data in memory and share processors with other workloads. Include the hosts that run in-scope applications, the hypervisor management plane and any shared container clusters. Confirm which workloads can be co-scheduled on the same node and whether the platform isolates memory between tenants or projects. A single shared node can bring unrelated systems into scope.
Shared platforms and multi-tenant services
Shared databases, message queues, caches and identity services often hold confidential data from several business units at once. Map which tenants, projects or namespaces share the same runtime and which administrators can inspect process memory or core dumps. The question for PR.DS-10 is whether one user or process can read another's data in memory. Document the isolation mechanism for each shared service and the people who can change it.
Teams that own memory and tenancy
Responsibility for in-use protection usually falls between platform engineering, application development and security operations. Name the team that sets memory cleanup behavior, the team that configures tenancy and isolation, and the team that reviews exceptions. Without named owners, the assessor will find controls that exist on paper but no one who can show how they are operated. Record these roles in the asset and responsibility matrix.
Cloud-hosted and third-party components
Managed databases, hosted AI services, SaaS integrations and cloud key management services may process confidential data outside your direct control. Ask each provider how it isolates customer workloads, clears memory after use and handles crash dumps, and record the answers in the supplier file. Where the provider cannot give a clear answer, note the residual risk and the compensating control you apply. Confirm the terms with the provider rather than assuming them.
Security tooling that touches data
Monitoring agents, backup agents, debuggers, APM tools and vulnerability scanners often read process memory or payloads. Each one can extend the in-scope boundary because it sees confidential data in use. List every agent on in-scope hosts, the data it can access and who can change its configuration. Restrict agents that do not need payload access, and confirm that logging pipelines do not capture secrets or personal data from memory.
How data-in-use protection works across the stack
The application is the first place where confidential data sits in memory, so it is also the first place where clearing and scoping decisions get made. Developers decide how long a decrypted value lives in a variable, whether it is written to logs or caches, and which service or user context may request it. NIST's Implementation Examples for PR.DS-10 describe removing confidential data from processors and memory once it is no longer needed, and that expectation starts in code rather than in infrastructure settings. Application teams should map where sensitive fields are decrypted, how long they remain in memory, and which components receive them.
- Scope of decrypted values: Decrypt only in the function that needs the plaintext, and pass references or tokens between services where the design allows it.
- Lifetime in memory: Release or overwrite secrets and personal data when the operation completes, and avoid long-lived caches that hold plaintext.
- Logging and debugging: Keep confidential values out of logs, crash dumps and error messages.
- Authorization checks: Confirm the calling identity before any processing step touches protected data.
- Dependency behavior: Review libraries and frameworks for how they handle buffers, serialization and caching.
Ask the development team for a data flow diagram that marks every point where plaintext exists in memory, and confirm that each point has a documented release or expiry behavior.
The operating system and hypervisor control which processes can read a given memory region, how memory is reused between tasks, and how virtual machines share physical hardware. Memory left behind by one process can be read by the next process that receives the same pages, so the platform team must confirm that memory is zeroed or otherwise cleared before reuse and that swap, core dumps and hibernation files do not capture sensitive pages in a readable form. This layer is where the isolation controls described in the topic actually take effect for process and virtual machine separation.
- Process isolation: Confirm that users and services run under separate accounts with no shared memory unless the design requires it.
- Memory reuse: Verify that the platform clears memory before handing pages to another workload.
- Swap and dumps: Encrypt swap, restrict core dump locations and disable dumps for sensitive services where feasible.
- Hypervisor separation: Check that virtual machines on one host cannot read another guest's memory, and document the controls that enforce this.
- Kernel and hypervisor patching: Track versions and patch levels, since isolation depends on the integrity of these components.
Ask the platform team to show the configuration for swap, core dumps and memory handling on each host class, and to name the hypervisor version in use.
Shared platforms such as container clusters, multi-tenant services and shared databases place several users or departments on the same infrastructure. Isolation at this layer means that one tenant's workloads cannot reach another tenant's data in memory, storage or network paths. The informative references for PR.DS-10 point to access control, separation and boundary protection, so the platform owner should map which tenants share hosts, which namespaces or projects are separated, and which network paths are open between them.
- Tenant boundaries: Define which workloads may share a node and which must run on dedicated hosts.
- Namespace and project separation: Use separate namespaces, projects or accounts for distinct data classifications, with role-based access limits.
- Network segmentation: Restrict east-west traffic so that only required services can reach protected workloads.
- Administrative access: Limit who can inspect running processes, attach debuggers or take memory snapshots on shared hosts.
- Monitoring of access: Record administrative sessions and access to protected workloads so that misuse can be investigated.
Ask the platform owner for a tenant map that lists each shared host or cluster, its tenants and its isolation mechanism, and confirm who holds privileges that can read memory.
Key-based encryption of processed data protects information when it is stored or passed between components, but the keys themselves become a high-value target. Where a platform encrypts or decrypts application data on request, the key management service must control who can use each key, how keys rotate and whether applications can receive raw key material. For PR.DS-10, the key layer supports the outcome by limiting which processes can turn ciphertext back into plaintext and by making key use auditable. The distinction between encrypting stored data (covered in PR.DS-01) and encrypting data during processing is worth drawing clearly for the team.
- Transit-style encryption: OpenBao's transit secrets engine encrypts and decrypts application data without storing the plaintext in the engine, so applications can process data without holding long-term keys.
- Versioned keys and rotation: The same engine supports versioned encryption keys and key rotation, which lets teams replace keys without rewriting every record at once.
- Access policies: Restrict which identities may call encrypt and decrypt operations for each key.
- Server-side encryption limits: Nextcloud's server-side encryption protects file contents at rest with keys kept on the server, but it does not encrypt file names or folder structure, so teams should not assume it hides metadata.
- Key audit: Log key use so that unusual decryption volume or unexpected callers can be detected.
Ask the security team to confirm which keys protect data in use, who administers them, and how a key rotation would affect running applications.
How an assessor tests PR.DS-10
This table sets out the test approach, the evidence an assessor typically requests and the findings that come up most often for PR.DS-10 Data in use. Read each row as one part of a test, not a standalone pass or fail. Assessors choose their own procedures, so confirm the approach with your assessor before fieldwork begins.
| Test activity | What the assessor examines | Evidence requested | Common findings |
|---|---|---|---|
| Interviews on data handling design | Where confidential data is processed, which teams handle it, and how the design limits its exposure in memory and on processors | Data flow diagrams, processing inventories, design notes for sensitive workloads | Design relies on informal practice with no written statement of how data in use is protected |
| Configuration review of isolation controls | Whether processes, tenants and users on shared platforms are separated, and how access to running workloads is restricted | Hypervisor or container isolation settings, access control lists, workload placement rules | Shared hosts run confidential and non-confidential workloads together with no documented separation |
| Configuration review of memory and processor handling | Whether memory is cleared or protected once a process no longer needs confidential data, including crash and dump handling | Runtime settings, memory protection options, core dump and swap configuration, cache and temporary file handling | Core dumps, swap files or temporary files retain confidential data after processing ends |
| Sampling of processing components | A selection of applications, services and hosts that process confidential data, checked against the documented design | Build and deployment records, system inventories, configuration exports for the sampled components | Sampled components differ from the documented design, or new components are not in the inventory |
| Review of residual data clearing tests | Whether the organization has tested that data is removed after processing and that the tests are repeatable | Test plans, test results, dated logs of clearing runs, remediation records | Tests cover only one component, or results are not retained or reviewed |
| Review of access to running workloads | Who can read memory, attach to processes or inspect live data, and whether that access is logged and reviewed | Privileged access lists, session logs, approval records for debugging access to production | Administrators can attach to production processes with no approval or logging |
| Review of encryption key handling during processing | Whether keys used to decrypt data for processing are held apart from the data and rotated under a documented procedure | Key management policy, key rotation records, key access logs | Keys are stored alongside the data they protect or rotation has never been performed |
| Confirm approach with the assessor | The assessor chooses the sample size, depth and methods for each activity | Written agreement on scope, sampling method and evidence list before testing starts | Scope and sample are not agreed in writing, which leads to late requests and rework |
Implementing PR.DS-10 step by step
This sequence moves an organization from knowing which confidential data gets processed to proving that the data is cleared from memory and processors when no longer needed and kept isolated from other users and processes. Each step produces a record that an assessor or internal reviewer can check.
Identify confidential data in processing
Start with the workloads that handle confidential data while they run: application services, analytics jobs, batch processing, administrative consoles and any AI or inference pipelines. The data owner and the platform owner confirm which datasets are in scope, using the classifications already defined under the organization's data security policy. The output is a register of processing workloads, the data classes each one touches and the named owner for each. Done means every in-scope workload has an owner and a classification, and the list has been signed off.
Map where data sits in memory and processors
For each workload in the register, the platform engineering team traces where the data appears while it is processed: application memory, caches, message queues, temporary files, swap space, GPU or accelerator memory, and logs or crash dumps. Many gaps appear here, because data often persists in places nobody designed for it. The output is a data-in-use flow diagram per workload and a short list of locations that retain data longer than the processing task needs. Done means each location is either justified or added to the remediation backlog.
Define clearing and isolation rules
Write the rules that govern the data identified in the first two steps. The security architect and the data owner agree on when confidential data must be released from memory or a processor, such as at the end of a transaction or session, and which workloads must run isolated from others on shared infrastructure. The rules should name the systems they apply to and the exceptions, with an approver for each exception. The output is a short standard approved by the owner of the risk decision. Done means every workload in the register maps to at least one rule.
Configure platform isolation and memory handling
The platform team implements the rules in the self-hosted platform: separate namespaces, tenants or virtual machines for sensitive workloads, restricted access to shared caches, limits on temporary storage and configuration that prevents sensitive values from reaching logs. Where the platform supports memory encryption or confidential computing features, confirm the hardware and hypervisor support before relying on it. The output is a configuration baseline stored under version control. Done means the baseline has been applied to a test environment and each rule is visible in a configuration review.
Add key management for data processed by services
Where a service must encrypt or decrypt data as part of processing, keys should stay out of the application code and be managed centrally with access logged. OpenBao's transit secrets engine can perform encryption and decryption on behalf of an application without storing the application data, and it supports versioned keys with rotation. Confirm the key rotation schedule with the organization's cryptography owner, and check the platform's own documentation for supported algorithms and deployment modes. The output is a key inventory, an access policy per service and a tested rotation procedure. Done means the services in scope fetch keys only through the managed path and a rotation has been performed in test.
Test isolation and clearing, then document the evidence
The security team tests each rule against the running configuration. Tests include checking that a session's data is absent from memory and temporary storage after completion, attempting access to another tenant's data from a shared component, and confirming that logs and crash dumps contain no confidential values. Record the test steps, results, defects and retests. Map each rule to the evidence it produces so an assessor can follow the chain from requirement to proof. The output is a test report, a control record for PR.DS-10 and a dated review date. Done means every failed test has a tracked fix and the owner has accepted the residual risk in writing.
Evidence that satisfies PR.DS-10 and how to keep it current
An assessor testing PR.DS-10 looks for a written rule for handling data in use, configuration records that show isolation is enforced, and test results that show confidential data is cleared when it is no longer needed. The cards below cover each artifact, what to check in it, and how to refresh it between assessments so it reflects the systems as they run today.
Data-handling standard for data in use
This is the written rule that tells engineers which data may be loaded into memory, how long it may stay there, and when it must be cleared. Name the data classes it covers, such as cardholder data, health records, or key material, and state the trigger for clearing, for example when a processing job completes or a session ends. Check that the standard names an owner and that developers and platform teams can point to the section that governs their code. Review it when new processing workloads are added.
Isolation configuration exports
Export the configuration that separates workloads on shared hosts, including container runtime settings, hypervisor or VM partitioning, memory limits, and process user separation. Store exports on a dated schedule so an assessor can compare the configuration in force at two points in time. Check for drift: a hand-edited setting that differs from the baseline is a finding in waiting. Keep the export tied to the change record that approved it.
Tenancy and process separation records
Maintain a current map of which tenants, applications, and service accounts share a platform, and which are kept apart. For each shared resource, record the control that prevents one process from reading another's memory or temporary files. Review the map after every onboarding or architecture change, because isolation decisions made for one release are often silently undone by the next. An assessor will ask for this map before reading any configuration.
Key management policy and rotation logs
Data in use is often protected by keys held in a key service, so the policy for creating, storing, and rotating those keys is direct evidence. OpenBao's transit secrets engine can encrypt and decrypt application data without storing it and supports versioned keys with rotation, so the rotation log can come from the service itself. Confirm that the audit log captures each rotation, the actor, and the key version in use. Ask the platform vendor which audit events are emitted by default and which need enabling.
Memory clearing test results
Test results are the strongest evidence that clearing works in practice, not just on paper. Run a documented test that loads a known confidential value into a process, triggers the end of the processing step, and then checks whether the value remains in memory, swap, or a core dump. Record the test method, the build tested, the date, and the result, and keep failed runs as well as passing ones. Repeat the test after each change to the runtime or language libraries.
Refreshing evidence between assessments
Evidence goes stale faster than policy documents do. Assign an owner to each artifact in this set, set a review cadence that matches how often the underlying system changes, and tie exports and test runs to the change management process so that each release produces new records automatically. Before an assessment, sample a few artifacts and confirm that the dates, versions, and configurations match the running environment. Confirm with your assessor which review intervals they expect, since NIST does not set them for CSF 2.0.
What meeting PR.DS-10 costs in money and effort
This table lists the cost components of protecting data in use under PR.DS-10, who is paid for each, and whether it is one-time or recurring. Read it to see where open-source tooling removes license spend and where engineering and evidence effort remain. No prices or durations are stated because none are supplied for this topic, so request figures from a written scope.
| Cost component | Who is paid or who carries it | One-time or recurring, and what drives it |
|---|---|---|
| Tooling or licenses | Software vendor or open-source project; no license fee for open-source components such as OpenBao or Nextcloud, but support contracts may apply | Commercial licenses are recurring. Open-source components remove license spend but still need hosting and patching. Confirm each vendor's license terms before deployment. |
| Engineering time for isolation and clearing | Implementation partner or internal platform engineers | Mostly one-time for design and configuration, then recurring for changes. Drivers include the number of platforms, workloads sharing hosts, and how memory clearing is handled by each runtime. |
| Key management and encryption design | Internal security engineers or implementation partner | One-time build, then recurring key rotation and access reviews. Versioned keys and rotation schedules set the ongoing effort. |
| Evidence upkeep | Internal compliance or platform team | Recurring. Configuration exports, access logs and isolation test results must be refreshed on each assessment cycle. Automating collection lowers this cost. |
| External testing or review | Independent security testers or assessors, paid per engagement | Recurring per engagement. Scope depends on how many platforms handle confidential data in use and whether memory or isolation testing is included. Ask for the scope in writing. |
| Auditor sampling | The organization pays the independent auditor or assessor under its own engagement | Recurring per assessment. Auditors sample evidence, so consistent, well-labeled records reduce the time and questions in each cycle. Confirm fees with the auditor directly. |
| Cost-reduction lever: self-hosted open source | Organization hosts in its own infrastructure | Removes license spend for covered components but shifts cost to hosting, patching and staff time. Compare total effort, not license lines alone. |
Self-hosted open-source tools that support PR.DS-10 evidence
Does Nextcloud server-side encryption satisfy PR.DS-10?
No, not by itself. Nextcloud server-side encryption protects file contents at rest on local and external storage, with keys kept on the server, but it does not encrypt file names or folder structure. PR.DS-10 concerns data while it is being processed, so encryption at rest addresses a different Subcategory (see PR.DS-01). Engineers can still use it as one part of a wider design, for example by documenting where decrypted content exists in server memory during a session and what limits other users and processes on the same host. Confirm the encryption mode, key handling and any end-to-end options against the admin manual for the version you run, and confirm how the platform behaves during active file access before you describe it as data-in-use protection.
What does the OpenBao transit engine do for data in use?
The OpenBao transit secrets engine encrypts and decrypts application data without storing that data in OpenBao, and it can also sign and verify data. Because the application sends data in and receives the result back, the sensitive material never has to rest in the secrets store. It supports versioned encryption keys with key rotation, so you can show how keys change over time. This helps with the confidentiality side of PR.DS-10, but the outcome still depends on the application. If the application holds plaintext in memory, caches it or writes it to logs, the transit engine does not remove that exposure. Map each service that calls the engine and record where plaintext lives during processing.
Which license terms should we review before deploying these tools?
Nextcloud is licensed under AGPL-3.0-only, and OpenBao is licensed under MPL-2.0. These are different copyleft licenses with different obligations. AGPL-3.0 has network-use provisions that can matter if you modify the server and offer it to users over a network, while MPL-2.0 is file-level copyleft that applies to modified covered files. Your legal team should confirm how each license applies to your planned modifications, integrations and distribution, including any custom code that links to these platforms. Record the license review as part of your evidence file so an assessor can see that the decision was made deliberately.
How should we decide whether these tools fit our processing design?
Start from the data flow, not the tool. List each system that handles the sensitive data, then mark where it is stored, transmitted and processed in clear form. For each step, ask whether a tool removes the plaintext, limits who or what can read it, or only protects it while idle. Nextcloud addresses data at rest on file storage, and OpenBao addresses key management and encryption as a service for application data. Neither replaces memory handling, process isolation or sound application design. Confirm the design with your architects and, where the workload is regulated, with your assessor before you rely on either tool as evidence.
What evidence can OpenBao and Nextcloud produce for an assessor?
Each tool can produce configuration and operational records that support the design story. For Nextcloud, these can include the encryption configuration, the list of storage backends in scope and records of key handling. For OpenBao, they can include the transit engine mount configuration, the key versions and rotation history, and audit logs of encrypt and decrypt requests. These records show what the platform does. They do not prove that applications clear memory or isolate processes, so pair them with application design documents, code review results and tests that confirm plaintext is not persisted. Keep the records together, dated and tied to a named owner.
Can our own team operate these tools, or do we need outside help?
Your team can operate both tools if it has the skills to manage Linux servers, key material, backups and upgrades. The cost is mostly staff time, plus the infrastructure you run the platforms on. Outside help is usually considered for planning the processing design, hardening the deployment, integrating the transit engine with applications, and preparing evidence for an assessment. DeployOpen plans, implements, customizes, hardens and documents self-hosted open-source platforms inside your own infrastructure, under a written scope agreed before work starts. DeployOpen does not issue audit reports or certifications. An independent assessor performs that role. Ask any provider to state which parts of the work they would hand over to your staff.
What drives the cost of running these tools for PR.DS-10?
Costs fall into a few groups: the software itself, which is free to download under these licenses, the infrastructure that hosts it, the staff time to design, deploy and operate it, and the assessment work that follows. One-time costs include design, integration and initial evidence preparation. Recurring costs include hosting, key management operations, upgrades, monitoring and periodic review. The main drivers are the number of applications that call the transit engine, the volume and sensitivity of stored files, how many environments need separate controls, and how often the design changes. Ask any quote to separate one-time and recurring items, name the environments covered, and state which evidence the provider will prepare and which your staff must maintain.
How do we confirm these tools meet our requirements before rollout?
Confirm the capability in the official documentation for the exact version you plan to deploy, then test it in a non-production environment. For Nextcloud, read the encryption configuration guide and verify what is and is not encrypted, including file names and folder structure. For OpenBao, read the transit secrets engine documentation and test encrypt, decrypt, key rotation and audit logging with your own application patterns. Document each test result, the version tested and the person who approved it. Re-run the checks after upgrades, because encryption behavior and configuration keys can change between releases.
Who owns PR.DS-10: your team, a partner and the auditor
Your organization owns PR.DS-10. That means you decide which systems process confidential data, what "no longer needed" means for each data type, how isolation between tenants, users and processes is designed, and who is accountable when a control fails. NIST CSF 2.0 is a voluntary framework with no certification, so the outcome is whatever your own risk decisions and documented practice say it is. Internal staff keep the knowledge that a partner cannot replace: business context, data classifications, and the owners of each application.
- Scope decisions: Name the systems, data stores and workloads that handle confidential data in use, and keep that list current as platforms change.
- Policy and standards: Set the rules for clearing memory, sanitizing processing buffers and separating workloads, and approve exceptions in writing.
- Accountable owners: Assign a named owner for each platform who answers for PR.DS-10 evidence.
- Day-to-day operation: Run access reviews, review isolation settings after upgrades, and act on monitoring alerts.
- Evidence custody: Retain configuration records, key-management logs and review sign-offs in a location your auditor can reach.
Before engaging anyone, check that your own owners can explain how each in-scope platform keeps confidential data out of shared memory and other tenants' reach.
An implementation partner helps you build and document the systems that deliver PR.DS-10 outcomes. DeployOpen, for example, plans, implements, hardens and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and prepares the evidence an assessor will ask for. The partner does not own the control, does not decide your risk tolerance, and does not issue a report or certificate. Most engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
- Architecture and hardening: Configure encryption, key handling, workload isolation and secure deletion for the platforms in scope.
- Evidence preparation: Produce configuration baselines, screenshots, logs and runbooks that show how each setting works.
- Testing support: Run security testing against the built environment and document findings and fixes.
- Documentation handover: Deliver procedures your staff can operate without the partner present.
- Ongoing support: Upgrade and monitor platforms under a retainer if you want continued help after go-live.
When you request a quote, ask the partner to list each deliverable, who signs off on it, and which evidence items remain your responsibility.
An independent auditor, assessor or certification body tests your PR.DS-10 controls and issues the report or certificate. Independence is the point of the exercise: the person testing your environment must not have designed, configured or operated it in a way that makes them judge their own work. NIST does not offer certifications or endorsements for CSF implementations, so any formal assurance you hear about comes from a body outside NIST, and the scope of that assurance depends on the engagement you contract for.
- Testing: The assessor samples configurations, observes operation and reviews records against your stated scope.
- Reporting: Only the assessor issues the findings, opinion or certificate.
- Independence line: Designing the isolation controls or writing the policy you are being tested against is a conflict to resolve before the assessment starts.
- Scope agreement: The assessor confirms in writing which systems and data flows the assessment covers.
- Evidence requests: Expect requests for logs, change records and access reviews over a defined period.
Ask your assessor which evidence formats they accept and whether your implementation partner may be present during fieldwork.
Common gaps in PR.DS-10 and how to close them
Most PR.DS-10 gaps are not missing technology. They are undocumented decisions: where confidential data is processed, whether memory is actually cleared, whether tenants on shared hosts are isolated, and whether keys are ever rotated. Each card below names one gap and the check that shows whether it is closed.
No defined processing locations
Confidential data often ends up in analytics jobs, caches, debugging sessions or developer workstations that nobody listed as places where data is processed. PR.DS-10 cannot be applied to locations the organization has not named. Close the gap by building a register of the hosts, containers, services and batch jobs that handle confidential data, with an owner for each entry. Check the register against data flow maps and cloud account inventories, then review it whenever a new workload is deployed.
Unverified memory clearing
Many applications assume that memory holding decrypted records or secrets is cleared when a process ends, but garbage collectors, swap files and crash dumps can keep copies longer than expected. The first PR.DS-10 Implementation Example addresses removing confidential data from memory and processors once it is no longer needed. Test this on your own stack: trigger a controlled process exit, inspect swap and core dump settings, and record the results as evidence. Ask each application owner to state how sensitive values are released.
Shared hosts without isolation evidence
Virtual machines, container nodes and shared database servers can place data from different users or tenants on the same platform. The second Implementation Example for PR.DS-10 asks that data in use be protected from other users and processes on that platform. Teams often assume the hypervisor or orchestrator provides this without checking. Collect the isolation configuration, such as tenant separation settings, namespace and node policies and access rules, and keep it with the change records that show it is still in force.
Keys not rotated
Encryption keys that protect data during processing and storage are rarely rotated after deployment, which leaves old material in use indefinitely. Versioned keys allow rotation without re-creating every dependent item, but only if the process is run and recorded. OpenBao's transit secrets engine supports versioned encryption keys with key rotation, so teams can encrypt application data through the service without storing key material in the application. Confirm the rotation interval, who approves it and where each rotation is logged.
Decrypted data left in the clear
Server-side encryption in some platforms protects file contents at rest but does not hide every piece of metadata. Nextcloud's server-side encryption keeps keys on the server and does not encrypt file names or folder structure, so confidential naming conventions can leak even when contents are protected. Document which fields are sensitive, decide whether they belong in names or paths at all, and test what a stolen storage volume would reveal. Treat this as a design decision to record, not a default to accept.
No evidence owner for PR.DS-10
Controls for data in use span platform, application and security teams, and none of them usually owns the outcome. Without a named owner, the evidence set for PR.DS-10 is assembled in a rush before an assessment and goes stale afterward. Assign one accountable owner, define the artifacts they must keep (location register, memory test results, isolation configuration, rotation logs), and set a review date. Ask your assessor which artifacts they expect before you collect them.
Questions buyers ask about PR.DS-10 cost, effort and audits
Can PR.DS-10 be certified?
No. PR.DS-10 is a Subcategory of the NIST Cybersecurity Framework 2.0, and NIST does not certify CSF implementations, products or services or plan a conformity assessment program for the CSF. What an organization can receive is an independent assessment of its own controls and evidence for PR.DS-10, issued by an assessor it hires. Ask any provider that offers a PR.DS-10 certificate what body issued it and under which program, because the CSF itself does not have one. If a customer or regulator asks for proof, the usual answer is a written assessment against the Subcategory with the supporting evidence attached, or a certification to a different standard that maps to it.
How much effort does meeting PR.DS-10 take?
The effort depends on how much of your data is processed in memory, on shared platforms or in analytics environments, and how many of those systems already isolate tenants and clear sensitive values. No supplied figure gives a duration, so ask for one in writing rather than relying on a general estimate. The main drivers are the number of processing workloads that handle confidential data, whether your platforms already separate users and processes, how much of the control depends on application code you own, and how much evidence your assessor will need. A fixed-scope engagement starts from an agreed list of systems, so the quote should name those systems and the evidence each one will produce.
What does PR.DS-10 cost, and who gets paid for what?
No price for PR.DS-10 is published, and DeployOpen does not publish a price list. Costs usually fall into four groups: internal staff time, implementation work on the platforms, the independent assessment fee, and any tooling licenses. Open-source components remove license fees but not configuration, testing or documentation work. Most of the cost is one-time, such as scoping, configuration and evidence collection. Recurring costs include reviewing isolation settings after upgrades, rotating keys and re-collecting evidence at each assessment cycle. A written quote should split these groups, state what is one-time and what recurs, and list the systems in scope.
What does our internal team need to provide?
Your team needs to own the decisions that the control depends on. These include which data is confidential, where it is processed, who may access each workload, how long data may stay in memory, and which owner accepts residual risk. Engineers must give access to platform configuration, logs and deployment pipelines, and someone must approve changes that affect isolation. Plan for time from a platform owner, a security lead who can interpret the assessment requirements, and a business owner for the data classification. Without these people, the implementation partner can prepare systems, but it cannot decide what the organization accepts.
Can we do PR.DS-10 ourselves without an outside partner?
Yes, if your team has the skills to design and test isolation on the platforms you run, keep configuration under change control, and produce evidence an assessor will accept. Many organizations do the policy and scoping work in-house and bring in help for technical hardening or evidence design. Outside help is most useful when the environment is complex, when several platforms share data, or when no one on staff has time to build and maintain the evidence. Whichever route you choose, the organization remains responsible for the control. An implementation partner prepares systems and documentation, and only an independent assessor issues an opinion.
How does PR.DS-10 map to ISO 27001 or SP 800-53 audits?
The CSF 2.0 Reference Tool lists informative references for PR.DS-10, including controls from NIST SP 800-53 Rev. 5.2.0, ISO/IEC 27001:2022 and SP 800-171 Rev. 3. These references show where other frameworks cover similar outcomes, but they are not a guarantee that evidence for one framework satisfies another. Before reusing evidence, check the exact control text in the target framework with its assessor, because an auditor may expect different artifacts or a different sampling method. Confirm the mapping you rely on against the current NIST reference export and the assessor's own criteria before you build a shared evidence set.
What evidence will an assessor ask for on PR.DS-10?
Assessors usually ask for evidence that the control operates, not only that it is written down. Typical items include the data classification that defines confidential data, the configuration of isolation between users and processes, records showing that memory and processor state are cleared or released when processing ends, and logs or test results that prove the setting holds. Ask your assessor which samples and time periods they will test before you collect anything. Tools that encrypt or manage keys, such as Nextcloud server-side encryption or OpenBao's transit engine for application data, can support parts of the evidence set, but each claim must be checked in your own environment.
Official NIST sources for PR.DS-10
Before you map PR.DS-10 to a control set, read the official text yourself. The authoritative wording sits in Appendix A of *NIST CSWP 29*, the CSF 2.0 publication, which lists every Function, Category and Subcategory of the CSF Core. Use the NIST CSWP 29 PDF for the Subcategory statement itself. Read it in the context of the PR.DS Category, because PR.DS-10 is about the confidentiality, integrity and availability of data while it is being processed, not stored or moving across a network. Those two other Subcategories are covered on their own pages.
The Reference Tool export is the second source to pull. It contains the Core, the NIST Implementation Examples for PR.DS-10 and the informative references that link the Subcategory to other catalogs. The export is a JSON download, so your team will need a parser or a spreadsheet step to read it. Use the CSF 2.0 Reference Tool export to confirm which Implementation Examples apply to your platform, and treat its informative references as pointers to candidate controls, not as proof that a control is in place. Record the export date in your evidence file, since NIST updates these resources separately from the framework document.
If you are moving from CSF 1.1, the NIST transition spreadsheet shows how PR.DS-10 absorbs part or all of the older PR.DS-5. Confirm that the Implementation Examples you rely on still match your own in-scope systems, and document any change in wording. Your assessor will expect a traceable record from the official source to your control design, so keep the PDF version, the export date and the spreadsheet together in one folder.
