Safeguard 3.10: Encrypt Sensitive Data in Transit

Safeguard 3.10: encrypt sensitive data in transit requirement means you must ensure sensitive data is protected with strong encryption whenever it moves across networks, including internal traffic, internet traffic, and connections to third parties. Operationalize it by scoping “sensitive data,” enforcing approved encrypted protocols (for example, TLS), disabling plaintext alternatives, and retaining repeatable evidence that encryption is consistently in place. ¹

Key takeaways:

• Define “sensitive data” and map every in-scope data flow; encryption decisions are made per flow, not per system. ¹
• Enforce encrypted-in-transit standards (protocols, configurations, certificate management) and block plaintext paths by default. ¹
• Keep assessment-ready evidence: inventories, configuration baselines, scan results, and exception approvals tied to specific flows. ¹

Encrypting data in transit is a control you can’t “policy” into existence. Examiners and internal auditors will look for proof that sensitive data is actually traveling over encrypted channels and that plaintext pathways are either removed or tightly exceptioned. Safeguard 3.10 is straightforward in concept, but teams stumble on scope (what counts as “sensitive”), coverage (which paths are in scope), and evidence (how you prove encryption is consistently enforced). ¹

For a CCO or GRC lead, the fastest path is to treat this as a data-flow control: identify where sensitive data moves, choose approved transport protections for each path, enforce them in configuration and network controls, then implement recurring verification. This also has third-party risk implications because many “in transit” paths cross trust boundaries: APIs, SaaS admin consoles, SFTP exchanges, EDI, VPNs, and remote access tooling. Your program needs a clear standard for encryption, a mechanism to block noncompliant connections, and a pragmatic exception workflow for legacy constraints. ¹

Requirement summary (plain-English)

What Safeguard 3.10 requires: Sensitive data must be encrypted whenever it is transmitted over a network so that interception does not expose the content. In practice, you must (1) identify sensitive data transmissions, (2) enforce encrypted transport protocols and configurations, (3) prevent fallback to plaintext, and (4) retain evidence that the control operates consistently. ¹

How auditors interpret “in transit”: Any movement of data between endpoints or services, including:

• User to application (browser to web app)
• Service to service (microservices, message buses, internal APIs)
• Admin access (SSH/RDP alternatives, management planes)
• File transfer (batch exports/imports)
• Connections to third parties (vendors, processors, SaaS) ¹

Regulatory text

CIS Controls v8 expresses this expectation as: “CIS Controls v8 safeguard 3.10 implementation expectation (Encrypt Sensitive Data in Transit).” ¹

Operator translation: You need an enforceable, testable standard that ensures sensitive data is not sent in cleartext, plus recurring validation and evidence capture so you can prove coverage during an assessment. ¹

Who it applies to (entity + operational context)

This safeguard applies broadly to enterprises and technology organizations implementing CIS Controls v8, especially where:

• Sensitive data traverses corporate networks, cloud networks, or the public internet
• Applications integrate via APIs or data pipelines
• Remote administration exists for servers, network devices, or cloud consoles
• Third parties exchange files or access systems ¹

You should treat these as in scope by default:

• Production environments and production data feeds
• Identity and authentication traffic (because credentials and tokens are sensitive)
• Backups and replication across network links
• Vendor/third-party connectivity into your environment ¹

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

Step 1: Define “sensitive data” for 3.10 and align it to your data classification

Write a short, operational definition that engineering can apply. Keep it concrete, tied to examples:

• Regulated data types (for example, personal data, financial data, health data) if applicable to your business
• Authentication secrets: passwords, API keys, private keys, session tokens
• Security telemetry that could aid an attacker (select logs, incident artifacts)
• Proprietary data that would cause material harm if intercepted ¹

Deliverable: “Sensitive Data in Transit Standard” with a one-page scope statement and examples.

Step 2: Inventory and map data flows that carry sensitive data

You can’t enforce encryption consistently if you don’t know where sensitive data moves.

Minimum viable data-flow inventory:

• Source system/service
• Destination system/service (including third parties)
• Transport method/protocol (HTTPS, gRPC, SMTP, SFTP, database replication, message bus)
• Network path (internal VPC/VNet, WAN, internet)
• Data classification transmitted
• Current encryption status and config owner ¹

Practical method: Start with your highest-risk pathways: external ingress/egress, admin access, and batch exports to third parties. Then fill in internal east-west traffic.

Step 3: Set approved encryption methods (protocols + minimum configuration)

Safeguard 3.10 is satisfied by enforceable, modern encrypted transport with secure configuration.

Define an “approved” list for your environment, such as:

• TLS-protected application traffic (HTTPS, TLS for APIs)
• SSH/SFTP for administrative and file transfer use cases
• VPN or private connectivity with encryption for network links where appropriate ¹

Also define “not approved” examples to eliminate ambiguity:

• Plain HTTP
• Telnet
• FTP
• Unencrypted SMTP submission between systems where sensitive content is present (unless you have explicit compensating controls documented) ¹

CCO/GRC note: Don’t over-specify crypto algorithms in governance if your technical team already maintains a security baseline. Require “approved secure configurations” and point to the baseline document that engineering updates.

Step 4: Enforce encryption technically (don’t rely on user choice)

Common enforcement points:

• Load balancers / reverse proxies: redirect HTTP to HTTPS; deny plaintext listeners; enforce modern TLS configuration.
• Service mesh / internal gateways: require mTLS or TLS between services where sensitive data moves.
• Network controls: block known plaintext ports at boundaries; restrict admin protocols; restrict egress to approved endpoints.
• Email gateways and file transfer platforms: require TLS for transfer, or use managed file exchange with encryption in transit. ¹

Third-party connectivity: Contract language helps, but you still need technical controls and validation. Require encrypted channels for data exchange methods (API, SFTP, private link), and verify with tests or configuration evidence.

Step 5: Implement certificate and key management for in-transit encryption

Encryption in transit fails operationally when certificates expire, private keys are mishandled, or teams bypass validation.

Minimum operational requirements:

• Certificate inventory (where certs are deployed, owner, renewal method)
• Renewal process (automated where possible)
• Secure storage for private keys and secrets
• Rules for certificate validation (avoid disabling verification in clients) ¹

Step 6: Create an exception process for legacy constraints (and make it painful by design)

You will find legacy integrations that can’t support encryption. Handle them with a controlled exception:

• Business justification
• Compensating controls (for example, isolated network segments, strict allowlists, short-lived data, additional monitoring)
• Time-bound remediation plan
• Risk acceptance approval (security + business owner; add legal/privacy where relevant) ¹

Step 7: Validate continuously and capture recurring evidence

You need repeatable checks that confirm encryption stays enabled as systems change:

• Configuration audits (load balancers, web servers, API gateways)
• Port/protocol scanning to detect plaintext services
• Targeted testing of critical paths (external endpoints, third-party transfers)
• Change management hooks: encryption requirements embedded in architecture reviews and deployment pipelines ¹

Daydream fit (where it earns its keep): Use Daydream to map Safeguard 3.10 to your documented control operation and schedule recurring evidence collection, so each quarter you can produce the same artifact set without scrambling. ¹

Required evidence and artifacts to retain

Store evidence in a way that ties back to specific in-scope flows and systems.

Core artifacts (assessment-ready):

• Sensitive Data in Transit Standard (approved protocols, prohibited protocols, exception method) ¹
• Data-flow inventory for sensitive data transmissions, including third-party flows ¹
• Network and application configuration baselines (TLS enabled, plaintext disabled)
• Screenshots/exports/config dumps showing TLS settings on key systems (load balancers, gateways, servers)
• Certificate inventory and renewal/ownership records
• Results from scans or validation checks (protocol/port scans, endpoint tests)
• Exception register with approvals and remediation plans ¹

Common exam/audit questions and hangups

Expect these and prepare crisp, evidenced answers:

1. “How do you define sensitive data for in-transit encryption?”
   Provide your classification mapping and examples. Show how engineering decides quickly. ¹

2. “Show me all the ways sensitive data leaves your environment.”
   This is where the data-flow inventory matters. Include third-party exchanges. ¹

3. “How do you prevent plaintext fallback?”
   Auditors want to see blocks/denies, not guidance. Show listener configs, security group rules, and gateway policies. ¹

4. “How do you know encryption didn’t drift after changes?”
   Answer with recurring validation and change controls plus retained outputs. ¹

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Better approach
Encrypting only internet-facing traffic	Sensitive data often moves east-west inside cloud networks	Classify and encrypt internal service-to-service flows that carry sensitive data 1
Relying on a policy without technical enforcement	Users and systems fall back to plaintext under outage pressure	Deny plaintext at gateways, load balancers, and boundary firewalls; require approved protocols 1
Ignoring third-party transfers	Many breaches involve exposed integrations and exports	Treat third-party connections as first-class data flows; require encrypted transport and retain proof 1
Weak evidence	You “know” it’s encrypted but can’t prove it	Standardize recurring evidence capture and store it centrally 1
Exceptions that never die	Legacy becomes permanent	Time-bound exceptions with tracked remediation and executive risk acceptance 1

Enforcement context and risk implications

CIS Controls v8 is a security framework, not a regulator. Your risk is indirect but real: if you can’t show encryption in transit for sensitive data, you raise incident impact (interception, credential theft, session hijacking) and often fail due diligence reviews from customers and third parties that expect CIS-aligned controls. The most common control failure is not “no TLS exists,” but “coverage and proof are inconsistent across flows,” especially for internal integrations and vendor exchanges. ¹

Practical 30/60/90-day execution plan

First 30 days: Scope + standards + quick wins

• Publish the Sensitive Data in Transit Standard (approved/prohibited protocols, exception workflow). ¹
• Build an initial sensitive data-flow inventory focused on: external endpoints, admin access, and third-party exchanges. ¹
• Remediate obvious plaintext exposures (disable HTTP where HTTPS exists, remove FTP/Telnet where present) and document what changed.
• Stand up an exception register with required approvals and compensating control expectations. ¹

Next 60 days: Enforce + validate + evidence

• Implement technical enforcement at common choke points (reverse proxies, API gateways, load balancers).
• Establish certificate inventory ownership and renewal processes for in-scope endpoints.
• Deploy recurring validation (scans/tests) and start retaining outputs as evidence. ¹
• Update third-party onboarding and security reviews to require encrypted transfer methods for sensitive data. ¹

By 90 days: Coverage maturity + audit-ready package

• Expand the data-flow inventory to cover internal service-to-service flows where sensitive data moves.
• Integrate checks into change management (architecture review gates, CI/CD guardrails where feasible).
• Review exceptions and force decision points: remediate, replace, or formally accept risk with a plan. ¹
• Produce a single “3.10 evidence packet” (standard, inventory, enforcement configs, validation results, exceptions). Use Daydream to keep the mapping and recurring collection consistent release over release. ¹

Frequently Asked Questions

Does “in transit” include internal traffic inside a private cloud network?

Yes. Treat any network transmission of sensitive data as in scope, including east-west traffic between services, not only internet-facing endpoints. ¹

If we use a VPN, do we still need TLS on applications?

Often yes for sensitive data flows, because VPNs reduce exposure but don’t automatically fix endpoint identity, certificate validation, or misrouting. Decide per flow and document your standard and any exceptions. ¹

What counts as “evidence” that data is encrypted in transit?

Keep configuration proof (gateway/server TLS settings), validation results (scans/tests), and a data-flow inventory showing which paths carry sensitive data and how they are protected. Tie evidence to specific systems and owners. ¹

How should we handle third parties that can only support email-based file exchange?

Treat it as a high-friction exception: require encrypted transport where possible, limit data, add compensating controls, and set a remediation path to a managed encrypted transfer method. Document the approval and the plan. ¹

Do we need to encrypt all traffic, even if it’s not sensitive?

Safeguard 3.10 is scoped to sensitive data. Many organizations choose to expand encryption broadly for simplicity, but the requirement-level minimum is to cover sensitive data flows and prove enforcement. ¹

What’s the fastest way to get audit-ready for 3.10?

Produce a tight evidence packet: standard, sensitive data-flow inventory, enforcement configurations for key choke points, recurring validation outputs, and an exception register. Keep it current with recurring evidence capture. ¹

Footnotes

1. CIS Controls v8; CIS Controls Navigator v8