Depuis le 1er avril 2025, la Suisse connaît une obligation légale de notifier les cyberattaques contre les infrastructures critiques à l'Office fédéral de la cybersécurité (OFCS / BACS). La base juridique est la loi sur la sécurité de l'information (LSI / ISG) dans sa version révisée ; les détails opérationnels découlent de l'ordonnance correspondante. Les hôpitaux figurent parmi les exploitants d'infrastructures critiques expressément visés dans le domaine de la santé – pour autant qu'ils atteignent les seuils définis dans l'ordonnance (par exemple le nombre de lits ou l'importance pour l'approvisionnement).

Pour la direction de l'hôpital, c'est un changement de paradigme : un incident de rançongiciel qui perturbe les urgences ou le système d'information clinique n'est plus seulement un problème informatique, mais un événement notifiable assorti de son propre délai. Cet article explique ce qui est notifiable, comment le délai court, ce qu'attend l'OFCS, comment éviter les risques de responsabilité et en quoi tout cela se distingue de la directive européenne NIS2.

Remarque importante d'emblée : les délais exacts, les seuils et le catalogue des incidents notifiables sont précisés dans l'ordonnance et peuvent évoluer. Vérifiez au cas par cas les délais détaillés applicables à votre hôpital. Cet article fournit la structure, non la date butoir contraignante.

Est notifiable une cyberattaque qui compromet le fonctionnement de l'infrastructure critique, qui a conduit à une manipulation ou à une exfiltration d'informations, ou qui est restée non détectée pendant une période prolongée, voire qui est liée à une extorsion, une menace ou une contrainte. Pour un hôpital, il s'agit typiquement de : rançongiciel chiffrant des systèmes de production, accès non autorisé confirmé au système d'information clinique ou de laboratoire, compromission des accès à distance (VPN, accès de maintenance des fournisseurs de dispositifs médicaux) ou attaque réussie de l'infrastructure de messagerie avec exfiltration de données.

La notification ISG/OFCS doit être distinguée de deux autres voies de notification susceptibles de courir en parallèle : premièrement, l'annonce de protection des données au PFPDT selon l'art. 24 nLPD, lorsque l'incident entraîne une violation de la sécurité des données personnelles et qu'un risque élevé existe ; deuxièmement – pour les données de santé sensibles – l'information des personnes concernées. Un seul incident de rançongiciel dans un hôpital peut donc déclencher trois obligations de notification, avec des destinataires, des délais et des seuils différents. Qui ne pense qu'au PFPDT oublie la notification ISG/OFCS – et inversement.

L'ISG prévoit un délai de première notification court après la prise de connaissance de la cyberattaque. L'ordonnance précise le délai (une première notification sous 24 heures est en discussion et en mise en œuvre) et prévoit une notification de suivi complémentaire et plus détaillée dans un délai de quelques jours. Ce qui est déterminant, c'est le moment de la prise de connaissance, et non le moment de l'attaque. Cela déplace la question critique de la technique vers l'organisation : à quel moment précis l'hôpital « sait »-il qu'un incident notifiable existe ? Dès que le responsable informatique de garde dispose d'un indice crédible – ou déjà lorsque le helpdesk signale trois services chiffrés ?

Vérifiez au cas par cas les délais exacts applicables à votre hôpital, car ils résultent de la version de l'ordonnance en vigueur. Ce qui compte en pratique : le délai est court, et il commence avant que les faits soient entièrement établis. Une première notification doit expressément être déposée même lorsque tous les détails ne sont pas encore connus. Qui attend la « forensique complète » manque le délai. C'est précisément pour cela qu'il faut un processus de notification préparé et répété, plutôt qu'une décision ad hoc à trois heures du matin.

L'OFCS ne veut pas une forensique achevée, mais un état des lieux initial structuré et honnête. On attend généralement : les coordonnées de l'organisation notifiante et de la personne de contact, la nature et le moment de l'incident (ou de la prise de connaissance), les systèmes concernés et les répercussions prévisibles sur l'approvisionnement en soins, les mesures immédiates déjà prises et la question de savoir s'il y a extorsion. La notification s'effectue via le formulaire ou la plateforme de notification mis à disposition par l'OFCS. L'OFCS utilise ces informations pour établir le tableau de la situation et peut renvoyer un soutien ainsi que des indications techniques (p. ex. sur des indicateurs connus).

Important pour la direction de l'hôpital : la notification à l'OFCS n'est pas une auto-dénonciation et ne déclenche aucune sanction de surveillance pour l'attaque elle-même. Ce qui est passible de sanction, c'est la violation de l'obligation de notifier, et non le fait d'avoir été victime. Le message à la direction et au conseil est donc : notifier protège, le silence expose. L'OFCS est un partenaire pour le tableau national de la situation – non une autorité de poursuite pénale. Cela abaisse le seuil pour déposer une première notification même lorsque la situation est encore floue.

Vous ne devriez pas lire le déroulé suivant pour la première fois en situation réelle, mais le jouer dans un exercice tabletop. Étape 1 – Détection : anomalie signalée (helpdesk, monitoring, signalement externe). Étape 2 – Triage : existe-t-il une cyberattaque qui compromet le fonctionnement, l'intégrité des données ou l'approvisionnement en soins ? Oui → continuer. Non/incertain → documenter, observer, revérifier le seuil. Étape 3 – Consigner la prise de connaissance : noter la date/heure du premier indice crédible. C'est le point de départ du délai.

Étape 4 – Vérifier les obligations parallèles : (a) notification ISG/OFCS requise ? (b) annonce nLPD au PFPDT (données personnelles concernées, risque élevé) ? (c) information des personnes concernées ? Étape 5 – Déposer la première notification OFCS avec l'état connu, sans attendre la forensique complète. Étape 6 – Escalade interne : cellule de crise, CISO/vCISO, service juridique, communication, direction, et au besoin la présidence du conseil. Étape 7 – Coordonner les acteurs externes : activer le prestataire externe de réponse aux incidents désigné et l'assureur cyber selon la liste de contacts préparée. Étape 8 – Notification de suivi à l'OFCS dans le délai prévu ; documenter les enseignements tirés. Chaque embranchement devrait disposer d'une personne responsable nommée et d'un suppléant.

L'obligation de notifier est une obligation d'organisation, et les obligations d'organisation s'arrêtent à l'organe suprême. Le conseil d'administration ou le conseil de l'hôpital doit s'assurer qu'une organisation de notification existe, que les compétences et les suppléances sont définies, que le processus de notification a été répété et que les contrats externes nécessaires (réponse aux incidents, assurance cyber) sont prêts. Cela relève du devoir légal de diligence et de la haute surveillance. Le membre de l'organe suprême qui tolère une lacune manifeste dans le dispositif de crise risque une responsabilité personnelle – indépendamment de la sanction ISG à l'encontre de l'organisation.

Concrètement, nous recommandons au conseil de réunir trois preuves : premièrement, un concept de réponse aux incidents et de notification adopté, avec des délais et des rôles clairs ; deuxièmement, le procès-verbal d'au moins un exercice tabletop mené avec l'obligation de notifier comme scénario ; troisièmement, une liste de contacts et d'escalade à jour incluant le prestataire externe de réponse aux incidents, l'assureur cyber et la voie de notification de l'OFCS. Ces trois documents transforment une obligation abstraite en une preuve de gouvernance vérifiable – et ce sont précisément eux qui, en situation réelle, font la différence entre une notification dans les délais et un délai manqué.

Les hôpitaux entendent souvent « NIS2 » et « notification sous 24 heures » dans la même phrase et mélangent les deux régimes. C'est dangereux, car ils ont des destinataires et des déclencheurs différents. NIS2 est une directive européenne (2022/2555) que la Suisse n'a pas transposée. Elle ne lie un hôpital suisse que si celui-ci dispose d'un établissement ou d'une activité pertinente dans l'UE – par exemple une filiale, un établissement stable ou une prestation de services significative dans un État membre de l'UE. Un hôpital actif uniquement en Suisse ne relève pas de NIS2.

Pour l'hôpital actif uniquement en Suisse, l'obligation de notification ISG/OFCS est et reste le mécanisme pertinent. NIS2 connaît certes aussi un système de notification échelonné (alerte précoce, notification de suivi, rapport final), mais auprès d'une autorité nationale de l'UE (CSIRT) de l'État membre concerné, et non auprès de l'OFCS. Qui touche les deux mondes (groupe hospitalier suisse avec un site dans l'UE) doit remplir les deux obligations séparément et ne peut pas les compenser l'une par l'autre. Gardez les deux régimes clairement distincts dans votre manuel de crise – avec une attribution claire indiquant quel site notifie à quelle autorité.

SIDD est un cabinet de conseil en protection des données et en sécurité de l'information dirigé par des juristes – et non un Security Operations Center. Nous intervenons clairement là où la gouvernance fait la différence : nous concevons et documentons votre concept de notification conformément aux exigences ISG/OFCS, construisons l'arbre de décision, définissons les rôles et les délais, préparons les interfaces et les voies d'escalade vers un prestataire externe de réponse aux incidents, l'assureur cyber et l'OFCS, et répétons l'ensemble avec votre direction lors d'un exercice tabletop. En tant que vCISO, nous accompagnons l'organisation de notification dans la durée et la mise à jour annuelle des playbooks.

La limite est tracée délibérément : la gestion technique en situation réelle – forensique, confinement, restauration, le traitement d'incident en direct 24 heures sur 24 – est assurée par un prestataire spécialisé en réponse aux incidents que nous mobilisons en amont et avec lequel nous préparons les interfaces. SIDD coordonne la préparation et la gouvernance, mais n'exploite pas lui-même de SOC et n'assume pas de réponse gérée aux incidents en exploitation réelle. Plus d'informations sur nos prestations sous vCISO, SMSI / ISO 27001 et conseil en protection des données (nLPD). Pour convenir d'un premier entretien sur l'organisation de notification de votre hôpital, utilisez le formulaire de contact ; pour une offre relative à un mandat de concept de notification, utilisez notre formulaire d'offre.