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

To meet the pr.ds-02: the confidentiality, integrity, and availability of data-in-transit are protected requirement, you must identify every way your organization transmits sensitive data and apply strong, managed protections (encryption, integrity validation, and resilience controls) across those paths, with monitoring and evidence. Make it auditable by mapping the requirement to an owner, procedures, and recurring proof. ¹

Key takeaways:

• Inventory and classify data-in-transit flows first; controls that aren’t tied to flows won’t satisfy PR.DS-02 in an exam.
• Enforce encryption + integrity + availability together, not “TLS exists somewhere,” and document exceptions.
• Treat third parties and APIs as first-class transit paths, with contractual and technical requirements plus collected evidence.

PR.DS-02 sits in the “Protect” function and focuses on a deceptively simple problem: data moves constantly, and every movement is a risk event. “Data-in-transit” includes browser-to-app traffic, service-to-service calls, admin access, file transfers, API traffic, database replication, message queues, OT/IoT telemetry, and connections to third parties. The requirement is broader than “turn on HTTPS.” It expects you to protect confidentiality (prevent interception), integrity (prevent tampering or spoofing), and availability (keep transit mechanisms working and resilient) for relevant transmissions. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to operationalize PR.DS-02 as a control set with clear scope: (1) enumerate and tier data flows, (2) standardize approved transport methods and cryptographic configurations, (3) implement detection and exception handling, and (4) retain evidence that proves consistent operation over time. The most common gap is not the absence of technical controls, but the absence of defensible mapping: no authoritative inventory of flows, no control owner, and no recurring evidence that the protections remain in place. ²

Regulatory text

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

Operator interpretation: You must ensure that when your organization transmits data, you apply protections that (a) keep it secret from unauthorized parties, (b) prevent or detect unauthorized modification and impersonation, and (c) keep transmission paths reliable enough to support business and security operations. This is a control design and control operation requirement: you need standards, implementations, monitoring, and evidence that covers your real transit paths, including third parties. ¹

Plain-English interpretation (what “good” looks like)

A defensible PR.DS-02 program answers these questions without hand-waving:

• What data moves, between which systems, over which protocols, and through which third parties?
• Which protections apply to each flow (encryption, authentication, integrity checks, anti-downgrade, key management, logging)?
• How do you prevent drift (config changes, expired certificates, newly introduced endpoints)?
• How do you prove it (recurring technical evidence + policy and procedure mapping)? ¹

Who it applies to

Entities: Any organization running a cybersecurity program and using NIST CSF 2.0 as a framework reference. ¹

Operational contexts where PR.DS-02 is usually tested hard:

• Internet-facing applications, SaaS, and customer portals
• Cloud workloads with microservices and internal APIs
• Remote administration (VPN, bastions, privileged access)
• File transfer processes (SFTP/FTPS/managed file transfer)
• Third-party integrations (payment processors, HR platforms, call centers, MSPs)
• Hybrid networks with site-to-site links and partner connectivity ¹

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

1) Define scope: what counts as “data-in-transit” for you

Create a short scoping statement that:

• Names your in-scope data types (e.g., customer data, employee data, regulated data, secrets, telemetry with identifiers).
• Includes both external and internal transit (east-west traffic).
• Includes third-party connections and contractor/admin access paths.
  Keep it in your security policy set so auditors see consistent scope language. ¹

2) Build a data-in-transit flow inventory (minimum viable, then iterate)

Start with a flow register (spreadsheet is fine) with these columns:

• Source system / owner
• Destination system / owner (or third party)
• Data classification
• Transport/protocol (HTTPS, mTLS, SFTP, SMTP, VPN, message bus)
• Authentication method (certs, tokens, keys)
• Encryption expectation (required/optional/exception)
• Integrity expectation (required/optional/exception)
• Availability dependency and criticality
• Monitoring/log source
• Exception ID (if any) and expiration date

Populate using: architecture diagrams, cloud load balancer listeners, API gateway routes, firewall rules, VPN configs, CI/CD service maps, and third-party integration lists. PR.DS-02 is difficult to defend without an inventory that can be shown and explained. ¹

3) Set enforceable transport standards (policy + configuration baseline)

Write (or update) a “Secure Data Transmission Standard” that covers:

• Approved protocols (e.g., HTTPS, mTLS, SFTP) and disallowed ones (e.g., cleartext protocols for sensitive data).
• Certificate and key management expectations (issuance, rotation approach, revocation handling).
• Minimum logging expectations for transit endpoints (load balancers, API gateways, VPN concentrators).
• Exception process: who can approve, compensating controls, and time bounds.

Then map the standard to technical baselines: cloud policy-as-code, reverse proxy configs, service mesh settings, MDM/email controls, and managed file transfer tooling. ²

4) Implement confidentiality protections (encryption + access controls for transit)

For each flow class, ensure encryption is real and enforced:

• Web/app traffic: TLS on every ingress, with redirects and HSTS where appropriate.
• Service-to-service: mTLS or equivalent strong channel protection for sensitive traffic.
• Admin access: VPN or zero-trust access with strong authentication; prohibit direct public admin ports where possible.
• Email and file transfer: use secure transfer mechanisms for sensitive data; avoid ad hoc cleartext exchanges.

Also address “confidentiality leakage” through misrouting: DNS controls, certificate validation, and blocking insecure downgrade paths. ¹

5) Implement integrity protections (authentication, validation, and anti-tamper)

Integrity requires more than encryption:

• Mutual authentication for high-risk service calls (mTLS, signed tokens, strong client auth).
• API request signing where appropriate for high-integrity workflows.
• Replay protection for sensitive API operations (nonce/timestamps depending on your architecture).
• Certificate validation and pinning policies where feasible for mobile or controlled clients.

Operationally, you need a way to detect tampering signals: abnormal TLS errors, certificate changes, unexpected cipher/protocol negotiation patterns, and token verification failures. ¹

6) Implement availability protections for transit mechanisms

Availability for data-in-transit usually fails because of operational brittleness:

• Certificate expiry and renewal failures
• Single points of failure in VPN, API gateways, load balancers, DNS
• Rate limiting misconfigurations that self-deny service
• DDoS exposure without upstream protections

Translate PR.DS-02 availability into controls you can show:

• Certificate lifecycle management with alerting and ownership
• Redundant ingress/egress paths for critical services
• Capacity and resilience monitoring on transit components (API gateways, service mesh, VPN, message brokers)
• Tested rollback procedures for network/security config changes ¹

7) Cover third parties explicitly (technical + contractual + evidence)

Treat third-party connections as data-in-transit flows in your register:

• Document the integration method and required protections (TLS, VPN, private link, signed payloads).
• Contractually require secure transmission and incident notification for security events related to transit.
• Collect evidence: attestation artifacts, integration architecture docs, and proof of enforced secure channels at your boundary (e.g., TLS-only endpoint configs). ¹

8) Make it auditable: assign an owner and set recurring evidence collection

PR.DS-02 commonly fails on “prove it.”

• Assign a control owner (Security, Network, Platform Engineering).
• Set a recurring review cadence for the flow register and baseline configs.
• Capture recurring evidence (see below) and tie it to the requirement mapping.
  Daydream is often used here as the system of record to map PR.DS-02 to the policy, procedure, owner, and recurring evidence tasks so you can answer audits quickly without re-creating the story each time. ²

Required evidence and artifacts to retain

Keep evidence that demonstrates design and operating effectiveness:

Governance artifacts

• Secure Data Transmission Policy/Standard
• Data-in-transit flow register with classifications and exceptions
• Exception approvals with compensating controls and expiration dates
• Third-party integration requirements (contract language excerpts or security addendum sections)

Technical evidence (sample set)

• TLS configuration screenshots/exports from load balancers, API gateways, reverse proxies
• Service mesh or mTLS enforcement configs (where used)
• VPN/remote access configuration and access method documentation
• Certificate inventory and alerting evidence (alerts, dashboards, ownership)
• Logging samples showing TLS handshake failures, auth failures, and gateway logs
• Change management records for network/security configuration changes tied to transit components ¹

Common exam/audit questions and hangups

Expect auditors to probe for completeness and exceptions:

• “Show me your inventory of data-in-transit paths and how you know it’s complete.”
• “Which transmissions are encrypted, and where are the exceptions documented and time-bound?”
• “How do you ensure integrity for service-to-service calls and APIs?”
• “How do you prevent certificate expirations from causing outages?”
• “How do you cover third-party connections and contractor access?”
• “What evidence shows this control operated consistently, not just configured once?” ¹

Frequent implementation mistakes (and how to avoid them)

• Mistake: Equating PR.DS-02 with ‘HTTPS everywhere.’
  Fix: Add integrity and availability checks to your control objectives and evidence list (mTLS/signing where needed, certificate lifecycle, redundancy). ¹

• Mistake: No authoritative flow inventory.
  Fix: Maintain a flow register tied to architecture sources and require new integrations to register a flow before production release. ¹

• Mistake: Exceptions that never expire.
  Fix: Require expiration dates, compensating controls, and a named approver; review exceptions as part of recurring evidence. ¹

• Mistake: Third parties treated as “out of scope.”
  Fix: Put third-party integrations in the same register and require secure transmission contractually and technically at your boundary. ¹

• Mistake: Weak evidence.
  Fix: Save config exports, logs, and monitoring artifacts that show continuous operation; map them to PR.DS-02 with a clear owner. ²

Risk implications (why operators get burned)

Data-in-transit failures produce high-impact incident patterns: interception of credentials or sensitive data, man-in-the-middle tampering of transactions, and outages caused by brittle crypto and network dependencies. Even without a breach, inability to demonstrate control ownership and recurring evidence can create audit findings and delay customer security reviews. The most defensible posture is one where every critical flow has a known protection pattern, known owners, and repeatable proof. ¹

Practical 30/60/90-day execution plan

First 30 days: establish scope and visibility

• Publish scope statement and assign PR.DS-02 control owner. ¹
• Build the initial data-in-transit flow register for the highest-risk systems and third-party connections. ¹
• Draft or update the Secure Data Transmission Standard and exception process. ²
• Capture baseline evidence for primary ingress (API gateway/load balancer/proxy TLS settings) and remote admin access.

Days 31–60: enforce standards and close obvious gaps

• Roll out required secure transport configurations by platform (web, API, service-to-service, file transfer, remote access). ¹
• Implement certificate inventory ownership and alerting; document the runbook for renewals and incident response for cert failures. ¹
• Put third-party requirements into contract templates or security addenda; update the integration onboarding checklist to require flow registration. ¹
• Start recurring evidence collection (scheduled exports, screenshots, log samples) and store in a centralized evidence repository.

Days 61–90: operationalize and make it repeatable

• Expand the flow register to remaining systems; reconcile against network/cloud inventories. ¹
• Add monitoring and detection use cases for downgrade attempts, anomalous TLS failures, and auth/integrity failures. ¹
• Run a tabletop: “certificate expires” and “third-party endpoint forced to insecure protocol” scenarios; document outcomes and control improvements. ¹
• In Daydream, map PR.DS-02 to the finalized policy, procedure, control owner, and recurring evidence tasks so audit prep becomes a retrieval exercise, not a rework project. ²

Frequently Asked Questions

Does PR.DS-02 require encryption for all traffic, including internal east-west traffic?

PR.DS-02 expects protections proportionate to risk across all relevant data-in-transit paths, including internal flows. Treat sensitive internal service-to-service traffic as in-scope and document any exceptions with compensating controls. ¹

What counts as “integrity” protection beyond TLS?

Integrity includes strong endpoint authentication and mechanisms that prevent or detect tampering (for example, mTLS for service identity or signed requests for high-integrity APIs). Your evidence should show both configuration and ongoing monitoring for integrity-related failures. ¹

How do we prove availability for “data-in-transit” without inventing uptime metrics?

Prove availability through design and operational controls: redundancy for transit components, certificate lifecycle controls, monitoring dashboards, and change/incident records for outages related to network and cryptographic services. Keep artifacts that show these controls run consistently. ¹

We have legacy systems that can’t support modern secure protocols. Can we still pass an audit?

Yes, if you document the exception, add compensating controls (segmentation, tunnels, gateways, strict access controls), and set a time-bound remediation plan. Auditors usually focus on whether you identified the risk and managed it with governance and proof. ¹

How should PR.DS-02 cover third-party integrations and SaaS connections?

Treat each third-party connection as a data-in-transit flow with explicit required protections and monitoring at your boundary. Retain contracts or addenda showing secure transmission expectations plus technical evidence of enforced secure endpoints. ¹

What’s the minimum evidence set to keep PR.DS-02 from becoming a scramble during audits?

Keep a current flow register, a secure transmission standard, and a repeatable evidence pack from key transit control points (ingress TLS configs, VPN settings, certificate inventory/alerts, and log samples). Map each artifact to PR.DS-02 with a named owner and collection frequency. ²

Footnotes

1. NIST CSWP 29

2. NIST CSF 1.1 to 2.0 Core Transition Changes