A GDPR compliant website comes down to a few questions you need to be able to answer in writing: what data you collect and why, on what legal basis, who you share it with, how long you keep it, and whether you have the visitor's consent before storing anything in their browser where the law requires it. A mandatory checkbox under a form and a banner with a single "I accept" button answer none of these questions.
Below we go through a company website and an online store element by element, with the provision the obligation comes from and how to implement it in code.
- A contact form usually does not need consent: the basis is responding to an enquiry (Article 6(1)(b) or (f) GDPR). It does, however, need the Article 13 GDPR information at the moment data is collected.
- Marketing emails require prior consent under Article 398 of Poland's Electronic Communications Law. The consent box must not be pre-ticked or combined with accepting the terms of service.
- Storing and reading information in the browser that is not necessary for the site to work requires consent before the script runs (Article 399 of the Electronic Communications Law). Refusing must be as easy as accepting.
- Every provider that processes data on your behalf, from hosting to a contractor with database access, needs a data processing agreement under Article 28 GDPR.
- The privacy policy has to describe the tools that actually run on the site. Every new script is a change to the policy.
Legal status as of 26 September 2026. This article describes the regulations from the perspective of a company that builds websites and online stores, and it is not legal advice. The legal bases for processing and the content of the privacy policy are determined by the data controller, ideally with a lawyer or a data protection officer. The contractor's job is to make sure the site works exactly as the policy describes.
Which laws apply to a company website
The foundation is the GDPR, Regulation (EU) 2016/679, which has applied directly in all EU countries since 25 May 2018. In Poland, the Personal Data Protection Act of 10 May 2018 supplements it with, among other things, provisions on the supervisory authority, which is the President of UODO, Poland's Personal Data Protection Office.
The second law is the Electronic Communications Law (Prawo komunikacji elektronicznej, PKE) of 12 July 2024, in force since 10 November 2024. Three of its provisions matter for a website: Article 399 on storing information on a user's device, which covers cookies among other things, Article 398 on consent to commercial communications sent, for example, by email, and Article 400, which requires the data protection rules to be applied to those consents. The earlier ban in Article 10 of the Act on Providing Services by Electronic Means was repealed on the same day.
Who is responsible for what
| Area | Provision | Authority |
|---|---|---|
| Processing personal data from forms, accounts, orders and analytics | GDPR, Personal Data Protection Act | President of UODO |
| Cookies and other storing or reading of information in the browser | Article 399 PKE | President of UKE |
| Emails and text messages with commercial content | Article 398 PKE | President of UKE |
For breaching Articles 398 and 399 PKE, the President of UKE, Poland's Office of Electronic Communications, can impose a fine of up to 3% of the previous year's revenue (Articles 444 and 446 PKE). Personal data collected through cookies and scripts is still subject to the GDPR, so a single mistake in a banner can concern both authorities.
Who is who: controller, processor, joint controller
The company that owns the website is the data controller: it decides why and how data is processed. The obligations described below come from that role, regardless of who built the site.
A processor is anyone who processes data on the controller's behalf: the hosting company, the email provider, the newsletter system, the CRM, the ticketing tool, and also the contractor who has access to the production database during maintenance or a migration. Each of them needs a data processing agreement under Article 28 GDPR.
The third role sometimes comes as a surprise. In its Fashion ID judgment of 29 July 2019 (C-40/17), the CJEU held that the operator of a website with an embedded Facebook "Like" button can be a joint controller together with Facebook for the collection and transmission of visitors' data. Every embedded element that sends data to an outside company therefore needs to be assessed.
A contact form without a mandatory checkbox
A common pattern is a form with an "I consent to the processing of my personal data" box that cannot be skipped. It looks safe, but it rests on the wrong legal basis.
A person asking about your services is asking for a reply. The basis for processing is then taking steps at their request before entering into a contract (Article 6(1)(b) GDPR), and for general correspondence the controller's legitimate interest (Article 6(1)(f)). Consent that is a condition of submitting the form can hardly be considered freely given (Article 7(4)), and on top of that it can be withdrawn at any time (Article 7(3)). A company that relied on consent should stop processing the data once it is withdrawn, even if it is in the middle of preparing a quote.
What the form does need is the Article 13 GDPR information at the moment the data is collected. The full list is long, so in practice there are two layers: a short notice right next to the submit button and a link to the privacy policy with the rest. An example first layer:
Example notice under a form
The data controller is [company name, address, email]. We process the data from this form to reply to your enquiry and prepare a quote (Article 6(1)(b) GDPR). Information on how long we keep the data, who receives it and your rights can be found in our [privacy policy].
The data minimisation principle (Article 5(1)(c)) also applies to forms. If you reply by email, the phone number does not need to be mandatory. If the quote does not depend on the company name, that field is unnecessary. Every field that is not there is data you do not have to protect, describe or delete.
A submission ends up in a mailbox, and sometimes in a CRM, server logs or a third-party form service. Each of these places should have a defined retention period (Article 5(1)(e)), and each run by an outside company needs a data processing agreement. Third-party spam protection that loads the provider's script and stores data in the browser also has to be assessed against Article 399 PKE and described in the policy. A hidden honeypot field and a server-side submission limit do not require sending data to anyone.
Newsletters and marketing emails: separate consent
Sending commercial information by email or text message requires the recipient's prior consent (Article 398(1) PKE). Consent can be given by providing an email address for the purpose of receiving commercial information (Article 398(2)), which is what a typical newsletter sign-up is. Processing the address itself also needs a GDPR basis: consent or legitimate interest, because according to Recital 47 GDPR direct marketing may be regarded as carried out for a legitimate interest.
Consent must meet the GDPR conditions, which Article 400 PKE refers to. In practice this means several requirements for the form:
- The box is not pre-ticked. Recital 32 GDPR states plainly that silence, pre-ticked boxes or inactivity do not constitute consent.
- Separate from other declarations. The request for consent must be clearly distinguishable from other matters (Article 7(2)). A single "I accept the terms of service and want to receive the newsletter" box combines two different things.
- No making the service conditional on it. An order in a store cannot require consent to marketing that is not needed to fulfil the order (Article 7(4)).
- Withdrawing is as easy as giving. An unsubscribe link in every message, and that link actually working (Article 7(3)). A person who objects to direct marketing must no longer receive such messages (Article 21(3)).
- Proof. The controller must be able to demonstrate that consent was given (Article 7(1)).
The last point is a job for the code. A consent log should record who consented, when, to what and with which version of the form, and when they withdrew consent:
Confirming a sign-up through a link sent to the address provided (double opt-in) is not required by law, but it makes it easier to show that the address was given by its owner.
Cookies and the consent banner under Article 399 PKE
Article 399 PKE allows information to be stored on a user's device, or accessed there, only if the user has first been clearly informed of the purpose and has given consent. The provision talks about information in general, so it covers not only cookies but also, for example, localStorage. Consent is not needed when storage is necessary to transmit a communication or to provide a service the user has requested (Article 399(3)).
Categories of browser storage
| Example | Does it require consent |
|---|---|
| Logged-in user session, cart contents, form security token | No, if it serves the service the user is asking for |
| Visit statistics with an identifier in a cookie | Yes |
| Advertising pixel, remarketing, campaign conversion tracking | Yes |
| Embedded video or map that sets its own cookies | Yes; loading only after a click moves that moment, but does not remove the need for an assessment |
| Chat that stores a visitor identifier from the moment they arrive | Depends on the configuration and the purpose of the storage |
How a banner should look is shown in documents from the European data protection authorities. EDPB Guidelines 05/2020 on consent state that scrolling a page is not consent, and that making access to content conditional on accepting cookies (a so-called cookie wall) means consent is not freely given. The report of the EDPB cookie banner taskforce from January 2023 discusses practices raised in complaints: no reject option on the layer with the accept button, pre-ticked boxes, highlighting the accept button with colour and contrast, cookies wrongly labelled as "essential" and no easy way to withdraw consent. The vast majority of authorities considered the lack of a reject option a breach, and colours and contrast are to be assessed on whether they mislead.
In the Planet49 judgment of 1 October 2019 (C-673/17), the CJEU ruled that a pre-ticked box does not constitute consent to cookies, and that users should know how long cookies will remain active and whether third parties have access to them.
The most important part is what you cannot see in the banner: scripts that require consent must not run before the user decides. A banner sitting on top of analytics that is already running is decoration. In code, this means such scripts are added to the page only after consent:
showBanner is the banner component with three equally weighted actions: accept, reject and choose categories. The version in the key lets you ask again after the list of tools changes. You also need a permanent "Cookie settings" link in the footer, because withdrawing consent must be as easy as giving it. With an off-the-shelf consent management platform, check in the developer tools that no non-essential cookies are set and no requests go out to analytics providers before the click.
The banner is also an interface element like any other. If it slides in above the content, it shifts the page layout and hurts the CLS metric, as we describe in Core Web Vitals in practice. If it sticks to the bottom of the screen, it must not hide the element with keyboard focus, and its buttons must work without a mouse, which is a WCAG 2.2 requirement covered in our article on digital accessibility for websites and online stores.
Analytics: Google Analytics, Consent Mode and transfers to the US
Cookie-based analytics requires consent under Article 399 PKE, whoever the provider is.
Google offers Consent Mode in two variants, described in Google's documentation. In the basic variant, Google tags are blocked until the user makes a choice in the banner and send no data before that. In the advanced variant, tags load immediately with a "denied" setting and, until consent is given, send cookieless pings to Google that are used to model the missing data. The advanced variant is worth discussing with whoever is responsible for data protection, because data reaches the provider before the user decides.
The second issue is transferring data to the US. Under Commission Implementing Decision (EU) 2023/1795 of 10 July 2023, data can go to US companies that have joined the EU-US Data Privacy Framework programme. On 3 September 2025 the General Court dismissed an action against that decision (T-553/23, Latombe v Commission), and on 31 October 2025 the applicant lodged an appeal with the Court of Justice (C-703/25 P). At the time of publication the decision is in force. You can check whether a given provider is certified on the list of programme participants.
The alternative is analytics running on your own server in the EU, or analysing server logs. That solves the transfer problem but does not take you out of the GDPR: in the Breyer case (C-582/14), the CJEU held that a dynamic IP address can be personal data for a website operator. A cookieless tool still processes personal data, so it needs a basis under Article 6 GDPR and a description in the privacy policy. Whether it also needs consent under Article 399 PKE depends on how it works technically. In its Guidelines 2/2023 of October 2024, the EDPB takes the view that the EU provision that Article 399 PKE implements in Poland can also cover tracking through pixels, through URLs and based on the IP address alone. So it is best to leave the assessment of a specific tool to a lawyer.
Third-party elements: fonts, maps, video, chat and pixels
Every element loaded from someone else's server, whether a font, a map, a video player, a chat widget, a reviews script or an advertising pixel, sends at least the visitor's IP address to its provider when the page loads. Some of them also set cookies. Sometimes even the site owner who pasted the code from the provider's panel does not know this.
The technical solutions are simple and make the site faster as a side effect:
- Fonts hosted on your own domain instead of being downloaded from an external server on every visit.
- Video and maps as a facade: a static image from your own server with a button that loads the player or map only after a click.
- Chat loaded on demand, after clicking the icon, not on every page visit.
- Advertising pixels only after consent to the marketing category, never hard-coded into the page template.
Before launch, open the site in a private window, switch on the network tab in the developer tools and write down the domains the page sends requests to before any interaction. That list is the starting point for the privacy policy and the agreements with providers.
A privacy policy that describes your website
The privacy policy fulfils the Article 13 GDPR information obligation for every place where the site collects data, in a concise and intelligible form, using clear and plain language (Article 12(1)). The obligation does not depend on the size of the company.
What a privacy policy must contain
| Element from Article 13 GDPR | What it looks like on the website |
|---|---|
| Controller and contact details, and the data protection officer if there is one | Full company name, address, email for personal data matters |
| Purposes and legal bases | Separately for the form, accounts, orders, newsletter, analytics, marketing |
| Legitimate interests | Which ones, if the basis is Article 6(1)(f) |
| Recipients of the data | Hosting, email, newsletter system, payment gateway, courier company, accounting |
| Transfers outside the EEA | To which country and on what basis, for example a Commission decision |
| Retention period | A specific period, or the criteria for determining it, for each purpose |
| Data subject rights | Access, rectification, erasure, restriction, portability, objection, withdrawal of consent, complaint to the President of UODO |
| Whether providing data is voluntary | Which fields are required and what happens if you do not fill them in |
| Profiling | Whether it is used and with what effect |
It happens that a template policy describes tools the site does not have and leaves out the ones it does. It is better to build it from the list of actual scripts and providers from the previous step, with a section on cookies (tool, category, purpose, duration) and the date of the last change. A new pixel, chat or newsletter system is a change to the policy, not just to the code.
Data processing agreements: a list of providers to check
Article 28 GDPR allows you to use only processors that provide sufficient guarantees, and requires a contract setting out the subject matter, duration, nature and purpose of the processing, the type of data and the categories of data subjects. Among other things, the contract obliges the provider to act only on the controller's documented instructions, to ensure its staff keep the data confidential, to apply the security measures under Article 32, to help handle data subject requests and breaches, to delete or return the data when the cooperation ends, and to allow audits.
A typical list for a company website and an online store:
stores the database, files and logs.
stores form submissions and correspondence.
the address list, the history of opens and clicks.
customer data and contact history.
depending on the configuration, a processor or a separate controller, which you need to check in the provider's terms.
a database backup is the same personal data.
if it has access to the production database during maintenance, a migration or bug fixing.
Large providers often make the data processing agreement available as part of their terms or for acceptance in the panel. Keep a copy and check the list of sub-processors, because under Article 28(2) the provider may only use them with the controller's authorisation. We wrote about what to check in a contract with a software contractor in How to choose a software house.
Security, breaches and user rights
Article 32 GDPR requires security appropriate to the risk and lists, among other things, encryption, the ability to ensure the confidentiality, integrity, availability and resilience of systems, the ability to restore data quickly after an incident, and regular testing of security measures. On a website this means, among other things, HTTPS, up-to-date dependencies, separate panel accounts with permissions matched to the role, two-factor login for administrators and backups with tested restores. We described how to organise this after launch in our article on monitoring and maintenance after launch.
If a personal data breach occurs, for example a leak of a store's customer database, the controller reports it to the President of UODO without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to people (Article 33). Where the risk is high, the data subjects must also be notified (Article 34). A processor, for example the hosting provider, reports the breach to the controller without undue delay. It is worth having a procedure with contacts ready in advance, because the 72 hours also run over the weekend.
The people whose data you process have the right of access, rectification, erasure, restriction of processing, data portability and objection. A request must be answered within one month, which can be extended by two months in complex cases (Article 12(3)). In a store or a panel with user accounts, it is worth having this in the code: exporting a customer's data, and deleting or anonymising an account while keeping the documents that must be retained under other laws. Manually searching for a customer across several tables easily ends with some of the data being missed.
Article 30 GDPR requires a record of processing activities. Companies with fewer than 250 employees are exempt, but only if the processing is occasional, does not pose a risk and does not include special categories of data. A form and a store operate every day, so they can hardly be considered occasional processing. In 2026 the EU institutions were working on extending this exemption to larger companies, so check the current wording of Article 30(5) before you assess it. Even when it is not mandatory, a record is the simplest way to know what the site does with data.
Typical mistakes on company websites and online stores
Mistakes and fixes
| Mistake | Why it is a problem | Fix |
|---|---|---|
| Mandatory consent under a contact form | The consent is not freely given, and the basis is responding to the enquiry anyway | Remove the box, add the Article 13 information |
| Marketing consent pre-ticked | Recital 32 GDPR and the Planet49 judgment | An empty box the user ticks |
| Analytics running before the choice in the banner | Article 399 PKE requires consent before storage | Load scripts only after consent |
| Banner with no reject button | Refusing must be as accessible as accepting | A "Reject" button next to "Accept" |
| No way to change the decision | Article 7(3) GDPR | A "Cookie settings" link in the footer |
| Template policy that does not match the site | The Article 13 information is untrue | A policy built from the list of actual tools |
| No agreement with the hosting provider or newsletter system | Article 28 GDPR | A list of providers and accepted agreements |
| Form submissions kept in the mailbox forever | The storage limitation principle | A defined period and regular deletion |
| Fonts, maps and video from external servers with no information | The IP address reaches the provider when the page loads | Local hosting or loading on click |
Fines and liability
The President of UODO can impose an administrative fine of up to EUR 10 million or 2% of total worldwide annual turnover for breaching the obligations of the controller and the processor, and up to EUR 20 million or 4% of turnover for breaching the basic principles of processing, including the conditions for consent, and data subjects' rights. In both cases, whichever amount is higher applies (Article 83 GDPR). Separately from fines, anyone who has suffered material or non-material damage as a result of a breach can claim compensation from the controller or the processor (Article 82). For breaches of Articles 398 and 399 PKE, the President of UKE imposes a fine of up to 3% of revenue.
What may change
On 19 November 2025 the European Commission presented a package of changes to digital legislation (the so-called Digital Omnibus). Among other things, it includes changes to the GDPR and to the rules on cookies intended to reduce the number of banners, allow consent to be given with a single click and allow preferences to be saved in browser settings. At the time of publication this is a proposal going through the legislative procedure of the European Parliament and the Council, so the rules described above apply.
Frequently asked questions
Does a contact form require consent to data processing?
Usually not. When someone asks about your services, the basis is taking steps at their request before entering into a contract (Article 6(1)(b) GDPR), and for general correspondence it is legitimate interest. The form does need the Article 13 GDPR information, ideally a short version next to the submit button and the full version in the privacy policy.
Does a site without Google Analytics need a cookie banner?
If the site stores in the browser only information necessary for the service the user is asking for, for example a login session or a cart, consent under Article 399 PKE is not required. Do check, though, whether embedded maps, videos, chat or spam protection set cookies.
Is a banner with an "I accept" button enough?
No. Consent must be freely given, so the user should be able to refuse as easily as they can agree. According to the 2023 EDPB report, the vast majority of European data protection authorities considered a banner that offers no reject option on any layer with an accept button to be a breach. Scripts that require consent must also not run before the user decides.
Can Google Analytics be used in line with the GDPR?
At the time of publication, yes, provided there is cookie consent before the script runs, a description in the privacy policy, and the transfer to the US is based on the Commission decision on the Data Privacy Framework. The judgment upholding that decision has been appealed to the Court of Justice of the EU.
Who is responsible for GDPR on a website built by a contractor?
The company that owns the website, as the data controller. The contractor is responsible for making the site work according to what was agreed in the contract, and if it has access to personal data, it is a processor and needs a data processing agreement.
A GDPR compliant website starts in the project scope
GDPR compliance is easiest when the data requirements are part of the project scope: the list of scripts and providers, blocking them until consent, retention periods, and functions for exporting and deleting data in the panel. The content of the policy and the legal bases are determined by the data controller with a lawyer. The contractor's job is to make the code do exactly what the policy promises.
If you are planning a website or an online store and want to go through these points before the quote, get in touch through the contact form. You will find the types of projects we deliver on the offer page, and how we work on the process page. After handover you get full rights to the code and documentation.
