Article 3: Territorial scope

To meet the article 3: territorial scope requirement, you must determine whether your organization’s personal data processing is “in the context of the activities of an establishment” in the EU and, if so, treat that processing as GDPR in-scope even when the data or systems sit outside the EU. Document the scope decision and wire it into intake, contracting, and system governance. (Regulation (EU) 2016/679, Article 3)

Key takeaways:

• If you have an EU establishment (controller or processor), GDPR can apply to related processing anywhere. (Regulation (EU) 2016/679, Article 3)
• Operationalize Article 3 by maintaining a role-and-scope register, a decision procedure, and recurring evidence packets. (Regulation (EU) 2016/679)
• Auditors expect a defensible scoping record tied to systems, data categories, and third parties, not just a policy statement. (Regulation (EU) 2016/679)

Article 3 is the “gate” requirement: it decides whether GDPR obligations attach to a processing activity at all. For a Compliance Officer, CCO, or GRC lead, the practical task is scoping with discipline. That means you need a repeatable method to answer: do we have an EU establishment, are we acting as controller or processor for the activity, and is the processing carried out “in the context of the activities” of that establishment? If yes, GDPR applies even if the data is processed on infrastructure outside the EU. (Regulation (EU) 2016/679, Article 3)

Teams lose time and credibility when scoping decisions live in email threads or slide decks that never reach procurement, engineering, or the data inventory. Your goal is a single source of truth that connects (1) the legal basis for GDPR applicability to (2) the operational reality of systems, data flows, and third parties. That scope then drives downstream controls: Records of Processing, DPAs, transfer assessments where relevant, incident response, and data subject request workflows.

This page gives requirement-level implementation guidance you can execute quickly: a scoping decision matrix, a procedure with named owners and triggers, and the evidence you should retain to survive regulator questions and customer due diligence.

Regulatory text

Text (excerpt): “This Regulation applies to the processing of personal data in the context of the activities of an establishment of a controller or a processor in the Union, regardless of whether the processing takes place in the Union or not.” (Regulation (EU) 2016/679, Article 3)

Operator meaning: If your organization has an EU establishment and personal data processing is connected to that establishment’s activities, treat the processing as GDPR in-scope even if the processing happens outside the EU (for example, US-hosted SaaS, offshore support, or a non-EU data center). Your job is to (1) decide and document whether each relevant processing activity is in scope and (2) ensure the organization’s control environment follows that scope. (Regulation (EU) 2016/679, Article 3)

Plain-English interpretation (what the requirement is asking)

Article 3(1) is not a “data location” rule. It is an establishment-and-activities rule. If you are established in the EU, GDPR can follow the activity wherever it is executed. (Regulation (EU) 2016/679, Article 3)

For most operators, the tricky phrase is “in the context of the activities.” Translate that into operational questions you can test:

• Which EU entity/team/function is involved (sales, customer success, HR, R&D, support)?
• Which processing activities support that EU function (customer account management, payroll, lead management, product telemetry, fraud monitoring)?
• Which systems and third parties execute those activities (CRM, ticketing, data warehouse, analytics tools, payroll provider)?

If the activity supports or is linked to the EU establishment’s business activities, you should assume GDPR applies and build controls accordingly, unless counsel documents a narrower position for a specific edge case. (Regulation (EU) 2016/679, Article 3)

Who it applies to (entity and operational context)

This requirement applies to:

• Controllers with an EU establishment whose processing is in the context of that establishment’s activities. (Regulation (EU) 2016/679, Article 3)
• Processors with an EU establishment processing personal data in the context of that EU establishment’s activities (for example, an EU office supporting delivery or account operations). (Regulation (EU) 2016/679, Article 3)

Operationally, you should treat Article 3(1) as relevant whenever any of the following are true:

• You have an EU office, branch, subsidiary, or other stable EU presence performing real business functions.
• An EU team influences how data is handled (decides tools, sets process, administers systems, or manages relationships).
• The processing supports EU customers, EU workforce operations, or EU go-to-market activity, even if the servers are elsewhere. (Regulation (EU) 2016/679, Article 3)

What you actually need to do (step-by-step)

The fastest path is to run a structured scoping exercise and then lock it into governance so it stays current.

Step 1: Establish your “EU establishment” inventory

Create an inventory of EU establishments and their activities:

• Legal entities in the EU (subsidiaries, branches).
• Physical offices and the functions performed there.
• EU-based staff working remotely and which entity/function they report into.

Output: “EU Establishment Register” (owner: Legal/Compliance; contributors: HR, Finance, Sales Ops). (Regulation (EU) 2016/679, Article 3)

Step 2: Build a processing activity list tied to business activities

Start from how work actually happens:

• Customer lifecycle: marketing → sales → onboarding → support → renewal.
• Workforce lifecycle: recruiting → onboarding → payroll/benefits → performance → offboarding.
• Product lifecycle: user analytics → feature flags → logging/monitoring → security operations.

Map each activity to:

• Data categories (customer contacts, end-user data, employee data).
• Systems of record.
• Third parties that touch the data (SaaS tools, cloud providers, consultants).

Output: A processing activity catalog aligned to your Record of Processing approach, but focused on territorial scope decisions. (Regulation (EU) 2016/679)

Step 3: Decide controller vs. processor role per activity, then decide Article 3(1) scope

For each activity, document:

• Your role (controller or processor).
• The EU establishment link (which EU entity/team/activity is connected).
• The scope decision: “GDPR applies under Article 3(1)” or “Not in scope under Article 3(1),” with rationale. (Regulation (EU) 2016/679, Article 3)

A simple decision table works well:

Question	Evidence to check	Result
Do we have an EU establishment involved in this business area?	Entity chart, org chart, office functions	If yes, proceed
Is this processing in the context of that establishment’s activities?	Process map, system ownership, operational responsibility	If yes, GDPR applies
Does processing occur outside the EU?	Hosting diagrams, vendor locations	Note: does not remove scope

Output: A “GDPR Role-and-Scope Register” that is reviewable and auditable. (Regulation (EU) 2016/679)

Step 4: Convert the scope decision into operational triggers

Write a short operating procedure that defines:

• Owners: who maintains the register, who approves scope calls, who is consulted (Legal, Security, Procurement, Product).
• Trigger events: new EU office/entity; new product line serving EU; new system of record; new third party; major data flow change; M&A.
• Control actions when in scope: require GDPR-aligned contracting and privacy review gates for in-scope activities (for example, DPA templates and vendor onboarding checks).

This is where teams usually fail: they do the initial scoping once and never connect it to change management. Your procedure fixes that. (Regulation (EU) 2016/679)

Step 5: Embed Article 3 scope into third-party onboarding and system governance

Make the scope register a required input to:

• Third-party intake (is this tool supporting an in-scope activity?).
• Architecture review (is the system used for EU establishment-linked processing?).
• Data inventory/RoPA updates.
• Security risk assessments and incident response scoping.

If you use Daydream for third-party risk management, treat Article 3 scope as a mandatory field in intake workflows so procurement cannot finalize onboarding without a scope decision and the supporting evidence attached.

Step 6: Run a recurring evidence cadence

Maintain an “evidence packet” per review cycle:

• Current role-and-scope register export.
• List of changes since the last cycle and approvals.
• Exceptions granted (who approved, compensating controls, remediation plan).
• Sampling proof: a few third-party onboarding records showing the scope gate was applied. (Regulation (EU) 2016/679)

Required evidence and artifacts to retain

Auditors and customers will ask how you decided GDPR applies. Retain artifacts that show your decision path and ongoing operation:

1. EU Establishment Register (entities, offices, functions).
2. GDPR Role-and-Scope Register per processing activity (role, data categories, systems, third parties, Article 3(1) decision, rationale).
3. Requirement-specific operating procedure (owners, triggers, approvals, review cadence).
4. System/data flow diagrams tied to in-scope activities (high-level is fine; accuracy matters).
5. Third-party due diligence and contracting records for in-scope activities (intake ticket, security review, DPA status).
6. Evidence packets showing periodic review, exceptions, and remediation tracking. (Regulation (EU) 2016/679)

Common exam/audit questions and hangups

Expect questions like:

• “Show me how you determined which processing is in scope under Article 3(1).” (Regulation (EU) 2016/679, Article 3)
• “Which EU establishment(s) do you have, and what activities do they perform?” (Regulation (EU) 2016/679, Article 3)
• “Where is processing performed, and why does location not change your scope decision?” (Regulation (EU) 2016/679, Article 3)
• “How do you ensure new tools and third parties supporting EU-linked processing go through GDPR review?”
• “Who approves scope determinations, and how do you document disagreements or exceptions?”

Hangups that derail reviews:

• Confusing “EU data subjects” with “EU establishment” for Article 3(1). Article 3 has multiple parts, but this page operationalizes the provided 3(1) excerpt only. (Regulation (EU) 2016/679, Article 3)
• Treating hosting location as the scope determinant.
• Not being able to tie the scope decision to a specific system list and third-party list.

Frequent implementation mistakes and how to avoid them

1. Mistake: A narrative memo with no system mapping.
   Fix: require system IDs, data categories, and third-party names in the role-and-scope register.

2. Mistake: Scope decided once during GDPR “project mode,” then forgotten.
   Fix: add trigger-based updates and a recurring review with an evidence packet.

3. Mistake: Procurement onboards third parties without a territorial scope check.
   Fix: add a mandatory question in intake, “Does this support an EU establishment-linked processing activity?” and route “yes” to privacy/security review.

4. Mistake: Controller/processor role is assumed globally.
   Fix: decide role per activity. Your role can differ by product line or relationship.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions.

Operational risk is still real: if you under-scope Article 3(1), you will likely under-implement GDPR controls for activities that are actually in scope. That creates downstream exposure in contracting, incident response, and customer audits, because your governance artifacts will contradict your business footprint. (Regulation (EU) 2016/679, Article 3)

Practical 30/60/90-day execution plan

You asked for speed. Here is a plan that produces usable artifacts early, then hardens operations.

First 30 days (get to a defensible scope decision)

• Stand up the EU Establishment Register (Legal/Compliance owner; HR/Finance inputs).
• Draft the GDPR Role-and-Scope Register template (fields: activity, role, EU establishment link, systems, third parties, decision, rationale).
• Run workshops with Sales Ops, HR, Product, Security to populate the first cut for the highest-risk activities (customer and employee systems of record).
• Publish a one-page operating procedure for Article 3(1) scope decisions and approvals.

Days 31–60 (connect scope to workflows)

• Add Article 3(1) scope as a required field in third-party intake and system onboarding.
• Train Procurement, IT, and business system owners on the trigger events and what “in scope” changes in practice.
• Create the first evidence packet: register export, approvals, and a small sample of onboardings showing the gate worked.

Days 61–90 (prove it operates and close gaps)

• Run a change review: new tools, new EU roles, new data flows since Day 1.
• Identify exceptions (legacy tools, shadow IT) and create remediation tickets with owners.
• Align the scope register with your broader GDPR documentation set (RoPA/data inventory) so you have one consistent story for customers and regulators. (Regulation (EU) 2016/679)

Frequently Asked Questions

Do we have to comply with GDPR if our servers are outside the EU?

If processing is in the context of the activities of your EU establishment, GDPR applies regardless of where the processing takes place. Document the scope decision and link it to the relevant systems and third parties. (Regulation (EU) 2016/679, Article 3)

We have an EU sales office, but engineering is in the US. Is product analytics in scope?

Treat this as a scoping question tied to the EU establishment’s activities: if analytics supports the EU establishment’s business activities (for example, EU customer acquisition/retention operations), you should document why it is in or out of scope under Article 3(1). (Regulation (EU) 2016/679, Article 3)

Does Article 3(1) apply to processors too?

Yes. The excerpt applies to processing in the context of activities of an establishment of a controller or a processor in the Union. Your obligations still depend on your role per activity, so document controller vs. processor in the same register. (Regulation (EU) 2016/679, Article 3)

What evidence will a customer or auditor accept for territorial scope?

Provide an EU Establishment Register, a role-and-scope register tied to systems and third parties, and an operating procedure that shows updates happen on trigger events and review cycles. Policy text alone rarely answers “how do you know?” questions. (Regulation (EU) 2016/679)

How do we operationalize this across third parties without slowing procurement?

Add a single required intake question tied to your scope register, then auto-route “in scope” onboardings to a standard privacy/security checklist and approved contract language. Tools like Daydream help keep the decision, approvals, and evidence in one workflow record.

Who should own Article 3 scoping decisions?

Compliance or Privacy typically owns the register and procedure; Legal approves edge-case interpretations; Security and Procurement own enforcement in onboarding and system change workflows. Make ownership explicit in the operating procedure so decisions do not drift. (Regulation (EU) 2016/679)