Remove the names. Replace them with codes. Place the key with a third party. Anonymous data? Not necessarily.
Recent decisions by the Garante and the CNIL are clear reminders that key-coded health data does not automatically fall outside of data protection law. Although SRB offers a potential route to treating pseudonymised data as anonymous in the hands of a particular recipient, it is not a silver bullet. Pharmaceutical and medtech businesses must still address re-identification and singling-out risks, as well as a more fundamental question: are they themselves acting as controllers of the anonymisation process?
The legal starting point: SRB and relative identifiability
In EDPS v SRB (4 September 2025), the Court of Justice of the European Union (CJEU) held that pseudonymised data are not personal data ‘in all cases and for every person’. From an ‘independent recipient’s’ perspective, data may lose their ‘personal’ character, but only where two conditions are met:
- the recipient cannot reverse the technical and organisational measures used for pseudonymisation; and
- those measures actually and effectively prevent the recipient from attributing the data to an individual by other means.
Importantly for pharmaceutical and medtech businesses, the CJEU confirmed the concept of relative personal data: the same data may be personal data in the hands of one party, but not in the hands of another. This is particularly significant where coded longitudinal datasets are routinely shared among several parties. The threshold, however, depends on the recipient’s actual role, access, influence and means, rather than solely on formal separation of the key or contractual labels.
The two decisions compared
The French data protection authority (CNIL) and the Italian Data Protection Authority (Garante per la protezione dei dati personali, the ‘Garante’) have each applied the SRB test in recent decisions, helping to clarify its limits. Although they reached similar conclusions, they relied on complementary lines of reasoning:
- The Italian decision illustrates how a business’s involvement in designing, structuring and operating a data pipeline may prevent it from relying on the position of an independent recipient. Instead, that party may be assuming a controllership role.
- The French decision confirms that, even where controllership arises from a specific regulatory framework, the dataset must still be assessed in substance for singling-out and linkage risks.
Whose perspective applies? In the Italian decision, the central question was whether the business was genuinely outside the collection and pseudonymisation chain. Its role in structuring and directing that chain meant that it could not rely on the position of an “independent recipient”. In the French decision, by contrast, the operator was treated as a controller primarily by reference to its role under the applicable data-warehouse authorisations and its responsibility for the processing.
Why did the data remain personal? The Italian authority focused on persistent identifiers, detailed longitudinal clinical data, limited controls over quasi-identifiers and unregulated free-text fields, all of which created singling-out and linkage risks. The French authority reached a similar conclusion by reference to unique patient identifiers, granular health histories and possible linkage with reasonably available external information, meaning that the data remained pseudonymised rather than anonymous.
What does separation of the key achieve? Both decisions confirm that separation of the key is relevant, but not decisive. In the Italian case, it could not overcome the fact that the party had arranged or controlled the broader processing architecture. In the French case, it did not establish anonymity because the records remained sufficiently unique, detailed or linkable from the recipient’s perspective.
What follows in practice? For businesses involved upstream in creating health datasets, the processing must be supported by a lawful basis, an Article 9 condition, accurate transparency information and documented accountability measures. For controllers operating within a specific regulatory framework, responsibility for transparency and compliance remains even where there is no direct contact with the individuals concerned.
When will a party be considered to be processing personal data?
The practical question is not simply whether a party holds the re-linking key. It is whether, viewed across the entire processing chain, that party determines or materially shapes the collection, pseudonymisation, use or disclosure of the data. The recent decisions indicate that a party is more likely to be regarded as processing personal data, and potentially as a controller, where one or more of the following features are present:
- Design of the data flow. The party specifies which data are collected, how they are extracted, transformed or coded, and how the resulting dataset is structured.
- Instructions to upstream actors. It directs healthcare professionals, software providers or other participants on the technical or organisational steps to be followed.
- Control of purposes or essential means. It decides why the database is created, how it may be used, who may access it, how long information is retained or the conditions for onward disclosure.
- Contractual organisation of the chain. It appoints processors, contracts with data sources or otherwise allocates responsibilities across the collection and pseudonymisation process.
- Ownership or operational control of the database. It operates, funds or controls the central dataset and benefits from the resulting analytics or products.
- Ability to influence identifiability risk. It determines coding parameters, data granularity, free-text controls, linkage possibilities or other measures that affect whether individuals can be singled out.
No single factor is necessarily determinative. However, the greater the party’s influence over the upstream process, the less credible it becomes to characterise that party as a passive or independent recipient for the purposes of SRB. Formal separation from the key, or a contractual statement that only anonymous data are received, will not displace the factual analysis.
Practical checklist for health-data businesses
- Map your role first. ‘Independent recipient’ status must reflect the facts, rather than merely being stated in a contract. If a business designs or directs the pseudonymisation process, it may assume a controller role and SRB is unlikely to assist.
- Test the entire record, not only the quasi-identifiers. Persistent identifiers, detailed longitudinal clinical data and long observation periods present precisely the risk profile highlighted by both authorities. Singling-out risk should be measured and documented.
- Treat separation of the key and contractual restrictions as supporting measures only. Placing the key with a third party and contractually limiting use to ‘anonymous’ data are relevant safeguards, but they are not decisive in determining whether a party holds anonymous information.
- Ensure that the anonymisation step has an appropriate lawful basis and is covered by accurate transparency information. Mischaracterising data as anonymous is itself a transparency risk. An Article 6 lawful basis, an Article 9(2) condition and accurate information from the controller are required for the lawful processing of personal data for anonymisation purposes.
- Document, control and re-test. Screen free-text fields, retain evidence of testing and reassess the position following incidents and relevant decisions in other jurisdictions. Group-wide data models should be reviewed on a country-by-country basis.
Key takeaway
SRB opens a potential route for pharmaceutical and medtech businesses to treat certain datasets as anonymous, but only from the perspective of genuinely independent recipients. Roles, access to additional information and record uniqueness remain fact-dependent.
