GDPR for Websites and Online Stores: Personal Data, Cookies, and Technical Requirements

GDPR compliance for a website does not begin with downloading a ready-made policy or installing a cookie banner. It begins with a more practical question: what data actually passes through the website, why it is needed, who receives it, and when its processing begins.

A company website may send data from a contact form, load an analytics system, display a map, and transmit information to an advertising platform. An online store adds orders, payments, deliveries, customer accounts, and connections to warehouse or accounting systems. Each of these processes has its own purpose, participants, retention periods, and technical configuration.

The presence of a policy and a banner therefore does not prove that the website behaves as described. Advertising technologies may activate before the visitor makes a choice, a form may collect unnecessary fields, or the policy may fail to mention a provider that actually receives data.

This guide helps website owners identify such discrepancies and prepare clear requirements for a lawyer, developer, and external providers. It is not legal advice and cannot determine the correct legal basis or retention period for a specific business without an assessment of its actual processes.

How a Website or Online Store Processes Personal Data

Personal data is not limited to a name, telephone number, and email address. Depending on the context, it may include an IP address, device identifier, customer number, order history, delivery address, and information that allows a person to be identified directly or indirectly.

Processing does not mean only saving information in a database. It includes collecting, sending, viewing, using, storing, linking, deleting, and granting access. When an employee opens an enquiry, a courier receives an address, or an analytics platform records behaviour, personal data is already being processed.

For a website owner, the most useful approach is to trace the entire journey:

1. A visitor performs an action or opens a page.
2. The browser, form, or store collects information.
3. The data is stored or sent to another system.
4. An employee or provider gains access.
5. The information is used for a specific purpose.
6. After a defined period, it is deleted, anonymised, or retained because of another obligation.

The website is only the visible part. The actual system includes hosting, WordPress, forms, email, payment providers, couriers, accounting software, customer management systems, and marketing platforms. A GDPR review must cover this entire journey, not only the text in the footer.

Start With a Data Map, Not a Ready-Made Template

A ready-made policy may look professional and still be inaccurate. If it says that the website does not use advertising technologies while Facebook Pixel loads on every page, the text and reality do not match. The same applies when a policy lists tools that were removed long ago.

A data map turns a broad subject into questions that can be verified. For each function or tool, record what is collected, its purpose, the recipients, the point at which processing begins, the retention period, and the responsible parties.

The table should not be completed from assumptions. Check the actual code, network requests, extension settings, email recipients, and provider contracts. The name of a tool is not sufficient because the same service may behave differently depending on its configuration.

When Consent Is Required and When Another Legal Basis Applies

One of the most common mistakes is to explain every type of processing through consent. The GDPR provides several legal bases. Depending on the process, data may be necessary for performing a contract, complying with a legal obligation, pursuing a legitimate interest, or another applicable reason.

For example, data required to fulfil an order is not normally processed solely because a customer ticked an "I agree" box. The store needs a name, address, and contact details to complete the requested purchase. Some information may also need to be retained because of accounting or other legal obligations. The exact assessment, however, depends on the process and must be made by the controller with appropriate legal advice.

When processing genuinely relies on consent, the choice must be freely given, specific, informed, and unambiguous. There should be no pre-ticked boxes, hidden bundling with an unnecessary purpose, or negative consequence simply because a person refuses optional processing.

A practical rule is to separate the purposes first and then determine the legal basis for each:

• responding to an enquiry;
• fulfilling an order;
• creating a customer account;
• issuing and retaining accounting documents;
• sending a newsletter;
• measuring behaviour;
• personalised advertising;
• preventing abuse and maintaining technical security.

One general checkbox cannot reliably cover all these different purposes. It also makes withdrawal difficult because it is unclear what exactly should be stopped.

What the Privacy Policy Should Explain

The policy should reflect the real business and its actual technical configuration. It is not a decorative document and should neither include services the website does not use nor omit providers that actually receive data.

For every main process, a visitor should be able to understand:

• who the controller is and how to contact it;
• what categories of data are processed;
• the specific purposes for which they are used;
• the applicable legal basis;
• which recipients or categories of recipients have access;
• whether data is transferred outside the European Economic Area and on what basis;
• how long the data is retained or which criterion determines the period;
• what rights the person has and how to exercise them;
• how to withdraw consent when processing relies on it;
• whether providing the data is mandatory and what happens if it is refused;
• whether automated decision-making or profiling takes place, where applicable.

The text should be clear and accessible. Phrases such as "we may process any information to improve our services" do not provide sufficient predictability. It is more useful to name the specific purpose, data, and recipients.

The privacy policy and cookie information may be separate documents or parts of one system. What matters more is that visitors can find them easily and that their content corresponds to the website's actual behaviour.

What Cookies Are and Which Ones Do Not Require Consent

A cookie is a small record that a website or external service may store in the browser. However, the rules do not depend solely on whether a technology is called a cookie. Local storage, pixels, identifiers, and other mechanisms may also write or read information from the device and process personal data.

According to official European Union information, consent may not be required for technologies used solely to transmit a communication or for strictly necessary functions of an online service explicitly requested by the user. Examples may include a shopping cart, login authentication, or technical load balancing.

The exception must be applied according to the actual purpose. A cookie does not become strictly necessary simply because it has been placed in a "Necessary" category. If it is used for measurement, profiling, or advertising, its name and banner setting do not change its behaviour.

The review should be based on behaviour, not merely on a list of names. A useful inventory records the provider, purpose, category, retention period, domain, and activation condition.

When Analytics and Advertising Technologies Require a Prior Choice

Analytics and advertising tools often begin operating as soon as a page opens. If a visitor sees the banner after the code has already sent an identifier or event to an external platform, the choice has come too late.

Official European information identifies certain analytics, marketing, social media, and behavioural advertising technologies as examples that require prior consent. This means the website must control not only the creation of a visible cookie, but also the loading of scripts, pixels, and network requests.

Check at least the following states:

1. A new visit before any choice has been made.
2. Acceptance of selected categories only.
3. Rejection of all optional categories.
4. A change to a previously saved decision.
5. Expiry or renewal of the decision after providers change.

When consent is refused, advertising events should not be sent merely because the tool operates in a limited mode. Features such as consent management or consent mode may transmit signals and alter platform behaviour, but they do not replace the legal assessment or technical verification of actual requests.

If measurement is important to the business, the solution is not to force visitors to accept it. A better approach is to assess what data is genuinely necessary, whether a less intrusive configuration is available, and what analysis remains possible after a refusal.

How Consent Management Should Work

A properly functioning banner is not merely a message saying, "This website uses cookies." It must provide a real choice and technically control optional technologies.

A practical configuration includes:

• a clear explanation of the main purposes;
• separate categories where the purposes differ;
• visible actions for accepting, rejecting, and changing settings;
• no optional categories enabled in advance;
• equally understandable buttons without misleading colour, size, or wording;
• blocking before the choice;
• permanent access to change or withdraw the choice;
• a record of the text version and the choice made;
• requesting a new choice when purposes or providers change materially.

Rejection should not be hidden behind a long sequence of screens. The EDPB Cookie Banner Taskforce report discusses problems such as the lack of a genuine reject option, pre-ticked boxes, misleading visual design, incorrectly classified "necessary" cookies, and difficult withdrawal.

The consent record should be sufficient to demonstrate the choice without creating new unnecessary data collection. The time, selected categories, version of the information, and technical mechanism are normally relevant. The exact scope and retention period should be defined for the specific system.

Contact Forms, Newsletters, Bookings, and Registrations

Forms are easy to see but are often left outside the technical review. Fields, recipients, email copies, WordPress records, and connections to external systems should be described separately.

A contact form should collect only the data needed to respond. If a telephone number is not required in every case, it can be optional. A free-text field should include clear guidance not to submit sensitive or unnecessary data when it is not required.

An "I agree to the policy" checkbox does not automatically make processing lawful. The policy provides information, while the legal basis for responding to an enquiry may be different. Do not use one mandatory general consent as a substitute for an actual assessment.

For newsletters, separate marketing subscription from sending an enquiry, registering, or making a purchase. Unsubscribing should be easy, and the system should retain the necessary evidence of how and when the choice was made. If email confirmation is used, check what records the provider retains and for how long.

Bookings and registrations may require more data, but every field should have a specific function. Do not collect a date of birth, address, or other information merely because the extension template includes it.

When commissioning a business website, the technical specification should describe the forms, recipients, retention periods, external connections, and behaviour after withdrawal or deletion. The developer can implement the approved logic, but the owner must determine the business purposes and legal requirements.

External Content, Maps, Video, and Social Media

Embedded content looks like part of the website but is often loaded from an external domain. Even before a person plays a video or opens a map, the browser may send the IP address, device data, and the address of the visited page to the provider.

Review separately:

• video platforms;
• interactive maps;
• social media posts and buttons;
• external fonts;
• chat systems;
• antispam and form protection;
• payment fields loaded from an external domain;
• session recording or heatmap tools.

One possible technical implementation is to show a local placeholder initially and load the external content only after an appropriate choice. This must still be tested. A visibly blocked video is not sufficient if hidden code has already sent a request to the provider.

Consider the alternative as well. An address can be shown as plain text and a link, a video can use a local image, and critical information should not be available only through an external service that the visitor has refused.

What Is Different for an Online Store

An online store processes data not only during a visit but throughout the commercial process. An order passes through the cart, payment, delivery, notifications, accounting, customer service, and sometimes advertising or behavioural analysis.

This creates more points where data may be excessive, sent to the wrong recipient, or retained without a clear period. The following require particular attention:

• guest checkout and checkout with an account;
• automatic creation of a customer account;
• different billing and delivery addresses;
• invoice issuance;
• abandoned carts;
• reminders and marketing messages;
• product recommendations and profiling;
• returns, complaints, and customer service;
• synchronisation with warehouse, ERP, CRM, or accounting systems.

Do not make fulfilment of the order conditional on mandatory acceptance of personalised advertising or a newsletter. Necessary commercial data and optional marketing serve different purposes and should be managed separately.

For an ecommerce website development project, the technical implementation may include choice management, correct activation of integrations, and access restrictions. The legal assessment of purposes, legal bases, retention periods, and texts remains the merchant's responsibility with appropriate legal advice.

Orders, Payments, Couriers, and Customer Accounts

During checkout, every field should have a clear function. If the store does not require company details from every customer, they should not be mandatory. If an account is not necessary for the purchase, consider offering guest checkout.

The payment provider may receive data directly through its own field or after a redirect. Check what information remains in the store, what is sent to the provider, and whether sensitive payment data is retained unnecessarily. The website itself should not store more card information than is necessary for the selected payment model.

The courier should receive the data needed for the specific delivery. Test the integration during automatic shipment creation as well as during corrections, cancellations, and returns. Archives, labels, and emails may also contain personal data.

A customer account creates ongoing access to history, addresses, and settings. It therefore requires:

• secure password management;
• login attempt limits and protection proportionate to the risk;
• appropriate roles and administrative access;
• the ability to correct data;
• a functioning process for deletion or restriction requests;
• a clear distinction between data that can be deleted and data that must be retained because of an obligation or legal claim.

Deleting an account does not always mean immediately deleting every related record. Orders or accounting documents may have to remain. The system should follow approved logic rather than promise an action that is technically impossible or legally incorrect.

External Providers, Access, and Data Transfers

Hosting, the email platform, courier, payment provider, and advertising system are not simply "tools". Each has a role in relation to the data. Some providers process it on the owner's instructions, others determine their own purposes, and in some cases responsibility may be shared.

For each provider, check:

• the legal entity and contracted service;
• what data it receives;
• the purposes for which it uses the data;
• its role in the specific processing;
• whether there are contractual processing clauses;
• where the data and subprocessors are located;
• whether data is transferred outside the European Economic Area;
• how data is deleted or returned on termination;
• how incidents and changes are reported;
• what administrative and technical access it has.

Do not assume that a provider is "in Europe" merely because it has a European website or invoice. Check the specific service, storage regions, subprocessors, and international transfer mechanisms.

Restrict access according to role. A marketing team should not automatically have access to every order, and an external developer should not keep a permanent administrator account after completing the task. Temporary access should be revoked, and actions in critical systems should be traceable.

Retention Periods, Rights, and Security

The default retention period should not be "indefinite". For every process, define a specific period or criterion: until the enquiry is completed, while the account remains active, until unsubscribing, for the duration of a contractual or accounting obligation, or while needed to defend a legal claim.

The same information may be used in different processes. An email address from an order may be needed for fulfilment, accounting, and support, but this does not mean it can automatically be used indefinitely for advertising. The period and purpose are determined separately.

The website should have a functioning process for requests concerning:

• access to data;
• correction;
• erasure;
• restriction of processing;
• objection;
• portability, where applicable;
• withdrawal of consent.

Not every right applies in the same way in every situation. A request for erasure, for example, may not affect information the business is legally required to retain. A technical button should therefore follow an approved process rather than indiscriminately delete related records.

Security should be proportionate to the risk. A practical foundation includes up-to-date software, strong and unique passwords, multi-factor protection for critical accounts, restricted permissions, protected backups, encrypted connections, monitoring for unusual activity, and an incident response plan. This does not cover the whole field of cybersecurity, but it reduces common technical weaknesses.

Who Bears the Legal and Technical Responsibility

The business owner usually determines why and how data is processed and is responsible for being able to demonstrate those decisions. A lawyer helps assess the legal bases, texts, retention periods, contracts, and specific risks. The developer implements the technical requirements and verifies that the system behaves according to the specification.

This division does not release anyone from their own obligations. If the developer has access to real customer data, their role, instructions, and access should be regulated. If the owner changes a marketing tool after the website has been handed over, the original technical review is no longer sufficient.

The most reliable model gives every requirement an owner, approved text, a technical task, and an acceptance test. This replaces the phrase "make the website GDPR compliant" with verifiable outcomes.

Why a Banner or Extension Does Not Guarantee Compliance

An extension may manage categories, block code, and store the visitor's choice. It cannot decide by itself why the business processes data, which legal basis is correct, how long records should be retained, or whether the contract with the provider is sufficient.

The most common discrepancies after installing a banner are:

• scripts load before the choice;
• some code is added outside the management system;
• a technology is placed in the wrong category;
• the reject button is missing or difficult to find;
• withdrawal does not stop future processing;
• the policy lists different tools from those actually used;
• a new extension is added without another review;
• the banner is translated, but its links or categories are not updated;
• the recorded choice does not correspond to the version shown.

An automated scanner is not definitive evidence either. It may miss a technology that activates only after a specific action, login, purchase, or visit to a particular page. It may also classify a tool incorrectly based only on its name.

Compliance is an ongoing process: documentation, legal assessment, technical implementation, testing, monitoring, and updating when something changes.

Practical Checklist Before Launching or Changing the Website

Use this checklist for a new website, a new online store, a change of analytics or advertising platform, a new form, a new payment method, or a significant content change.

Data and Purposes

• All forms, accounts, orders, tools, and external services have been documented.
• The data collected and its purpose are clear for every process.
• Fields and records without a genuine need have been removed.
• Recipients and internal access permissions have been defined.
• A retention period or clear retention criterion has been defined.

Legal Assessment and Information

• The applicable legal basis has been determined for every purpose.
• Consent is used only when appropriate and can genuinely be refused.
• The privacy policy reflects the technologies and providers actually used.
• Cookie information describes the purpose, provider, duration, and activation condition.
• Rights and the channel for submitting a request are clearly stated.
• International transfers and provider contracts have been reviewed.

Technical Implementation

• Optional technologies are blocked before the required choice.
• After a refusal, no advertising or analytics events that should be stopped are transmitted.
• Categories are not enabled in advance.
• Acceptance, rejection, and settings are clear and accessible.
• Withdrawal is easy and stops future activation.
• External video, maps, chat, and social media elements have been checked for prior requests.
• Forms send data only to approved recipients.
• Administrative roles and temporary access are restricted.
• Backups, logs, and email copies are included in the assessment.

Testing and Maintenance

• A new visit before any choice has been tested.
• Acceptance of one category only has been tested.
• A complete refusal has been tested.
• Changing and withdrawing a choice have been tested.
• Actual network requests, not only visible cookies, have been checked.
• A person has been assigned to monitor new extensions, code, and providers.
• A date has been set for a periodic review.

When information about a purpose, legal basis, retention period, or provider is missing, technical work should stop at that point. The developer should not fill in legal decisions by assumption, and the owner should not treat an installed extension as a completed GDPR review.

SeoWebDesign can implement and test technically approved requirements when developing a website or online store. The legal texts and assessment for the specific business should be supplied or reviewed by an appropriate legal professional.

Official Sources

• EUR-Lex - General Data Protection Regulation
• Your Europe - Data protection under GDPR
• Your Europe - Cookies and online privacy
• EUR-Lex - Directive 2002/58/EC on privacy and electronic communications
• EDPB - Guidelines 05/2020 on consent
• EDPB - Cookie Banner Taskforce report
• EDPB - Data protection by design and by default
• CPDP - Quick guide to GDPR compliance
• CPDP - Specific guidance for different sectors