Quelle responsabilité personnelle en cas d’inaction cyber ?

Une attaque réussie n’est pas une preuve automatique de faute

Le niveau de sécurité doit être apprécié à partir des obligations applicables, de l’état de l’art, du risque, des moyens et des alertes réellement disponibles. La CNIL rappelle la nécessité d’un pilotage documenté, d’habilitations, de journalisation et d’une amélioration continue. CNIL — Piloter la sécurité des données

Une architecture en huit questions

1. Qui disposait du pouvoir de décision ou d’allocation ?
2. Quelle obligation particulière s’appliquait ?
3. Le risque critique était-il objectivement établi ?
4. Le responsable en avait-il connaissance ?
5. Avait-il les moyens d’agir ou au moins d’escalader ?
6. L’omission a-t-elle persisté au-delà du délai raisonnable ?
7. Existait-il un motif légitime ?
8. Quel lien causal relie l’omission à l’atteinte ou à l’exposition grave ?

L’article 121-3 du Code pénal sert de référence utile pour réfléchir à une faute caractérisée ou à la violation manifestement délibérée d’une obligation particulière. Légifrance — Code pénal, article 121-3

NIS2 comme modèle de gouvernance

NIS2 attribue aux organes de direction un rôle d’approbation et de supervision des mesures de gestion des risques cyber. Ce modèle montre comment passer d’un vague « l’organisation savait » à une chaîne où les décisions et responsabilités sont attribuables. EUR-Lex — Directive (UE) 2022/2555 NIS2

Safe harbors : protéger celui qui alerte correctement

Conditions d’une responsabilité cyber personnelle défendable

Une compromission ne suffit jamais, à elle seule, à démontrer une faute. La question juridique doit porter sur une abstention ou un manquement personnellement imputable, suffisamment précis et documenté.

1. Pouvoir effectif. La personne disposait d’un pouvoir de décision, de supervision, d’allocation budgétaire ou au minimum d’un pouvoir formel d’escalade.
2. Obligation identifiable. Loi, règlement, référentiel rendu obligatoire, prescription d’une autorité, plan de remédiation approuvé ou engagement formalisé.
3. Risque critique établi. Audit, incident antérieur, AIPD, alerte RSSI/DPO, injonction ou constat technique formalisé.
4. Connaissance. Le responsable savait, ou ne pouvait raisonnablement ignorer, la gravité du risque.
5. Capacité raisonnable d’agir. Une mesure, une réduction du risque ou une escalade était réellement possible.
6. Omission persistante et injustifiée. Ni correction, ni décision motivée, ni acceptation de risque par l’autorité compétente dans le délai applicable.
7. Conséquence ou exposition grave. Atteinte massive aux données, rupture importante de service, préjudice financier ou risque majeur pour une mission essentielle.
8. Lien causal. L’omission a contribué de manière suffisamment directe à l’exposition ou au dommage.

NIS2 : gouverner la cybersécurité au niveau où se prennent les décisions

La directive NIS2 fournit un modèle utile : les organes de direction doivent approuver les mesures de gestion des risques cyber et en superviser la mise en œuvre. Cette logique évite de faire porter la totalité de la responsabilité sur le technicien ou le RSSI alors que les arbitrages déterminants peuvent concerner les budgets, les priorités et les délais.

La loi ne devrait pas figer un produit technique dans le Code pénal. Elle devrait définir le devoir de gouvernance, de décision, d’escalade et de contrôle ; les mesures techniques détaillées doivent rester dans des référentiels évolutifs.

Audit critique → remédiation → escalade → acceptation du risque

Le but est de pouvoir répondre après coup à des questions simples : qui savait ? quand ? qui avait le budget ? qui pouvait arrêter ou différer le système ? qui a accepté le risque résiduel ? qui a demandé la correction ? Une responsabilité individuelle ne peut être juste que si l’organisation produit ces traces avant l’incident.

Ne pas confondre intrusion, violation constatée et notification

Pour les violations de données personnelles, la chronologie doit distinguer la détection d’une intrusion, la confirmation qu’une violation de données s’est produite, la notification à la CNIL et l’information des personnes lorsque celle-ci est requise. Accuser mécaniquement une organisation à partir de la seule date de la première alerte technique peut être juridiquement trompeur.

Le Portail pourrait au contraire publier, lorsque cela est légalement possible, quatre dates distinctes : détection, qualification, notification et remédiation, avec une explication des écarts plutôt qu’un verdict automatique.

NIS2 : un modèle de gouvernance, pas une liste figée d’outils

La directive NIS2 est utile parce qu’elle place la cybersécurité au niveau de la gouvernance. Ses articles 20 et 21 demandent aux organes de direction d’approuver et de superviser les mesures de gestion des risques cyber, tandis que les mesures techniques et organisationnelles doivent rester proportionnées aux risques. Pour Delta-Sierra, l’idée à reprendre n’est pas de graver un produit ou une technologie dans le Code pénal : c’est d’exiger une décision documentée, un responsable, un calendrier de correction et une capacité d’escalade.

Neuf critères avant toute responsabilité personnelle

1. Une personne identifiée disposait d’un pouvoir de décision, d’allocation ou d’escalade.
2. Une obligation précise ou une mesure de remédiation était identifiable.
3. Le risque était suffisamment grave et documenté.
4. Le responsable en avait connaissance ou ne pouvait raisonnablement l’ignorer.
5. Une action ou une escalade était matériellement possible.
6. L’omission a persisté au-delà du délai raisonnable ou prescrit.
7. Aucun motif légitime ne justifiait l’inaction.
8. Une conséquence ou une exposition grave peut être caractérisée.
9. Le lien entre l’omission et l’exposition est suffisamment établi.

Cette grille évite deux erreurs symétriques : considérer qu’une cyberattaque prouve automatiquement une faute, ou conclure au contraire que personne ne peut jamais répondre d’une inaction documentée.

Audit → remédiation → escalade → acceptation du risque → réexamen

Le mécanisme proposé impose qu’un constat critique débouche sur un propriétaire, une échéance et une décision. Lorsque l’équipe technique ne possède pas le budget, le risque remonte. Lorsque l’autorité supérieure décide de ne pas corriger immédiatement, elle doit motiver l’acceptation du risque résiduel et fixer la prochaine revue. La responsabilité ne se dissout alors plus dans la formule « le service savait ».

Continuer la lecture

Dossier maître : responsabilité personnelle des décideurs publics · Contrôler les dépenses publiques · Portail de données publiques

Article 226-17 : une obligation pénale de sécurité existe déjà, mais elle ne résout pas toute la gouvernance cyber

Le droit pénal français sanctionne déjà certains manquements à la sécurité des données personnelles. L’article 226-17 du Code pénal réprime le fait de procéder ou faire procéder à un traitement sans mettre en œuvre les mesures prescrites par le droit applicable à la protection des données. Ce texte ne constitue toutefois pas un régime général de responsabilité de tous les dirigeants publics en matière de cybersécurité : son champ, ses éléments constitutifs et la personne à laquelle le manquement peut être imputé doivent être analysés dans chaque cas.

La réforme proposée ne doit donc pas présenter l’article 226-17 comme une solution universelle. Elle ajoute une architecture de gouvernance : qui reçoit l’audit, qui arbitre le budget de remédiation, qui accepte le risque résiduel, qui fixe l’échéance et qui doit être alerté lorsqu’une recommandation critique reste ouverte. La responsabilité ne naît pas de l’existence d’une attaque mais de la violation d’un devoir déterminé et personnellement imputable.

La référence pénale doit être reliée au Code pénal sur Légifrance, tandis que la gouvernance opérationnelle peut s’appuyer sur les recommandations de la CNIL pour piloter la sécurité des données.

ANSSI, RSSI, DPO et direction : chacun voit une partie différente du risque

Une alerte ANSSI, un audit du RSSI, une analyse d’impact du DPO ou une recommandation d’un prestataire ne produisent pas automatiquement la même obligation. Le dispositif doit qualifier le niveau de criticité, la compétence de l’émetteur, la précision de la recommandation et les conséquences d’une non-remédiation. Le décideur qui n’a pas le budget doit pouvoir escalader formellement plutôt que devenir responsable d’un choix budgétaire qu’il ne maîtrise pas.

Inversement, l’échelon qui dispose réellement du budget ou du pouvoir d’arbitrage ne doit pas pouvoir renvoyer indéfiniment le risque vers le RSSI. Une « acceptation du risque » critique devrait devenir une décision signée, limitée dans le temps, accompagnée de mesures compensatoires et automatiquement réexaminée. Le Portail n’en publierait que les métadonnées non sensibles : date, niveau de risque, statut, échéance, autorité responsable et existence d’un plan, jamais la vulnérabilité exploitable.