Hashed user IDs are personal data for the SaaS vendor that processes them

A prospect's privacy lead sends back the security questionnaire with one answer flagged: "We only receive hashed user IDs, so the GDPR does not apply to us." The privacy lead wants a data processing agreement and breach-notice terms before the deal moves. If a data protection regulator later tests that answer and it fails, every obligation the vendor skipped because of it is a separate infringement. On 21 October 2026 the EU's member states sided with the privacy lead. In their position on the Digital Omnibus, a package of amendments to the GDPR, coded data stays personal data for any vendor processing it for a customer, however well the names are hidden 1. EU regulators already read today's law the same way in draft guidance 6. I would not put that answer in front of a prospect.

The same text answers the opposite case, a company that sends hashed or coded data to an analytics tool, a model provider or a partner: for the company holding the key, that data never stops being personal data. Pseudonymised data, the legal term for coded data, means names and other direct identifiers swapped for a code, with the key kept separately 5. In a SaaS product that covers event rows keyed on a user ID, support transcripts with the email removed and training sets with the account name replaced by a number. On these points the member states' draft matches how the GDPR is read today.

Is pseudonymised data personal data for a SaaS vendor that processes it for customers?

Yes, in the regulators' current reading and in the member states' text.

The European Data Protection Board (EDPB), where the EU's data protection regulators agree common positions, says in its draft anonymisation guidelines of July 2026 that information a company processes on a customer's behalf "should also be considered personal data for the processing entity" 6. Whether the data is personal depends on what the customer can identify. What the vendor can see does not decide it. Article 25a(4) of the member states' text would write that into the GDPR: data a processor handles for a controller is personal data for the processor, and the processor stays subject to the GDPR 1. No court has ruled on it yet.

So the data processing agreement, the security duties and the duty to tell the customer about a breach all stay, whatever the vendor can see. Reuse is covered too. A vendor that uses customer data for its own product analytics, or to train its own model, is a controller for that use. The data reached it as personal data, so the reuse needs its own legal basis. My co-founder Kenneth covered the EDPB guidelines in his post on anonymity being relative to who holds the data.

When is coded data not personal data, and what does the sender owe?

Coded data can fall outside the GDPR for a company that receives it for its own purposes and cannot identify anyone. It never does for the company that holds the key.

That rule comes from a 2025 judgment of the EU Court of Justice, EDPS v SRB 3. The Single Resolution Board (SRB), the EU agency that handles failing banks in the euro area, sent comments from shareholders and creditors of a failed Spanish bank to the consultancy Deloitte. Each comment carried a random code instead of its author's name, and only the Board could link a code to a person. The case was decided under the data protection rules for EU bodies, whose definition of personal data uses the same words as the GDPR's. The Court held three things:

• Coded data is not personal data "in all cases and for every person", because the code can stop anyone but the key-holder from identifying people.
• For the Board, which held the key, the comments stayed personal data.
• The Board had to name Deloitte as a recipient in its privacy notice when it collected the comments, whether or not the comments were personal data from Deloitte's side.

Article 25a(2) writes the first point down: pseudonymised data is not personal data for a third party unable to identify the person 1. The explanatory recital that goes with it sets the bar. A third party lacks the means to identify people if the risk "appears in reality to be insignificant", because identifying them would be impossible, would take disproportionate time, cost and labour, or is prohibited by law. Italy's regulator showed how strictly that is read today when it fined IQVIA 7 million euros for treating coded patient data as anonymous: a code that never changed tied each patient's history together.

For the sender, nothing changes. Sending coded data is processing of personal data for the company that holds the key, so it needs a legal basis, and the recipient goes in the privacy notice. Whether the partner can identify anyone only decides whether the GDPR applies to the partner as well. If the partner holds email addresses or device IDs it could match against the data, the Court's case law treats the data as personal for the partner too, and Article 25a(3) applies the same rule whenever coded data is passed on to someone able to identify people 1.

What did the member states change in the Digital Omnibus?

They kept the GDPR's definition of personal data as it is. The Commission had proposed adding sentences to Article 4(1), the definition, so that information would not be personal data for a company unable to identify the person behind it 2. The EDPB and the European Data Protection Supervisor, which oversees data protection at EU bodies, objected in a joint opinion of February 2026 that this went beyond the Court's case law 4. The privacy professionals' association IAPP reported in February that a leaked Council draft had already deleted the change, and the text agreed on 21 October leaves it out 1.

For each holder of coded data, here is whether the data counts as personal data for them under each text:

None of it is law yet. The text is the Council's mandate for negotiations with the European Parliament, which had not adopted its own position by 21 October, according to the Brussels news agency Agence Europe's report of that day's meeting.

What should you do if your product handles coded data?

If you build or run a product that receives customer data with the names replaced by codes, or sends such data to partners, here is what I would do.

• Search your security page, questionnaire answers and sales deck for "the GDPR does not apply". Delete any version that rests on only receiving coded or hashed data.
• List the places your product reuses customer data for your own purposes, such as analytics or model training, and give each one its own legal basis. You received that data as personal data, so the rule for outside companies that cannot identify anyone does not cover it.
• List every partner you send coded data to, and check that each one, or its category, is in the recipients section of your privacy notice. What the partner can see does not change that.
• Do not rewrite your DPA or privacy notice to cite Article 25a yet. Wait for the final text.

Lawcel is a tool that reads a team's pull requests and flags the ones that affect the team's legal documents. A pull request that starts sending coded data to a new partner is the kind of change it is built to catch, so the partner can be added to the privacy notice's list of recipients.