Under the GDPR, is a table of SHA-256-hashed email addresses handed to an ad partner still personal data?
answer
- identifiable, not only identified
- same input, same hash
- means reasonably likely to be used
- Recital 26 and Art. 4(5)
basics
~20 sYes. A hashed email is a stable identifier that anyone holding the address can recompute and match, so under the GDPR it is pseudonymised data, which Recital 26 treats as personal data. Only data rendered anonymous leave the Regulation's scope.
solid answer
~50 sYes. Under the GDPR, personal data is any information relating to an *identified or identifiable* natural person (`Art. 4(1)`), and Recital 26 says pseudonymised data that could be attributed to a person with additional information stay personal data. An unsalted SHA-256 of an email is deterministic: the ad partner hashes the addresses it already holds and joins on the result, which is exactly the identification the hash was supposed to prevent. Recital 26 judges identifiability by the means reasonably likely to be used *by the controller or by another person*, so the partner's own email list counts. Pseudonymisation is a recognised safeguard (`Art. 25(1)`, `Art. 32(1)(a)`), but it does not take the table out of scope: handing it over is still processing of personal data, with every obligation that brings. Only data rendered anonymous, where no one can reasonably re-identify the person, fall outside the Regulation.
go deeper
Recall that personal data covers identifiable people, not only named ones, and that Recital 26 keeps pseudonymised data inside the GDPR. Hashed emails are the textbook example.
Explain why a deterministic hash is linkable: the recipient recomputes it from addresses it holds. Cite Art. 4(1), Art. 4(5) and the Recital 26 means-reasonably-likely test.
Apply the Recital 26 test from every holder's side, and show you know pseudonymisation earns credit as a safeguard under Arts. 25 and 32 without changing scope.
Frame data-sharing designs around the assumption that pseudonymised outputs stay personal data, so anonymity claims are reserved for cases that survive the Recital 26 test against anyone's means.
## What the GDPR means by personal data The GDPR (Regulation (EU) 2016/679) applies to **personal data**, which `Art. 4(1)` defines as *any information relating to an identified or identifiable natural person*. The second half of that definition carries most of the weight: a person is **identifiable** when they can be identified *directly or indirectly*, in particular by reference to an identifier such as a name, an identification number, location data or **an online identifier**. Two consequences follow for anyone building data systems: - A record does not need a name in it to be personal data. A customer ID, a device ID or an email hash that points at one person is an identifier. - Recital 30 names internet protocol addresses and cookie identifiers as online identifiers that, combined with other information, can be used to profile and identify people. ## Pseudonymised is not anonymous `Art. 4(5)` defines **pseudonymisation** as processing personal data so that they can no longer be attributed to a specific data subject *without the use of additional information*, provided that: 1. the additional information (a lookup table, a key, a salt) is **kept separately**, and 2. it is protected by technical and organisational measures that stop anyone attributing the data to a person. Recital 26 then settles the legal status: personal data which have undergone pseudonymisation and *could be attributed to a natural person by the use of additional information* should be considered information on an identifiable person. Pseudonymised data are **still personal data**. Only **anonymous information**, meaning data that do not relate to an identifiable person or have been rendered anonymous so that the person is *not or no longer identifiable*, sit outside the Regulation. | Status | Can the person be re-identified? | Is the GDPR engaged? | |---|---|---| | Identified (name, email in clear) | Directly | Yes | | Pseudonymised (hash, token, internal ID) | Yes, with additional information someone holds | Yes: still personal data (Recital 26) | | Anonymous | Not by any means reasonably likely to be used | No: Recital 26 excludes it | ## Why a hashed email fails the anonymity test Recital 26 sets the test: account should be taken of **all the means reasonably likely to be used**, *such as singling out*, **either by the controller or by another person**, weighing objective factors such as cost, time and the technology available. Apply it to a table of SHA-256 email hashes handed to an ad partner: - **Hashing is deterministic.** The same address always produces the same digest, so anyone who holds the address can recompute the hash and look it up. No reversal of the function is needed. - **The recipient holds the additional information.** An ad partner already has its own users' email addresses. Hashing them and joining is a cheap, routine operation, well within "reasonably likely". - **The purpose of the handoff is matching.** The table is shared precisely so that rows can be tied to known people. Data whose entire use is to single out and target individuals cannot plausibly be called anonymous. - **Salting inside the sender does not change the sender's position.** If the sender adds a secret salt or key, the sender still holds the additional information, so for the sender the data remain pseudonymised personal data. Because the email address itself is the "additional information", and anyone who knows the address can use it, an unsalted email hash is arguably weaker than the Art. 4(5) model, which assumes that the additional information is kept separately under protective measures. ## What pseudonymisation does change Pseudonymisation is not legally meaningless. The Regulation rewards it as a **safeguard**: - `Art. 25(1)` names pseudonymisation as an example of data protection by design. - `Art. 32(1)(a)` lists pseudonymisation and encryption among appropriate security measures. - `Art. 89(1)` names it among the safeguards for research and statistical processing. - Recital 28 says it can reduce the risks to the data subjects and help controllers and processors meet their obligations. What it does **not** do is remove the data from scope. Sharing the hashed table is still *processing* in the `Art. 4(2)` sense ("disclosure by transmission, dissemination or otherwise making available"), so everything the Regulation requires for a disclosure of personal data still applies. Which lawful basis could carry it is a separate question. ## How to answer this in an interview 1. Start from `Art. 4(1)`: identifiable, not only identified. 2. Name the status: pseudonymised under `Art. 4(5)`, still personal data under Recital 26. 3. Apply the Recital 26 test from the recipient's side: the partner holds the emails, so re-identification is trivially likely. 4. Credit the safeguard (`Art. 25`, `Art. 32`) without claiming it changes scope. 5. Note that anonymity is a high bar, judged against the means of *anyone* reasonably likely to try, and reassessed as technology develops.
- Under the GDPR, if the sender hashes with a secret key it never shares, is the partner's copy anonymous?Not for the sender, which holds the key and therefore the additional information `Art. 4(5)` describes. For the partner, Recital 26 asks whether it has means reasonably likely to re-identify; without the key, direct matching fails. But the whole point of the handoff is matching, so a secret key defeats the use case, and whether the partner's copy is personal data in its hands remains a judgement, not an automatic result.
- Under the GDPR, is an IP address or a cookie ID personal data?Usually, yes. `Art. 4(1)` lists an online identifier among the ways a person becomes identifiable, and Recital 30 names IP addresses and cookie identifiers as identifiers that, combined with other information, can be used to profile and identify people. Where the identifier can be linked to a person, as it typically can in a tracking context, it is personal data.
- Under the GDPR, when does a dataset count as anonymous, and is that status permanent?Under Recital 26, when the person is not or no longer identifiable by any means reasonably likely to be used, by the controller or anyone else, including singling out, weighed against cost, time and available technology. The recital also points to technological developments, so the assessment is not fixed: data that were anonymous against yesterday's means can become identifiable again.
A hashed email is like a cloakroom ticket: it hides the coat's owner from a passer-by, but anyone holding the matching stub can walk straight to it. The GDPR asks who holds stubs, not whether the ticket shows a name.
saying these in an interview costs you the question
- SHA-256 is one-way, so hashed emails are anonymous data.
- Data are anonymous as long as our own company cannot re-identify them.
- Pseudonymised data fall outside the GDPR once the key is stored separately.
- Only names and contact details are personal data, not internal IDs or device identifiers.
- Adding a secret salt makes the hash anonymous for the sender too.