Encryption of PII transmitted over public networks

Encrypt all PII before it crosses a public data-transmission network by enforcing strong, modern transport encryption (for example, TLS) on every channel where PII can leave your controlled environment. Operationalize ISO/IEC 27018 Annex A.11.6 by inventorying PII data flows, forcing encrypted-by-default protocols, blocking plaintext paths, and retaining testable evidence that encryption is consistently applied. ¹

Key takeaways:

• Map where PII traverses public networks, then eliminate or block any plaintext protocol or downgrade path.
• Make encryption enforceable: configuration baselines, automated checks, and hard technical controls beat policy-only statements.
• Keep audit-ready proof: network diagrams, configuration snapshots, test results, and exception approvals.

“Encryption of PII transmitted over public networks” is a requirement you either meet continuously or fail intermittently, usually without noticing until an incident or audit forces a reckoning. ISO/IEC 27018 Annex A.11.6 is direct: if PII traverses a public data-transmission network, it must be encrypted prior to transmission. ¹

For most cloud environments, “public network” includes any Internet path, any partner connection that rides the Internet, and any remote access path that is not fully private and controlled end-to-end. The operational challenge is that PII rarely moves in one “main” application flow. It also moves through APIs, logs, message queues, support tooling, batch exports, email notifications, third-party integrations, and administrator workflows.

This page translates the requirement into implementable controls a Compliance Officer, CCO, or GRC lead can drive: what to scope, what to mandate technically, how to handle exceptions, and what evidence auditors actually accept. You can use it as a checklist for engineering, security operations, procurement, and third-party risk.

Regulatory text

Text (verbatim): “PII that is transmitted over public data-transmission networks shall be encrypted prior to transmission.” ¹

Operator meaning: If PII can traverse the Internet (or any other public network), the organization must apply encryption in transit before the first packet leaves the sending system. In practice, you operationalize this by:

• Requiring encrypted transport protocols for all PII flows (human and machine).
• Preventing plaintext protocols and downgrade paths.
• Proving, with retained artifacts, that encryption is enforced and monitored.

Plain-English interpretation (what the requirement demands)

If you send PII across a public network, you must encrypt it. No “we trust the network,” no “it’s only internal,” and no “the vendor handles it” without verification. Encryption must cover the transmission path in a way that protects confidentiality and also resists tampering during transit, which is why modern cryptographic transport protocols are expected in real implementations. ¹

What counts as “PII” and “transmitted”

ISO/IEC 27018 is written for public cloud environments acting as PII processors, so interpret “PII” broadly: any data that identifies or can identify an individual, including identifiers in payloads, headers, URLs, tokens that map to identities, and files containing PII. “Transmitted” includes interactive traffic (web, API), batch transfers, replication, admin access, integrations, and any egress to third parties.

What counts as “public data-transmission networks”

Treat the following as “public” for scoping and control design:

• Internet-facing traffic (client-to-service, service-to-service over the Internet).
• Connections to third parties over the Internet (SaaS, payment processors, analytics, customer support platforms).
• Remote access where the path is not fully private (contractors, admins, support staff).
• Cross-cloud or cross-region paths that traverse public routing unless you have a controlled private link and can prove it.

If you are unsure whether a link is “public,” assume it is. That bias reduces exception handling later.

Who it applies to

Primary applicability: Cloud service providers that process PII on behalf of customers (PII processors), including SaaS, PaaS, and managed service providers. ¹

Operational contexts where this shows up immediately:

• Public web apps that collect or display PII (account portals, HR tools, patient/member portals).
• APIs carrying PII (mobile apps, partner APIs, internal microservices exposed via gateways).
• Data exports/imports (SFTP alternatives, object storage presigned URLs, file sharing links).
• Support and operations tooling (ticketing attachments, screen-sharing, remote shells).
• Third-party integrations (CRM syncing, marketing systems, identity verification providers).

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

1) Build a scoped inventory of PII-in-transit “channels”

Create a simple register that lists, for each PII flow:

• Source system and destination system (include third parties).
• Protocol and port (HTTPS, gRPC, SMTP, SFTP, WebSockets, database replication, etc.).
• Whether the path can traverse a public network.
• Authentication method (mTLS, OAuth, API keys).
• Owner (team) and system criticality.

Practical tip: start with the “usual suspects” (edge ingress, API gateway, load balancers, outbound proxies, email services, file transfer tooling), then expand by asking engineering for all integrations that touch customer identity data.

2) Set non-negotiable transport requirements for any PII flow over public networks

Write requirements that engineering can implement and auditors can test. Examples you can adopt as policy standards (keep them technology-neutral where possible):

• PII must only be transmitted over encrypted transport protocols approved by security.
• Certificate validation must be enforced (no “skip verification” in clients).
• Weak or plaintext protocols must be disabled at endpoints and blocked at egress.

Avoid vague phrasing like “encrypt where feasible.” ISO/IEC 27018 uses “shall.” ¹

3) Implement hard technical controls (not just documentation)

Prioritize controls that prevent drift:

Inbound (client → service):

• Enforce HTTPS on every endpoint that can receive PII.
• Redirect HTTP to HTTPS where safe, and block plaintext where redirection is not appropriate.
• Use managed TLS termination with controlled certificates and renewals.

Service-to-service (internal and partner traffic):

• Require TLS for any service call that can traverse public routing.
• For high-risk PII flows, consider mutual TLS to prevent client impersonation and reduce MITM risk.
• Standardize on a service mesh or gateway policy where possible, so encryption requirements are centralized.

Outbound (service → Internet / third party):

• Force outbound traffic through controlled egress (proxy, NAT with inspection, or a cloud egress control).
• Deny plaintext protocols at egress; allowlist required destinations and ports.
• For third parties receiving PII, contractually require encrypted transport and verify with technical testing.

File transfer patterns:

• Eliminate ad hoc file sending over email or “public links” without encryption controls.
• Prefer secure, authenticated transfer mechanisms that enforce encryption in transit.

4) Prove encryption is enforced with repeatable tests

Auditors will ask, “How do you know it’s encrypted?” Have an answer that is test-based:

• Run periodic scans or configuration checks that confirm only encrypted protocols are exposed for PII endpoints.
• Capture evidence of TLS configuration at the edge (load balancer or API gateway settings).
• Validate outbound clients enforce certificate verification (code review evidence, static analysis, or runtime configuration checks).

5) Create a tight exception process for legacy or constrained systems

You will find at least one legacy integration that “can’t do TLS.” Treat that as an exception with:

• Business justification and data classification of the PII involved.
• Compensating controls (for example, private dedicated connectivity that is demonstrably not public, or a secure tunneling layer that encrypts before transmission).
• An owner and a remediation plan to eliminate the exception.

Exceptions should be rare and time-bounded. Keep approvals and technical design evidence together.

6) Operational monitoring and response

Encryption can break silently through certificate expiration, misconfigurations, or library downgrades. Add:

• Certificate lifecycle monitoring (expiry alerts and ownership).
• Alerts on plaintext traffic attempts at egress or blocked port events.
• Change management gates for any network path or endpoint that carries PII.

7) Make it third-party ready

If a third party processes or receives PII from you, incorporate checks into due diligence:

• Ask for evidence they encrypt PII in transit over public networks.
• Confirm how they enforce it (configuration, gateway controls, monitoring).
• Validate your own integration settings (don’t assume the third party forces TLS if your client can be misconfigured).

Daydream can help you centralize third-party evidence collection, map PII data flows to specific integrations, and track encryption-in-transit exceptions with owners and remediation status, so you can answer audits without chasing screenshots across teams.

Required evidence and artifacts to retain

Keep artifacts that demonstrate both design and operating effectiveness:

Design evidence

• Network/data flow diagrams highlighting PII paths over public networks.
• Standards/policies for encryption in transit for PII (approved and versioned).
• Reference architectures for edge ingress, service-to-service, and outbound integrations.

Technical configuration evidence

• TLS endpoint configuration exports (load balancer/API gateway settings, supported protocol versions/cipher policy where your platform exposes it).
• Egress firewall/proxy rules showing plaintext protocols are blocked and required encrypted destinations are allowlisted.
• Client configuration standards proving certificate validation is required.

Testing and monitoring evidence

• Scan results or configuration compliance reports showing only encrypted endpoints handle PII.
• Logs/alerts evidencing detection of plaintext attempts and response workflows.
• Certificate monitoring outputs (inventory, owners, renewal status).

Exception artifacts

• Exception request, risk acceptance, compensating controls, and remediation plan.
• Re-test evidence when the exception closes.

Common exam/audit questions and hangups

Expect these and prepare crisp answers:

• “Show me all channels where PII crosses the Internet.” They want a complete inventory, not a single diagram.
• “How do you prevent someone from standing up an HTTP endpoint that returns PII?” They want preventive guardrails (CI/CD checks, gateway policies, egress blocks).
• “How do you verify third-party connections are encrypted?” They want evidence you tested and enforced configuration, not a contract clause alone.
• “What about emails, tickets, and logs?” They want proof you addressed operational leakage paths, not just product traffic.
• “Do you allow exceptions?” If yes, they will sample them. Make exceptions defensible and documented.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating ‘internal traffic’ as safe by default. Fix: scope by routing reality. If it can traverse public infrastructure, require encryption.
• Mistake: Depending on policy statements without enforceable controls. Fix: enforce at gateways, proxies, firewalls, and CI/CD.
• Mistake: Allowing TLS but skipping certificate validation in clients. Fix: secure client libraries and configuration baselines, plus code review checks.
• Mistake: Ignoring non-HTTP paths. Fix: include batch, file transfer, admin tooling, and third-party sync jobs in your flow inventory.
• Mistake: No evidence trail. Fix: define a standard evidence packet per PII flow (diagram + config + test result + owner).

Enforcement context and risk implications

No public enforcement sources were provided for this requirement, so don’t rely on case law narratives to justify urgency. The risk case is straightforward: if PII traverses a public network without encryption, interception and tampering become realistic threats, and incident response becomes harder because you may not be able to bound exposure reliably. The operational goal is to make “plaintext PII over public networks” technically difficult to achieve, and easy to detect if it happens. ¹

Practical execution plan (phased)

Immediate phase (stabilize and stop obvious gaps)

• Identify your highest-volume PII ingress and API endpoints; confirm encrypted transport is enforced.
• Block or restrict plaintext protocols at internet-facing edges and outbound egress where you can do so safely.
• Stand up a PII-in-transit inventory register and assign owners for each flow.

Near-term phase (make it systematic)

• Implement centralized enforcement: gateway/service mesh policies, egress proxy controls, and CI/CD checks that fail builds if plaintext endpoints are introduced for PII services.
• Formalize evidence collection: a standard packet per PII flow (diagram + config + test).
• Add certificate lifecycle ownership and monitoring.

Ongoing phase (reduce exceptions and prove control health)

• Drive down exceptions through modernization plans and integration redesign.
• Run recurring tests (scans/config checks) and track findings to closure.
• Expand third-party due diligence to require encryption-in-transit evidence and validate client configurations on your side.

Frequently Asked Questions

Does “encrypted prior to transmission” mean I must encrypt the payload, or is TLS enough?

The requirement is satisfied when PII is encrypted before it traverses the public network; transport encryption such as TLS is the common control pattern. Decide case-by-case if you also need payload encryption, but don’t treat it as a substitute for secure transport. ¹

What if the third party says they “support HTTPS,” but our integration sometimes falls back to HTTP?

“Support” is not enforcement. Configure your client to require encrypted transport and certificate validation, and block plaintext egress paths so fallback fails closed rather than silently downgrading.

Are private leased lines or direct connect links “public networks”?

Treat them as non-public only if you can demonstrate they are private end-to-end and do not traverse public routing. If you cannot prove that, apply encryption anyway to meet the “public network” condition conservatively. ¹

How do we handle PII in operational tooling like support tickets or chat systems?

Include those tools in your PII flow inventory and enforce encrypted access paths (web access, APIs, integrations). Also address exports and attachments, since those often bypass the “main app” controls.

What evidence is strongest during an ISO/IEC 27018 audit?

Auditors respond well to a complete flow inventory tied to concrete configurations (gateway/load balancer settings, egress rules) plus repeatable test results. Exception approvals and remediation tracking matter because auditors will sample edge cases. ¹

We encrypt external traffic, but what about service-to-service traffic inside our cloud?

If that traffic can traverse public networks (for example, over Internet routing between environments or to third parties), it falls in scope. Many teams standardize on TLS for service-to-service by default to avoid mis-scoping debates and future architecture changes.

Footnotes

1. ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors