Logo
  • Home
  • Service
  • About LLH
  • FAQ
  • Contact
  • Email Tracking and Data Protection: France’s CNIL Requires Explicit Consent for Marketing Tracking from July 2026

    07.08.2026

    Tracking pixels are tiny, usually invisible images that are not embedded in the email itself but are loaded from a remote server when the message is opened. Through the individualised image URL, the sender learns whether, when and on which device an email was opened.

    The French data protection authority CNIL has published its final “Recommendation on tracking pixels in emails” on this subject and makes clear: reading out this information constitutes a read/write operation on the recipient’s terminal equipment within the meaning of Article 82 of the French Data Protection Act (Loi Informatique et Libertés), which implements Article 5(3) of the ePrivacy Directive. In doing so, the CNIL expressly follows EDPB Guidelines 2/2023 on the technical scope of the ePrivacy Directive.

    The recommendation states verbatim that the integration of tracking pixels constitutes “an instruction given to the user’s terminal to return targeted information” — that is, an instruction to the terminal equipment to send back specific information (pixel identifier, IP address, etc.).

    The consequence: as a general rule, the recipient’s prior, freely given, specific, informed and unambiguous consent is required unless an exemption applies.

    E-Mail Tracking

    Applicability

    The rules have applied since mid-July 2026 to recipients in France. The Italian supervisory authority will follow with comparable requirements in October 2026. Observers expect further EU supervisory authorities to adopt the CNIL’s approach: the position is based on the EDPB Guidelines and is therefore capable of being applied across the Union.

    What is actually new about this?

    The consent requirement as such is not new. Article 5(3) of the ePrivacy Directive has long applied in a technology-neutral manner to any access to terminal equipment. In Germany, section 25 TDDDG governs the same matter, and the fact that personalised newsletter tracking falls within its scope has been the settled European view since EDPB Guidelines 2/2023. Many companies therefore already obtain consent today, though often in the form of a blanket sentence in the newsletter sign-up text (“We analyse open and click rates in order to improve our content”), bundled together with the marketing consent. This is precisely where the CNIL comes in: the recommendation does not create new law, but for the first time defines in a binding and concrete manner how consent texts, sign-up forms and privacy policies for email tracking are to be designed.

    The following points are new in detail:

    Granularity instead of blanket consent. A collective consent covering “newsletter incl. tracking” is no longer sufficient. Each tracking purpose (campaign optimisation, profiling, fraud detection) requires its own active opt-in action — with a short title and a brief description for each purpose; the CNIL provides verbatim model wording for this (section 4.1). Only closely related purposes may be bundled, for example direct marketing expressly advertised as personalised together with the pixels used for that purpose.

    The cookie banner is not a suitable place. In a dedicated note, the CNIL clarifies that obtaining consent via a consent management platform on the website is problematic: users do not understand there that their choice concerns a different environment — their email inbox — and a specific email address; the informed nature of the consent is therefore lacking. The correct place is the newsletter sign-up form itself, at the point where the email address is collected.

    Concrete data minimisation requirements. For consent-free deliverability measurement, only the date of the last opening may be stored, to the day — without a time stamp, without any history, on an overwriting basis. Anyone who currently retains complete opening logs will have to adapt their systems.

    Concrete requirements on withdrawal. A withdrawal link in the footer of every email, withdrawal without having to re-enter the address, and effectiveness also for emails already sent when they are re-opened.

    Obligation to adapt the privacy policy. Even consent-free pixels (deliverability, authentication, compliance evidence) should, as good practice, be disclosed transparently in the privacy policy.

    In practice this means: the implementation effort lies less in the “whether” of consent than in revising existing consent texts, sign-up journeys and privacy policies — away from the blanket sentence and towards purpose-separated consents that have to be actively ticked, with documented evidence.

    Purposes requiring consent

    Under section 3.1 of the recommendation, the recipient’s consent is required in particular for the following purposes:

    Campaign optimisation and performance measurement. Analysing the open rate in order to measure and optimise campaigns — for example by personalising content, adjusting sending frequency or choosing the communication channel (email, SMS, push) — requires an opt-in. This also covers send-time optimisation based on individual opening times.

    Profiling. Creating recipient profiles based on observed preferences and interests in order to address individuals outside the email channel (websites, apps, other channels) requires consent. This includes classic practices such as follow-up campaigns to openers or non-openers, or triggering the next email in a series upon an opening.

    Fraud detection for the sender’s benefit. Detecting and analysing suspicious activity — for instance mass automated openings in prize draws or indications of ad fraud — also requires consent.

    Individual open measurement outside the deliverability exemption. Individual measurement of the open rate for deliverability purposes is exempt from consent only within the narrow limits of section 3.2 (see below); beyond that, the consent requirement applies.

    Purposes exempt from consent

    Section 3.2 of the recommendation lists purposes for which pixels may be used without consent — provided they are used exclusively for those purposes:

    Security measures in the context of user authentication, for example verifying whether an email containing an authentication code is in fact opened on a device attributed to the user.

    Individual open measurement for deliverability purposes. The CNIL acknowledges that managing distribution lists is, in practice, dependent on opening statistics. However, the controller must be able to demonstrate that the processing is limited to what is strictly necessary — specifically, adjusting the frequency or stopping sending to inactive recipients (database cleansing). Subject to that proviso, the following are additionally permissible: assessing and adjusting the communication channel (choosing alternative contact routes) and evidencing compliance with statutory information obligations (e.g. receipt of legally required communications within a contractual relationship).

    Strict data minimisation applies here: in principle, only the date of the last known opening may be stored — to the day, without a time stamp — with each new opening overwriting the previous entry. A history of opening behaviour is not permitted.

    Aggregated, anonymised open rates. According to the recommendation, the further use of effectively anonymised data does not constitute an additional interference within the meaning of Article 82; the GDPR remains applicable to the anonymisation process itself.

    Important: the exemptions apply only to emails that the recipient has requested or that relate to a service requested by them — in particular transactional emails (order confirmations, dispatch notifications, password resets, appointment confirmations, etc.) as well as emails from public authorities within the scope of their public task. The CNIL also points out that the consent regime for pixels is independent of the one governing the sending of the email itself: even for emails that may be sent without consent (e.g. marketing to existing customers), separate consent may be required for the use of pixels.

    How companies can implement the requirements

    At its core, implementation comes down to adapting three documents or processes: the newsletter sign-up form with its consent texts, the privacy policy, and the withdrawal/preference process. In detail:

    1. Audit of the current state.

    First, an inventory should be taken of which tracking pixels are in use, who sets them (in-house sending, email service provider, third-party technology) and for which purposes the opening data is actually used. The CNIL requires each actor to determine its role: the sender is regularly the controller (even where sending is outsourced), the email service provider is generally a processor; where list rental companies or technology providers also use the data for their own purposes, joint controllership under Article 26 GDPR may arise — with a corresponding obligation to conclude an arrangement.

    2. Obtain granular consent — ideally at the point of address collection.

    The CNIL recommends obtaining consent for the use of pixels already when the email address is collected, i.e. in the sign-up form. Each purpose must be presented with a short title and a brief description; the recommendation contains concrete wording examples for this. In principle, it must be possible to give consent separately for each purpose — one separate, non-pre-ticked checkbox per purpose. In two-tier consent solutions, an overall consent at the first level is permissible only if a purpose-specific choice (or a choice by related families of purposes) can be made at the second level. A single consent covering both direct marketing and pixels is possible only exceptionally, where the purposes are closely connected — for instance marketing expressly advertised as personalised together with the pixels used for it.

    3. Subsequent collection via a pixel-free email.

    Where consent could not be obtained at the point of address collection, it can be obtained subsequently by email — that email must not itself contain any tracker requiring consent. The link should lead to a page on which the person performs an active action (clicking a button), in order to avoid unintended “consents” caused by email clients automatically pre-loading links. Inactivity is to be treated as a refusal. As good practice, the CNIL suggests not re-approaching recipients who have refused for at least six months.

    4. Withdrawal as easy as giving consent.

    The CNIL recommends an individualised link in the footer of every email leading to a page where withdrawal is possible without further hurdles — in particular without having to re-enter the email address. The withdrawal must be effective: pixels that have already been set must no longer be evaluated when old emails are re-opened.

    5. Evidence of consent.

    Under Article 7(1) GDPR, consent must be demonstrable on an individualised basis at any time. Where consent is obtained by third parties (such as list brokers), a mere contractual clause is not sufficient — but the contract can govern evidence mechanisms, retention and regular audits. The controller’s liability remains in place if the third party is unable to provide the evidence.

    6. Transitional arrangement for existing addresses.

    For addresses already collected, tracking may initially be continued provided that recipients are informed clearly and accessibly within, in principle, three months from publication of the recommendation and can object to the use for future emails. In practice this meant: anyone who has not informed existing subscribers (sign-up before 14 April 2026) by 14 July 2026 and given them an opt-out option must now actively obtain consent on an opt-in basis. For addresses collected after 14 April 2026 and before the go-live of the new opt-in process, the opt-in requirement applies from the outset, as for new subscribers.

    7. Transparency also for consent-free pixels.

    Article 82 does not require separate information for consent-free uses; the CNIL nevertheless recommends, as good practice, disclosing them in the privacy policy.

    What happens in the event of non-implementation?

    The recommendation itself is formally non-binding (“neither regulatory nor exhaustive”), but it gives concrete shape to binding law: Article 82 of the Loi Informatique et Libertés and thus Article 5(3) of the ePrivacy Directive. The CNIL can sanction infringements of Article 82 directly — and has done so consistently for years: the cookie fines against Google (EUR 150 million in total) and Amazon (EUR 35 million) were based on precisely this provision; the fining framework extends up to EUR 20 million or 4% of worldwide annual turnover. Since, by its own account, the CNIL is receiving an increasing number of complaints about email pixels, enforcement by the supervisory authority is to be expected. In addition, there are civil law risks (data subject rights, damages under Article 82 GDPR) and — where downstream data processing takes place without a legal basis — parallel GDPR infringements, since the recommendation makes clear that any further processing of the data obtained via pixels must additionally satisfy the requirements of the GDPR.

    Alongside the legal risk, practical considerations also argue for a realignment: since Apple’s Mail Privacy Protection, opening data has in any event been of only limited reliability, and since November 2025 measured Gmail open rates have fallen by around 30% as a result of stricter requirements for bulk senders. Marketing professionals are therefore increasingly shifting performance measurement and segmentation to clicks, conversions, website activity and zero-party data (preference centres) — signals that can at the same time be structured in a more robust way from a data protection perspective.

  • Data Protection for Freelancers: Avoiding Legal Pitfalls

    09.03.2026

    Your company now wants to work with freelancers, i.e. independent contractors. There are several advantages, such as flexible deployment on an invoice basis without employment law obligations. At the same time, there are legal questions that need to be considered and clarified. Depending on how closely a freelancer is integrated into your business, completely different rules apply. And you should know them – otherwise you risk not only trouble with the data protection authority, but in the worst case also consequences under social security law.

    This article focuses in particular on the data protection hurdles.

    A Freelancer is Not Just a Freelancer

    When you bring in external specialists and they process personal data for you or with you, this can take on very different legal forms. The GDPR recognises several models for classifying freelancers as data recipients in the context of data protection:

    • Independent controller (Art. 24 GDPR)
    • Joint controllers (Art. 26 GDPR)
    • Processor (Art. 28 GDPR)
    • Person subject to the authority of the controller (Art. 29 GDPR)

    Which model applies to your situation depends on the specific working relationship. And this is where it gets interesting.

    The Decisive Factor: How Much Control Do You Exercise Over a Freelancer?

    The central question is: How much do you dictate to the freelancer what to do and how to do it?

    A lot of autonomy

    If the freelancer decides for themselves the purpose and manner in which they process data, they act as an independent controller. In that case, they are a third party under data protection law and bear full responsibility themselves. If you jointly determine the purpose and nature of the data processing, joint controllership applies. In both cases, a Data Processing Agreement is required – clearly regulating responsibilities and their limits.

    Subject to instructions, but organisationally independent = Processor

    The term “subject to instructions” is already tricky in the context of a freelancer contract. However, if a freelancer processes data on your behalf and that work is bound by your instructions, this constitutes order processing.

    Caution! It is important to note here that even though someone works according to your content guidelines, they should still distance themselves from your organisation as much as possible – for example, by using their own tools or by independently deciding on their working hours and location. In this case, you absolutely need a Data Processing Agreement (DPA) that precisely governs what is to be done and how, and in particular that the instructions relate exclusively to data processing.

    When Is a Freelancer to Be Classified as an Employee?

    If your freelancer effectively works like an employee, they may qualify as a “person subject to the authority of the controller” within the meaning of Art. 29 GDPR. That sounds practical at first, but it has its pitfalls.

    The following points indicate that someone is legally treated like an employee:

    • Works with your hardware and software
    • Has fixed working hours on your premises
    • Uses your time-tracking systems
    • Wears a staff ID badge
    • Submits regular project reports
    • Has little scope to exercise their own judgement in performing tasks
    • Is integrated into workflows just like your permanent employees

    Caution: Bogus Self-Employment!

    Now it gets tricky: if someone is as closely integrated as an employee – why are they still “self-employed”? This is where the danger of bogus self-employment lurks, which can have massive employment, social security, tax, and even criminal law consequences for both parties.

    Bogus self-employment exists when someone is formally engaged as self-employed but is in fact in a dependent employment relationship and would actually need to be employed subject to social security contributions.

    Additional warning signs include:

    • No work for other clients
    • Non-competition and secondary employment restrictions
    • No use of own capital or resources
    • Inability to engage third parties to perform the service

    Important to understand: The data protection classification is not identical to the social security law assessment. You can classify someone as a person subject to authority under Art. 29 GDPR without this automatically constituting bogus self-employment – but the areas overlap significantly. So: keep your eyes open when drafting contracts!

    How to Avoid Mistakes

    The different classifications require a careful case-by-case review. Our tip:

    • Analyse the actual working relationship – not just what the contract says
    • Clearly distinguish between order processing and Art. 29 GDPR – do not use Art. 29 as an excuse to avoid a proper DPA
    • Document everything carefully – precise contracts are your best protection
    • Review regularly – working relationships evolve, and so does their legal classification

    Legal Living Hub Takes Care of It for You

    Sounds complicated? It is. But that’s what we’re here for.

    At Legal Living Hub, we help small businesses like yours stay on the safe side of the law. We analyse your freelancer collaboration, classify it correctly under data protection law, and create the appropriate contracts – whether DPA, joint controllership agreement, or confidentiality declarations.

    That way, you can focus on your business, while we make sure you don’t receive any unpleasant correspondence from the data protection authority or the pension insurance provider.

    Let’s talk about your freelancer situation – together we’ll find the legally clean solution for your company.

  • GEMA vs. OpenAI: Landmark Ruling on Copyright in the AI Era

    26.11.2025

    The Case That’s Shaking the AI Industry

    On November 11, 2025, the Munich Regional Court issued a decision* that could have far-reaching consequences for the development of artificial intelligence. GEMA, Germany’s largest music rights management organization, had sued OpenAI – and won. The allegation: ChatGPT had used copyrighted song lyrics without a license and reproduced them almost verbatim.

    *LG München I, Endurteil v. 11.11.2025 – 42 O 14139/24– can be found here: gesetze-bayern.de

    The Core Question: What is Text & Data Mining?

    In its defense, OpenAI had invoked so-called Text & Data Mining (TDM). This exception anchored in copyright law generally allows the use of protected works for automated analysis of large data sets. The idea behind it: science and research should be able to recognize patterns and correlations in texts without having to acquire a license for each individual text.

    GEMA vs. OPENAI

    However, the Munich court made it clear: What OpenAI was doing goes beyond pure TDM. The crucial difference lies in the type of use. TDM typically analyzes data and derives new insights from it. ChatGPT, however, had apparently processed the song lyrics in such a way that they could later be output almost word-for-word.

    The Problem of “Memorization”

    A central concept in this legal dispute is so-called “memorization.” This refers to the process by which AI systems go beyond simply learning patterns from training data. Instead, they effectively store this content and can later reproduce it.

    In large language models like ChatGPT, memorization can occur under specific conditions. This happens when certain texts are processed so frequently during training or are so distinctive that the model essentially “memorizes” them. The system then develops the ability to reproduce these texts almost identically. This process is similar to a human who has memorized a poem.

    It was precisely this memorization that became OpenAI’s undoing. The court’s argumentation addressed a crucial distinction in AI usage. When an AI internalizes copyrighted works so strongly that it can reproduce them verbatim, it crosses a legal boundary. This is no longer permissible analysis, but constitutes unauthorized reproduction and public communication.

    The Legal Classification

    The Munich Regional Court established a clear boundary in AI copyright law. When AI training results in content being permanently retained or later reproduced word-for-word, it exceeds the scope of the TDM exception. This exception is intended only for pure analysis, not for the reproduction of protected works.

    Therefore, if an AI application uses and reproduces song lyrics without a license, developers violate German copyright law. This directly interferes with the economic exploitation interests of the creators. Users could then access texts via AI instead of purchasing them from licensed providers.

    Reactions and Outlook

    Dr. Tobias Holzmüller, CEO of GEMA, was combative after the verdict: The internet is not a self-service store and human creative achievements are not free templates. They had created a precedent that makes clear – operators of AI tools must also comply with copyright law. Therefore GEMA sees the verdict as a successful defense of musicians’ livelihoods (Zitat: gema.de)..

    The verdict is not yet legally binding. OpenAI could appeal, and it remains to be seen whether higher courts will share the Regional Court’s assessment.

    What Does This Mean for the Future?

    This decision could have profound implications for the development and deployment of AI systems. Companies may need to rethink their training methods and ensure that their models cannot memorize and reproduce protected content. This could lead to technical adjustments, such as filters that prevent copyrighted texts from being output.

    At the same time, the verdict raises fundamental questions: How can AI developers ensure that their systems do not violate copyrights? What technical measures are necessary and practicable? And how can innovation in AI development be reconciled with the protection of creative works?

    In any case, the Munich verdict makes one thing clear: The message “Copyright remains in force – even in the AI age” has reached the courts. Song lyrics and other creative works are not free training resources for artificial intelligence. Those who want to use them must pay for it – or find technical ways that exclude memorization and reproduction.

    You want to read more about AI? Check out our articles on “What is an AI System?” and “CRA vs. AI Act“.

    Do you have questions about using AI systems? Secure your free initial consultation now!

    Secure a free 30-minute initial consultation

Copyright 2024

  • Imprint
  • Privacy Notice
Cookie Consent
Legal Living Hub uses cookies to ensure the website functions reliably and to collect information for statistical analysis. You can change your cookie settings at any time in the footer of the website. For more information, please refer to our privacy notice.