Data residency is easy to promise and hard to keep. An operator can host in one country and still move player data across three borders every minute, because residency is not one property of a platform. Storage location, access path, processing location and copy management are four different facts, and a platform that answers only the first one has a residency claim rather than a residency control.
For an operator’s platform architect, data-protection lead or the supplier integrating into a regulated market, the delivery artifact is a residency control pack: the dataset register that says which record must sit where, the transfer register that says which flows leave and under which instrument, the replication and access duties that come with an in-country hosting rule, and the tests that force each of those to fail. This guide is engineering guidance, not legal advice; residency and transfer obligations are market-specific and change, so confirm the current requirement for each licensed market with its regulator and your counsel.
Four questions a residency rule is really asking
A single sentence such as “player data must remain in the country” contains four separable engineering questions, and each has its own evidence.
Where is the record stored, and is that a primary store or a replica? Who can reach the record, from where, and through which path? Where is the record processed, including transient processing such as a fraud score computed by a third-party service? And where do copies go — analytics extracts, backups, test data, support exports and the read replica that quietly becomes a second production database?
Answer them separately or the residency claim will not survive the first reviewer who asks for the receipt behind it. A dataset register with one row per dataset answers all four: classification, jurisdiction-specific residency requirement, primary region, permitted processing locations, copy destinations, retention and the named owner. The register is also where residency stops being a hosting decision and becomes an auditable control, in the same way the security logging and audit evidence control pack turns an event log into something a reviewer can use.
Brazil makes in-country hosting explicit, and adds three duties to it
Brazil’s fixed-odds betting framework is the clearest current example of a residency rule written for engineers rather than for a press release. Portaria SPA/MF nº 722, of 2 May 2024, published in the Diário Oficial da União on 3 May 2024, sets the technical and security requirements for betting systems and their sports betting and online gaming platforms. Its Article 4 requires operators to keep the betting system and its respective data in data centres located in Brazilian territory, while observing the General Data Protection Law, Lei nº 13.709/2018. The same article requires the data centre used to hold ISO 27001 certification, and Article 5 requires the electronic channels that offer fixed-odds bets to use a “bet.br” domain registration.
The exception is where the engineering work lives. Systems and data may be located outside Brazil only in countries that have an international legal cooperation agreement with Brazil covering civil and criminal matters jointly, and only where the operator satisfies Article 33, VIII of the LGPD and four requirements cumulatively:
- the data subject authorises the international transfer specifically and in advance, with clear information about the purpose of the operation;
- the technical area of the Ministry of Finance has secure and unrestricted access, both remotely and on site, to the systems, platforms and data;
- the operator replicates its database and information base in Brazil, continuously updated, with every database instance holding the same content, tested periodically;
- the operator presents an information-technology business continuity plan covering likely loss scenarios, risk identification and evaluation, prevention and mitigation actions, and named owners.
Note what that list is not. It is not a choice between hosting locally and hosting abroad, because the third condition means an operator that hosts abroad must still run a continuously updated Brazilian copy. Residency under this ordinance is a replication requirement plus an access requirement, not merely a location. Do not treat the exception as an availability win either: Article 10 obliges operators to send data on bets, bettors, bettor wallets and legal destinations to the SPA on the schedule and in the format defined in the SIGAP manual, and the ordinance also requires certification of the betting system by a certification entity whose capacity has been recognised by the SPA, with annual revalidation and the revalidated certificate sent to the SPA within five business days of issue.
A mirror copy is a product, not a backup
The second and third conditions above translate into ordinary platform engineering with unusually strict acceptance criteria, because the regulator’s version of “replicated” is stricter than most disaster-recovery designs.
Continuous update with identical content means the Brazilian copy cannot be a nightly dump. It has to be fed by change data capture, dual writes at a defined boundary, or a transactionally ordered stream, and the platform must be able to show that the copy is current rather than merely present. Periodic testing means the comparison runs on a schedule and its result is retained: row counts per table, a hash or checksum comparison over defined key ranges, a replication-lag measurement, and a named exception path for the tables that legitimately cannot match, such as ephemeral session state.
Then reverse the question. If the Brazilian copy is a full copy, it becomes a candidate for reads, and a read path that silently prefers the nearer region is exactly how a residency design fails an audit while passing every availability test. Decide read authority per dataset, record it in the register, and test the failure: a query that must resolve against the in-territory copy should be provably unable to fall back to a foreign region on timeout.
Regulator access is a provisioned path, not a promise
“Secure and unrestricted access, remotely and on site, to the systems, platforms and data” is the second condition that most operators discover late, usually because access was designed as an internal privilege question rather than as a delivery obligation.
A defensible design specifies the access path before it is requested: which accounts and which roles the authority uses, whether those are federated identities or provisioned accounts, which network path they take, what the second factor is, what the session records, and who is notified when the path is used. It also states the on-site variant, because a remote-only design does not satisfy a requirement that names both. The access path then belongs in the back-office access control requirements and the incident evidence set, not in a runbook nobody has executed.
Test it as an availability property rather than a permissions property. Rehearse a regulator-initiated read of a defined dataset on a short notice window and record how long the path took to become usable. An access path that is only proven by reading the identity provider’s configuration has never been tested; the incident response plan treats an access failure in the same class as any other availability failure, and it should be rehearsed on that basis.
Ask whether a flow is a transfer before choosing an instrument
The European side of the same problem starts with a question that is often answered by assumption. The European Data Protection Board’s Guidelines 05/2021, in the final version adopted on 14 February 2023, set out three cumulative criteria for a processing operation to be a transfer: a controller or processor subject to the GDPR for that processing discloses or otherwise makes personal data available to another controller, joint controller or processor, and that importer is in a third country or is an international organisation. If the three criteria are met, Chapter V of the GDPR applies and the flow needs a transfer instrument.
Two consequences matter to a platform design. The first is that remote access is disclosure: the EDPB’s own illustrations include a processor located in a third country remotely accessing, for support purposes, data stored in the EU — treated as a transfer from the EU controllers to that processor. Support access, admin tooling and vendor debugging sessions are therefore ordinary transfer events that need a documented instrument, not exceptions to one. The second is that criteria that are not met do not end the analysis: the guidelines state that processing which is subject to Article 3 but is not a transfer can still carry increased risk, and Articles 5, 24 and 32 still apply. That is the same reasoning that makes a residency register worth building even where no transfer occurs, and the multi-tenant isolation guide covers the tenant-boundary version of it.
Choose the instrument, then record the assessment behind it
Once a flow is a transfer, the GDPR gives two families of instrument: an adequacy decision under Article 45, or appropriate safeguards under Article 46. Choosing one is a documented decision with an assessment attached, because the EDPB’s Recommendations 01/2020, in the final version adopted on 18 June 2021, require an assessment of whether the instrument in question ensures a level of protection essentially equivalent to that guaranteed within the EU, or whether supplementary measures have to be implemented.
The United Kingdom runs a separate scheme over the same data. The ICO issues two sets of standard data protection clauses for restricted transfers, the International Data Transfer Agreement and the International Data Transfer Addendum to the European Commission’s standard contractual clauses, and the ICO’s guidance is explicit that the EU clauses are not valid on their own for restricted transfers under the UK GDPR. The same guidance states that a transfer risk assessment must be completed so that the standard of protection is not materially lower after the transfer, and that the ICO plans to update both documents during 2026 while organisations continue to use the current versions — with an option for the instrument to update automatically when a new version is issued. Build the register so a clause-set version change is a data update, not a contract renegotiation.
Brazil has its own instruments and its own clock. Resolução CD/ANPD nº 19, of 23 August 2024, approves the International Data Transfer Regulation and the content of the ANPD’s standard contractual clauses, alongside adequacy recognition, specific contractual clauses and binding corporate rules. Under Article 2 of that resolution, controllers using contractual clauses had twelve months from publication to incorporate the approved standard clauses into their contracts — a deadline that closed on 23 August 2025. The regulation also assigns the controller an explicit three-part verification: whether the operation characterises an international transfer, whether it is subject to Brazilian data protection law, and whether it is supported by a valid legal basis and transfer mechanism. Those are three different questions with three different evidence trails, and the transfer register should answer each one per flow rather than per vendor.
Make the control pack testable
A residency and transfer control pack is only worth its file size if each claim has a test that fails loudly. Start with the residency claim: attempt to write a copy of a residency-bound dataset outside the permitted region and require the write to be rejected, not merely discouraged by convention. Continue with the mirror: pause the replication stream and require the platform to surface the lag within a defined window instead of reporting healthy. Then the access path: run a read of a defined dataset using only the authority-facing path, on the working day after a credential rotation, which is when these paths usually break.
Then the transfer side. Force a vendor support session that needs remote access and require it to produce a transfer-record entry with an instrument reference before the session opens. Delete an adequacy decision from the register in a test environment and require dependent flows to fail closed rather than fall back to a legacy clause set. Expire a standard clause version and require an owner to be named. And test the register itself: a dataset with no residency entry, a flow with no instrument, a copy destination with no owner — each should be a finding rather than an omission.
For operators and suppliers specifying platform residency and cross-border transfer controls, Wizards certification and compliance turns this control pack into platform, provider and acceptance requirements.
Frequently asked questions
Does a data residency rule mean data can never leave the country?
No. Brazil’s Portaria SPA/MF nº 722 allows betting systems and their data to be located abroad, but only in countries that have an international legal cooperation agreement with Brazil covering civil and criminal matters jointly, and only if four further conditions are met cumulatively — including a continuously updated Brazilian copy of the database with identical content, tested periodically, and secure, unrestricted remote and on-site access for the Ministry of Finance’s technical area. Residency in that model is a replication and access obligation, not a prohibition on any foreign processing.
When is a cross-border data flow a legal “transfer” under the GDPR?
The European Data Protection Board’s Guidelines 05/2021, in their final version of 14 February 2023, apply three cumulative criteria: the exporter is subject to the GDPR for the processing, the exporter discloses or otherwise makes personal data available to another controller, joint controller or processor, and that importer is in a third country or is an international organisation. All three must be met for Chapter V to apply. Remote access counts — the guidelines’ illustrations treat a third-country processor accessing EU-stored data for support as a transfer.
Can we rely on the European standard contractual clauses for UK transfers?
Not on their own. The ICO issues two sets of standard data protection clauses for restricted transfers under the UK GDPR, the International Data Transfer Agreement and the International Data Transfer Addendum to the European Commission’s standard contractual clauses, and its guidance states that the EU clauses are not valid by themselves for UK restricted transfers. Using the Addendum lets an organisation rely on the EU clauses for those transfers, and a transfer risk assessment is required in addition. The ICO has said it plans to update both documents during 2026 and that the current versions remain in use.
What changed for Brazilian international transfers in 2025?
Resolução CD/ANPD nº 19, of 23 August 2024, approved Brazil’s International Data Transfer Regulation and the content of the ANPD’s standard contractual clauses. Its Article 2 gave controllers twelve months from publication to incorporate the approved standard clauses into existing contracts, so that transition window closed on 23 August 2025. The regulation also sets the controller’s verification duties: whether the operation characterises an international transfer, whether it is subject to Brazilian law, and whether a valid legal basis and transfer mechanism support it.
What should a residency and transfer register contain per dataset?
One row per dataset, answering four separate questions: where the record is stored and whether that store is primary or replica, who may reach it and through which path, where it is processed including transient third-party processing, and where copies go — analytics extracts, backups, test data, support exports and read replicas. Record the jurisdiction-specific requirement behind each entry, the transfer instrument for each flow that leaves, the retention rule and a named owner. A register that answers only the storage question cannot support a residency claim.
