PR.DS-10: The confidentiality, integrity, and availability of data-in-use are protected

To meet the pr.ds-10: the confidentiality, integrity, and availability of data-in-use are protected requirement, you must protect sensitive data while it is actively being processed in memory, runtimes, or active sessions, not just at rest or in transit. Operationalize this by inventorying data-in-use paths, enforcing runtime access controls and isolation, hardening secrets handling, and collecting repeatable evidence that controls run as designed. ¹

Key takeaways:

• Data-in-use protection focuses on memory, execution environments, and active sessions, where traditional disk and network controls do not apply. ¹
• You need mapped data flows + technical controls + recurring evidence, owned by named operators, to pass audits. ²
• Most audit failures are documentation and scoping failures: teams protect “everything generally” but cannot prove protection for the highest-risk data-in-use paths. ¹

PR.DS-10 exists because many programs stop at encryption-at-rest and TLS, then assume the job is done. Your real exposure often sits in application memory, container runtimes, CI/CD runners, admin sessions, and analytics/ML pipelines where data is decrypted and acted on. PR.DS-10 requires you to protect the confidentiality, integrity, and availability (CIA) of that data-in-use. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat PR.DS-10 as a requirement to (1) define what “data-in-use” means in your environment, (2) identify the systems and workflows where sensitive data is processed, (3) apply specific runtime protections, and (4) retain evidence that those protections are consistently operating. ²

This page gives requirement-level implementation guidance that you can assign to engineering, infrastructure, and security operations with clear deliverables: a scoped inventory, technical control set, test approach, and an evidence package you can reuse in internal audits, SOC reports, and regulator exams. ¹

Regulatory text

Requirement (excerpt): “The confidentiality, integrity, and availability of data-in-use are protected.” ¹

What the operator must do: implement controls that prevent unauthorized access, tampering, and disruption while data is being processed (for example, in memory, in active compute jobs, inside application runtimes, or within privileged sessions). This includes defining scope (which data, which systems), enforcing runtime protections (identity, isolation, secrets, and monitoring), and keeping evidence that these protections are in place and reviewed. ¹

Plain-English interpretation (what PR.DS-10 really means)

“Data-in-use” is data that has been decrypted and loaded into an application or workload so it can be processed. That includes:

• Customer records displayed in an agent portal during an active session
• Payment or payroll data processed by a batch job
• Health data transformed in an analytics pipeline
• Secrets and tokens loaded into app memory to call APIs

PR.DS-10 expects you to reduce three concrete risks in those moments:

1. Confidentiality: stop data from being read by the wrong identities or workloads.
2. Integrity: stop data from being modified in memory or during processing without authorization and detection.
3. Availability: keep processing environments resilient so data handling services remain accessible and recoverable. ¹

Who it applies to

Entities: any organization operating a cybersecurity program that processes sensitive, regulated, or business-critical data in applications, infrastructure, endpoints, or cloud services. ¹

Operational contexts where PR.DS-10 is highest impact:

• Cloud-native workloads (Kubernetes, serverless, managed databases with compute)
• Privileged access workflows (admins, SREs, DBAs, security analysts)
• High-volume processing (ETL, streaming, data warehouses)
• Third-party processing (SaaS platforms, managed service providers, customer support tooling)
• CI/CD and build environments (where code-signing keys and tokens often become “data-in-use”)

Third-party angle (TPRM): if a third party processes your sensitive data in their runtime, PR.DS-10 becomes a due diligence and contracting requirement: you need assurances and evidence that their production runtimes and privileged sessions protect data-in-use. ¹

What you actually need to do (step-by-step)

Use this as an assignable implementation checklist.

1) Define “data-in-use” and scope it to your high-risk data

Deliverables:

• A data classification crosswalk that explicitly calls out “data-in-use” handling expectations by class (e.g., Restricted/Confidential).
• A shortlist of crown jewel processing workflows (the ones auditors will ask about first). ¹

Practical scoping rule: start with systems where sensitive data is decrypted, transformed, queried, displayed, or exported.

2) Map data-in-use paths and trust boundaries

Deliverables:

• Data flow diagrams or architecture maps showing where sensitive data enters, is processed, and exits.
• Trust boundary notes: which components are multi-tenant, internet-exposed, or accessible by admins/third parties.

Minimum mapping elements you should capture:

• Workload type (VM, container, serverless, endpoint)
• Identity plane (SSO, workload identity, service accounts)
• Secrets source (vault, KMS, env vars, config files)
• Observability (logs, traces, crash dumps) that might capture data-in-use ¹

3) Implement runtime confidentiality controls

Pick controls that fit your architecture; auditors care that you covered the risk, not that you used a specific product.

Baseline control set:

• Strong authentication and session controls for all interactive access to systems that handle sensitive data-in-use (SSO, MFA, short session lifetimes for privileged tasks).
• Least privilege for service accounts and workloads: permissions only for the data and actions needed at runtime.
• Isolation boundaries: separate workloads and tenants so one process cannot read another’s memory or accessible runtime files.
• Secrets hygiene: prohibit hard-coded secrets; restrict where secrets can be injected; rotate and revoke quickly after exposure.
• Prevent data-in-use leakage through telemetry: review logging for sensitive fields, restrict crash dump collection, and protect APM/debug tooling access. ¹

4) Implement integrity controls for processing and runtime state

Deliverables:

• Runtime change control and detection for the components that process sensitive data.

Controls to consider:

• Code integrity: signed builds, controlled deployment pipelines, restricted production changes.
• Configuration integrity: immutable infrastructure patterns or controlled config changes with approvals and audit logs.
• Input/output validation and tamper detection for pipelines and APIs that transform sensitive data.
• Privileged activity logging with review and alerting for high-risk actions (e.g., exporting large datasets, disabling controls). ¹

5) Implement availability controls specific to data processing services

Availability for data-in-use is not only uptime. It is also recovery and continuity of secure processing.

Controls to consider:

• Capacity and resilience for critical processing services
• DDoS and abuse protections on systems that expose processing endpoints
• Backup/restore for dependent systems, plus tested recovery runbooks
• Dependency risk management (managed services, third-party APIs used in processing) ¹

6) Assign ownership, cadence, and evidence collection (make it auditable)

This is where teams fail PR.DS-10 in practice.

Create a control record that maps PR.DS-10 to:

• Policy: data handling standard that explicitly includes data-in-use
• Procedure: how engineering implements and security validates
• Control owner: named role (not a team alias)
• Evidence cadence: what you collect and how often (for example, per release, per quarter, or continuously)
• Exception process: risk acceptance with compensating controls and expiration ²

If you run Daydream for GRC operations, treat PR.DS-10 as a requirement object with linked controls, owners, and recurring evidence tasks so you can show “designed + operating” without rebuilding the package each audit cycle. ²

Required evidence and artifacts to retain

Auditors and examiners typically want proof across scope, design, and operation.

Scope + design

• Data classification standard referencing data-in-use handling
• Data flow diagrams for in-scope systems
• Control matrix mapping PR.DS-10 to technical controls and owners ²

Operational evidence (examples)

• IAM exports showing privileged role assignments and service account permissions for key processing systems
• Screenshots or exports of session controls (MFA enforcement, conditional access policies)
• Secrets management configuration proof (approved secret stores, rotation settings)
• Logging standards plus samples showing sensitive field redaction
• Change management records for production releases affecting sensitive processing
• Incident tickets or detections related to data exposure in memory/logging, plus remediation notes ¹

Third-party evidence (if applicable)

• Contract clauses requiring protection of data-in-use and limitations on debugging/log access
• Due diligence artifacts: SOC reports, shared responsibility documentation, or control attestations that speak to runtime access controls and privileged access governance ¹

Common exam/audit questions and hangups

Common questions you should be ready to answer with artifacts:

1. “Show me where sensitive data exists in use.” Expect follow-ups on the top workflows, not every system.
2. “Who can access production runtime and how do you control sessions?” Have the privileged access story tight (SSO, MFA, approvals, logging).
3. “How do you prevent data from showing up in logs, traces, or crash dumps?” This is a frequent gap for app teams.
4. “How do you know controls are operating?” Provide recurring evidence and reviews, not one-time screenshots. ¹

Hangup pattern: teams present encryption-at-rest and TLS diagrams. Auditors will push: “Where is it decrypted and processed, and what controls exist at that point?” ¹

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails PR.DS-10	How to avoid it
Treating PR.DS-10 as “database encryption”	Data-in-use is outside disk encryption scope	Build a data-in-use inventory and show runtime controls 1
No clear scope	You cannot prove coverage or prioritize	Start with crown-jewel workflows and document boundaries 2
Over-permissioned service accounts	Creates silent data-in-use exposure paths	Enforce least privilege and periodic access review evidence 1
Debug tooling left open in production	Memory/telemetry can expose sensitive data	Restrict APM/log access, redact fields, and gate crash dumps 1
Evidence is ad hoc	Audits become painful and inconsistent	Predefine evidence cadence and owners; collect continuously where possible 2

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for PR.DS-10, so this page does not cite specific actions.

Risk-wise, PR.DS-10 maps to failure modes that create real incident impact: unauthorized access through privileged sessions, exposure through logs and debugging, and tampering via compromised runtimes or pipelines. The compliance risk is compounded when you cannot demonstrate control operation with repeatable evidence mapped to the requirement. ¹

Practical 30/60/90-day execution plan

First 30 days (scope + minimum viable controls)

• Name a PR.DS-10 control owner and publish a short standard for data-in-use handling aligned to your data classification.
• Identify the highest-risk processing workflows and draft data flow diagrams with trust boundaries.
• Implement or verify: MFA/SSO for privileged access, least privilege for top service accounts, and a secrets storage standard.
• Stand up an evidence register: what you will collect, who collects it, and where it lives. ²

Days 31–60 (close gaps + validate operation)

• Reduce over-privileged roles and service accounts in the in-scope systems; document exceptions.
• Add controls to prevent data-in-use leakage through logs/traces and restrict crash dumps and production debugging access.
• Add integrity controls: controlled deployments, production change approvals, and administrative action logging for sensitive systems.
• Run an internal audit walkthrough: pick one workflow and prove CIA protections end-to-end with artifacts. ¹

Days 61–90 (scale + make it repeatable)

• Expand the scoped inventory to additional workflows and third parties that process sensitive data.
• Formalize recurring reviews: privileged access reviews, secrets rotation checks, logging/redaction checks.
• Implement continuous evidence collection where feasible (IAM exports, configuration snapshots) and attach it to the PR.DS-10 control record in your GRC system (Daydream or equivalent). ²

Frequently Asked Questions

Does PR.DS-10 require encryption of RAM or “confidential computing”?

PR.DS-10 requires protection of data-in-use, but the framework excerpt does not prescribe a specific technology. If your risk profile includes hostile co-tenancy, advanced threats, or highly regulated workloads, memory-encryption or hardware-backed isolation may be appropriate, but your obligation is to implement and evidence effective runtime protections. ¹

We already have TLS and disk encryption. Why isn’t that enough?

TLS protects data in transit and disk encryption protects data at rest. Data-in-use is the period where data is decrypted for processing, so your controls must address runtime access, isolation, secrets handling, and logging hygiene. ¹

What systems should I scope first for data-in-use protection?

Start with workflows that process restricted data and have broad access paths: production apps, analytics pipelines, admin consoles, and third-party support tooling. Document the data flow and trust boundaries so you can show auditors a defensible scope. ¹

What evidence is most persuasive in an audit for PR.DS-10?

A mapped control record (policy, procedure, owner) plus operational proof: IAM role assignments, privileged access controls, secrets management settings, logging/redaction samples, and change/audit logs. Recurring evidence beats one-time screenshots. ²

How do I handle third parties that process our data in their applications?

Treat them as in-scope for PR.DS-10 and require contract language and due diligence artifacts that address runtime access controls and privileged session governance. Track these third parties in your TPRM inventory and tie the evidence to the PR.DS-10 control. ¹

Engineering says “we don’t store sensitive data,” but we process it. What now?

Processing still creates data-in-use exposure, even if storage is minimized. Ask for a data flow diagram and inspect logs, traces, and debug practices, because those commonly reintroduce sensitive data into stored systems. ¹

Footnotes

1. NIST CSWP 29

2. NIST CSF 1.1 to 2.0 Core Transition Changes