Identify basis for PII transfer between jurisdictions

To meet the “identify basis for PII transfer between jurisdictions” requirement, you must inventory every cross-border PII transfer and document the specific transfer mechanism (the “basis”) that permits it, then keep that mapping current as systems, third parties, and locations change. ISO/IEC 27701 expects written, reviewable evidence that each international transfer has a defined, justified basis. ¹

Key takeaways:

• You need a transfer-by-transfer register that ties data flows to a named legal basis, not a generic statement.
• The scope includes third parties, intra-group transfers, support access, and remote administration across borders.
• Audits fail when teams cannot prove where PII goes, why it goes there, and what document authorizes the transfer.

This requirement is operational, not theoretical: if your organization transfers PII across borders, you must be able to point to a documented basis for each transfer and show that the basis matches the transfer reality in production. ISO/IEC 27701 frames this as an identification and documentation obligation, which means your outcome must be concrete evidence an auditor can sample against actual flows. ¹

In practice, most organizations struggle with two things: (1) discovering all transfers (including “invisible” ones like admin access, log shipping, sub-processors, and incident response access), and (2) maintaining the mapping as cloud regions, vendor subprocessors, and corporate structures change. The fastest path is to treat cross-border transfers like a control plane: maintain a single system of record (a transfer register), connect it to your DPIA/PIA workflow and third-party intake, and require an explicit “basis” field before a new transfer can go live.

This page gives requirement-level guidance you can implement quickly: who is in scope, the step-by-step process, the artifacts to retain, common audit questions, and a phased execution plan you can run as a compliance program workstream.

Regulatory text

Requirement (verbatim): “The organization shall identify and document the relevant basis for transfers of PII between jurisdictions.” ¹

What the operator must do

You must:

1. Identify where PII moves between jurisdictions (country/region to country/region).
2. Determine the “basis” that permits each transfer (for example: adequacy decision, standard contractual clauses, binding corporate rules, explicit consent).
3. Document that basis in a durable, reviewable form tied to the transfer details (systems, parties, jurisdictions, data categories, purpose).
4. Keep it accurate over time as infrastructure, third parties, and processing change.

ISO/IEC 27701 does not prescribe a single acceptable basis because it is a global standard; it requires that you have a relevant basis and that it is documented. ¹

Plain-English interpretation

Any time personal data crosses a border, you need to know:

• From where to where it goes (jurisdictions).
• Who is involved (your entity, affiliates, third parties, sub-processors).
• What PII is transferred and for what purpose.
• Which transfer mechanism you rely on to make it lawful/allowed under your obligations.
• Where that mechanism is documented (contract, policy, consent record, corporate rule).

If you cannot answer those questions quickly for a sampled transfer, you are not meeting the requirement.

Who it applies to

Entity scope

This requirement applies to PII Controllers. ¹

Operational scope (what counts as a “transfer” in real life)

Treat these as in-scope cross-jurisdiction transfers when they involve PII:

• Cloud hosting or storage in a different country/region than the data originates.
• Third-party processing (SaaS, payroll, CRM, ticketing, call centers) where processing locations or support locations differ.
• Intra-group sharing (parent/subsidiary, shared services, global HR).
• Remote access and administration (engineers, SREs, customer support) from another jurisdiction.
• Backups, DR, and log telemetry shipped to a different region.
• Incident response / eDiscovery access by external counsel or forensics teams outside the originating jurisdiction.

A common hangup: teams track “data residency” for production but miss that support tools and subprocessors can create separate transfers.

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

Step 1: Build a definitive cross-border transfer inventory (the “transfer register”)

Create a register with one row per transfer pathway. At minimum, capture:

• Transfer ID (stable identifier)
• Exporter (entity/system sending PII)
• Importer (entity/third party receiving PII)
• Origin jurisdiction and destination jurisdiction
• Data subjects (customers, employees, users)
• PII categories (contact data, identifiers, HR data, etc.)
• Purpose (support, billing, fraud, analytics)
• Transfer channel (API, SFTP, admin console access, replication)
• Onward transfers (sub-processors, affiliates)
• Owner (business + technical)
• Basis (selectable value, see Step 3)
• Evidence pointer (contract clause ID, consent record location, policy reference)

Implementation tip: start with your high-signal sources—vendor inventory, cloud account region settings, identity provider access logs, and data maps—then fill gaps through interviews with IT, Security, HR, Customer Support, and Procurement.

Step 2: Confirm the transfer is real (and not “assumed”)

For each entry, validate with at least one of:

• Architecture diagram or data flow diagram
• Cloud region configuration screenshot/export
• Contracted processing locations/subprocessor list
• Network flow evidence (where feasible)
• Support model documentation (follow-the-sun coverage, escalation paths)

This validation step prevents the most painful audit finding: a register that looks polished but is disconnected from reality.

Step 3: Define your “basis” taxonomy and decision logic

ISO/IEC 27701 expects a “relevant basis” for transfers and gives examples such as adequacy decisions, standard contractual clauses, binding corporate rules, or explicit consent. ¹

Operationalize that by creating:

• A controlled list of allowed bases your organization recognizes (based on your legal counsel’s positions).
• A short decision tree that forces consistency.

Example decision tree (customize with counsel):

1. Is the destination jurisdiction recognized internally as “adequate” for the relevant origin jurisdiction?
   • Yes: basis = “Adequacy decision / recognized adequacy mechanism”
2. If not adequate, do you have an executed contract addendum that governs the transfer?
   • Yes: basis = “Standard contractual clauses or equivalent contractual mechanism”
3. If intra-group: do you have approved internal rules for transfers?
   • Yes: basis = “Binding corporate rules / intra-group transfer framework”
4. If none of the above: do you rely on a data subject’s explicit consent or another narrow mechanism?
   • Yes: basis = “Explicit consent” (and document how captured, scoped, and stored)

Keep the logic short enough that procurement and privacy ops can apply it without rewriting legal memos.

Step 4: Attach the basis to each transfer and store the evidence pointer

For each transfer register row, populate:

• Selected basis
• Document location (contract repository link, consent record system, internal policy ID)
• Signatures / effective date where applicable
• Scope confirmation (what products/systems and which affiliates it covers)

If you cannot point to the evidence quickly, you do not have “documented” basis in an audit-ready sense.

Step 5: Put gating controls in front of new cross-border transfers

Add “basis for transfer” to:

• Third-party onboarding intake
• Security architecture review
• Data protection impact assessment / privacy review intake (where used)
• Change management for cloud region changes and new integrations

Minimum gating rule: no new cross-border PII transfer goes live without a register entry and an identified basis.

Step 6: Establish ongoing monitoring and review triggers

Instead of calendar-only reviews, use triggers:

• New sub-processor notice received
• New cloud region enabled
• M&A or new affiliate onboarding
• Support model change (new service desk geography)
• New product feature that exports data

This is where tools can help. Daydream can act as the workflow system to collect transfer details during intake, route to privacy/legal for basis selection, and maintain an auditable record tied to the third party and system entry.

Required evidence and artifacts to retain

Auditors usually sample. Keep artifacts in a form that supports sampling without heroics.

Core artifacts

• Cross-border PII Transfer Register (current version + change history)
• Data flow diagrams or system architecture docs that show cross-jurisdiction flows
• Contracts and addenda that implement the chosen basis (or references to where they’re stored)
• Third-party subprocessor lists and processing location statements (where applicable)
• Consent records and consent language (if consent is a basis)
• Intra-group transfer documentation (if used)
• Approval records showing who reviewed/approved the basis selection

Operational artifacts

• Intake tickets (third-party onboarding, privacy review, architecture review) with “basis” field completed
• Exception approvals when a transfer lacks the standard basis
• Evidence of review triggers being handled (e.g., subprocessor change review tickets)

Common exam/audit questions and hangups

Expect questions like:

• “Show me all jurisdictions where PII is stored or accessed from.”
• “For this third party, what is the basis for transfer, and where is it documented?”
• “How do you detect when a new cross-border transfer is introduced?”
• “Do subprocessors create onward transfers, and how are those covered?”
• “Who owns and updates the transfer register?”

Hangups that cause findings:

• Register lists “SCCs” but no executed addendum is traceable.
• Destination is recorded as “cloud” or “global” rather than an actual jurisdiction.
• Support access is not treated as a transfer.
• The basis is inconsistent across similar transfers because teams “picked something that sounded right.”

Frequent implementation mistakes and how to avoid them

1. Mistake: treating this as a one-time documentation exercise.
   Avoid it by tying updates to onboarding, change management, and subprocessor change processes.

2. Mistake: tracking only storage location, not access location.
   Fix it by requiring “admin/support access jurisdictions” in the register.

3. Mistake: no defined basis taxonomy.
   Fix it with a controlled dropdown list and a one-page decision tree approved by privacy counsel.

4. Mistake: “basis” stored in emails or chat.
   Fix it by putting it in a system of record (GRC tool, ticketing workflow, or Daydream workflow) with evidence links.

5. Mistake: ignoring onward transfers.
   Fix it by capturing subprocessors and their processing jurisdictions where relevant, then linking them to the same basis approach.

Enforcement context and risk implications

No public enforcement cases were provided for citation here, so treat risk framing as programmatic: if you cannot show the basis per transfer, you create exposure across privacy, contractual, and customer assurance channels. The immediate business impacts tend to show up as failed customer due diligence, delayed procurement, blocked go-lives, and audit nonconformities against ISO/IEC 27701 expectations. ¹

Practical phased execution plan (30/60/90 style, without pretending it’s calendar-true)

Use phases to drive outcomes; adjust timing to your org size and complexity.

Phase 1: Immediate (stand up control plane)

• Appoint an owner (Privacy Ops or GRC) and a backup.
• Create the transfer register template and “basis” taxonomy aligned to counsel’s positions.
• Identify initial transfer sources: top third parties, primary cloud environments, HR/payroll, customer support stack.
• Define the gating requirement for new cross-border transfers in intake workflows.

Phase 2: Near-term (complete baseline mapping)

• Run workshops with IT/Security/Engineering and business owners to enumerate transfers.
• Validate each transfer with at least one technical or contractual artifact.
• Populate basis + evidence pointers for each register entry.
• Identify transfers with missing basis or missing documentation and open remediation work items.

Phase 3: Ongoing (make it self-maintaining)

• Embed basis capture into procurement and architecture review.
• Add trigger-based reviews (subprocessor change, region change, new integration).
• Report monthly to your privacy steering group: new transfers, remediations, exceptions.
• Prepare an audit packet: register export, sample evidence, and process description.

Frequently Asked Questions

Does “between jurisdictions” mean only cross-country, or do regions/counties/states matter too?

ISO/IEC 27701 uses “jurisdictions,” which you should interpret based on the legal regimes that apply to your organization and data subjects. Treat cross-country transfers as in-scope by default, and align any finer-grained jurisdiction rules with counsel and your compliance obligations. ¹

Are remote support and admin access considered a transfer?

If personnel in another jurisdiction can access PII, treat it as a cross-jurisdiction transfer for purposes of identification and documentation. Auditors commonly test this via support models, IAM logs, and third-party support terms.

What level of detail is “documented” enough?

“Documented” should mean you can show an auditor the transfer, the selected basis, and the supporting artifact quickly, without recreating evidence. A register row with a basis value and a working link to the executed contract addendum (or consent record location) usually meets that bar. ¹

How do we handle third parties that refuse to specify processing locations?

Record the gap as a risk and treat it as a due diligence and contracting issue, not a documentation “nice-to-have.” Escalate through procurement, require location and subprocessor transparency in contract terms, or decide to avoid the transfer.

We have multiple products and many integrations. Do we need one register per product?

Keep one enterprise register, but include fields for product/system and environment so you can filter by scope during audits and customer questionnaires. Multiple registers tend to diverge and create conflicting “sources of truth.”

Where does Daydream fit without turning this into a tool project?

Use Daydream as the workflow layer that forces basis selection during third-party onboarding and architecture reviews, stores evidence pointers, and generates an audit-ready export of cross-border transfers. That replaces spreadsheet sprawl and reduces rework during audits.

Footnotes

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