Délais de notification

Au moment où l'entité a connaissance de l'incident important, et non au début de l'incident. L'article 23, paragraphe 4, compte à partir de ce moment l'alerte précoce (24 heures) comme la notification d'incident (72 heures).

Selon l'article 23, paragraphe 4, point a), l'alerte précoce indique, le cas échéant, si l'on soupçonne que l'incident important est causé par des actes illicites ou malveillants et s'il pourrait avoir un impact transfrontière. Les détails suivent dans la notification à 72 heures.

Non : un mois après l'envoi de la notification d'incident. Si l'incident est encore en cours à ce moment, un rapport d'avancement est dû à la place, et le rapport final dans le mois qui suit le traitement de l'incident.

Oui. Un prestataire de services de confiance notifie les incidents importants qui ont un impact sur la fourniture de ses services de confiance dans les 24 heures après en avoir eu connaissance, au lieu de 72 heures.

Selon l'article 33 du RGPD, le responsable du traitement notifie la violation de données à caractère personnel à l'autorité de contrôle dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance, sauf si elle n'est pas susceptible d'engendrer un risque pour les personnes. Selon l'article 34, lorsqu'elle est susceptible d'engendrer un risque élevé, les personnes concernées doivent être informées dans les meilleurs délais. NetSenX prépare pour votre DPO une notification au titre de l'article 33 ; la décision et l'envoi vous reviennent.

L'article 14 du règlement sur la cyberrésilience oblige les fabricants de produits comportant des éléments numériques à notifier, en plusieurs étapes, les vulnérabilités activement exploitées de leurs produits et les incidents graves qui affectent la sécurité de ces produits. Pour les étapes, leurs délais et les destinataires des notifications, voir le règlement (UE) 2024/2847, article 14. Ces obligations de déclaration s'appliquent à partir du 11 septembre 2026. Elles concernent les fabricants, pas les entreprises qui se contentent d'utiliser les produits, même si l'incident propre d'un utilisateur peut devoir être notifié au titre de NIS2 ou du RGPD.

DORA, le règlement sur la résilience opérationnelle numérique (règlement (UE) 2022/2554), s'applique depuis le 17 janvier 2025 aux entités financières telles que banques, assureurs, entreprises d'investissement et établissements de paiement, ainsi qu'aux prestataires tiers critiques de services TIC désignés à ce titre. L'article 19 impose aux entités financières de notifier les incidents majeurs liés aux TIC à leur autorité compétente, par une notification initiale, un rapport intermédiaire et un rapport final ; les délais sont fixés par des normes techniques adoptées en vertu de l'article 20. Pour une entité financière, les règles de DORA sur les incidents TIC priment sur les règles générales de NIS2. Si vous fournissez des services TIC à une entité financière, DORA vous atteint par le contrat : l'article 30 liste les clauses que ces contrats doivent contenir, dont l'assistance en cas d'incident, les droits d'audit et les plans de sortie. Attendez-vous à des questions détaillées et à des clauses de la part de clients financiers.

Un incident qui a causé ou est susceptible de causer une perturbation opérationnelle grave de vos services ou des pertes financières pour votre entreprise, ou qui a affecté ou est susceptible d'affecter d'autres personnes ou organisations en causant des dommages matériels ou moraux considérables. C'est le critère de l'article 23, paragraphe 3, et seuls les incidents importants doivent être notifiés. Susceptible de signifie qu'on n'attend pas que le dommage survienne. Pour certains fournisseurs numériques, comme les fournisseurs cloud, DNS et de services gérés, le règlement d'exécution (UE) 2024/2690 fixe des seuils plus précis ; pour les autres, les lois et autorités nationales peuvent publier des lignes directrices. Fixez à l'avance, dans votre procédure de gestion des incidents, les critères retenus, comme une indisponibilité au-delà d'une certaine durée, des données clients touchées ou un acteur criminel en cause, et qui décide. NetSenX suit les délais une fois la décision prise ; la décision vous revient.

En général pas comme incident important, mais cela peut arriver, et vous pouvez toujours la signaler volontairement. L'obligation de l'article 23 vise les incidents importants : ceux qui ont causé, ou auraient pu causer, une perturbation grave, des pertes financières ou des dommages considérables pour d'autres. Une attaque stoppée avant tout effet ne remplit normalement pas ce critère, mais une attaque passée tout près, par exemple un rançongiciel repéré alors qu'il avait déjà atteint le serveur de sauvegarde, peut le remplir. NIS2 distingue aussi les incidents évités et les cybermenaces importantes, et l'article 30 permet de les notifier volontairement, ce qui aide le CSIRT à prévenir d'autres organisations. Consignez chaque événement de ce type dans votre registre avec votre raisonnement, pour pouvoir expliquer ensuite pourquoi vous avez notifié ou non. NetSenX conserve les alertes derrière chaque décision.

En préparant à l'avance tout ce qui ne dépend pas de l'incident. L'alerte précoce de l'article 23, paragraphe 4, point a), est courte : elle indique qu'un incident important s'est produit et, le cas échéant, si l'on soupçonne un acte illicite ou malveillant et s'il pourrait avoir un impact transfrontière. Les détails suivent dans la notification à 72 heures. Préparez donc un modèle d'une page, le canal de notification et l'accès à votre CSIRT ou autorité nationale, une personne désignée et un suppléant habilités à l'envoyer, et une règle interne sur qui décide qu'un incident est important. Faites une répétition par an. Les petites équipes perdent surtout du temps à comprendre ce qui s'est passé : veillez à ce que les alertes atteignent quelqu'un la nuit et le week-end. NetSenX lance le compte à rebours par incident et garde les alertes avec heure, appareils et destinations au même endroit.

Une courte liste de faits, un canal prêt et une personne habilitée à envoyer. Pour l'alerte précoce elle-même, il faut : l'heure à laquelle vous avez eu connaissance de l'incident ; une description simple de ce qui est touché à ce stade ; si vous soupçonnez un acte malveillant ou illicite ; et si d'autres pays pourraient être concernés. Pour la notification à 72 heures qui suit, commencez tout de suite à rassembler : gravité et impact, systèmes et services touchés, indicateurs de compromission comme des adresses malveillantes ou des empreintes de fichiers, et mesures prises. Tenez dès la première minute une chronologie de qui a fait quoi. Vérifiez si des données personnelles sont en jeu, car une notification RGPD peut courir en parallèle. NetSenX fournit la partie réseau de cette chronologie : première connexion inhabituelle, appareils impliqués, destinations et volumes, et délais de l'article 23 comptés à partir du moment de connaissance que vous enregistrez.

Parfois. Selon l'article 23, paragraphe 1, le cas échéant, les entités concernées informent sans retard injustifié les destinataires de leurs services des incidents importants susceptibles de nuire à la fourniture de ces services. Selon l'article 23, paragraphe 2, s'il y a lieu, elles communiquent aussi aux destinataires potentiellement touchés par une cybermenace importante les mesures qu'ils peuvent prendre, et le cas échéant la menace elle-même. Les autorités peuvent aussi ordonner cette information. Le droit national précise les détails : en Allemagne, le BSI peut ordonner d'informer les destinataires (article 35, paragraphe 1, du BSIG), et les entités de secteurs comme la finance, les infrastructures numériques et la gestion des services TIC doivent les informer des cybermenaces importantes (article 35, paragraphe 2). Les contrats et le RGPD peuvent ajouter leurs propres obligations. Préparez un modèle de message aux clients dans le plan de réponse.

Souvent oui, si des données personnelles sont touchées, même si rien n'a été volé. Le RGPD définit à l'article 4, point 12, la violation de données à caractère personnel comme une violation de la sécurité entraînant, de manière accidentelle ou illicite, la destruction, la perte, l'altération, la divulgation non autorisée de données personnelles ou l'accès non autorisé à celles-ci. Le chiffrement par un rançongiciel rend les données indisponibles, ce qui est une violation de disponibilité, et les attaquants copient souvent les données avant de chiffrer. Selon l'article 33, le responsable du traitement notifie l'autorité de contrôle dans les meilleurs délais et, si possible, dans les 72 heures après en avoir pris connaissance, sauf si la violation n'est pas susceptible d'engendrer un risque pour les personnes, par exemple parce qu'une sauvegarde récente a tout restauré rapidement et que rien n'est sorti du réseau. Documentez le raisonnement dans tous les cas. NetSenX peut montrer si des envois inhabituels sont partis d'appareils surveillés avant le chiffrement, ce qui compte pour cette appréciation.

Peut-être l'autorité, mais souvent pas les personnes concernées. L'article 34, paragraphe 3, point a), du RGPD dispense d'informer les personnes si le responsable avait mis en œuvre des mesures, comme le chiffrement, rendant les données incompréhensibles pour toute personne non autorisée. La notification à l'autorité de contrôle selon l'article 33 est une question distincte : elle s'impose sauf si la violation n'est pas susceptible d'engendrer un risque pour les personnes, ce qui dépend de la robustesse du chiffrement, de l'exposition éventuelle de la clé et de la disponibilité des données pour vous. Si la clé se trouvait sur le même portable volé, ou si le chiffrement était faible, traitez les données comme exposées. Notez quelles données étaient chiffrées, comment, et où étaient les clés. Des preuves réseau sur ce qui est sorti, et quand, aident votre DPO à trancher.

Oui par étapes, et en retard seulement avec des motifs. L'article 33, paragraphe 4, du RGPD permet de communiquer les informations de manière échelonnée, sans autre retard indu, lorsqu'il n'est pas possible de les fournir toutes en même temps, et l'article 33, paragraphe 1, impose qu'une notification faite après 72 heures soit accompagnée des motifs du retard. N'attendez donc pas d'avoir toute la vision : envoyez dans le délai une notification initiale avec ce que vous savez, la nature de la violation, les conséquences probables, les mesures prises et les coordonnées de votre DPO, puis complétez au fil des constats. Gardez une trace du moment où vous en avez pris connaissance et de la raison de chaque complément tardif. Les autorités proposent en général des formulaires en ligne permettant des compléments, comme la CNIL en France. NetSenX prépare une notification au titre de l'article 33 pour votre DPO à partir des données de l'incident ; l'envoi vous revient.

Quand le responsable du traitement prend connaissance de la violation de données, pas quand la violation a commencé. L'article 33, paragraphe 1, compte les 72 heures à partir de la prise de connaissance. Les lignes directrices du Comité européen de la protection des données considèrent qu'un responsable en a connaissance lorsqu'il a un degré raisonnable de certitude qu'un incident de sécurité s'est produit et a compromis des données personnelles. Une courte enquête initiale pour l'établir est admise, mais elle doit être rapide ; on ne retarde pas la prise de connaissance en évitant de regarder. Un sous-traitant qui découvre une violation doit en informer le responsable dans les meilleurs délais (article 33, paragraphe 2), et le délai du responsable court en général à partir de ce moment. Notez donc dans votre registre l'heure exacte à laquelle quelqu'un a conclu que des données personnelles étaient en jeu. NetSenX permet d'enregistrer ce moment par incident et conserve les alertes qui montrent quand l'activité a commencé.

Chaque texte a sa propre notification, son destinataire et son délai, et un incident peut en déclencher plusieurs. Un incident important dans une entité concernée va au CSIRT ou à l'autorité compétente au titre de l'article 23 de NIS2 ; si des données personnelles sont touchées, le responsable du traitement notifie aussi l'autorité de protection des données selon l'article 33 du RGPD ; une entité financière notifie les incidents majeurs liés aux TIC au titre de l'article 19 de DORA à la place de NIS2 ; et un fabricant de produits peut avoir des obligations au titre du règlement sur la cyberrésilience, voir le règlement (UE) 2024/2847, article 14. Certains systèmes nationaux offrent un portail unique, mais ne supposez pas qu'une notification couvre tout. Tenez un seul dossier d'incident et produisez chaque notification à partir de lui, pour que les faits concordent. L'article 35 de NIS2 demande aussi aux autorités NIS2 d'informer les autorités de protection des données des violations dont elles ont connaissance. NetSenX suit les délais NIS2 et prépare un projet de notification RGPD article 33 à partir des mêmes données d'incident.

Un incident qu'une entité financière classe comme majeur selon les critères de l'article 18 de DORA et les normes techniques adoptées en application. L'article 18 cite des critères comme le nombre et l'importance des clients ou contreparties financières touchés, le montant ou le nombre de transactions affectées, l'atteinte à la réputation, la durée et l'indisponibilité du service, l'étendue géographique, les pertes de données affectant disponibilité, authenticité, intégrité ou confidentialité, la criticité des services touchés et l'impact économique. Les normes les traduisent en seuils. Seuls les incidents majeurs doivent être notifiés au titre de l'article 19 ; les cybermenaces importantes peuvent l'être volontairement. Intégrez la classification à votre procédure d'incident, pour que la décision soit rapide, reproductible et documentée, et convenez avec vos prestataires TIC de la façon dont ils vous transmettront les faits nécessaires. Les clients financiers attendront la même chose de leurs fournisseurs.

Ils figurent dans les normes techniques adoptées en vertu de l'article 20 de DORA, pas dans le texte du règlement lui-même : consultez ces normes et les indications de votre autorité compétente pour les heures et jours exacts. L'article 19, paragraphe 4, fixe la séquence : une notification initiale, un rapport intermédiaire dès que le statut de l'incident initial a changé de manière significative ou que son traitement a évolué au vu de nouvelles informations, suivi de notifications mises à jour selon les besoins, et un rapport final une fois l'analyse des causes profondes achevée. Les normes fixent aussi le contenu et les modèles. Comme les délais sont liés à la détection de l'incident et à sa classification comme majeur, la rapidité de la classification compte autant que celle de la rédaction. Si vous êtes prestataire TIC d'une entité financière, attendez-vous à ce que votre contrat vous impose de prévenir le client assez vite pour qu'il tienne ces délais.

Par la plateforme unique de signalement que l'ENISA exploite pour le règlement sur la cyberrésilience. Selon l'article 14 du règlement (UE) 2024/2847, les fabricants de produits comportant des éléments numériques notifient par cette plateforme les vulnérabilités activement exploitées de leurs produits et les incidents graves ayant un impact sur leur sécurité ; la notification va au CSIRT désigné comme coordinateur dans l'État membre de l'établissement principal du fabricant et à l'ENISA. Pour les étapes, délais et contenus, voir le règlement (UE) 2024/2847, article 14. Ces obligations visent les fabricants, y compris les éditeurs de logiciels qui mettent des produits sur le marché de l'UE, pas les entreprises qui ne font qu'utiliser les produits. Les utilisateurs peuvent avoir leurs propres notifications NIS2 ou RGPD après le même événement. Si vous développez des logiciels, mettez en place un processus de gestion des vulnérabilités et décidez qui accède à la plateforme avant d'en avoir besoin.

Souvent oui, mais c'est une décision distincte des notifications réglementaires. Une attaque par rançongiciel, un vol de données, une fraude ou une extorsion est en général une infraction, et une plainte peut aider pour la déclaration de sinistre, pour la banque qui tente de rappeler un virement frauduleux et pour les enquêtes qui relient votre cas à d'autres ; certains assureurs demandent un récépissé de plainte. Une plainte ne remplace pas les notifications au CSIRT, à l'autorité compétente ou à l'autorité de protection des données, et celles-ci ne remplacent pas une plainte. Beaucoup de pays disposent d'unités spécialisées ou de formulaires en ligne ; en France, la plateforme cybermalveillance.gouv.fr oriente les victimes. Avant de déposer plainte, convenez avec vos avocats et votre prestataire de réponse des preuves à remettre et de la façon de les préserver, pour ne pas détruire ce dont les enquêteurs ont besoin. L'alerte précoce NIS2 demande déjà si vous soupçonnez un acte illicite ou malveillant ; votre réponse et la plainte doivent concorder.

Les bases sont partout les mêmes : ce qui s'est passé, quand, ce qui est touché, la gravité, ce que vous avez fait et qui contacter. Selon l'article 23, paragraphe 4, de NIS2, l'alerte précoce indique si l'on soupçonne un acte malveillant ou illicite et si l'incident pourrait avoir un impact transfrontière ; la notification à 72 heures ajoute une première évaluation de la gravité et de l'impact et, s'ils sont disponibles, des indicateurs de compromission ; et le rapport final ajoute une description détaillée, le type de menace ou la cause profonde, les mesures d'atténuation et l'impact transfrontière. Selon l'article 33, paragraphe 3, du RGPD, la notification décrit la nature de la violation, les catégories et le nombre approximatif de personnes et d'enregistrements, les conséquences probables, les mesures prises et les coordonnées du DPO. Séparez clairement faits et hypothèses. NetSenX fournit depuis le réseau les heures, appareils, destinations et volumes.

Oui, s'il était important ou s'il constituait une violation de données personnelles à notifier ; le corriger ne supprime pas l'obligation. L'article 23 de NIS2 attache l'obligation de notification à l'incident important, qu'il soit en cours ou non, et les délais courent à partir du moment où vous en avez eu connaissance. Si vous découvrez seulement maintenant que la panne du mois dernier était une attaque, le délai commence à cette découverte, et vous devez notifier rapidement en expliquant la chronologie. Selon le RGPD, une violation susceptible d'engendrer un risque pour les personnes doit être notifiée même si elle a été maîtrisée ; la maîtrise peut réduire le risque et influencer le contenu. Un incident résolu peut en général être notifié directement avec les faits déjà connus, mais suivez le format de votre autorité. Notez séparément les dates de survenance, de connaissance et de résolution.

Surtout ce que vous avez fait avant et après : une notification rapide, une vraie atténuation et la coopération. L'article 83, paragraphe 2, du RGPD liste les facteurs que pèsent les autorités, dont la nature, la gravité et la durée de la violation, son caractère délibéré ou négligent, les mesures prises pour atténuer le dommage subi par les personnes, les mesures techniques et organisationnelles déjà en place, les violations antérieures, le degré de coopération avec l'autorité, les catégories de données concernées et la manière dont l'autorité a eu connaissance de la violation, notamment si vous l'avez notifiée. Pour les violations les plus graves, les amendes peuvent atteindre 20 millions d'euros ou 4 % du chiffre d'affaires annuel mondial selon l'article 83, paragraphe 5. En pratique : notifier à temps avec des faits, montrer les mesures de sécurité existantes, contenir vite la violation, informer les personnes quand c'est requis et documenter chaque étape. NetSenX aide pour la chronologie et avec un projet de notification article 33 pour votre DPO.

Oui, sous forme de projet pour votre DPO ; décider et transmettre vous reviennent. À partir des données de l'incident, NetSenX prépare un projet avec ce que montre le réseau : quand le problème a été détecté et quels appareils et destinations étaient en cause. L'article 33, paragraphe 3, demande aussi des informations que vous seul détenez, comme les catégories et le nombre approximatif de personnes et d'enregistrements concernés, les conséquences probables, les mesures prises et les coordonnées de votre DPO. Les preuves réseau ont des limites : NetSenX voit des connexions, des volumes et des destinations, pas quels fichiers ou enregistrements sont sortis, donc le DPO doit compléter le contenu à partir d'autres sources. Le projet fait gagner du temps le vendredi soir quand le délai de 72 heures court, et garde les faits cohérents avec vos notifications NIS2. Vérifiez-le, complétez-le et déposez-le vous-même auprès de votre autorité de contrôle.

Oui, pour la partie des contrôles qui concerne l'outil lui-même. Les commissaires aux comptes et les auditeurs ISO ou SOC 2 testent les contrôles généraux informatiques : qui a accès aux systèmes, comment les changements sont approuvés et tracés, comment l'exploitation et les incidents sont surveillés. Le journal d'audit d'un outil de sécurité apporte des preuves pour sa propre part : qui a des comptes, qui a modifié les réglages de détection ou les règles de notification, qui a clôturé ou décidé chaque alerte, et quand. Dans toutes les offres, NetSenX tient un tel journal d'audit, avec une conservation qui augmente avec l'offre. Il n'enregistre pas les changements dans votre ERP, vos serveurs de fichiers ou d'autres systèmes, qui ont besoin de leurs propres journaux. Exportez l'extrait de la période auditée et rapprochez-le de vos revues d'accès et tickets de changement, pour que l'auditeur voie un ensemble cohérent.

Avec un journal d'audit qui enregistre chaque changement, son auteur et l'heure, conservé là où il ne peut pas être modifié discrètement. Pour vos propres systèmes, cela veut dire activer la journalisation des changements sur les pare-feu, les annuaires, les consoles cloud et les outils de sécurité, envoyer les journaux vers un endroit central à accès restreint et relier les changements à des tickets approuvés. Les comptes d'administration partagés rendent toute preuve impossible : donnez à chacun un compte nominatif avec authentification multifacteur. Examinez les journaux pour repérer les changements inattendus, surtout hors des heures de travail. Pour NetSenX lui-même, le journal d'audit de toutes les offres enregistre qui a modifié les réglages de détection, les règles de notification ou les membres de l'équipe et qui a décidé des alertes, avec horodatage ; vous pouvez en exporter l'extrait pour un auditeur. Il couvre les changements faits dans NetSenX, pas les réglages de vos autres systèmes.

Avec un état de couverture simple, étayé par des preuves, angles morts compris. Listez chaque site et chaque segment réseau, s'il est observé par un capteur ou un agent, depuis quand et ce qu'il couvre ; indiquez ensuite ce qui ne l'est pas, comme le Wi-Fi invités, une agence ou un environnement cloud, et comment vous le traitez autrement. Joignez des preuves : la liste des capteurs, une alerte récente de chaque segment surveillé et la carte réseau. Les auditeurs font davantage confiance à une déclaration honnête aux limites connues qu'à une prétention de couverture totale qui s'effondre à la première question. Avec NetSenX, un agent sur le port miroir d'un commutateur (SPAN) ou sur un TAP réseau observe tout un segment, et le tableau de bord montre quels agents tournent où ; le trafic d'un segment non mis en miroir reste invisible, et NetSenX ne prétend pas le contraire.

Tout ce qui se passe uniquement à l'intérieur de ce segment. Un capteur voit le trafic qu'il reçoit ; si un port de commutateur n'est pas recopié vers lui et qu'aucun agent ne tourne sur les hôtes du segment, les connexions entre appareils de ce segment, comme un attaquant passant d'un PC au serveur de fichiers voisin, restent invisibles. Vous verrez peut-être encore le trafic qui quitte le segment par un point surveillé, vers internet ou un autre site, mais les étapes internes d'une intrusion sont souvent justement ce qu'il faut voir. Décidez selon le risque : mettez d'abord en miroir les segments des serveurs, de l'administration, de la finance, des RH et de la production, puis le reste. Là où c'est impraticable, faites tourner l'agent sur les hôtes importants eux-mêmes. NetSenX montre quels segments ses capteurs et agents observent, pour que les angles morts soient visibles.

Assez pour reconstituer chaque incident et chaque décision sans faire appel à la mémoire de quiconque. Pour chaque entrée : une référence unique ; quand l'incident a commencé, quand et par quoi il a été détecté, et quand il a été qualifié d'important ou non ; une courte description et les systèmes, services et données touchés ; l'évaluation de la gravité et son auteur ; s'il a été notifié, à qui et à quelles heures, avec copie des notifications ; les étapes de confinement, d'éradication et de rétablissement avec heures et responsables ; la cause profonde ; et les enseignements et changements qui ont suivi. Consignez aussi les incidents évités, avec la raison de leur non-notification. Gardez le registre protégé contre les modifications et à accès contrôlé. NetSenX alimente automatiquement la partie réseau : alertes avec heure, appareils et destinations, délais NIS2 par incident et journal d'audit de qui a décidé quoi.

Avec une trace qui relie chaque alerte à une décision, une personne, une heure et une justification. Les auditeurs veulent voir que les alertes ne disparaissent pas : chacune a été examinée, classée comme anodine, en cours d'analyse ou incident, puis close avec une explication. Un tableur suffit pour quelques alertes, mais il ne tient pas quand le volume augmente et se remplit facilement après coup. Utilisez autant que possible le circuit de l'outil lui-même, écrivez de courtes justifications plutôt que des statuts d'un mot, et revoyez chaque trimestre un échantillon d'alertes closes pour vérifier la qualité des décisions. Dans NetSenX, les décisions des analystes sur les alertes sont enregistrées dans le journal d'audit de toutes les offres, avec qui a décidé et quand ; dès l'offre Starter, vous pouvez exporter des rapports PDF pour l'auditeur.

NIS2 ne fixe pas de durée unique : décidez-en une vous-même et écrivez pourquoi. Plusieurs règles vont dans le même sens. Le RGPD impose de documenter toute violation de données personnelles (article 33, paragraphe 5) afin que l'autorité puisse vérifier le respect du règlement, ce qui suppose de garder la trace aussi longtemps qu'un tel contrôle peut raisonnablement intervenir. Les autorités NIS2 peuvent demander des preuves d'incidents et de notifications passés, les assureurs examinent parfois un sinistre longtemps après, et les délais de prescription des actions contractuelles et en responsabilité se comptent en années dans de nombreux pays. Des règles sectorielles et nationales peuvent fixer leurs propres durées. Une pratique courante consiste à garder le registre des incidents et les notifications plusieurs années, et les journaux bruts moins longtemps, en supprimant les données personnelles devenues inutiles. La conservation de l'historique des alertes et du journal d'audit de NetSenX dépend de l'offre ; exportez ce que vous devez garder plus longtemps.

Oui, pour les segments surveillés, et elle est souvent plus exacte qu'un schéma dessiné. Une carte construite à partir du trafic observé montre quels appareils existent, les noms qu'ils annoncent et qui parle à qui, y compris des connexions que personne n'a documentées, comme un poste qui atteint un serveur qu'il ne devrait pas ou la session à distance d'un fournisseur. Elle ne montre pas ce qui n'émet jamais de trafic, les segments sans capteur ni l'architecture voulue : gardez votre schéma d'architecture et vérifiez-le avec la carte observée. Dans toutes les offres, NetSenX construit une telle carte à partir du trafic surveillé, avec les première et dernière apparitions de chaque appareil. Avant de la montrer à un auditeur externe, pensez à ce qu'elle révèle : les noms d'appareils peuvent contenir des noms de salariés et la carte décrit votre structure interne, donc montrez-la à l'écran ou sous accord de confidentialité.

Oui. L'article 33, paragraphe 5, du RGPD impose au responsable du traitement de documenter toute violation de données personnelles, en indiquant les faits, ses effets et les mesures prises pour y remédier, qu'elle ait été notifiée ou non à l'autorité de contrôle. Il s'agit de permettre à l'autorité de vérifier ensuite le respect du règlement, y compris votre décision qu'une violation n'était pas susceptible d'engendrer un risque pour les personnes. Pour chaque violation, notez donc ce qui s'est passé, les données et personnes touchées, pourquoi vous avez jugé la notification nécessaire ou non, qui a décidé et quand, et ce que vous avez changé. Tenez un registre des violations distinct du registre des incidents de sécurité, mais relié à lui. Les autorités peuvent le demander lors d'un contrôle ou après une plainte, et l'absence de trace d'une violation non notifiée fait plus mauvais effet que la violation elle-même. NetSenX conserve les preuves d'alertes derrière chaque entrée pendant la durée prévue par votre offre.

Quand la violation est susceptible d'engendrer un risque élevé pour leurs droits et libertés. L'article 34 du RGPD impose alors au responsable du traitement de la leur communiquer dans les meilleurs délais, en des termes clairs et simples, en décrivant la nature de la violation, les conséquences probables, les mesures prises ou proposées et les coordonnées du DPO. Un risque élevé concerne en général des données pouvant causer un vrai préjudice, comme des pièces d'identité, des données bancaires ou de santé, des mots de passe ou des informations permettant une fraude. L'article 34, paragraphe 3, prévoit des exceptions : les données ont été rendues incompréhensibles, par exemple par un chiffrement robuste ; des mesures ultérieures font que le risque élevé n'est plus susceptible de se matérialiser ; ou des messages individuels exigeraient des efforts disproportionnés, auquel cas une communication publique les remplace. L'autorité de contrôle peut aussi exiger l'information. Dites aux personnes quoi faire, comme changer leurs mots de passe ou se méfier de l'hameçonnage.