DSAR, effacement et éléments probants ISO 27001 en 2026

L’e-mail est arrivé dans la boîte de réception de Sarah à 9 h 03.

Ce n’était pas la première Data Subject Access Request reçue par son entreprise SaaS en forte croissance. C’était la première qui ressemblait à un audit public.

L’expéditeur était un ancien employé, devenu défenseur de la protection de la vie privée. La demande citait les articles du GDPR par numéro et exigeait toutes les données à caractère personnel, la limitation immédiate du traitement, la liste de chaque prestataire tiers détenant ses données et une preuve vérifiable de l’effacement dans les systèmes de production et de sauvegarde. Un journaliste était en copie.

En quelques minutes, les lacunes sont apparues. L’ingénierie a averti que la « véritable suppression » dans une base de données multi-tenant pouvait affecter d’autres clients. Le marketing démêlait les données utilisateur réparties entre plusieurs plateformes d’analyse. Le service juridique a identifié un dossier d’emploi non résolu. La sécurité craignait que les journaux ne révèlent la logique de détection ou les données d’une autre personne. Le support détenait des enregistrements sous deux adresses e-mail. La finance avait des factures sous une troisième.

Le compte à rebours avait déjà commencé.

Ce scénario n’a plus rien d’exceptionnel. En 2026, les droits des personnes concernées ne relèvent plus d’une simple boîte de réception dédiée à la protection de la vie privée. Ils constituent un processus métier contrôlé qui dépend des inventaires d’actifs, des décisions relatives à la base légale, de la vérification d’identité, du contrôle d’accès, des règles de conservation, des conservations pour litige, de la coordination des fournisseurs, de la divulgation sécurisée, des éléments probants de suppression et d’une journalisation compatible avec les exigences d’audit.

Le GDPR indique aux organisations quels droits les personnes détiennent. ISO/IEC 27001:2022 donne aux équipes sécurité et conformité la discipline de système de management nécessaire pour prouver que ces droits sont traités de manière cohérente, sécurisée et reproductible.

Pour les RSSI, les responsables conformité, les responsables de la protection des données et les dirigeants d’entreprise, l’objectif n’est pas de produire davantage de documents. Il s’agit de construire un processus fiable de DSAR, d’effacement et de limitation qui produit les éléments probants requis par le GDPR, les audits ISO/IEC 27001:2022 et les attentes d’assurance plus larges au titre de NIS2, DORA, NIST CSF 2.0 et COBIT 2019.

Pourquoi le traitement ad hoc des DSAR échoue sous pression

La plupart des défaillances liées aux DSAR ne sont pas dues à de mauvaises intentions. Elles sont dues à la fragmentation.

Une organisation peut disposer d’une notice de confidentialité, d’une boîte aux lettres du DPO et d’une clause GDPR dans ses contrats fournisseurs, tout en ayant des difficultés à répondre à des questions opérationnelles de base :

• Qui valide l’identité du demandeur ?
• Quelle entité juridique agit comme responsable du traitement ou sous-traitant ?
• Quels systèmes doivent être interrogés ?
• Qui est propriétaire de chaque système ?
• Quelles données relèvent du périmètre de la demande ?
• Quelles données doivent être caviardées avant divulgation ?
• Quelles données ne peuvent pas être effacées en raison d’obligations fiscales, d’audit, de litige, de prévention de la fraude ou d’une obligation légale ?
• Comment la limitation du traitement est-elle appliquée techniquement ?
• Quels fournisseurs doivent prendre en charge la recherche, l’export, la suppression ou la limitation ?
• Quels éléments probants démontrent que la demande a été traitée dans les délais ?
• Que se passe-t-il si la DSAR révèle une violation de données à caractère personnel ?

GDPR Article 5 exige que les données à caractère personnel soient traitées de manière licite, loyale et transparente, collectées pour des finalités déterminées, limitées à ce qui est nécessaire, tenues à jour, conservées pendant une durée n’excédant pas celle nécessaire et protégées par des mesures techniques et organisationnelles appropriées. Article 5(2) rend la responsabilité explicite : le responsable du traitement doit être en mesure de démontrer la conformité. Article 4 définit largement le traitement, incluant la collecte, le stockage, l’utilisation, la divulgation, la limitation, l’effacement et la destruction.

Cela signifie que le processus DSAR est lui-même une activité de traitement. Il doit être maîtrisé.

GDPR Article 3 est également important pour les entreprises cloud, SaaS, fintech et numériques situées hors de l’UE. Si vous proposez des biens ou services à des personnes dans l’Union, surveillez leur comportement ou traitez des données à caractère personnel dans le cadre des activités d’un établissement dans l’UE, le GDPR peut s’appliquer même lorsque les opérations sont externalisées ou que l’infrastructure est mondiale.

ISO/IEC 27001:2022 apporte une structure à cette réalité. Les clauses 4.1 à 4.4 exigent que l’organisation comprenne son contexte, les parties intéressées, les exigences, le domaine d’application du SMSI et les processus en interaction. Une personne concernée est une partie intéressée. Les droits GDPR sont des exigences. Les applications SaaS, les fournisseurs d’identité, les plateformes d’analyse, les outils de support, les entrepôts de données et les sauvegardes cloud sont des processus en interaction. Un processus DSAR doit être intégré au SMSI, et non fonctionner en marge de celui-ci.

Les trois droits des personnes concernées qui créent le plus de pression

L’accès, l’effacement et la limitation exposent le plus grand écart entre la promesse juridique et la capacité opérationnelle.

GDPR Article 6 est central dans cette logique de décision. Vous ne pouvez pas traiter, conserver, divulguer des données ou refuser l’effacement sans comprendre la base légale. Article 9 élève le niveau d’exigence pour les catégories particulières de données à caractère personnel, telles que les données de santé, les données biométriques utilisées pour l’identification unique ou les données révélant des caractéristiques sensibles. Dans un environnement SaaS en 2026, cela peut affecter l’onboarding, la vérification d’identité, la surveillance de la fraude, les pièces jointes du support client et les dossiers du personnel.

La Politique de protection des données et de la vie privée [P17] d’entreprise de Clarysec formule directement l’obligation. Dans la clause 3.6 des objectifs, elle exige que l’organisation :

Respecte les droits des personnes concernées, notamment l’accès, la rectification, l’effacement, la limitation, la portabilité, l’opposition et la protection contre la prise de décision automatisée.

Cet objectif ne devient auditable que lorsqu’il est relié à des propriétaires, des registres, des workflows, des contrôles et des éléments probants.

Commencer là où commencent les auditeurs : périmètre, parties intéressées et responsabilités

Dans Zenith Blueprint : feuille de route en 30 étapes pour l’auditeur [ZB], la phase ISMS Foundation & Leadership, étape 2, se concentre sur les besoins des parties intéressées et le domaine d’application du SMSI. Pour le GDPR, le Blueprint identifie les attentes des autorités de régulation comme suit :

Régulateurs de l’UE
(GDPR)

Traitement licite des données à caractère
personnel, notification des violations en 72 h,
droits des personnes concernées

Nommer un délégué à la protection des données, établir
un processus de réponse aux violations, des procédures pour
le traitement des demandes relatives aux données.

C’est le bon point de départ. Avant d’automatiser les tickets ou de configurer des portails, définissez le périmètre du traitement des droits des personnes concernées :

1. Quelles entités juridiques agissent comme responsable du traitement, responsables conjoints du traitement ou sous-traitants ?
2. Quels produits, services et territoires relèvent du périmètre ?
3. Quelles catégories de personnes concernées existent, par exemple clients, employés, utilisateurs d’essai, prospects, fournisseurs, visiteurs du site web ou utilisateurs d’application ?
4. Quels systèmes, référentiels et fournisseurs détiennent des données à caractère personnel ?
5. Quels rôles approuvent la divulgation, le refus, l’effacement, la limitation ou l’escalade ?
6. Quels indicateurs sont communiqués à la direction ?

Les clauses 5.1 à 5.3 d’ISO/IEC 27001:2022 exigent le leadership, l’alignement de la politique, les ressources et l’attribution des responsabilités. Cela s’aligne directement sur l’obligation de rendre compte prévue par le GDPR.

La Politique de protection des données et de la vie privée [P17], clause 6.4.1 des exigences de mise en œuvre de la politique, indique :

Le délégué à la protection des données (DPO) doit tenir à jour des processus documentés pour la réception, la validation, le suivi et la réponse aux demandes des personnes concernées (DSR).

Pour les PME, la Politique de protection des données et de la vie privée - PME [P17S] de Clarysec utilise une attribution des responsabilités adaptée à la taille de l’organisation. La clause 5.2.1 des exigences de gouvernance indique :

Le Coordinateur Protection des données doit tenir à jour un registre de toutes les activités de traitement des données à caractère personnel, incluant les catégories de données, la finalité, la base légale et les durées de conservation

Ce registre des activités de traitement est le cœur opérationnel de la préparation aux DSAR. S’il est incomplet, l’équipe DSAR recherche dans sa mémoire, dans les messages Slack et dans la connaissance informelle. S’il est exact, l’équipe recherche par activité de traitement, catégorie de données, propriétaire de système, fournisseur et règle de conservation.

Le processus DSAR Clarysec : de la réception à la clôture

Un processus DSAR prêt pour l’audit doit être suffisamment simple pour fonctionner sous pression, mais suffisamment maîtrisé pour résister à une autorité de régulation, à une revue d’assurance client ou à un audit ISO/IEC 27001:2022.

1. Réception et accusé de réception

Les demandes doivent entrer par un canal maîtrisé, tel qu’une boîte aux lettres dédiée à la protection des données, un portail, un formulaire de support ou une file de réception juridique. Le personnel doit reconnaître les demandes formulées en langage courant. Une personne n’a pas besoin d’écrire « DSAR » pour exercer un droit. « Quelles données détenez-vous sur moi ? » ou « supprimez mon profil » peut suffire à déclencher le processus.

La Politique de protection des données et de la vie privée - PME [P17S], clause 6.5.2 des exigences de mise en œuvre de la politique, fixe un niveau de service clair :

Le Coordinateur Protection des données doit accuser réception des demandes dans un délai de 3 jours ouvrés et répondre dans un délai de 30 jours

L’accusé de réception doit inclure la référence de la demande, une clarification du périmètre si nécessaire, les instructions de vérification d’identité et le délai de réponse prévu.

2. Vérification d’identité et contrôle de l’habilitation

Une DSAR peut devenir une violation de données à caractère personnel si des informations sont envoyées à la mauvaise personne. La vérification doit être proportionnée et ne doit pas collecter de nouvelles données à caractère personnel excessives. Utilisez des portails authentifiés lorsque cela est possible. Pour les anciens utilisateurs, validez par rapport aux données de compte connues. Pour les employés, coordonnez avec les ressources humaines. Pour les représentants, exigez une preuve d’habilitation.

Conservez les éléments probants relatifs à la méthode de vérification, la date d’achèvement, l’approbateur, toute information supplémentaire demandée et la décision en cas d’échec de la vérification.

3. Classer la demande

Un même message peut contenir plusieurs droits. Classez chacun séparément, car l’accès, l’effacement, la limitation, l’opposition et la portabilité exigent des logiques de décision et des éléments probants différents. Signalez également les réclamations potentielles, les dossiers du personnel, les données relatives aux enfants, les données relevant de catégories particulières et les violations potentielles de données à caractère personnel.

4. Rechercher dans l’inventaire, pas seulement dans les systèmes évidents

C’est ici qu’ISO/IEC 27001:2022 devient concrète. Zenith Blueprint [ZB], phase Controls in Action, étape 22, avertit que le périmètre de l’inventaire est plus large que ce que beaucoup d’organisations imaginent :

Le périmètre de cet inventaire est plus large qu’on ne le pense généralement. Il doit inclure :

✓ Actifs physiques : ordinateurs portables, serveurs, téléphones, bandes de sauvegarde, supports amovibles,
enregistrements imprimés.
✓ Actifs numériques : documents, jeux de données, référentiels, e-mails, code source, fichiers
stockés dans le cloud.
✓ Actifs logiques : comptes utilisateurs, identifiants, clés, licences logicielles, interfaces de programmation (API).
✓ Actifs liés aux services : plateformes SaaS, services de sécurité managés, stockage
externalisé.
✓ Personnes comme actifs : non au sens marchand, mais au regard des responsabilités attribuées,
des accès et de l’exposition à l’information liée aux rôles.

L’étape 22 explique également la propriété :

Chaque actif doit avoir un propriétaire défini, non pas la personne qui l’utilise, mais celle qui est responsable
de son utilisation, de sa protection et de son cycle de vie. La propriété est essentielle pour l’alignement des contrôles : qui classe
l’actif (5.10), qui décide de son niveau d’accès (8.3), qui gère sa suppression (8.10), qui s’assure
de sa restitution (5.9 recoupe subtilement les procédures de retour des actifs).

Dans Zenith Controls : guide de correspondance de conformité [ZC], le contrôle ISO/IEC 27002:2022 5.9, Inventaire des informations et des autres actifs associés, est traité comme un contrôle préventif soutenant la confidentialité, l’intégrité et la disponibilité. Son concept cybersécurité est Identifier, sa capacité opérationnelle est la gestion des actifs et ses domaines de sécurité incluent la gouvernance, l’écosystème et la protection.

Pour les DSAR, cela signifie que l’inventaire n’est pas une feuille de calcul informatique. C’est la cartographie qui indique aux équipes protection des données, juridique et sécurité où des données à caractère personnel peuvent exister.

5. Examiner, caviarder et approuver la divulgation

Une réponse à une DSAR ne doit pas être un export brut. La revue doit protéger les données à caractère personnel d’autres individus, les informations métier confidentielles, le secret professionnel, les données sensibles pour la sécurité, les signaux de fraude et les données hors du périmètre de la demande.

L’approbation doit être fondée sur les risques. Les réponses d’accès courantes peuvent être approuvées par le Coordinateur Protection des données ou le DPO. Les demandes impliquant des employés, un litige, des données relevant de catégories particulières, des enfants, la fraude, des journaux de sécurité ou des exports volumineux doivent impliquer les fonctions juridique, ressources humaines ou la direction sécurité.

6. Transmettre de manière sécurisée

N’envoyez pas de fichiers volumineux non chiffrés en pièce jointe d’un e-mail. Utilisez des portails authentifiés, des fichiers chiffrés avec transmission séparée du mot de passe ou des liens de transfert sécurisés avec expiration et journalisation des accès. Enregistrez la méthode de transmission, la date, le compte destinataire, la date d’expiration et la confirmation lorsqu’elle est disponible.

7. Clôturer avec les éléments probants

La Politique de protection des données et de la vie privée [P17], clause 6.4.3, est explicite :

Toutes les actions entreprises doivent être journalisées à des fins d’audit, y compris les décisions de refus des demandes.

La Politique de protection des données et de la vie privée - PME [P17S], clause 6.5.4, indique :

Toutes les réponses aux demandes des personnes concernées doivent être consignées dans un registre sécurisé, avec un accès restreint au Coordinateur Protection des données et au DG

Une DSAR n’est pas terminée lorsque l’e-mail est envoyé. Elle est terminée lorsque le registre montre la demande, le contrôle d’identité, les décisions, les systèmes recherchés, la réponse, les exceptions, les approbations, la transmission et la clôture.

L’effacement est une destruction maîtrisée, pas un bouton de suppression

Les demandes d’effacement révèlent si la protection de la vie privée a été intégrée aux systèmes ou ajoutée après le lancement.

La Politique de conservation et d’élimination des données [P14] d’entreprise de Clarysec, clause 4.3.3 des rôles et responsabilités, attribue la responsabilité au rôle qui :

Répond aux demandes d’effacement et assure la suppression des données à caractère personnel en temps utile et de manière vérifiable lorsque cela est requis.

L’expression « lorsque cela est requis » est essentielle. L’effacement au titre du GDPR n’est pas absolu. Les organisations peuvent devoir conserver des données au titre d’obligations légales, d’audit, d’obligations fiscales, d’exigences réglementaires, de la prévention de la fraude, de la sécurité, de litiges ou de la constatation, de l’exercice ou de la défense de droits en justice. Le processus doit inclure une décision licite de conservation et d’exception.

Zenith Blueprint [ZB], phase Controls in Action, étape 19, explique le contrôle ISO/IEC 27002:2022 8.10, Suppression des informations, en termes opérationnels :

Ce contrôle garantit que les données ne sont pas conservées plus longtemps que nécessaire et, lorsqu’elles ne sont plus
nécessaires, qu’elles doivent être supprimées de manière sécurisée et fiable. De nombreuses organisations accumulent de grands
volumes de données au fil du temps, mais, sans processus clair de suppression, ces données peuvent rester inutilisées et
non protégées, augmentant discrètement le risque d’exposition, de violation ou de manquement réglementaire.

Il avertit également :

N’oubliez pas les sauvegardes et les systèmes archivés, qui conservent souvent des données historiques bien au-delà de leur
valeur opérationnelle. Les politiques de suppression doivent couvrir :

✓ Les paramètres de conservation des sauvegardes,
✓ Les cycles de vie des instantanés,
✓ Les référentiels archivés d’e-mails ou de documents.

Et il conclut sur les éléments probants :

Le processus de suppression lui-même doit être journalisé et, dans le cas de données à haut risque ou réglementées,
revu ou approuvé. Cela assure la traçabilité et protège contre la destruction accidentelle ou
non autorisée d’enregistrements précieux.

Dans Zenith Controls [ZC], le contrôle ISO/IEC 27002:2022 8.10, Suppression des informations, est cartographié comme un contrôle préventif axé sur la confidentialité, aligné sur le concept cybersécurité Protéger et relié aux capacités opérationnelles de protection de l’information ainsi que juridique et conformité.

Pour les architectures cloud complexes, l’effacement cryptographique peut être approprié lorsqu’il est correctement conçu. Si les données à caractère personnel sont chiffrées avec une clé propre à une personne concernée ou à un tenant, la destruction de la clé peut rendre les données définitivement inaccessibles, y compris lorsque des fragments chiffrés restent dans les sauvegardes jusqu’à leur rotation planifiée. Cette approche doit être soigneusement conçue, documentée, testée et approuvée. Elle ne constitue pas un contournement d’une architecture de suppression insuffisante.

La préparation applicative est donc essentielle. La Politique relative aux exigences de sécurité des applications - PME [P09S] de Clarysec, clause 6.5.1.3, exige que les applications :

permettent l’export et la suppression sécurisés des données à caractère personnel lorsque cela est légalement requis (par exemple, GDPR Article 17 – droit à l’effacement).

Si les équipes produit ne construisent pas les capacités d’export et de suppression, les équipes protection des données sont contraintes d’utiliser des scripts de base de données, des tickets fournisseurs et des traitements manuels incohérents.

Conservation pour litige et suspension de la suppression

Un processus d’effacement mature doit inclure une voie « ne pas supprimer ». Ce n’est pas une excuse pour ignorer l’effacement. C’est une exception maîtrisée.

La Politique de conservation des données et d’élimination sécurisée - PME [P14S] de Clarysec, clause 5.4 des exigences de gouvernance, indique :

Les données soumises à une conservation pour litige et à une suspension de suppression (par exemple en cas de litige, d’audit ou d’enquête) doivent être clairement identifiées dans le système et protégées contre la suppression, même si la durée de conservation planifiée a expiré.

La Politique de conservation et d’élimination des données [P14], clause 6.4.1, reprend le même principe :

Si une conservation pour litige et une suspension de suppression est émise (par exemple, dans l’attente d’un litige, d’une investigation ou d’un audit), les données qui seraient autrement soumises à destruction doivent être conservées au-delà de leur durée normale de conservation.

Les auditeurs veulent les deux versants du dossier : les éléments probants d’une suppression en temps utile et ceux d’une conservation justifiée.

Limitation du traitement : le droit sous-estimé

Les demandes de limitation n’exigent pas toujours la suppression. Elles exigent que l’organisation limite le traitement actif tout en conservant les données dans des conditions maîtrisées.

Exemples courants :

• Un client conteste l’exactitude des données et vous demande de cesser de les utiliser pendant leur vérification.
• Un ancien employé s’oppose au traitement, mais l’enregistrement est nécessaire à la défense de droits en justice.
• Un utilisateur demande l’effacement, mais des données minimales doivent être conservées pour maintenir une liste d’opposition.
• Une investigation de fraude exige la conservation, mais pas l’usage opérationnel normal.

Un processus de limitation praticable doit inclure une décision juridique, un indicateur système, un ajustement du contrôle d’accès, une suppression marketing, une exclusion analytique, une instruction fournisseur, une revue périodique et des éléments probants d’exception.

Dans Zenith Controls [ZC], le contrôle ISO/IEC 27002:2022 5.34, Protection de la vie privée et protection des informations à caractère personnel, est traité comme un contrôle préventif soutenant la confidentialité, l’intégrité et la disponibilité. Il est cartographié avec Identifier et Protéger, avec les capacités opérationnelles de protection de l’information ainsi que juridique et conformité.

Zenith Blueprint [ZB], phase Controls in Action, étape 23, résume le test d’audit :

Confirmez que votre organisation a mis en œuvre des mesures de protection de la vie privée (5.34) alignées sur
les exigences légales applicables. Vérifiez la classification des informations à caractère personnel, les contrôles d’accès appropriés, les pratiques
de traitement sécurisé et la formation de sensibilisation. Validez si les demandes d’accès des personnes concernées, la
suppression des données ou les journaux de traitement sont pris en charge opérationnellement, et pas seulement par la politique.

L’expression clé est « pris en charge opérationnellement, et pas seulement par la politique ».

Cartographier les processus DSAR avec les éléments probants ISO/IEC 27001:2022

ISO/IEC 27001:2022 ne remplace pas le GDPR. Elle organise les éléments probants.

Les clauses 6.1.1 à 6.1.3 exigent l’appréciation des risques, le traitement des risques, les critères d’acceptation du risque, les propriétaires de risques, la sélection des contrôles, une Déclaration d’applicabilité et un plan de traitement des risques. Les risques DSAR incluent la divulgation non autorisée, les délais manqués, l’effacement incomplet, la conservation illicite, la vérification d’identité excessive, la non-coopération des fournisseurs et l’incapacité à limiter le traitement.

La clause 8.1 exige que les organisations planifient, mettent en œuvre et maîtrisent les processus du SMSI, conservent des informations documentées, maîtrisent les changements et s’assurent que les processus, produits et services fournis par des tiers et pertinents pour le SMSI sont maîtrisés. Cela correspond aux opérations DSAR, car les demandes traversent des fonctions internes et des sous-traitants externes.

Un dossier d’éléments probants solide comprend la procédure DSR, le registre DSR, le registre des activités de traitement, l’inventaire des actifs, le calendrier de conservation des données, le registre des conservations pour litige, la procédure de vérification d’identité, les lignes directrices de caviardage, la méthode de divulgation sécurisée, la procédure d’effacement, la procédure de limitation, le playbook fournisseur, le registre des exceptions, les enregistrements de formation, les résultats d’audit interne et le reporting de revue de direction.

Un processus pratique pour l’accès, l’effacement et la limitation

Ce processus transforme la crise de Sarah en processus auditable. Chaque étape dispose d’un propriétaire, d’une base de contrôle et d’éléments probants.

Valeur de conformité croisée au-delà du GDPR

Un processus DSAR trouve son origine dans le GDPR, mais les mêmes contrôles soutiennent des référentiels plus larges.

NIS2 Article 20 fait de la cybersécurité une responsabilité de la direction pour les entités essentielles et importantes. Article 21 exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées, incluant l’analyse des risques, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, l’évaluation de l’efficacité, l’hygiène cyber, la formation, le contrôle d’accès, la gestion des actifs, l’authentification et les communications sécurisées. Les DSAR reposent sur nombre de ces mêmes capacités.

DORA s’applique à compter du 17 janvier 2025 à de nombreuses entités financières et définit des exigences uniformes de gestion des risques liés aux TIC, de notification des incidents, de tests de résilience et de gestion du risque lié aux tiers TIC. Les Articles 5 et 6 exigent une gouvernance et une gestion documentée des risques liés aux TIC. Les Articles 17 à 20 traitent de la détection, de la classification, de l’escalade, de la communication et de la clôture des incidents. Les Articles 24 à 30 portent sur les tests de résilience, le risque lié aux tiers TIC, les registres de services, les droits d’audit, la localisation des données, l’assistance en cas d’incident et les stratégies de sortie. Une fintech traitant les DSAR via des plateformes cloud doit aligner le traitement des demandes de protection des données avec son registre des services TIC.

NIST CSF 2.0 aide à traduire le même travail en résultats de cybersécurité. GOVERN couvre les exigences légales, réglementaires et contractuelles, la stratégie de risque, les rôles, la politique et la supervision. IDENTIFY et PROTECT s’alignent fortement sur la visibilité des actifs, la classification des données, le contrôle d’accès, la suppression, la gouvernance des fournisseurs et la protection de la vie privée.

COBIT 2019 pose des questions de gouvernance. Qui possède le processus ? Quels objectifs sont définis ? Comment la performance est-elle mesurée ? Comment les exceptions sont-elles approuvées ? Comment l’assurance est-elle obtenue ? Les éléments probants DSAR peuvent soutenir des objectifs tels que APO13 Sécurité gérée, APO14 Données gérées et DSS06 Contrôles gérés des processus métier.

Le regard de l’auditeur

Ne créez pas des éléments probants séparés pour chaque référentiel. Créez un processus DSAR fiable et cartographiez-le correctement.

Les indicateurs DSAR que la direction doit voir

La direction ne peut pas superviser ce qu’elle ne voit pas. Les indicateurs utiles incluent le volume de demandes par type de droit, le délai moyen d’accusé de réception, le délai moyen de clôture, la performance de respect des échéances, les taux de clarification d’identité, les exceptions de suppression, les cas de conservation pour litige, les délais de réponse des fournisseurs, les refus partiels, les incidents identifiés pendant le traitement et les actions de remédiation ouvertes.

Ces indicateurs montrent si les droits des personnes concernées sont maîtrisés opérationnellement ou dépendent d’efforts héroïques.

Lacunes fréquentes de préparation aux DSAR

Clarysec observe couramment les mêmes faiblesses dans les organisations SaaS, fintech, de services professionnels et les PME orientées cloud :

• Absence de propriétaire pour chaque système contenant des données à caractère personnel
• Registre des activités de traitement non aligné avec l’usage SaaS réel
• Plateformes marketing, analytiques et entrepôts de données exclus des recherches
• Absence de norme documentée de vérification d’identité
• Absence de revue de caviardage avant divulgation
• Suppression en production effectuée sans traitement des sauvegardes
• Absence de contrôle de conservation pour litige avant effacement
• Limitation traitée manuellement sans indicateur système
• Contrats fournisseurs dépourvus de clauses d’assistance DSAR
• Refus et refus partiels non documentés
• Absence d’échantillonnage par audit interne des DSAR clôturées
• Personnel de première ligne non formé à reconnaître les demandes

Votre liste de contrôle de préparation DSAR 2026

Utilisez-la comme test de maturité :

• Disposons-nous d’un processus documenté de réception, validation, suivi et réponse aux DSR ?
• Accusons-nous réception des demandes dans un SLA interne défini ?
• Tenons-nous un registre DSR sécurisé avec accès restreint ?
• Disposons-nous d’un registre des activités de traitement à jour, avec catégories, finalités, bases légales et durées de conservation ?
• Connaissons-nous chaque système, plateforme SaaS, référentiel et fournisseur susceptible de détenir des données à caractère personnel ?
• Chaque actif pertinent dispose-t-il d’un propriétaire responsable ?
• Pouvons-nous exporter les données à caractère personnel de manière sécurisée ?
• Pouvons-nous supprimer les données à caractère personnel de manière sécurisée lorsque cela est légalement requis ?
• Pouvons-nous limiter le traitement techniquement ou procéduralement ?
• Vérifions-nous la conservation pour litige avant suppression ?
• Documentons-nous les décisions de refus, de refus partiel et d’exception ?
• Les contrats fournisseurs prennent-ils en charge l’assistance DSAR ?
• Testons-nous le processus par audit interne ou par exercices sur table ?
• Communiquons-nous la performance DSAR à la direction ?
• Cartographions-nous les contrôles DSAR dans le traitement des risques ISO/IEC 27001:2022 et la Déclaration d’applicabilité ?

Si plusieurs réponses sont « pas de manière constante », la prochaine demande pourrait exposer la lacune.

Transformer les droits des personnes concernées en éléments probants prêts pour l’audit

En 2026, les droits des personnes concernées exigent plus que de bonnes intentions et une boîte de réception dédiée à la protection des données. Ils exigent un processus capable de trouver les données, valider l’identité, prendre des décisions licites, coordonner les fournisseurs, protéger la divulgation, exécuter l’effacement, appliquer la limitation et préserver les éléments probants.

Clarysec aide les organisations à construire ce processus sans créer une bureaucratie de conformité parallèle. Commencez par Zenith Blueprint pour positionner les droits des personnes concernées dans la bonne phase et les bonnes étapes du SMSI. Utilisez la Politique de protection des données et de la vie privée, la Politique de protection des données et de la vie privée - PME, la Politique de conservation et d’élimination des données, la Politique de conservation des données et d’élimination sécurisée - PME et la Politique relative aux exigences de sécurité des applications - PME de Clarysec pour définir les responsabilités et les règles opérationnelles.

Utilisez ensuite Zenith Controls pour cartographier les contrôles ISO/IEC 27002:2022 5.9, 5.34 et 8.10 avec les éléments probants de conformité croisée pour l’assurance GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 et COBIT 2019.

Si vous souhaitez savoir si vos processus DSAR, d’effacement et de limitation résisteraient demain à un audit, Clarysec peut vous aider à tester le processus, combler les lacunes et constituer le dossier d’éléments probants avant l’arrivée de la prochaine demande. Téléchargez les modèles de politiques Clarysec pertinents ou réservez une évaluation de préparation DSAR pour passer d’une réponse réactive à des opérations de protection des données maîtrisées et prêtes pour l’audit.