Cyber-assurance, déposer un sinistre, respecter les délais, ce détail inattendu sécurise votre remboursement

Après une cyberattaque, la cyber-assurance ne rembourse pas « automatiquement ». Le dépôt de plainte sous 72 heures peut conditionner l’indemnisation de certaines pertes. Et l’assureur peut refuser un sinistre si des mesures de sécurité prévues au contrat ne sont pas respectées.

La séquence est toujours la même: systèmes chiffrés, activité ralentie ou stoppée, questions juridiques immédiates, et une course contre la montre pour documenter l’incident. La déclaration de sinistre devient un exercice de rigueur, autant technique qu’administratif.

Concrètement, tout se joue sur trois blocs: l’activation des bons interlocuteurs, la constitution de preuves exploitables, et le respect des obligations contractuelles. Une cyber-assurance sert de soutien de « deuxième niveau » pendant la crise, selon Clubic: elle encadre la réponse et finance certains impacts, mais elle ne remplace pas la cybersécurité interne.

Plainte sous 72 heures: le minuteur juridique

Dans les premières heures, la gestion du sinistre ne se limite pas à l’informatique. Le dossier avance sur plusieurs rails à la fois: continuité d’activité, communication, et calendrier légal. Le point le plus net concerne le dépôt de plainte pour certains professionnels: l’article L12-10-1 du Code des assurances prévoit que l’indemnisation de pertes et dommages entrant dans son champ est conditionnée au dépôt d’une plainte au plus tard 72 heures après la connaissance de l’attaque ^[2].

Ce délai structure toute la suite. Il impose d’identifier rapidement l’événement déclencheur, de dater la « connaissance » de l’attaque, et d’organiser la collecte d’éléments factuels pour étayer la plainte. La plainte n’est pas qu’un acte symbolique: elle devient une pièce du dossier d’assurance.

Reste un détail qui change tout: une cyberattaque déclenche plusieurs calendriers qui ne doivent pas être confondus, souligne la même source ^[2]. Déclaration à l’assureur, plainte, notifications réglementaires éventuelles, et gestion contractuelle avec des prestataires, tout peut se télescoper. La bonne pratique consiste à tenir un journal de crise horodaté (décisions, constats, actions), pour éviter les trous dans la chronologie quand l’assureur demandera « qui a su quoi, et quand ».

Déclarer le sinistre: preuves, chronologie, périmètre des dommages

Une déclaration efficace commence par un périmètre clair. Quel incident? Un rançongiciel, un vol de données, une fraude, une indisponibilité d’un prestataire cloud, une erreur humaine? Ces catégories ne sont pas forcément traitées de la même façon dans les contrats, rappelle Frenchweb dans un passage repris par la fiche CB Insights ^[2].

Le problème? Une déclaration trop floue ouvre la porte à des allers-retours, au pire à une contestation sur la nature de l’événement. Une déclaration trop étroite, elle, peut oublier des postes de pertes qui apparaîtront plus tard. Il faut donc documenter sans surinterpréter: faits observables, systèmes concernés, premiers impacts métier, et actions engagées.

Concrètement, le dossier gagne en solidité quand il contient:

• une chronologie horodatée (détection, isolement, décisions de coupure, remise en service),
• les éléments techniques disponibles (alertes, journaux, constats de chiffrement, comptes compromis),
• la liste des actifs touchés (serveurs, postes, applications, sauvegardes),
• les impacts opérationnels (services arrêtés, retards, impossibilités),
• les premières mesures de remédiation (réinitialisations, restauration, durcissement).

Il faut aussi cadrer les dommages assurantiels. Les contrats peuvent intégrer des pertes d’exploitation, avec des paramètres à vérifier: délai d’attente, durée maximale d’indemnisation, point de départ de la période, selon la même source ^[2]. Même sans entrer dans les montants, ce point impose de conserver les preuves internes de l’arrêt ou de la dégradation de service: tickets, messages d’incident, décisions de fermeture, éléments comptables et opérationnels.

Pourquoi l’assureur peut refuser: sauvegardes, correctifs, comptes admin

Depuis plusieurs mois, les assureurs resserrent les exigences et conditionnent davantage l’indemnisation au niveau de préparation. Clubic décrit une logique proche de la prévention routière: les compagnies refusent de couvrir un risque jugé évitable ^[1].

Les motifs de refus cités sont concrets. Un sinistre peut être refusé si des sauvegardes manquent, si les administrateurs ne sont pas protégés, ou si les correctifs tardent à être installés ^[1]. Dans la pratique, cela signifie que la phase « assurance » commence avant l’attaque: configuration des sauvegardes, gestion des comptes à privilèges, politique de patch, et preuve de mise en œuvre.

Autre point. Les assureurs imposent aussi des prérequis techniques et organisationnels. Clubic mentionne des campagnes de phishing simulé, une communication interne régulière et des rappels pratiques sur la gestion des mots de passe ^[1]. L’intérêt n’est pas seulement pédagogique. Ces éléments créent de la traçabilité: la capacité à démontrer que l’entreprise entretient des réflexes, pas seulement un dossier de conformité.

Dans un dossier de sinistre, ces preuves peuvent peser lourd. Elles contribuent à montrer que l’assuré a respecté les mesures de sécurité prévues au contrat, point central puisque les garanties sont encadrées et l’indemnisation dépend du respect contractuel, selon Clubic ^[1].

Cas réel: Cerballiance, « accès non autorisé » et renforcement des protocoles

Les attaques touchent aussi des acteurs de santé. Le réseau de laboratoires de biologie médicale Cerballiance en France a annoncé avoir été victime fin mars d’une attaque informatique ayant entraîné un accès non autorisé à des données personnelles de « certains » patients, selon une dépêche AFP reprise par CB Insights ^[3].

Ce type d’incident illustre deux réalités utiles pour un sinistre d’assurance. D’abord, la qualification des faits: « accès non autorisé » renvoie à une problématique de données, pas seulement de disponibilité. Ensuite, l’après-crise: Cerballiance indique avoir mis en place avec son prestataire « les mesures indispensables pour renforcer ses protocoles de sécurité » pour éviter une situation similaire, selon la même dépêche ^[3].

Dans une logique assurantielle, ces actions post-incident peuvent compter à double titre: elles réduisent le risque de récidive, et elles structurent le récit factuel de la remédiation. Elles peuvent aussi nourrir les échanges avec l’assureur sur les mesures correctrices attendues.

Reste une difficulté fréquente: l’assuré ne maîtrise pas toujours toute la chaîne technique, surtout quand un prestataire est impliqué. Le dossier doit donc intégrer les éléments disponibles côté prestataire (constats, actions, périmètre), sans laisser d’angles morts sur la responsabilité opérationnelle.

L’essentiel pour sécuriser le dossier

• Tenir une chronologie horodatée dès la détection.
• Déposer plainte dans les délais applicables.
• Aligner la déclaration sur les clauses du contrat.
• Documenter la sécurité existante (sauvegardes, patch, comptes admin).
• Tracer les actions de remédiation et de restauration.

Ce qui se joue après la déclaration

Une fois le sinistre déclaré, la discussion se déplace vite sur la preuve: preuve de l’incident, preuve des impacts, preuve du respect des obligations de sécurité. C’est aussi le moment où l’entreprise découvre le vrai contenu de son contrat: incidents couverts ou exclus, modalités des pertes d’exploitation, et articulation avec les prestataires. Le dossier le plus solide reste celui qui colle aux faits, minute par minute, et qui documente les contrôles attendus avant l’attaque.