EU Representative for SaaS Companies: Do You Actually Need One?

By Trusteraai Team | Last reviewed: October 2026

You sign your first customer in Spain. Within a week, someone tells you your US SaaS company “needs an EU representative.” It might be a customer’s legal team, a consultant, or a vendor’s sales rep. Sometimes they’re right. But they’re often stating a conclusion the law only supports after a few questions have been answered.

This guide explains when an EU representative for SaaS companies is actually required, and walks through the questions in order. It covers the GDPR’s Article 27 representative, the separate authorised-representative rules in the EU AI Act, and how both differ from a Data Protection Officer. It doesn’t promote any representative provider. The useful part is deciding whether you need one, and what to look for if you do. If you’re also working through your wider Spain obligations, the Spain GDPR Checklist for SaaS covers the bigger picture.

Quick Answer: When Does a SaaS Company Need an EU Representative?

Under the GDPR, a non-EU company must designate an Article 27 representative when all of the following are true:

1. The relevant processing falls within Article 3(2). It relates to offering goods or services to data subjects who are in the Union or monitoring their behaviour there.
2. The controller or processor is not established in the Union. Assess any EU presence and its relationship to the relevant processing rather than assuming that an EU customer, representative or group company automatically settles the question.
3. The Article 27(2) exemption does not apply. Check all the conditions of the narrow exemption for certain occasional, low-risk processing.

Apply this test separately to the relevant controller or processor and its processing activities. A company may have different roles across its product, customer, account, and marketing data.

Many non-EU SaaS companies that deliberately serve EU customers need to assess Article 27, but the outcome depends on their activities, their role in the processing, and the exemption analysis. It is not an automatic result of selling a subscription into Spain.

The EU AI Act is a separate assessment, not a fourth condition of the GDPR test. It can require an authorised representative from non-EU providers of high-risk AI systems (Article 22) and of general-purpose AI models (Article 54). Far fewer SaaS companies fall into those categories.

Two points hold either way. A representative is not a Data Protection Officer, and appointing one does not transfer your GDPR responsibility to them.

A Quick Decision Path

1. Does the GDPR apply to the relevant processing? Assess Article 3(1) first where processing takes place in the context of an EU establishment’s activities. If that route does not apply, assess whether Article 3(2) brings the processing within scope because the organisation offers goods or services to people in the EU or monitors their behaviour there.
2. Do you have an EU establishment relevant under Article 3(1)? If so, assess that route instead of automatically applying Article 27.
3. Does the Article 27(2) exemption apply? Check every required condition, and write down your reasoning.
4. Document the conclusion. If appointment is required, appoint a representative by written mandate and update your notices and records.

This is an illustrative decision aid, not a legal determination.

What an EU Representative for SaaS Companies Actually Does

Article 27 asks certain non-EU companies to name a person or company established in the EU (defined in Article 4(17)) that regulators and individuals can contact on their behalf. The appointment must be in writing. Under Article 27(4), the representative can be addressed, in addition to or instead of you, by supervisory authorities and data subjects on all issues related to your processing.

In practice, that makes the representative a contact point. The EDPB’s guidelines on territorial scope describe duties such as keeping a copy of your records of processing (Article 30) and cooperating with supervisory authorities, including answering information requests. Those duties should not be read as an exhaustive list of everything a representative may be responsible for. The scope of the role is set by applicable law and by the written mandate you agree with them.

Here is what a representative is not:

• Not a DPO. The EDPB’s guidelines take the position that the same external person can’t be both. A representative acts under your mandate, while a DPO has to work independently. This position comes from EDPB guidance, not from the text of Article 27 itself.
• Not your compliance department. It doesn’t write your privacy notice, run your impact assessments, or make decisions for you.
• Not a liability shield. Article 27(5) says designating a representative doesn’t prevent legal action against you as the controller or processor. Your GDPR responsibility stays with you.
• Not an EU establishment. The EDPB confirms that designating a representative doesn’t create one.

Failing to designate a required representative may fall within the fine tier set out in Article 83(4), which provides for a maximum of €10 million or 2% of total worldwide annual turnover, whichever is higher. That is a ceiling, not an automatic penalty. Actual fines depend on the circumstances, but it’s not something to ignore.

The EU Representation Stack™

This is our practical framework for working through the question, not an official legal test. Work through four layers in order. Each one narrows the answer and produces something you can document.

Layer	Key question	Output
1. Scope Test	Does EU law reach our processing at all?	A written Article 3 conclusion, plus an AI Act scope view
2. Establishment & Exemption Test	Do we have an EU establishment, or does an exemption apply?	A documented rationale for the Article 27 conclusion
3. Representative Mapping	Which representative roles might apply to us?	A short list: GDPR, AI Act, UK, DPO
4. Appointment & Documentation	How do we appoint, publish, and maintain it?	Signed mandate, updated notices and records

Layer 1: Does the GDPR Reach You?

Article 3(2) can bring a non-EU controller or processor within the GDPR where the relevant processing relates to offering goods or services to data subjects who are in the Union, or to monitoring their behaviour there. Without one of those, Article 27 doesn’t come into play. The EDPB also stresses that territorial scope is assessed in relation to specific processing activities, not for a company as a whole.

Offering services to people in the EU

The GDPR looks for intention. Recital 23 says mere accessibility of your website from the EU isn’t enough. It points instead to signals such as using a language or currency of a Member State and mentioning customers who are in the EU. For a company selling into Spain, the realistic signals look like this:

• A Spanish-language website, app interface, or onboarding flow
• Euro pricing or invoicing
• Sales or support people assigned to cover Spain
• Spanish customers named in case studies or on your logo wall
• Ads or outreach geo-targeted at Spain
• A country page or a .es domain

No single signal decides it. What matters is the overall picture. These examples show how it can play out:

Scenario	Article 3(2) likely?	Why
US HR-tech SaaS with a Spanish onboarding flow and a customer-success contact in Madrid	Likely yes	Deliberate offer of services to people in Spain
English-only US developer API, no EU marketing, a few EU sign-ups arriving on their own	Not necessarily	Accessibility alone isn’t targeting, though you should revisit it if EU usage grows
US analytics SaaS that tracks how visitors behave on customers’ EU websites	Potentially yes	The outcome depends on whether the provider’s own activities involve monitoring the behaviour of people in the EU, taking account of the nature and purpose of the tracking and the processing involved
US AI note-taking app with a free tier and euro pricing on paid plans	Likely yes	Free services count, and euro pricing is a targeting signal

These are illustrations, not legal determinations.

Monitoring behaviour

Monitoring behaviour generally involves tracking individuals in the Union and subsequently using data about them to analyse or predict their behaviour. Behavioural profiling and location tracking may qualify. Whether usage analytics fall within Article 3(2) depends on the tracking method, purpose, and whether the processing concerns identifiable individuals. Genuinely anonymous aggregate statistics generally present a different case, but assess the underlying collection and processing rather than relying on the aggregate output alone.

What if you only sell B2B, or you’re a processor?

This is where founders most often over- or under-reach, so keep three questions separate:

1. Does the GDPR apply to the particular processing under Article 3?
2. Is your company acting as a controller, a processor, or both for that processing?
3. Does Article 27 require your company to designate a representative?

Your EU customer’s GDPR obligations do not automatically create your separate Article 27 obligation as its vendor. Selling to businesses doesn’t take you outside the GDPR automatically, because your customers’ employees and end users are individuals. But the fact that your customer is bound by the GDPR doesn’t answer question 3 for you.

An EU-established controller remains responsible for assessing and meeting its own GDPR obligations when it uses a non-EU processor. Outsourcing processing does not, by itself, remove the controller’s processing from the GDPR’s scope. The controller must put the required Article 28 terms in place through a Data Processing Agreement (DPA), and ensure that its choice of processor meets the GDPR’s requirements.

The processor’s own territorial scope must be assessed separately. A non-EU processor does not automatically become subject to the GDPR simply because it processes personal data for an EU-established controller. Article 27 expressly covers non-EU controllers and processors whose relevant processing falls within Article 3(2), subject to the Article 27(2) exemption. Assess the processor’s own activities, establishment and role in the arrangement before concluding whether it must appoint a representative. Where the position is uncertain, obtain advice on the specific facts.

You can be both roles at once: a controller for your own account and marketing data, and a processor for your customers’ data. The EDPB says one representative can cover multiple processing activities, so you don’t need a separate appointment for each.

Layer 2: Do You Have an EU Establishment, and Does an Exemption Apply?

Establishment

If you already have an establishment in the EU and the processing happens in the context of its activities, Article 3(1) governs and Article 27 isn’t the route. “Establishment” is read functionally. Recital 22 looks for real and effective activity through stable arrangements, not legal form. Depending on the facts, even a small EU presence involved in the activity can matter, though the EDPB cautions against stretching the concept too far.

The practical takeaway is that hiring your first employee in Madrid, or opening an EU subsidiary, is a trigger to rerun this analysis. A representative doesn’t count as an establishment.

The exemption

Article 27(2) exempts public authorities, and it exempts processing that meets all three of these conditions:

Condition	Question to ask	Why it’s hard for SaaS
Occasional	Is the processing occasional rather than part of the organisation’s normal operations?	Subscription products process account, usage, and support data continuously
No large-scale processing of special-category data under Article 9(1), or of personal data relating to criminal convictions and offences under Article 10	Is the processing free of large-scale processing of Article 9(1) special-category data and Article 10 criminal-conviction and offence data?	HR, health, education, and security products often do
Unlikely to risk people’s rights and freedoms	Considering nature, context, scope, and purposes, is harm unlikely?	Profiling, automated decisions, and AI features push this the other way

All three have to be met. Article 27 has no startup carve-out and no minimum number of EU users or amount of revenue. If you conclude the exemption applies, write down the facts and reasoning behind each condition, and review the conclusion as your EU activity grows.

Layer 3: Which EU Representative Rules Apply to Your SaaS Company?

Several different roles get called “representative,” or get confused with it. Here’s how they compare.

Role	Legal basis	Applies to	Key point
GDPR representative	GDPR Article 27	Non-EU controllers and processors caught by Article 3(2) with no exemption	Named in writing and established in a Member State where your data subjects are
AI Act authorised representative (high-risk)	AI Act Article 22	Non-EU providers of high-risk AI systems	Where Article 22 applies, a non-EU provider must appoint an authorised representative established in the Union by written mandate before making the high-risk AI system available on the Union market. Check the applicable application date and transitional provisions for the specific system.
AI Act authorised representative (GPAI)	AI Act Article 54	Non-EU providers of general-purpose AI models	Aimed at model providers, with an open-source exception unless the model poses systemic risk
UK representative	UK GDPR	Non-UK controllers and processors whose processing falls within the UK GDPR’s territorial scope, subject to its own representative exemption	A separate regime, so an EU representative doesn’t cover the UK
Data Protection Officer	GDPR Articles 37–39	Organisations meeting the DPO criteria	An independent adviser, and EDPB guidance says the same external person can’t also be your representative

What this means for a typical SaaS company

GDPR representative. This is the one most non-EU SaaS companies serving the EU have to assess first.

AI Act, high-risk systems (Article 22). This applies only if you’re the provider of a high-risk AI system, and embedding AI in a product doesn’t automatically make you one. Classification depends on what the system does. Annex III covers uses such as employment, credit, and education. To work out your role, start with your AI inventory and the provider/deployer analysis in our AI Policy Template.

Where Article 22 applies, the representative’s mandated tasks include verifying that the EU declaration of conformity and technical documentation have been drawn up and that the appropriate conformity-assessment procedure has been carried out; keeping specified documents and provider contact details available to authorities for ten years after the system has been placed on the market or put into service; and cooperating with competent authorities on reasoned requests and risk mitigation. It must also terminate the mandate if it believes you’re acting contrary to your obligations, so it’s more than a mailbox. Check the exact provider conditions in the current text of the Act.

On timing: Regulation (EU) 2026/1744 amended the AI Act’s application timeline. The relevant high-risk provisions are scheduled to apply from 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and from 2 August 2028 for systems classified as high-risk under Article 6(1) and Annex I. These are application dates for the relevant provisions, not a blanket postponement of every AI Act obligation.

Transitional rules may also matter for systems already placed on the market or put into service before the relevant date. These dates do not, by themselves, determine every provider’s appointment deadline. Where Article 22 applies, plan the appointment before making the high-risk AI system available on the Union market, taking account of the applicable application date and any transitional provisions for that particular system.

AI Act, general-purpose models (Article 54). The general application date for the general-purpose AI model rules was 2 August 2025. However, Article 111(3) gives providers of general-purpose AI models placed on the market before that date until 2 August 2027 to take the necessary steps to comply.

Article 54 contains a separate authorised-representative requirement for providers established in third countries, subject to its specific exception for qualifying free and open-source models that do not present systemic risks. Check the transition rules against your model’s market-placement date and circumstances. A SaaS company building on a third-party model usually isn’t that model’s provider. If you train and release your own general-purpose model for the EU market, this is the one to check closely.

UK. If you also serve UK users, the UK GDPR has its own representative rule, so check it separately.

Your vendors. Your own non-EU vendors can have these obligations too. Add “have you appointed an EU representative?” to your vendor review, using the AI Vendor Risk Assessment or the Vendor Risk Assessment Workbook.

Other EU laws. Some other EU laws have representative rules of their own, for example the NIS2 Directive for certain cloud and digital infrastructure providers and the Digital Services Act for certain intermediary services. They’re outside this guide, but check them if you run a platform or provide infrastructure-type services.

The Spain Angle: Choosing a Member State

Where to base the representative. Article 27(3) lets you choose any Member State where your data subjects are. The EDPB’s best-practice suggestion is the one with the highest concentration of them. If your EU base is mostly in Spain, a Spain-established representative is the natural fit.

Language. The EDPB says the representative should, in principle, communicate in the language of the authorities or individuals concerned. If Spanish individuals or the AEPD contact your representative, Spanish capability matters.

Breach notification and the one-stop-shop. A representative in Spain doesn’t give a non-EU controller a single lead authority. In its Guidelines 9/2022 on breach notification, the EDPB says the mere presence of a representative in a Member State doesn’t trigger the one-stop-shop. For a breach affecting people in several countries, a non-EU controller may need to notify each relevant authority, which means the AEPD for people in Spain. Two points for your AI Incident Response Plan:

• You remain responsible for deciding which authorities to notify and for meeting those deadlines.
• Your representative can act as a contact point or assist within the scope of its mandate, but appointing one does not transfer your breach-response duties.

AEPD readiness. If the AEPD asks about your processing, it can go through your representative, so brief them. Our AEPD Inspection Guide covers what inspections typically look at.

How to Choose a Representative

Check each of these:

• Established in the right place, meaning a Member State where your data subjects are.
• Real capacity. There should be staff who can read an authority’s letter and respond properly, in the right language, not just a forwarding address.
• Independence. The representative shouldn’t also be your external DPO.
• A written mandate that spells out what they do when a regulator or an individual makes contact, how fast, and how the appointment ends.
• Access to your records. They need your records of processing, so agree how you’ll keep them current.
• Clear scope and pricing. Ask what’s included, such as data subject requests and authority correspondence, and how you’d switch providers.
• Liability and insurance position, including what happens if an authority acts against them.

Red flags:

• A promise that appointing them “handles your GDPR compliance”
• A mailbox or P.O. box address with no staff behind it
• A claim that a representative gives you a single EU regulator
• A bundle that puts the representative and external DPO roles in one person
• Reluctance to explain what happens when an authority writes

Layer 4: Appointing and Documenting It

Once you’ve decided you need one, treat it as part of your compliance system and not just a signature.

1. Write down your analysis: scope, establishment, and exemption conclusions, with a date and an owner.
2. Choose the Member State and the representative using the criteria above.
3. Sign a written mandate (Article 27(1) and (4)) covering scope and termination.
4. Give them what they need: your records of processing, a contact-routing process, and your breach protocol.
5. Update your privacy notices. If you’re required to designate a representative, Articles 13(1)(a) and 14(1)(a) require your notices to include the representative’s identity and contact details. If you publish a Spanish version, update that too.
6. Update your records of processing to include the representative (Article 30).
7. Check your contract documents, including your DPA, so customers have a correct data protection contact.
8. Update your incident response plan so it states who decides on and sends notifications to each relevant authority.
9. Set review triggers: a new EU hire or entity, a new market, a new AI feature that changes your provider status, and at least once a year.

Common Mistakes

• Assuming no EU office means no GDPR. Article 3(2) exists for exactly that situation.
• Treating a DPO as the representative. They are separate roles (see above).
• Relying on the exemption without writing it down. If you can’t show the reasoning, you can’t defend it.
• Buying a mailbox instead of a mandate. A representative needs a written mandate and real people behind it.
• Expecting the representative to handle your breach response. Those decisions stay with you.
• Forgetting the paperwork. Privacy notices and records of processing need the representative’s details.
• Ignoring the AI Act, or overreading it. Not every AI feature triggers Article 22, but a high-risk provider can’t skip it.
• Treating it as one-and-done. New markets, hires, and products can change the answer.

FAQs

Your Next Step: Document the Decision

For a SaaS company, deciding whether an EU representative is required starts with the processing, establishment, and exemption tests—not simply where the business is incorporated. Whatever you conclude, document the reasoning:

1. Determine whether Article 3 applies to the relevant processing.
2. Assess the establishment and exemption questions.
3. If an appointment is required, sign the mandate and update your notices and records.

A dated, owned record of that reasoning is what makes your position defensible, whether the answer is “appoint” or “not required.” For the wider picture, work through the Spain GDPR Checklist for SaaS.

Related Resources

• Spain GDPR Checklist for SaaS: the wider Spain obligations this fits into
• AEPD Inspection Guide: what to expect if the AEPD comes asking
• Data Processing Agreement Template: the Article 28 contract for your customers and vendors
• AI Policy Template: the provider/deployer analysis behind the AI Act question
• AI Vendor Risk Assessment and Vendor Risk Assessment Workbook: check whether your vendors have appointed one
• AI Incident Response Plan: wiring in multi-authority breach notification
• ISO 42001 for SaaS: why AI governance certification doesn’t replace a representative
• AI DPIA Checklist for Spain-Facing SaaS Startups: documentation your representative may need to see

Sources

• GDPR: Regulation (EU) 2016/679 (EUR-Lex), Articles 3, 4(17), 13, 14, 27, 30, 83
• EDPB Guidelines 3/2018 on the territorial scope of the GDPR (Article 3)
• EDPB Guidelines 9/2022 on personal data breach notification under GDPR
• EU AI Act: Regulation (EU) 2024/1689 (EUR-Lex), Articles 22, 54 and 111
• Digital Omnibus on AI: Regulation (EU) 2026/1744 (EUR-Lex)
• AEPD: Agencia Española de Protección de Datos

This article provides general educational information and isn’t legal advice. Whether you need a representative depends on the facts of your processing, so confirm with qualified counsel before relying on any conclusion here.