Most data residency programs address the first condition and are silent on the second.
Why This Matters Now
Data residency has become a primary mechanism for addressing data sovereignty and regulatory compliance requirements in cloud environments. Organizations configure their cloud providers to store data in specific geographic regions, execute data residency options in SaaS contracts, and document regional storage configurations as evidence of compliance with localization requirements.
This approach addresses a real and important governance requirement. It does not address the processing dimension of data sovereignty, which is where most residency programs have a significant gap. Modern cloud architectures distribute computation across global infrastructure. Processing jobs, analytics queries, machine learning inference, and operational monitoring routinely execute on compute resources that are not geographically constrained by the data residency configuration applied to the underlying data storage.
Storing data in a single region and processing it in that same region are two separate technical configurations. They are frequently conflated in data residency governance programs that treat regional storage configuration as equivalent to regional processing confinement.
The Governance Problem Beneath the Surface
The distinction between data at rest and data in processing is a technical one with significant regulatory implications. GDPR and other privacy frameworks govern the processing of personal data, not just its storage. An organization that has configured EU data residency for storage but runs analytics queries on globally distributed compute infrastructure is processing EU personal data outside the EU, regardless of where the data was stored before the query executed.
Most organizations are not aware that this gap exists in their residency configuration. The cloud provider's data residency documentation covers storage. The processing layer is a separate configuration, often not included in the default residency package, and frequently not addressed in the governance program that relied on the storage configuration as its compliance foundation.
What This Actually Means in Enterprise Practice
Serverless and Managed Services Process Globally by Default
Managed services, serverless compute platforms, and cloud-native data processing tools typically execute on globally distributed infrastructure unless specific regional constraints are applied. A Lambda function, a Cloud Run service, or an Azure Functions deployment will execute on available compute resources that may or may not be in the same region as the data the function processes. The data moves from its storage region to the compute region for processing and returns. This is a cross-border data flow that the storage residency configuration does not prevent.
This is the default behavior of cloud compute platforms. Constraining processing to a specific region requires explicit configuration that is separate from storage residency settings and, in some cases, comes with performance and cost trade-offs.
Analytics and Business Intelligence Introduce Processing Without Residency
Business intelligence platforms and analytics tools often execute queries on globally distributed query engines. When an organization's BI platform runs an analytics query against EU-resident data, the query engine may execute on infrastructure in any region, pulling data to the execution environment, processing it, and returning results. The data residency configuration for storage does not follow the data into the processing layer.
AI and ML Inference Crosses Borders Continuously
Machine learning inference, the act of running data through a deployed model to generate predictions or outputs, occurs on the compute infrastructure where the model is deployed. If the model is deployed on global inference infrastructure, EU-resident personal data submitted for inference is processed outside the EU regardless of where it was stored. AI-powered features in SaaS platforms routinely operate this way: the data is stored in the contracted region, but inference occurs on the vendor's global ML infrastructure.
Every AI-powered feature that processes personal data is a potential processing residency gap. Storage residency configurations do not extend to inference infrastructure unless specifically contracted and technically implemented.
Operational Monitoring Accesses Data Globally
Operational monitoring, log analysis, performance monitoring, and security monitoring tools that observe cloud infrastructure often aggregate and analyze data across regions. A global monitoring deployment that ingests logs from EU infrastructure and processes them in a centralized monitoring environment is processing EU operational data outside the EU. The data access patterns of monitoring infrastructure are rarely assessed against data sovereignty requirements.
How Different Teams See This: Where They All Miss
Processing residency is a technical governance requirement that requires coordination between legal, engineering, and operations. In most organizations, no single team owns the question of where data is processed, as distinct from where it is stored.
Framework Cross-Walk
- GDPR Article 4(2): The definition of processing is broad and includes collection, recording, organization, structuring, storage, adaptation, retrieval, consultation, use, disclosure, and erasure. All of these activities are in scope, not just storage.
- China PIPL and DSL: Localization requirements under Chinese law apply to processing and storage. The distinction between storage residency and processing residency is explicitly relevant in Chinese regulatory compliance.
- NIST CSF 2.0: Data flow documentation requirements extend to processing flows, not just storage locations. Accurate records of processing activities must reflect where data is processed.
- EDPB Transfer Impact Assessment guidance: The EDPB's TIA framework explicitly addresses technical supplementary measures including encryption and pseudonymization during processing, indicating that processing location is within the regulatory assessment scope.
The regulatory frameworks that govern data sovereignty and cross-border transfers were written with processing in mind, not just storage. Governance programs that address storage residency but not processing residency are aligned to a subset of the regulatory requirement.
The Enterprise Reality Gap
The enterprise reality gap is between the residency compliance posture organizations present, which is typically based on storage configuration documentation, and the actual processing reality, which includes compute workloads executing in regions outside the storage residency boundary.
This gap is not visible in standard compliance documentation. Storage region configurations are clearly documented. Processing execution regions are often not tracked at the governance level. The gap exists between what is governed and what actually happens during the processing lifecycle.
If a regulator asked not where your data is stored but where your data is processed, would your compliance documentation provide an accurate answer? For most organizations, the honest answer is that the processing answer has never been specifically investigated.
Backup Processing: The Overlooked Residency Gap
Backup and recovery operations involve processing: data is read from storage, potentially decompressed, deduplicated, encrypted, and written to backup storage. Backup processing jobs in cloud environments may execute on compute resources in different regions than the source data. An organization that has configured EU storage residency may have backup processing executing on non-EU compute as a side effect of the backup provider's default infrastructure configuration.
Enterprise Scenario: The Query That Crossed the Border
What the configuration did not address: The firm's BI platform runs daily analytics queries against customer transaction data using a globally distributed query engine. The queries execute on available compute nodes, several of which are regularly allocated outside the EU. EU customer transaction data is pulled from EU storage to non-EU compute for query execution and returned to EU storage after processing.
The storage residency configuration was correctly implemented and accurately documented. It did not prevent cross-border processing through the query execution layer, because query execution is not governed by storage residency settings. The cross-border transfer that GDPR Chapter V governs was occurring daily through the analytics infrastructure, undetected and undocumented.
Industry Signal
European DPA guidance following Schrems II has increasingly focused on technical measures that ensure effective data protection during processing, not just at rest. The EDPB's recommendations on supplementary measures explicitly discuss technical measures applicable during processing, including pseudonymization and encryption that remains effective at the processing layer. The direction of regulatory travel is toward assessment of processing conditions, not just storage configurations.
The regulatory assessment framework is evolving to include where data is processed alongside where it is stored. Organizations whose residency compliance posture is built on storage configuration alone are building compliance against yesterday's assessment standard.
Enabling Capabilities
- Cloud provider processing residency controls: Regional compute constraints, VPC configurations, and managed service regional restrictions that confine processing to defined geographic boundaries.
- Data flow monitoring with processing visibility: Tools that track not just where data is stored but where processing operations execute, including query execution, ML inference, and batch processing.
- BI and analytics platform residency controls: Query engine regional configurations that constrain execution to defined compute regions.
- AI inference regional controls: Model deployment configurations that restrict inference to specific geographic compute regions. Available from major cloud providers with varying coverage across services.
- DSPM platforms with processing visibility: Emerging capability to track data movement through processing operations in addition to at-rest location.
A Practical Starting Point
Conduct a processing residency assessment separate from your storage residency assessment. For each category of processing your organization performs on personal data, including analytics, ML inference, batch processing, monitoring, and backup, identify where that processing executes and whether execution is constrained to the same regional boundary as storage.
Document the gaps. Prioritize based on regulatory obligation and data sensitivity. Implement processing regional constraints for the highest-priority gaps. Where constraints are not technically feasible without unacceptable trade-offs, document the residual risk and legal position.
Processing residency governance is not a one-time configuration exercise. Cloud services evolve, new processing tools are adopted, and existing processing infrastructure changes. Build a review cadence that keeps the processing residency assessment current.
Questions Leaders Should Be Asking
- Have we assessed where our data is processed, as distinct from where it is stored, and documented the processing regions for each significant processing activity?
- Do our analytics and BI query engines execute on compute infrastructure that is regionally constrained consistent with our data residency requirements?
- Where does ML inference execute for AI-powered features that process personal data, and is that consistent with our residency obligations?
- Has our backup and recovery processing been assessed for processing residency compliance?
- Does our data residency documentation accurately reflect processing locations, or does it reflect only storage locations?
What to Require From Vendors
Ask directly:
"For each processing activity your platform performs on our data, including analytics query execution, ML inference, monitoring, and backup processing, confirm the geographic regions where that processing occurs and whether regional constraints are available and included in our current contract."
Expect as evidence:
- Documentation of processing execution locations for each service component, not just storage location
- Clear description of which processing activities are included in residency configurations and which require additional configuration
- Confirmation of ML inference execution geography for AI-powered features
- Regional constraint options for processing activities with associated performance and cost implications
A vendor who confirms data residency by describing storage region configuration, without addressing processing execution geography for each service component, has given you a partial answer to a complete question.
Demonstrating Diligence
- Documentation: Processing residency assessment covering all significant processing activities; records of processing activities that reflect processing locations alongside storage locations; vendor documentation of processing execution geography.
- Process: Processing residency review as part of new service onboarding; regular review of processing execution geography as cloud services evolve; governance response process for identified processing residency gaps.
- Technical evidence: Cloud provider processing region configurations; analytics platform regional execution configurations; ML inference deployment region documentation.
The evidence that demonstrates processing residency compliance is technical, not contractual. Show the configuration, not just the contract.
Closing Perspective
Data residency programs have provided a valuable governance foundation for cloud data sovereignty compliance. The limitation is that they were largely designed around the storage question, which is the most visible and easiest to configure. The processing question is less visible, requires separate technical configuration, and has received substantially less governance attention.
As regulatory frameworks continue to evolve toward fuller assessment of processing conditions, organizations that have addressed only storage residency will find gaps in their compliance posture that were not visible under previous assessment standards.
The organizations that close these gaps now, before regulatory assessment standards explicitly require processing residency documentation, will be in a materially stronger position when those standards arrive. The technical configurations exist. The governance attention has been elsewhere.
Data does not stay where you store it. It goes where it is needed for processing. Govern both journeys.
Enterprise practitioner perspective. Not legal advice. Part of the Deep Trust Governance Series by Verisq. Get the free weekly Breach Digest.