DAT-004 Encryption in Transit
Description
All data transmitted over any network, external or internal, including service-to-service traffic inside the production environment, is protected by an approved transport encryption protocol, with TLS 1.2 the minimum and TLS 1.3 preferred. Deprecated protocol versions and weak cipher suites are disabled on every endpoint. The encryption configuration is reviewed at defined intervals and updated when a protocol vulnerability is published. Public key certificates are issued under a documented certificate policy by approved certificate authorities or obtained from an approved provider, recorded in an inventory that carries each certificate's expiry date, renewed automatically before expiry and revoked on compromise. Trust stores the organisation manages contain only approved trust anchors. Where a certificate authenticates a party, the relying system constructs and verifies a certification path to an accepted trust anchor, checks certificate status and holds a local cache of revocation data.
Rationale
Network interception is a high-probability threat against any service reachable over a network. Transport encryption is the baseline every other data protection control assumes. The certificate half is where the outages come from: an expired certificate takes a service down as effectively as an attack. A certificate trusted only because the trust store was never curated defeats the encryption entirely. Automatic renewal removes the class of failure that depends on somebody remembering. The local revocation cache matters for availability as much as for security, because path validation that depends on reaching a network service fails when the network is the problem. DAT-003 and DAT-005 hold the cryptographic standards and key management, including protection of the private key; IAM-009 holds the mapping of an authenticated identity to an account.
Applicability (9 profiles)
164.312(e) reaches any electronic communications network, which since 2013 has been read to include internal service-to-service traffic. DAT-004 already states that scope, which is why it holds the full on all three transmission rows.
Framework Mappings (30)
| CEK-03 | Data Protection | full |
| DSP-10 | Sensitive Data Transfer | partial |
| I&S-07 | Migration to Hosted Environments | full |
| IPY-03 | Secure Interoperability and Portability Management | partial |
| CEK-03 | Data Protection | full |
| DSP-10 | Sensitive Data Transfer | partial |
| I&S-07 | Migration to Cloud Environments | full |
| IPY-03 | Secure Interoperability and Portability Management | partial |
| DORA-Art.30.2.c | Availability, authenticity, integrity and confidentiality of data | informative |
| EU-DA-Art.25.2.a.iv | Security of Data During Transfer and Retrieval | informative |
| GDPR-Art.32.1 | Technical and Organisational Security Measures | partial |
| GDPR-Art.5.1f | Integrity and Confidentiality (Security Principle) | informative |
| HIPAA-164.312.e.1 | Transmission Security | full |
| HIPAA-164.312.e.2.i | Integrity Controls | full |
| HIPAA-164.312.e.2.ii | Encryption | full |
| 5.14 | Information transfer | informative |
| 8.24 | Use of cryptography | informative |
| NIS2-Art.21.2.h | Use of Cryptography and Encryption | informative |
| NIS2-Art.21.2.j | Multi-Factor Authentication and Secured Communications | informative |
| NIS2-CIR-6.7 | Network Security | informative |
| NIS2-CIR-9 | Cryptography | partial |
| AC-17(2) | Remote Access | Protection of Confidentiality and Integrity Using Encryption | full |
| IA-5(2) | Authenticator Management | Public Key-based Authentication | partial |
| SC-13 | Cryptographic Protection | informative |
| SC-17 | Public Key Infrastructure Certificates | full |
| SC-23 | Session Authenticity | informative |
| SC-8 | Transmission Confidentiality and Integrity | full |
| SC-8(1) | Transmission Confidentiality and Integrity | Cryptographic Protection | full |
| ASI07 | Insecure Inter-Agent Communication | informative |
| CC6.7 | Transmission, Movement, and Removal of Information | partial |
Evidence (4)
Load balancer, API gateway and web server configuration demonstrating enforcement of TLS 1.2 or higher with weak protocol versions and cipher suites disabled.
Example: AWS ALB listener configuration export, nginx TLS configuration, or Qualys SSL Labs scan results (A rating) for all public-facing endpoints, showing TLS 1.0 and 1.1 disabled
Test: Run an SSL/TLS scan against all external endpoints (e.g. Qualys SSL Labs or testssl.sh) and review load balancer listener configurations. Verify: (1) TLS 1.0 and 1.1 are disabled on all endpoints, (2) minimum TLS 1.2 is enforced, (3) no weak cipher suites (RC4, 3DES, NULL) are enabled, (4) HTTP (port 80) redirects to HTTPS or is blocked.
Internal service mesh or network policy configuration showing that service-to-service communication within the cluster or VPC is encrypted in transit.
Example: Kubernetes Istio mTLS policy export or AWS VPC security group / service mesh configuration confirming mutual TLS is enforced for all east-west service communication in the production environment
Test: Review the service mesh or internal network encryption configuration. Verify: (1) mTLS (or equivalent internal encryption) is enforced in STRICT mode across all namespaces, (2) no services are exempted from internal transport encryption without documented justification, (3) configuration was last reviewed within 12 months.
Cryptographic standards policy or TLS configuration standard specifying approved protocols, minimum versions, and cipher suites for data in transit.
Example: Cryptographic Standards document or TLS Configuration Standard (version-controlled, approved within the last 12 months) referencing a named baseline such as NIST SP 800-52 or BSI TR-02102
Test: Request the cryptographic standards document. Verify: (1) approved protocol versions and cipher suites are explicitly listed; (2) deprecated protocols are explicitly prohibited; (3) a review or update trigger is defined for when protocol vulnerabilities are announced; (4) the document has been approved by a named owner.
Certificate inventory export listing every certificate in use with its issuing authority, expiry date, renewal mechanism and revocation status, together with the managed trust store contents.
Example: Certificate inventory export from the certificate management platform (2026-03-31), listing 214 certificates with issuer, subject, expiry, auto-renewal state and owning service, alongside the managed trust store manifest held in the platform configuration repository
Test: Export the certificate inventory and the contents of the trust stores the organisation manages. Verify: (1) every certificate in the inventory was issued by an authority the certificate policy approves, (2) each entry carries an expiry date and an automatic renewal mechanism, (3) no certificate in production use is past its expiry date, (4) the managed trust stores contain only the trust anchors the certificate policy approves, (5) certificates recorded as compromised have a revocation entry and are no longer accepted, (6) the relying configuration performs path validation with status checking and holds a local revocation cache.
Questions (3)
Is all data transmitted over networks, internal and external, protected by an approved transport encryption protocol?
TLS 1.3 is preferred. TLS 1.0 and 1.1 must be disabled. This applies to all public-facing endpoints and to service-to-service communication within the infrastructure.
What is the minimum TLS version enforced on external-facing endpoints?
TLS 1.2 is the minimum acceptable baseline. TLS 1.3 is strongly preferred. Any answer indicating TLS 1.1 or lower requires a remediation plan.
Which of the following are in place for the certificates and transport encryption configuration of your production endpoints?
Automatic renewal removes the commonest outage behind this control, an expired certificate nobody was watching. Scanning on each deployment is stronger than a scheduled scan; either meets the last item provided it also runs after a change to a load balancer, an API gateway or a certificate.