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.

  • Pseudonymised is not anonymous – EUR 5 million against IQVIA and what MedTech should take from it

    07.08.2026

    CNIL decision of 26 May 2026 – SAN-2026-008 (IQVIA Operations France)

    Anyone consolidating health data at scale cannot fall back on the argument that the result is “anonymous” and therefore outside the scope of the GDPR. That calculation did not work out for IQVIA’s French entity: the CNIL imposed a fine of EUR 5 million.

    The facts in brief

    IQVIA produces studies for the pharmaceutical industry and operated two health data warehouses for this purpose, both previously authorised by the supervisory authority. They were fed from roughly 14,000 pharmacies and from several thousand physicians. The inspection revealed that data subjects were not properly informed, that data subject rights were ineffective in practice, and that the technical safeguards fell short of what was required.

    The company’s line of defence: the datasets were anonymous, so data protection law did not apply in the first place.

    Why the authority saw it differently

    In the CNIL’s assessment the datasets were not anonymous but pseudonymised, because tracing them back to individuals remained possible with reasonable effort. Three considerations carried that finding:

    1. A persistent identifier per patient, tying every data point of an individual together.
    2. The level of detail held – including year of birth, sex, treating general practitioner, prescriptions, diagnoses, symptoms, allergies, body measurements, vital signs, vaccination status, examinations performed and periods of sick leave.
    3. The ability to combine the data with publicly accessible sources. How low that threshold actually sits was demonstrated in the proceedings: through a patient support group on a social network, a study participant was matched within minutes.

    Two further points matter particularly for day-to-day practice:

    • Contractual re-identification bans are not enough. Prohibiting partners from re-identifying by agreement does not change the objective possibility. A statutory prohibition may be assessed differently – a contract clause is no substitute.
    • Intention is irrelevant. The fact that nobody in the organisation wanted to re-identify anyone was expressly treated as immaterial. What counts is whether it could be done.

    How this sits alongside the CJEU’s SRB judgment

    The company was able to invoke a line of authority that is genuinely favourable to data recipients: on 4 September 2025 (C-413/23 P, SRB), the CJEU confirmed a relative standard. The same pseudonymised dataset may constitute personal data in the hands of the party holding the key while being anonymous for a third party with no means of attribution.

    The CNIL draws the line where the role changes: IQVIA was not a recipient at the end of a chain but controller of the entire processing operation from the point of collection onwards – and the party creating the linkage in the first place. The relativity established in SRB relieves the third party without the key. It does not relieve the party that designs the warehouse, populates it and controls the linking logic.

    The additional findings

    Beyond the anonymity question, the authority criticised concrete implementation gaps: access logs were not reviewed systematically, multi-factor authentication was absent, patient information was inaccurate, and no functioning objection procedure was in place. On top of that, some pharmacies failed to inform their own customers correctly about the transfer, and the pharmacy software transmitted patient data without consent – a textbook privacy-by-design failure already built into the product architecture.

    In setting the amount, the sensitivity of the category, the volume (several tens of millions of data subjects), the market position and the financial strength of the company were treated as aggravating. The pseudonymisation actually carried out was recognised as mitigating, since it did rule out direct identification.

    Dos

    • Derive anonymity demonstrably rather than asserting it. Document, for each dataset, which attack scenarios (singling out, linkability, inference) you tested and how you excluded them.
    • Differentiate by constellation. What may be anonymous vis-à-vis an external recipient remains personal data internally. Determine the status separately for each recipient role.
    • Attack the identifier, don’t just mask it. Consider aggregation, k-anonymity, noise, generalisation of date fields, and breaking up longitudinal records.
    • Actively limit data depth. Every additional attribute – a vital sign, a prescription, the treating clinician – shrinks the comparison group. Fewer attributes is the legally more robust design here as well.
    • Get the basics working: intelligible patient information, a functioning objection route, systematic review of access logs, MFA on privileged accounts.
    • Think upstream. Where clinics, practices or pharmacies collect on your behalf, their information and legal basis chain is your risk – down to the configuration of the software they use.
    • Keep authorisations current. A regulatory approval protects you only to the extent that actual practice matches it.

    Don’ts

    • Don’t rely on SRB if you are the one performing the consolidation. The relative standard helps the third party without means of attribution – not the operator of the dataset.
    • Don’t treat contractual clauses as an anonymity argument. A re-identification ban is a sensible addition, but no substitute for technical effectiveness.
    • Don’t argue absence of intent. What is assessed is the possibility, not the motive.
    • Don’t use “pseudonymised” and “anonymous” interchangeably – not internally, and not in records of processing, privacy notices or customer-facing statements.
    • Don’t ignore publicly available sources. Social networks, patient forums and public registers belong in the risk assessment.
    • Don’t treat AI training data as a special case. The same standard applies to real-world evidence products, registry analyses and model training.

    What this means for MedTech specifically: this affects anyone maintaining post-market surveillance data, device telemetry, registry data or RWE datasets with stable identifiers over time. The combination of a persistent identifier and an expanding set of attributes is precisely the pattern the CNIL held to be incapable of anonymisation here.

    CNIL decisions are open to judicial review, so the case is not necessarily settled. For practical purposes, that changes little about the analytical framework applied.

  • 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.

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.