gdpr data-protection security
Hiding order invoice information, GDPR
<p>I have a software where we can show order invoice information by typing in the order number and buyer email. Now the thing is that I need to hide the sensitive order information like:</p>

<pre><code>Name Surname
Address 11
Germany
</code></pre>

<p>as example I want to hide this data and show it as:</p>

<pre><code>N*** S******
A****** **
G******
</code></pre>

<p>I think that showing the exact number of letters and numbers by just replacing them with asterisks is not quite safe, but I want to make sure if it's not breaking the laws of GDPR.</p>

<p>The GDPR is wide in scope, and flexible in application. Therefore it is not possible to give an absolute yes/no as to whether masking text with asterisks is or is not lawful.</p>

<p>We can gain a deeper insight by looking at the GDPR itself. Firstly, the definition of <strong>processing</strong> (Art. 4 lit. 2):</p>

<blockquote>
  <p>any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction</p>
</blockquote>

<p>As <a href="https://law.stackexchange.com/questions/46652/hiding-order-invoice-information-gdpr#comment89702_46652">mentioned by amon</a>, the principles relating to processing of personal data (Art. 5) are highly relevant, insofar as the activity constitutes processing. In particular, <strong>purpose limitation</strong>:</p>

<blockquote>
  <p>[Personal data shall be] collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes</p>
</blockquote>

<p>...and <strong>data minimisation</strong>:</p>

<blockquote>
  <p>[Personal data shall be] adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed</p>
</blockquote>

<p>I would argue that <strong>making available</strong> the personal data on an invoice is processing. There are two separate operations:</p>

<ol>
<li>Making the data available to authenticated users; and</li>
<li>Making the data available to non-authenticated users</li>
</ol>

<p>The purpose of making it available to authenticated users may be different to the purpose of making it available to non-authenticated users. Again acknowledging <a href="http://amon" rel="nofollow noreferrer">amon</a>, the necessity of making the data available to non-authenticated users must be examined, as too must the means by which a non-authenticated user gains access to an invoice: are they using a URL that contains a token of some kind? Is this unique in some way? It could be that the presentation of a token itself constitutes authentication and thus authorisation to view the entire invoice, in which case further redaction may not be necessary if there is a clear necessity to disclose the entire contents to such a user. Whether the token expires or is limited to a certain referrer would be part of complying with the <strong>integrity and confidentiality</strong> principle and Art. 32 (Security of processing) by implementation of technical measures.</p>

<p>When considering pseudonymisation and anonymisation, you will note that the redaction of name and address data from a certain view of the invoice, while nevertheless displaying the invoice number, constitutes pseudonymisation, since it would be possible with unfettered access to the remaining data, to determine the name and address from the invoice number, but not for the non-authenticated user whose view is redacted. In such a case, I fail to see how or why the replacement of a string with the same number of asterisks, or starting with the real character is secure or even practical, when the entire field could simply be replaced with a fixed-width string of asterisks or other filler, thus providing the user with no right or necessity to view the personal data with no further insight into what the personal data may or may not be.</p>
