Réponse succincte
Gestion des versions et Audit-Les « traces » sont importantes dans les logiciels de protection des données, car les organisations doivent non seulement connaître l'état actuel d'une Traitement, une Analyse d'impact relative à la protection des données ou d'une validation, il faut également documenter de manière traçable leur genèse. Il est donc essentiel de savoir quelle version était en vigueur à quel moment, qui a apporté une modification, pour quelle raison celle-ci était nécessaire, qui a vérifié ou validé la modification, et quelles informations étaient disponibles au moment de la vérification ou de la décision.
Un AuditDans ce contexte, l’historique n’est pas une simple fonctionnalité technique supplémentaire. Il permet d’apporter des réponses à des questions essentielles en matière de gestion et de gouvernance : quelles étaient les règles en vigueur à un moment donné ? Qui a pris la décision ? Quels contenus ont été modifiés ? Pour quelle raison cette modification a-t-elle été effectuée ? Quels étaient les risques connus et quelle était la situation documentée au moment d’un audit ?
Traçabilité de l'état de la protection des données tel qu'il est documenté
Dans les projets liés à la protection des données, ce sont généralement les exigences de fond qui occupent le devant de la scène. Il convient par exemple de vérifier si le Répertoire des activités de traitement est complète, que les mesures techniques et organisationnelles ont été décrites de manière suffisante, qu'une Analyse d'impact relative à la protection des données a été menée à bien ou que l'évaluation d'un prestataire de services s'est déroulée conformément aux règles. Il en va de même pour la mise en œuvre des mesures et la validation des cas d'utilisation de l'IA.
Pour évaluer la fiabilité de ces informations, il convient toutefois de tenir compte de la manière dont les données actuelles ont été obtenues. À cet égard, les questions suivantes se posent notamment :
- Qui a une Traitement modifié ?
- Quand une nouvelle catégorie de données a-t-elle été ajoutée ?
- Pour quelle raison le délai de suppression a-t-il été modifié ?
- Qui a décidé qu'il n'y avait pas de Analyse d'impact relative à la protection des données est-ce nécessaire ?
- Quelle version était en vigueur au moment d'un contrôle ?
- Quelle était la recommandation du délégué à la protection des données à ce moment-là ?
- Une modification a-t-elle été vérifiée ou simplement enregistrée par-dessus l'enregistrement existant ?
En l'absence d'informations correspondantes, cela concerne la Documentation tout comme la gouvernance. Une situation qui semble plausible aujourd’hui ne présente qu’une fiabilité limitée à des fins de contrôle et de reddition de comptes si l’on ne peut pas retracer sur quel contrôle, quelle décision ou quelle autorisation elle repose.
La piste d'audit en tant qu'outil de pilotage organisationnel
Le terme AuditLe terme « trail » est souvent associé aux fichiers journaux, aux horodatages, à l'historique des bases de données ou à l'administration du système. Or, dans le cadre de la gestion de la protection des données, une telle approche purement technique s'avère insuffisante.
Un programme conçu de manière professionnelle Audit-La traçabilité permet de vérifier si une organisation prend ses décisions de manière transparente, met en œuvre les changements de manière contrôlée et est en mesure d'expliquer ultérieurement comment un certain niveau de protection des données a été atteint. Elle constitue ainsi également un outil de pilotage organisationnel.
Cela est étroitement lié au principe de responsabilité. Le Comité européen de la protection des données décrit Responsabilité éthique sous la RGPD en tant qu’obligation pour le responsable du traitement de veiller au respect des exigences en matière de protection des données et d’être en mesure d’en apporter la preuve. Dans la pratique, cela implique notamment une Documentation des pratiques en matière de protection des données et des décisions qui les sous-tendent.[1]
Le site AuditDans ce contexte, le « trail » sert de trace traçable d'une modification ou d'une décision. Sa valeur ne réside pas uniquement dans l'enregistrement technique, mais aussi dans la classification technique de l'opération documentée.
Les limites d'un simple instantané
De nombreux systèmes n'affichent que l'enregistrement actuel. On peut par exemple voir l'objet actuel d'une Traitement, les catégories de données, les destinataires et les délais de suppression actuellement répertoriés, ainsi que le responsable et le statut de traitement.
Ces informations sont obligatoires, mais elles ne suffisent généralement pas pour garantir la traçabilité ultérieure.
Si, dans un Répertoire des activités de traitement Si un délai de suppression de six mois est aujourd'hui enregistré, alors qu'il y a un an, un délai de trois ans y était encore consigné, la question se pose dans un Audit Il ne s'agit pas seulement de la question du délai actuellement en vigueur. Il convient également de déterminer pourquoi ce délai a été modifié, qui a examiné cette modification, si celle-ci repose sur une analyse juridique, une nouvelle directive interne, une constatation issue d'un audit ou un changement de système, et si cette modification a été appliquée à toutes les variantes concernées.
Il en va de même pour un cas d'utilisation de l'IA. Si celui-ci est actuellement validé, alors qu’il était encore en cours d’examen trois mois auparavant, il doit rester possible de retracer quelle évaluation des risques a servi de base à cette validation, quelles données étaient décrites à cette date, quelle version de la « Model Card » était en vigueur et si la validation était assortie de conditions. Des modifications ultérieures concernant le fournisseur, la finalité ou l’étendue des données peuvent nécessiter une nouvelle évaluation technique.
L'ensemble de données actuel reflète le résultat. Gestion des versions et Audit-Le « trail » retrace le parcours des modifications et des décisions associées.
Article 30 du RGPD et l'évolution des activités de traitement
Le site Répertoire des activités de traitement n'est pas un ensemble de données quelconque. Art. 30 RGPD exige notamment des informations sur les finalités de la Traitement, concernant les catégories de personnes concernées et de données à caractère personnel, les destinataires, les transferts vers des pays tiers, les délais de suppression ainsi que les mesures techniques et organisationnelles. Le registre doit être tenu par écrit, y compris sous forme électronique, et être mis à la disposition de l’autorité compétente autorité de contrôle à fournir sur demande.[2]
Dans la pratique, il convient donc de s'assurer dans un premier temps que les informations requises sont complètes et à jour. Pour mettre en place un dispositif de protection des données fiable, il est également important de pouvoir retracer l'évolution de ces données au fil du temps.
Les activités de traitement font régulièrement l'objet de modifications. Les systèmes sont remplacés, les prestataires changent, les finalités sont élargies, de nouvelles catégories de données sont ajoutées et les délais de suppression sont adaptés. Les responsabilités, les transferts internationaux, les évaluations des risques et les mesures techniques ou organisationnelles peuvent également évoluer.
Si le répertoire ne présente que l'état actuel, l'organisation se trouve privée d'une partie essentielle des informations nécessaires à la vérification et au pilotage.
Éléments constitutifs d'un justificatif de modification fiable
Une modification enregistrée ne peut pas être assimilée d'emblée à une preuve de modification fiable. Pour garantir la traçabilité technique, il convient de regrouper plusieurs informations.
Objet de la modification
Il convient de consigner la valeur précédente et la nouvelle valeur, ainsi que le concernés Champ ainsi que l'objet de gouvernance associé.
Personne ou rôle en évolution
Il faut pouvoir identifier le personnage, son rôle et les concernés Unité organisationnelle. Si une modification intervient dans le cadre d'un remplacement, il convient également d'en tenir compte.
Date et version
Il faut indiquer la date de la modification, ainsi que la concernés La version ainsi que le statut avant et après le traitement.
Motif et justification
La raison de la modification peut résulter, par exemple, d'un ticket, d'une constatation d'audit, d'une nouvelle appréciation juridique, d'une modification des processus ou du système, ou encore d'un changement de prestataire.
Examen
Il convient de pouvoir vérifier si la modification a été examinée par le délégué à la protection des données, le service juridique, le service de sécurité informatique, le service compétent, la direction ou d'autres réviseurs.
Validation
Lorsqu'une autorisation est nécessaire, il convient de consigner par écrit le nom de la personne qui l'a délivrée, la date, le champ d'application et les conditions éventuelles.
Pièces justificatives correspondantes
Il peut s'agir notamment d'évaluations, de décisions, d'e-mails, de procès-verbaux, de mesures, d'acceptations de risques ou de constatations d'audit.
Conséquences de la modification
Il convient de tenir compte des éléments suivants : concernés Variantes, sociétés locales, risques, mesures, rapports et délais.
Si seules les modifications apportées au système sont consignées, sans que ces informations techniques ne soient prises en compte, la preuve reste généralement incomplète. Seule la mise en relation du contenu de la modification, de la responsabilité, du motif, de la vérification et de l'impact permet une classification fiable.
Exigences techniques relatives à la gestion des versions
La gestion des versions est souvent réduite à la simple conservation d'une ancienne version et à l'enregistrement d'une nouvelle version. Cette fonctionnalité technique est certes nécessaire, mais elle ne répond pas encore pleinement aux exigences métier en matière de gestion de la protection des données et de la gouvernance.
Une version peut avoir différentes significations. Elle peut être à l'état de brouillon, soumise pour vérification, vérifiée, validée, historiquement valide, remplacée ou archivée. Il doit être possible de distinguer ces différents statuts les uns des autres.
Un projet ne doit pas ressembler à une version validée Traitement être traitée. Une version antérieure peut être utilisée pour un Audit continuer à être pertinente, même si elle n’est plus applicable sur le plan opérationnel. Une version validée ne doit pas être remplacée sans un processus de modification justifié. Il convient également de vérifier si une modification apportée après validation doit donner lieu à une nouvelle révision. Dans le cas des variantes locales, il peut en outre être pertinent de savoir sur quelle version d’une norme de niveau supérieur elles se fondent.
La gestion des versions devrait donc être associée au statut, à la validité, à la vérification et à la validation.
Traçabilité temporelle
Lors d'audits, en cas d'incidents et dans le cadre de décisions de direction, ce n'est souvent pas la situation actuelle qui prévaut, mais celle qui prévalait à un moment donné.
Dans ce contexte, les questions suivantes, entre autres, peuvent s'avérer pertinentes :
- Quelles informations ont été consignées le jour de l'incident ?
- Quelle était la version en vigueur au moment de la validation ?
- Quelles mesures étaient encore en cours à la date de l'audit ?
- Quelle mesure était déjà en retard à ce moment-là ?
- Quelle était la base juridique mentionnée lorsque la Traitement a été enregistré ?
- Quel était le délai de suppression applicable lors de la collecte des données ?
- Sur quelle évaluation la direction s'est-elle appuyée pour prendre sa décision ?
Un système qui se contente de refléter la situation actuelle ne peut généralement apporter que des réponses limitées à ces questions. Un système de gouvernance devrait donc permettre d'obtenir une vue ponctuelle. Outre la représentation de l'état actuel, il doit être possible de reconstituer comment une Traitement à quoi cela ressemblait, par exemple, le 15 mars, et quelles modifications ont été apportées par la suite.
Cette fonction revêt une importance capitale pour les audits internes et externes, le traitement des incidents et la reddition de comptes à la direction.
| Question d'examen | Sans gestion des versions et Audit-Trail | Avec la gestion des versions et Audit-Trail |
|---|---|---|
| Quelle version était en vigueur à la date de l'audit ? | Il faut reconstituer la situation à partir des exportations, des e-mails ou des rappels. | L'état de référence peut être affiché à une date donnée. |
| Qui a apporté cette modification ? | Souvent, le personnage n'est identifiable qu'indirectement, voire plus du tout. | La personne, le rôle et la date sont consignés. |
| Pour quelle raison cette modification a-t-elle été apportée ? | Le motif peut, le cas échéant, provenir uniquement d'une réunion, d'un ticket ou d'un échange d'e-mails. | Le motif et l'occasion sont associés à la procédure. |
| Qui a donné son accord ? | L'autorisation figure peut-être dans un procès-verbal distinct. | La validation, les conditions et le validateur sont associés à la version. |
| Quelles données ont été écrasées ? | L'ancienne valeur n'est plus visible. | Les valeurs « avant » et « après » restent traçables. |
| Quels étaient les risques connus ? | Il faut rassembler les informations provenant de plusieurs sources pour établir l'évaluation de l'époque. | Le niveau de risque de chaque version est clairement indiqué. |
| Quelles informations la direction peut-elle vérifier ? | Souvent, seuls l'état actuel ou des rapports créés manuellement sont disponibles. | Il est possible d'analyser l'historique des modifications, les décisions en suspens et les remontées hiérarchiques. |
| Quels documents peut-on présenter à un auditeur ? | C'est le résultat qui est visible, mais pas la manière dont il a été obtenu. | Le parcours des décisions et des modifications, tel qu'il a été consigné, peut être justifié. |
Cette comparaison montre clairement que le confort d'utilisation technique n'est pas la priorité. Ce qui est déterminant, c'est la capacité de l'organisation à expliquer de manière compréhensible son niveau de gouvernance et son évolution.
Exemple : modification d'un délai de suppression
Lors de la Traitement „Dans le cadre de la “ gestion des candidatures », un délai de conservation de six mois est initialement consigné. Par la suite, le service juridique constate que, pour certains documents, un délai plus long Rangement peut s'avérer nécessaire. Le service compétent propose alors un délai de douze mois. Le délégué à la protection des données recommande une logique de délais différenciée selon les catégories de données. La direction approuve la modification à condition que les données relatives aux candidatures soient traitées séparément en conséquence.
Sans gestion des versions, il se peut que seule l'information suivante soit visible dans le résultat :
Délai de conservation : douze mois
Avec la gestion des versions et Audit-Trail permet en revanche de visualiser l'ensemble du processus :
- Version 1 avec un délai de suppression de six mois,
- Lancement d'un examen à la suite d'une notification du service juridique,
- Recommandation du délégué à la protection des données concernant une approche différenciée en matière de délais,
- Décision de direction prise dans des conditions définies,
- Version 2 prévoyant un délai de douze mois pour certains documents et un délai plus court pour d'autres données,
- Mesure visant à adapter la configuration du système,
- nouvel examen six mois après la mise en œuvre.
La valeur probante varie considérablement. Dans le second cas, on peut identifier les évaluations et décisions techniques sur lesquelles repose l'état des lieux documenté.
Exemple : modification d'un cas d'utilisation de l'IA
Un cas d'utilisation de l'IA sera dans un premier temps mis en service pour la synthèse interne des demandes des clients. À un stade ultérieur, le service concerné souhaite utiliser ce résultat pour établir également un ordre de priorité des demandes des clients. Ensuite, un champ de données supplémentaire doit être ajouté à la Traitement être pris en compte.
Chacune de ces modifications peut avoir une incidence sur l'évaluation technique et celle au regard de la protection des données. Il convient notamment de vérifier :
- L'objectif du cas d'utilisation a-t-il changé ?
- Si des données à caractère personnel traité ?
- Le risque pour les personnes concernées évolue-t-il ?
- La surveillance humaine prévue reste-t-elle suffisante ?
- Le service juridique doit-il réexaminer le prestataire ?
- Faut-il mettre à jour la fiche technique ?
- Une nouvelle autorisation est-elle nécessaire ?
Sans Audit-Trail, il se peut que seule la description actuelle du cas d'utilisation soit visible. Avec un Audit- Le historique permet de retracer l'évolution de l'objectif, du volume de données, de l'évaluation et de la validation au fil du temps.
Cela revêt une importance particulière pour la gouvernance de l'IA, car le contexte d'utilisation, les données utilisées et le comportement du modèle peuvent évoluer même après la mise en service initiale.
Questions courantes lors des audits
Un auditeur ne se contente généralement pas de vérifier si un champ donné a été rempli. Pour évaluer la fiabilité d'un processus de protection des données, ce sont plutôt les questions relatives aux responsabilités, aux contrôles et aux décisions qui sont pertinentes.
Il s'agit notamment :
- Qui est responsable de cette opération ?
- À quand remonte la dernière vérification de cet ensemble de données ?
- Quelles informations ont été modifiées ?
- Pour quelle raison cette modification a-t-elle été apportée ?
- Quelle version était en vigueur à un moment donné ?
- Qui a validé cette version ?
- Sur quelle recommandation cette décision s'est-elle fondée ?
- Quelle mesure a été tirée de cette évaluation ?
- Quels risques subsistaient ?
- Comment les écarts constatés ont-ils été traités ?
- Pourquoi peut-on considérer que la situation actuelle est solide ?
Un tableau de bord permet de présenter clairement l'état actuel. Pour répondre à ces questions, il faut toutefois fournir en outre une preuve permettant de retracer l'origine de l'état documenté.
Pertinence pour différents processus de protection des données
Gestion des versions et AuditLes « trails » sont pertinents pour de nombreux processus liés à la protection des données et à la gouvernance.
Répertoire des activités de traitement
Il convient de consigner les modifications apportées aux finalités, aux catégories de données, aux destinataires, Bases juridiques, les délais de suppression, les mesures techniques et organisationnelles ainsi que les responsabilités.
Analyse d'impact relative à la protection des données
Les éléments pertinents sont les différentes versions de l'évaluation des risques, les recommandations, les mesures, les risques résiduels et les autorisations.
Contrôle des prestataires
Les modifications apportées au prestataire, aux sous-traitants, aux mesures techniques et organisationnelles, aux mécanismes de transfert, aux contrats et aux évaluations des risques doivent rester traçables.
Demandes des personnes concernées
Il est possible de consigner les différentes étapes du traitement, les délais, les systèmes concernés, les décisions relatives aux exceptions et les différentes versions de la réponse.
Incidents liés à la protection des données
Les éléments importants sont l'évolution des faits, leur évaluation, la décision de signalement, les mesures qui en découlent et la communication.
Gouvernance de l'IA
Cela comprend la description du cas d'utilisation, la « Model Card », la classification des risques, les conditions de validation, le suivi et les revues ultérieures.
Gestion des mesures
Les changements de statut devraient être traçables, Responsable, les délais, les justificatifs, les procédures d'escalade et la décision finale correspondante.
Tous les processus reposent sur la même exigence : l'organisation doit pouvoir expliquer ultérieurement comment elle est parvenue, à partir de la première information, à la décision actuelle.
Validations liées à la version
Une autorisation doit permettre d'identifier le contenu précis qui a été autorisé. Si une Traitement Si le contenu a été modifié ultérieurement sans qu'une nouvelle version ait été créée, la validation initiale peut se référer à un contenu qui n'existait pas encore sous cette forme au moment de la validation.
Dans ce cas, il n'est plus possible de déterminer avec certitude si la validation inclut également l'état actuel.
Les validations devraient donc pouvoir être associées à une version spécifique. Cela concerne par exemple :
- la version d'une Traitement,
- la version d'une Analyse d'impact relative à la protection des données,
- la version d'une fiche modèle,
- la version d'une évaluation des risques,
- la version d'une mesure,
- la version d'un rapport.
Si un champ essentiel est modifié après la validation, il convient de vérifier si la validation initiale reste valable ou si un nouvel examen est nécessaire.
Piste d'audit et confiance des dirigeants
La direction n'est pas tenue d'examiner chaque modification apportée à un système de gestion de la protection des données. Elle doit toutefois pouvoir avoir l'assurance que les modifications ayant une importance technique ou juridique significative sont effectuées de manière contrôlée.
Cela concerne notamment les modifications apportées à :
- Bases juridiques,
- Délais de suppression,
- Catégories de données,
- Destinataires,
- les transferts de données à l'international,
- prestataires de services,
- Évaluations des risques,
- Conditions d'autorisation,
- Responsabilités,
- le statut des mesures critiques,
- Décisions relatives à la déclaration des incidents,
- aux fins des cas d'utilisation de l'IA.
Si des modifications sont apportées sans suivre de processus clairement défini, la direction peut certes prendre connaissance de l'état actuel, mais elle n'est pas en mesure de déterminer si celui-ci résulte d'une décision formelle ou d'une intervention qui n'a pas été documentée davantage.
Un Audit-Trail renforce la confiance des dirigeants, car il permet de vérifier les modifications critiques si nécessaire et de retracer les décisions qui les ont motivées.
Exigences relatives à une plateforme de gouvernance telle qu'Ailance
Pour une plateforme de gouvernance telle qu'Ailance, cela signifie que la modélisation métier ne doit pas se limiter au stockage des données actuelles. Il doit être possible d'enregistrer les modifications de manière à garantir la traçabilité de leur origine, de leur validation et de leurs répercussions.
Il s'agit notamment :
- Versions des objets de gouvernance,
- un historique des modifications avec les valeurs « avant » et « après »,
- l'affectation des rôles et des personnes,
- Dates et versions,
- Changement de statut,
- Partages,
- Justifications,
- Liens avec les mesures, les risques et les justifications,
- vues liées à une date,
- Rapports sur les modifications critiques,
- Exportations de l'historique pour Audit- et à des fins de gestion.
Une entrée dans le Répertoire des activités de traitement peut ainsi être représenté comme un processus traçable. Dans le cas d’une Analyse d'impact relative à la protection des données Il est possible de documenter le développement depuis la première évaluation jusqu'à la validation. Un cas d'utilisation de l'IA peut être associé à son cycle de vie grâce à des versions, des révisions, des validations et un suivi.
C'est là que réside la différence organisationnelle entre le simple stockage d'un enregistrement de données actuel et la mise en œuvre d'un processus de gouvernance.
Différenciation en fonction du niveau de criticité d'une modification
Les modifications peuvent avoir des implications techniques différentes. La correction d'une faute de frappe dans le texte descriptif ne nécessite généralement pas un processus comparable à celui requis pour l'ajout d'une nouvelle catégorie de données ou la modification d'une base juridique.
Une plateforme de gouvernance devrait donc pouvoir distinguer les modifications en fonction de leur niveau de criticité.
Les éléments suivants sont généralement considérés comme particulièrement pertinents :
- Modification de la finalité du traitement,
- Ajout de nouvelles catégories de données,
- Intégration de nouveaux groupes de personnes concernées,
- Ajouter de nouveaux destinataires,
- Changement ou recours à un prestataire de services,
- Enregistrement d'un virement en provenance d'un pays tiers,
- Modification du délai de suppression,
- Modification de la base juridique,
- Modification de l'évaluation des risques,
- Modification des conditions de validation,
- Changement de propriétaire,
- Fin ou reprise des mesures essentielles,
- Modification du statut d'un incident,
- Modification de l'objectif d'un cas d'utilisation de l'IA,
- Modification d'une « Model Card » ou du dispositif de contrôle humain prévu.
Ces modifications devraient au moins être consignées. En fonction du profil de risque concerné, il est également possible de prévoir le déclenchement automatique d'une révision, d'une validation ou d'une remontée hiérarchique.
Protection de l'historique des modifications
Faut-il qu'un AuditPour que l'historique puisse servir de preuve fiable, il ne doit pas être possible de le modifier arbitrairement a posteriori. Sinon, l'historique perdrait une partie essentielle de sa valeur probante.
Cela ne signifie pas pour autant que chaque fichier journal technique doive être immuable, à l'instar d'un acte notarié. D'un point de vue technique, il convient toutefois de s'assurer que les modifications apportées à l'historique soient effectuées de manière contrôlée et restent elles-mêmes traçables.
Lorsqu'une entrée erronée est corrigée, l'historique d'origine ne doit donc pas être supprimé. Il convient plutôt de créer une nouvelle modification documentée.
En cas de corrections importantes, il convient notamment de veiller à ce que les éléments suivants restent identifiables :
- Quelle information était erronée ?
- Qui a effectué cette correction ?
- Pour quelle raison cette correction était-elle nécessaire ?
- Quand a-t-elle eu lieu ?
- Quelle est la version en vigueur depuis lors ?
Un historique correctement structuré peut, dans la pratique, contribuer à éviter toute ambiguïté ultérieure quant au contenu et à la date d'une modification.
Implications pour les rapports sur la protection des données
Gestion des versions et Audit-Trail est également pertinent pour les rapports destinés à la direction. Outre les indicateurs clés actuels, un rapport sur la protection des données doit mettre en évidence les évolutions significatives survenues depuis la dernière période de référence.
Les questions suivantes peuvent notamment présenter un intérêt :
- Quels sont les nouveaux risques identifiés ?
- Quelles mesures sont restées en suspens depuis le dernier rapport ?
- Quelles recommandations ont été mises en œuvre ?
- Quels changements importants ont eu lieu au cours de la Répertoire des activités de traitement?
- Quelles autorisations ont été accordées sous certaines conditions ?
- Quels incidents ont conduit à des changements dans les processus ?
- Quels cas d'utilisation de l'IA ont été récemment validés ou ont subi des modifications importantes ?
En l'absence de gestion des versions, ces évolutions doivent souvent être reconstituées à partir d'exportations ponctuelles, d'e-mails ou de notes prises à la main. Grâce à un historique structuré des modifications, elles peuvent être analysées de manière systématique et intégrées dans des rapports de gestion.
Rapports ponctuels
Le rapport « à un moment donné » est une fonctionnalité particulièrement utile pour les audits et les rapports de gestion. Il permet de présenter l'état de la protection des données à une date donnée.
Un tel rapport peut, par exemple, montrer où en est la situation telle qu'elle a été documentée
- le jour d'un audit,
- le jour où un incident s'est produit,
- le jour où une décision de direction est prise,
- le jour de la mise en service ou
- à la fin d'un exercice.
Cette fonction empêche que des améliorations apportées ultérieurement ne masquent l'état antérieur. Elle permet également de consigner les modifications effectuées à la suite d'un événement donné.
Cette reconstitution chronologique peut présenter un intérêt pratique considérable pour les audits internes, les contrôles externes, les demandes des autorités et les rapports de direction.
Exigences figurant dans les appels d'offres et les appels à propositions
La question générale de savoir si un système dispose d’un Audit-Le fait de disposer d'un parcours d'essai ne suffit généralement pas pour établir une évaluation fiable du produit. Étant donné que de nombreux fournisseurs répondront par l'affirmative à cette question, les exigences techniques devraient être décrites de manière plus concrète.
Voici quelques exemples de questions appropriées :
- Quels objets font l'objet d'un contrôle de version ?
- Quels champs sont archivés ?
- Les valeurs « avant » et « après » sont-elles enregistrées ?
- Les autorisations peuvent-elles être associées à une version spécifique ?
- Existe-t-il une vue par date ?
- Les changements de statut sont-ils compréhensibles ?
- Est-il possible d'analyser les modifications apportées aux rôles et aux autorisations ?
- Les justifications des modifications importantes sont-elles consignées ?
- Les modifications critiques peuvent-elles déclencher automatiquement des révisions ?
- Est-il possible d'exporter l'historique ?
- Comment se déroule le Audit- La trace est-elle protégée contre toute manipulation ultérieure ?
- Pendant combien de temps l'historique est-il conservé ?
Ces questions permettent de faire la distinction entre une fonction simplement désignée et sa mise en œuvre concrète et solide sur le plan technique.
Matrice d'évaluation des appels d'offres
| Question d'évaluation | Réponse peu convaincante | Réponse fiable |
|---|---|---|
| Existe-t-il un système de gestion des versions ? | Les anciennes versions sont enregistrées. | Les versions des objets, les statuts, les validations et les périodes de validité sont traçables. |
| Y en a-t-il un ? Audit-Trail ? | Les modifications sont consignées. | La personne, le rôle, la date, le contenu de la modification, les valeurs « avant » et « après », la justification et le changement de statut sont visibles. |
| Les partages peuvent-ils faire l'objet d'un contrôle de version ? | La validation est indiquée sur l'objet. | La validation porte sur une version spécifique et des conditions documentées. |
| Existe-t-il des vues « à un instant donné » ? | Une reconstitution n'est possible, le cas échéant, qu'à partir des données d'exportation. | Il est possible de visualiser immédiatement la situation à une date donnée. |
| Les modifications critiques sont-elles détectées ? | Les modifications sont simplement enregistrées. | Certaines modifications peuvent déclencher des révisions, des tâches ou des remontées. |
| Est-il possible d'exporter l'historique ? | Les exportations ne sont possibles que partiellement. | Une exportation conforme aux exigences d'audit contient l'historique des modifications et les justificatifs correspondants. |
| Les modifications apportées aux droits sont-elles consignées ? | Seul un journal d'administration général est disponible. | Il est possible de retracer l'historique des rôles, des autorisations et des accès. |
| Est-ce que le Audit- Le sentier est-il sécurisé ? | Les administrateurs peuvent gérer ou écraser les journaux. | L'historique est contrôlé ; les corrections génèrent des entrées supplémentaires traçables. |
Les entreprises qui choisissent une plateforme de gouvernance devraient, dans la mesure du possible, tenir compte de ces exigences dès la phase de sélection, et non pas seulement après une première évaluation.
Mise en pratique d'une approche critique
Pour dresser un premier état des lieux, une analyse critique peut Traitement sont sélectionnés au sein de l'entreprise et évalués à l'aide de quatre questions :
- Quelle était la version en vigueur il y a six mois ?
- Qui a apporté des modifications depuis lors ?
- Pour quelle raison ces modifications ont-elles été apportées ?
- Quelle version est incluse dans la mise à jour d'aujourd'hui ?
Si l'on ne peut répondre à ces questions qu'à l'aide d'e-mails, d'anciennes exportations ou de souvenirs personnels, il manque alors une trace structurée et fiable des modifications.
Conclusion
Gestion des versions et AuditLes pistes d'audit constituent un fondement essentiel pour la responsabilité, l'auditabilité et la confiance de la direction dans les processus documentés de protection des données.
Une organisation qui n'est pas en mesure de déterminer qui a modifié une donnée pertinente et sur quel contrôle repose cette modification ne peut généralement expliquer que de manière limitée la situation actuelle aux auditeurs, aux autorités de contrôle ou à sa propre direction.
Un système de gestion de la protection des données devrait donc pouvoir refléter non seulement l'état actuel, mais aussi son historique. Cela comprend la version en vigueur, les personnes chargées de la mise en œuvre et de la vérification, le motif de la modification, la validation, les risques connus et l'état documenté à un moment donné.
Gestion des versions et Audit-Le « trail » soulève ainsi des questions fondamentales en matière de gouvernance. L'état actuel des choses est d'autant plus fiable que son évolution a été documentée de manière transparente.
Pour l'examen pratique, la question suivante reste donc déterminante : quel changement critique l'organisation ne serait-elle pas en mesure d'expliquer de manière exhaustive aujourd'hui ?
Questions et réponses
Pourquoi la gestion des versions et la piste d'audit sont-elles importantes dans les logiciels de protection des données ?
Les décisions relatives à la protection des données doivent pouvoir être expliquées de manière compréhensible ultérieurement. La gestion des versions et Audit- L'historique permet de voir quelle version était en vigueur à un moment donné, qui a apporté des modifications, pour quelle raison celles-ci ont été effectuées et quels contrôles ou validations y ont été associés.
La piste d'audit est-elle une obligation légale prévue par le RGPD ?
Le site RGPD n'utilise généralement pas ce terme pour désigner les logiciels de protection des données Audit-Trail. La responsabilité exige toutefois que Responsable pouvoir prouver qu'ils respectent les exigences en matière de protection des données. Un Audit-Le « trail » peut être considéré comme un outil pratique permettant de documenter de manière traçable les décisions, les modifications et les justificatifs correspondants.
Quelle est la différence entre le contrôle de version et la piste d'audit ?
Le contrôle de version permet de représenter différentes versions d'un objet, par exemple une Traitement ou d'une Analyse d'impact relative à la protection des données. Le site Audit- L'historique retrace l'évolution des modifications et indique qui a modifié, vérifié, validé ou transmis à un niveau supérieur quelles informations et à quel moment.
Quelles informations une piste d'audit doit-elle contenir ?
Un document techniquement fiable Audit-Trail doit au moins indiquer le personnage, son rôle, le moment, le concernés Contenir l'objet, les champs modifiés, les valeurs « avant » et « après », les changements de statut, les justifications, les validations et les pièces justificatives associées.
Pourquoi la situation actuelle n'est-elle pas suffisante ?
Les audits et les décisions de direction se rapportent souvent à un moment précis. Ce qui importe alors, ce n'est pas seulement ce qui est documenté aujourd'hui, mais aussi les informations qui étaient valables à ce moment-là et la manière dont la situation a évolué par la suite.
Quels sont les changements les plus critiques ?
Les modifications apportées à la finalité, aux catégories de données, Bases juridiques, les délais de suppression, les destinataires, les prestataires de services, les transferts internationaux, les évaluations des risques, les conditions de divulgation, les incidents et les descriptions des cas d'utilisation de l'IA.
Pourquoi faut-il gérer les versions des partages ?
Une validation ne peut être attribuée sans ambiguïté que s'il est possible d'identifier la version concrète qui a été vérifiée et validée. Si le contenu subit par la suite des modifications substantielles, il convient de vérifier si la validation initiale reste valable.
Qu'est-ce qu'une vision « point dans le temps » ?
Une vue « à un instant donné » présente l'état documenté d'un processus à une date précise, par exemple au moment d'un audit, d'un incident ou d'une décision de la direction.
En quoi la gestion des versions facilite-t-elle l'établissement des rapports de gestion ?
Elle met en évidence les évolutions intervenues entre les différentes dates de rapport. Cela inclut les risques nouvellement identifiés, les modifications apportées aux activités de traitement, les mesures en retard, les autorisations modifiées, les changements récurrents ou les améliorations apportées à la suite d'un incident.
Quelles questions faut-il poser dans l'appel d'offres concernant la piste d'audit ?
Il convient notamment de vérifier quels objets et champs font l'objet d'un contrôle de version, si les valeurs « avant » et « après » sont visibles, si les validations peuvent être associées à des versions spécifiques, si des vues ponctuellesdans le temps sont possibles, si les modifications des droits sont consignées et comment l’historique est protégé contre toute modification ultérieure.
Comment Ailance prend-il en charge la gestion des versions et l'auditabilité ?
Ailance ne devrait pas traiter les objets de gouvernance uniquement comme des ensembles de données actuels, mais doit également refléter de manière traçable les modifications, les validations, les changements de statut, les responsabilités, les justifications et les pièces justificatives. Cela permet de créer un parcours documenté des décisions et des modifications.
Quelle modification critique faudrait-il examiner en premier lieu ?
Un bon point de départ est une Traitement, dans laquelle la finalité, les catégories de données, le délai de conservation, les prestataires de services ou la base juridique ont été modifiés. S'il n'est pas possible de déterminer qui a effectué, vérifié et validé la modification, le processus sous-jacent doit faire l'objet d'un examen plus approfondi
Références
[1] Comité européen de la protection des données sur la responsabilité dans le cadre de la RGPD.
[2] Art. 30 RGPD.
German 
English 
Italian 
French