Key Takeaways
- The GDPR applies almost always: as soon as a website processes an IP address, a contact form, a newsletter, or an embedded tracking script, the regulation applies in full.
- Six duties are non-negotiable: transparency, consent, rights of access and erasure, data security, data processing agreements, and a clean third-country transfer form the backbone of every legally compliant site.
- Cookies need active consent: since the CJEU ruling Planet49 (1 October 2019), pre-checked boxes are not consent. Scripts may only load after an opt-in.
- Fines are serious: the framework under Art. 83 GDPR reaches up to EUR 20 million or 4 % of group turnover. The GDPR Enforcement Tracker records 2,685 cases through March 2026 with a total of roughly EUR 6.11 billion.
- The website check is mandatory work: legal texts, cookie logic, third-party services, encryption, and data flows must be reviewed as one system. That is precisely where most sites fail in practice.
What does the GDPR actually require from websites?
The GDPR requires every website to process personal data only on a clear legal basis, to disclose every processing operation in understandable terms, and to secure the data technically. In practice, that means a complete privacy policy, active cookie consent before any third-party script loads, documented consents, accessible data subject rights, TLS-encrypted transmission, and a data processing agreement with every external service.
If you run websites professionally, you should not read the regulation as an obstacle but as a duty list. It defines six pillars against which any audit measures a site. If one pillar is off, you face a warning notice at best and a fine under Art. 83 GDPR of up to EUR 20 million or 4 % of worldwide group turnover at worst. In Germany the authorities are active: the Hamburg Data Protection Commissioner alone recorded over 2,600 complaints and 955 reported data breaches in 2024. If you work in the SME segment and assume this does not concern you, you overlook that, according to the same report, every fourth complaint in Hamburg related directly to website topics.
What counts as "personal data" and when does the GDPR apply?
Classic identifiers on a website
Personal data is any information that makes a natural person identifiable: name, email, phone number, IP address, cookie IDs, location data, click behaviour in analytics tools. The GDPR applies as soon as even one of these is collected. A pure business-card page without a form, without tracking, without external fonts would in theory sit outside the scope, but in practice you can hardly find such pages any more.
Particularly sensitive are the "special categories of personal data" listed in Art. 9 GDPR: health data, religious or political beliefs, sexual orientation, biometric data. As soon as a website collects such information (for example through a job application form noting disability status, a medical history form, or a registration form in sports or care services), stricter requirements apply, including explicit and separate consent.
Hidden third-country transfers via standard tools
As soon as a website loads Google Fonts from the third-party CDN, embeds a YouTube video, sends a newsletter via Mailchimp, or integrates a chatbot, it processes personal data into third countries. At the latest here, the duty to document and secure data flows applies. If you use third-country transfers to the United States, since the CJEU ruling Schrems II of 16 July 2020 you must additionally check whether the specific transfer offers an equivalent level of protection, and where necessary deploy Standard Contractual Clauses plus a Transfer Impact Assessment.
The most common misconception in the SME segment goes: "We do not process any US data at all." But as soon as an embedded YouTube preview, a Google font from the Google CDN, or a classic Mailchimp form is embedded on the page, IP addresses and browser fingerprints already flow to the United States before consent. These data transfers run invisibly, yet they are regulated exactly like a deliberate data export.
Which six duties must a GDPR-compliant website fulfil?
Six duty areas form the backbone of every legally compliant site. If even one of them has open flanks, the overall system is not compliant.
Transparency and the privacy policy
The privacy policy must be reachable from every page in two clicks, name every service in use, state retention periods, and list all data subject rights. Generic templates that do not match the tools actually embedded are, in most audits, the most frequent defect. The document becomes a legal paper tiger with no connection to the actual data processing. A good privacy policy reads like an inventory list of data flows, not like a boilerplate text.
Legal basis and consent
Every data processing operation needs one of the six legal bases from Art. 6 GDPR. For marketing cookies, analytics, tracking, and third-party scripts it is almost always explicit consent. Consent must be given freely, informed, and actively. Silence, pre-checked boxes, and "continued scrolling means consent" have been ruled out explicitly since the CJEU ruling Planet49.
Rights of access, erasure, and objection
Under Art. 15 to 22 GDPR users can view, correct, and delete their data and object to processing. An accessible contact point and a documented process are mandatory, not optional. In practice a clear email address backed by an actual workflow is enough. Requests must be answered within one month. If you ignore requests or stall them, in our experience you risk a complaint at the competent supervisory authority, which almost always leads to a formal hearing.
Data security at the current state of the art
Art. 32 GDPR requires technical and organisational measures at the current state of the art. That includes TLS encryption, regular updates for all CMS and plugin components, patch management for third-party dependencies, and a documented backup procedure. Where data security ends, the attack surfaces described in our article on the biggest security gaps on websites begin.
A data processing agreement with every service provider
You need a Data Processing Agreement (DPA) under Art. 28 GDPR with every external provider that processes personal data, meaning hosters, mail services, analytics vendors, and cloud storage. Without a DPA the processing is unlawful from the outset. Most reputable providers make DPAs available as a PDF download or let you sign them electronically through account settings. Which contracts you hold belongs in a simple register that can, if needed, be evidenced to the supervisory authority within minutes.
Securing third-country transfers correctly
Data flows outside the EEA are permitted only if an adequacy decision exists (currently, for example, the EU-US Data Privacy Framework since 2023) or Standard Contractual Clauses plus a transfer assessment apply. US tools without a clean legal basis are one of the most common causes of fines against European SMEs. If you can replace a classic US service (newsletter tool, analytics, or form provider, for instance), you gain legal certainty and significantly reduce the ongoing documentation burden.
When do cookies need active consent?
As soon as a cookie or a comparable tracking method is not strictly technically necessary, it requires the user's active consent before being triggered. The CJEU clarified this in its ruling Planet49 (Case C-673/17, 1 October 2019): pre-checked boxes do not constitute valid consent. The German Federal Court of Justice immediately followed suit with BGH I ZR 7/16, and in Germany Section 25 TDDDG (formerly TTDSG) translates the standard into national law.
Four requirements for a legally sound cookie banner
Concretely, that means four requirements for the cookie banner. First, no cookies or external scripts before consent, neither Google Analytics, nor Meta Pixel, nor embedded YouTube videos. Second, equivalent "Reject" and "Accept" buttons on the first layer, without dark patterns. Third, granular selection by category. Fourth, an always-reachable option to withdraw consent. Our guide to the cookie banner requirement describes in detail how these requirements are implemented in practice.
Supervisory authorities now read source code with tools that audit cookie banners automatically. Anyone loading an embedded script before consent stands out immediately. The typical SME reflex "but everyone does it that way" does not help in proceedings. What matters alone is whether the cookie logic evaluates consent in a blocking way or only displays it cosmetically.
How high are the fines for GDPR violations?
The statutory framework under Art. 83 GDPR
The fine framework under Art. 83 GDPR reaches up to EUR 20 million or 4 % of worldwide annual group turnover, whichever is higher. For lighter violations half the framework applies: EUR 10 million or 2 % of turnover.
What supervisory authorities actually impose
How seriously supervisory authorities take this is shown by the GDPR Enforcement Tracker Report 2026 from law firm CMS: 2,685 documented fines totalling around EUR 6.11 billion, plus 440 new cases compared with the previous report. The highest single fine sits at EUR 1.2 billion against Meta Platforms Ireland (May 2023) for unlawful third-country transfers to the United States.
For small and medium-sized websites, fines rarely reach this order, but EUR 50,000 to EUR 500,000 are realistic figures in the lower SME range and often hit cookie banner defects, faulty privacy policies, or insufficient encryption. On top of that come warning costs and reputational damage. As the Bitkom Data Protection Report 2024 shows on the basis of 605 surveyed companies, 94 % of companies rate the GDPR effort as high, for 63 % it grew further year on year, and 84 % regard their implementation as never fully complete. The compliance curve is not flattening. It is getting steeper.
Which GDPR mistakes do I see most often in audits?
In audits I have run with the Evelan team on SME websites between 2020 and 2026, four error classes recur so consistently that I now recognise them blind. The industry plays a surprisingly small role; whether trades, consulting, healthcare, or software, the patterns stay the same.
Cookie banner theatre
The first class is the cookie banner that is purely theatre. Visually correct, technically useless: Google Analytics, Meta Pixel, and YouTube iframes load before the user makes a choice. I see this on every second audited site. The fix is non-trivial because it touches the order of script injection, but it is unavoidable. Anyone who examines the issue in detail usually finds not one but three or four scripts firing in parallel and jointly building a complete tracking profile long before the banner has even been closed.
Outdated privacy policies
The second class is the privacy policy that does not match the technology in use. Generators produce 30 pages of text, but the CMS has integrated new services for three years without anyone maintaining the document. HubSpot, Calendly, a new chatbot, an embedded review platform, none of it appears in the document. Under Art. 13 GDPR that is a transparency defect. If you treat the policy as a living document and touch it exactly once on every tool introduction, you defuse the problem permanently.
Unintended third-country transfers
The third class is the unintended third-country transfer. Google Fonts from the CDN, an embedded Vimeo video, a US newsletter tool without a clean legal basis. Since Schrems II this is one of the most expensive mistakes overall because it triggers data transfers without protective guarantees. Often these services were embedded years ago by a previous agency, nothing was documented, and after staff turnover no one knows any more which token in which plugin sends data where.
Security gaps under the compliance cosmetics
The fourth class is the security gap below the GDPR cosmetics. Outdated WordPress versions, unpatched plugins, missing TLS on subdomains. Data security under Art. 32 GDPR is not breached only once an attack has succeeded; it is breached as soon as the measures are no longer "at the state of the art". If you want a second opinion here, the article on a legally compliant website offers a systematic checklist. A clean privacy policy does not protect against an underestimated backend, and a fine procedure following a data leak does not care whether the cookie logic in the frontend was formally correct.
How does a GDPR website check make your site compliant?
A GDPR website check combines three layers that are often treated in isolation in regular audits: legal documents, technical cookie and script logic, and data flows to third parties. Only the combination of these three perspectives shows whether the site is actually compliant.
A professional GDPR website check examines, among other things:
- the use of cookies and tracking tools
- GDPR compliance of the privacy policy
- external services and third-party providers
- form functions and data storage
- security measures such as SSL and server configuration
This gives a realistic picture of how well website data protection is actually implemented in practice.
How an Evelan check runs in practice
In a typical Evelan check we open the site in a fresh browser session without an ad blocker, log every network request before and after consent with the browser dev tools, compare the result with the privacy policy, and map every third-party service onto an existing or missing DPA. If a script fires without consent or a service is missing from the policy text, that is audit entry number one. From this we derive an action plan that prioritises legal, technical, and organisational gaps so you do not have to solve everything at once, but risks first.
In parallel we check the state of encryption, the currency of the CMS and plugins, and the backup and recovery routine. That turns a pure document audit into a technical check that also evaluates data security under Art. 32 GDPR. The written report contains for each gap a risk assessment, a concrete implementation path, and a time estimate. That way management decides with numbers, not gut feeling.
From Evelan's Practice
A north German financial advisory firm, which counsels its clients on wealth and financing matters, wanted to move document exchange between advisors and clients out of the email inbox. Until then, self-disclosures, financing requests, contract documents, and identification records ran as attachments through classic mailboxes. From a GDPR perspective, that was a cluster of problems in a tight space: unencrypted transmission of sensitive wealth and creditworthiness data, no access control after sending, no deletion routine, and no properly documented data processing arrangement with the mail provider. At the latest when a self-disclosure with marital status, income, assets, and credit obligations was sent, a supervisory authority would have found issues immediately.
Together we designed and built a tailored cloud application in which clients can upload documents through a protected access, complete self-disclosures, submit financing requests, and sign contracts digitally. Three GDPR building blocks were central: first, a clear legal basis per data class, with tiered consents for creditworthiness and financing data. Second, technical protection under Art. 32 GDPR with servers in Germany, encryption at rest and in transit, granular access control per advisor and per client, and audit logs for every document access. Third, a complete Data Processing Agreement between the advisory firm and Evelan as operator that explicitly governs sub-processors, storage locations, and deletion periods.
The result: since rollout, the financial advisory firm has stopped using email attachments for sensitive client documents entirely. Advisors and clients work in an auditable workflow that enforces GDPR requirements technically instead of merely depicting them. In the event of complaints or requests, any data flow can be traced in minutes, including evidence of who accessed which document and when. The application is ready for future requirements, such as new retention periods or additional authentication levels, without the legal basis having to be set up again.
Frequently Asked Questions
A legal basis for every data processing operation, a complete and up-to-date privacy policy, active cookie consent before any tracking script, accessible data subject rights, TLS encryption, a DPA with every service provider, and a clean solution for third-country transfers. These six areas form the minimum standard.
Related Evelan articles
- Cookie Banner Requirement: How to Implement It Correctly
- Legally Compliant Website: The Practical Guide
- How to Close the Biggest Security Gaps on Your Website
- Why a Legally Compliant Imprint Is Essential for Every Website
Quellen
- EUR-Lex GDPR portal: Art. 83 — fine framework (2016)
- CJEU: Planet49 — Case C-673/17 cookie consent (2019)
- CJEU: Schrems II — Case C-311/18 third-country transfer (2020)
- CMS: GDPR Enforcement Tracker Report — numbers and figures (2026)
- Bitkom: Data protection effort for companies is rising (2024, press release)
- HmbBfDI: Annual data protection report Hamburg (2024)
- BfDI: 33rd Annual Report on Data Protection (2024)
- EU Commission: EU-US Data Privacy Framework — adequacy decision (2023)
