Information transfer policies and procedures

“Information transfer policies and procedures” is a deceptively simple requirement that fails in real environments because PII moves through too many channels: APIs, web apps, admin portals, email, support tickets, exports, file shares, backups, observability tools, and transfers to third parties. ISO/IEC 27018 focuses on public cloud providers acting as PII processors, so auditors and customers expect you to show both governance (documented rules) and control evidence (technical enforcement).

Your goal is practical: (1) define the approved ways PII can be transmitted, (2) block or tightly control everything else, (3) encrypt PII in transit across networks you don’t fully control, and (4) keep evidence that the rules work day-to-day. This page gives requirement-level guidance you can hand to engineering, security operations, and legal/procurement without rewriting it into theory. It also highlights common hangups: “Is TLS enough?”, “What about internal service calls?”, and “How do we control employee-driven transfers like email and downloads?”

Regulatory text

ISO/IEC 27018:2019 Clause 13.2.1 states: “Formal transfer policies, procedures and controls shall be in place to protect the transfer of PII through the use of all types of communication facilities, including encryption of PII in transit.” ¹

Operator meaning: you must (a) formalize how PII may be transferred, (b) implement procedures people follow, and (c) implement controls that technically protect transfers across all communication facilities, with encryption applied to PII in transit. ¹

Plain-English interpretation (what the requirement is really asking)

You need a documented, enforceable “safe transfer” program for PII. It must cover:

• All transfer mechanisms (web, APIs, files, email, messaging, admin downloads, batch exports, third-party sharing, remote support).
• Protection during transmission (confidentiality and integrity expectations), with encryption in transit as a required control for PII transfers. ¹
• Operational follow-through: people know what to do, systems default to secure pathways, and you can demonstrate compliance through evidence.

If you can’t name the allowed transfer paths for PII, you don’t have an implementable policy. If you can’t show technical enforcement and proof, you have a paper program.

Who it applies to

Entity scope

• Cloud Service Providers acting as PII processors (the explicit applicability in ISO/IEC 27018). ¹

Operational scope (where auditors will look)

Apply it anywhere your organization transfers PII:

• Customer-facing services: browser-to-app, app-to-API, mobile-to-backend.
• Service-to-service traffic: microservices, queues, event streams, internal APIs.
• Admin and support operations: console access, database queries, exports, log pulls.
• Integrations and third parties: SSO/IdP, payments, CRM, ticketing, analytics, subprocessors.
• Human-driven channels: email, chat, file shares, removable media (even if “not allowed,” you must address it in policy and controls).

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

1) Map where PII is transferred (don’t start by writing a policy)

Create a PII Transfer Inventory that lists each transfer path and the approved mechanism. Minimum fields:

• Source system / destination system (including third parties)
• Data elements (PII categories)
• Transfer method (API, HTTPS download, SFTP, email, message queue, webhook)
• Network boundary crossed (internet, partner network, internal)
• Encryption-in-transit mechanism (e.g., TLS, VPN, SSH-based transfer)
• Owner (system and business)
• Logging/monitoring location

This inventory becomes your policy’s “scope of covered transfers” and your audit map.

2) Define the policy rules as “allow-list” statements

Your policy should read like enforceable requirements. Include:

• Approved channels for PII transfers (e.g., HTTPS/TLS APIs, managed file transfer, secure portals).
• Prohibited channels (e.g., personal email, consumer file sharing, plaintext protocols).
• Mandatory encryption-in-transit for PII transfers across communication facilities. ¹
• Authentication requirements for transfer endpoints (service identity, user identity, key management).
• Integrity protections expectations (for example: signed artifacts for batch transfers, or protocol-level integrity via TLS/SSH).
• Exceptions process (documented risk acceptance, compensating controls, time-bound approval).

Write it so engineering can convert each statement into a control (gateway config, IAM, DLP rule, MFT standard).

3) Publish procedures that match real workflows

Procedures are where programs fail. Cover at least these workflows:

• Sending PII to a third party: required due diligence inputs, approved method, contract/subprocessor checks, approval steps, and how to verify encryption-in-transit.
• Ad hoc exports for support: how to generate, where to store, how to transfer, who approves, when to delete.
• Customer-initiated transfers: secure upload/download portals, expiring links, authenticated sessions.
• Incident/forensics transfers: secure evidence transfer to legal counsel or responders, chain-of-custody controls.

Procedures must name the “system of record” for approvals and tickets so you can show evidence later.

4) Implement technical controls that enforce the rules

Focus on controls that reduce discretion:

• Standardize encrypted transport for PII: enforce HTTPS/TLS for web and API endpoints; use SSH-based protocols for file transfer; require encrypted tunnels where applicable. ¹
• Centralize egress control: route outbound transfers through controlled services (API gateways, proxies, managed file transfer, secure email gateways).
• Prevent “shadow transfer paths”: restrict direct database exposure; lock down public buckets; limit outbound network paths from sensitive environments.
• DLP and monitoring: detect attempted PII exfiltration via email, chat, uploads, or logs; alert and respond.
• Logging: retain evidence that transfer endpoints negotiate encrypted sessions and that access is attributable to identities.

5) Control third-party transfers explicitly

For each third party that receives PII:

• Document the transfer method and encryption expectations in the transfer inventory.
• Ensure the third party relationship reflects your transfer rules (for example, approved endpoints and secure protocols).
• Confirm operational ownership: who reviews transfer logs, who approves new data sharing, who can revoke access.

If you run a third-party risk program, connect this requirement to onboarding and change management. Daydream can help here by turning “PII transfer paths” into a concrete due diligence checklist and evidence request set for subprocessors, then tracking renewals and exceptions without losing audit traceability.

6) Test and prove it works

Do at least three types of validation:

• Configuration review (gateways, endpoints, file transfer services)
• Evidence sampling (recent transfers, support exports, third-party feeds)
• Negative testing (attempt disallowed transfers in a controlled way and confirm controls block or alert)

Record findings and remediation. Auditors often accept minor gaps if you show disciplined detection and closure.

Required evidence and artifacts to retain

Keep evidence in a form an auditor can replay:

• Information Transfer Policy (PII scope, encryption-in-transit requirement, approved/prohibited channels) ¹
• Information Transfer Procedures (export, third-party sharing, support workflows)
• PII Transfer Inventory / Data flow map (with owners and methods)
• Technical standards (secure transport standards, approved protocols/ciphers if you maintain them)
• System configurations (gateway settings, MFT configurations, secure email gateway policies, IAM constraints)
• Logs and monitoring outputs (samples that show encrypted sessions and accountable identities)
• Exception records (approvals, compensating controls, time limits, closure evidence)
• Third-party transfer records (approved integrations, subprocessor listings where relevant, tickets/approvals for new transfers)
• Training/communications that target teams who move data (support, engineering, sales ops)

Common exam/audit questions and hangups

Expect these prompts:

1. “Show me your policy. Does it explicitly require encryption for PII in transit?” ¹
2. “List all the ways PII leaves your environment.” They will test whether you included support tools, ticket attachments, and third-party SaaS.
3. “How do you prevent employees from emailing exports?” Policy alone won’t pass; show controls or monitoring.
4. “How do you govern ad hoc transfers?” If support can generate downloads, show approvals, short-lived links, and logging.
5. “Prove encryption in transit.” Provide config screenshots, endpoint settings, or test outputs that demonstrate encrypted protocols.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Policy only covers “network encryption” and ignores human channels.
  Fix: Treat email, chat, tickets, and downloads as “communication facilities” and explicitly address them with allowed paths and controls. ¹

• Mistake: “TLS is enabled” with no proof or enforcement.
  Fix: Enforce HTTPS-only, disable plaintext listeners, and retain evidence from configs and monitoring.

• Mistake: Exceptions become the normal path.
  Fix: Require time-bound approvals with accountable owners, and track closure like vulnerabilities.

• Mistake: Third-party transfers are treated as procurement paperwork.
  Fix: Record each transfer mechanism, validate encryption-in-transit, and monitor ongoing transfers.

• Mistake: Teams can create new transfer paths without review.
  Fix: Add “new PII transfer path” as a trigger in change management and architecture review.

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the available sources. Practically, weak transfer controls create predictable failure modes: accidental plaintext transfer, misdirected email, exposed download links, insecure integrations, and support-driven exports that escape retention controls. ISO/IEC 27018’s emphasis on encryption-in-transit and formal controls gives auditors a clear bar: you must show both documentation and consistent technical application. ¹

A practical execution plan (30/60/90)

First 30 days (stabilize and scope)

• Name an owner for the information transfer program (security or GRC) and a technical counterpart (platform/security engineering).
• Build the first version of the PII Transfer Inventory: start with customer-facing services, support tooling, and top third-party integrations.
• Draft the policy with clear allow/prohibit rules and an exceptions workflow, including encryption-in-transit requirements. ¹

By 60 days (standardize and enforce)

• Publish procedures for support exports, third-party transfers, and customer downloads.
• Implement or tighten core controls: HTTPS-only enforcement, secure file transfer standard, controlled egress paths, logging coverage.
• Stand up a lightweight approval workflow for any new PII transfer path (ticket template plus security review).

By 90 days (prove and iterate)

• Run a control test cycle: sample real transfers, validate encryption-in-transit evidence, confirm logging and access attribution.
• Reduce exceptions by replacing risky transfers with approved mechanisms (secure portal, MFT, controlled integration).
• Package your audit binder: policy, procedures, inventory, configs, logs, and exception register.

Frequently Asked Questions

Does this requirement mean every transfer must be encrypted, even internal traffic?

The text requires encryption of PII in transit and covers “all types of communication facilities.” ¹ Treat any network you don’t fully control, and any boundary crossing, as non-negotiable for encryption; for purely internal segments, document your decision and controls.

Is “TLS enabled” sufficient evidence?

Usually no. Auditors expect proof that plaintext paths are disabled and that real transfers negotiate encrypted sessions, supported by configs, monitoring, or test results.

How do we handle PII in support tickets and attachments?

Put it in scope as an information transfer channel. Define approved ways to share diagnostic data, block or monitor uploads of raw PII, and require secure alternatives for customer-provided files.

What about third parties that receive PII via API integrations?

Treat each integration as a transfer path with an owner, approved method, and evidence of encryption-in-transit. Keep approvals and change records whenever scopes expand or endpoints change.

We sometimes need to send customers exports. How can we do that safely?

Use authenticated portals or expiring links tied to an identity, log the download, and keep the export lifecycle (creation, access, deletion) documented in a procedure.

How can Daydream help without turning this into a paperwork exercise?

Use Daydream to track each third-party transfer path as a due diligence object with required evidence (encryption-in-transit confirmation, approved mechanisms, exceptions) and to maintain an audit-ready record across renewals and 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