28 Op Der Haart L-9999 Wemperhardt Grand-Duché de Luxembourg

Software and GDPR be careful

I’ve one of my customer using a ERP, my customer told me if need to be compliant with this software.

So I not a DBA Architect specialist, I’m not also a code analyzer expert, so in this case just write to the publisher by this question :

Does your software use a particular technic to protect the personal data of my customers? (example encryption, pseudonymization)?
I ask you this question because my customer want to know if your application is in conformity with the arrival of the GDPR.

And what’s my surprise when I read his answer :

  1. He considering the GDPR as an framework for the company.
  2. It’s not a standard for dev.
  3.  and more.

So really, I think this person is a dev only that have create an application, so never understanding what’s GPDR, is not a framework but a new European law.

Here his answer (translated from french to english by google):

The GDPR framework seems to be more an organizational framework of the company than a standard on a software. It is therefore difficult to answer this question because it is up to the company to take the repository is ensured, according to its processes, that it has documented and implemented practices that guarantee the GDPR.

For example, the point « pseudonymization of personal data » is not a technical requirement. But a requirement on the fact that the company has documented in a code of conduct what it does to pseudonymize personal data, if a person concerned asks him to be no longer named.

For that, the answer can be that the user in the company, in case of request, replaces the name in base by a pseudo. However, this will rarely be done on an ERP because, on the other hand, the law also requires keeping track of customer details on invoices for tax control purposes.

The GDPR apply for very specific data cases and very very rarely, never see, to ERP data that is professional and non-personal data.

Possibly, there would be the date of birth on the contact which could enter this perimeter because not required by the tax legislation, and in this case, it is enough to decide not to feed it or to document that in case of request delete, the user will purge this information. It is up to the user, depending on their context, to decide which data is relevant or not and how they organize themselves to handle this.

To date, I do not see any incompatibility on the software but everything depends on the processes that have been implemented and that the company has documented to use this software. It is all the vagueness of the GDPR that does not define rules but the need to document the way of working that touches the theme of personal data.

here the original version :

Le référentiel RGPD semble etre plus un référentiel organisationnel de l’entreprise qu’un norme sur un logiciel. Il est donc difficile de répondre à cette question car c’est à l’entreprise de prendre le référentiel est s’assuré, selon ses processus, qu’elle a documenté et mis en ouvre des pratiques qui garantissent le RGPD.

Exemple, le point « la pseudonymisation des données à caractère personnel » n’est pas une exigence technique. Mais une exigence sur le fait que la société a documenté dans un code de conduite ce qu’il fait pour pseudonymiser des données personnelles, si une personne concernée lui demande de ne plus etre nommée. Pour cela, la réponse peut etre que l’utliisateur dans la société, en cas de demande, remplace le nom en base par un pseudo. Toutefois, ceci se fera rarement sur un ERP car, à contrario, la loi impose aussi de conserver traces des coordonnées clients sur les factures à des fins de control fiscal. Le RGPD s’appliquent pour des cas de données très spécifiques et très très rarement, voir jamais, aux données d’un ERP qui sont des données professionnelles et non personnelles. Eventuellement, il y aurait la date de naissance sur le contact qui pourrait rentrer dans ce périmètre car non exigé par la législation fiscale, et dans ce cas, il suffit de décider de ne pas l’alimenter ou de documenter qu’en cas de demande de suppression, l’utilisateur va purger cette information.  C’est à l’utilisateur, selon son contexte, de décider quelle donnée en relève ou pas et comment il s’organise pour gérer cela.

A ce jour, je ne vois pas d’incompatibilité sur le logiciel mais tout dépend des processus qu’à mis en oeuvre et qu’à documenté l’entreprise pour utiliser ce logiciel. C’est tout le flou du RGPD qui ne définit pas des règles mais le besoin de documenter la manière de travailler qui touche au theme des données personnelles.

Just to tell you, dear freelance, SMB, Start-Up, and other company, check the information about the software you use.
1. Asked which technique is or is being used to protect the data stored in this software.

2. If it has been reviewed or is undergoing revision so that it becomes default and design consistent with the needs of the GDPR.

3. If the application is a service, then also ask what are the security, level of the data center standard TIER, if they have certifications such as ISO27001 and when their last audit took place.

Do not forget that it is you who have chosen the use of a software so you need to have all certainties about this program, because in case of security breach you will be responsible too.


Articles associés