Does GDPR apply to us? Scope test and EU representative

Does GDPR apply to us? The short answer and the two tests that decide it

When a customer, contract or regulator asks whether you comply with the GDPR, the first question is whether the regulation applies at all. It applies in two cases: when your organization is established in the EU and processes personal data in the context of that establishment (Article 3(1)), or when you are established outside the EU but offer goods or services to people in the Union, or monitor their behaviour there (Article 3(2)). Personal data is defined broadly as any information relating to an identified or identifiable person, so the test is usually met sooner than teams expect. You decide scope yourself. No audit, attestation or certificate is needed to fall within the GDPR, and no regulator has to confirm it first.

The first test asks where you are established. A subsidiary, branch or office in an EU Member State, or in Iceland, Liechtenstein or Norway under the EEA arrangement, can bring processing within scope even if the servers sit elsewhere. The second test asks who you serve. A non-EU company with users in the Union, or one that tracks their behaviour through cookies or similar identifiers, may be in scope. Recital 30 names IP addresses and cookie identifiers as examples of online identifiers that can single people out. Pseudonymised data stays personal data under Recital 26, and only truly anonymous information falls outside the regulation. Confirm with your legal team whether your logs, analytics and telemetry hold identifiers that could be linked back to a person.

Once you conclude the GDPR applies, the result changes your documentation. Systems that hold personal data, the roles you hold as controller or processor, and the transfers that leave the EEA all need to be recorded. If you conclude it does not apply, record the reasoning and the facts behind it, and revisit the decision when your customer base, offerings or tracking change. For a non-EU organization in scope, check whether Article 27 requires a written designation of an EU representative, which depends on the processing involved. The GDPR has applied since 25 May 2018, so an inquiry about past processing is judged against the rules in force when the processing occurred.

Which personal data counts: identifiers, pseudonymised data and anonymous data

Whether the GDPR applies to a system often turns on what the data is, not only who holds it. The tests below run in parallel: a record can fail one and still count as personal data. Apply them to logs, telemetry and analytics before deciding the regulation is out of reach.

Direct identifiers in records

Names, email addresses, account numbers and national ID numbers identify a person on their face, so any system storing them is in scope. Check application databases, support tickets, CRM exports and file shares for these fields. Note that free-text fields often hold identifiers that no schema lists, such as a name typed into a notes box. Inventory those fields before assuming a system holds no personal data.

Online identifiers in logs

Recital 30 treats IP addresses, cookie identifiers and RFID tags as identifiers that can be combined with other server-side information to single out a person. Web server access logs, reverse proxy logs, authentication logs and device IDs in mobile telemetry therefore usually count as personal data. Confirm retention periods for these logs, since they are often kept longer than teams expect.

Pseudonymised data stays personal

Recital 26 states that pseudonymised data remains personal data when it can be attributed to a person using additional information. Hashed user IDs, tokenised customer references and analytics events keyed to a random ID fall in this category if the key, lookup table or original system still exists. Check where the mapping is held, who can access it and whether the two sets are ever joined.

Reasonably likely means test

Identifiability is judged by all means reasonably likely to be used, taking account of cost, time and available technology. A dataset that looks anonymous today may become personal when cheaper linking tools or other datasets appear. Document the re-identification assessment for each dataset, and revisit it when the data is shared with a new party or combined with new sources.

Anonymous data falls outside

Recital 26 says the GDPR does not apply to anonymous information, meaning data that no person can be identified from by any reasonably likely means. Aggregated metrics and statistics can qualify, but only when individual records cannot be recovered. Treating data as anonymous is a claim the organization must be able to defend, so record the method and the reasoning behind it.

Who is in scope and what each role triggers

This table compares the four positions an organization can occupy under the GDPR, the trigger for each and the first obligation it creates. Read it by asking which trigger describes your processing, then check the duty in the last column before assuming the rest of the regulation applies in the same way.

Position	Trigger	Role and first obligation
EU-established controller	Determines purposes and means of processing in the context of an EU establishment (Article 3(1))	Controller. Full Chapter IV duties apply, including security of processing under Article 32, whether or not the processing takes place in the Union.
EU-established processor	Processes personal data on another's behalf in the context of its EU establishment (Article 3(1))	Processor. Must act only on documented instructions and keep processing security under Article 32, even when the customer is outside the EU.
Non-EU controller or processor under Article 3(2)	Offers goods or services, paid or free, to people in the Union, or monitors their behaviour within the Union	Controller or processor with GDPR duties for that processing. First obligation is to designate a written representative in the Union (Article 27(1)), unless an Article 27(2) exemption clearly applies.
Article 27(2) exemption check	Processing is occasional, does not involve large-scale special category or criminal offence data, and is unlikely to result in risk, or the organization is a public authority or body	Representative duty may not apply. Confirm each condition in writing, because a single large-scale or regular data flow removes the exemption.
Role under contract versus in fact	Purposes and means of processing decide the role, not the label in a contract	Controller or processor status follows what the organization actually decides. Review processing decisions before signing any data processing agreement.

Does the GDPR cover the EEA and every EU country the same way?

The GDPR applies in the same form across all EU Member States and in the EEA. Regulation (EU) 2016/679 is binding in its entirety and directly applicable in every Member State, so national governments do not need to adopt it into local law before it applies. It also applies in Iceland, Liechtenstein and Norway under an EEA Joint Committee Decision that entered into force on 20 July 2018, as recorded in Commission Implementing Decision (EU) 2023/1795. For an engineering team, this means one set of obligations for security of processing, rights handling and breach notification covers every system that processes personal data of people in those countries, not a separate rulebook per country. Check whether any systems hold data about people in Iceland, Liechtenstein or Norway, since these are often forgotten in scoping documents that only list EU countries.

The regulation is uniform, but enforcement is not centralized. Independent national supervisory authorities enforce the GDPR in each country, and their decisions can differ in emphasis, guidance and the expectations they set for documentation. Where a processing activity crosses borders, the authorities cooperate, and the European Data Protection Board resolves disputes through binding decisions. Regulation (EU) 2025/2518 adds procedural rules for complaints and investigations in cross-border cases and applies from 2 April 2027. Before that date, the procedures in force still govern how these cases move, so organizations should confirm with counsel which authority would likely lead if they process data across several countries, and record that analysis as part of their scope decision.

In practice, the reader should ask three questions: which supervisory authorities could receive a complaint about their processing, which countries their data subjects live in, and whether their breach response plan can notify several authorities within the same deadline. Systems that serve customers in many countries should keep an up-to-date list of the Member States and EEA countries covered, so breach and rights workflows can route correctly. The GDPR sets no separate certificate or audit for each country, so the evidence an organization builds for one authority is generally the evidence another authority will examine. Confirm the current procedural position with a qualified adviser before relying on it for a specific cross-border case.

How to run a scope check for your systems in four steps

The sequence turns a vague question about whether the GDPR applies into a recorded conclusion that names the entity, the processing, the territorial test and the reasoning behind each answer. Each step produces an output that the next one depends on.

Inventory where personal data is collected and processed
Start with the systems, not the legal text. Engineering, product and operations staff list each application, database, analytics tool, log store, backup and support channel that holds information about people, including online identifiers such as IP addresses, cookie identifiers and device IDs. Include data held by third-party services. The output is a data flow inventory showing the source, the storage location, the people concerned and the recipients for each flow. The step is complete when every flow that touches a person has an owner and a location.
Identify the controller or processor and the purposes
For each flow, record which legal entity decides why and how the data is processed (a controller under Article 4) and which entity processes it on someone else's behalf (a processor). Write down the purposes in plain terms, such as account management, marketing, fraud prevention or service delivery. Note which group company or contractor runs each system. The output is a role and purpose register. Ask counsel to confirm any case where roles are shared, because the classification affects the contracts you need.
Test establishment under Article 3(1)
Ask whether the controller or processor has an establishment in the Union and whether the processing takes place in the context of that establishment's activities. An office, branch or subsidiary with real activity in an EU Member State can be enough, even if the servers sit outside the Union. Record each entity, each EU location and the activity that links it to the processing. The output is a yes or no finding for Article 3(1), with the supporting facts. Where an establishment exists, the GDPR applies to the processing in its context regardless of where the processing physically happens.
Test targeting and monitoring under Article 3(2)
Where no EU establishment links the processing, test whether people in the Union are targeted. Ask whether the organization offers goods or services to them, paid or free, or monitors their behaviour within the Union. Check signals such as EU languages, euro pricing, delivery to EU addresses, marketing aimed at EU audiences and tracking of EU users. Compare the answer with the EDPB's territorial scope guidance. The output is a yes or no finding for Article 3(2) with the evidence for each signal. Note that mere accessibility of a website is not, on its own, the test.
Check material scope and the EEA position
Confirm that the processing involves personal data and not anonymous information. Apply Recital 26: pseudonymised data remains personal data if it can be attributed to a person with additional information, and identifiability is judged by means reasonably likely to be used. Note that the GDPR applies in Iceland, Liechtenstein and Norway as well as the EU. The output is a material scope finding for each flow, marking which flows are personal data and which are anonymous, with the reasoning for any anonymisation claim.
Decide whether an EU representative is required
If Article 3(2) applies to a controller or processor not established in the Union, check whether the Article 27(2) exemptions cover the processing. Those exemptions concern occasional processing that is unlikely to create a risk and does not include large-scale special category or criminal offence data, and processing by public authorities or bodies. If no exemption fits, the organization must designate a representative in the Union in writing under Article 27(1). The output is a documented decision on the representative requirement, with the exemption analysis.
Record the conclusion with its reasoning
Write a scope memo that states, for each system, whether the GDPR applies, which article grounds that answer, the facts relied on and the open questions. Date it, name the person who prepared it and the person who approved it, and store it with the data flow inventory. Mark the points that depend on facts still changing, such as the pending Omnibus proposals noted in the GDPR changes guidance. An independent adviser or counsel can review the conclusion, but only the organization decides its compliance position, and no adviser or regulator issues a compliance decision on this basis alone.

When a non-EU company must appoint an EU representative

A non-EU controller or processor that falls under the GDPR's territorial scope may need a written representative in the Union. The cards below cover when the duty applies, when it does not, what the representative actually does, and why appointing one leaves compliance responsibility with the company.

The Article 27(1) appointment duty

Where Article 3(2) applies, a controller or processor not established in the Union must designate a representative in the Union in writing. The trigger is the targeting or monitoring of people in the EU, not the company's size or revenue. Check first whether your offering or monitoring activity actually reaches people in the EU, because that test decides whether the appointment question arises at all.

Occasional processing exemption

Article 27(2) exempts processing that is occasional, does not include large-scale processing of special category or criminal offence data, and is unlikely to result in a risk to people's rights and freedoms. All three conditions must hold together. A company that serves EU users regularly, handles health or biometric data at scale, or runs continuous behavioural tracking will usually fail this test, so document the reasoning rather than assume it.

Public authority and body exemption

The Article 27(2) exemption also covers public authorities and bodies. This matters for non-EU government agencies, public universities or state-owned entities that offer services to people in the Union. Confirm your legal status under the relevant national law before relying on it, because a body that is only partly public may not qualify.

What the representative does

The representative acts as the point of contact for supervisory authorities and, where relevant, data subjects, on matters concerning processing covered by the GDPR. It is named in the company's privacy notices and records of processing so regulators can reach it. Ask any provider which authorities it will accept correspondence for, how quickly it forwards requests, and whether it keeps records of its own.

What the representative does not do

The representative does not decide purposes or means of processing, approve the company's security measures, answer rights requests on the company's behalf without instructions, or carry the company's fines. It is not a substitute for a Data Protection Officer, and it does not establish an EU establishment for Article 3(1) purposes. Write these limits into the appointment mandate so both parties know where the boundary sits.

Responsibility stays with the company

Appointing a representative does not transfer responsibility for compliance. The controller or processor remains accountable for lawful processing, security under Article 32, breach notification and every other duty, and supervisory authorities can act against the company directly. Treat the representative as a communication channel, and keep the security, records and rights-handling evidence inside your own systems where it can be produced on request.

What changes for your systems once GDPR applies

Once the GDPR applies to a system, scope decides which obligations an assessor or supervisory authority will test against it. The first question is not whether the regulation covers your company in general but which processing operations fall under it. Each system that holds personal data, including logs, backups, analytics tables and support tooling, needs a documented answer to that question. Three obligations usually carry the most technical weight: security of processing under Article 32, breach notification under Articles 33 and 34, and the handling of data subject rights. Records of processing under Article 30 sit alongside them and tell you what each system holds, why, and for how long.

Treat scope as a working inventory rather than a one-time legal opinion. For each in-scope system, record the personal data it holds, the lawful basis and purpose, where the data is stored, who can access it, and how it would be found, exported and erased on request. Detection and logging must show when a personal data breach could have occurred, because the 72-hour clock in Article 33 starts when the controller becomes aware of it. The sibling pages on GDPR security requirements, GDPR breach response and GDPR data subject requests set out the duties in detail. Confirm the exact obligations for your role with counsel or your DPO before you build against them.

Ownership is the point to settle early. Your organization owns its controls, its records and its decisions about what counts as in scope. An implementation partner such as DeployOpen can prepare systems and evidence: deletion paths, access logs, retention settings, backup restore procedures and rights-request workflows, all inside your own infrastructure. Only an independent assessor or certification body issues reports or certificates, and certification under Article 42 does not transfer responsibility away from you. Before engaging anyone, ask for a written scope listing the systems, data categories and deliverables covered, and confirm who signs off on the records.

Who decides scope, who prepares evidence and who can attest

This team owns the scope decision. It asks whether the organization has an establishment in the EU, whether it offers goods or services to people in the Union, or whether it monitors their behaviour there, and it records the answer and the reasoning. It also decides the role for each processing activity, because the same company may be a controller for its own marketing and a processor for a customer's platform. The conclusion is a legal position, not a technical finding, so it should be written down and reviewed when products, markets or vendors change.

Establishment test: Decide whether any branch, subsidiary or stable arrangement in the EU makes processing in its context subject to Article 3(1).
Targeting and monitoring test: Document whether offers to people in the Union or tracking of their behaviour under Article 3(2) apply, including free services and analytics.
Role analysis: Record whether the organization acts as controller, processor or joint controller for each activity.
Representative decision: Determine whether an Article 27 representative in the Union is needed, and check the exemptions in Article 27(2).
Regulator and court position: Remember that only supervisory authorities and courts decide enforcement. Guidance from the European Data Protection Board is persuasive, not a ruling on your case.

Check that the written scope memo names the people who signed it and the date of the last review.

Common questions about GDPR scope

Does a non-EU company need to comply with GDPR?

Yes, it can. A company outside the EU is in scope when it processes personal data of people in the Union in connection with offering them goods or services, paid or free, or when it monitors their behaviour as far as that behaviour takes place in the Union (Article 3(2)). Having an EU establishment also brings processing within scope under Article 3(1), wherever the processing physically happens. Scope depends on who you target and what you do with their data, not on where your company is incorporated. If you are unsure, map the flows that involve EU residents and check them against both paragraphs before deciding.

Are pseudonymised logs still personal data?

Yes. Recital 26 states that pseudonymised data remain personal data when they can be attributed to a person using additional information, such as a lookup table or a key held elsewhere. Logs that carry user IDs, session tokens or hashed emails usually stay in scope as long as the organization or another party can reverse the link. Truly anonymous data is outside the GDPR, but the test is whether re-identification is reasonably likely, judged by cost, time and available technology. Check who holds the mapping, whether it is separated and access-controlled, and whether the logs can be linked to other datasets you hold.

Does an IP address count as personal data?

It can. Recital 30 notes that people may be associated with online identifiers such as IP addresses and cookie identifiers, which can be combined with other information that servers receive to identify and profile them. A static IP address tied to a household, or an address logged alongside an account, is generally treated as personal data. Whether a given address is personal data depends on whether you or someone else can reasonably link it to a person. Document the decision for each log source, because a regulator or customer auditor will ask how you reached it.

Does hosting data in the EU make us in scope?

Hosting in the EU does not by itself decide scope, and hosting outside the EU does not remove it. Article 3(1) covers processing in the context of an establishment in the Union, regardless of where the processing takes place, while Article 3(2) covers non-EU organizations that target or monitor people in the Union. An organization that stores EU customer data on servers in Frankfurt but has no EU establishment and no EU targeting may still need to check Article 3(2). Data location matters for transfers under Chapter V, which is a separate question. Confirm with counsel whether your activities trigger either paragraph.

When does a non-EU company need an EU representative?

A non-EU controller or processor that falls under Article 3(2) must designate a representative in the Union in writing (Article 27(1)). The obligation does not apply to processing that is occasional, does not include large-scale processing of special category or criminal offence data, and is unlikely to result in a risk, nor to public authorities or bodies (Article 27(2)). Because the exemption depends on several conditions, record why each one applies or does not. The representative acts as a contact point for supervisory authorities and data subjects, and the role is usually a recurring cost, so ask providers what the written mandate covers before you sign.

How much effort does a GDPR scope check take?

The effort depends on how many systems, vendors and data flows touch personal data, and on how well they are documented. The main drivers are the number of processing activities, whether data about EU residents is collected directly or through customers, whether you monitor behaviour, how many sub-processors you use, and whether the data is pseudonymised or anonymised. A small product with one database and a clear customer base can be checked quickly. A platform with logs, analytics, backups and third-party tools will need an inventory first. No fixed duration applies, so ask for the work to be broken into inventory, legal analysis and sign-off, and agree on each deliverable in writing.

Can we run the GDPR scope check ourselves?

Often yes, for a clear-cut case, but the decision must be documented and owned by the organization. The GDPR does not require an external audit or certificate, so internal staff can map data flows, apply Articles 3, 4 and 27, and record their reasoning. Outside help is most useful when the activities are unusual, when a regulator or large customer will review the outcome, or when legal interpretation is needed on borderline cases such as analytics on EU visitors. DeployOpen can prepare the system inventory, logs and technical evidence for that review, but the legal scope conclusion remains with your organization and its counsel.

What to confirm with counsel before relying on this result

Treat the scope analysis on this page as a starting point for a conversation with qualified counsel, not as a conclusion. Before you rely on it, pull the current consolidated text of Regulation (EU) 2016/679 from EUR-Lex and read Article 3, Article 4 and Recital 26 yourself. Confirm that the wording you rely on is the version in force on the date you make the decision, and record that date. The text in force is the only text that matters, so a summary written earlier, including this one, should not be your evidence of scope.

Check the two pending files before you plan around them. As of October 2026 the GDPR text has not been amended, but the Omnibus IV proposal (procedure 2025/0130(COD)) and the Digital Omnibus proposal (procedure 2025/0360(COD)) are still moving through the EU institutions. Use the Legislative Observatory entry for Omnibus IV) and the Digital Omnibus entry) to see their status on the day you check. Ask counsel whether any proposed change could affect your territorial or material scope, such as a change to who counts as a controller or what counts as personal data, and whether a change would be relevant to your systems or only to documentation duties.

Confirm national and supervisory guidance in every Member State where you operate, offer services or monitor people. Supervisory authorities are independent, and their published positions on online identifiers, cookies, employee data and processor roles can differ in emphasis even though the Regulation is directly applicable. Ask counsel which authorities are competent for your establishments and main customers, and whether the EDPB guidelines on territorial scope are the guidance they apply. Keep a dated list of the guidance you relied on, because your position may need to be explained to a regulator or customer later.

How DeployOpen prepares systems and evidence once scope is confirmed

Once an organization has worked out whether the GDPR applies to a system, the practical question is what the system must show. DeployOpen plans, builds and documents self-hosted open-source platforms inside the client's own infrastructure, so the scope, the data flows and the evidence stay under the client's control. DeployOpen prepares the systems and records, while the organization keeps responsibility for its compliance decisions.

How we scope

The written scope lists the systems, data stores, identifiers and processing activities that fall under the GDPR analysis.
Scope names the EU establishment or Article 3(2) trigger the client relies on, and records who makes the final determination.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

Systems are deployed in the client's cloud accounts, data centers or air-gapped networks, with data locations documented from the start.
Logging and access settings are configured so that identifiers such as IP addresses and cookie IDs are handled as personal data.
Security testing covers applications, APIs and infrastructure, with findings tracked to remediation before handover.

How we hand over

Handover includes configuration records, data flow diagrams and a list of personal data categories found in each system.
Evidence packs map each system to the GDPR decisions the client must document, such as scope, roles and data locations.
The client receives runbooks and training so its own staff can operate and update the systems after handover.

How we support

Ongoing support, upgrades and continuous testing are available as retainers when the client wants them after handover.
Retainers can cover re-checking scope when new systems, identifiers or data flows are added to the platform.
Questions about whether the GDPR applies to a specific activity should go to qualified counsel or the supervisory authority, not to DeployOpen.

Does GDPR apply to us? Territorial and material scope