Regional privacy overlays
Privacy law, unlike a security benchmark, is jurisdiction-dependent: the same record can carry different obligations depending on where the data subject lives and where the bytes physically reside. The regional privacy overlay is the layer of the report that answers the concrete technical question underneath every one of those obligations — where does regulated and personal data actually live, and what movement does your cloud configuration silently permit? It reconciles the data-residency and cross-border commitments an organization has made (to customers, regulators, and its own counsel) against what region selection, replication, backup, CDN, and logging settings really allow. On top of that placement picture it flags the sector rules (GLBA, HIPAA), the growing patchwork of US state comprehensive privacy statutes, and the cross-border regimes for Canadian and EU data that attach to the specific data types found. It is framed as current to 2026 and as practical guidance for planning and counsel review — not a legal determination and not legal advice.
Overview
What this check looks like in practice
On top of the security frameworks, most organizations answer to privacy law that depends on where they and their customers operate — US state privacy statutes, sector rules like GLBA and HIPAA, and cross-border regimes for organizations handling Canadian or EU data. The report surfaces where a finding intersects data-residency and privacy obligations so those requirements are visible alongside the security controls. This is practical guidance for planning, not legal advice, and it is framed as current to 2026 without asserting a compliance determination.
Why it matters
A residency or cross-border violation is not an abstract policy gap — it is usually visible directly in configuration, which is exactly where a data protection authority, auditor, or acquirer will look. Cloud defaults make this easy to get wrong: a geo-redundant backup, a multi-region storage bucket, a CDN edge cache, or a log-shipping pipeline can copy regulated data out of its intended jurisdiction without anyone approving a cross-border transfer, and with no documented mechanism (SCCs, EU-US Data Privacy Framework, adequacy) behind it. The consequence compounds because the same personal data can trigger a US state statute, a sector rule like GLBA or HIPAA, and a cross-border regime simultaneously, each with its own enforcement path and remedies. There is also an operational trap: you cannot honor an access, correction, or deletion request under a state privacy law or Quebec's Law 25 for personal data you cannot reliably locate, so an estate with no sensitive-data discovery is out of position before any regulator arrives. Mapping this overlay turns "we think our EU data stays in the EU" into observed evidence about where the data is, where it can go, and which obligations that placement creates.
What we assess
What we look for
- Whether storage, database, and backup resources are pinned to regions consistent with the residency commitments made to customers and regulators — S3 bucket Region, Azure storage account geography, Cloud Storage bucket location
- Whether an organization-level location guardrail exists (AWS SCP on aws:RequestedRegion or Control Tower region guardrail, Azure Policy Allowed locations, GCP gcp.resourceLocations org policy constraint) or region choice is left to individual builders
- Whether cross-region replication, geo-redundant backups, DR failover, or CDN edge caching silently move regulated data outside its intended jurisdiction without a documented transfer mechanism
- Whether a sensitive-data discovery and classification capability is enabled (Amazon Macie, Microsoft Purview, Google Cloud Sensitive Data Protection/DLP) so PII, PHI, and cardholder data can actually be located before obligations are mapped
- Whether encryption keys (AWS KMS, Azure Key Vault, Cloud KMS CMEK) reside in the same jurisdiction as the data they protect, and whether cross-border transfers have a documented basis such as SCCs or EU-US DPF self-certification
- Whether the data types found trigger sector privacy rules — GLBA for financial data, HIPAA for PHI — in addition to any US state comprehensive privacy law, and whether sensitive-data categories under those state laws are present
- Whether telemetry, logs, and vendor/support access paths export data cross-border (for example logs aggregated into a US region, or support access originating from another geography)
- Whether obligations that require legal judgment — state data protection assessments, Quebec Law 25 privacy impact assessments, GDPR transfer risk assessments — are flagged as counsel-review items rather than treated as settings we can resolve
Across your clouds
AWS, Azure & Google Cloud
AWS
Residency is enforced primarily with Service Control Policies denying aws:RequestedRegion outside approved Regions and Control Tower region-deny guardrails, with AWS Config rules validating placement; Amazon Macie discovers and classifies PII in S3 so you know where personal data lives, while S3 cross-region replication rules, AWS Backup copy jobs, KMS key Region, and CloudFront edge behavior are where cross-border movement usually hides.
Azure
Residency is enforced with Azure Policy's built-in Allowed locations policy constraining the regions where resources can deploy, with compliance state surfaced in Defender for Cloud, while Microsoft Purview provides data discovery, classification, and sensitivity labeling across stores; storage account geography and geo-redundant storage (GRS) replication pairs, Key Vault key region, and diagnostic-setting log routing are the settings that determine whether regulated data stays within a geography.
Google Cloud
Residency is enforced with the gcp.resourceLocations organization policy constraint limiting where resources and data can be created, with Assured Workloads adding stronger data-residency and sovereignty controls for regulated workloads; Sensitive Data Protection (Cloud DLP) discovers and classifies PII, while Cloud Storage bucket location (region, dual-region, multi-region), Cloud KMS key location, and log sinks are where cross-region exposure appears.
Example finding
Cross-region replication copies regulated customer data outside its committed jurisdiction with no documented transfer basis
Risk: A storage bucket holding personal data subject to a residency commitment (an EU customer contract, Quebec Law 25, or a US state privacy expectation) is configured to replicate to a second region for durability. The copy creates a cross-border transfer that no one approved and that has no SCC or EU-US Data Privacy Framework basis behind it, widening the residency footprint beyond what was represented to customers and regulators. Because no sensitive-data discovery is enabled, the organization also cannot confirm exactly which regulated categories are in the replicated object set.
Fix: Constrain replication and backup targets to jurisdiction-compliant regions, and add an organization-level location guardrail so region choice is not left to individual builders. Enable sensitive-data discovery to confirm what the store actually contains, and where a transfer is genuinely required, document the transfer mechanism and route it to counsel rather than leaving it implicit in a durability setting.
Remediation
How to close it
- 1 Enable sensitive-data discovery and classification (Amazon Macie, Microsoft Purview, Google Cloud Sensitive Data Protection) to inventory where PII, PHI, and financial data actually reside across every account, subscription, and project.
- 2 Map each identified store to the jurisdiction(s) whose law governs its data and to the residency commitments the organization has made, so obligations attach to real locations rather than assumptions.
- 3 Enforce location guardrails at the organization level — an SCP denying aws:RequestedRegion outside approved Regions or a Control Tower region guardrail, Azure Policy Allowed locations, and the GCP gcp.resourceLocations constraint — so residency is a control, not a convention.
- 4 Audit replication, backup, disaster-recovery failover, CDN caching, and log-shipping paths for silent cross-border movement; pin them to compliant regions, or where a transfer is required, document the mechanism (SCCs, EU-US DPF self-certification, adequacy).
- 5 Confirm encryption keys (AWS KMS, Azure Key Vault, Cloud KMS CMEK) live in the same jurisdiction as the data they protect and that plaintext access is limited to approved regions and personnel.
- 6 Route obligations that require legal judgment — US state data protection assessments, Quebec Law 25 privacy impact assessments, GDPR transfer risk assessments — to counsel as flagged items with the supporting placement evidence attached.
Questions
Do US state privacy laws like CCPA/CPRA actually change what you check in the cloud?
Yes, in concrete technical ways. Comprehensive state statutes change where personal data can live, what categories count as sensitive, and what has to be locatable so you can honor access and deletion requests. So the overlay checks whether you can actually find the personal data (via Macie, Purview, or Cloud DLP), whether region and residency controls exist, and whether sensitive-data categories are identified — the settings that determine whether you could meet those obligations. It is practical planning guidance, not legal advice.
How do you handle cross-border transfer for GDPR or Quebec Law 25 data?
We surface where your configuration allows regulated data to leave a region — replication targets, geo-redundant backups, CDN caching, log destinations, and support access paths — and show where a documented transfer mechanism (SCCs, EU-US Data Privacy Framework, or adequacy) would be required. We flag those as counsel-review items rather than asserting whether a given transfer is lawful. The guidance is framed as current to 2026 and is not a compliance determination.
We only operate in the United States — does the regional overlay still apply?
Yes. By 2026 roughly twenty US states have enacted comprehensive privacy laws, and sector rules like GLBA and HIPAA apply regardless of state footprint. Even a US-only estate routinely moves data across regions through backups, multi-region buckets, and CDN edges, and the presence of financial data or PHI triggers residency and discovery obligations that the overlay makes visible before an auditor or regulator does.
More in framework mapping
See where you stand
A health check finds and prioritizes real exposure. It is not a certification or a promise you will never be breached — closing the findings is what changes your risk.
Related domain surfaces
The rest of what we assess
The same read-only assessment covers every domain — see what else it looks at.
