Data residency: what it means in practice to ensure that data stays in Brazil

"Our data stays in Brazil" is one of the most repeated phrases in technology contracts and most rarely verified in practice. The statement seems objective — either the servers are here or they are somewhere else. But the concept of data residency is technically more complex than the physical location of a data center, and the difference between what contracts guarantee and what happens in the infrastructure is where most compliance problems arise.

What data residency really means technically

Data residency has three distinct dimensions that are rarely treated as separate. The first is where data is stored at rest — where files, database records, and storage objects physically reside. The second is where the data is processed — application servers that execute queries, transformations and analyzes may be in a different location from the data they manipulate. The third, often overlooked, is where the metadata lives — indexes, access logs, configuration data, and audit logs that describe the master data.

Most data residency agreements only cover the first dimension. A company can have production data stored in the Brazil South region of a cloud provider and, at the same time, have access logs for this data automatically sent to a region in the United States, read replicas for performance created in other regions, or analytics pipelines that move data for processing in global infrastructure.

Data processing is especially problematic. When a user in Brazil performs a search and the query is sent to a distributed global search engine, where does this processing occur? When a machine learning model trained in the United States makes inference on Brazilian data, where does the data reside at that time? The answers depend on the specific architecture of each system and are rarely spelled out in standard service contracts.

How large cloud providers address the topic

AWS has been offering the sa-east-1 region in São Paulo since 2011, with a wide catalog of services available locally. AWS's data residency promise is that data stored in a region is not moved outside of it without explicit customer action. This covers primary storage, managed database, and compute. What is not automatically included: AWS CloudTrail logs can be configured to send to different regions, AWS technical support can be provided by engineers in other regions with access to customer environments, and global services such as AWS IAM and Route 53 have control infrastructure that is not regional.

Microsoft with Azure Brazil South in São Paulo offers similar guarantees for core services, but with a smaller catalog than older regions — some services available in the United States or Europe are not available in the Brazilian region, which may force hybrid architectures that contradict residency requirements. Oracle Cloud with a region in Vinhedo, São Paulo, is a relevant option especially for Oracle Database workloads with regulatory requirements.

What all providers have in common: Geographic backups are a feature that often requires explicit configuration to remain within the country. Automatic replication to ensure data durability can by default distribute copies across regions in different countries. Verifying the default replication configuration before assuming data is contained is the customer's responsibility.

The exceptions that contracts rarely mention

Support Access is the most significant exception. When a company opens a technical support ticket with AWS, Azure or Google Cloud, the responding engineer may be anywhere in the world and may require access to the customer's environment to diagnose the issue. Providers have controls to limit this access, but the default is not zero access. The AWS Nitro System and Azure Customer Lockbox are examples of mechanisms that give customers control over when and by whom their environment can be accessed — but they need to be enabled and understood.

Compliance and audit logs are another frequent blind spot. SIEM (Security Information and Event Management) tools and monitoring platforms that aggregate logs from multiple regions often have their storage infrastructure in regions where the service is cheaper or has more capacity. The customer configures the collection agent in the Brazilian region, but the log data ends up stored in another country.

CDN and edge computing services by definition distribute data close to users globally. If a company uses CloudFront, Azure CDN, or Fastly to distribute content, parts of that content — potentially including cached user data — may temporarily exist on servers in other countries. For most types of data this is acceptable, but for sensitive personal data it requires specific analysis.

What to ask suppliers before signing

Data residency due diligence with suppliers begins with specific questions, not with confirmation that "the data stays in Brazil". The questions that matter are: where are backups and replicas stored by default, and can this be configured to remain in Brazil? Which regions are used for analytics and machine learning data processing? Which employees have technical access to the environment and where do they operate from? Where are audit logs stored? Are there support services, diagnostic tools or telemetry pipelines that send data to infrastructure outside of Brazil?

Vendors that can't answer these questions accurately don't have real data residency — they have data residency marketing. The distinction is important because it directly impacts the ability to demonstrate compliance in the event of inspection by the ANPD or by customers who require proof.

A practical strategy for those who need to secure real residency

The first step is a data flow inventory — mapping where each category of data goes after it enters the environment. Not just where it is initially stored, but where it flows through integrations, replications, analytics pipelines, and third-party tools. This mapping often reveals data exit points that were not considered in the original architecture.

The second step is to review the default settings for each service in use. Cloud providers often let you configure data residency on a granular basis, but the default settings are optimized for global availability, not local compliance. The difference between what the service can do and what it is configured to do is where most data residency projects fail.