The GDPR celebrates its first year and a half on Nov 25, 2019. It seems that the media is no longer making so much noise on the subject, but the law is still strong and the statistics continue to indicate that the data protection regulations are not under consideration on every company, we simply do not comply.
35 % of American companies still do not comply with the GDPR
According to the latest study by the consulting firm Capgemini, only 35% of American companies, as of June 2019, complies with the “not so new” regulation. Interestingly enough, 83% of them expected to comply a year earlier. Do we need to hear more news of the fines, sentenced to those who do not apply GDPR regulations, in the media to take the necessary measures? Do not worry, this text is not meant to be an opinion article 😉.
Some American companies believe that because GDPR applies to only Europeans, that they do not have to take action. However, if you have or are planning to have clients in Europe, it does apply.
The goal of this article is to address aspects that directly affect database administration by reviewing the most relevant GDPR Articles and giving an interpretation (and solutions) to justify compliance.
How to reduce the risk of exposure of sensitive information in your database and avoid fines
First, we will take a quick look at the most common examples of personal data that we need to protect against possible security breaches:
- Name, identity document, address, telephone number…
- Email account, information sent to social networks, IP address, cookies…
- Physical, psychological, medical, genetic information…
If you work with this type of information in production or development and test environments, I recommend you read this post until the end.
In the following, we highlight the articles directly related to the implications of a possible exposure of sensitive information due to security breaches:
- GDPR Art. 33
- GDPR Art. 34
As a summary, and referring to articles 33 and 34, organizations and companies are obliged to protect sensitive information and inform in case of security breach, both the competent authorities (i.e. to the Data Protection Agency if you are in Spain, and in less than 72h) and affected individuals if their data was exposed.
Would you be prepared to identify this gap and communicate it within the established timeframe? Have you thought about the impact – in terms of reputation – that communicating a security gap to your customers or suppliers could have? The negative implications of GDPR are not only economic amounts in fines if you do not comply with the regulations…
Fortunately, there are some interesting points in these two articles 😊:
“The communication to the data subject referred to in paragraph 1 shall not be required if any of the following conditions are met: (a) the controller has implemented appropriate technical and organisational protection measures, and those measures were applied to the personal data affected by the personal data breach, in particular those that render the personal data unintelligible to any person who is not authorised to access it, such as encryption.”
“The controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority competent in accordance with Article 55, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where the notification to the supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay.”
In other words, it is established that if our data is anonymized or encrypted and there is a security breach, we will not be obliged to notify those affected or the Supervisory Authority. This is because it is unintelligible to third parties and because such a breach of security does not constitute a risk to citizens’ rights and freedoms.
If our data is intelligible:
- We reduce the risk of sanctions
- We avoid the process of communicating contingencies to the Control Authority and to those potentially affected.
- Reduce the risk of exposure to criticism and cost in terms of corporate reputation
How can we make these sensitive data intelligible?
Through an obfuscation process.
An obfuscation process bases on a set of rules to mask certain information, depending on how sensitive such information is. It uses dictionaries to make the information look real in the event of a security breach.
For example, suppose we want to encrypt my name: Paula Garcia. Using an encryption key, something similar to “6ey9e Netzue” could appear in a “name” field, that is, something that does not look like a name and could show that we are using an encryption method.
Through an obfuscation process, the name would be associated with its equivalent in the dictionary, say, “Mariana Romero”. The values of obfuscated databases seem real.
Also, dictionaries are completely configurable.
When should we obfuscate?
In production environments, but also in development and test environments (because regulations also apply). It is a common process to work with real data when we are in test development phase in our database to check realistically if the functionality works as expected and covers scenarios in real time.
Cybercriminals have this aspect in mind and, and without realizing it, this testing environment can be an easy target (and a gateway) to personal data that should not be exposed.
If you find yourself in this situation, we recommend that you take action as soon as possible.
At SolidQ, we have developed a Database Obfuscator tool that allows you encrypt sensitive information in your cloud or on-premise database, using a series of rules to randomize the data in (configurable) dictionaries without compromising the performance of SQL.
¿Want to learn more about this service? Contact us and we´ll be happy to help.
Latest posts by Paula García Esteban (see all)
- GDPR implications and Database administration. Do you comply? - November 20, 2019