Incident : qui prévenir, et en combien d’heures ?

Si vous éditez un logiciel en ligne (SaaS) pour des banques, des établissements de santé ou des industriels, vos clients ont des obligations de notification que vous n’avez pas toujours : ils doivent prévenir la Commission nationale de l’informatique et des libertés (CNIL), leur superviseur financier ou leur centre de réponse aux incidents de sécurité informatique (CSIRT) dans des délais comptés en heures. Une partie des informations dont ils ont besoin n’existe que chez vous.

Depuis le 11 septembre 2026, le Cyber Resilience Act (CRA) ajoute une quatrième horloge à celles du règlement général sur la protection des données (RGPD), de la directive NIS 2 et du règlement DORA. Ces quatre horloges ne partent pas du même événement, ne visent pas le même destinataire et ne s’appliquent pas toutes à vous.

L’ordre, lui, est presque toujours le même. Vos clients touchés d’abord, dès que l’incident est établi : votre message fait partir leurs propres délais, et le plus court, celui de DORA, peut expirer 4 heures plus tard. Ensuite, si vous y êtes soumis, le CSIRT, sous 24 heures, au titre du CRA ou, une fois la loi française adoptée, de NIS 2. Pour les données de vos clients, la CNIL et les superviseurs financiers ne sont pas vos interlocuteurs : vos clients les préviennent, avec ce que vous leur avez transmis.

Vos obligations, et celles de vos clients

Les obligations de vos clients vous concernent autant que les vôtres : ce sont vos informations qui leur permettent de les remplir.

NIS 2. Un éditeur SaaS de taille moyenne relève en principe de la directive au titre de l’informatique en nuage, comme nous l’expliquons dans notre article sur NIS 2. La France ne l’a pas encore transposée : ses délais s’imposeront aux entités françaises une fois la loi adoptée. Vos clients établis dans d’autres États membres peuvent déjà être soumis à ces délais. La directive prévoit aussi que vous informiez, le cas échéant, les destinataires de vos services des incidents importants qui peuvent nuire à leur fourniture (article 23).

DORA. Pour vos clients financiers, le règlement (UE) 2022/2554 s’applique à la place de NIS 2 pour la notification des incidents (considérant 28 de la directive). Il ne vous impose aucune notification à une autorité. Il oblige en revanche vos clients à inscrire dans votre contrat votre assistance en cas d’incident, sans frais supplémentaires ou à un coût fixé à l’avance. Si votre service soutient une fonction critique ou importante, c’est-à-dire une fonction dont la perturbation nuirait sensiblement à l’activité de votre client ou à sa conformité, le contrat fixe aussi vos obligations de notification envers lui (article 30). Notre article sur le temps que DORA prend à votre CTO présente les autres chantiers du règlement.

CRA. Selon les lignes directrices de la Commission européenne, une application web utilisée uniquement dans un navigateur n’est pas un produit au sens du CRA. Une application installée, un agent, une extension ou une bibliothèque cliente sont en revanche des produits, et la partie de votre service dont ils ont besoin est couverte avec eux : notre article sur le signalement CRA détaille ces cas.

HDS. Si vous hébergez des données de santé pour un établissement, vous-même ou par un hébergeur certifié, votre contrat doit prévoir, au titre de l’hébergement de données de santé (HDS), les modalités de signalement d’une violation de données et désigner le référent du client à contacter pour les incidents qui touchent les données hébergées (article R. 1111-11 du code de la santé publique). L’établissement doit en outre signaler sans délai ses incidents graves de sécurité des systèmes d’information à son agence régionale de santé (ARS), en vertu de l’article L. 1111-8-2 : un incident chez vous peut en faire partie.

Quatre horloges côte à côte

Deux moments font courir ces délais :

• La prise de connaissance (RGPD, NIS 2, CRA, et plafond de 24 heures de DORA) : le moment où vous avez un degré raisonnable de certitude qu’un incident a eu lieu. C’est la lecture du Comité européen de la protection des données (CEPD) pour le RGPD, de la Commission européenne pour le CRA, et du règlement d’exécution 2024/2690 pour les fournisseurs numériques soumis à NIS 2. Un premier soupçon ne la déclenche pas, mais appelle une évaluation immédiate. Pour une vulnérabilité, le CRA demande en plus des preuves fiables d’exploitation : une faille trouvée lors d’un test ne se déclare pas tant que rien ne montre qu’elle a été exploitée.
• La classification (DORA) : votre client notifie dans les 4 heures qui suivent le moment où il classe l’incident comme majeur, et au plus tard 24 heures après en avoir eu connaissance. S’il le classe au-delà de ces 24 heures, il dispose encore de 4 heures (article 5, paragraphe 2, du règlement délégué 2025/301).

Sous-traitant RGPD : « dans les meilleurs délais »

Le RGPD ne vous fixe pas de délai chiffré : « Le sous-traitant notifie au responsable du traitement toute violation de données à caractère personnel dans les meilleurs délais après en avoir pris connaissance » (article 33, paragraphe 2). Les lignes directrices 9/2022 du CEPD en précisent la lecture :

• Pas d’évaluation du risque avant de prévenir. Il vous suffit d’établir qu’une violation a eu lieu. Évaluer le risque pour les personnes revient à votre client.
• Une information rapide, puis échelonnée. Prévenez sans attendre, et complétez au fur et à mesure.
• Un message par client touché. Si l’incident touche plusieurs clients, chacun doit recevoir ce qui le concerne.

Votre client n’est en principe réputé avoir connaissance de la violation qu’une fois informé par vous : son délai de 72 heures part de votre message. Ce n’est pas pour autant une marge pour vous. Votre délai reste « dans les meilleurs délais », et le client consigne les faits de chaque violation (article 33, paragraphe 5) : le temps écoulé entre votre détection et votre message peut y apparaître.

Vos contrats ont souvent transformé cette formule en heures. L’article 28 impose un contrat de sous-traitance qui prévoit votre assistance : c’est là que vos clients inscrivent leur délai. Relisez ces accords de traitement des données (DPA) : votre procédure doit respecter le délai le plus court.

Prestataire d’un client DORA : ce qu’il attend de vous

Le premier rapport des autorités européennes de surveillance (AES) sur les incidents majeurs, publié le 3 juin 2026, en recense 3 383 en 2025, déclarés par les entités financières de l’Union. Les AES y appellent à une coordination étroite avec les prestataires pendant la réponse aux incidents. Quand l’incident a son origine chez vous, la notification initiale de votre client peut être due 4 heures après votre premier message, s’il classe l’incident aussitôt.

Pour classer l’incident, votre client applique le règlement délégué (UE) 2024/1772 (articles 8 et 9). Un incident est majeur s’il touche des services critiques et, en plus :

• soit s’il comporte un accès réussi, malveillant et non autorisé, susceptible d’entraîner des pertes de données ;
• soit s’il franchit au moins deux autres seuils, par exemple plus de 10 % des clients du service touchés, une interruption de plus de 2 heures d’un service qui soutient une fonction critique ou importante, une incidence dans au moins deux États membres ou plus de 100 000 euros de coûts et de pertes.

La notification initiale de votre client indique aussi l’heure et le mode de détection, l’origine de l’incident et les États membres touchés (article 2 du règlement délégué 2025/301). Votre premier message doit donc répondre, même partiellement, à ces questions :

• depuis quand le service est atteint, et s’il l’est encore ;
• quelles fonctions sont concernées, et lesquelles servent ce client ;
• si l’accès est malveillant et non autorisé, ou si rien ne permet encore de le dire ;
• quelles données de ce client sont en cause, et en quel volume ;
• dans quels pays le service est fourni et les données traitées.

Le rapport intermédiaire est dû 72 heures après la notification initiale, même si rien n’a changé. Le rapport final suit l’analyse des causes : votre client ne peut pas l’écrire sans votre analyse.

La règle du week-end ne vaut pas pour les banques

Lorsqu’un délai DORA expire un week-end ou un jour férié, l’entité financière peut soumettre sa notification ou son rapport au plus tard à midi le jour ouvrable suivant (article 5, paragraphe 4, du règlement délégué 2025/301). Ce report ne s’applique pas à la notification initiale ni au rapport intermédiaire des établissements de crédit, des contreparties centrales, des opérateurs de plateformes de négociation et des entités financières qui sont aussi des entités essentielles ou importantes au sens de NIS 2 (paragraphe 5). L’autorité compétente peut aussi l’écarter pour d’autres entités financières, importantes ou systémiques, après le leur avoir notifié (paragraphe 6).

Si vous vendez à une banque, le samedi ne vous donne aucun délai supplémentaire : votre astreinte doit pouvoir lui répondre à toute heure.

Un incident type, heure par heure

Un éditeur de logiciel de gestion documentaire a trois clients : une banque, une mutuelle et un groupe de cliniques. Un vendredi à 22 h 00, en temps universel coordonné (UTC), sa supervision signale des extractions de données inhabituelles depuis un compte du support.

Votre premier message établit déjà un accès malveillant et non autorisé : la banque pouvait classer l’incident dès H+2, et notifier avant H+6. Le deuxième message compte autant : il apporte les volumes et les pays que la notification initiale doit indiquer.

Une seule fiche pour les quatre régimes

Les quatre régimes demandent en grande partie les mêmes informations. Une seule fiche, ouverte à la première alerte et tenue par le responsable de l’incident, évite de reconstituer les faits client par client.

Écrivez aussi ce que vous ne savez pas encore. « Volume de données en cours d’évaluation, prochain point à 3 h 00 UTC » aide davantage votre client qu’un silence de six heures, et le RGPD admet une information échelonnée (article 33, paragraphe 4), que le CEPD admet aussi pour le sous-traitant. Le premier message à chaque client peut tenir en quelques lignes :

Objet : incident de sécurité, information n° 1, [date et heure UTC]

Le [date] à [heure] UTC, notre supervision a détecté [nature de l’événement]. À [heure] UTC, nous avons établi que [ce qui est établi, pour ce client].

Ce que nous ne savons pas encore : [volume de données, origine, durée…].

Mesures prises : [révocation, isolement…]. Ce que vous pouvez faire : [rotation de clés, vigilance…].

Prochain point : [heure] UTC, ou plus tôt si un fait nouveau le justifie. Contact joignable à toute heure : [nom, téléphone, adresse].

Exercer la procédure avant d’en avoir besoin

Toutes ces horloges partent de ce que vous savez. Le 29 septembre, l’Agence nationale de la sécurité des systèmes d’information (ANSSI) a publié son rapport sur les cyberattaques qui ont touché la Direction générale des finances publiques (DGFiP) à l’été 2026. Elle y constate qu’aucune de ces exfiltrations n’a été détectée, ni par les dispositifs de la DGFiP, ni par les siens. Un délai de 24 heures ne compense pas une détection qui prend des semaines : la supervision fait partie de la procédure d’incident.

Un exercice de deux heures sur un scénario fictif révèle les lacunes d’une procédure plus sûrement qu’une relecture :

1. Un scénario. Il touche plusieurs clients, soumis à des régimes différents, un vendredi soir.
2. Une horloge. Notez l’heure de chaque décision et de chaque message, puis comparez ces heures aux délais de vos contrats.
3. Des contacts. Pour chaque client, un contact incident à jour et joignable le week-end ; votre assureur et sa ligne d’assistance.
4. Des modèles. Le premier message au client, les messages suivants, l’alerte précoce NIS 2 ou CRA si vous y êtes soumis.
5. Des comptes. Pour le CRA, au moins deux personnes avec un compte EU Login actif.

Tenir 24 heures demande des noms : qui qualifie, qui décide, qui prévient les clients, et qui les remplace.

Ce que nous prenons en charge

Si personne ne porte la sécurité chez vous, nous tenons le rôle de responsable de la sécurité des systèmes d’information (RSSI) : c’est notre offre RSSI externalisé. Nous recensons vos clients et les délais de vos contrats, rédigeons la procédure d’incident et ses modèles, menons l’exercice avec vous et vous accompagnons pendant un incident réel. Un workshop hebdomadaire d’une heure fait le point, avec un suivi en asynchrone entre deux workshops. Vos équipes gardent la main sur la technique. Recruter ou externaliser ce rôle ? Notre article sur le RSSI à temps partagé compare les deux.

Si vous avez déjà un RSSI ou une équipe sécurité, le pilotage leur revient avec notre offre Accompagnement à la conformité : nous apportons notre lecture des textes et rédigeons avec eux la procédure et la fiche incident. Si vous ne savez pas encore quels régimes vous visent, commencez par une analyse d’écarts : elle établit lesquels s’appliquent à vous, directement ou par vos clients, et ce qui manque à votre procédure. Nos pages DORA, NIS 2 et CRA détaillent chaque démarche.

Questions fréquentes

Faut-il prévenir un client que l’incident ne touche pas ?

Pas au titre du RGPD : seuls les clients dont les données sont touchées doivent être informés. Si vous êtes une entité NIS 2, la directive prévoit en revanche que vous informiez les destinataires de vos services lorsqu’un incident important peut nuire à leur fourniture (une interruption, par exemple), même si aucune donnée n’est touchée. Vos contrats peuvent aller plus loin.

Pouvons-nous notifier à la place de notre client ?

Oui, si le contrat le prévoit, mais la responsabilité reste la sienne. Le CEPD admet qu’un sous-traitant notifie la CNIL pour le compte du responsable du traitement, s’il y est autorisé. DORA permet de même à une entité financière d’externaliser ses obligations de déclaration, en restant pleinement responsable de leur respect (article 19, paragraphe 5).

Faut-il prévenir notre assureur et porter plainte ?

Si vous avez une assurance cyber, oui, et vite : le contrat fixe souvent un délai de déclaration et une assistance à appeler avant d’engager des frais. L’indemnisation des pertes causées par une cyberattaque suppose aussi une plainte déposée au plus tard 72 heures après la connaissance de l’atteinte (article L. 12-10-1 du code des assurances). Inscrivez l’assureur et la plainte dans votre procédure, avec leurs délais.

Par où commencer

Trois actions suffisent pour démarrer : lister vos clients avec leur régime et le délai de leur contrat, préparer la fiche incident et le premier message au client, puis désigner l’astreinte qui enverra ce message un samedi soir. L’exercice viendra ensuite.

Pour savoir ce que vos clients attendent de vous et en combien d’heures, parlons de votre procédure d’incident : si nos offres ne sont pas encore pertinentes pour vous, nous vous le dirons.