Intended destination of PII

“Intended destination of PII” sounds like a policy statement, but auditors treat it as an operational promise: customers should not learn after the fact that their PII was moved to a new country or legal jurisdiction. In ISO/IEC 27018, this requirement is scoped to public cloud providers acting as PII processors, and it focuses on transparency before cross-jurisdiction transfer occurs.

For a Compliance Officer, CCO, or GRC lead, the practical work is straightforward but cross-functional. You must (1) know the jurisdictions where PII may be stored, processed, replicated, backed up, or accessed; (2) communicate those intended destinations to customers in a durable, pre-transfer way (contract, DPA, service description, trust notice); and (3) run change management so engineering cannot introduce a new jurisdiction without triggering updated customer notice.

Treat this requirement as a control over “data residency claims” and “international transfer transparency,” not as a one-time legal disclosure. The operational risk is customer harm (unexpected foreign legal exposure), failed procurement/security reviews, and misalignment between technical reality and contractual statements.

Regulatory text

Requirement (verbatim): “Where PII is to be transferred to another jurisdiction, the cloud service customer shall be informed in advance of the intended destination of the PII.” ¹

Operator interpretation: If your service might move a customer’s PII across jurisdictional boundaries (storage, processing, replication, backup, support access, DR), you must tell that customer ahead of time which jurisdiction(s) the PII is intended to go to. “Informed in advance” is the key test: disclosures after a transfer do not meet the requirement. ¹

Plain-English interpretation (what the requirement really means)

You need a customer-visible statement of where their PII will go, expressed in jurisdictions (typically countries, sometimes states/provinces depending on how you define “jurisdiction”), before you move it there. ¹

This is not limited to “primary hosting.” In practice, the destinations can include:

• Application hosting regions (primary and secondary)
• Replication targets
• Backup locations
• Disaster recovery/failover regions
• Log aggregation, analytics, and monitoring platforms that ingest identifiers
• Support tooling that can display or export customer PII
• Subprocessors that receive PII (even transiently)

Who it applies to (entity and operational context)

Applies to: Cloud Service Providers acting as PII processors for their customers. ¹

Operational triggers (where teams get caught):

• You introduce a new cloud region, availability zone strategy, or cross-region replication.
• You onboard or change a subprocessor (ticketing, CRM, analytics, fraud, email).
• You change your support model (new follow-the-sun location, new outsourced support).
• You implement DR that can fail over into a new country.
• You restructure accounts/tenants and move workloads for cost/performance.

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

1) Define “jurisdiction” for your service and disclosures

Make a concrete decision that engineering and legal can both enforce:

• Minimum viable definition: country-level destinations (e.g., “United States,” “Germany”).
• Document edge cases: territories, overseas regions, and cloud-provider “global” services.

Create a short internal standard: “When we say ‘destination,’ we mean any jurisdiction where customer PII is stored, processed, replicated, backed up, or routinely accessed for support.” Keep it aligned to actual architecture.

2) Build a defensible map of PII destinations

Create a PII data flow and location inventory that answers:

• Which systems handle PII (by product feature and data type)
• Where each system runs (cloud region(s), SaaS subprocessor location commitments)
• Which flows are cross-jurisdiction (including failover and backup)
• Which destinations are optional (customer-configurable) vs fixed (provider-controlled)

Practical approach:

• Start with your data classification/ROPA-like sources if you have them.
• Validate with architecture diagrams, IaC configs, and cloud account region restrictions.
• Require subprocessors to state processing/storage locations contractually or in their security docs.

3) Decide how you will “inform in advance”

Pick mechanisms customers actually see before transfer:

• Contract/DPA clause: lists allowed destinations (or a bounded set like “EEA + UK”).
• Service description / trust page: lists data hosting regions and subprocessors with locations.
• Order form / region selection: customer chooses region; you disclose any unavoidable ancillary destinations (e.g., global support tools).
• Subprocessor notice process: advance notice of new subprocessor and its jurisdiction(s).

A strong pattern is layered disclosure:

1. DPA sets the rule and the notification commitment.
2. Trust content provides the current list.
3. Change process controls updates and customer notices before go-live.

4) Put change control gates where engineers cannot bypass them

This control fails when a new destination appears without compliance noticing. Add gates to:

• Architecture review: any new region, replication, backup, or SaaS integration must declare jurisdictions.
• Procurement intake: no third party can process PII until location fields are completed and approved.
• Release/change management: launching in a new region requires confirmation that customer disclosure has been updated and notice timing met.

Make the gating question binary: “Does this introduce a new jurisdiction for customer PII?” If yes, stop until customer notice artifacts are ready.

5) Maintain customer-facing destination disclosures (and keep them accurate)

Operationalize a routine:

• Maintain a “Data Locations & Transfers” statement that lists intended destinations by product and feature.
• Maintain a subprocessor list with jurisdictions of processing/storage.
• Version control the page/doc; keep an archive for point-in-time audit.

If you offer customer-selected regions, state:

• What stays in-region (primary data)
• What may be processed elsewhere (support, billing, telemetry)
• What the customer can configure vs what they cannot

6) Handle exceptions explicitly

You will encounter cases where “intended destination” is conditional:

• DR/failover destinations that are rarely used
• Security incidents requiring specialized response access
• Temporary processing for troubleshooting

Treat these as “intended” if they are part of your planned operating model. Disclose them up front as conditional destinations (e.g., “may be transferred to X for disaster recovery”) if they can occur. ¹

Required evidence and artifacts to retain

Keep artifacts that prove (a) you knew the destinations, and (b) customers were informed before transfer:

Core evidence set

• Data flow diagrams for PII-bearing systems, with jurisdictions annotated
• Inventory of PII systems and their hosting regions (export from CMDB/IaC, plus written mapping)
• Subprocessor register with jurisdiction(s) of processing/storage
• Customer-facing disclosures (DPA language, service description, trust page snapshots)
• Change tickets/architecture approvals showing destination review for new regions/subprocessors
• Customer notification records for destination changes (email templates, send logs, portal notices)

Audit-friendly packaging tip: Maintain a “Point-in-time destination pack” per quarter (or per major change) that includes the disclosure as published and the internal mapping that supports it.

Common exam/audit questions and hangups

Expect these questions:

• “Show me where you disclose cross-jurisdiction destinations to customers before transfer.”
• “How do you ensure a new cloud region or subprocessor cannot be introduced without customer notice?”
• “Do backups, logs, and monitoring data contain PII? If so, where do they go?”
• “Is DR/failover cross-border? If yes, where is that disclosed?”
• “If a customer selects an EU region, can any PII still go to the US (support tooling, telemetry, billing)?”

Common hangup: teams answer with “our cloud provider is global.” Auditors want your intended destinations, in jurisdictions customers can evaluate.

Frequent implementation mistakes (and how to avoid them)

1. Publishing a region list that only covers primary application hosting.
   Fix: include replication, backups, support access, and subprocessors in the destination map.

2. Treating “customer can choose region” as the entire control.
   Fix: disclose non-configurable destinations and conditional DR locations.

3. Updating disclosures after the change is live.
   Fix: put a release gate in place; no production rollout to a new jurisdiction without published notice.

4. Relying on informal tribal knowledge of where data goes.
   Fix: tie destinations to concrete systems and cloud accounts, and keep the mapping current.

5. Subprocessor location blind spots.
   Fix: require location fields in the third-party intake, and block PII sharing until complete.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat risk analysis as an operational and contractual exposure assessment rather than a prediction of regulator actions.

Practical risk you can quantify internally:

• Sales friction: failed security reviews when your data destination story is inconsistent.
• Contractual breach: misalignment between DPA disclosures and actual transfers.
• Incident amplification: during a breach, investigators will ask where data was and where it moved; weak mapping slows response.

Practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Assign a single owner for “PII destination disclosures” (often Privacy/GRC with Security Architecture).
• Build a first-pass inventory of PII systems and current hosting/processing jurisdictions.
• Identify “known risky flows”: backups, observability/logging, support tooling, ticketing, CRM.
• Draft customer-facing disclosure language that matches reality today (even if conservative).

Days 31–60 (Operationalize and gate changes)

• Implement a standard question set in architecture review and procurement intake: “Does this add a new jurisdiction for PII?”
• Create a subprocessor register entry template that includes jurisdictions and data categories.
• Publish or update your customer-facing destination disclosure (DPA exhibit, trust page, or service description).
• Establish an internal “destination change” workflow: compliance review, customer notice prep, publish, then deploy.

Days 61–90 (Harden and make it auditable)

• Automate evidence collection where possible (cloud region configs, IaC outputs, CMDB exports).
• Add periodic reconciliation: compare actual deployed regions and third parties against the disclosure list.
• Train Engineering, SRE, and Procurement on the gate criteria and examples of cross-jurisdiction transfers.
• Create an audit packet: point-in-time disclosure snapshot, mapping, and last change approvals.

Where Daydream fits (practical, earned mention)

If you manage many third parties and subprocessors, the hardest part is keeping jurisdiction fields, notices, and change records consistent as tools and providers change. Daydream can act as the system of record for third-party due diligence fields (including processing jurisdictions), tie them to approval workflows, and keep an audit-ready trail that shows customers were informed before new destinations went live.

Frequently Asked Questions

What counts as “in advance” for informing customers of the intended destination?

Operationally, “in advance” means the customer has the destination disclosure before you initiate the transfer. Implement a release gate so the disclosure update and any required notice publish before production rollout.

Do we need to name specific countries, or can we say “global”?

This requirement is about jurisdictions customers can evaluate. “Global” is usually too vague to function as an intended destination; list specific jurisdictions or a bounded set that accurately reflects where PII may go. ¹

If customers choose a hosting region, do we still need to disclose other destinations?

Yes. Region selection covers primary hosting, but support, monitoring, backups, DR, and subprocessors can still create cross-jurisdiction transfers. Disclose what is fixed vs configurable so customers understand the full destination set.

Does “transfer to another jurisdiction” include remote access by support staff in another country?

Treat routine access that exposes PII as a cross-jurisdiction transfer risk for this control, and disclose the jurisdictions involved through your support model or tooling destinations. Align the statement to your actual operating model and systems. ¹

How do we handle disaster recovery regions that are only used during an outage?

If DR is part of your planned design and could move PII to another jurisdiction, include those destinations as conditional in your advance disclosure. Then your change control should ensure DR expansions trigger updated customer notice before enabling failover.

What evidence will an auditor accept that we informed customers?

Provide the published disclosure (DPA exhibit or trust page snapshot), version history, and the change record showing it was approved and published before the technical change. Pair it with the internal destination mapping that supports the disclosure.

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