What CIS Safeguard 3.10 encrypt sensitive data in transit asks for
Safeguard 3.10 requires that sensitive data be encrypted while it moves across networks. It sits in the Data asset class and the Protect security function, and it applies to Implementation Groups 2 and 3 only, so an IG1 enterprise does not need to measure it against the Safeguard. The risk it addresses is interception: when sensitive records travel between users, applications, databases, service providers and partners in clear text, anyone who can observe the network path can read or alter them. CIS names Transport Layer Security (TLS) and OpenSSH as example implementations. The Safeguard does not prescribe either one. It asks whether sensitive data in transit is protected, and the answer must be demonstrable for the flows that carry it.
The hard part is usually coverage, not the protocol choice. An enterprise that enforces HTTPS on its public website may still send sensitive data over internal API calls, database connections, file transfers, backup replication, message queues, email gateways or administrative sessions that were configured years ago and never inventoried. The assessment specification for this Safeguard measures coverage, and it lists Safeguards 3.2 (the data inventory) and 4.1 (the secure configuration process) as prerequisites because they produce the data the measurement needs. Before you claim coverage, confirm with your data owners which flows carry sensitive data, using the flow documentation from Safeguard 3.8 as a starting point, and check each one against the list. Ask your assessor which evidence format they expect for each flow.
Your preparation work is to build that flow list, then record for each flow the protocol, the minimum version or cipher policy, and where the configuration is enforced. Confirm with the owners of each system whether unencrypted fallback is blocked, not only preferred. Where you use the CIS Controls Navigator, check the mapped NIST CSF 2.0, NIST SP 800-53, ISO/IEC 27001:2022 and PCI DSS v4.0 requirements for this Safeguard, since the same flow evidence often answers several of them. Note that the Navigator mappings are CIS's, and that the Controls do not replace any regulatory or compliance scheme. Plan for the cost of this work as internal time for data owners and engineers, plus any external help you contract to build the inventory and configuration evidence.
Which data flows and systems fall under Safeguard 3.10 encrypt sensitive data in transit
Safeguard 3.10 only covers the data you have classed as sensitive, so the work starts with the 3.1 data management process and the 3.2 data inventory. The cards below name the scoping decisions that most change how many paths, services and third parties need encryption and evidence.
Defining sensitive data for transit
Safeguard 3.10 applies to sensitive data, so the scope depends on how your data management process defines sensitivity and which data types the 3.2 inventory records as sensitive. If the definition is broad, more flows fall in scope. Check that each sensitive data type maps to named systems and paths before you count encryption work. Ask whether a sensitivity label exists for each type, since the 3.7 classification scheme may not be in place yet.
Internal versus external network paths
Traffic that crosses an untrusted network, such as the internet, a partner link or a branch connection, carries the most exposure and usually needs encryption without exception. Traffic inside a single segment may be assessed differently under your documented policy. Map each sensitive flow to the network boundary it crosses. Expect the external paths to drive the first wave of certificate and protocol configuration work.
Service-to-service traffic
Application components, APIs, message queues and databases often exchange sensitive data over internal connections that no one documents as a data flow. These links are easy to miss because they never touch a user browser. Identify them through the 3.8 data flow documentation and the configuration of each service. Each service pair that carries sensitive data needs a protocol, a certificate source and a renewal owner.
Administrative access channels
Administrators who reach databases, hypervisors, storage consoles or sensitive applications create sensitive data in transit through their sessions, even when no business user is involved. Remote management paths often use legacy protocols or default settings. List each administrative channel that can read or export sensitive data, and confirm it uses an encrypted protocol such as OpenSSH or TLS. These channels are often assessed under Controls 4 and 6 as well.
Third parties receiving sensitive data
Data sent to service providers, payment processors, cloud platforms or partner organizations leaves your direct control. Your scope should include the paths you operate and the encryption requirements you place in contracts or onboarding. Confirm which provider endpoints accept only encrypted connections and which fall back to plaintext. Control 15 covers the contractual side, so align the two reviews.
Legacy and unmanaged endpoints
Older devices, embedded systems, scanners and printers may send sensitive data over protocols that cannot be upgraded easily. They can be the weakest link in an otherwise encrypted environment. Inventory them through your asset records and decide whether each is in scope, compensated or replaced. Document the decision for each device, since assessors will look for how exceptions were handled.
How an assessor tests encryption of sensitive data in transit
This table breaks down how the CIS Controls Assessment Specification approaches Safeguard 3.10, from its three measures and prerequisites to the evidence an assessor requests and the gaps they most often find. Read each row as a step in the test, and use the findings column to check your own flows before an assessor does.
| Assessment element | What the assessor looks for | Common finding |
|---|---|---|
| Measure 1: sensitive data flows in transit | Whether each sensitive data flow identified in the data inventory and data flow documentation is listed with its encryption status | Flows exist in production but are absent from the inventory, so they are never tested |
| Measure 2: encryption protocol in use | Whether each flow uses a current encrypted protocol such as TLS or an SSH-based channel, with settings that match the organization's own standard | Legacy protocol fallback is still enabled on an endpoint that otherwise uses TLS |
| Measure 3: internal and external coverage | Whether encryption applies to traffic inside the network, between internal services and to external parties, not only to internet-facing links | Unencrypted internal hops between application tiers or to database servers |
| Combined coverage metric | The share of identified sensitive data flows that meet all three measures, which the assessor uses to judge overall coverage | Coverage looks high because the denominator omits flows that were never inventoried |
| Prerequisite Safeguard 3.2 | A current data inventory that names sensitive data and where it moves, since it supplies the flow list the measures test against | Inventory covers stored data but not the paths data takes between systems |
| Prerequisite Safeguard 4.1 | A documented secure configuration process that sets protocol versions, cipher settings and certificate handling on each system | Configuration baselines are undocumented, so protocol settings drift between hosts |
| Evidence requested | Current inventory extracts, protocol and cipher configuration exports, certificate records and network or service diagrams showing flow paths | Screenshots of one host only, with no evidence covering the rest of the flows |
| Sampling approach (illustrative) | Assessors commonly select a sample of flows from the inventory and trace each one to configuration, so confirm the sampling method with the assessor | Sampled flows were chosen from a list that omitted service-to-service traffic |
How to implement encryption of sensitive data in transit step by step
This sequence takes Safeguard 3.10 from an inventory of what sensitive data moves and where, through TLS and SSH baselines, certificate and key lifecycle, boundary enforcement and coverage verification, with a named artifact closing each step.
Confirm the data inventory and configuration process
Start by checking that the data inventory (Safeguard 3.2) and the secure configuration process (Safeguard 4.1) exist and are current. The assessment specification treats both as prerequisites for measuring Safeguard 3.10, because they supply the data classifications and the list of assets the measurement needs. Your data owner and configuration owner sign off that both documents cover the systems in scope. The closing artifact is a dated inventory extract with sensitivity labels, plus the approved configuration process. If either is missing, pause here, since later steps depend on them.
Map sensitive data flows across networks
Using the inventory, trace every path where sensitive data crosses a network: user-facing applications, service-to-service calls, database connections, backups, file transfers, administrative sessions and flows to service providers. Record the source, destination, protocol and the network segments each flow crosses. Compare this map with the data flow documentation from Safeguard 3.8 so the two agree. The closing artifact is a flow register that lists every sensitive transit path and marks any unencrypted or unknown protocol for remediation.
Set TLS and SSH configuration baselines
Define the approved transport settings for each flow in the register. For web and API traffic this means TLS, and for administrative and file access it means OpenSSH, with CIS citing both as example implementations. Specify protocol versions, cipher suites, certificate requirements and the rule that legacy clear-text protocols are disabled for sensitive flows. Use your secure configuration process to apply these settings and check them with a configuration scanner or a benchmark-based tool. The closing artifact is a written baseline per protocol and a scan report showing which hosts meet it.
Issue and rotate certificates and keys
Set up how certificates and keys are issued, stored, renewed and revoked. Internally, an identity system with an integrated certificate authority such as FreeIPA's Dogtag-based CA can issue certificates to hosts and services. In Kubernetes or OpenShift, cert-manager can request certificates from configured issuers, store them in Kubernetes Secrets and renew them before expiry. Keys for application encryption can be managed with a secrets engine such as OpenBao's transit engine, which supports key rotation. Confirm with your own team which issuers are permitted. The closing artifact is a certificate and key register with owners, issuers, expiry dates and a tested rotation procedure.
Enforce encryption at network boundaries
Configure the points where traffic enters or leaves a segment, such as load balancers, reverse proxies, API gateways, database listeners and jump hosts, so they accept only the approved protocols for sensitive flows. Reject plaintext listeners on those paths and document any exception with an owner and a review date. Where an application cannot terminate TLS itself, document the compensating control. The closing artifact is a boundary configuration record that shows, for each sensitive flow, the enforcing component and the protocol it accepts.
Verify coverage against the flow register
Test each flow in the register from the outside, not only from configuration files. Capture the negotiated protocol and certificate for each path, confirm that clear-text fallbacks are refused, and check that certificates chain to a trusted authority and are not near expiry. Compare results with the three measures in the assessment specification for Safeguard 3.10, which combine into one coverage metric. Record exceptions and feed them into the remediation queue. The closing artifact is a coverage report with per-flow results, evidence of the test runs and the named reviewer who accepted them.
Record evidence and schedule recurring review
Package the outputs of the previous steps into an evidence set that an independent assessor can follow: the flow register, baselines, scan reports, certificate register, boundary records and coverage results. Set a recurring review and repeat the flow verification after material changes to applications, networks or providers. Where you need an assessor's view, your auditor or certification body issues any report, not your implementation partner. The closing artifact is a versioned evidence package with an owner and the date of the next review.
How TLS, OpenSSH and certificate authorities fit together
TLS protects application traffic only while every endpoint holds a certificate it trusts. When a browser, API client or service connects to an application, TLS negotiates an encrypted channel and confirms the server's identity through an X.509 certificate chained to a certificate authority (CA). The encryption itself is strong enough for Safeguard 3.10, but the trust decision behind it depends on the certificate. An expired, self-signed or unknown certificate either breaks the connection or pushes users toward a workaround that disables verification. Before assessing Safeguard 3.10, confirm which internal services, load balancers, message brokers and database listeners carry sensitive data, and which of them terminate TLS themselves.
OpenSSH covers the administrative path that TLS does not. Shell sessions, file transfers and tunnels used by administrators and automation carry configuration, credentials and sometimes regulated data, and OpenSSH is the example CIS gives for encrypting that traffic. Its trust model is different: hosts and users are usually recognized through keys rather than CA-issued certificates, unless the environment configures OpenSSH certificate authentication. Review sshd_config on in-scope hosts for protocol and cipher settings, and record where administrators keep their private keys, since a copied or shared key defeats the encryption as well as the access control.
Issuance and renewal decide whether encryption stays in force over time. A certificate lifecycle has an owner, a CA or issuer, a renewal trigger and a documented fallback if renewal fails. Tools such as FreeIPA, which includes an integrated Dogtag-based certificate authority, and cert-manager, which issues and renews TLS certificates for Kubernetes or OpenShift workloads from configured issuers, can automate much of that lifecycle. Confirm with each vendor which issuers, key types and renewal behavior your versions support, and test an expiry scenario in a non-production environment. Your evidence for the assessor should include the certificate inventory, issuer records, renewal logs and the process for revoking a compromised key, because a missing renewal is an encryption gap that appears without any change to the application.
Evidence that shows sensitive data is encrypted in transit
An assessor testing Safeguard 3.10 needs to see where sensitive data travels, which protocols and ciphers protect it, and who approved any exception. The cards below cover the artifacts that answer those questions, and each depends on the one before it: the data flow record defines what must be protected, the configuration baselines define how it is protected, and the scans and change records show that the baselines held.
Data flow documentation from Safeguard 3.8
This is the starting point for the measurement. The data flow record shows every path where sensitive data crosses a network, including links to service providers and external enterprises, and it tells the assessor which connections must be covered by TLS or SSH. Check that each flow lists its endpoints, protocol and data sensitivity, and that the record is re-reviewed whenever a new integration, API or file transfer is added. Without it, coverage cannot be measured against a known set of flows.
TLS and SSH configuration baselines
A baseline records the approved protocol versions, cipher suites and key exchange settings for each service that carries sensitive data, such as web applications, APIs, database connections and administrative SSH. Store the baseline as code or as a documented standard so that its version and approval date are visible. Confirm that the baseline names the configuration keys or files that enforce it, for example ssl_protocols in an nginx configuration or Ciphers and KexAlgorithms in sshd_config, so the assessor can compare the running system to the approved values.
Certificate inventory with issuer and expiry
Every TLS certificate on a sensitive data path should appear in an inventory with its subject, issuing authority, validity dates and the system that uses it. Expired or unknown certificates are a common cause of failed or unreliable encryption, and an inventory with expiry records shows the assessor that renewal is controlled rather than accidental. For Kubernetes workloads, automated issuance and renewal tools can export this record, while internal certificate authorities should keep their own issuance log. Confirm that private keys are stored in a managed location and not in shared repositories.
Scan output for protocol and cipher coverage
Scans show what is actually running, which matters more than what the baseline says should be running. Run protocol and cipher checks against each in-scope endpoint on a schedule, and retain the output with the date, target list and tool version. Look for deprecated protocol versions, weak ciphers and endpoints absent from the data flow record. Scan results that fail to list a service the data inventory says is in scope are a gap to resolve before the assessment, not after it.
Change records for encryption exceptions
Some systems cannot yet meet the baseline, for example a legacy integration that still depends on an older protocol. Each exception should carry a documented business reason, a risk owner, compensating controls, a review date and an expiry. Change records should also show when a baseline changed, who approved it and which systems were updated. Assessors look for exceptions that are time-limited and reviewed, because an open-ended exception usually indicates that the encryption requirement is not being enforced.
What meeting Safeguard 3.10 costs in money and effort
This table breaks down the cost components of meeting Safeguard 3.10, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to scope internal work against outside help and to frame what to ask for in a written quote. No price or duration is stated because none is supplied for this Safeguard, so confirm figures with each vendor and provider.
| Cost component | Who is paid or who bears the effort | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Protocol and tooling licenses | Software vendor or subscription provider | Recurring if commercial | Self-hosted open source such as OpenBao, FreeIPA and cert-manager removes license spend, though support contracts may still apply |
| Flow mapping and data inventory alignment | Internal staff or implementation partner | One-time, then periodic review | Number of data flows crossing networks and dependence on the Safeguard 3.2 data inventory and Safeguard 4.1 configuration process |
| Protocol configuration (TLS, OpenSSH) | Internal engineers or implementation partner | One-time per system, then change work | Count of services, legacy protocols that need retirement and the number of distinct platforms |
| Certificate lifecycle management | Internal platform team | Recurring | Certificate count, issuer model (public ACME, internal CA or Kubernetes-native issuers) and renewal automation |
| Evidence collection and upkeep | Internal compliance or security staff | Recurring, usually tied to review cycles | Whether configuration exports and certificate inventories are generated automatically or gathered by hand |
| External testing or review | Independent tester or assessor | Periodic | Scope of interfaces tested, number of endpoints and whether results feed a formal assessment |
| Assessor sampling and walkthroughs | Independent auditor or certification body | Per assessment cycle | Number of systems sampled, how well evidence is organized and how many exceptions are raised |
| Remediation of weak protocols or ciphers | Internal teams or implementation partner | One-time, then recurring as standards change | Legacy clients or devices that cannot negotiate current protocols and the lead time to replace them |
Who owns encryption in transit and what a partner can take on
Your organization owns Safeguard 3.10. Only you can decide which data counts as sensitive, which network paths carry it, which protocol versions and cipher suites are acceptable for your risk appetite, and whether any residual exposure is accepted. These are governance decisions, and they flow from the data management process and the data classification scheme under Control 3. A partner can draft options, but the accountable owner must approve them and sign off on risk acceptance.
- Classification and scope: Decide which data classes require encryption in transit, using the labels your data management process defines.
- Standards and exceptions: Approve the minimum TLS and SSH versions, the approved cipher policy and a documented exception process for legacy systems.
- Risk acceptance: Record who accepts any unencrypted or weakly protected path, for how long, and under what compensating controls.
- Operational ownership: Keep certificate, key and configuration changes under your change management, with named owners for each service.
- Ongoing review: Re-check flows and settings when systems, providers or data types change.
Before engaging anyone, confirm that a named executive owns the Safeguard and that the decisions above are written down somewhere an assessor can read.
An implementation partner can do the technical preparation that Safeguard 3.10 requires, inside your infrastructure, under a written scope. DeployOpen, for example, plans, implements, hardens and documents self-hosted open-source platforms in your own cloud accounts, data centers or air-gapped networks. Preparation does not transfer ownership. The partner builds and records; you approve and operate.
- Flow mapping: Map where sensitive data moves between services, users, providers and storage, so the data flow documentation and the data inventory agree.
- TLS and SSH configuration: Configure protocol versions, cipher suites and certificate chains on the in-scope services, and document the settings as configuration baselines.
- Certificate automation: Set up issuance and renewal for internal and external certificates, for example with an internal certificate authority such as the Dogtag-based one in FreeIPA or cert-manager in Kubernetes, so that expiry does not become an unmanaged risk.
- Evidence packs: Produce configuration exports, scan results, certificate inventories and change records that show coverage over time.
- Remediation support: Fix gaps found in testing, then re-verify them.
Ask the partner which of these items are in the written scope, who holds the administrative credentials after handover, and how the evidence will be retained.
The independent assessor tests whether Safeguard 3.10 is in place and reports on it. Depending on the context, this may be an external auditor, a certification body or a firm that CIS has accredited for Controls assessment work. Assessors form their own conclusions from evidence and their own testing. Their independence is the reason the report has value to customers, regulators and your board.
- Test design: The assessor samples in-scope systems and checks them against the measures in the CIS Controls Assessment Specification for Safeguard 3.10.
- Independent testing: Expect the assessor to run or observe its own checks, such as protocol scans of listed endpoints, rather than relying only on documents you supply.
- Reporting: Only the assessor issues the report, attestation or certificate. A partner cannot issue or co-sign these outputs.
- Line between preparation and assurance: A partner may help you understand the requirement and prepare evidence, but it should not write the assessor's conclusions, select the assessor's samples or pass test results off as independent findings.
- Conflict checks: Confirm the assessor has no role in designing the controls it will test.
Before the engagement, agree in writing who will provide which evidence, who the assessor's contact is, and which party is responsible for any findings.
Most organizations outsource the technical build and the evidence collection for Safeguard 3.10, and keep the decisions and the sign-off. The split usually follows the same lines as the three roles above, but the boundary between them is where most audit disputes start. Draw that boundary before work begins.
- Usually outsourced: Protocol and cipher configuration, certificate issuance and renewal automation, flow discovery workshops and evidence exports.
- Usually kept in-house: Classification of sensitive data, approval of the cryptographic standard, risk acceptance and final ownership of the keys and certificates.
- Usually independent: Testing and the opinion on whether the Safeguard is met.
- Watch for: Partners who offer to sign attestations, guarantee an audit result or act as the named control owner.
- Quote scope: Ask for a written list of deliverables that separates configuration work, evidence work and any advisory work, with a named owner for each.
If a partner's proposal does not show these lines clearly, ask for a revised scope before you sign.
Common gaps that fail encryption in transit reviews
Assessors reviewing Safeguard 3.10 usually start from the data, not the protocol. Most failed reviews trace back to a flow nobody wrote down, a network segment treated as safe by default, or a certificate that someone forgot to renew. The gaps below are ordered roughly by how early they appear in an assessment.
Sensitive flows missing from the inventory
A flow cannot be encrypted if nobody recorded it. Sensitive data often moves through exports, batch jobs, reporting tools and integration scripts that never reached the data inventory from Safeguard 3.2. The Assessment Specification lists that inventory as a prerequisite for measuring Safeguard 3.10, so a gap there weakens every later measure. Closing action: trace each sensitive data set to its destinations, add the missing flows to the inventory, and confirm each one has a protocol and encryption setting recorded.
Internal traffic assumed trusted
Teams often encrypt traffic that crosses the internet but leave service-to-service calls, database connections and admin sessions inside the data center in plain text. Safeguard 3.10 covers sensitive data as it crosses networks, and an internal network is still a network. Closing action: list internal paths that carry sensitive data, such as application to database and backup traffic, and require TLS or an equivalent protected channel on each one, or document a specific reason for an exception.
Protocol fallback left enabled
A service can require TLS and still accept older or weaker versions when a client asks for them. Assessors look for legacy protocol versions and weak cipher suites that remain configured, because a downgrade can expose the session even when the preferred path is encrypted. Closing action: test each endpoint with a scanner, disable deprecated protocol versions and weak ciphers, and keep the scan output as evidence of the current configuration.
Expired or hand-tracked certificates
Certificates that renew by hand tend to expire during an outage or after the person who tracked them leaves. An expired certificate either breaks the service or pushes teams to disable verification, and both outcomes fail the review. Closing action: inventory every certificate that protects sensitive data in transit, record its issuer and expiry, and automate issuance and renewal where the platform supports it. Keep alerts on upcoming expiry so the record stays current.
Third-party transfers without documented encryption
Data sent to processors, payment networks, file transfer partners and cloud services often leaves the organization's control at the network edge. Reviewers ask whether each external transfer uses an encrypted protocol, who holds the keys and where the setting is documented. Closing action: review the data flow records for external recipients, confirm the protocol and endpoint validation for each one in the contract or integration configuration, and record any transfer that relies on a manual or unencrypted method as a formal exception with an owner and a deadline.
Questions about Safeguard 3.10 cost, effort and scope
How much effort does Safeguard 3.10 take to do in-house?
The effort depends mostly on how many services carry sensitive data and how many of them already use TLS correctly. A team that already runs a current data inventory and a documented secure configuration process has a head start, because the CIS Controls Assessment Specification lists Safeguards 3.2 and 4.1 as prerequisites for measuring Safeguard 3.10. The in-house work usually falls into four parts: finding every path where sensitive data moves, setting a minimum protocol and cipher standard, configuring each endpoint and service to meet it, and keeping a record that shows coverage. Ask your team to inventory the flows first, because the unknown paths are where most of the effort goes. No effort figure is given here because none has been supplied for this Safeguard.
Do TLS and OpenSSH alone satisfy Safeguard 3.10?
No. TLS and OpenSSH are the example implementations CIS gives, but the Safeguard asks that sensitive data in transit be encrypted across the paths where it actually moves. Enabling TLS on a public website does not cover an internal database link, a message queue, a backup replication channel or a vendor API that carries the same records. Your assessor will expect you to show which data types travel over which paths, that each path uses encryption, and that the configuration is maintained. Treat the protocols as the tools and the data flow inventory as the proof of scope.
What does the work need from the client team?
The work needs owners who can answer three questions: what sensitive data the organization holds, where it travels, and which systems terminate those connections. Typically the data owner confirms classification, the network or platform team confirms where traffic crosses networks, and application owners confirm which services speak which protocols. Someone must also own certificate issuance, renewal and key custody, because expired or untracked certificates are a common source of gaps. Plan for time from these people during discovery and again when reviewing the results. Clarify these responsibilities in the written scope before work begins.
How long does it take to reach usable evidence?
The time to evidence depends on the drivers, not a fixed duration. The main drivers are the number of data flows in scope, whether sensitive data is already mapped in the data inventory, how many legacy systems support only older protocols and need replacement or a compensating control, and how quickly certificate and key ownership can be agreed. Organizations with a clean inventory and modern services usually move faster than those discovering flows for the first time. Ask any provider to break the timeline into discovery, configuration, testing and evidence collection, and to state which steps depend on your team's availability.
Will an auditor accept self-hosted open-source tooling as evidence?
An auditor or assessor evaluates the evidence and the control design, not the brand of software that produced it. Self-hosted tools can generate useful evidence when they record configuration, certificate issuance and renewal, and key rotation in a way that can be reviewed later. For example, cert-manager stores TLS certificates as Kubernetes Secrets and renews them before expiry, and OpenBao's transit secrets engine supports versioned keys with rotation. Your own records still have to show the flow inventory, the required protocol standard and proof of enforcement. Confirm with your assessor which artifacts they expect before you rely on any tool.
When is it worth bringing in an implementation partner?
A partner is worth considering when the data flows are numerous or poorly documented, when several platforms must be configured consistently, or when your team lacks capacity to run discovery and build the evidence trail alongside daily operations. DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure and prepares the systems and evidence an assessment will examine, but it does not issue audit reports or certifications. Work is usually fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing renewal, upgrades and testing can be covered by a retainer.
What should a quote for Safeguard 3.10 include?
A useful quote separates one-time work from recurring work. One-time work usually covers flow discovery, protocol standards, configuration of each in-scope service, certificate and key setup, and evidence design. Recurring work covers certificate renewal, key rotation, protocol review as standards change, and updating the flow inventory when systems are added. Ask the provider to list the in-scope systems, the data types covered, the assumptions about your team's time, which deliverables are documents and which are configurations, and who holds the certificate authority and keys after handover. Any price should follow directly from that written scope.
Which open-source tools can produce encryption in transit evidence
Assessors testing Safeguard 3.10 want proof that sensitive data in transit is encrypted and that the certificates and keys behind that encryption are issued, tracked and renewed under control. Three open-source components can produce much of that evidence in a self-hosted environment: OpenBao for key management, FreeIPA for certificate issuance and cert-manager for certificate lifecycle in Kubernetes or OpenShift. Each covers a different part of the chain, so the first decision is which parts your environment actually runs. Confirm each capability in your own deployment before you rely on it in an assessment.
OpenBao (MPL-2.0) provides a transit secrets engine that encrypts and decrypts application data without storing that data, and it supports versioned encryption keys with rotation. This helps where applications need a central key service for protecting sensitive payloads they send over the network, and the rotation history becomes evidence that keys are not static. FreeIPA (GPL-3.0-or-later) includes an integrated certificate authority based on Dogtag, which issues and manages the certificates that TLS endpoints and internal services present. Its issuance and revocation records can show which certificates were issued to which hosts. Ask your auditor which key and certificate records they expect to see, and confirm that your FreeIPA CA policy and audit logs are retained for the period they will sample.
cert-manager (Apache-2.0) creates TLS certificates for workloads in Kubernetes or OpenShift from issuers such as ACME (Let's Encrypt), a CA key pair, HashiCorp Vault, CyberArk or self-signed certificates. It stores them in Kubernetes Secrets and renews them before they expire, so expiry-based outages and stale certificates are less likely. Confirm which issuer your workloads use, because an ACME issuer depends on public DNS and internet reachability that many internal systems lack. Nextcloud (AGPL-3.0-only) server-side encryption is different: it protects file contents at rest on local and external storage, with keys kept on the server, and it does not encrypt file names or folder structure. It does not evidence encryption in transit, so pair it with TLS configuration evidence for the Nextcloud endpoints.
How DeployOpen prepares encryption in transit evidence
DeployOpen plans, implements and documents the transport encryption that Safeguard 3.10 asks for, inside the client's own infrastructure. We prepare the systems and evidence an assessor will examine, while the organization owns the control and an independent assessor or auditor issues any report.
How we scope
- Written scope lists which sensitive data flows, services and interfaces are in scope for encryption in transit.
- Scope records the data inventory and secure configuration inputs that Safeguard 3.10 measurement depends on.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We configure TLS and OpenSSH on in-scope services so sensitive traffic uses approved protocols and cipher settings.
- Certificate issuance and renewal are set up with FreeIPA or cert-manager, depending on the client's environment.
- Internal key and secret handling can be designed around OpenBao where the client needs centralized encryption services.
How we hand over
- Handover includes configuration records and a coverage view showing which sensitive data flows are encrypted in transit.
- Test results from checking protocol versions and certificate validity are documented for the assessor's review.
- Runbooks explain how the client maintains encryption settings, certificate renewal and exceptions after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial handover.
- Retainers can cover periodic re-checks of encrypted flows as new services and data flows are added.
- Clients should confirm with us which evidence is refreshed by them and which is refreshed under the retainer.
