gdpr
Email and Name Data Pseudonymize
<p>As per GDPR, we need to pseudonymize the name and email address. How can we pseudonymize name and email address?  For example, is the below is correct way to pseudonymize?</p>
<blockquote>
<p>Steve Anderson
Stxxx Axxdxrxn</p>
<p>test@testdomain.com
txxx@xxxxxxxxxx.com</p>
</blockquote>
<p>Is the above definition of pseudonymize is correct? Or we can reduce or increase the number of characters like,</p>
<blockquote>
<p>Steve Anderson
Sxxx xxxrxn</p>
</blockquote>
<p>I want to implement this in my code but don't now how can I implement pseudonymized Name and Email properly.</p>

<p>The GDPR does not prescribe how information should be pseudonymized and does not even define the term properly. Yet, pseudonymization is suggested as an safety measure in various places, so that pseudonymization should be implemented wherever appropriate.</p>
<p>The most useful guidance the GDPR gives is by contrasting pseudonymization with anonymization, where it says that pseudonymized data is still personal data because the data subjects can be identified using additional information (see <a href="https://gdpr-info.eu/recitals/no-26/" rel="nofollow noreferrer">Recital 26 GDPR</a>). In contrast, re-identification is not reasonably likely for truly anonymized data.</p>
<p>A common technique for pseudonymization is to replace identifying information with a pseudonym, for example replacing a name with a random numeric ID. However, this can only be considered pseudonymous if the mapping between the ID and the real value is not available to whoever uses this data.</p>
<p>Replacing individual fields in a data set might not be sufficient for pseudonymization because apparently non-sensitive fields could still enable indirect identification. This requires careful analysis taking into account the entire context of the data, so it isn't possible to say whether merely removing names + email addresses achieves pseudonymization or anonymization.</p>
<p>What you are doing is redacting <em>parts</em> of sensitive data. I think this is a pretty weak pseudonymization method since it still leaks partial information about the true value, and leaks information about the length of the redacted value. It is possible to argue that this is OK (e.g. if you can show that you have multiple similar redactions so that you achieve a level of k-anonymity). But by default, such partial redactions are likely to be unsafe. Completely removing the sensitive data is much safer.</p>
<p>The “Article 29 Working Party”, a pre-GDPR EU body, has published an <a href="https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf" rel="nofollow noreferrer">opinion on anonymization techniques in 2014 (PDF)</a>. It does not account for the GDPR's specific phrasing, but provides an overview of pseudonymization and anonymization techniques and puts them into context of European data protection law. It considers how such guarantees guard against attacks such as singling out data subjects, linking multiple records of the same individual, and making inferences about the data subject.</p>
<p>In this guidance, pseudonymization techniques that are suggested include encrypting or hashing the sensitive data. However, the guidance warns that such techniques do not provide strong protection against singling out or linking records of the data subject.</p>
<p>A bit earlier, the <a href="https://ico.org.uk/media/for-organisations/documents/1061/anonymisation-code.pdf" rel="nofollow noreferrer">UK ICO had published guidance on personal data, including on the matter of anonymization and pseudonymization (PDF)</a> with some good examples. For determining whether a data set has been successfully anonymized (or pseudonymized), they suggest a motivated intruder test: could someone without specialist knowledge or skills re-identify the data subject? In your example, such a person should not be able to infer that a record about <code>Stxxx Axxdxrxn</code> is about a <code>Steve Anderson</code>. In my opinion, your pseudonymization approach would fail the motivated intruder test unless you have multiple records that could all be about Steve Anderson (compare k-anonymity).</p>

<p>First of all, the GDPR doe not require you to pseudonymize  anything. It requires that &quot;appropriate&quot; security measures be used. It also required that when Personal Data (which I shall call PI) is processed (which includes storing PI) that there be a lawful basis, as described in GDPR <a href="https://gdpr-info.eu/art-6-gdpr/" rel="nofollow noreferrer">Article 6</a>. The person's consent is one of the six possible lawful bases.</p>
<p>Second, while using pseudonymous data may be a good security practice, and is recommended by the GDPR, such data is still PI (and often PII, Personally Identifiable Information) and still requires a lawful basis for any processing. PI also requires that the Data Subject (DS) be notified when it is collected (<a href="https://gdpr-info.eu/art-13-gdpr/" rel="nofollow noreferrer">Article 13</a> and <a href="https://gdpr-info.eu/art-14-gdpr/" rel="nofollow noreferrer">Article 14</a>, and that the DS has the &quot;right to Know&quot; (<a href="https://gdpr-info.eu/art-15-gdpr/" rel="nofollow noreferrer">Article 15</a>), &quot;right to modify&quot; (<a href="https://gdpr-info.eu/art-16-gdpr/" rel="nofollow noreferrer">Article 16</a>), and &quot;right of erasure&quot; (<a href="https://gdpr-info.eu/art-17-gdpr/" rel="nofollow noreferrer">Article 17</a>), and proper security must still be used on pseudonymized PI.</p>
<p>To convert PI into something that is not PI, where these rights and requirements do not apply, the data must be so modified that it is not reasonably possible, given current technology, to re-associate the modified data with the person that they represent, either directly or with the assistance of other data held by others than the Data Controller (DC). It must also not be possible to &quot;single out&quot; the DS.  That is, if you suspect that the DS is a specific person X, it must not be possible to confirm this using the modified data. A hash, for instance, is not good enough, because if you suspect a particular person, you can hash that person's info and compare, and if you are correct there will be a match. If you can eliminate many of the possible suspects, leaving a much smaller pool, that is also singling-out, and means that the data has not been successfully anonymized. Data so modified is said to be anonymized, not just pseudonymous. Data that has been successfully anonymized is not subject to the security or notification requirements of the GDPR.</p>
<p>The GDPR does not specify any particular methods that may be used to anonymize PI. Certainly anything that leaves a recognizable name in the modified data is not good enough. Even recognizable initials would mean that the modified data has not been anonymized. Because that would allow someone the drastically limit which of a group of suspected people the PI belongs to. That is &quot;singling out&quot;.</p>
<p>It should be assumed that an attacker knows any and all algorithms used to anonymize data, and if the attacker can re-identify or single-out the DS with this knowledge, plus other potentially available information, then the data has not been successfully anonymized.</p>
<p>To judge if an algorithm successfully anonymizes data, one would need the details of the algorithm, and an idea of other information which might be available to use in re-identifying the data.  To anonymize data is not a simple or trivial task, and any DC who depends on it must be prepared to demonstrate that there is no reasonable way to re-identify or single out the DS from the anonymized data,</p>
<p>Nor does the GDPR ever require anonymization. If the DC abides by the requirements in handling PI and PII, there is no need for it at all.</p>
