Logiciel conforme à la KVKK : commencer par l’inventaire des données

Les organisations viennent souvent nous voir en disant qu’elles veulent un logiciel conforme à la KVKK. Pour voir où cette conformité commence dans le code, il faut d’abord regarder l’inventaire, car sans savoir quelles données sont conservées et où, on ne peut définir correctement ni les règles d’accès ni les durées de conservation.

Lorsqu'on intervient dans une organisation pour une mise en conformité KVKK, on trouve généralement ceci. Une notice d'information, un formulaire de consentement exprès, une politique de conservation et de destruction. Les trois sont préparés, signés, classés.

On pose alors une seule question. D'où viennent les catégories de données mentionnées dans ces textes ?

La réponse est le plus souvent celle-ci. Un modèle trouvé sur internet a été repris, le nom de l'organisation y a été inscrit, quelques points ont été ajoutés. Autrement dit, la déclaration ne découle pas d'une vérification des faits, mais d'un modèle type. C'est l'erreur d'ordre la plus fréquente et la plus coûteuse que je constate dans les démarches de mise en conformité.

Pourquoi l'ordre compte autant

La notice d'information est une déclaration. L'article 10 de la loi exige que le responsable du traitement communique les catégories de données traitées, les finalités, les destinataires auxquels les données seront transférées et la base juridique. Si vous faites une déclaration, celle-ci doit être exacte.

Un texte rédigé sans inventaire ne peut pas être exact. Au mieux, il sera incomplet. Lorsqu'un audit détecte une activité de traitement absente du texte, il ne s'agit pas d'une simple lacune technique, mais du non-respect de l'obligation d'information de manière adéquate.

L'inverse est également vrai. Une organisation disposant déjà de l'inventaire rédige sa notice d'information en une journée, car tout ce qu'il y a à écrire est déjà établi.

Ce que l'on recherche réellement dans l'inventaire

Le tableau d'inventaire est généralement établi avec les colonnes catégorie de données, finalité et durée de conservation. Ces trois colonnes ne suffisent pas.

La colonne manquante est celle-ci. Où cette donnée se trouve-t-elle physiquement ? Dans quelle base de données, quelle table, quel champ ? Existe-t-elle aussi dans les sauvegardes ? Une copie existe-t-elle dans le système d'un prestataire tiers ?

Quand cette question n'est pas posée, l'inventaire reflète l'opinion que l'organisation a d'elle-même, et non la réalité. Lorsqu'une violation de données survient, la première question sera « quelles données personnelles se trouvaient sur ce serveur ». Un inventaire qui n'indique pas l'emplacement physique est inutile à ce moment-là.

Le choix de la base juridique est une décision architecturale

L'article 5 de la loi énumère les conditions de traitement. En pratique, cet article est souvent considéré comme une formalité, alors que la base juridique choisie détermine directement la manière dont le système doit être construit.

Dans une activité de traitement fondée sur le consentement exprès, celui-ci peut être retiré à tout moment. Dès son retrait, le traitement doit cesser. Cela impose trois choses au système. Un enregistrement indiquant à quelle version du texte le consentement a été donné, une interface offrant à l'utilisateur la possibilité de le retirer, et un contrôle qui arrête le traitement correspondant lorsque le consentement est retiré. Si l'un de ces trois éléments manque, s'appuyer sur le consentement place l'organisation dans une position indéfendable.

À l'inverse, un traitement nécessaire à l'exécution d'un contrat ne requiert pas ces mécanismes. La même donnée, traitée sur une base juridique différente, génère une charge technique complètement différente. C'est pourquoi le choix de la base juridique ne doit pas être fait par l'avocat seul, indépendamment de l'architecture.

La durée de conservation et le composant qui l'applique

Fixer une durée de conservation est la partie la plus facile du travail de mise en conformité. En assurer l'application est la partie la plus difficile.

Une conception qui fonctionne se présente ainsi. Chaque enregistrement porte sa propre durée de conservation, par exemple un champ « fin_conservation ». Un traitement automatisé parcourt régulièrement les enregistrements dont le délai a expiré. Ce traitement supprime, détruit ou anonymise l'enregistrement et consigne l'opération effectuée dans une table distincte. Ce qui est présenté lors d'un audit n'est pas le texte de la politique, mais cette table.

Les organisations qui ne mettent pas en place cette structure font généralement ceci. Elles inscrivent le délai dans la politique, reportent l'application à une date ultérieure, et cette date n'arrive jamais. Deux ans plus tard, on se retrouve avec des données non supprimées et un document indiquant qu'elles auraient dû l'être. La coexistence de ces deux éléments est pire que de n'avoir écrit aucune politique.

VERBİS et la question du périmètre

L'obligation d'inscription au Registre des responsables du traitement est soumise à des critères fixés par le Conseil. Le nombre annuel de salariés, la taille du bilan financier et la nature des données traitées sont déterminants.

Un avertissement s'impose ici. Le périmètre de l'exemption a évolué dans le temps par des décisions du Conseil et peut continuer à évoluer. Une organisation exemptée aujourd'hui devient assujettie lorsque son effectif augmente. C'est pourquoi l'exemption n'est pas une question à trancher une fois pour toutes et à oublier, elle doit être vérifiée chaque année. Pour les seuils actuels, il convient de consulter les communiqués publiés par l'Autorité.

Le plan de violation se rédige à l'avance

Le cinquième alinéa de l'article 12 de la loi exige que la violation soit notifiée au Conseil aussi rapidement que possible. Les décisions du Conseil ont concrétisé ce délai à soixante-douze heures.

Soixante-douze heures, c'est le temps total alloué, après détection de l'incident, pour déterminer son périmètre, identifier les personnes concernées et préparer la notification. Même la première de ces étapes prend des jours dans la plupart des organisations, car l'emplacement de chaque donnée n'est écrit nulle part.

Autrement dit, la préparation face à une violation commence bien avant celle-ci, et ramène toujours au même point. L'inventaire.

Que se passe-t-il quand la mise en conformité est terminée

Elle ne se termine pas. Une nouvelle fonctionnalité engendre un nouveau champ de données. Un nouveau prestataire engendre un nouveau transfert. Les décisions du Conseil resserrent le cadre.

C'est pourquoi il faut cesser de concevoir la conformité comme un projet et l'intégrer au sein même du processus de développement du produit. Si la mise à jour de l'inventaire lors de l'ajout d'un nouveau champ devient partie intégrante de la revue de code, le processus se maintient de lui-même. Sinon, on repart de zéro chaque année, et la même erreur d'ordre se répète à chaque fois.