Tailored Coding
The NIST Privacy Framework 1.0 treats privacy management as part of enterprise risk and draws attention to the data processing ecosystem, made up of the entities involved in creating or operating products and services. When that ecosystem crosses borders, responsibilities, contracts, and privacy requirements must remain clear.
In Brazil, physical location abroad alone does not determine whether an international transfer has occurred or which law applies. Resolution CD/ANPD No. 19/2024 addresses the transmission, sharing, or provision of access to personal data to another processing agent abroad and distinguishes that operation from direct collection by a foreign agent. A transfer requires a legal basis for processing and a valid transfer mechanism. The LGPD may apply regardless of where the agents are based or where the data is located when the statutory criteria are met. This analysis requires the specific context. Storing data abroad is not automatically inappropriate, just as storing it domestically does not guarantee security or privacy.
“Where” includes data at rest, in transit, and in use
The primary location is only the beginning. Depending on the architecture and configuration, data may appear in production databases, replicas, backups, temporary files, queues, caches, content delivery networks, search indexes, telemetry, support tools, test environments, devices, exports, and subcontractors’ systems.
Data in transit and in use also needs to be mapped: where the encrypted connection terminates, where decryption occurs, which components process inputs and outputs, and which administration, identity, or support planes can intervene.
Metadata follows its own paths. File names, authors, timestamps, approximate locations, device identifiers, IP addresses, access histories, and relationships between users may be stored separately from the content. This information may constitute personal data depending on its ability to identify or relate to a person.
The record should distinguish three states: what was technically observed, what the supplier committed to contractually, and what remains unknown. When the customer knows only the contracted regions, individual physical locations or internal flows may remain outside their observation.
Access matters as much as location
Two services may declare the same region and offer very different controls. Key management needs clear responsibilities for generation, storage, use, rotation and recovery. Assess these procedures alongside administrative permissions, availability and audit evidence.
The organization needs to identify which administrators, support operators, subcontractors, identity services and integrations can access content or metadata. Purpose, responsibilities, limits and access records should be documented. Product or supplier changes require a fresh review of this chain and the relevant contractual and regulatory requirements.
Privacy requires purpose, proportionality, transparency, and applicable rights. Where personal data is involved, the LGPD establishes principles such as purpose, necessity, free access, transparency, security, and prevention. The application of these principles to the architecture and contract needs to be validated for the specific context.
The decision takes shape in three layers
Class and purpose
First, identify the data class, the purpose of processing, and the impact of exposure, alteration, unavailability, or incompatible use. Public information, internal material, confidential documents, and sensitive personal data do not need to occupy the same environment or accept the same access chain.
Topology and access
Next, trace the systems and regions through which primary copies, replicas, backups, logs, metadata and data in transit and in use pass. For each layer, document entities with access, administrative responsibilities, cryptographic controls and support and recovery procedures.
Data residency, compliance and lifecycle
Finally, confirm which legal basis supports the processing, which mechanism supports any transfer, which rights and obligations apply, and who validated the analysis. The decision also needs to cover incident response, continuity, portability and deletion where applicable, permitted retention, proof of disposal, and exit from the provider.
The record that supports the decision
The architecture needs to account for the moment when prevention fails. The organization should be able to establish, within the limits of the evidence, which copies, flows, and credentials were affected, which keys need to be replaced, which entities participated in processing, and which records allow the events to be reconstructed.
Backups may extend the existence of data according to the retention policy. Logs help an investigation but may contain sensitive information. Replication may extend the set of regions, failure domains, or operators, depending on the topology. Each benefit creates a corresponding need for control.
The data placement record brings together class, purpose, data at rest, in transit, and in use, permitted environments, regions, copies, metadata, entities with access, key functions, retention, disposal, incident response, and the person responsible for the decision. It should show technical evidence, contractual commitments, and unknown gaps in separate fields.
How we work
The work begins with data classification and mapping flows, copies, metadata, and entities with access. We compare what was observed in the architecture with contracts, configurations, and applicable requirements. The deliverable organizes the placement record, transfer points, key dependencies, evidence gaps, and decisions needed for each data class, with responsible parties and criteria for change or exit.
If an incident happens tomorrow, can your company say where all relevant copies and flows are, who can access them, and what can actually be deleted? That is the decision hidden behind the “region” field.