Geographical location of PII

ISO/IEC 27018 Annex A.12.1 requires a public cloud PII processor to specify and document every country where customer PII might be stored, and any known countries where PII may be processed by sub-contractors. To operationalize it, you need an authoritative data-location register tied to your architecture, subprocessors, and customer disclosures, plus change control to keep it current. ¹

Key takeaways:

• Build a single source of truth listing all possible PII storage countries and known sub-contractor processing countries.
• Make the list contract-ready and customer-facing (DPA, security addendum, trust center), not just an internal wiki page.
• Keep it accurate through mandatory triggers: new regions, new subprocessors, DR/failover changes, and support access model changes.

“Geographical location of PII” is a transparency and governance requirement, not a data localization mandate. ISO/IEC 27018 Annex A.12.1 is aimed at public cloud providers acting as PII processors: you must be able to tell customers which countries their PII might be stored in, and which countries are involved when sub-contractors process PII. ¹

For a CCO or GRC lead, the operational challenge is rarely “we don’t know our primary region.” The failure mode is uncontrolled sprawl: logs routed to a different geography, backups replicated cross-border, support tools exporting data, or a subprocessor’s operations footprint that is not tracked centrally. Auditors and enterprise customers will test this requirement by asking for a list, then probing whether it matches reality across production, DR, analytics, and human access paths.

This page gives requirement-level implementation guidance: what to document, how to derive it from real systems, how to package it for customer due diligence, and what evidence you should retain so you can answer questionnaires without re-investigating your own architecture each time.

Regulatory text

Requirement (verbatim): “The public cloud PII processor shall specify and document the countries in which PII might possibly be stored, including any known countries where PII may be processed by sub-contractors.” ¹

Plain-English interpretation

You must maintain a documented list of:

1. All countries where customer PII could be stored (not just “normally stored”), and
2. All known countries where PII could be processed by subcontractors (subprocessors and other third parties in your delivery chain).

“Stored” includes any persistent or semi-persistent copies that can exist as part of operating the service: databases, object storage, backups, replicas, snapshots, archives, and log retention systems if they contain PII. “Might possibly be stored” is the key phrase; it pulls in disaster recovery, failover, and optional features that customers can enable.

“Processed by sub-contractors” includes cases where a third party touches PII to provide the service (support tooling, managed detection/response with visibility into customer data, communications platforms, ticketing systems that may contain customer identifiers, managed databases, or external analytics processors).

Who it applies to

Entity scope

• Public cloud service providers acting as PII processors for customer data. ¹

Operational context where this bites

• Multi-region architectures (active-active, active-passive, read replicas).
• Centralized logging/observability platforms that default to a single geography.
• Backup/DR vendors, managed database services, and CDN/edge services.
• Support and operations models that allow cross-border access to production systems.
• M&A or rapid procurement where new subprocessors arrive faster than governance updates.

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

Step 1: Define “PII in scope” for your service

Create a short, explicit statement covering:

• The PII elements your service stores by design (account profiles, end-user identifiers, IP addresses, contact details).
• The PII elements that may appear incidentally (free-text fields, file uploads, logs, support tickets). This prevents teams from arguing that “logs aren’t PII” when they contain identifiers.

Output: PII data inventory summary scoped to your service offering.

Step 2: Map all storage locations that could contain PII

Work from architecture, not assumptions. For each system, capture:

• System name and purpose (prod DB, object store, search index, data warehouse, logging, backups).
• Whether it stores customer PII, and what type.
• The countries where it can reside under normal operation and under DR/failover.
• Whether customers can choose a region, and what “region” means in country terms.

A practical way to do this is a table you can export to auditors:

PII Location Register (minimum fields)

• Data store / service component
• PII types (high-level)
• Environment (prod, staging, DR, support)
• Countries where PII may be stored (possible, not just default)
• Replication/backup behavior that changes geography
• Owner (team)
• Customer control (fixed, customer-selectable, conditional)
• Notes / constraints

Operator tip: include staging and pre-production if they can contain production-like data or copies. If you rely on “no prod data in non-prod,” keep evidence (see artifacts section).

Step 3: Identify subprocessors and their processing geographies

Build (or refresh) a subprocessor register that includes:

• Subprocessor name and service provided.
• Whether the subprocessor can process PII (yes/no, with rationale).
• Known countries where the subprocessor processes PII (operations locations, support locations, processing locations as applicable).
• Data categories shared.
• Transfer mechanism and contractual controls (keep this factual; avoid legal conclusions).

This is where many teams fail ISO 27018 A.12.1: they list the subprocessor but do not track the countries involved in the subprocessor’s processing footprint.

Step 4: Create customer-facing disclosure that matches the register

The requirement is “specify and document.” In practice, customers will expect this documentation to be accessible and consistent across:

• DPA / data processing terms
• Security addendum
• Trust center / security documentation
• Subprocessor list page and notification process

Make one document the “system of record” (the PII Location Register), and publish a controlled extract. If you provide only “we store data in the EU” without naming countries, expect due diligence friction.

Step 5: Implement change control so the list stays true

Add mandatory triggers to your change management and procurement workflows:

• Launching a new region or moving DR to a different geography.
• Switching logging/monitoring vendors or changing retention architecture.
• Adding a new subprocessor or expanding a subprocessor’s support locations.
• Enabling engineering or support access from new countries.

Gate releases and procurement sign-off on updating:

• PII Location Register
• Customer disclosure text
• Subprocessor register and customer notifications (if your terms require them)

Step 6: Test your answer like an auditor would

Run a quarterly internal “residency reality check”:

• Pick one customer tenant and trace data paths (primary, backup, logs, support tickets).
• Confirm countries match your register.
• Capture evidence (screenshots/config exports) so you can prove it later.

If you need a workflow system to keep the register, subprocessors, and customer disclosures synchronized, Daydream is often a practical fit because it ties third-party records, subprocessor changes, and evidence collection into one reviewable package that GRC can export during due diligence.

Required evidence and artifacts to retain

Keep artifacts that prove both content (the list exists) and operational control (it stays updated):

1. PII Location Register (dated, version-controlled, approver captured).
2. Subprocessor register with “known processing countries” field completed.
3. Architecture evidence supporting geography claims:
   • Cloud region configuration exports
   • Backup/replication settings
   • Data residency controls configuration
4. Customer-facing disclosure copies (DPA/security addendum/trust center pages) with version history.
5. Change tickets showing updates when geography changed (region expansion, DR move, new subprocessor).
6. Non-prod data handling standard and evidence of enforcement if you claim non-prod is excluded.

Common exam/audit questions and hangups

Expect these questions, and pre-answer them in your documentation:

• “You say ‘may be stored in X.’ What technical event causes that?” (Failover, replication, support export, feature enablement.)
• “Do backups, snapshots, archives, and logs follow the same geography as primary storage?”
• “Which subprocessors can access PII, and from what countries?”
• “Is customer selection of region enforced technically, or is it a policy statement?”
• “How do you ensure the list stays current when engineering launches new regions?”
• “Do your support tools or ticket attachments contain PII, and where are they hosted?”

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Listing only ‘regions’ instead of countries.
   Fix: translate every region into explicit countries for storage, and document any multi-country scenarios.

2. Mistake: Ignoring observability and support systems.
   Fix: treat logging, APM, SIEM, ticketing, and CRM as in-scope if they can contain customer identifiers.

3. Mistake: Documenting “where we store” instead of “where we might store.”
   Fix: add DR/failover paths and optional product features that change data residency.

4. Mistake: Subprocessor list without country detail.
   Fix: add “known processing countries” as a required field before onboarding approval.

5. Mistake: One-time spreadsheet that goes stale.
   Fix: bind updates to change control and procurement gates; require GRC sign-off for geography-impacting changes.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog, so this page does not cite enforcement outcomes.

Operationally, the risk is still concrete:

• Customer contract risk: inaccurate location statements can breach DPAs and security addenda, and trigger termination rights or notification obligations.
• Cross-border transfer risk: customers rely on your country list to assess transfer mechanisms and internal policies; gaps slow deals and create escalation to legal.
• Incident response risk: during an incident, you may need to rapidly identify which jurisdictions are involved. If your location register is incomplete, response time and regulator/customer communications suffer.

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

Timelines below describe phases, not guaranteed calendar durations.

First 30 days (Immediate)

• Assign ownership: one accountable owner for the PII Location Register, and named technical owners per system.
• Produce a first-pass PII Location Register from current architecture docs and cloud console checks.
• Inventory all third parties/subprocessors that might touch PII; flag unknown processing countries.

By 60 days (Near-term)

• Reconcile the register against reality:
  • Validate backups/replication/logging geographies
  • Validate non-prod handling claims
• Publish controlled customer-facing disclosure that matches the register.
• Update procurement onboarding to require subprocessor processing countries before approval.

By 90 days (Operationalize)

• Add change-management triggers and approval steps for geography-impacting changes.
• Run an internal audit dry run: pick a tenant, trace data flows, and store evidence.
• Set a recurring review cadence tied to product release planning and subprocessor reviews.

Frequently Asked Questions

Do we have to guarantee a single country for PII storage?

No. ISO/IEC 27018 A.12.1 requires you to specify and document countries where PII might possibly be stored, not to restrict storage to one location. Your disclosure must match your actual architecture and failover model. ¹

If we say “EU,” is that sufficient?

Usually not for enterprise due diligence. The requirement is to document the countries where PII might be stored, so you should name countries rather than a political or economic bloc if the underlying storage footprint spans multiple countries. ¹

Do logs count as “PII stored” under this requirement?

If logs can contain identifiers linked to an individual, treat them as potentially in scope and document where those logs are stored. Most audit issues come from logging pipelines that route to a default geography outside the primary data region.

How detailed does the subprocessor country list need to be?

Record the known countries where PII may be processed by the subprocessor, then ensure the list can be traced to a contractual disclosure or due diligence artifact. If the subprocessor won’t provide country detail, document that gap as a risk and decide whether the relationship is acceptable. ¹

We use multiple cloud providers. Can we maintain one register?

Yes. Keep one authoritative PII Location Register and tag entries by provider and service component. Auditors care that the country list is complete and controlled, not how many platforms you run.

What’s the fastest way to answer customer questionnaires about “where data is stored”?

Maintain a customer-ready extract of your PII Location Register mapped to product modules and subprocessors, and keep it versioned. Tools like Daydream help by keeping third-party records, subprocessor details, and evidence in one place so you can respond consistently across deals.

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