Le sigle revient dans presque tous les textes consacrés à la cybersécurité, des recommandations de l’ANSSI aux exigences posées par les clients et les assureurs. Il est pourtant rarement défini. Beaucoup de dirigeants le rangent du côté de la technique, alors que la fonction de responsable de la sécurité des systèmes d’information, le RSSI, relève d’abord du pilotage : décider ce qu’il faut protéger en priorité, avec quels moyens, et rendre des comptes à la direction sur le niveau de risque réellement assumé.
Comprendre ce que recouvre cette fonction permet de trancher une question concrète que se posent de nombreuses PME, ETI et collectivités : faut-il un RSSI, et sous quelle forme.
Ce que fait réellement un RSSI
Un RSSI ne configure pas des pare-feux et n’administre pas des postes de travail. Son travail consiste à rendre la sécurité pilotable, et il s’articule autour de quelques missions.
Il définit la politique de sécurité de l’organisation : les règles applicables aux accès, aux données, aux prestataires, à l’usage des outils. Il conduit l’analyse de risques et hiérarchise les actions selon leur impact sur l’activité plutôt que selon leur intérêt technique. Il pilote le plan d’action et le budget qui en découlent, suit leur avancement et alerte lorsque les moyens ne sont pas à la hauteur des risques. Il veille à la conformité, qu’elle résulte de la réglementation, d’un client exigeant ou d’un assureur. Il prépare enfin l’organisation à gérer une crise : rôles, procédures, exercices, relations avec les prestataires de supervision.
→ Plan de réponse à incident : comment réagir face à une cyberattaque
À ces missions s’ajoute une dimension que les organigrammes rendent peu visible : le RSSI fait le lien entre des interlocuteurs qui ne parlent pas la même langue. Il traduit un risque technique en conséquence métier pour la direction générale, et une exigence de la direction en mesures concrètes pour les équipes informatiques.
RSSI et DSI : deux rôles qui ne se confondent pas
Le directeur des systèmes d’information fait fonctionner le système d’information et le fait évoluer. Ses priorités sont la disponibilité, les projets, la qualité de service rendue aux utilisateurs. Le RSSI, lui, doit pouvoir poser des limites lorsque ces objectifs entrent en tension avec la sécurité : refuser une ouverture d’accès, imposer un délai pour corriger une vulnérabilité, demander qu’un projet intègre des exigences de sécurité avant sa mise en production.
Ces deux fonctions se complètent, mais elles ne peuvent pas toujours être exercées par la même personne sans que l’une prenne le pas sur l’autre. Quand un DSI cumule les deux rôles, la sécurité est souvent arbitrée au profit de la continuité de service et des délais de projet, par manque de temps et non par négligence. C’est une des raisons pour lesquelles une supervision continue des événements de sécurité, distincte de l’exploitation courante, apporte au RSSI la visibilité qu’il ne peut pas obtenir seul.
→ SOC cybersécurité : à quoi ça sert vraiment ?
À qui rattacher le RSSI
Le rattachement détermine la capacité d’action réelle de la fonction. Un RSSI placé sous l’autorité du DSI dépend de la personne dont il est censé challenger les arbitrages, ce qui limite sa marge de manœuvre. Un RSSI rattaché à la direction générale, ou disposant au minimum d’un accès direct à elle, peut porter un sujet jugé gênant sans passer par un intermédiaire.
Il n’existe pas de modèle unique. Dans une petite structure, un rattachement au DSI peut rester raisonnable si le dirigeant s’implique directement dans les décisions de sécurité. Dans une organisation plus grande, la direction générale gagne à s’informer elle-même du niveau de risque plutôt que de recevoir une synthèse filtrée.
Quand une organisation a-t-elle besoin d’un RSSI
Aucun seuil de taille ne tranche la question. Plusieurs signaux invitent à structurer la fonction : un système d’information étendu ou hétérogène, une activité exposée à des exigences réglementaires ou contractuelles, une dépendance forte aux outils numériques, des sites ou des entités multiples, ou le constat que personne n’a aujourd’hui la responsabilité explicite de la sécurité.
Le cadre réglementaire va dans le même sens. Le projet de loi de transposition de NIS2 exige, dans sa version initiale, un pilotage de la sécurité des réseaux et des systèmes d’information, incluant la formation à la cybersécurité des membres des organes de direction, sans imposer de fonction nommée. Une organisation concernée devra donc démontrer ce pilotage, et le RSSI en est l’incarnation la plus naturelle.
→ NIS2 : quelles obligations pour les PME et comment s’y préparer
Trois modèles d’organisation
Le RSSI interne
C’est le modèle le plus abouti : une personne dédiée, qui connaît l’entreprise, ses métiers et ses équipes, et peut peser dans les décisions au quotidien. Il demande un profil rare et un poste à plein temps, ce qui le réserve aux organisations dont la taille et l’exposition le justifient. Son principal risque est l’isolement : seul sur son sujet, sans équipe ni visibilité sur les événements de sécurité, il peut rapidement être débordé.
Le RSSI à temps partagé
Dans ce modèle, un RSSI intervient pour plusieurs structures, à raison de quelques jours par mois pour chacune. Il convient aux organisations qui ont besoin d’un pilotage sans justifier un poste complet. C’est aussi la logique de mutualisation que les collectivités explorent pour se doter de compétences qu’aucune ne pourrait financer seule.
→ Cybersécurité des collectivités territoriales : enjeux et obligations
Le RSSI externalisé
Il s’agit d’une prestation de conseil et de pilotage confiée à un partenaire spécialisé. Elle donne accès à une expertise et à une expérience de situations variées, sans recrutement. Sa limite tient à l’ancrage : un RSSI externe connaît moins finement l’organisation et dépend d’un interlocuteur interne qui porte le sujet au quotidien. Le modèle fonctionne le mieux lorsque l’entreprise désigne un correspondant sécurité clairement identifié, qui sert de relais.
→ Pourquoi externaliser sa cybersécurité en PME
Ces modèles ne s’excluent pas. Une ETI multi-sites peut associer un RSSI interne, des correspondants sécurité dans chaque site et un partenaire de supervision continue. C’est la logique décrite pour les entreprises de taille intermédiaire.
→ Cybersécurité des ETI : enjeux, gouvernance et obligations NIS2
Ce qui fait réussir ou échouer la fonction
Un RSSI se juge à ce qu’il peut décider, pas à son titre. Plusieurs conditions déterminent son efficacité : un mandat écrit qui précise son périmètre et son autorité, un budget lié à une analyse de risques plutôt que reconduit mécaniquement, un accès régulier à la direction, et une visibilité réelle sur ce qui se passe dans le système d’information.
→ Coût et ROI de la cybersécurité : comment raisonner son budget en PME
Les échecs suivent un schéma assez constant. Le RSSI nommé sans moyens ni autorité, dont la fonction sert surtout à rassurer sur le papier. Le cumul avec la direction informatique sans garde-fous, qui renvoie la sécurité au second plan dès que les projets s’accumulent. Le profil purement technique placé sur un poste de pilotage, ou à l’inverse le profil de gestionnaire sans compréhension des risques réels. Et la sécurité tenue à l’écart des projets, sollicitée seulement à la fin, quand les corrections coûtent le plus cher.
Ce qu’il faut retenir
La question n’est pas de savoir si une organisation peut s’offrir un RSSI, mais si quelqu’un porte aujourd’hui, explicitement et avec l’autorité nécessaire, la responsabilité de sa sécurité. Selon la taille, cette personne peut être un salarié, un expert partagé entre plusieurs structures ou un partenaire externe.
Ce qui compte, au bout du compte, c’est que la direction puisse répondre sans hésiter à une question simple : qui décide, dans cette organisation, quand la sécurité et l’activité ne vont pas dans le même sens ? Lorsque la réponse est claire, la fonction existe, quel que soit le titre inscrit sur la carte de visite.