PR.DS-02 Data in transit: requirements and evidence

What PR.DS-02 data in transit requires in plain terms

PR.DS-02 asks the organization to protect the confidentiality, integrity and availability of data while it moves between systems. If an audit, a customer questionnaire or an engineering backlog item has brought you here, the practical question is which flows carry sensitive data, how each one is protected, and what proof exists that the protection is active. The Subcategory is part of the Data Security Category in the PROTECT Function of CSF 2.0. It continues CSF 1.1 PR.DS-2 at the same identifier and absorbs part or all of CSF 1.1 PR.DS-5, so older assessments that cite PR.DS-2 or PR.DS-5 can be carried forward with some rework. The risks are concrete: interception of traffic on untrusted networks, tampering with data in transit, leakage through outbound email and personal file sharing services, and production records copied into development and test environments where access controls are weaker. Each of these is a flow, and that is why the Subcategory is hard to satisfy. Many flows are undocumented. Service-to-service calls, backup replication, vendor integrations, scheduled exports and developer copies often exist without an owner or a diagram. Start with a data flow inventory that records source, destination, data classification and transport method, then check each entry against the NIST Implementation Examples for PR.DS-02 in the NIST CSWP 29 framework document. PR.DS-02 sits beside PR.DS-01 (data at rest), PR.DS-10 (data in use) and PR.DS-11 (backups). It covers the movement of data, so a file encrypted on disk but sent over plain HTTP still fails here, while a backup copy is assessed under PR.DS-11. Confirm with your assessor which evidence they will accept for each flow, because the same encryption setting can support more than one Subcategory and the overlap should be explained once in your assessment rather than repeated for each one.

Which data flows and systems PR.DS-02 covers in practice

PR.DS-02 applies wherever data moves, so the first real task is deciding which flows and systems the organization brings inside its documented scope. The four Implementation Examples NIST publishes define the boundary: encrypting and signing network communications, encrypting or blocking outbound sensitive email, blocking personal email and file sharing, and preventing reuse of production data in development and test. The organization owns these scope decisions, and an assessor will test the scope as the organization documents it.

Internal service-to-service traffic

Decide whether traffic between application tiers, databases, message queues and identity services inside the private network is in scope. Many organizations encrypt only the perimeter and leave east-west traffic in clear text, which is the gap an assessor is most likely to probe. Check which connections carry sensitive records, which use mutual TLS, and where certificates are issued and renewed. Record the decision and its rationale, even when the answer is to encrypt everything.

External and customer-facing channels

Public web applications, APIs, partner gateways and file transfer endpoints form the boundary most organizations already treat as in scope. The scoping question is which protocol versions, cipher suites and certificate chains are accepted, and whether any legacy endpoint is excluded. Document each external channel, its owner and the data classes it carries. Partner connections that sit outside the organization's own network still count if sensitive data crosses them.

Outbound email and file sharing

Scope the mail gateway, collaboration tools and any sanctioned file sharing service, then decide what happens when sensitive content leaves through them. NIST's examples describe automatically encrypting or blocking outbound email that contains sensitive data, and blocking personal email and file sharing services. Each choice creates a rule set, an exception process and logs an assessor can sample. Confirm which channels employees can reach from managed devices and which are blocked at the network or endpoint.

Administrative access paths

Administrative sessions to databases, hypervisors, cloud consoles and network devices carry credentials and configuration data that attackers target. Decide whether bastion hosts, privileged access tools and remote management protocols are in scope, and whether their sessions are encrypted end to end. Include backup and monitoring tools that pull data from production. Confirm that each administrative path has a named owner and a documented encryption standard.

Non-production environments fed from production

Development, test and training environments are often copied from production, and that copy moves sensitive data into systems with weaker controls. NIST's example on preventing reuse of production data in development and test defines the boundary here. Decide whether data is masked or synthesized before it leaves production, and whether the transfer itself is encrypted and logged. Ask the engineering team to list every refresh job, since undocumented copies are where scope breaks down.

How an assessor tests PR.DS-02 in transit

This table lists each part of the PR.DS-02 outcome, the test an assessor typically runs, the evidence requested and the findings that commonly appear. Read each row as a test plan you can prepare for before fieldwork starts. The auditor, not DeployOpen or NIST, decides whether the organization meets the outcome.

Test area	Test approach and evidence requested	Common findings
Transit inventory	Review the documented inventory of data flows, including which systems send sensitive data over networks, APIs and third-party links. Request network and data flow diagrams and a list of owners for each flow.	Flows missing from the inventory, unknown integrations, and flows with no named owner
Protocol and cipher configuration	Sample internet-facing and internal endpoints, load balancers and application services. Capture the protocol versions and cipher suites in use and compare them with the organization's approved standard.	Legacy protocol versions still enabled, weak cipher suites on internal services, and endpoints outside the scan scope
Certificate issuance and renewal	Select a sample of certificates and trace each to its issuing authority, requester, renewal record and installed location. Request the certificate register and the renewal alerts or automation logs.	Expired certificates, self-issued certificates with no ownership record, and certificates that renewed manually without a log entry
Outbound email and file sharing rules	Send test messages containing sample sensitive content (synthetic data only) through outbound email and file transfer paths. Record whether the control encrypts, blocks or only alerts, and request the rule configuration and change history.	Rules that log matches but never block or encrypt, rules limited to some mail domains, and sensitive patterns the rules do not detect
Personal email and file sharing blocking	Attempt access from managed endpoints and the corporate network to approved test services that are not authorized for business data. Review proxy, firewall and endpoint policy exports and the exception register.	Exceptions granted without expiry or approval, unmanaged devices that bypass the proxy, and blocking applied to web access only
Production data in non-production	Review the documented process that governs copying production data to development and test. Request examples of refresh requests, masking or synthetic data records, and access reviews for non-production environments.	Full production copies in test without approval, masking steps that are undocumented, and developer access to live data
Encryption and signing of network communications	Confirm that transit encryption is applied to the flows identified in the inventory and that signing is used where the flow requires integrity checks. Request the configuration baseline and sample verification records.	Flows encrypted on the outside but not inside the network, and signing keys with no rotation record

Implementing PR.DS-02 in sequence

This sequence moves an organization from knowing where its data travels to proving that data in transit is encrypted, signed, controlled and monitored. Each step produces a record that an assessor or internal reviewer can check against PR.DS-02.

Inventory data flows and classify data
Start by mapping which systems, users, partners and external services exchange data, and which of that data is sensitive. The data owner and the security team should build a flow register listing each source, destination, protocol, data class and business owner. The step is complete when every flow carrying sensitive data has a named owner and a classification, and the team can explain how the register was checked against network and application inventories.
Define the encryption and signing standard per flow
For each flow in the register, decide what protection applies: which TLS versions and cipher suites are permitted, when mutual authentication is required, where message or file signatures are needed, and which exceptions need approval. The security architect writes this as a transport standard and the owner signs it off. The standard is done when every flow class maps to a stated requirement and the exception process is written down.
Establish a certificate authority and issuance process
Encryption and signing depend on certificates that can be issued, tracked and revoked. Decide whether certificates come from an internal CA, such as the integrated Dogtag-based CA in FreeIPA, or from a secrets platform, and define who may request, approve and revoke them. For Kubernetes or OpenShift workloads, cert-manager can issue and renew certificates from configured issuers. The step closes with CA records: the issuer hierarchy, key storage location, issuance log, renewal method and revocation procedure.
Enforce protection on internal and external paths
Apply the standard to the actual paths. Configure TLS on internal services and external endpoints, enable signing where the standard requires it, and use a transit encryption or signing service, such as the OpenBao transit secrets engine, where applications should not hold keys. The platform team should test each path with a scan or a connection check. The output is a set of configuration baselines per system, with the test results attached.
Configure outbound email and file sharing controls
Translate the standard into rules for outbound channels. Define how email containing sensitive data is detected and either encrypted or blocked, which personal email and file sharing services are blocked, and which approved services must be used instead. Confirm with the chosen tools which detection and enforcement features they actually provide before writing rules. The output is a rule set with its owner, change history and a list of approved exceptions.
Separate non-production data handling
PR.DS-02 includes preventing reuse of production data in development and test. Write a data handling procedure that states when production data may be copied to a non-production environment, how it must be masked or synthesized, who approves the copy, and how copies are deleted. Check existing test environments against the procedure. The step is complete when the procedure is approved and a sample of recent test data loads has been reviewed against it.
Set up monitoring and periodic review
Protection decays unless it is watched. Set alerts for certificate expiry, failed or downgraded TLS connections, blocked outbound transfers and new unregistered flows, then schedule reviews of the flow register, the standard and the rule sets. Record each review with its findings and the changes made. The output is a review log and a monitoring baseline. Ask any external assessor which review frequency and evidence they expect before setting one, since no frequency is fixed by the CSF itself.

Evidence that shows data in transit is protected

PR.DS-02 is tested through records, not promises. The cards below describe the artifacts an assessor expects to see, and each one needs a refresh rhythm so it still matches the live environment when someone checks it.

Data flow register with classification

A register listing each system-to-system and user-to-system data path, the data classification it carries, the network zone it crosses and the owner who approves it. It is the starting point for every other card because it shows which flows need encryption and which need outbound controls. Keep it current by reviewing it whenever a new integration, API or SaaS connector goes live, and by reconciling it against a quarterly export of network flow or firewall rules. A stale register looks like a diagram with systems missing from it, or flows that appear in traffic logs but in no record.

Transit encryption and signing standard

A written standard naming the approved protocol versions, cipher suites, key lengths and signing algorithms for internal and external traffic, including which flows may use mutual TLS. The standard should state who can approve an exception and how long it lasts. Review it on a fixed schedule and whenever a protocol is deprecated. An assessor will notice a standard that still permits protocols the live systems have already retired, or one that no engineer can point to in a change record.

Configuration exports and scan results

Exports from web servers, load balancers, databases and message brokers, plus periodic TLS scans of internal and external endpoints, showing the protocols and ciphers actually negotiated. These records prove the standard is applied rather than documented. Schedule the scans and store each result with a date and scope, and rerun them after every platform upgrade. A stale version shows scan dates older than the most recent change, or findings from a previous scope that no longer covers the current hosts.

Certificate inventory with ownership records

An inventory of every TLS and signing certificate, with issuer, issue date, expiry, renewal method, system and named owner. Where certificates are issued by an internal CA such as FreeIPA's Dogtag-based authority, or automated by cert-manager in Kubernetes, the inventory should show the issuance and renewal trail as well. Reconcile it against scan results each cycle so unlisted certificates surface. A stale inventory shows expired certificates still in use, or certificates with no owner.

Outbound email and file sharing logs

The policy governing sensitive data in outbound email and personal file sharing, together with logs from the blocking or encryption controls that enforce it. Logs should show which rule fired, the classification involved and what action was taken. Review the rule set when classifications change and sample the logs periodically to confirm events are recorded. A stale record looks like a policy that names services no longer in the rule set, or logs that stop at a date when the gateway was replaced.

Non-production data handling records

Records showing that production data is not copied into development or test environments, or that copies are masked, tokenized or approved and then removed. This usually means refresh requests, masking job outputs and access reviews for non-production databases. Sample these records at a set frequency and compare them with the environment inventory. A stale version shows a test database refreshed from production with no approval, or a masking job whose last successful run predates the most recent schema change.

What meeting PR.DS-02 costs in money and effort

This table lists the cost components of protecting data in transit under PR.DS-02, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to check that a quote covers each line and to spot where an implementation partner's work ends and your own staff's work begins. No prices or durations are given because none were supplied for this topic, so ask for each line in writing.

Cost component	One-time or recurring	What drives it up	How to keep it down and what to request in a quote
Tooling and licenses	Mostly one-time setup, with recurring support if you buy a subscription	Commercial gateways, proxies or PKI products you already license but do not need for this outcome	Name each open-source component (for example Nextcloud, OpenBao, FreeIPA, cert-manager) and its license terms. Ask which license spend can be removed and which commercial support is optional.
Flow inventory and engineering time	One-time, with periodic refresh when new services are added	Number of network flows, legacy protocols, undocumented batch jobs and third-party integrations	Request a line for mapping every service-to-service and external flow carrying sensitive data. Ask for the flow list as a deliverable so later audits can reuse it.
Encryption configuration of services	One-time per service, with recurring change work	Number of services, mixed TLS versions, and protocols that cannot be upgraded without application changes	Ask for a quote that lists each in-scope service and the protocol settings to be enforced. Group similar services to reduce repeated effort.
Certificate and key operations	Recurring, driven by renewal and rotation cycles	Number of certificates, number of issuers (public ACME, internal CA, Vault or similar), and manual renewal steps	Ask for automated issuance and renewal (cert-manager renews before expiry; FreeIPA and OpenBao handle internal CA and transit keys). Request a runbook for key rotation and revocation, and who holds the signing keys.
Email and file sharing gateway work	One-time policy build, with recurring rule tuning	Volume of outbound mail and file transfers, number of sanctioned tools, and false positives blocking business work	Ask for a written list of sanctioned and blocked services and the outbound sensitive-data rules. Request a tuning period in the scope so the rules are adjusted before go-live.
Non-production data controls	One-time design, with recurring review at each release	Number of development and test environments and manual data copies from production	Ask for a documented rule on masking or excluding production data outside production, and a check that tests it. Confirm which environments are in scope.
Evidence upkeep	Recurring, usually the largest ongoing line	Frequency of evidence collection, number of systems, and manual screenshots or exports	Request automated evidence exports (configuration, certificate inventory, flow map, gateway logs) with a named owner and review date for each.
External testing or review	Recurring or per engagement	Scope of the test (external interfaces, APIs, internal segments) and number of retests	Ask whether testing of TLS configuration and interception paths is in the quote, and whether retesting after fixes is included or priced separately.
Auditor sampling and assessor time	Per assessment cycle	Number of systems sampled, number of exceptions, and whether evidence must be rebuilt for the auditor	Ask the auditor for its sample method in advance. Keep evidence in the form the assessor will test, so sampling does not trigger rework. Remember that only an independent assessor issues the findings.

Which self-hosted open-source tools support PR.DS-02 evidence

Four self-hosted components cover different parts of PR.DS-02: encryption of stored content, cryptographic services for applications, certificate issuance, and TLS certificate lifecycle for workloads. None of them proves on its own that data in transit is protected across the whole environment, so each card names what it can evidence and what the team must confirm before presenting it to an assessor.

Nextcloud file storage

Nextcloud's server-side encryption protects file contents at rest on local and external storage, with keys kept on the server. It does not encrypt file names or folder structure, so those metadata remain visible to anyone with access to the storage. For PR.DS-02, Nextcloud is a candidate for the file sharing and outbound transfer controls, not a transit control in itself. Confirm in your environment that client connections use TLS, that sharing settings match your data handling rules, and that metadata exposure is covered by other measures.

OpenBao transit engine

The OpenBao transit secrets engine encrypts and decrypts application data without storing that data, and signs and verifies it. Versioned encryption keys with rotation give the team a record of which key protected which payload. Applications that exchange sensitive messages can call the engine rather than hold their own keys. Confirm that key policies restrict who can use each key, that rotation is scheduled, and that the systems calling the engine connect to it over protected channels.

FreeIPA certificate authority

FreeIPA includes an integrated certificate authority based on Dogtag for issuing and managing certificates. For PR.DS-02, this gives the organization an internal source for certificates used by services and hosts on its network, so that encrypted sessions rest on certificates the organization controls. The evidence is the issuance and management record for each certificate. Confirm the CA hierarchy, who may request certificates, how revocation is handled, and which services are actually configured to use these certificates.

cert-manager for Kubernetes

cert-manager creates TLS certificates for workloads running in Kubernetes or OpenShift. It can draw on issuers such as ACME (Let's Encrypt), a CA key pair, HashiCorp Vault, CyberArk or a self-signed issuer, stores the results in Kubernetes Secrets, and renews them before they expire. Its issuer configuration and renewal events are the evidence an assessor will ask to see. Confirm which issuer each workload uses, who controls access to the Secrets, and that expired or failed renewals raise alerts.

Doing PR.DS-02 in-house or with an implementation partner

Your organization owns PR.DS-02 in every sense that matters to an assessor. Your people decide which data counts as sensitive, which flows carry it, which protocols are acceptable, and whether any remaining gap is accepted or fixed. No outside party can make those decisions for you, and an auditor will ask who signed them.

Data flow register: Maintain the inventory of where data moves between systems, users, cloud services and external parties, and mark which flows carry sensitive data.
Classification decisions: Decide and document the classes of data that trigger encryption, outbound inspection or blocking rules.
Protocol and cipher standards: Approve the transport security baseline, including minimum TLS versions and certificate authorities, and review it on a set cycle.
Risk acceptance: Record any exception, such as an unencrypted legacy link, with a named business owner, a compensating control and an expiry date.
Business owner sign-off: Obtain sign-off from the system owner that the evidence reflects the system in production.

Check that each decision above has a named owner and a dated record, because those records are what the assessor samples first.

Where transit protection usually falls short

Most organizations encrypt the traffic they can see and assume the rest is covered. Assessors look for the gaps in between: internal flows nobody mapped, certificates nobody renews, and outbound rules that record problems without stopping them. Each card below names the finding an assessor is likely to write and the step that closes it.

Undocumented internal traffic

Internal service-to-service traffic is often unencrypted because nobody listed it. An assessor will ask for data flow diagrams that show where sensitive data moves inside the network and will compare them against live traffic. Start by mapping flows between applications, databases, message queues and management interfaces, then mark which carry sensitive data. Each flow marked sensitive needs a documented protection method, such as TLS or an approved tunnel, and an owner who answers for it.

Certificates without an owner

Certificates that protect data in transit fail quietly when they expire or when no one knows which team holds them. The usual assessor finding is a certificate inventory that is incomplete or a renewal that depends on one person. Record every certificate with its issuer, subject, owner and expiry date, and automate issuance and renewal where the platform supports it. For Kubernetes workloads, cert-manager can request and renew TLS certificates from configured issuers, which removes manual renewal from the critical path.

Legacy protocols still enabled

Internal services often keep older protocol versions and weak cipher suites enabled for compatibility with old clients. A scan usually reports these as findings even when no one uses them. Review each listener on internal services, disable protocol versions and ciphers that no longer meet your policy, and test client compatibility before the change. Keep the scan output and the change record as evidence that the configuration was reviewed and that the decision was approved.

Outbound rules that only log

Data loss prevention rules on email and file transfer are often set to alert or log, so sensitive content leaves the organization and a report records it afterward. PR.DS-02 expects outbound sensitive data to be encrypted or blocked. The assessor will ask which rule fires, what action it takes and who reviews the alerts. Move high-confidence rules to block or enforced encryption, keep alert-only mode for tuning, and document which data types each rule covers.

Personal file sharing without a policy

Staff use personal email and consumer file sharing services for work files, often because approved tools are slow or missing. Assessors commonly find no written rule on these services and no technical control to enforce one. Define which services are prohibited for company data, block them at the network or endpoint layer where feasible, and provide an approved alternative. Keep the policy, the block list and the exception log together so the decision is traceable.

Production data copied to test

Test and development environments are frequently refreshed from production dumps with no handling rule. The resulting finding is that sensitive data sits in less protected systems, often with weaker transport encryption between test components. Write a rule that prohibits production data in non-production unless it is masked or tokenized, and confirm the rule in each refresh job. Record who approved each copy and when it was deleted, so the assessor can trace the data path.

Questions buyers ask about PR.DS-02 cost, effort and scope

How much work does meeting PR.DS-02 take, and what drives it?

The effort depends on how many systems carry data in transit and how much of the estate already uses current encryption. NIST publishes four Implementation Examples for PR.DS-02: encrypting and signing network communications, automatically encrypting or blocking outbound email that contains sensitive data, blocking personal email and file sharing services, and preventing production data from being reused in development and test. Each is a separate body of work with its own owners, so cost usually rises with the number of networks, applications, certificate authorities and mail or file flows in scope. The main drivers are:

the number of internal and external services that exchange sensitive data
how many certificates must be issued, renewed and tracked
whether identity and key management already exist or must be built
how many data flows cross trust boundaries

Ask for a breakdown by Implementation Example so you can see which parts carry the most effort.

Can our own team meet PR.DS-02 without outside help?

Yes, a capable internal team can work toward PR.DS-02 on its own, since the framework describes outcomes and does not require a particular provider. Outside help usually makes sense when the team lacks time, has little experience with certificate lifecycles or outbound data controls, or wants an independent check on its own work. Open-source components such as OpenBao, cert-manager and the certificate authority in FreeIPA can cover parts of the work, but each needs confirmation against your environment before you depend on it. The organization keeps ownership of its controls. An implementation partner such as DeployOpen prepares systems, configuration and evidence, while the organization decides what is in scope and accepts the remaining risk. Confirm that your team can run the recurring tasks after handover, including certificate renewal and key rotation, because those continue long after the project ends.

What does PR.DS-02 need from our internal staff?

Internal staff supply the knowledge a partner cannot infer: which data is sensitive, where it travels, which applications and business partners depend on it, and who approves exceptions. Expect named owners from security, network engineering, application development, email administration and platform engineering. Security owns the policy and the definition of sensitive data. Network and platform teams own TLS settings, segmentation and gateway behavior. Application owners confirm which services can move to new certificates and which legacy clients need a time-limited exception. Someone must also own the evidence, meaning configuration exports, certificate inventories, block logs and change records, because an assessor will ask for them. Before work starts, ask the provider to list each role, the decisions it must make and the approvals it must give, so the calendar for those people can be planned.

How long does a PR.DS-02 project take?

The duration depends on scope, so no single timeline applies to every organization. The factors that move the schedule most are the number of data flows, the condition of existing certificate infrastructure, and how many approvals are needed for changes to production networks and email gateways. DeployOpen works on fixed-scope engagements in which scope, deliverables and timelines are agreed in writing before work starts. The written plan should set out phases, dependencies, acceptance criteria and the dates each party must meet. Be cautious with any proposal that offers a duration before the systems in scope have been inventoried. Ask the provider to show which Implementation Example each phase addresses and what evidence will close it, so progress can be measured against the plan rather than against estimates.

Is there an audit or certification for NIST CSF 2.0?

No. NIST does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans to develop a conformity assessment program. Most organizations use the framework voluntarily, so alignment is typically self-described unless a customer, regulator or contract requires more. When a requester wants independent evidence, an independent assessor can test whether PR.DS-02 outcomes are in place and supported by records, then report on that testing under the terms of its own engagement. DeployOpen prepares systems, controls and evidence for such reviews, but it does not issue audit reports, attestations or certifications. Before scoping any work, ask the requesting party which type of assessor it accepts and what form of report it expects. You can read NIST's own answers in the NIST Cybersecurity Framework FAQs.

What should we ask for in a quote for PR.DS-02 work?

A useful quote traces every line item to a written scope. Ask for:

the list of systems, data flows and Implementation Examples in scope
the deliverables for each item, such as configuration baselines, certificate inventories and runbooks
which costs are one-time (design, build, testing, documentation) and which recur (renewals, key rotation, monitoring, upgrades)
which tools are open source and which, if any, require licenses you must buy
assumptions about staff availability and change windows
acceptance criteria and who signs them off
exclusions, including the independent assessment itself

Also ask whether ongoing support is a separate retainer. DeployOpen does not publish a price list, and a quote follows from the written scope.

How DeployOpen works on this

DeployOpen approaches PR.DS-02 Data in transit as a fixed-scope engagement inside your own infrastructure. We prepare the encryption, signing and outbound data controls and the evidence that shows them working, while your organization owns the controls and an independent auditor or assessor issues any report.

How we scope

Agree in writing which network paths, services, email and file sharing channels fall inside PR.DS-02 scope
Map where sensitive data leaves production and which non-production environments must be kept free of live data
List the systems that need encrypted or signed communications and the certificates and keys they depend on

How we build

Configure TLS for internal workloads with cert-manager on Kubernetes or OpenShift, using the issuers your environment requires
Set up an internal certificate authority with FreeIPA where that fits your identity architecture
Deploy OpenBao transit encryption and signing with versioned keys and a documented rotation procedure

How we hand over

Deliver configuration records, key and certificate inventories and rotation runbooks for your review and sign-off
Document test results showing encrypted channels, blocked outbound transfers and separated non-production data
Provide an evidence index mapping each artifact to the PR.DS-02 Subcategory and the controls your assessor will test

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Confirm with your auditor which evidence formats and sampling periods they expect before final delivery
Review certificate renewals, key rotations and configuration drift on the schedule agreed in your scope