4 questions to ask your GDPR and CCPA attorneys

Imagine this — Last several years, your bank has been trying to integrate all bank accounts and link them with a common identifier — The CIN (wow — Customer Identification Number). Customers can now login with their CIN and view all their accounts in one fancy web and mobile interface.

Several man hours have been spent in planning and designing the solution. Some of you may have also taken steps towards implementing it. Your presentation to the Executive team is going well until someone asks the question, “What about GDPR?”

Ok, what about GDPR? what are you referring to?

If you have to be compliant with GDPR, you cannot persist the CIN. It is PII (Personally Identifiable Information)”

Now what? What do you say?

I am not a GDPR attorney and neither do I claim to have all the knowledge but my experience tells me that “most” folks who quote GDPR in board rooms and meetings have NOT read even a single clause. They throw GDPR and CCPA (California Consumer Privacy Act) out to stumble the presenter and show off their newly found wisdom.

Here are four smart questions that you may want to prepare yourself with:

  1. Whats the context?

First and foremost, both GDPR and CCPA have very broad range of what Personal Data means: Drivers License, Passport, SSN, Contact Address, Biometric Information (Face, Fingerprints, DNA etc), geo location, etc.

From the intent and usage of the CIN, it is certainly relatable to the customer in question. An important aspect though who is looking?

If a number such as “754-24–3333” is found on a piece of paper, what is it? Is it a customer account number , a Social Security Number or a phone number? Can’t say!

Unless the context is established i.e additional pieces of information is available, the number by itself does not become Sensitive in nature. i.e.

Bank name or Routing Number + CIN — this is clearly relatable information and needs to be handled with care both from insider and outside threat actors.

So asking a question, “If the CIN were an opaque value that is not derived from any PII attributes, is it still considered PII?” will get you some good responses (or none at all)

2. Does Pseudonymisation help?

Please read this carefully. There are two key words here that need to be mentioned:

GDPR Article 4(5) : ‘pseudonymisation’ means the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person;

CCPA is also has similar terminology for DeIdentification in 1798.140 (h):

Deidentified” means information that cannot reasonably identify, relate to, describe, be capable of being associated with, or be linked, directly or indirectly, to a particular consumer, provided that a business that uses deidentified information…

This means, and also according to GDPR Article 25 (1), that as long as there are “appropriate technical and organisational measures” implemented to turn Sensitive Data into non-sensitive information — i.e. translating information bits into “tokens”, then compliance can be met.

This is the same as Encryption? Apparently not — the pseudonymisation is achieved by replacing a random set of characters from Sensitive information such as Bank account numbers, Card numbers or in our case the CIN without altering the length of the strings and storing the original data in a secure cloud data vault. Detokenization can be done only by the original tokenization system.

If your organization implements a Tokenization solution such as Protegrity or TokenEx, your question would be “If a cloud assisted service is used for Tokenization will my solution be compliant?” (Think of an immutable data store such as a Blockchain to share your CIN with other banks for example)

3. Do I need explicit Consent?

Two more references in GDPR that require mention:

GDPR Article 5 (1a and 1b) : Personal data shall be:

  1. processed lawfully, fairly and in a transparent manner in relation to the data subject (‘lawfulness, fairness and transparency’);
  2. collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes; further processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes shall, in accordance with Article 89(1), not be considered to be incompatible with the initial purposes (‘purpose limitation’);

ooooo scary. This is a loaded one but genuinely requires legal help. The collection, creation and linking of your customer accounts into a new identifier has a specific purpose and that could be, lets say, to send one bank statement instead of 3 or let the customer log in and view all their accounts online.

Transparency and receiving customer consent is absolutely important and one that cannot be ignored. So your question may be, “If the legal text is displayed or sent to the customer and a checkbox capturing their consent is recorded, will the solution be compliant?”

4. How do I process Right to Erasure requests?

There obviously have been bad actors in software that have misused the trust customers have put in companies. Enterprises have harvested well-meaning personal information and changed the course of countries. It however offers a lot of challenges for product teams in terms of erasing information from all datastores, log files, etc. (please don’t tell me that you have golden sources and no duplication of data stores :))

GDPR Article 17 (3d): Paragraphs 1 and 2 shall not apply to the extent that processing is necessary:

d. for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes in accordance with Article 89(1) in so far as the right referred to in paragraph 1 is likely to render impossible or seriously impair the achievement of the objectives of that processing; or

What the clause here states is to put data relating to the customer “beyond use” or “inaccessible”. Most enterprises are legally obligated to prevent fraud and bad actors in the system. This means audit records may not be deleted just because a customer requested for such an action. Some Banks are mandated to keep transaction logs, audit information for 5–10 years. Dormant accounts are detected by may not be deleted.

Your question, “Do I treat audit records as archieved data and retain for the time period specified by my corporate Standards? Is there public interest involved?

This is actually a tricky one but one that every project team must ask their GDPR attorneys.

I am by no means an expert on the subject but it is good to pose questions and understand regulations. GDPR and CCPA compliance are very important and far too many times we choose to remain silent in meetings instead of understanding the mitigation steps. Hope this information helps folks!