Data Residency: Where the Bytes Live

This post follows directly from Crossing the Ditch and digs into the question Maya deferred at the end of that conversation: where is the data allowed to live, and what does that mean operationally.

The conversation that starts in the office

It’s a Monday morning the week after the deal with Harvest Circle was announced. Tom has set up a meeting with Priya, the new legal counsel Diane recruited for the Series B, and a lawyer from an Auckland firm who specialises in privacy law. Maya is there too, because she wants to understand what’s being decided, not just be told the answer.

Tom opens with the question he’s been carrying around all weekend.

“Harvest Circle has 812 subscribers. Nina has their names, addresses, delivery instructions, payment details, and order histories. After the acquisition closes, are we allowed to copy that data into the Greenbox systems?”

The lawyer, an NZ privacy specialist named Rachel, takes a sip of coffee and says the sentence that will drive the next three months of engineering work:

“The short answer is: probably, with conditions. The long answer is that ‘where data lives’ and ‘who data is about’ and ‘who data is accessed by’ are three different questions, and your obligations are different for each one.”

Why data residency is a thing at all

Data residency is the idea that personal data about a person should, in some cases, be stored or processed in a specific jurisdiction. Different countries have different rules about this, and the rules exist for a mix of reasons.

Some of those reasons are privacy-driven. If your data is stored in a country with weak privacy protections, the argument goes, your rights over that data are weaker. Governments and courts in that country might access it. Companies in that country might use it. Your ability to correct, delete, or retrieve it might depend on local law.

Some of the reasons are sovereignty-driven. Governments want certain kinds of data to stay within their borders because they believe it matters for national security, economic policy, or the ability to enforce their own laws. Health records, financial data, and government-held data are common examples.

Some of the reasons are pragmatic. Regulators can only inspect what they can reach. If your data is stored in another country, the regulator might have to request it through diplomatic channels rather than simply demanding access.

The result is a patchwork of rules that vary by country, by data type, and by who’s asking. A company operating in multiple jurisdictions has to deal with all of them simultaneously.

The three questions

Rachel writes the three questions on the whiteboard.

Where is the data physically stored? This is the most literal version of data residency. Is the bit-for-bit data sitting on disks in Sydney, Auckland, Frankfurt, or Virginia? For cloud-based systems, this usually comes down to which region you’ve configured your cloud provider to use.

Who is the data about? Personal data about an Australian resident, about a New Zealand resident, about a European resident, and about an American resident are all treated differently by different legal regimes. The protections follow the person, not the server. A server in Australia containing data about a European resident is still subject to GDPR.

Who has access to the data? Even if the data is stored in one country and about residents of another, the question of who can access it matters. An Australian employee querying New Zealand subscriber records might or might not be allowed, depending on the contractual and legal framework. A government making a lawful access request might or might not be allowed, depending on cross-border cooperation treaties.

“You need to think about all three,” Rachel says. “It’s tempting to focus on the first one, where the servers are, because it’s the most concrete. But the legal obligations usually hinge on the second two.”

The New Zealand situation

Rachel walks the room through the specifics of transferring Harvest Circle’s data into Greenbox systems.

New Zealand’s privacy law is the Privacy Act 2020, which replaced the earlier 1993 Act. It’s broadly similar in shape to Australia’s Privacy Act 1988 and the Australian Privacy Principles (APPs), but with some specific differences.

Key points for the Harvest Circle transfer:

Consent matters. Nina’s subscribers agreed to a Harvest Circle privacy policy. That policy presumably allowed Harvest Circle to use their data for running the business. The question is whether transferring the data to a new owner. Greenbox, is allowed under that original consent. In most cases it is, but only if the new owner continues to use the data for the same purposes.
Cross-border transfer rules. Under NZ Privacy Act Principle 12, a New Zealand agency can disclose personal information to an overseas agency only if the receiving country has “comparable” privacy protections or if the individual consents. Australia is generally considered comparable for this purpose, but there’s still a paperwork trail.
Notification obligations. Subscribers need to be told, in plain language, that their data is being transferred to Greenbox and what that means practically. They need to be given an opportunity to opt out, and in most cases, opting out means closing their Harvest Circle account.
Sensitive data requires stronger controls. Payment details, especially, need to be handled with care. Greenbox’s PCI DSS environment is probably acceptable, but the transfer process itself (moving card tokens from Nina’s payment processor to Greenbox’s) needs to follow specific rules.

Rachel translates this into practical steps:

Send a notification email to every Harvest Circle subscriber two weeks before the transfer, explaining what’s happening and giving them an opt-out option.
Transfer only the data necessary for continued operation. Historical data that isn’t needed can be deleted rather than migrated.
Keep the New Zealand data segregated within the Greenbox systems, even if it’s stored in the same database, so that it can be separately governed and, if necessary, separately deleted.
Document every step of the transfer. If a regulator asks what happened, the answer should be complete and auditable.

Tom asks a question that isn’t about New Zealand at all.

“What if a New Zealand subscriber is travelling in Europe and places an order while they’re there? Do we become subject to GDPR?”

Rachel and the Greenbox legal counsel look at each other. This is the question that everyone who operates across borders ends up asking, and the answer is more complicated than people expect.

GDPR, the General Data Protection Regulation, is the European Union’s comprehensive privacy law. It applies not just to EU-based companies, but to any company anywhere in the world that offers goods or services to people in the EU or that monitors the behaviour of people in the EU. This is called the extraterritorial scope of GDPR, and it’s why companies based far outside Europe still comply with it.

The question of whether Greenbox needs to comply with GDPR depends on several things:

Does Greenbox offer services to people in the EU? Not currently. Greenbox operates in Australia and, as of the Harvest Circle deal, New Zealand. Neither is in the EU.
Does Greenbox monitor EU residents? Also no. Analytics, marketing, and subscriber tracking all happen within the Australia-New Zealand footprint.
What about the subscriber in Paris? If a New Zealand subscriber travels to Europe and accesses the Greenbox website from there, GDPR’s “targeting” test asks whether Greenbox is targeting EU residents, offering the service to them, marketing to them, processing payments in euros, delivering to European addresses. If not, the fact that someone happens to use the site from the EU doesn’t trigger GDPR.
What if Greenbox expands to the UK? Then everything changes. The UK has its own version of GDPR (the UK GDPR, nearly identical to the EU version) and serving British subscribers would put Greenbox squarely within scope.

Rachel’s summary: “For now, you’re not GDPR-covered. But the moment you decide to ship a box to anyone in Europe, you are. So build your systems with the assumption that you will be, eventually, even if you aren’t yet. It’s much cheaper to bake compliance in than to retrofit it.”

What “build for it” actually means

Priya, who has been quiet, asks the practical question. “What does building for GDPR-readiness look like technically?”

Rachel and Tom work through the list together. Most of it is good practice regardless of jurisdiction.

Data minimisation. Collect only what you need for the purposes you’ve stated. If Greenbox only needs a subscriber’s name, delivery address, dietary preferences, and payment method, don’t ask for their birthday or income bracket. This reduces compliance obligations and reduces the blast radius of any future breach.

Purpose limitation. Use data only for the purposes you collected it for. If you collected an email address for delivery confirmations, don’t start using it for marketing campaigns without explicit consent.

Right of access. Build an internal tool that can assemble everything Greenbox knows about a specific subscriber in a machine-readable format, on request. GDPR requires this within thirty days. Most companies discover they can’t do it quickly because their data is scattered across a dozen systems.

Right of erasure (“right to be forgotten”). Build an internal tool that can delete a subscriber’s data from every system, not just the main database. This is harder than it sounds. Backup systems, analytics stores, log files, and third-party services like payment processors all need to be considered.

Data protection by design. Encrypt data at rest. Encrypt data in transit. Use role-based access control so that employees see only the data they need for their job. Log all access to sensitive data. Review logs.

Records of processing. Keep a register of what data you collect, why, where it’s stored, how long you keep it, and who you share it with. GDPR Article 30 mandates this; good privacy hygiene requires it even where the law doesn’t.

Most of this is already in place at Greenbox, because the team has tried to be careful from the start. A few gaps come up. The analytics data isn’t segregated by jurisdiction. The backup retention policy is longer than it needs to be. Nobody has built a right-of-access tool yet.

Priya volunteers to own the gaps. Tom adds them to the engineering backlog.

The decision about where the data lives

After the legal conversation, the engineering question remains: where does the data physically sit?

Options:

Everything in Australia. Simplest operationally. One region, one database, one set of backups. New Zealand subscriber data crosses the Tasman Sea to reach the Greenbox servers in Sydney.
Everything in New Zealand. Symmetric argument. One region for NZ, but then Australian subscriber data has to cross the other way. And NZ cloud regions have fewer available services than Australian ones.
Split by jurisdiction. New Zealand subscriber data stored in New Zealand. Australian subscriber data stored in Australia. More operationally complex, more expensive, but stronger guarantees for each jurisdiction.
Primary in one country, read replicas in the other. Write once, replicate for performance. Legally similar to option 1 (the authoritative copy lives in one place) but with better read performance on both sides.

Tom initially favours option 1 because it’s simplest. Priya pushes back. “If we ever expand to Europe, we’re going to need to have already figured out how to split data by jurisdiction. Doing it now, with 800 New Zealand subscribers, is much easier than doing it later with 30,000 European subscribers.”

Rachel agrees. “Even if option 1 is legal, which it probably is, building the capability to segregate data by jurisdiction now is a strategic investment. The cost difference is small. The optionality is large.”

Maya makes the call. Option 3, split by jurisdiction. New Zealand subscriber data stored in a New Zealand region. Australian subscriber data stored in an Australian region. Each region has its own backups, its own access logs, its own governance. The application code abstracts over the two regions so that engineers writing features don’t need to think about where the data lives, they use the same APIs regardless.

It’s more work in the short term. It builds the capability for everything that might come next.

The thing Tom almost missed

A week into the implementation, Tom realises something he hadn’t thought about in the meeting. Analytics data.

When a subscriber places an order, the order event is sent to the analytics system. The analytics system aggregates data across all subscribers to compute things like conversion rates, retention curves, and revenue by cohort. Those aggregations are used by the product team to make decisions.

If Tom segregates the operational data by jurisdiction but still sends all the analytics events to a single system in Sydney, he’s effectively copying New Zealand subscriber data into Australia every time someone places an order. The segregation is only superficial.

He talks it over with Priya. The solution they settle on is to aggregate before cross-border transfer. Analytics events generated in New Zealand are processed in the New Zealand region first, producing aggregated numbers that contain no individual-level personal data. Only the aggregates cross the border. Individual-level analytics stays in the region it originated in.

This is slightly harder to engineer than the naive approach, but it’s the right architecture for any business that will eventually span more jurisdictions. It also has a nice side effect: the aggregation layer forces the team to think carefully about what they’re measuring and why, which generally results in cleaner metrics.

The lesson for any cross-border team

There’s a general principle buried in this story. When your data is in one country and your customers are in one country, you can be sloppy about the distinction between where things live and where they came from. It doesn’t usually hurt anyone. When your data crosses a border, even a friendly one, the distinction suddenly matters a lot.

The engineering work to keep data segregated by jurisdiction isn’t glamorous. It doesn’t show up on a product roadmap. It’s the kind of work that prevents problems rather than creating visible features. But it’s the kind of work that compounds over time, because each new jurisdiction you add becomes incrementally cheaper to support.

Tom writes a short internal document called Greenbox Data Residency Principles. It has four rules:

Segregate by jurisdiction at the storage layer. Personal data about residents of a country is stored in that country’s region.
Aggregate before you transfer. Analytics, metrics, and other aggregated data can cross borders, but individual-level personal data should not, except where explicitly required for operational reasons.
Log every cross-border access. When an employee in Perth queries a New Zealand subscriber’s data, log it, attribute it, and make the logs reviewable.
Design for the next jurisdiction. Every architectural decision should leave room for adding another country without rewriting the core systems.

Rachel reads the document and sends one comment: “This is better than most formal legal documents I see. Publish it. Make it a living artefact. Update it when your circumstances change.”

Tom files it in the engineering wiki and adds it to the onboarding checklist for new developers.

Why this matters

The answer Rachel gave in the first meeting still applies. Where data lives, who data is about, and who accesses data are three different questions, and treating them as one question leads to bad decisions. The team now knows this explicitly. Every future expansion, whether it’s another New Zealand market, the UK, or Singapore, starts with the same three questions, which is exactly how it should start.

Maya closes the notebook on the residency conversation with a single line:

“A border is not just a political thing. It is also a data thing. Treat both borders with equal respect, and the company can live on both sides of them.”

She goes to make a cup of tea. There’s a subscriber email to answer before the end of the day, and Harvest Circle has just sent over the first draft of the transfer plan.