Country or region of PII processing

To meet the ISO/IEC 27701 “country or region of PII processing” requirement, you must identify, document, and keep current every country (and relevant international organizations) where personal data may be stored, accessed, or otherwise processed, and make that information available to customers. Operationally, this means maintaining a provable “PII location map” across your systems and third parties, and disclosing it through contract terms and customer-facing documentation.

Key takeaways:

• You need a complete, maintained list of potential PII transfer/processing locations, not a best-effort guess.
• “Processing location” includes storage, admin access, support access, backups, DR, and subprocessors.
• Make it customer-accessible through a standard disclosure (DPA exhibit, subprocessor page, or security pack) and keep evidence of change control.

“Country or region of PII processing” sounds like a privacy-policy line item. In audits, it becomes a control with teeth: prove you know where customer PII can go, including where your third parties and support teams can touch it. ISO/IEC 27701 Clause 8.5.1 expects specificity and documentation, plus transparency to customers. That drives two workstreams that often live in different teams: (1) technical and operational mapping of processing locations across your architecture and service delivery model, and (2) contractual/customer disclosure that stays aligned with reality.

For a Compliance Officer, CCO, or GRC lead, the fastest way to operationalize this requirement is to build a single authoritative “PII processing locations register,” backed by configuration evidence and third-party due diligence artifacts, then publish a controlled customer disclosure fed by that register. The hard part is scoping correctly: you are documenting where PII can potentially be transferred, not only where it is “intended” to be processed. That means you must include edge cases like support tooling, log pipelines, managed service provider access, and disaster recovery.

Regulatory text

ISO/IEC 27701 requires that: “The organization shall specify and document the countries and international organizations to which PII can potentially be transferred, and make this information available to customers.” ¹

Operator interpretation: you must (a) enumerate potential cross-border PII processing/transfer locations, (b) document them in a controlled artifact, and (c) publish them to customers in a reliable, maintained way. “Potentially” matters: if your architecture, access model, or third parties could route or expose PII to a location, that location belongs in scope.

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

You need to be able to answer, with evidence:

1. Where can customer PII be processed or accessed? Countries/regions for storage, compute, remote access, support, analytics, monitoring, backups, and DR.
2. Which third parties expand that footprint? Subprocessors, cloud providers, support tools, managed services, and consultants.
3. How do customers learn this? A customer-accessible disclosure that stays accurate as systems and third parties change.

This is a transparency control that also supports customers’ cross-border transfer assessments and internal approvals.

Who it applies to (entity and operational context)

Entity type: PII processors ². ¹

Operational contexts that trigger real work:

• Multi-region cloud deployments (primary + failover, regional services, global control planes).
• Follow-the-sun support or engineering access from multiple countries.
• Centralized logging/telemetry platforms that aggregate data globally.
• Use of subprocessors (ticketing, chat support, email delivery, analytics, monitoring, managed databases).
• M&A or inherited systems with unclear data residency.

If you process only de-identified data, you still need to validate whether PII appears in logs, support tickets, or exports; otherwise the “we don’t process PII” claim collapses under sampling.

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

Step 1: Define “PII processing location” for your program (and make it testable)

Write a short internal definition that audit can test. Include:

• Storage location (databases, object storage, backups, archives).
• Compute location (application/runtime where PII is transformed or queried).
• Access location (where admins/support can view or retrieve PII, including remote access).
• Transfer pathways (replication, ETL, exports, email, ticket attachments).
• Third-party processing (subprocessors and affiliated entities that handle PII).

Keep it aligned to “can potentially be transferred” language. ¹

Step 2: Build a system-by-system PII location map

Create a register that ties together:

• System name and purpose
• PII categories processed (high level)
• Environment (prod, staging, support)
• Hosting provider and region(s)
• Backup/DR regions
• Operational access countries (support, SRE, DBAs)
• Data flows to other systems/tools

Practical approach:

• Start from your data inventory and asset inventory.
• Add network egress destinations and integration list to catch exports and pipelines.
• Verify with evidence (see “Evidence” section) rather than relying on tribal knowledge.

Step 3: Enumerate third parties and subprocessors with their processing locations

For each third party that processes or can access PII, capture:

• Legal entity name
• Service provided and data touched
• Countries/regions where PII is processed/stored/accessed
• Any “global support” or “remote admin” locations that expand reach
• Contractual commitments relevant to location changes (notification, approval)

If you can’t get country-level specificity from a third party, document the limitation and the mitigation (for example: data minimization, tokenization before transfer, restricted fields, or disabling PII in the tool). ISO/IEC 27701 expects you to specify and document, so gaps should be treated as an exception with an owner and a plan. ¹

Step 4: Convert the register into customer-facing disclosure

You need a stable customer-facing output that can be referenced during procurement and contract negotiation. Common patterns:

• DPA exhibit listing processing locations and/or subprocessors with locations.
• Subprocessor page with countries/regions and a change log.
• Security/Privacy FAQ in your trust center or security pack.

Minimum standard for defensibility:

• It lists countries (and international organizations if applicable) where PII can be processed/transferred.
• It matches the authoritative internal register.
• It has a clear owner and update process so it stays current. ¹

Step 5: Put change control around location changes

Auditors will test whether the disclosure stays accurate through change. Implement:

• A trigger in your procurement/onboarding process: no third party goes live without confirmed locations recorded.
• A trigger in engineering change management: new region, new analytics pipeline, new support tool, or new DR design requires updating the register and customer disclosure.
• A periodic review cadence (set it in policy; frequency is your risk decision) and event-driven updates when architecture or third parties change.

Step 6: Prove operational alignment (support, incidents, and access)

Cross-border processing is often created by people, not servers. Validate:

• Where privileged support can be performed from (employment locations, contractor locations).
• Whether ticketing systems routinely contain PII attachments.
• Whether incident response involves transferring logs or database snapshots across borders.

If you allow “anywhere access,” your location list expands rapidly. Many teams narrow scope by limiting administrative access to approved countries and documenting the control (identity, VPN, conditional access, bastions).

Required evidence and artifacts to retain

Keep artifacts that prove both accuracy and maintenance:

Core artifacts

• PII Processing Locations Register (system + third party coverage, version-controlled)
• Data flow diagrams or integration maps covering PII pathways
• Subprocessor inventory with country/region fields
• Customer-facing disclosure (DPA exhibit, subprocessor page export, or trust documentation snapshot)

Supporting evidence (examples)

• Cloud configuration evidence showing region settings (screenshots/exports)
• Backup/DR configuration evidence (regions, replication settings)
• Access control evidence showing admin access restrictions by location (policy/config exports)
• Third-party due diligence responses or contract exhibits confirming processing locations
• Change tickets/approvals showing register updates after location-impacting changes

Auditors look for traceability: pick one disclosed country, trace it to a system/third party, then to config and contract evidence.

Common exam/audit questions and hangups

Expect questions like:

• “Show me the list of all countries where customer PII can be processed, including by subprocessors.”
• “How do you know this list is complete?”
• “What triggers an update to this disclosure?”
• “Do support personnel outside the primary hosting region have access to production PII?”
• “How do you ensure third parties don’t add processing locations without your knowledge?”

Hangups that slow teams down:

• Confusing data residency (where you intend to store) with processing footprint (where it can be accessed).
• Missing “hidden transfers” in logs, support tickets, monitoring, and data exports.
• Inconsistent disclosures across Sales security responses, DPAs, and trust pages.

Frequent implementation mistakes (and how to avoid them)

1. Listing only cloud hosting regions

   • Fix: include access countries, third-party tooling, backups, DR, and support workflows.

2. Publishing a static list that never changes

   • Fix: tie updates to procurement and engineering change control; keep a change log.

3. Treating “potentially transferred” as hypothetical

   • Fix: interpret “potentially” as “possible under current design or operating model,” then document constraints that make transfers impossible (for example, geo-fencing admin access).

4. Letting each team answer questionnaires differently

   • Fix: make the register the single source of truth and require Sales/Procurement/GRC to reference it.

5. No evidence behind third-party location claims

   • Fix: require contractual language or due diligence evidence that states locations, or document exceptions and mitigations.

Enforcement context and risk implications

No public enforcement sources were provided for this requirement, so this page does not cite specific cases. Practically, the risk is commercial and contractual as much as regulatory: inaccurate location disclosures can trigger customer audit findings, procurement rejection, contractual breach claims, and forced remediation under tight timelines. Treat this as a “trust control” that must stay synchronized with the real technical footprint.

Practical execution plan (30/60/90-day)

No fixed timeline is required by the ISO text; use phased execution that reaches accuracy quickly and then hardens into operations. ¹

First 30 days (Immediate: get to a defensible baseline)

• Name an owner (GRC or Privacy) and approvers (Security, Engineering, Procurement).
• Draft the definition and scope for “PII processing location.”
• Build the first version of the locations register for top systems and top third parties by PII volume.
• Publish an interim customer disclosure if needed (clearly versioned and controlled).

Days 31–60 (Near-term: completeness and evidence)

• Expand mapping to remaining systems and all subprocessors that can touch PII.
• Collect configuration and contract evidence for each listed country/region.
• Add change triggers to procurement and architecture review processes.
• Standardize questionnaire responses by pointing Sales to the register/disclosure.

Days 61–90 (Ongoing operations: keep it current)

• Implement periodic review and exception management for unknown/uncertain locations.
• Add monitoring for location-impacting changes (new regions, new integrations, new support tooling).
• Run an internal audit: sample a few systems and subprocessors, trace disclosure → register → evidence.
• If you use Daydream for third-party risk, configure required fields for processing locations and automate renewal prompts when a third party’s footprint changes.

Frequently Asked Questions

Do we have to list every country where our employees live?

Only if employees in those countries can access or process customer PII as part of service delivery. If access is technically blocked (and you can prove it), document the control and keep the country off the disclosure.

What counts as “potentially transferred”?

Treat it as “possible given your current architecture, configurations, contracts, and operating model.” If a transfer is theoretically possible but practically prevented by enforced controls, document the controls and your basis for exclusion.

Do backups and disaster recovery regions count?

Yes, if backups, replicas, or DR environments contain PII or can be restored into environments where PII is processed. Record both the storage region and the operational access model for restore activities.

How do we handle third parties that won’t disclose exact processing countries?

Record the gap as an exception, document your mitigation (data minimization, redaction, tokenization, restricted fields, or alternate providers), and set a contractual and renewal path to obtain the missing location detail.

Is a subprocessor page enough to satisfy “make this information available to customers”?

It can be, if it covers the relevant countries/regions and stays aligned to your internal register. Many teams also include locations in a DPA exhibit for contractual clarity.

Our cloud provider has a “global control plane.” Do we have to list those countries?

If the control plane or provider personnel can access content containing PII, it belongs in scope. If provider documentation and your configuration show the control plane does not process customer content, document that rationale and keep the evidence with your register.

Footnotes

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

2. ISO/IEC 27701 Clause 8.5.1