GDPR is often treated as “an EU problem”, but the regulation was designed to travel. If your company is outside the EU and you market to, sell to, or track people in the EU, GDPR regulations can apply to you through their extraterritorial scope (Article 3). The stakes are real: the GDPR allows administrative fines of up to €20 million or 4% of global annual turnover (whichever is higher), alongside corrective orders that can disrupt operations.

For non-EU businesses, the goal is not to copy an EU compliance program line-by-line. It is to build a defensible, documented, risk-based privacy program that matches what you actually do with personal data.

1) When GDPR regulations apply to non-EU companies (the Article 3 reality check)

GDPR can apply even if you have no EU office, no EU staff, and no EU servers. The most common “hooks” are:

• Offering goods or services to individuals in the EU (paid or free). Indicators include EU languages/currencies, EU delivery options, EU-focused ads, or EU customer support.

• Monitoring behavior of individuals in the EU, especially online (for example, tracking for analytics, profiling, targeted advertising, location tracking).

• Processing “in the context of an establishment” in the EU (for example, a branch office, representative office, or stable arrangements).

For the underlying legal text, see the GDPR on EUR-Lex.

Practical test: If an EU resident can sign up, be tracked, or be supported as a normal customer journey (not a rare accident), assume GDPR applies and document why.

2) Start with roles: controller, processor, or both

Your obligations change depending on whether you determine the “why and how” of processing (controller), process for someone else (processor), or share decisions (joint controllers). Many non-EU businesses are controllers for their own customer and marketing data, and processors for enterprise clients.

Typical implications:

• Controllers must provide privacy notices, choose lawful bases, enable data subject rights, and ensure appropriate transfer mechanisms.

• Processors must follow documented instructions, secure data, keep certain records, and sign GDPR-compliant processing agreements.

Misclassifying roles is a frequent source of contract and accountability gaps, especially in cross-border B2B relationships.

3) Data mapping that is useful (not just paperwork)

A “data map” is valuable when it answers four operational questions:

1. What personal data do we collect? (identifiers, contact info, device data, payments, HR data, etc.)

2. Why do we need it? (the specific purpose, not broad statements)

3. Where does it go? (systems, vendors, countries)

4. How long do we keep it? (retention by category)

This feeds directly into your Article 30 Records of Processing Activities (RoPA) (required in many cases, and still a best practice even when an exemption might apply).

4) Lawful bases: choose one per purpose, then align your UX and contracts

Non-EU teams often stumble by treating “consent” as the default. GDPR requires a lawful basis under Article 6, and the right choice depends on purpose and user expectations.

Two common fixes that immediately reduce exposure:

• Separate “service essential” processing (contract/legal obligation) from optional processing (consent or legitimate interests).

• Make your cookie and tracker decisions consistent with your lawful basis strategy. If you rely on consent for certain tracking, your banner and tag management must actually enforce it.

5) Privacy notices that match reality (Articles 13 and 14)

A compliant privacy notice is not a marketing page. It should be readable, complete, and aligned with actual processing.

At minimum, ensure you accurately describe:

• Controller identity and contact details

• Purposes and lawful bases

• Categories of recipients (including key vendors)

• International transfers and safeguards

• Retention periods (or criteria)

• Data subject rights and how to exercise them

• Complaint route (relevant supervisory authority)

If you obtain data indirectly (for example, lead lists, referral partners), Article 14 duties may apply.

6) Data subject rights: build an internal “request-to-resolution” path

Even with no EU office, you must be able to handle EU rights requests within GDPR timelines (generally one month, with limited extensions).

Operationally, what matters is not just a webform. It is:

• Identity verification proportional to risk

• A defined process to search across systems and vendors

• Decision rules for exemptions (for example, legal privilege, certain legal claims contexts)

• A consistent response package and logging

For companies with litigation risk, a good rights-handling process also helps avoid inconsistent statements that later appear in disputes.

7) Vendor contracts (Article 28) and cross-border transfers (Chapter V)

Processor and sub-processor contracts

If vendors handle personal data for you (cloud hosting, CRM, email delivery, analytics, payment providers), your contracts should clearly allocate:

• Processing instructions and confidentiality

• Security measures

• Sub-processing controls

• Assistance with rights requests and breaches

• Deletion/return at end of service

• Audit and compliance information

International transfers: don’t stop at “we signed SCCs”

If EU personal data is transferred outside the EEA, you need a valid transfer mechanism, commonly:

• Adequacy decision (where applicable)

• Standard Contractual Clauses (SCCs) plus a Transfer Impact Assessment (TIA) where required

• Binding Corporate Rules (usually for larger groups)

After the Schrems II decision, regulators expect exporters and importers to assess access risks and, where needed, implement supplementary measures. The European Data Protection Board provides guidance on transfer assessments and supplementary measures on the EDPB website.

If your vendors are in the United States, also check whether the relevant entity participates in the EU-US Data Privacy Framework (where that is appropriate for your transfer scenario), and still document how your overall transfer approach works.

8) Security (Article 32): align measures to the data and threat model

GDPR does not mandate a single security standard, but it does require “appropriate” measures. In practice, regulators look for evidence of mature basics:

• Access control (least privilege, MFA)

• Encryption in transit, and at rest where appropriate

• Secure backups and restore testing

• Patch management and vulnerability handling

• Logging and monitoring, especially for admin actions

• Secure SDLC practices for applications

Security must match the sensitivity of the data. For example, health and therapy data, biometric identifiers, and children’s data generally require a higher bar.

As an illustration, providers offering speech and language services, occupational therapy, or psychological support often handle sensitive information that can fall into “special categories” under GDPR. A clinic like Bridges Speech Center is a good example of the type of organisation that would typically need stricter controls, clear consent pathways where appropriate, and carefully managed access due to the nature of the data involved.

9) Breach readiness: 72 hours is a governance test, not a stopwatch

Under Article 33, certain personal data breaches must be notified to the competent supervisory authority within 72 hours of becoming aware, unless the breach is unlikely to result in risk to individuals. Under Article 34, affected individuals must be informed when there is a high risk.

Non-EU companies should pre-decide:

• What constitutes “awareness” internally

• Who leads triage (legal, security, operations)

• How to assess risk to individuals

• How vendor incidents are escalated and timed

A written incident playbook plus periodic tabletop testing is often the difference between a controlled response and a costly scramble.

10) Do you need an EU representative (Article 27) or a DPO (Articles 37 to 39)?

EU representative

Many non-EU controllers and processors subject to GDPR must appoint an EU representative (with some exceptions, such as occasional low-risk processing). This is not a box-ticking exercise. The representative becomes a contact point for regulators and individuals, and your notices should reflect the representative’s details.

Regulators such as the UK ICO (for UK GDPR matters) provide practical explanations of representative requirements. See the ICO guidance on representatives for organisations outside the UK.

Data Protection Officer (DPO)

A DPO is required in specific cases (for example, large-scale monitoring or large-scale processing of special category data). If you do not appoint a DPO, you should still assign accountable owners for privacy governance.

11) DPIAs: use them to reduce risk before you launch

A Data Protection Impact Assessment (DPIA) is required when processing is likely to result in high risk, often including:

• Systematic monitoring (especially at scale)

• Large-scale processing of sensitive data

• New technologies used in ways that materially affect individuals

A good DPIA is practical: it documents the processing, assesses necessity and proportionality, identifies risks to individuals, and records mitigations. It also creates an audit trail showing you considered privacy before deployment.

12) Common non-EU compliance pitfalls (and quick fixes)

Pitfall: “We’re B2B, so GDPR doesn’t apply.” If you process personal data of EU individuals (even in a work context), GDPR can still apply.

Pitfall: Cookie banners that do not control tags. If tags fire before consent, your banner may create more risk than it reduces.

Pitfall: One global privacy notice that never matches operations. Create a master notice, then tailor by product and region where needed.

Pitfall: SCCs signed, but no transfer assessment. Treat SCCs as the contract layer, and TIAs as the reality-check layer.

Pitfall: No retention rules. Keeping everything “just in case” increases breach impact and makes rights requests harder.

A practical “first 30 days” plan for non-EU companies

If you need traction quickly, aim for outcomes you can prove:

• Confirm whether you are within scope (document your Article 3 analysis)

• Create or refresh your data map and RoPA

• Fix lawful bases for core journeys (sign-up, purchase, support, marketing)

• Update privacy notice and cookie approach to match actual tracking

• Put Article 28 vendor terms in place for high-impact vendors

• Decide your transfer mechanisms and complete priority TIAs

• Stand up a rights-request workflow and breach playbook

How counsel can help (especially for cross-border risk)

GDPR compliance is partly operational, but the hard edges are legal: role allocation in contracts, lawful basis defensibility, cross-border transfers, DPIA conclusions, and regulator-facing decisions after an incident.

Henlin Gibson Henlin advises on data privacy, compliance, and risk, with the cross-border perspective many Jamaica-based and international businesses need when EU data enters the picture. If your organisation is expanding into EU markets, integrating new tracking and analytics, or handling sensitive categories of data, getting the compliance architecture right early is usually far less costly than rebuilding it during an investigation or dispute.

This article is for general information and does not constitute legal advice.