Does GDPR apply to a company with no EU office, and what must it do?
GDPR can apply to a company with no EU office. Article 3(2) reaches a controller or processor outside the Union when it processes personal data of people in the Union to offer them goods or services, paid or free, or to monitor their behaviour where that behaviour takes place in the Union. When a customer, contract or regulator asks for GDPR compliance, the core duties for such a company are three: designate an EU representative in writing unless an exemption applies, notify a personal data breach to every supervisory authority in a Member State where affected people live, and choose a transfer mechanism for any personal data that flows back to your home country. Start by confirming whether your services are offered to people in the EU and whether any monitoring takes place there, because that answer decides whether the rest of this section applies to you.
The GDPR does not require an audit, attestation or certificate, and no one can issue one that makes you compliant. Certification under Article 42 is voluntary, lasts for at most three years, and is issued by accredited certification bodies or supervisory authorities. It does not reduce your responsibility for compliance. Your organization owns its controls, including the representative appointment, breach procedures and transfer assessments. DeployOpen can plan and implement the systems, logging, access controls, transfer records and evidence those controls depend on, inside your own infrastructure. Only an independent auditor or certification body issues reports or certificates. Before you ask anyone for a quote, confirm in writing which of these duties your processing triggers and who will hold each one.
Fines are the reason to treat these duties seriously. Article 83 sets maximum administrative fines of EUR 10 million or 2% of total worldwide annual turnover for infringements such as Articles 25 to 39, and EUR 20 million or 4% for infringements of the principles, data subject rights and transfer rules, whichever is higher in each case. Transfer infringements sit in the higher tier, and supervisory authorities can order the suspension of data flows under Article 58(2)(j), which can stop a service regardless of any fine. Read the GDPR text on EUR-Lex for the full provisions before you decide who on your side owns the representative, breach and transfer decisions.
Which non-EU companies fall under Article 3(2)
Article 3(2) reaches a company with no EU establishment when it processes personal data of people in the Union. The test turns on targeting and monitoring, so the questions below are about who you serve, who you watch and where that happens, not where your company is incorporated.
Offering goods or services to EU people
The first trigger covers offering goods or services to people in the Union, whether paid or free. A SaaS product sold to EU customers, or a free tool used by EU residents, can fall under it even when you have no office there. Check whether your site, pricing, languages, currencies, payment options and marketing show an intention to serve people in one or more Member States. Mere accessibility of a website from the EU is not enough on its own, so record the signals you rely on and how you reached your conclusion.
Monitoring behaviour within the Union
The second trigger covers monitoring the behaviour of people as far as that behaviour takes place in the Union. Tracking that builds profiles, follows movements, or scores how people act inside the EU falls here. Typical examples include behavioural advertising, device fingerprinting of EU visitors and usage analytics tied to identifiable users. Check each tracking tag, SDK and session recording you run, and confirm which of them can be tied to a person located in the Union.
Analytics on EU website visitors
Illustrative case: a US company runs a marketing site with analytics that records returning visitors and their page paths. If the site targets EU visitors, or the analytics profile visitors who are in the Union, the company is in scope for those processing activities. Scope the processing by purpose, list the analytics vendors and cookies involved, and decide whether consent banners and vendor terms match the purposes you actually pursue.
Hosting provider serving EU tenants
Illustrative case: a US hosting or managed service provider runs customer workloads for European tenants. Whether Article 3(2) applies depends on whether the provider offers services to people in the Union and whether it monitors them there. Where the provider acts as a processor for tenants, the role also shapes its duties. Confirm which tenant data sits in your systems, which of your staff access it from outside the EEA, and whether your service targets individuals in the Union or only businesses located there.
Free app with EU users
Illustrative case: a non-EU developer publishes a free mobile app that EU residents download and use. Offering a service free of charge still counts, so the app is within the first trigger if it is directed at people in the Union. Check app store listings, supported languages, in-app purchases, crash reporting and advertising SDKs. Map which data flows to your own systems and which flows to third parties, since each flow may require its own assessment.
Deciding scope before you build the representative
Once a trigger applies, the next question is whether you must appoint an EU representative in writing, which depends on whether the processing is occasional and low risk. Record the scope decision for each processing activity, with the reasoning, the dates it was made and the owner who approved it. Review the decision when products, markets or tracking tools change, because a scope conclusion that was correct for one launch may not hold after the next.
How the EU representative duty works and when it can be avoided
A controller or processor with no establishment in the Union that falls under Article 3(2) must designate a representative in the Union in writing under Article 27(1). The designation is a formal act: the organization should keep a signed mandate that names the representative and the processing it covers, and it should be able to produce that document if a supervisory authority asks. The representative must be established in one of the Member States where the affected data subjects are. If your users sit in several countries, you choose which of those Member States hosts the representative, and that choice affects which authorities are most likely to contact it first. Supervisory authorities and data subjects may address the representative on all processing issues, so the named contact must be reachable, competent on your processing and able to pass requests to your team quickly.
The exemption in Article 27(2) is narrow, and every condition must be met at once. The processing must be occasional, must not include large-scale processing of special category or criminal offence data, and must be unlikely to result in a risk to individuals. Public authorities and bodies are also exempt. A SaaS product that processes customer records continuously, or any service with recurring user accounts, will rarely qualify. Treat the exemption as a conclusion you document, not a default. Write down the processing activities, the volumes, the categories of data, the risk reasoning and the reviewer, then have counsel confirm the reasoning before you rely on it. Revisit the assessment whenever the product, data categories or user base changes.
Two limits matter for planning. The representative does not take on the controller's or processor's liability: EDPB Guidelines 3/2018 state that the designation leaves responsibility for compliance where it was. The same guidelines state that the representative role is not compatible with that of an external data protection officer, so a firm that acts as your DPO cannot also be your representative. Confirm this with your DPO and counsel before you sign a combined engagement, and make sure the representative's contract, mandate and contact details are kept current in your records of processing and privacy notices.
Which transfer mechanism fits data flowing back to the home country
This table compares the four routes for moving personal data from the EU to a non-EU home country: adequacy, standard contractual clauses, binding corporate rules and Article 49 derogations. Read each row as a decision: when the route fits, what you must keep in place, and where it most often fails. Treat Article 49 as a last resort, not a planning baseline.
| Mechanism | When it fits | What you must maintain | Main risk |
|---|---|---|---|
| Adequacy decision (Article 45) | Your home country or the recipient is covered by a Commission adequacy decision, such as the EU-US Data Privacy Framework for certified US recipients | Confirm the recipient's current certification or scope, monitor the status of the decision, and document why the transfer relies on it | The pending Case C-703/25 P appeal against the EU-US framework could change the basis for transfers |
| Standard contractual clauses (Decision 2021/914) | No adequacy decision covers the recipient, or your customers require contractual safeguards for the flow | Execute the module that matches your role, complete a transfer impact assessment, and add supplementary measures such as encryption and access restrictions where needed | Local laws on government access may undermine the clauses, so the assessment must be specific and kept current |
| Binding corporate rules (Article 47) | A multinational group moves personal data across many affiliates and needs one internal framework | Obtain approval from a competent supervisory authority, enforce the rules across all group entities, and keep audit and training records | Approval takes time and is built for groups, so it rarely suits a single company or a small set of flows |
| Derogations (Article 49) | Only for occasional, specific situations such as an explicit consent to a one-off transfer, where no other mechanism is possible | Record the specific situation and why no other route applies, and limit the transfer to what that situation needs | Regular or systematic transfers relying on derogations are hard to defend and may draw enforcement action |
| Supplementary measures (with SCCs) | The recipient's country allows government access that could undermine the clauses on their own | Apply technical measures such as encryption where the company holds the keys, pseudonymisation, and documented access policies | Measures that leave the recipient able to read data in clear text may not close the gap, so confirm the technical design with counsel |
| Suspension of data flows | Applies to any mechanism that a supervisory authority finds inadequate in practice | Keep a fallback route ready and a map of every flow so that a suspension order can be handled quickly | Supervisory authorities can order suspension under Article 58(2)(j), which can halt a service that depends on the flow |
How to get the three core duties in place, phase by phase
The sequence below takes a company with no EU establishment from an Article 3(2) scoping question to an evidence pack that an independent reviewer or a supervisory authority can test. Each step produces a document or check that the next step depends on.
Scope the processing and map affected Member States
Start by listing each processing activity that touches people in the Union and recording why Article 3(2) applies to it, whether that is offering goods or services or monitoring behaviour. For each activity, record the Member States where the affected individuals reside, since that list drives both the representative location and breach notification. Involve product, sales, marketing and analytics owners, because they know where EU users come from. The output is a scoping register that names the activity, the trigger, the data categories and the Member States. Ask a partner to confirm in writing how they will test completeness, for example by reviewing sign-up flows, analytics regions and customer contracts.
Document the Article 27 assessment
Using the scoping register, record whether the exemption in Article 27(2) could apply to each activity. The exemption covers only processing that is occasional, that does not include large-scale special category or criminal offence data, and that is unlikely to result in a risk. Because the test has several conditions, the reasoning must be written down and signed off by the accountable owner, and it should be revisited when the product or user base changes. The output is a dated memo that either justifies the exemption or confirms the representative duty. Ask any partner to confirm who signs the memo and how the memo will be kept with the scoping register.
Appoint the EU representative in writing
Where the duty applies, appoint a representative in writing and establish that person or firm in a Member State where the affected data subjects are. The mandate must allow supervisory authorities and data subjects to address the representative on all processing issues. Keep in mind that the representative does not take on the company's responsibility or liability, and that the role cannot be combined with an external DPO appointment under the EDPB's reading of the rules. The output is a signed appointment, a mandate that names the representative's contact channels, and an internal record that links the representative to the scoping register. Ask a partner to confirm which Member State they would use and how the representative will receive and route authority correspondence.
Build the breach runbook for each supervisory authority
Because a representative does not trigger the one-stop-shop, the breach runbook must identify every supervisory authority in whose Member State affected individuals reside. Build a contact register for those authorities, a decision path for deciding whether a breach is notifiable, and a template that can be filled in phases as facts emerge. Assign owners for legal, security, communications and the representative, and rehearse the path with the systems in scope. The output is a tested runbook, a current authority contact list, and a breach log format that records the decision and the reasons behind it. Ask any partner to confirm how the runbook will be tested and how it will map to the Member States listed in step one.
Map data flows and choose transfer mechanisms
Trace where personal data collected from the Union is stored, processed, backed up and accessed, including access from support staff or sub-processors located outside the EEA. For each flow that returns data to the company's home country or another third country, identify the transfer mechanism. Adequacy under Article 45 is one option, appropriate safeguards such as standard contractual clauses under Article 46 are another, and the derogations of Article 49 apply only where the first two do not. Note that the EU-US Data Privacy Framework has a pending court appeal, so confirm its status before relying on it. The output is a data flow map, a transfer register, and the supporting documents for each mechanism, such as signed clauses and transfer assessments. Ask a partner to confirm how they will verify the map against live systems rather than design documents.
Assemble the evidence pack
Collect the outputs of the earlier steps into one evidence pack that a reviewer can navigate: the scoping register, the Article 27 memo, the representative appointment, the breach runbook and contact list, the transfer register with supporting documents, and records of testing. Add a short index that shows which document answers which obligation, and set an owner and review date for each item. Remember that the GDPR requires no audit or certificate, so the pack is evidence for supervisory authorities and customers, not proof issued by a third party. The output is a versioned pack with an index and a named owner. Ask any partner to confirm the format, the storage location, and who in the company keeps the pack current after handover.
Notifying a breach in several EU countries without a lead authority
A non-EU controller cannot route a breach notice through a single lead authority. Appointing an EU representative under Article 27 does not trigger the one-stop-shop, so EDPB Guidelines 9/2022 (paragraph 73) expect the controller to notify every supervisory authority in whose Member State affected data subjects reside. The notice still runs on the Article 33 clock: the controller must notify without undue delay and, where feasible, within 72 hours of becoming aware of the breach. The practical consequence is that the company needs to know, within that window, which countries its affected people live in. That knowledge is not automatic. It has to be built into the systems before an incident, and the response plan should name the owner who turns it into a country list and a set of filings.
Processors carry part of this burden. Under Article 33(2), a processor must notify the controller without undue delay after becoming aware of a breach, so the contract and runbooks should specify what the processor reports first, including the affected tenants, data categories, approximate record counts and the time of discovery. A SaaS company acting as processor for customers should check that its own incident procedure captures the customer's country of residence for each affected record, or at least the data subject's Member State, because the controller that ultimately notifies may need that split. Confirm with counsel how any Member State designations under your own contracts are recorded, and do not assume a single regulator will coordinate the filings for you.
Being able to produce that country mapping depends on the evidence the company already keeps. Application logs, access logs and customer records should show which accounts and data subjects were touched and where those people are established, without requiring a manual search of production databases during an incident. Article 32 expects a level of security appropriate to the risk, including the ability to detect and assess incidents, and regulators judge breach handling against that baseline. Fines under Article 83 reach EUR 10 million or 2% of worldwide annual turnover for infringements of Articles 25 to 39, which covers breach notification, and EUR 20 million or 4% for transfer infringements. A company that cannot show which countries were affected, or that notifies late, is exposed on both counts.
Who owns what: your team, an implementation partner, and the assessor
Your organization remains the controller or processor under Article 3(2), and every legal decision stays with you. That includes deciding whether the processing is in scope, designating the EU representative in writing, choosing the transfer mechanism for data flowing back to your home country, and deciding whether a personal data breach must be notified to each supervisory authority where affected people live. A partner can gather facts for these decisions, but the accountability cannot be transferred to them. Your team should own the following:
- Scope and role decisions: confirming which processing falls under Article 3(2) and whether you act as controller or processor for each activity.
- Representative designation: appointing an EU representative in writing, where the exemption in Article 27(2) does not apply, and keeping that appointment current.
- Breach decisions: assessing risk, deciding on notification to every affected Member State, and signing off the notice content and timing.
- Transfer choices: selecting an adequacy route, standard contractual clauses or another mechanism, and recording the transfer impact review.
- Policies and sign-off: approving the written policies, records of processing and DPIAs that the partner documents.
Confirm with counsel which of these decisions your own governance requires you to approve at executive level.
An implementation partner such as DeployOpen works inside your infrastructure to prepare the systems and evidence that support those decisions. Work is usually fixed-scope, with deliverables agreed in writing before it starts. The partner does not issue opinions on whether you comply with the GDPR and does not act as your representative or DPO. Typical outsourced work includes the following:
- Data maps: tracing where personal data enters, moves, is stored and leaves your self-hosted platforms, including flows to other countries.
- Logging and monitoring: configuring audit logs and alerting so breach facts can be established within the notification window.
- Technical configuration: hardening access controls, encryption, backup and restore, and hosting locations that your decisions have fixed.
- Evidence packs: collecting configuration exports, runbook records and change history into a form your team and an assessor can review.
- Documentation of what was built: describing the architecture, data flows and controls as implemented, so the written record matches the running system.
Ask any partner to state in its statement of work that it does not issue compliance reports or certificates, and that your team retains all legal decisions.
The GDPR requires no audit, attestation or certificate. Where an assessment is used, it is performed by an independent auditor or certification body, and certification under Article 42 is voluntary and issued by accredited certification bodies or supervisory authorities. Supervisory authorities enforce the GDPR and can investigate, order corrective measures and impose fines under Article 83. An assessor examines evidence and reports on what it finds, but only it can issue a report or certificate, and it is independent of both your team and the partner who built the environment. Its role typically covers the following:
- Independent testing: sampling records, configurations and logs against the claims your team makes about the system.
- Reporting: issuing findings or a certificate in its own name, with a defined scope and validity period.
- Regulator contact: supervisory authorities receive your notifications and may request records directly during an investigation.
- Separation of duties: the assessor should not design the controls it later examines.
- Scope limits: a certificate covers only the stated scope, and it does not reduce your responsibility for compliance.
Confirm who will issue any report you present to customers, and whether the certification body is accredited for the relevant scheme.
What usually delays non-EU GDPR projects and how to avoid each
Most delays in non-EU GDPR work come from a few misreadings: who the EU representative is, how breaches are reported, how transfers are justified, and where data actually sits. Each card names the cause and the control that prevents the delay.
Treating the representative as the DPO or compliance owner
Teams often appoint an EU representative and assume the job of data protection leadership is covered. Under Article 27, the representative is the point of contact that supervisory authorities and data subjects address, but EDPB Guidelines 3/2018 state that the role does not remove the controller's or processor's responsibility and is not compatible with acting as an external DPO. Check that a named internal owner still holds accountability for records, DPIAs and rights handling, and that the representative's mandate is written down.
Notifying only one lead authority after a breach
Companies used to one-stop-shop reporting often file a single notice with one regulator. A non-EU controller with no EU establishment does not get the one-stop-shop, so EDPB Guidelines 9/2022 require notice to every supervisory authority in whose Member State affected data subjects reside. Before an incident, map affected individuals by country, prepare notice templates for each relevant authority, and confirm the 72-hour clock runs from awareness, not from the end of the investigation.
Relying on the Data Privacy Framework without a fallback
Many US companies make the EU-US Data Privacy Framework their only transfer basis, then stall when customers ask what happens if it is struck down. The framework rests on Commission Implementing Decision (EU) 2023/1795, and an appeal in Case C-703/25 P is pending. Keep standard contractual clauses under Commission Implementing Decision (EU) 2021/914 signed and ready as the fallback, and document a transfer impact assessment for each importing entity so the switch does not stop onboarding.
Missing remote support access as a transfer
Engineers in the company's home country who log into EU-hosted systems to troubleshoot can create a transfer even when data never leaves the EU. Under EDPB Guidelines 05/2021, a remote access from a third country to data held in the Union is treated as a transfer that must meet Chapter V. Inventory who can reach production from outside the EEA, require just-in-time access with session logging, and record the safeguard that covers each access path.
Lacking data maps by affected country
Breach notice, representative placement and transfer analysis all depend on knowing where affected people live and where their data is stored, processed and accessed. Without a data map, teams cannot name the supervisory authorities they must notify or the Member States where the representative must sit. Build a register that links each processing activity to data subject countries, hosting regions, sub-processors and support locations, and refresh it whenever a system or vendor changes.
Assuming Article 3(2) does not apply
Some companies conclude the GDPR does not reach them because they have no office, staff or payment flow in the EU. Article 3(2) applies when the company offers goods or services to people in the Union, paid or free, or monitors their behaviour there. Test the offer in writing: language, currency, EU-facing marketing, and tracking of EU visitors. Record the outcome, because the representative, breach and transfer duties follow from it and an error discovered during a customer review causes the longest delays.
Questions buyers ask before engaging outside help
Does a non-EU company have to appoint an EU representative?
Yes, in most cases. When Article 3(2) applies, a controller or processor not established in the Union must designate a representative in the Union in writing (Article 27(1)). The exemption in Article 27(2) is narrow: it covers only occasional processing that does not involve large-scale special category or criminal offence data and is unlikely to risk individuals' rights, and it never covers public authorities. The representative must be established in a Member State where the affected data subjects are, and supervisory authorities and data subjects may address them on all processing issues. A representative does not take on the company's liability, and the EDPB's territorial scope guidelines state that the role cannot be combined with an external DPO. Confirm the exemption with counsel against your own processing, since it is easy to misjudge.
What does outside help for GDPR transfers and representation cost?
No price is published here, and the cost depends on the written scope. Ask for a quote that separates the components: the representative service (an external firm acting as your Union contact, usually recurring), the transfer assessment work (mapping data flows, choosing and executing standard contractual clauses, and documenting supplementary measures, usually one-time with periodic review), and the technical work DeployOpen would perform, such as configuring hosting, logging and access controls in your own infrastructure. Costs rise with the number of data flows, sub-processors, Member States where data subjects live, and the age of existing contracts. Ask which items recur, who holds the contracts, and what happens to the work if the scope changes.
How long does it take to get the transfer and representative arrangements in place?
The duration depends on the scope, so ask for a timeline in the written proposal rather than relying on a general figure. The main drivers are how many transfers exist, whether a sub-processor or support team outside the EEA has access, whether the company relies on the EU-US Data Privacy Framework or needs standard contractual clauses, and how quickly your staff can supply system and vendor information. Appointing a representative is usually the faster step, while mapping flows and rebuilding technical controls takes longer. Clarify which milestones depend on your team and which on the provider.
What does the work need from our staff?
Expect the work to need named owners in engineering, security, legal and procurement. Engineering must describe where personal data is stored, copied, backed up and accessed, including remote support from outside the EEA. Legal must confirm the controller or processor role for each activity and review the contracts. Security must provide access logs, encryption settings and sub-processor details. Ask the provider to list these inputs in the proposal with the expected hours for each owner, so you can plan internal time before work starts.
Can our company handle the EU representative and transfer work in house?
Yes, if you have people with the right knowledge and time. The representative role must be held by an entity established in the EU, so an in-house employee cannot simply be named unless the company has an EU establishment that meets the Article 27 conditions, which is a legal question to confirm with counsel. For transfers, an in-house team can map data flows and execute standard contractual clauses. Outside help adds value where systems are complex, where the team lacks experience with supplementary measures, or where a fixed deadline applies. Many companies split the work: internal staff own the data map and decisions, while an outside firm handles the representative and technical hardening.
Is GDPR certification required for a non-EU company?
No. The GDPR requires no audit, attestation or certificate. Certification under Article 42 is voluntary, is issued for at most three years by accredited certification bodies or supervisory authorities, and does not reduce the controller's or processor's responsibility for compliance. Buyers may still ask for evidence, so the practical deliverables are documented transfer mechanisms, a representative appointment, a record of processing and the security measures under Article 32. DeployOpen prepares systems and evidence for assessment but does not issue certificates or audit reports.
What happens if our transfer mechanism fails?
Supervisory authorities can order the suspension of data flows under Article 58(2)(j), which can stop a service that depends on transfers to your home country. Transfer infringements carry fines of up to EUR 20 million or 4% of total worldwide annual turnover, whichever is higher (Article 83(5)(c)). Practical exposure also includes customer contract breaches and loss of EU sales. To reduce this risk, keep the transfer basis documented, review it when the legal position changes (for example, the pending appeal in the EU-US Data Privacy Framework case), and plan a fallback such as standard contractual clauses. Ask any provider how it would keep the service running if a flow had to stop.
How DeployOpen works on this
DeployOpen plans and implements the self-hosted open-source systems that non-EU companies use to meet GDPR obligations inside their own infrastructure. We prepare systems, controls and evidence for your assessors and advisers, while your organization keeps ownership of its controls, representative appointment and transfer decisions.
How we scope
- We agree a written scope covering which EU data subjects and processing activities are in view before work starts.
- The scope names the systems, cloud accounts or data centers where personal data is held and processed.
- Engagements are fixed-scope, with deliverables and timelines confirmed in writing before any build begins.
How we build
- We configure breach detection and logging so affected Member States can be identified and notified within the GDPR timelines.
- We map where personal data and remote administrative access flow, so transfer mechanisms can be documented per flow.
- We harden self-hosted platforms for access control, encryption and backup, producing the configuration evidence an Article 32 review will ask for.
How we hand over
- We deliver system documentation, configuration records and data flow maps that your counsel and representative can review.
- We provide breach notification runbooks listing supervisory authority contacts for each Member State where data subjects reside.
- We document what DeployOpen did and what remains your responsibility, so ownership of decisions stays clear after handover.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after the initial scope is delivered.
- We can rerun configuration checks and update data flow maps when your systems or sub-processors change.
- Questions on EU representative duties, transfer mechanisms or legal interpretation should go to your qualified legal adviser or the relevant authority.

