Basis for PII transfer between jurisdictions (processor)

To meet the ISO/IEC 27701 basis for PII transfer between jurisdictions (processor) requirement, you must tell each customer what legal mechanism supports any cross-border processing of their PII and notify them promptly before you change that mechanism or the relevant transfer pattern. Operationalize this through documented transfer mapping, contract language, and a customer notification workflow. ¹

Key takeaways:

• Maintain an accurate, customer-scoped map of international PII transfers and the “basis” you rely on for each transfer. ¹
• Put the transfer basis in customer-facing terms: contracts, DPA exhibits, and security/privacy documentation that customers can act on. ¹
• Treat transfer-basis changes as a notifiable change: trigger review, customer notice, and updated artifacts before production cutover. ¹

International PII transfers are rarely a single “yes/no” question. As a processor, you typically move or enable access to customer PII across borders through hosting regions, support access, engineering access, disaster recovery, subprocessors, and telemetry. ISO/IEC 27701 Clause 8.5.2 narrows the operational requirement to two things you can implement fast: (1) inform the customer of the basis for those international transfers, and (2) inform the customer of intended changes to that basis in a timely manner. ¹

This is a customer-trust requirement as much as a privacy one. Customers use your stated “basis” to complete their own transfer impact assessments, procurement reviews, and contract files. If you cannot explain where data goes, who can access it, and what mechanism you rely on, customers will treat you as high-risk and audits will stall.

The fastest path is to build a small set of durable artifacts: a transfer register (ground truth), a customer-facing transfer disclosure (contract exhibit or DPA annex), and a change-notice workflow tied to vendor/subprocessor and infrastructure change management. ¹

Regulatory text

Requirement (processor): “The organization acting as PII processor shall inform the customer in a timely manner of the basis for international PII transfers and of any intended changes in this regard.” ¹

Operator translation (what you must do):

1. Identify international transfers that occur while you process customer PII. This includes transfers caused by your own systems and by subprocessors you engage. ¹
2. For each transfer pattern, document the “basis” you rely on (the legal or contractual mechanism that permits the cross-border transfer, as applicable to the customer relationship). ¹
3. Disclose that basis to the customer in a form they can retain (contract terms, DPA annex, or formal written notice). ¹
4. Notify customers of intended changes before the change takes effect, through an established communications path and with updated artifacts. ¹

Plain-English interpretation

As a processor, you do not get to treat cross-border processing as an internal implementation detail. Your customer needs to know:

• Where their PII can be processed or accessed from (jurisdictions/regions).
• Why you believe that cross-border flow is permitted (the transfer basis).
• What will change if you add a new country/region, switch hosting, add a subprocessor in a different jurisdiction, or change the transfer mechanism you rely on. ¹

“Timely manner” is not defined in the provided ISO text; implement it as a documented internal standard that triggers notice early enough for customers to assess risk and, if needed, object or exit under contract. ¹

Who it applies to

Applies to: Any organization acting as a PII processor. ¹

Operational contexts where this shows up:

• SaaS platforms hosting customer data in multiple regions or using global CDNs.
• Managed services where analysts/support engineers access PII from different countries.
• Development and SRE practices with on-call access across borders.
• Subprocessor chains (cloud, ticketing, observability, email delivery) with non-local processing locations. ¹

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

Step 1: Build a transfer inventory (your “ground truth”)

Create a register that answers, for each product/service and customer data category:

• Origin jurisdiction(s) (where customers/users are).
• Processing locations and access locations (hosting region, backup region, support access countries).
• Subprocessors involved and their processing locations.
• Transfer “basis” you rely on for each cross-border flow. ¹

Practical tip: include “remote access” as a transfer scenario even if data stays in one data center. Auditors and customers often treat cross-border access as a cross-border transfer for due diligence purposes.

Step 2: Define what counts as a “basis” for your business

ISO requires disclosure of the basis, but does not prescribe which mechanisms to use. Implement a controlled list you can apply consistently, such as:

• Contractual transfer mechanism referenced in your customer agreement/DPA
• Customer instructions (where the customer selects a region and instructs you to process there)
• Other documented mechanism applicable to the customer relationship (kept in the contract file)

Keep the list short so Sales, Legal, Privacy, and Procurement can speak the same language to customers. ¹

Step 3: Put the disclosure in customer-facing artifacts

Customers need something durable. Common patterns:

• DPA annex/exhibit: “International Transfers” section listing (a) countries/regions, (b) categories of processing, (c) subprocessors, and (d) the transfer basis.
• Subprocessor page + notice mechanism: useful, but do not treat a web page alone as sufficient if your contract promises formal notice. Align to your contract.
• Security/privacy addendum: a structured disclosure that procurement can attach to the vendor file.

Make sure the disclosure is consistent across documents. One common failure is having the DPA say “EU only” while the subprocessor list includes global processing. ¹

Step 4: Implement a “change in transfer basis” trigger

Treat intended changes as a change-management event with privacy gates. Define triggers such as:

• Adding a new hosting region or moving primary processing to another jurisdiction
• Adding a new subprocessor that processes PII in a new jurisdiction
• Material change in support/access locations
• Changing the contractual mechanism you cite as the transfer basis ¹

Minimum workflow:

1. Change request opened (Engineering/Procurement).
2. Privacy/Legal review checks whether it changes transfer locations or basis.
3. If yes, update the transfer register and customer-facing disclosure.
4. Customer notice sent through the agreed channel.
5. Evidence captured (copy of notice, date sent, customer list).
6. Production cutover only after the notice step completes per your internal standard. ¹

Step 5: Operationalize through third-party and subprocessor management

Most cross-border movement comes from subprocessors. Add to your third-party intake:

• Required processing locations and any cross-border paths
• Contractual commitments on processing geography
• Notice obligations if the subprocessor changes locations or adds sub-subprocessors ¹

If you use Daydream to run third-party risk management, configure a required field set for “PII processing jurisdictions” and “international transfer basis disclosure impact,” then route changes into your customer notice workflow and contract exhibit updates. Keep it boring and repeatable.

Required evidence and artifacts to retain

Auditors typically want proof you (a) know the transfer basis, (b) told customers, and (c) can prove notice of changes. Retain:

• International transfer register (current + version history)
• Customer-facing disclosure artifacts (DPA annexes, contract clauses, security/privacy addenda)
• Subprocessor list with processing locations and effective dates
• Change-management records showing review and approvals for cross-border-impacting changes
• Notice records (template, distribution list logic, samples of notices, timestamps, and the updated exhibit/version) ¹

Common exam/audit questions and hangups

Expect these questions:

• “Show me all jurisdictions where customer PII is processed or can be accessed from, including support and engineering.”
• “For each transfer, what is the basis, and where is it disclosed to customers?”
• “How do you determine whether a new subprocessor introduces a new international transfer?”
• “Show an example of a change that triggered customer notice and the evidence it was sent.” ¹

Hangups that slow audits:

• No single source of truth for processing locations (Sales says one thing, Security says another).
• “Basis” described vaguely (“compliant with laws”) rather than as a specific contractual or documented mechanism tied to the customer relationship.
• No proof of notice timing, only an internal Slack message. ¹

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating hosting region as the only transfer.
   Fix: document access paths (support tools, remote admin, SOC monitoring) and subprocessors. ¹

2. Mistake: Publishing a subprocessor page without contract alignment.
   Fix: ensure your customer contracts define notice method and that your operational process matches it. ¹

3. Mistake: No defined trigger for “intended changes.”
   Fix: add a privacy gate in change management and procurement so changes cannot ship silently. ¹

4. Mistake: One-size-fits-all disclosures that ignore customer-specific configurations.
   Fix: if customers can select regions, disclose the set of possible jurisdictions and clarify which are customer-configurable vs processor-determined. ¹

Enforcement context and risk implications

No public enforcement cases were provided for this ISO requirement, but the risk is practical and immediate: failed procurement, delayed deals, audit findings, and contract disputes when cross-border processing differs from what customers were told. A weak transfer-basis disclosure also increases the chance that a customer will classify you as a high-risk third party and require enhanced due diligence, security exceptions, or regional hosting commitments. ¹

Practical 30/60/90-day execution plan

First 30 days (Immediate)

• Assign an owner (Privacy/Legal with Security and Procurement support) for the transfer register and disclosures. ¹
• Draft the transfer register template and collect inputs from Cloud/Infrastructure, Support, and Procurement.
• Identify the customer-facing “system of record” document: DPA annex vs master services exhibit.
• Create a draft notice template for “intended changes in international transfers/basis.” ¹

By 60 days (Near-term)

• Complete the first publishable version of the transfer disclosure (countries/regions, subprocessors, basis). ¹
• Update standard DPAs/contracts to include the disclosure and notice method.
• Add intake questions and approval gates to third-party onboarding for processing jurisdictions.
• Train Support and Engineering change approvers on what triggers customer notice. ¹

By 90 days (Operationalize and prove)

• Run a tabletop test: simulate adding a new subprocessor in a new jurisdiction and execute the full workflow (register update, legal review, notice, evidence capture). ¹
• Implement ongoing monitoring: subprocessor change alerts, infrastructure region changes, and periodic register review tied to existing governance forums.
• Store evidence in a retrievable audit package so you can answer customer and auditor questions quickly. ¹

Frequently Asked Questions

What counts as an “international PII transfer” for a processor under this requirement?

Treat any processing or access that crosses jurisdictional boundaries as in scope, including subprocessor processing and remote support access. Your goal is to disclose where PII is processed or accessed and the basis you rely on for that cross-border activity. ¹

Where should we disclose the transfer basis to customers?

Put it in durable customer-facing artifacts that procurement can retain, typically a DPA annex/exhibit or contract attachment, and keep it consistent with your subprocessor disclosures. The requirement is to inform the customer, so the disclosure must be accessible and attributable. ¹

What does “timely manner” mean in practice?

ISO/IEC 27701 does not define a specific timeframe in the provided text, so you should define an internal standard and follow it consistently. The standard should provide notice early enough for customers to assess the change and take any actions their contract allows. ¹

Do we need to notify customers for every infrastructure change?

Notify customers when the change affects international transfer locations or the stated basis for those transfers, or when it introduces new cross-border access paths through subprocessors or support. Keep a written trigger definition so teams can apply it without guesswork. ¹

How do we prove we informed customers and provided notice of intended changes?

Keep versioned disclosures (DPA exhibits and subprocessor lists) plus evidence of notice distribution such as dated emails, customer portal announcements tied to accounts, and the approval record that shows the change was reviewed before rollout. Auditors will ask for both the content and the timestamped trail. ¹

Our customers can select their hosting region. What do we disclose?

Disclose the set of jurisdictions available, clarify what is customer-configurable versus processor-determined (like support access locations), and state the basis you rely on for any cross-border access that can still occur. This prevents a mismatch between “data residency” marketing and actual operational access. ¹

Footnotes

1. ISO/IEC 27701:2019 Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management