Concevoir des systèmes métier conformes aux exigences de protection des données

La loi sur la protection des données personnelles B.E. 2562 (2019) s’applique aux organisations qui collectent, utilisent ou communiquent des données personnelles de personnes se trouvant en Thaïlande. Elle distingue le responsable du traitement, qui décide pourquoi et comment les données sont traitées, du sous-traitant, qui les traite pour le compte du responsable du traitement ; son application est supervisée par le Personal Data Protection Committee (PDPC). La loi définit les bases légales du traitement, les droits des personnes concernées, les obligations de sécurité, les obligations de tenue de registres et une obligation de notification des violations.

Ce guide est fourni à titre informatif et ne constitue pas un conseil juridique. La loi, ses textes d’application et les lignes directrices du PDPC évoluent ; votre délégué à la protection des données ou votre conseil juridique doit confirmer la manière dont ils s’appliquent à votre organisation. Ce qui suit relève du point de vue de l’ingénierie : lorsque la loi exige que l’organisation soit en mesure de faire quelque chose, ce guide décrit ce dont le système a besoin pour le faire.

Lorsque le consentement est la base légale, le système doit pouvoir démontrer qu’une personne donnée a accepté une utilisation donnée, selon une formulation donnée, à un moment donné, et de quelle manière. Enregistrez une preuve de consentement comportant l’identifiant de la personne concernée, la finalité, la version de la notice ou du texte de consentement qu’elle a vue, l’horodatage, le canal (formulaire web, application, papier numérisé, appel) et tout élément de preuve tel que l’identifiant du formulaire. Conservez chaque version du texte de consentement ; un enregistrement qui renvoie à un texte réécrit depuis ne prouve rien.

Le retrait doit être aussi simple que le consentement et prendre effet dans tous les systèmes qui s’en sont servis. Concevez le consentement comme un état central que les systèmes en aval (une plateforme marketing, un outil d’envoi de newsletter, une chaîne d’analyse) consultent au moment de l’utilisation, plutôt que comme un indicateur copié une fois puis oublié. La newsletter de notre propre site web en est un petit exemple : double opt-in par e-mail, lien de désinscription dans chaque message et liste d’exclusion appliquée avant l’envoi.

Le consentement n’est pas la base appropriée pour tout. Le traitement des données d’un salarié pour la paie ou de celles d’un client pour livrer un achat repose sur le contrat ou sur une obligation légale ; demander le consentement dans ces cas crée un droit de retrait que l’organisation ne peut pas honorer. Lorsque la base légale est choisie avec justesse, les enregistrements de consentement deviennent moins nombreux et plus significatifs.

La loi impose des mesures de sécurité appropriées. Au niveau du système, cela commence par le principe du moindre privilège : un accès par rôle dans lequel chaque rôle voit les champs nécessaires à son travail, et rien de plus. Un modèle Propriétaire/Administrateur/Membre/Lecteur constitue une base solide pour un espace de travail ; les applications métier exigent généralement des rôles plus fins, afin qu’un préparateur d’entrepôt voie les adresses de livraison mais pas les numéros d’identité nationale, et qu’un agent du support voie les quatre derniers chiffres d’une carte mais jamais le numéro complet. Le masquage au niveau des champs, appliqué dans la couche API afin qu’aucun client ne puisse le contourner, vaut l’effort pour les champs personnels et sensibles.

La minimisation s’applique dès la collecte et à chaque copie. Ne collectez que les champs nécessaires à une finalité ; ne copiez pas les données personnelles de production dans les environnements de test et de développement, mais générez ou anonymisez plutôt des données de test ; réservez les exports et les téléchargements en masse aux rôles qui en ont besoin et journalisez chacun d’eux. Une authentification forte protège l’ensemble : authentification unique (SSO) avec le fournisseur d’identité de l’organisation, authentification à deux facteurs (2FA), clés d’accès (passkeys) lorsqu’elles sont prises en charge, et délais d’expiration de session proportionnés à la sensibilité des données.

Les sous-traitants auxquels l’organisation fait appel (hébergement, e-mail, analyse, services d’IA) doivent être liés par des contrats qui leur imposent les mêmes exigences, et l’architecture doit faire apparaître clairement quelles données personnelles sont transmises à chacun.

Les données personnelles ne peuvent être conservées que le temps nécessaire à la finalité ou exigé par la loi. Traduisez ce principe en un calendrier de conservation par catégorie de données, avec une durée et une justification juridique ou métier : les pièces comptables pendant la durée imposée par la législation fiscale, les données des candidats pendant une période définie après la décision, les comptes clients inactifs au-delà d’une période d’inactivité définie, les transcriptions des échanges avec le support au-delà d’un délai défini. Automatisez ensuite ce calendrier. Une politique de conservation qui dépend d’une personne exécutant un script une fois par an ne constitue pas un contrôle.

Déterminez le fonctionnement technique de la suppression. La suppression logique rend les données invisibles mais les conserve ; elle n’est acceptable que comme bref délai de grâce avant une suppression définitive ou une anonymisation. L’anonymisation, qui supprime ou transforme de manière irréversible les identifiants tout en préservant les statistiques, permet à l’organisation de conserver l’historique de son activité sans conserver les personnes. Les sauvegardes appellent le même traitement : définissez leur durée de vie, vérifiez qu’elles sont chiffrées et veillez à ce que les données restaurées soient soumises aux suppressions intervenues après la sauvegarde.

Les personnes concernées peuvent demander quelles données l’organisation détient à leur sujet, en demander une copie ou la rectification, en demander l’effacement, s’opposer au traitement ou en demander la limitation, et retirer leur consentement ; le responsable du traitement doit donner suite dans le délai fixé par la loi et ses textes d’application. Le système doit permettre à un membre du personnel formé de traiter ces demandes sans l’aide de l’équipe technique : retrouver tous les enregistrements d’une personne dans l’ensemble des modules, produire un export lisible de ses données personnelles, corriger un champ avec une entrée d’audit, et procéder à la suppression ou à l’anonymisation dans le respect des règles de conservation applicables (une facture ne peut pas être supprimée parce que le client a demandé l’effacement ; elle peut être conservée avec une base légale enregistrée).

Tenez un registre des demandes : qui a fait la demande, quand, comment l’identité a été vérifiée, ce qui a été fait et à quelle date la demande a été traitée. Ce registre démontre la conformité et met en évidence les processus trop lents.

Un journal d’audit enregistre qui a fait quoi, sur quelles données et quand : connexions, modifications d’autorisations, consultations et exports de données personnelles, modifications et suppressions, changements de configuration. Il doit être écrit par l’application au moment de l’action, stocké séparément des données métier avec un accès en écriture restreint, et conservé pendant une durée fixée délibérément. Des journaux qui se trouvent dans la même base de données, sous la responsabilité des mêmes administrateurs, n’offrent aucune protection contre une menace interne.

Les journaux doivent être utiles, et pas seulement présents : consultables par personne et par enregistrement, examinés selon un calendrier défini, avec des alertes sur les comportements inhabituels tels que les exports en masse ou les accès en dehors des heures de travail. Les journaux d’audit contiennent eux-mêmes des données personnelles et doivent figurer dans le calendrier de conservation.

La loi impose au responsable du traitement de notifier au PDPC toute violation de données personnelles dans les meilleurs délais et, si possible, dans les 72 heures après en avoir pris connaissance, sauf si la violation n’est pas susceptible d’engendrer un risque pour les droits et libertés ; lorsque le risque est élevé, les personnes concernées doivent également être informées. Soixante-douze heures passent vite. Côté système, être prêt signifie savoir détecter, c’est-à-dire disposer d’une journalisation et d’une supervision capables de révéler un accès non autorisé, et pouvoir établir rapidement quelles données ont été touchées, concernant qui et sur quelle période.

Côté organisation, il faut une procédure d’incident écrite : qui est prévenu en premier, qui évalue le risque, qui rédige la notification, qui s’adresse aux clients, avec des modèles préparés à l’avance dans chaque langue de travail de l’organisation. Organisez chaque année un exercice sur table fondé sur un scénario réaliste, afin que la première utilisation du runbook n’ait pas lieu pendant une violation réelle.