Every conversation your team handles contains personal data. Over months and years of operation, your platform builds a detailed, sensitive record of your customers and their relationship with your organisation. Most support operations managers have not yet considered what that means, but that is starting to change.

The EU Data Act is now in force. It sets binding rules around where customer data can be stored, who can access it, and whether you have the right to move it. As most businesses run their support operations on US cloud infrastructure, the problem that creates is structural: if a provider is subject to US jurisdiction, full GDPR compliance cannot be guaranteed, and the Data Act makes that gap harder to ignore.

The EU Data Act is already in force and already applies to your platform

The EU Data Act became applicable on 12 September 2025. Its cloud switching provisions, set out in Chapter VI of the regulation, apply directly to providers of data processing services. That definition covers infrastructure as a service, platform as a service, and many software as a service tools, including the customer service platforms most support teams use every day.

The regulation was designed to end vendor lock-in. Before the Data Act, switching cloud providers was technically possible but practically difficult. High egress fees, opaque export processes, and fragmented data architectures meant that most organisations stayed with their existing providers by default rather than by choice.

The Data Act changes that. Cloud providers must now remove the commercial, technical, and contractual barriers that previously made leaving difficult. They must specify in their contracts exactly which data categories can be exported during a switch. Customers can terminate on no more than two months’ notice. A transition period of up to 30 days follows, during which the migration happens, and a further data retrieval period of at least 30 days applies after that.

Switching Fees Are Being Phased Out Too

From January 2027, most switching-related charges, including fees for data transfer and reformatting, must be eliminated. That deadline is closer than it appears, and the organisations that understand their data portability position now will be far better placed to act on it.

Data Residency Is Not the Same as Data Sovereignty

This is one of the most important distinctions in EU data governance, and one of the most common sources of false confidence among support teams.

Many organisations assume that because their provider stores data in Europe, they have met their obligations. That assumption is often wrong.

Data residency refers to the physical location of the servers where your data is stored. A provider offering EU data residency is telling you that your data sits in facilities within the European Union. That is a meaningful commitment. It is not, however, the whole story.

A provider can store data in an EU data centre while operating under governance structures that allow non-EU entities to access that data. The most prominent example is the US CLOUD Act, which allows American authorities to compel US-based cloud providers to produce data held on their servers, regardless of where those servers are physically located.

If your support platform is operated by a US-headquartered company, the physical location of the data does not protect it from access under US law. Regulators in Austria and France have already found that the use of US-operated tools violated GDPR, on the grounds that data transfers to the US lacked adequate safeguards. The same logic applies to any cloud platform operated by a US parent company.

What genuine data sovereignty actually requires

Data sovereignty means your data is governed by the laws of the jurisdiction you operate in, with access controlled in a way consistent with those laws. Achieving it requires infrastructure that operates under EU law, a provider whose corporate structure is not subject to non-EU legal demands for data access, configurable access controls your organisation manages directly, and full transparency over subprocessors and third-party data flows.

In other words: data residency gives you the appearance of compliance. Data sovereignty gives you the substance of it.

Why your support platform carries the highest data risk in your organisation

There are many systems in a modern organisation that handle personal data. HR platforms, CRM systems, marketing tools, and payment processors all hold information about individuals. But the customer support platform occupies a distinctive position. It processes the highest volume and broadest range of personal data in real time, and it is typically the system that has received the least scrutiny from a data governance perspective.

Consider a mid-sized support operation handling five hundred interactions per day. That is over a hundred thousand interactions per year. Each one contains personal data. Many contain sensitive personal data: financial details, account credentials, complaint records, health-related information. Over time, the volume alone creates significant risk.

The fragmentation problem

Most support operations compound that risk through fragmentation. Email is handled in one system, live chat in another, voice calls logged separately, social media messages handled somewhere else. Customer data ends up distributed across tools with no single point of visibility or control.

When a customer requests access to their data under GDPR, your team must locate and compile records across every system. When a supervisory authority asks where a specific piece of information is stored, you need a confident answer. When a team member leaves and their access needs removing, that change must be made across every platform they used. With fragmented tools, none of this is straightforward.

The access and retention gap

Support platforms are collaborative by nature. Multiple team members access the same customer data, often simultaneously. Supervisors review conversations. Quality teams audit records. Contractors or offshore teams may have access. Without configurable access controls, demonstrating that data access is restricted to those who need it, which is a core GDPR requirement, becomes very difficult.

Retention is the other common gap. GDPR requires that personal data is not kept longer than necessary. Many platforms make it technically possible to configure retention settings but require specialist knowledge or third-party support to do so in practice. If your team cannot set and automate retention rules without developer involvement, you are likely carrying retention risk you are not aware of.

The questions your provider should be able to answer

Genuine data sovereignty translates into concrete capabilities. A provider that takes data governance seriously should be able to answer the following questions promptly and with documentation.

• Where exactly is your customer data stored? Not somewhere in Europe, but specifically which data centres, in which countries, operated by which company, under which legal framework. 
• Who has access to it, and can your organisation control that at a granular level? 
• Can you set your own retention policies and automate deletion when records reach their limit? 
• Is all your customer communication in one system, or is it fragmented across tools with separate governance frameworks? 
• Can you respond to a data subject access request within the one-month GDPR deadline? And if a supervisory authority requested your compliance documentation tomorrow, could you produce it?

If any of these questions cannot be answered confidently based on documented information from your provider, those gaps carry real regulatory risk.

What a sovereign-ready support platform looks like in practice

A platform built for data sovereignty brings all customer communication into a single unified workspace. Email, voice, live chat, WhatsApp, and social media messaging handled in the same system, under the same data governance framework, with a consistent data architecture across every channel.

This is the foundation of data governance. When conversations are spread across five separate tools, each with its own access model and retention defaults, there is no unified governance. A single platform means every conversation is stored in one place, under consistent access controls, subject to the same retention rules, and searchable as a single source of truth when a compliance question arises.

Access controls that your organisation manages

In a properly governed support platform, every user has access only to what they need. Roles and permissions are defined at a granular level. A team leader in one department cannot access conversations from another unless that access has been explicitly granted. An external contractor can be given time-limited access that expires automatically. A full audit log records every action taken, by whom, and when. That log is exportable and retained in line with your own governance policies.

Retention that you configure without developer support

Retention management should be accessible to the people responsible for it. Your platform should allow you to set rules for different types of communication and different data categories, automate the archiving and deletion of records when they reach their limit, and produce documentation showing that your practices are consistent with GDPR. If configuring retention requires a support ticket or developer resource, that is a governance gap.

On-premise deployment for complete infrastructure control

For organisations with the highest governance requirements, cloud deployment may not be sufficient. On-premise deployment means the platform runs entirely on your own servers, under your direct control. No data leaves your infrastructure unless you explicitly choose to share it. Not all customer support platforms offer this. For teams in regulated industries or handling particularly sensitive data, it provides a level of certainty that no cloud-based solution can match.

The infrastructure decision that determines your compliance position

The EU Data Act does not just impose obligations on your vendors. It creates a clear opportunity to assess whether your current platform was built with data control in mind.

The organisations best positioned as the regulatory environment continues to tighten are not necessarily the largest or the most resourced. They are the ones that chose infrastructure built for control, asked the right questions early, and did not rely on a vendor’s data centre location as a substitute for genuine sovereignty.

FocalScope is built for exactly this.

A single platform for email, voice, live chat, WhatsApp, SMS, and social media, with granular access controls your team manages directly, configurable retention without developer support, and full audit logging across every channel. Deployment options include on-premise and hybrid on Microsoft SQL Server, for organisations that need complete infrastructure control.