Okay, But Actually… Data Residency Is Not the Same as Data Protection

Mention custom software online and somebody will eventually ask:

“What if you are holding Californian data, EU citizen data or Brazilian data?”

Those are reasonable things to think about.

And yes, we are back here again: before announcing an international legal disaster, somebody has to ask what the application actually does.

I keep repeating this because the people delivering the lectures keep skipping it.

Throwing California, Europe and Brazil into the same warning may sound impressive, but without knowing anything about the product, it tells us absolutely nothing. We have three place names and still no idea what problem we are supposed to be solving.

Several different questions are being mixed together

When people talk about “where the data is,” they are often combining three separate questions:

1. Where is the information physically stored?
2. Which laws apply to the business?
3. Is the information properly protected?

These questions are connected, but they do not have the same answer.

Suppose a Portuguese business uses an application with a database hosted in Germany.

The first question is easy. The main database is in Germany.

That does not tell us whether copies also exist in backups, logs, email notifications, analytics tools or support systems. It does not tell us who can access the information. It does not tell us how long the business keeps it or whether customers can ask for it to be deleted.

Most importantly, it does not tell us that the business is compliant with every law that may apply to it.

It only tells us where one part of the system stores information.

Data residency is about location

Data residency means where information is stored or processed.

Some companies require their data to remain inside a particular country or region. They may have contractual requirements, industry rules or customers who insist upon it. Sometimes choosing a nearby region also improves speed.

All perfectly normal reasons to care about location.

Services such as Supabase and major cloud providers allow developers to choose a region for a project. If a customer requires its main database to be hosted in Europe, we can select an appropriate European region.

That choice matters, but it does not finish the job.

A European database can still have terrible permissions. An account can still be compromised. A former contractor can still have access six months after leaving. Personal information can still appear in an email, an error log or a spreadsheet downloaded by somebody who has forgotten it exists.

You can put every database in exactly the requested country and still give the wrong people access to everything.

It would be a very geographically accurate breach.

The server location does not decide which laws apply

This is where the confident comments usually begin to wobble.

Privacy laws do not simply inspect the server, read the country name and go home.

The GDPR can apply when an organisation is established in the EU, regardless of where the processing happens. It can also apply to some organisations outside the EU when they offer goods or services to people in the EU or monitor their behaviour there. That is part of the GDPR’s territorial scope under Article 3.

Brazil’s LGPD also looks at more than the location of the company’s headquarters or database. Its scope can include processing carried out in Brazil, services aimed at people in Brazil and personal data collected there. The official English version of the law explains that in Article 3.

California is another useful example because people mention “Californian data” as though one email address from Los Angeles immediately transforms a small Portuguese company into Meta.

The CCPA applies to certain for-profit businesses that do business in California and meet specific thresholds. Those thresholds include revenue, the amount of personal information handled and how much income comes from selling or sharing that information. The California Attorney General’s CCPA guidance explains the criteria.

This does not mean smaller businesses have no privacy responsibilities. Other laws, contracts and industry requirements may still apply.

It means you cannot decide which law governs a business from a two-line description of its software.

You need to know what the business does, where it operates, who its customers are, what information it collects and why it collects it.

Unfortunately, that takes longer than typing “California, Europe, Brazil” and adding a warning emoji.

Regional hosting can still be the right decision

None of this means data location is irrelevant.

Keeping data in a particular region may be required by a customer contract. It may make international data transfers easier to manage. It may help with performance, procurement or an organisation’s internal policies.

If a client tells us their data needs to remain in a particular region, that requirement should affect how the system is designed.

What we should not do is pretend that selecting “Europe” from a dropdown makes the entire application GDPR compliant.

It does not inspect the client’s privacy policy. It does not decide whether the business has a lawful reason to collect the information. It does not remove old accounts, define retention periods, respond to access requests or stop an employee downloading a customer list.

The server location is one decision inside a much larger system.

The database is not the only place information goes

A customer fills in a form.

The information enters the main database, but that may not be the end of its journey.

The system might also:

• Send part of it through an email provider.
• Add the person to a mailing platform.
• Create a record in a customer management system.
• Send payment information to Stripe.
• Store an uploaded file in a separate storage service.
• Record an error in a monitoring tool.
• Include details in an internal notification.
• Copy data into a testing environment.
• Allow a team member to export it into a spreadsheet.
• Send text to an AI service to generate a summary or response.

That does not automatically make the application unsafe. Modern software is usually built from several specialised services.

It does mean that answering “Where is the data?” requires more than pointing at the database provider.

We need to know where the information travels, which services receive it, what each service keeps and who can access those accounts.

If somebody cannot explain that journey, the problem is not that they used Supabase, Stripe or an email provider. The problem is that they connected a collection of services without keeping track of what they were sending to each one.

Keeping data nearby does not protect it from people nearby

A database can be hosted in the correct country, encrypted and sitting inside a provider with an impressive security page.

And here comes another thing I keep repeating, because businesses keep doing it: somebody gives twelve people administrator access because setting up proper permissions felt annoying.

An old freelancer still has access to the project. Everybody shares one account. Production data gets copied into a development project so somebody can test a button. Then a team member falls for a convincing login email and nobody even knows which account was used.

Yes, we have covered this before. Apparently access control is going to become the recurring guest star of this series.

Where the server lives will not fix any of it.

Location matters when location matters. Access matters every day.

That is why we need to think about who can view, change, export and delete information. We also need to know whether access can be removed quickly and whether the system records important actions.

Checking all of that takes actual work. Announcing that the database is in Frankfurt takes five seconds and sounds technical enough to end the conversation, which probably explains the preference.

Hosting data abroad is not automatically illegal either

Another popular performance is announcing that information crossed a border, therefore the business has broken the law.

International transfers can absolutely create legal obligations. Under the GDPR, for example, transfers of personal information outside the relevant area must meet specific conditions. Depending on the situation, that may involve an adequacy decision, contractual safeguards or another recognised mechanism.

It still is not as simple as:

Foreign server = illegal.

The correct setup depends on the organisations involved, the countries, the type of information, the contracts and the services being used.

This is the point where the business needs advice from a qualified lawyer. The lawyer can work out which rules apply, while the developer explains how the system works and implements any technical requirements.

By the way, the same legal questions exist when a business buys SaaS. Funny how the people lecturing custom developers about Californian, European and Brazilian data suddenly become much less curious when the software happens to be the platform in their affiliate link.

HighLevel still does not include a tiny privacy lawyer in the monthly subscription.

Using HighLevel, ClickFunnels, HubSpot or another ready-made platform does not answer the legal questions for the customer. The business still decides what information to collect, why it wants that information, who it contacts and how long it keeps everything.

The SaaS provider has responsibilities for the part it operates, but it does not become the customer’s lawyer.

HighLevel’s own GDPR documentation says that its customers act as controllers of the information they upload, while HighLevel acts as the processor. It also recommends contacting a legal specialist when advice is needed.

Its security and compliance overview is even more direct:

“Use of the HighLevel product alone does not make you GDPR compliant.”

There it is, from HighLevel itself.

A HighLevel subscription gives the business access to HighLevel. It does not review the business’s data collection, write its privacy policy or decide whether its campaigns are lawful.

We are developers, not privacy lawyers

We know the basics because we need to.

We need to understand that different kinds of information carry different risks. We need to ask where a business operates, identify the services receiving its data and recognise when a decision may have legal consequences.

If the client takes the project to a lawyer, we should be able to provide a clear list of what information the application collects, where it goes, which providers are involved and who can access it.

What we cannot do is declare that a client’s entire business is legally compliant.

That requires somebody qualified to look at the business itself, the information it collects, its contracts, its customers and the countries involved.

Some clients will not want to hire a lawyer because lawyers cost money. I get it. But I do not become the free legal department because I am already building the software.

I can document what the system does and point out when a legal answer is needed. I cannot decide which laws apply to their whole business or promise that they are compliant. If I recommend legal advice and the client chooses to skip it, that choice is theirs.

In many privacy laws, the organisation deciding why information is collected and what happens to it has its own responsibilities. Under the GDPR, that organisation is usually called the controller. Under other laws, different terminology may be used.

For a typical client project, that is often the customer’s business.

Hiring a developer does not quietly transfer those responsibilities to the developer. Paying a monthly SaaS subscription does not transfer them either.

The customer still needs appropriate legal advice and must decide what its business is permitted or required to do.

That does not let the developer or SaaS provider wash their hands of everything either.

Developers and service providers may have their own legal and contractual duties. At a practical level, we are responsible for building what we agreed to build, protecting the system properly, following the client’s instructions and warning them when we see an obvious risk.

The client handles the legal decisions with a lawyer. We provide the technical facts and implement those decisions correctly.

Nobody gets to point at the other person and pretend the problem belongs entirely to them.

Business owners should not have to learn all of this terminology

A business owner hiring someone to build software should not need to arrive with a prepared list of questions about data residency, international transfers, encryption keys, subprocessors and retention policies.

That is part of what they are hiring expertise for.

The developer should be able to explain, in normal language:

• What information the application collects.
• Why the application needs it.
• Which services receive it.
• Where the main information is stored.
• Who can access it.
• Whether staff can export it.
• How long it is kept.
• How it can be corrected or deleted.
• What happens if an account or service is compromised.
• Which decisions require advice from a lawyer.

The customer can then take an accurate picture of the system to a qualified legal adviser.

That is much more useful than asking a lawyer to review “an app with Supabase somewhere in it.”

Put the map in its proper place

Data residency matters.

International transfers matter.

Privacy laws matter.

But none of them can be understood from a provider name, a server location or an alarming comment from somebody who knows nothing about the application.

First, find out what information the business collects and why.

Then map where it goes, where it is stored, who can access it and which outside services receive it.

After that, the customer can get legal advice based on the actual business rather than a collection of hypothetical disasters.

If somebody names California, Europe and Brazil before asking what the application stores, they are not mapping your data.

They are listing places.