Outsourcing European customer support is routine and entirely permissible. What is not permissible is discovering the data questions after go-live, because the obligations sit with you rather than your provider. GDPR applies to the personal data of people in the EU, and a support programme handles that data all day: names, addresses, order histories, account details, the content of every call and chat.

This article sets out the questions to settle before a European customer's data reaches an outsourced team. It covers roles, the written agreement, where processing happens, what data the team actually needs, recording, individual requests, and how to rehearse all of it during onboarding. It is general information rather than legal advice. The specifics of your obligations are for your data protection officer or counsel to confirm, and every recommendation here should be checked with them.

In practical terms it means three things matter before anything else: who is responsible for the data and who acts on their instructions, where the data is processed and by whom, and whether the arrangement is written down properly. Get those three settled and the rest of the programme, from training and systems to quality and reporting, can be built on top. Skip them and every later decision is provisional.

Roles: who decides and who acts

In almost every support arrangement you decide why customer data is collected and what is done with it, and the provider handles it on your instructions. Those are different roles with different responsibilities, and the regulation treats them differently. The accountability for the customer's data stays with the business whose customer it is. A provider's assurances do not transfer the obligation; they describe how the provider will help you meet it.

Your counsel or DPO will confirm how the roles apply to your specific arrangement, and there are situations where a provider takes on more responsibility than the usual pattern. What matters at the scoping stage is that both parties agree, in writing, which role each holds and what that means for the instructions the provider must follow.

In practice the split is straightforward. You decide what data is collected, why, how long it is kept and who may see it. Our agents handle the contacts inside those rules, record what the workflow tells them to record, and escalate anything outside the agreed scope. Nothing about the purpose of processing is decided on the floor.

The written agreement

The agreement covering the data is not a formality attached to the commercial contract. It is the document that says what the provider may do with the data, for what purpose, for how long, with what security measures, and what happens at the end. Your DPO or counsel will specify what it has to contain; expect it to address the purpose and scope of processing, the categories of data and people involved, the security measures, the use of other companies by the provider, what happens when an individual makes a request, and deletion or return of the data when the engagement ends.

We work from your instructions and your agreement. The scoping call is where the data categories and the purpose are agreed, and the project manager maps the process against them before agents are trained, so that nothing outside the agreed scope is collected by habit.

Where the data is processed

Processing location matters. Processing inside the EU keeps the transfer question simple, which is much of why Poland, Romania, and Bulgaria feature heavily in European support strategies; the European coverage page sets out the delivery options. Processing outside the EU is possible with an appropriate mechanism in place, but it needs a documented basis rather than an assumption, and which mechanism applies is a question for counsel.

Location is broader than the agents' desks. It includes where the ticketing system is hosted, where recordings are stored, where backups sit, where the quality reviewers work, and where any subcontractor the provider uses is located. Ask for the full list, with countries, and keep it current.

A provider rarely works alone. The telephony platform, the ticketing system, the recording store, the quality tool and the workforce management system are usually other companies' services, each processing your customers' data somewhere. Ask directly which companies touch this data, in which countries, and how you are told when that changes. A provider who cannot produce the list has not mapped their own processing, which is a signal about everything else.

What data actually reaches the team

The simplest control is to send less. A support agent needs enough of the customer's record to resolve the contact, not the whole record. Before launch, decide field by field what agents can see and what they can change:

  • Identity and contact details needed to verify the caller and reply.
  • Order, account or case history relevant to support, not the full commercial record.
  • Payment information only as a masked reference, never full card or bank details.
  • Sensitive categories, health for example, only where the service genuinely requires them and counsel has confirmed the basis.
  • Nothing exported to spreadsheets or shared drives outside the system that enforces the permissions.

Call recording and chat logs

Role-based access and controlled permissions are how our agent environments are run; the scope of that access is set with you during onboarding and reviewed when the process changes. The data security article covers the broader controls. Recording deserves its own decision.

Recording is processing. Establish the basis for recording, how callers are informed, how long recordings and chat transcripts are kept, who can access them, and how they are deleted. Indefinite retention because nobody chose a period is a common and avoidable finding. Quality review needs recordings; it does not need them forever, and a retention period tied to the review cycle is usually enough.

Also decide where recordings live. A recording platform hosted in a different region from the agents is a transfer, whether or not anyone thought of it that way, and it belongs on the location list above.

Chat and email carry the same question in a quieter form. Transcripts and threads accumulate in the helpdesk, and the helpdesk's own retention setting is often the only one anyone set. Check it, and align it with the recording decision.

Requests from individuals

People can ask what data is held about them, ask for it to be corrected, and ask for it to be deleted, and those requests have to be answered within the time the regulation allows, which your DPO will confirm. That includes data held by your provider: the ticket history, the recordings, the notes. Agree how a request reaches the provider, who owns it, how quickly they must respond to you, and how deletion is confirmed across every system including backups.

Rehearse a data subject request during onboarding. Discovering the gap during a live one is a bad time to find out.

Security controls a buyer should ask about

The regulation asks for measures appropriate to the risk; it does not prescribe a list. For a support programme the controls that matter are practical: access limited to the role, individual logins so actions are attributable, screen and device controls at the workstation, encryption of stored recordings and transcripts, secure disposal at the end of retention, and a documented process for handling a security incident that includes telling you quickly. Ask a provider to describe each, ask who checks them, and ask to see the incident process. Ask any provider for the documents behind any certification or compliance claim they make, and have your DPO read them.

Onboarding: rehearse before go-live

The strategy phase, where our project manager maps the process and prepares the systems, is where all of the above becomes concrete. The agreement is signed, the access list is set, the retention periods are configured, the recording announcement is written, and the request process is walked through end to end with a test request. Agents are trained on the handling rules alongside the product and the tone, and quality review scores adherence to them from the first week.

The reporting rhythm agreed up front should include the data items: access reviews completed, requests received and closed, incidents, and changes to the sub-processor list. That keeps the subject visible after launch rather than filed away with the contract.

When to wait, and what to ask a provider

It is the wrong move when you cannot yet describe what data the support process needs, when your own retention and recording policies do not exist, when there is nobody on your side to own the agreement and the requests, or when the data is so sensitive that counsel advises against any external processing. Those are gaps in the business, not in the provider, and a provider cannot close them for you. Settle them first, then outsource.

Ask which role they take and whether they will sign your agreement or expect you to sign theirs. Ask where every part of the processing happens, including subcontractors and hosting. Ask what data they need and whether they will work with less. Ask how recordings are retained and deleted. Ask how a request from an individual is handled and how fast. Ask how an incident is reported to you. Ask for the documents behind any security or compliance claim. Then take the answers to your DPO or counsel before signing. Our customer support page covers the service itself; the questions above are what turn it into a programme you can defend.