Logo
  • Home
  • Service
  • About LLH
  • FAQ
  • Contact
  • 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.

  • When Do You Need a Data Protection Officer?

    25.10.2025

    Send us an email to [email protected] and receive a Checklist “Does My Company Need a Data Protection Officer (DPO)?

    Are you wondering whether your company needs a Data Protection Officer (DPO)? Many business owners and managers ask themselves this question. The good news: there are clear rules that can help you make this decision.

    The Data Protection Conference (DSC), a body of the independent data protection authorities of Germany’s federal and state governments, has published a short paper that serves as an initial guide explaining when do you need a DPO. It’s aimed particularly at organizations outside the public sector and explains when, in the DSC’s view, a Data Protection Officer is required. It also outlines which rules apply to both controllers and processors in this regards.

    The Three Most Important Situations When You Must Act

    In Germany, there are three specific cases in which you must appoint a Data Protection Officer — regardless of what the EU General Data Protection Regulation (GDPR) requires:

    1. You Have at Least 20 Employees with Data Access

    Once you regularly employ 20 or more people who handle personal data automatically, appointing a Data Protection Officer becomes mandatory.

    Important to know: The term “people” is interpreted broadly. It includes not only full-time employees but also:

    • Part-time staff
    • Temporary workers
    • Freelancers
    • Trainees

    However, your management team is not counted — they are not considered “employees” in the traditional sense, as they lead the company rather than being employed by it.

    What does “automated processing” mean?
    It’s easier to meet this condition than many think. Even if your employees send business emails, they are already processing personal data. Typical departments affected include:

    • Customer service and sales
    • IT department
    • Human resources
    • Accounting

    2. You Conduct High-Risk Data Processing

    If your company carries out processing activities that require a Data Protection Impact Assessment (DPIA), you would also need a DPO. This obligation can arise even from a single such processing activity.

    A DPIA is necessary when your data processing is likely to pose a high risk to the rights and freedoms of individuals. This is often the case in situations such as:

    Automated evaluations and profiling
    If you systematically create profiles of individuals or automatically assess them — for example, through scoring systems or automated decisions about credit approval or recruitment.

    Extensive processing of sensitive data
    This includes particularly sensitive information such as:

    • Health data
    • Ethnic origin
    • Religious or political beliefs
    • Criminal convictions or offenses

    Systematic monitoring of public areas
    Video or audio surveillance in publicly accessible areas falls into this category. The use of sensors that systematically observe their surroundings can also qualify.

    3. You Process Data on a Commercial Basis

    If you process personal data commercially — for example, to transfer, anonymize, or use it for market or opinion research — you must appoint a DPO.

    When Does It Become Particularly Critical?

    The likelihood that you’ll need to carry out a DPIA (and therefore appoint a DPO) increases significantly if your data processing meets at least two of the following criteria:

    • You evaluate or classify individuals
    • You make automated decisions with legal consequences
    • You carry out systematic monitoring
    • You process particularly sensitive or personal data
    • You process data on a large scale
    • You combine different data sets
    • You process data of vulnerable individuals (e.g., children)
    • You use innovative or new technologies
    • Your processing prevents individuals from exercising their rights or accessing services

    Not Sure Whether You Need a DPO?

    Get in touch with us, and we’ll help you determine whether your company falls under this obligation.
    With Legal Living Hub, you’ll receive modern data protection consulting and AI compliance guidance at eye level.

    Conclusion

    The decision about whether you need a Data Protection Officer is usually quite straightforward. Simply check whether one of the three main situations applies to your company. When in doubt, it’s best to consult an expert — because fines for violations can be severe.

    Remember: appointing a Data Protection Officer isn’t just about compliance. It’s also an opportunity to minimize data protection risks and build greater trust with your customers.

    If you need legal support with the assessment, get in touch with us.

    Secure your free 30-minute initial consultation.
  • Compliance Essentials for Founders

    19.10.2025

    Building a company in 2025 means building with trust from day one. Founders who treat privacy, security, and AI governance as core product features scale faster, avoid rework, and inspire investor confidence. 

    This article summarises our masterclass into a practical guide you can implement immediately.

    Why Compliance Matters

    Compliance = Trust + Credibility + Scalability.

    Compliance is not bureaucracy, it’s your growth strategy. Investors, partners, and customers expect transparency, accountability, and readiness from day one. Laying the foundations early helps you avoid costly fixes and product delays later.

    Sanctions and Business Risks

    Understanding the potential risks of non-compliance is essential for every founder. Regulatory frameworks like the GDPR and the EU AI Act are designed to protect individuals and ensure responsible innovation but violations can be costly. Beyond financial penalties, non-compliance can damage your brand, delay product launches, and erode investor and customer trust. The following overview highlights the main legal and financial risks founders should be aware of when handling data or deploying AI systems.

    • GDPR: Administrative fines up to €20 million or 4% of global turnover. Common triggers include data misuse, insufficient security, and unlawful processing.
    • Unlawful marketing: Unsolicited communications can lead to claims of harassment, individual damages (around €5,000 per person), and legal expenses.
    • EU AI Act: Non-compliance with transparency, risk, or data-governance obligations can result in fines of up to €35 million or 7% of annual turnover. High-risk AI faces the strictest rules.

    First Steps: Your Legal Foundations

    Every successful company begins with a sound legal foundation. Before focusing on product growth or marketing, founders should ensure that their business model and digital presence are compliant from the start.

    1. Check your business model.

    Begin by confirming that your activities are lawful in all target markets. Review whether your product or service requires any licences, certifications, or regulatory approvals before launch. At the same time, assess whether your business falls under the obligation to appoint a Data Protection Officer (DPO), a requirement for many data-driven or customer-facing companies in the EU.

    2. Fix your online presence.

    Your website is your company’s legal face to the world. Make sure it includes a clear and complete imprint (legal notice), an up-to-date privacy policy written in plain language, and a cookie banner that allows users to make an informed, balanced choice without manipulative design patterns. Don’t forget well-structured Terms & Conditions (T&Cs) and the mandatory consumer information that protects both you and your users.

    3. Contact customers lawfully.

    Before sending newsletters, promotional emails, or outreach messages, clarify who you may contact and on what legal basis. Marketing activities must comply not only with the GDPR but also with anti-spam and e-privacy regulations, which differ slightly between EU member states. Aligning your communication strategy with these rules helps you build trust, avoid fines, and keep your brand reputation intact.

    GDPR Essentials for Startups

    Why GDPR Still Matters in 2025

    Since May 2018, the General Data Protection Regulation (GDPR) has set the global benchmark for data privacy and accountability. It’s not just a European framework, it has influenced data protection laws from California to South Africa and continues to shape how startups handle personal data worldwide.

    For founders, the GDPR is both a legal requirement and a business opportunity. Implemented early, it becomes a foundation for trust, transparency, and scalability. Ignored, it can lead to reputational damage, product delays, and significant financial risks. Under the regulation, national supervisory authorities can impose fines of up to €20 million or 4% of global annual turnover, whichever is higher. But more often, the real cost of non-compliance lies in lost investor confidence and user trust.

    Core Principles Every Founder Should Know

    The GDPR is built around six key principles that should guide every product and data-handling decision:

    • Lawfulness: Every data processing activity must have a valid legal basis  such as contract performance, consent, or legitimate interest.
    • Fairness and Transparency: Individuals must understand how and why their data is used. Hidden or overly complex privacy notices violate both the letter and the spirit of the law.
    • Data Minimisation: Collect only the data you actually need. More data doesn’t mean better insight, it often just means more liability.
    • Purpose Limitation: Use data only for the specific purpose you’ve communicated to users. Repurposing data without a new legal basis is one of the most common GDPR breaches.
    • Accuracy and Storage Limitation: Keep data up to date and don’t store it longer than necessary. Define clear retention periods and deletion processes.
    • Integrity and Confidentiality: Implement security measures to protect data against unauthorised access, loss, or destruction.

    Practical Steps to Stay Compliant

    Turning these principles into practice requires both strategy and structure. Here’s how to begin:

    1. Map your data. Identify what personal data your startup collects, where it’s stored, who can access it, and for what purpose. A clear data inventory helps you meet documentation requirements and quickly respond to data subject requests.
    2. Manage access control. Limit access to personal data strictly to those who need it to perform their work. Implement strong authentication (e.g. MFA) and keep audit trails.
    3. Strengthen technical security. Encryption, regular backups, patching, and incident response plans aren’t optional, they’re essential for compliance and resilience.
    4. Formalise relationships with vendors. Whenever a third party processes data on your behalf, sign a Data Processing Agreement (DPA) and ensure they meet equivalent security and privacy standards.
    5. Manage international transfers. If you use tools or providers outside the EU, apply Standard Contractual Clauses (SCCs) and perform a transfer impact assessment to ensure adequate safeguards.
    6. Prepare for incidents. When a data breach occurs, you may have to notify the supervisory authority within 72 hours. Having an incident response plan can make this manageable and prevent escalation.

    Common Pitfalls to Avoid

    Many startups make the same avoidable mistakes:

    • Outdated or hard-to-find privacy policies. Your privacy notice must be clear, accessible, and written in plain language.
    • Overreliance on consent. Not every data use requires consent. In fact, consent can be withdrawn at any time, so it’s important to use it only where necessary.
    • Manipulative cookie banners. “Accept all” buttons that are easier to click than “Reject all” risk enforcement actions and reputational harm.
    • Excessive form fields. Asking for more data than needed, especially in contact or sign-up forms which violates data minimisation principles.
    • Ignoring small incidents. A pattern of minor lapses can reveal deeper systemic issues later. Every incident should be assessed, documented, and reviewed.

    The key is to treat privacy and compliance as part of your product design, not as an afterthought. When embedded early, compliance becomes a natural part of the development workflow.

    The EU Digital Strategy: The Bigger Picture

    The EU Digital Strategy complements the GDPR and the AI Act, forming the backbone of Europe’s vision for a trusted and competitive digital economy. For startups, it’s not just another layer of regulation it’s a roadmap for building future-proof businesses in Europe.

    The strategy aims to create a single digital market where data can flow freely, innovation can thrive, and users can trust the technologies they use. It includes key initiatives like the Data Governance Act, the Digital Markets Act, and the Digital Services Act, which set clear rules for data sharing, online platforms, and fair competition.

    In simple terms: the EU wants companies to innovate boldly but with transparency, user protection, and ethical data use at the core. Understanding these principles early helps founders design products and business models that can scale confidently across Europe and beyond.

    Understanding the EU AI Act

    The EU Artificial Intelligence Act (AI Act) is one of the world’s first comprehensive regulatory frameworks for artificial intelligence. It applies to developers, providers, and deployers of AI systems that have an EU connection, even if they operate abroad. The AI Act takes a risk-based approach: the greater the potential impact on people or society, the stricter the obligations. This means low-risk tools can operate with minimal requirements, while high-risk applications  such as those affecting health, employment, or access to essential services  face rigorous compliance duties, documentation, and oversight.

    Rather than introducing all rules at once, the EU has designed a phased implementation to give organizations, especially startups and SMEs, time to adapt and build compliant systems.

    Timeline Overview:

    • August 2024: Regulation enters into force.
    • February 2025: Ban on “unacceptable-risk” AI systems (e.g. manipulative or social scoring applications).
    • August 2025: Governance and transparency obligations become applicable.
    • 2026–2027: Full obligations for high-risk AI systems take effect.

    What Founders Should Do Now

    For founders building or using AI systems, preparation is key. Start by determining whether your product qualifies as an AI system under the Act and defining your role: are you a provider, deployer, or user? Each role carries different legal duties.

    Next, assess your system’s risk level: minimal, limited, high, or prohibited. For high-risk systems (e.g. those used in employment, healthcare, or critical infrastructure), you’ll need detailed documentation covering datasets, training processes, explainability, and human oversight.

    Data governance also becomes crucial. High-quality, representative, and well-documented datasets help prevent bias and discrimination while demonstrating accountability. Finally, integrate AI compliance into your broader digital strategy  alongside ethics, privacy, and security.

    Make Compliance Part of Your DNA

    Compliance is not a blocker, it’s a strategic advantage. Startups that take privacy, security, and governance seriously from the beginning build stronger relationships with users, attract more confident investors, and reduce legal risks as they grow.

    • At the Early Stage, focus on the basics: privacy policy, imprint, non-disclosure agreements, cookie banner, and Terms & Conditions.
    • At the Seed Stage, expand your scope to include employee data protection, contractual frameworks, and GDPR documentation.
    • At the Expansion Stage, prepare for cross-border data transfers, AI Act readiness, and investor due diligence.

    By building compliance into your company’s DNA, you don’t just meet legal standards, you signal to the market that your business is mature, trustworthy, and built to last.

    Conclusion

    Sustainable growth today is built on trust, transparency, and accountability. Compliance isn’t about ticking boxes it’s a core element of smart business strategy. Founders who embed privacy, security, and AI governance into their products from day one save time, reduce risk, and earn lasting trust from customers, partners, and investors.

    Startups that treat ethics and compliance as part of their DNA don’t just stay compliant they help shape the digital future of Europe.

    If you’re unsure and need legal support with the implementation, get in touch with us.

    Secure your free 30-minute initial consultation.

    Read also our article to Legal Tips for eCommerce

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.