What the EDPB enforcement action 2026 examines
The Coordinated Enforcement Framework (CEF) is the procedure European supervisory authorities use to examine one topic jointly and in a coordinated way. In October 2025 the EDPB chose the topic for its fifth coordinated action at its plenary session: compliance with the transparency and information obligations of the GDPR (EDPB). The action was launched on 19 March 2026 (EDPB). During 2026, 25 data protection authorities from across Europe are taking part (EDPB). According to the EDPB, they contact controllers from different sectors, either through formal enforcement actions or through fact-finding exercises.
In the second half of the year the participating authorities share their findings and aggregate them (EDPB). The result is a consolidated report meant to allow targeted follow-up at national and EU level.
From Germany, the supervisory authorities of Lower Saxony and Brandenburg are taking part (LDA Brandenburg). The data protection commissioner of Lower Saxony intends to contact 15 companies and 5 municipalities in the state (LfD Niedersachsen). Brandenburg is focusing on a selection of recruitment agencies based in the state (LDA Brandenburg).
Transparency is not the first topic of this procedure. These are the previous coordinated actions and their reports as the EDPB lists them in its launch announcement:
| Topic of the coordinated action | Status according to the EDPB |
|---|---|
| Use of cloud-based services by the public sector | report published in 2023 (EDPB) |
| Designation and position of data protection officers | report published in 2024 (EDPB) |
| Implementation of the right of access | report published in 2025 (EDPB) |
| Right to erasure (Art. 17 GDPR) | report adopted in 2026 (EDPB) |
| Transparency and information (Art. 12 to 14 GDPR) | launched on 19 March 2026 (EDPB) |
A questionnaire within the enforcement action is initially a stocktaking exercise. The EDPB does, however, point out explicitly that authorities may decide on additional follow-up actions after fact-finding exercises (EDPB).
What Art. 12 to 14 GDPR require from a privacy policy
Art. 12 GDPR governs the form. The controller has to provide the information under Art. 13 and 14 in a concise, transparent, intelligible and easily accessible form, using clear and plain language (Art. 12 GDPR). Art. 13 governs the content when data is collected from the data subject. On a website that happens with every page view, every form and every embedded service that receives data from the browser. Art. 14 applies when data comes from other sources; the information must then be provided within a reasonable period, at the latest within one month (Art. 14 GDPR).
At the time of collection, Art. 13 GDPR requires the following information:
- Controller: name and contact details, and those of the representative where applicable (Art. 13(1)(a))
- Data protection officer: their contact details where one has been designated (Art. 13(1)(b))
- Purposes and legal basis for each processing operation, and for legitimate interests the interest itself (Art. 13(1)(c) and (d))
- Recipients or categories of recipients, where applicable (Art. 13(1)(e))
- Transfer to a third country including the adequacy decision or a reference to the safeguards, where applicable (Art. 13(1)(f))
- Storage period or the criteria used to determine it (Art. 13(2)(a))
- Data subject rights, the right to withdraw consent where consent is the basis, and the right to lodge a complaint with a supervisory authority (Art. 13(2)(b) to (d))
For websites, recital 58 is particularly revealing. It explicitly names situations where the number of actors and the technological complexity make it difficult for the data subject to know whether, by whom and for what purpose personal data are being collected, "such as in the case of online advertising" (Recital 58 GDPR). That is exactly where the information has to be concise, easily accessible and easy to understand.
The Court of Justice of the European Union already ruled under the predecessor directive that the operator must also provide information about embedded third-party services. If a website embeds a plugin that causes the browser to request content from the provider and to transmit personal data in the process, the duty to inform lies with the operator, namely for the operations it decides on itself: the collection and the disclosure by transmission (CJEU, C-40/17). The judgment of 29 July 2019 was handed down under Directive 95/46/EC (CJEU, C-40/17). In practice this means the information about embedded services cannot simply be passed on to their providers.
| Information | Provision | Typical gap on websites |
|---|---|---|
| Recipients | Art. 13(1)(e) GDPR | Services added since the last update are missing, removed ones are still listed |
| Third country | Art. 13(1)(f) GDPR | Service transferring data outside the EU without reference to an adequacy decision or safeguards |
| Purpose and legal basis | Art. 13(1)(c) GDPR | One catch-all wording for all services instead of a purpose per service |
| Storage period | Art. 13(2)(a) GDPR | Phrase such as "as long as necessary" without criteria |
| Withdrawal of consent | Art. 13(2)(c) GDPR | No explanation of how to withdraw consent in the consent banner |
| Right to complain | Art. 13(2)(d) GDPR | Missing or only on a linked subpage |
The recipients section: where policy and website drift apart
The recipients section is the part of the policy that goes out of date fastest. Every embedded service that receives data from the browser is a potential recipient: the content delivery network for images, the map service on the contact page, the video on the home page, web analytics, the advertising pixel. The HTTP Archive Web Almanac shows how widespread such services are: the share of pages with at least one third party is 90 percent or more (HTTP Archive Web Almanac 2025). At least one third-party tracker was found on 75 percent of desktop pages and 74 percent of mobile pages (HTTP Archive Web Almanac 2025).
On top of that there is an effect no plugin menu shows. The median depth of the inclusion chain is 3, which means the majority of third parties include at least one further third party themselves (HTTP Archive Web Almanac 2025). A chat widget can load an analytics script, a video player an advertising domain. Writing the policy only from the list of installed extensions misses this second layer. Which parts of a URL are sent along when a third party loads is controlled by the referrer policy, by the way; more on this in the article on direct traffic and the referrer policy.
How precisely recipients have to be named is described in the transparency guidelines of the Article 29 Working Party, which the EDPB has endorsed. According to them, the actual (named) recipients or the categories of recipients must be provided (WP260 rev.01). In line with the principle of fairness, controllers must provide the information that is most meaningful for data subjects, and in practice this will generally be the named recipients (WP260 rev.01). Anyone who only lists categories should make them as specific as possible: by type of activity, industry and location of the recipient (WP260 rev.01).
The guidelines explicitly advise against qualifiers such as "may", "might", "some", "often" and "possible" (WP260 rev.01). A sentence such as "We may use third-party services" does not answer the question about recipients. Anyone who still uses indefinite language should, according to the guidelines, be able to demonstrate why it could not be avoided and why it does not undermine the fairness of the processing.
Step 1: Check the privacy policy for required sections
Before looking at individual services, it is worth checking the framework. The free privacy policy crawler from XICTRAQ® checks a privacy page for the information required by Art. 13 GDPR. It separates information every controller owes from information the regulation only requires "where applicable". Controller, purpose, legal basis, storage period, data subject rights and the right to complain count towards the score. Recipients, data protection officer, third-country transfer, cookies, web analytics and contact forms are reported but do not count.
So the recipients section in particular is on the list of conditional items, because whether "where applicable" applies cannot be read from the privacy page alone. Only step 2 provides the answer. The check itself is a keyword heuristic: it detects whether a section exists, not whether it is correct. The tool points out itself that it does not replace legal advice and does not evaluate the accuracy of the content.
- Can the privacy policy be reached from every page via a clearly visible link under a commonly used term (WP260 rev.01)?
- Are the controller and, if designated, the data protection officer named with contact details?
- Does every processing operation have a purpose and a legal basis, not just a catch-all phrase at the beginning?
- Is there a storage period, or the criteria for it, for every processing operation?
- Are data subject rights, withdrawal of consent and the right to complain described?
- Does the policy show the date of its last change? This is not mandatory, but it helps with your own tracking.
Step 2: Measure which services load on a first visit
The policy describes what the controller believes is happening. What the website actually does only becomes visible through a measurement in the browser. The GDPR scan from XICTRAQ® simulates a first-time visitor without consent and records the trackers, cookies and network requests that occur on the first page view before consent. This includes an analysis of embedded third-party services such as fonts, videos, maps or web analytics.
For a one-off check without an account, the free cookie scanner is enough. It loads the page in a real headless Chromium without clicking the consent banner, lists every third-party domain the browser contacts and assigns them to categories such as analytics, advertising, social, fonts, CDN, maps, video and chat. Domains without a known category appear as "Other" and need a manual check.
The limits of this measurement matter, because they determine what you have to record yourself:
- Only before consent: services that load only after consent do not appear in this scan. They are listed in your consent tool's service list and still belong in the policy.
- Only the scanned URL: home page, contact page with a map, product page with a video and checkout often load different services. Measure the page types individually.
- Only what happens in the browser: server-side recipients such as the shipping provider, the newsletter service or accounting do not show up in any browser measurement.
- Only one point in time: a measurement applies to the day it ran. After every plugin update the list can look different.
The scan and your own system overview together produce a service inventory. A simple table is enough; what matters are columns that will carry the comparison later. The values in the example are arbitrary and not a legal assessment:
service_category;domain;page_type;before_consent;in_policy;legal_basis;third_country;checked
CDN;cdn.example-cdn.example;all;yes;yes;legitimate interest;no;2026-10-19
Map service;maps.example-maps.example;contact;no;yes;consent;yes;2026-10-19
Video platform;video.example-video.example;product;no;yes;consent;yes;2026-10-19
Web analytics;analytics.example-analytics.example;all;no;yes;consent;no;2026-10-19
Payment service;pay.example-payment.example;product,checkout;yes;no;contract;yes;2026-10-19
Chat widget;chat.example-chat.example;all;yes;no;open;yes;2026-10-19Step 3: Compare policy and measurement by hand
XICTRAQ® does not automatically compare the privacy policy with the scan. The comparison remains manual work because the policy describes providers and purposes in prose, while the scan delivers domains. With the service inventory from step 2, it works in this order:
- Group domains by provider. A service often uses several domains, for example for the script, the API and images. The goal is one row per provider, not per domain.
- List your own domains separately. They are not a third party in the browser, but they often run on a hosting provider or content delivery network. Processors are recipients within the meaning of the regulation as well (WP260 rev.01).
- Hold each row against the recipients section. Is the provider, or a sufficiently specific category, named in the policy?
- Hold the legal basis against the loading behaviour. If the policy names consent as the basis but the service loads before consent, the first problem is not the text but the integration.
- Check third countries. For services transferring data outside the EU, Art. 13(1)(f) GDPR requires a reference to an adequacy decision or safeguards. How to spot such data flows in the network log is described in the article on measuring data flows from websites.
- Check the other way round. Which providers does the policy name that the website no longer uses? Outdated entries make it inaccurate too.
- Record the date. The measurement date, the policy version and every change belong in the service inventory with a date.
| Finding in the comparison | What it means | Next step |
|---|---|---|
| Service loaded, not named in the policy | Recipient missing (Art. 13(1)(e) GDPR) | Update the policy, clarify legal basis and third country |
| Service named, but no longer loading | Policy inaccurate | Remove the entry, update the version |
| Basis is consent, service loads before consent | Contradiction between text and technology | Fix the integration, then measure again |
| Transfer to a third country without a reference | Information under point (f) missing | Add the transfer mechanism |
| Domain in the "Other" category | Purpose unclear | Find its origin, often a service loaded by another service |
Neither source is enough on its own. The policy knows server-side recipients no browser can see; the scan knows services loaded by other services that appear in no contract. Only together do they produce the recipients section Art. 13 GDPR has in mind.
New services in the fourth quarter
Ahead of the Christmas season, shop and company websites typically add new services: an additional payment method, a chat for questions, a review widget, a pixel for the campaign. Each of them is a potential new recipient. Four typical candidates for a gap:
Instalment and express buttons can load scripts from the payment provider on the product page already. Measure product page and cart separately, add the provider and any third country.
A chat is usually embedded site-wide and can open connections before anyone writes. Check whether it loads before consent and whether the storage period of chat histories is described.
A pixel usually reads or stores information on the device and then requires consent (§ 25 TDDDG). If it loads before consent, fix the integration first and the policy second.
Trust badges and review displays load content from the provider's server. If the browser sends data there, the provider belongs in the recipients section.
If the new service brings a new purpose, the order is fixed by law: if the controller intends to further process data for a different purpose, it must inform the data subject prior to that further processing (Art. 13(3) GDPR). For changes to the policy, the transparency guidelines recommend communicating fundamental changes well in advance of them taking effect. As examples they explicitly name an enlargement of the categories of recipients and the introduction of transfers to a third country (WP260 rev.01).
For anything that stores or reads information on the device, § 25 TDDDG applies in addition. The German provision only allows this if the end user has consented on the basis of clear and comprehensive information, and it refers explicitly to the GDPR for information and consent (§ 25 TDDDG). Consent that relies on an incomplete policy can therefore be open to challenge. How to detect deviations technically after every release is shown in the article on consent and tag drift. And because different services load at checkout than on the home page, it is worth looking at how a browser check walks through the order path step by step, as described in the article on discount codes at checkout.
When the questionnaire arrives: documents to have ready
The enforcement action works with a questionnaire coordinated across Europe (LDA Brandenburg). In Lower Saxony, the selected controllers are asked about their measures and processes regarding the information obligations under Art. 13 and 14 (LfD Niedersachsen). So the question is not only about the text but about how it comes about: who maintains the policy, what triggers a change, and how is it checked whether it is still accurate?
Behind these questions lies the accountability principle. The controller must be able to demonstrate compliance with the principles (Art. 5(2) GDPR), and these principles include processing in a manner that is transparent to the data subject (Art. 5(1)(a) GDPR). These documents should therefore be ready:
- the current privacy policy with the date of its last change
- the service inventory with provider, purpose, legal basis, third-country link and page type
- dated scan results before consent, for each relevant page type
- the service list of the consent tool as an export
- the data processing agreements with the service providers in use
- a short description of the process: who updates the policy when an extension is installed or a service is booked?
The fines provision places infringements of the data subject's rights under Articles 12 to 22 in the upper tier (Art. 83 GDPR). There, fines of up to 20 million euros or, for undertakings, up to 4 percent of the total worldwide annual turnover of the preceding financial year are possible, whichever is higher (Art. 83 GDPR). That is the frame, not the amount to expect.
This article describes a technical comparison. Whether a legal basis holds or a transfer to a third country is permitted is assessed by data protection officers or legal counsel. XICTRAQ® provides the measurements they need for that.
Make the comparison a routine
A privacy policy describes a state that can change with every release. A fixed trigger for the comparison is therefore useful: every change to extensions, tag configuration or consent tool, every new campaign, and in addition a regular date.
XICTRAQ® takes care of the measurement part of this routine. The GDPR scan records which services load before consent, and a new scan after the fix shows whether it worked. The free privacy policy crawler checks the status of the required sections. The remaining checkpoints for websites, from consent banners to external fonts, are summarised in the guide to GDPR compliance for websites. The live demo shows how findings appear in the dashboard, and the pricing page lists which features are included in which plan.
The EDPB enforcement action 2026 is therefore a good moment to hold your own policy against measured reality.
This article is based on: EDPB, announcements of 14 October 2025 and 19 March 2026 on the coordinated action on transparency and information; LfD Niedersachsen and LDA Brandenburg, press releases of 19 March 2026; Regulation (EU) 2016/679 (GDPR), Art. 5, 12, 13, 14 and 83 and recital 58; Article 29 Working Party, Guidelines on transparency (WP260 rev.01), endorsed by the EDPB; CJEU, judgment of 29 July 2019, C-40/17 (Fashion ID); § 25 TDDDG; HTTP Archive, Web Almanac 2025, chapters Privacy and Third Parties. This article does not constitute legal advice.