⚡ Quick answer: GDPR doesn’t apply to a company simply because its site is reachable from Europe. Under Article 3 it applies to a non-EU business only if you offer goods or services to people in the EU, or monitor their behaviour there. Signs of intent: prices in euros, a language version aimed at a specific market, delivery to EU countries. If that’s you, three things are needed: a privacy policy, a correctly implemented cookie banner, and clear consent on forms. Fines reach €20 million or 4% of global annual turnover, whichever is higher.
A note upfront: this is an overview, not legal advice. It will help you know which questions to ask and what’s worth doing on the technical side — but documents for a specific business should be reviewed by a lawyer.
The most common misconception runs like this: “the site is accessible from Europe, therefore GDPR applies.” It doesn’t work that way, and the regulation’s own text is fairly specific.
Article 3 describes two situations where GDPR reaches a company with no EU establishment:
The operative word is intent. Technical accessibility from Europe doesn’t demonstrate it. What does: prices in euros, a dedicated language version for a European market, delivery terms for EU countries, advertising aimed at a European audience.
The second limb — monitoring — catches more companies than people expect. If you install an advertising pixel and build audiences for retargeting, and some of your visitors are in the EU, you are monitoring their behaviour.
Worth stating plainly, because a fair amount of unnecessary service has been sold on GDPR anxiety.
| Situation | GDPR |
|---|---|
| Local business, local-language site, domestic clients | Most likely no |
| Local-language site, someone from the EU stumbles in | No — incidental reach doesn’t count |
| You have an English version and prices in euros | Yes, that indicates intent |
| You accept European cards and ship to the EU | Yes |
| You advertise to audiences in EU countries | Yes |
If entering the European market is in your plans, it’s worth building that into the site structure early — we covered this in the piece on multilingual websites. The legal side follows the same rule: cheaper upfront than retrofitted.
Independently of GDPR, most countries have their own personal data legislation, and it usually requires the same two things: telling people why you’re processing their data, and having a lawful basis for doing so.
For a website that means what the European logic means: you can’t quietly collect a name, phone number and email from a form and use them however you like. The person has to understand what the data is for and what happens to it.
Worth knowing that this area of law keeps moving. Ukraine, where our team is based, has a draft reworking of its personal data law intended to bring national rules closer to European standards; it passed a first reading at the end of 2024 and was being revised through 2025. Because the status of such documents changes, check the current state before relying on specific provisions — and do that with a lawyer rather than a blog post.
The good news: the practical steps below are needed under any version. Nobody has repealed the requirement to explain to people what you do with their data.
The question owners ask first is simple: what happens if we do nothing.
The GDPR ceiling looks frightening: up to €20 million or 4% of global annual turnover, whichever is higher. But context matters: those sums are applied to serious breaches by large organisations, not to a brochure site missing a cookie banner. Regulators weigh the nature of the breach, how long it lasted, how many people were affected, and whether the company cooperated. For a small business the realistic scenario isn’t a multimillion fine but a complaint from a specific person, a demand to delete data, and friction with a European partner for whom compliance is a condition of doing business. In Netloria’s experience that last one is the actual trigger far more often than any inspection: a company operates for years with no policy, then a large EU client sends a supplier questionnaire with questions about data processing — and there’s nothing to put in the answers.
So the motivation here is commercial rather than fear of punishment. Compliance is an entry condition for certain markets and certain clients.
The minimum set looks like this, and for most businesses it’s enough.
Privacy policy. The main document. It should answer plain questions: what data you collect, why, how long you keep it, who you share it with (that includes Google Analytics, ad platforms, CRM, delivery services), and how someone can ask for deletion. Link it from the footer of every page.
Cookie policy. Either a separate document or a section of the privacy policy. It describes which files you set and why.
Terms of service or a public offer. Mandatory for stores: ordering, payment, delivery and returns. For a services site, situational.
The worst thing you can do with these documents is download the first template you find and not read it. They typically retain somebody else’s company name, mentions of services you don’t use, and references to a jurisdiction you have nothing to do with. Such a document is worse than none: it creates the appearance that the question is settled while actually describing a different business. At Netloria we routinely find, during technical audits, policies listing analytics tools that aren’t on the site — and conversely, scripts that are installed but appear nowhere in the document.
This is where most of the confusion sits, because banners get installed “just in case” without understanding the logic.
The rule set by the European directive is straightforward: consent must be obtained before any cookies are set, except strictly necessary ones. Strictly necessary means the ones without which the site doesn’t function: cart storage, authentication, language settings. Those don’t need consent, but their purpose should still be explained.
Everything else — analytics, advertising pixels, chat widgets, embedded maps — requires consent in advance.
What makes a banner pointless:
An enquiry form is the most common point where personal data gets collected, and it’s the easiest place to get right.
The working minimum: a separate, unticked checkbox with short text along the lines of “I consent to the processing of my personal data in accordance with the privacy policy,” where the policy is a link. The wording should be comprehensible to someone without a legal background.
What not to do: merge consent to data processing and consent to marketing emails into one checkbox. They’re different things with different consequences, and combining them is a common mistake. If you plan to send emails, ask separately — we covered why this matters practically in the piece on email marketing: a list built without explicit consent generates spam complaints and damages your sending domain.
One more thing: every field in a form is data you’re responsible for. A pointless “date of birth” field creates an obligation for nothing.
The typical site has Google Analytics installed, a Meta pixel, sometimes a few more scripts — and no mention of any of them in its documents.
This is the most widespread failure and simultaneously the easiest to fix. Three things are needed: list every service in the privacy policy, load them through a consent management system so they don’t fire before the click, and verify that declining actually disables them.
That last check is the most important and the most frequently skipped. Click “reject,” then look in developer tools to confirm the scripts genuinely didn’t load. In our experience they load anyway in roughly half of cases.
The side effect of doing this correctly is unwelcome, and it’s fairer to say so in advance: some visitors will decline, and your analytics will start showing smaller numbers. That isn’t a malfunction — it’s the real picture replacing a complete one.
A copied policy. The fastest way to end up with a document describing someone else’s business.
The document exists, the link doesn’t. The policy sits at a URL nothing points to. Formally present, functionally absent.
A banner with no actual blocking. Covered above — appearance instead of action.
Collecting data “for later.” More fields means more obligations. Collect what you genuinely need now.
Ignoring processors. If anyone else handles your data — hosting, CRM, an email service — that belongs in the policy.
The technical part is small: connect a consent management platform, configure script blocking until consent, add footer links and form checkboxes. That’s a few hours of developer work on a typical site.
The main expense is legal: drafting a policy for your specific business and your specific list of services. Cost there depends on complexity and on whether you need European compliance or domestic rules suffice.
The order we recommend at Netloria: first compile a complete list of what the site actually collects and where it sends it — without that list no lawyer can write a correct document. Then the documents. And only then the technical implementation of banner and forms.
Breaking that order is a familiar story: a ready-made banner gets bought first, the policy is commissioned afterwards, and it emerges that the banner blocks the wrong scripts while the policy describes the wrong services. Both need redoing.
If most of those aren’t in place, that’s a normal starting point for most sites, and it closes in a few days of work.
If you want the technical side built correctly from the outset — get in touch. We’re a web studio based in Ukraine, and we’d start with an audit of what your site actually collects. That list usually surprises the owner more than the documents do.
