Where Does Your Business Data Actually Live? Cloud Software and Data Residency

When a business adopts cloud software, the data it generates goes somewhere. For many businesses, the exact answer to "where?" is unclear — buried in a privacy policy, distributed across multiple vendors' infrastructure, or simply not thought about. For UK businesses handling personal data under UK GDPR, not knowing is not a neutral position. It is a compliance gap.

The Problem with "Cloud" as an Answer

Cloud is not a location. It is a marketing term. When a SaaS vendor says their product is "cloud-based", that tells you nothing about where your data physically resides, who has access to it, or under which country's laws it operates.

The practical reality for many UK SMEs using popular cloud software is that their data sits on servers in the United States. This creates several layers of complexity under UK GDPR. Transferring personal data from the UK to a third country requires either an adequacy decision (the UK currently maintains several, including for the US under the UK-US data bridge), standard contractual clauses, or binding corporate rules. Most businesses using US-hosted SaaS are technically relying on these mechanisms without being aware of them.

The simpler approach — and the one that eliminates the transfer question entirely — is using infrastructure that keeps data in the UK from the outset.

What Azure UK South Means in Practice

For the bespoke systems I build, all data infrastructure runs on Azure UK South, physically located in London. This is not an assumption or a hope — Microsoft publishes the physical locations of their data centres and provides contractual data residency commitments for each Azure service.

For Azure SQL, the database engine, data at rest does not leave the UK South region. Backups are stored in the same region unless explicitly configured otherwise. Azure Blob Storage, used for document and file storage, operates on the same basis.

This means that for clients such as NT Labs, Buxted Construction, and Dugard, the operational and personal data their systems handle stays within the United Kingdom. The list of data processors is known and limited: Microsoft as the infrastructure provider, and SWF Consultancy as the software developer and maintainer. There are no unknown sub-processors, no analytics platforms receiving copies of data, no third-party integrations quietly sending records elsewhere.

Compare this with a typical SaaS product: the main vendor, their cloud infrastructure provider (often AWS US East), their analytics platform, their customer support tool, their billing processor, their email service. Each is a data processor. Each may operate in a different jurisdiction. The combined data processing picture is complex, and most users have never read the sub-processor list.

GDPR's Records of Processing Activities

Under UK GDPR Article 30, businesses with more than 250 employees — and smaller businesses in certain circumstances — are required to maintain records of processing activities (RoPA). This document maps what personal data you hold, why you hold it, where it is stored, who has access, and how long it is retained.

Bespoke software simplifies this considerably. The data sits in a known database, in a known Azure region, processed by a known set of people under a known contract. The RoPA entry for the bespoke system is straightforward to write and to keep accurate.

For businesses running their operations across a collection of SaaS products — each with their own data storage, their own sub-processors, their own retention policies — constructing an accurate RoPA becomes a significant exercise. It requires reading the privacy policy and DPA of every product, mapping where data flows between them, and tracking when any of those policies change.

This is not an argument against SaaS per se. It is an argument for understanding what you are adopting and for ensuring that your data processing map remains accurate and auditable. Regulated industries — financial services, healthcare, legal, food manufacturing — face particular scrutiny here, and the compliance overhead of a fragmented SaaS estate is real.

Commercially Sensitive Data: Beyond GDPR

GDPR covers personal data. But many businesses also hold commercially sensitive information that does not relate to identifiable individuals — pricing models, supplier terms, product formulations, client acquisition strategies, financial forecasts.

This data has no specific regulatory framework, but it carries obvious commercial value. Storing it in a system where the terms of service give the vendor broad rights to analyse usage, improve their product, or share aggregated data is worth examining carefully. Most SaaS terms are written to permit the vendor considerable latitude with data generated within their platform.

For systems where the commercial sensitivity of the data is high — such as Dugard's pricing and quotation system or NT Labs' product formulation records — keeping data within a controlled, bespoke environment with no third-party analytical access is the right approach.

The Question to Ask of Every Software Product

For any software product your business uses that holds personal or commercially sensitive data, there are four questions worth answering:

Where is the data physically stored? Get a specific answer — country, region, data centre provider — not just "the cloud".

Who are the sub-processors? Every SaaS vendor should publish a list. If they do not, that is worth noting.

Is there a Data Processing Agreement in place? Under UK GDPR, there must be one for every processor. If there is not, you are non-compliant regardless of the vendor's practices.

What happens to your data if you stop using the product? Is there an export? How long does the vendor retain it after cancellation? Can they delete it on request?

The answers to these questions shape your actual data risk profile — not the vendor's marketing around "security" and "compliance". The security of how data is accessed is one dimension; where it lives and who can see it is another.

For businesses at the point of commissioning new software, or reviewing existing arrangements, these questions are worth answering before signing rather than after. If you want to understand how a bespoke system would handle your specific data requirements, get in touch.

Frequently Asked Questions

Does GDPR require business data to stay in the UK?

Not automatically, but international transfers — moving personal data outside the UK — require a legal basis. For most SMEs, this means either using a provider with UK-based servers or relying on adequacy decisions and standard contractual clauses. The simplest approach is choosing infrastructure that keeps data in the UK, which eliminates the transfer question entirely.

What is a data processing agreement and do I need one?

A Data Processing Agreement (DPA) is a contract between you (the data controller) and any third party that processes personal data on your behalf (a data processor). Under UK GDPR Article 28, you are required to have one in place with every data processor. Most SaaS vendors provide a standard DPA — the question is whether you have read it and whether it actually covers your data processing activities.

How do I find out where my current software stores data?

Start with the privacy policy and DPA of each software product you use. Look for 'data storage location', 'hosting', or 'infrastructure'. If it says 'US East' or similar, your data is in the United States. If it says 'EU' without specifying, check whether that includes UK post-Brexit. If you cannot find the information, that itself is a concern worth raising with the vendor.

Is Azure UK South actually in the UK?

Yes — Azure UK South is physically located in London, and Azure UK West in Cardiff. Data stored in these regions stays within the United Kingdom. Microsoft publishes their data centre locations and the data residency commitments for each Azure service. For Azure SQL, Azure Blob Storage, and Azure App Service in UK South, data at rest does not leave the UK.

What business data should I be most concerned about?

Under UK GDPR, personal data is the primary concern — customer records, employee data, contact details, financial information relating to individuals. Special category data (health, biometric, religious beliefs) carries higher obligations. Beyond GDPR, commercially sensitive data — pricing models, client lists, formulations, supplier terms — should also be stored and processed with care for confidentiality, regardless of whether it is strictly personal data.

What is a Records of Processing Activities document and do I need one?

A Records of Processing Activities (RoPA) is a GDPR requirement under Article 30 — a document mapping what personal data your business holds, why, where it is stored, who has access, and how long it is retained. Businesses with more than 250 employees are required to maintain one; smaller businesses handling regular, high-risk, or special category data should also do so. Bespoke software with known, limited data processors simplifies the RoPA considerably compared to a fragmented SaaS estate.

How does bespoke software simplify GDPR compliance compared to multiple SaaS products?

A typical SaaS product involves the main vendor, their cloud infrastructure provider, analytics platforms, customer support tools, and billing processors — each a data processor, each potentially in a different jurisdiction, each with their own sub-processor lists. A bespoke system built on Azure UK South with a known set of processors has a straightforward data processing picture. The RoPA entry is clear, the transfer question is answered, and there are no unknown third parties receiving copies of your client data.

What happens to my data if a SaaS vendor closes or changes their terms?

It depends on what their terms allow and what export options exist. Some vendors provide a data export on cancellation; others retain data for a period after account closure; a few make extraction difficult or expensive. Vendors that cease trading may give minimal notice. The prudent approach for any operationally critical SaaS product is to test the export function with real data before you are in a position where you need it urgently.

What are sub-processors and why do they matter for data compliance?

A sub-processor is a third party that a SaaS vendor engages to help process your data — their hosting provider, analytics platform, customer support tool, or billing processor. Under UK GDPR, you as the data controller are responsible for ensuring that all processors and sub-processors meet the required standards. Every SaaS vendor should publish a sub-processor list. If yours does not, or if the list includes processors in jurisdictions without adequacy decisions, that is a compliance gap worth addressing.

How do I get started if I want my data kept in the UK on a bespoke system?

The first step is a conversation about your current systems, what data they hold, and what your specific compliance requirements are. You'll get an honest assessment of whether the investment in bespoke software makes sense for your situation, and what a system built on Azure UK South with known, limited data processors would look like for your specific operations. Get in touch to start the conversation.