Compliance Basics for Overseas Sites: How to Handle GDPR, Cookies, and Cross-Border Data

Bottom line first: Compliance isn’t “adding a cookie popup” — it’s getting three flows right: data collection, data storage, and data transfer. Most overseas sites only fake the first layer: the popup is there, but tracking scripts keep running after users click “Reject.”This kind of “compliance theater” is riskier than having no popup at all.

This article is an engineering-practice summary and does not constitute legal advice. For specific legal applicability and risk assessment, please consult a professional legal advisor.

1. First, distinguish the three roles

The easiest thing to blur in compliance discussions is “who am I.” The GDPR framework has three roles, and your obligations depend on where you stand:

Role	Definition	Typical scenario	Main obligations
Data Controller(Controller)	The party that determines the purpose and means of processing	Your overseas site collects visitor and customer data	Establish a legal basis, provide notice, respond to data subject rights
Data Processor(Processor)	Processes data on behalf of the controller	For sites you build for clients, the client is the controller	Process per controller instructions, ensure security
Third parties(Third Party)	Independently determines processing purposes	Analytics tools and ad platforms you embed	Each bears controller responsibility

This distinction is especially important for overseas businesses, because it determines two completely different scenarios:

Scenario	Who you are	Compliance responsibility holder
Building your own overseas site, collecting customer data yourself	Controller	Yourself
Building and maintaining sites for clients	Processor	The client (but you must provide compliant technical capabilities)
Site embeds third-party analytics/ads	Controller (and transfers to third parties)	Yourself + third parties

The second line is the key: If you build sites for clients, your obligation isn’t to “make your client compliant” — it’s “to give them tools that make compliance possible”— for example, a switch to turn off tracking, cookie category controls, data export. That’s why we made “separate tables for technical data and personal data” the default in the plugin design.

II. Four regulatory scenarios you have to handle

An overseas-facing site usually faces four sets of requirements at once, each looking at a different layer:

Regulation / Scenario	Main focus	Impact on the site
GDPR(EU)	Lawful processing of personal data, data subject rights	Legal basis for forms and tracking, notice and consent, right to erasure
ePrivacy / Cookie rules(EU)	Non-essential cookies require prior consent	The cookie banner must actually work (refuse means stop)
US state laws(such as CCPA/CPRA)	Right to know, right to opt out, non-discrimination	Provide a way to opt out of “sale/sharing of my personal information”
Cross-border transfers	Legal mechanisms for moving data out of the EU	Server location, deployment region of third-party tools

All four share one thing: they require mechanisms that actually work, not a block of declaration text. Users must be able to really refuse, really opt out, really delete.

III. Cookie categories and how to handle them

This is the most common step and the easiest to get wrong.

How to handle the three cookie categories

Category	Examples	Prior consent required?	Behavior after refusal
Strictly Necessary	Session, login state, CSRF token, language preference	❌ Not required	Must keep working
Analytics	Visit statistics, conversion tracking	✅ Required	Must not load
Marketing / Advertising	Ad platform pixels, retargeting tags	✅ Required	Must not load

The easiest thing to get wrong

“Refuse means stop” means the script doesn’t load — not that it loads and then doesn’t send data.

How to do it	Compliant?	Description
After the user refuses, the analytics script doesn’t load at all	✅ Compliant	The right way
After the user refuses, the script still loads but checks a flag and doesn’t send data	⚠️ High risk	The script has already run; it may have written cookies or opened a connection
After the user refuses, “anonymous analytics” still loads	⚠️ Needs assessment	Depends on whether personal data is involved; by default, treat it as requiring consent
The banner only has an “Accept” button, or “Reject” is buried on a second-level page	❌ Non-compliant	Consent must be as easy as refusal

“How visible the reject button is” is a key focus for regulators. If “Accept all” is a prominent button while “Reject” is small gray text or requires going into settings and turning things off one by one, in practice this will be found to be “no valid consent obtained.”

Implementation checklist

#	Project	Acceptance Criteria
1	Cookie category list	List every cookie the site loads, with its category and purpose
2	Three-button banner	“Accept all” / “Necessary only” / “Settings” (equally visible)
3	Don’t load after refusal	Verified: no analytics/ad scripts in network requests after rejection
4	Consent can be withdrawn	A “Cookie Settings” link in the footer lets users change their choice at any time
5	Consent records	Log the time of consent, the version, and what was selected (as evidence)
6	Cookie policy page	Explain the purpose, retention period, and third parties for each cookie category

4. Data collection

Forms are where you collect personal data most directly, and where compliance requirements pile up the thickest.

Project	Requirement	Common mistake
Clear purpose	Every field on a form should have a stated purpose	Collecting “company size” with no idea what it’s for
Data minimization	Don’t collect fields unrelated to the purpose	Asking for address, postal code, fax number
Notice	A privacy policy link and a short explanation before submission	Link only in the footer, nothing next to the form
Legal basis	A clear basis (consent / contract performance / legitimate interest)	Never considered the question at all
Checkbox	If you rely on consent, it must be unchecked by default	Checked by default (invalid consent)
Third-party sharing	If data goes to a third party (e.g. a CRM), say so	Data flows undisclosed
Retention period	State how long data is kept	Indefinite retention promised

One concrete test:“Why do you need this field?” If the only answer is “it might be useful someday,” don’t collect it.The practical standard for data minimization: only collect what you can justify for a current purpose.

5. Data storage and transfers

This layer is the easiest to overlook because it never shows up on the page.

5.1 Servers and data location

Project	What to confirm
Host location	Which country/region the database and file storage physically sit in
Backup location	Whether backups are stored locally too (a common slip: backups synced to a cloud drive in a third country)
CDN	Whether the CDN logs original IPs, and how long logs are kept
Posts	Server access logs contain IPs (personal data) — what are the retention period and access controls?

“Where do backups live?” is a frequent blind spot. The primary database is in Germany, but automatic backups sync to a cloud drive in a default US region — that’s a cross-border transfer, and most companies never realize it.

5.2 Third-party tools

Tool type	Compliance points
Analytics	Does it transmit original IPs? Does it offer a data processing agreement? Where are its servers?
Ad platform	Does it load before consent is given? Does it transmit form data?
Email platform	Is customer data uploaded? Is there a data processing agreement?
Support / chat widget	Does it record conversations? Where is it stored?
Fonts / maps / video embeds	Do they send requests to third parties (which transmits visitor IPs)?

The last row deserves special attention: Many sites use web fonts or map components from third-party CDNs to “load faster.”These requests send visitor IPs to third parties— EU case law has already found this to constitute personal data transfer, requiring a legal basis.The solution is locally self-hosted fonts and critical resources.

5.3 Technical Implementation of Data Subject Rights

GDPR requires you to respond to data subject rights requests: access, rectification, erasure, portability, and objection. On the technical side, you need the corresponding capabilities:

Right	Technical Requirement
visit	Export all records for that data subject by email/identifier
Rectification	Edit the relevant records
Delete	Delete or anonymize the relevant records (including a backup handling policy)
Portability	Export in a common format (CSV / JSON)
Objection	Flag the record and stop further processing (e.g. marketing)

“Erasure” is the most troublesome one technically, because data is usually spread across multiple systems (site database, CRM, email platform, analytics tools). The recommended approach:Build a “data map” listing every system that holds personal data and how to delete from it — this list saves a lot of digging when an erasure request comes in.

6. Common Mistakes and a Self-Check List

Six Common Mistakes

#	Mistake	Risk
1	The popup only has “Accept”; rejecting is inconvenient	Invalid consent, and a frequent enforcement target
2	Tracking scripts still load after rejection	A substantive violation, and the evidence is visible (network requests)
3	Fonts / maps / video embeds pass IPs to third parties	Data transfer without consent
4	Backups synced to an overseas cloud drive without an assessment	Undisclosed cross-border transfer
5	Consent checkbox pre-ticked on forms	Treated as invalid consent
6	The privacy policy is a template and doesn’t match actual practice	What you state doesn’t match what you do, which increases liability

Item 6 is the most common. Many sites going global use a template-generated privacy policy that mentions tools that don’t match what’s actually deployed (or doesn’t mention the tools actually in use at all).From a regulator’s point of view, “what you say doesn’t match what you do” is more serious than “you left something out.”

Pre-Launch Self-Check List

#	Checklist	Pass criteria
1	The cookie list matches reality	Verify with browser developer tools; nothing missed
2	All three popup buttons are equally visible	Keep a screenshot as evidence
3	No analytics/ad requests after rejection	Test with the developer tools network panel
4	A withdrawal entry point exists	Clickable in the footer; choices can be changed
5	Fonts and static resources are localized	No third-party domain requests (or a compliance assessment is in place)
6	No pre-ticked boxes on forms; policy link present	Check each form one by one
7	The privacy policy names the third parties actually in use	Compare item by item against the tool list
8	A data map has been built	Covering systems, data items, deletion method, and owner
9	Backup and log locations confirmed	Including retention periods and access controls
10	The erasure request response process has been rehearsed	Run through the full process at least once

FAQ

Our site mainly serves non-EU customers — do we still need to worry about GDPR?

You need to assess it; you can’t simply ignore it. GDPR applicability doesn’t depend only on where the company is registered, but also on whether you offer goods/services to data subjects in the EU(the “targeting” test). Signals include: pricing in euros with EU delivery, EU languages, ads run in the EU, and pages aimed at the EU market.If EU visitors can submit a form at all, you need basic compliance, even if you are not an EU company.

How to do it	Can you avoid consent?
No cookies at all, no cross-site tracking, no raw IP retention	More likely to count as strictly necessary or low risk
Using a cookie to generate a visitor ID (even without a name)	Consent is usually still required
Retaining raw IPs for geographic stats	Consent required (IP addresses are personal data)

Can “anonymous analytics” let me skip the banner?

It depends on how it is built:The test is whether you can identify an individual, or track the same person across sites. If it is the latter, you usually need consent up front. That is why our visitor attribution defaults to a lightweight approach: read the CDN country header and infer from time zone —no external requests, no extra data collection, and far easier to explain to a regulator.

How long should you keep cookie consent records?

Recommendation Keep them as long as your data processing requires, usually 6–24 months. At minimum, record the time of consent, the version (which policy version), what was chosen (which categories were accepted), the source (which domain or page), and an identifier you can use to withdraw tracking.The value of this record is that it proves your case: if someone claims a user never consented, you can show them the record.

Item	Owner
The substance of the privacy policy	The client (you provide the template and technical support)
Technical compliance features (banner, reject option, export)	You (this is part of delivery quality)
Data Processing Agreement (DPA)	Signed by both parties

Client sites are our service delivery — are we a controller or a processor?

You are usually the Processor(the client decides what data is collected and why), and the client is the controller. That means:So when you build sites for clients, list “compliance features” as a deliverable, rather than patching it in after a client gets a complaint.

Measure	Description
Retention limits	Set as needed (e.g. 30–90 days), with automatic deletion when they expire
Access control	Logs open only to the people who need them
Purpose limitation	Used only for security and operations, never for visitor profiling
Cross-border assessment	Log server locations must be included in the cross-border assessment

If I store visitor IPs in server logs, is that personal data?

Yes. Under GDPR, IP addresses are widely treated as personal data (they can be combined with other information to identify a person). So server logs need compliant handling too:In practice you do not need to panic, but you do need clear rules: set a retention period, restrict access, restrict purpose. Do those three things and log risk is largely under control.

Level	Status	Verdict
Compliance on paper	A banner and a policy exist, but tracking keeps running after a user rejects	❌ Highest risk (you have evidence you knew and did not act)
Basic compliance	Working cookie banner, policy matches reality, opt-out available	✅ A reasonable goal for most sites going global
Full compliance	Add a data inventory, deletion process, consent records, cross-border assessment	✅ Recommended if you serve EU business customers

How much compliance is “enough”?

There’s no absolute standard, but there is a practical rule of thumb:“If someone asks how you handle data, can you produce documentation they can verify and steps they can reproduce?” The level you most need to avoid is the first one— it looks like a site that has “done compliance,” but it leaves behind the most direct evidence that you haven’t.

Final thoughts

In global business, compliance is often treated as a “legal issue” or a cookie banner you add before launch. But from an engineering standpoint, it’s really about how well you execute three chains:

Collection: collect only what’s necessary, state the purpose clearly, allow opt-out
Storage: know where the data is, how long you keep it, and who can access it
Transfer: know who you give the data to, which country it goes to, and on what legal basis

Once those three chains are clear, your privacy policy can match reality, and you can produce evidence when asked.

The value of compliance isn’t just “avoiding penalties” — it’s also part of trust. When overseas B2B customers evaluate suppliers, data handling practices show up more and more often in tenders and supplier review checklists —a supplier that fakes even its cookie consent is hard to trust with any other promise.