A l’occasion d’interventions récentes, je me suis à nouveau retrouvé devant un thème qui a déjà fait couler (métaphoriquement) beaucoup d’encre : l’articulation entre le Délégué à la Protection des Données (DPD) et le Responsable de la Sécurité des Systèmes d’Information (RSSI).
Beaucoup ont proclamé l’incompatibilité de ces deux missions, sur la base de trois catégories d’arguments : les conflits d’intérêts, l’incompétence juridique des techniciens que seraient les RSSI, et le refus d’ajouter à leur charge déjà conséquente.
La question de la charge de travail prend le problème à l’envers. L’organisation doit déterminer les ressources, et non l’inverse.
Le procès en incompétence est douteux. Recenser les finalités, la pertinence des données, les durées de conservation nécessaire requiert plus un effort de collecte auprès des responsables métier qu’une culture juridique approfondie. Reste la gymnastique des conditions de licéité, sur laquelle une assistance juridique ponctuelle peut être bienvenue.
Sur les conflits d’intérêt, on trouve deux volets connexes : l’un étant que la mission du RSSI serait de défendre les intérêts de sa structure et non ceux des personnes concernées ; l’autre étant que contribuant à la définition des objectifs et des moyens du traitement de l’information il ne pourrait s’en abstraire dans la mission de DPD.
Pourtant, lorsque l’on pratique la mise en place de systèmes de management de la sécurité de l’information selon l’ISO 27001, on ne peut qu’être frappé par la convergence des travaux et des moyens. Inventorier les traitements de données personnelles ou les actifs informationnels, mener une étude d’impact sur la vie privée ou une analyse de risques sur l’information, notifier les violations de données personnelles ou mettre en œuvre la communication des incidents de sécurité : les termes changent mais les méthodes et les objets sont les mêmes.
Comme souvent dans les débats confus, cela me semble venir d’un problème de vocabulaire. Contrairement à celui de DPD, le terme de RSSI n’était pas vierge. Il correspond à une activité déjà portée, le plus souvent au sein des DSI, par un expert technique reconnu, qui n’a effectivement pas nécessairement d’appétence pour les raisons d’être des traitements qu’il est déjà fort occupé à sécuriser techniquement.
Par ailleurs, une seconde acceptation découle de la norme ISO 27001, qui impose de désigner un responsable pour la conformité du système de management de la sécurité de l’information (SMSI) à la norme et pour la restitution à la direction des performances de ce système. Ce rôle a été amalgamé au RSSI technique préexistant, alors qu’il s’agit plus ici d’un travail d’animation et de coordination.
Ce malaise terminologique, je le retrouve dans le guide des indicateurs des prérequis du socle commun du programme HOP’EN, édité par la DGOS en juillet 2019. Dans son prérequis P2.4, trois termes différents sont utilisés pour cette même fonction : responsable sécurité, RSSI et référent sécurité. Ainsi, la description faite dans le recensement des indicateurs mentionne « Positionnement fonctionnel du RSSI en dehors de la DSI », tandis que la fiche détaillée explicite « L’exigence concerne l’existence d’une fonction de référent sécurité au sein de l’établissement, fonction qui n’est pas exercée nécessairement à temps plein et dont le positionnement fonctionnel est en dehors de la DSI (il pourrait, par exemple, être attaché à la cellule qualité de l’établissement/GHT). »
Si l’on décorrèle ces termes, en laissant au RSSI son positionnement historique d’expert technique au sein de la DSI et en chargeant le référent sécurité des tâches spécifiques au fonctionnement du système de management, on dégage pour ce dernier un rôle de pilotage et d’animation totalement compatible des missions du DPD :
- Cartographie des données et des traitements,
- Cotation avec les directions métier de l’impact des pertes de confidentialité, disponibilité, intégrité sur ces biens essentiels, avec l’établissement d’objectifs argumentés sur la perte de disponibilité (indicateur P2.2 des prérequis HOP’EN)
- Animation annuelle d’une analyse des risques inter-directions pour déterminer les scénarios pouvant entrainer ces événements redoutés, et sélectionner ceux qui requièrent des actions de mitigation prioritaire (P2.4).
- Consolidation de l’ensemble des mesures de mitigation de haut niveau en une politique de sécurité de l’information (P2.4). Ces mesures sont ensuite déclinées opérationnellement dans chaque direction concernée, dont principalement la DSI.
- Animation de réunions périodiques de suivi de l’avancement des actions, des retours d’expérience sur les incidents rencontrés, sur les résultats des audits, et de mise à niveau en conséquence de l’analyse des risques et du plan d’actions.
- Conduite des actions de sensibilisation des personnels de l’établissement, notamment sur la base des retours d’expérience.
- Organisation des routines de communication interne et externe, et particulièrement de la notification des incidents de sécurité.
- Consolidation et publication régulière des indicateurs de fonctionnement du système de management de la sécurité, parmi lesquels l’indicateur P2.2 de disponibilité des applicatifs.
- Organisation des audits internes et des tests d’intrusion (indicateur P2.5)
- Restitution semestrielle à la direction des résultats et performances du SMSI (P2.4).
Avec ce périmètre, il recouvre à 80% ce que l’on attend d’un DPD. Il convient d’y ajouter le cadrage initial des traitements en termes de licéité et de minimisation, la mise en place des circuits d’information et d’exercice des droits des personnes concernées, et l’on a un périmètre cohérent.
Cette cohérence permet, comme l’affirme la fiche n°6 de la boîte à outils de l’ANAP pour l’atteinte des prérequis HOP’EN, de faire porter les rôles de RSSI (ou plus exactement, si on utilise les termes définis ici, de référent sécurité) et de DPD par une même personne.
La personne ou l’équipe qui porte cette mission a bien le niveau d’indépendance requis tant d’un DPD que d’un référent sécurité. Son rôle est de médiation, d’objectivation, de synthèse et de communication entre les utilisateurs, les Directions supports et la Direction générale. Il n’est nullement en contradiction avec celui du RSSI historique, auquel elle fournit des objectifs explicites et assumés, facilitant son travail de recherche des solutions les plus efficaces.
Les compétences requises sont généralistes : capacité de synthèse, d’animation et de vulgarisation, un peu de culture informatique et juridique, et surtout beaucoup de bon sens, de rigueur et de patience. Pour désamorcer un autre débat récurrent, elles ne préjugent pas que l’expérience initiale du titulaire soit juridique ou technique. Un conseil que j’ai reçu lorsque j’étais débutant m’a toujours servi avec profit : pour marcher, il faut un pied d’appui et un pied qui avance.