KRI : définition, exemples cyber et finance, méthode et seuils

Un KRI (Key Risk Indicator, ou indicateur clé de risque) est une mesure chiffrée qui signale qu'une exposition se rapproche de la limite acceptée par la direction, idéalement avant qu'un incident ne survienne. Là où un KPI indique si un objectif est atteint, le KRI répond à une autre question : sommes-nous en train de sortir de notre appétence au risque ? Né dans la gestion du risque opérationnel bancaire, l'outil est désormais attendu en cybersécurité : le règlement DORA demande aux entités financières des objectifs de sécurité assortis de mesures clés du risque, et la clause 9.1 de l'ISO/IEC 27001 impose d'évaluer l'efficacité du système de management. En 2026, un tableau de bord sans indicateur de risque relié à des seuils approuvés convainc rarement un comité d'audit. Ce guide propose une définition opérationnelle, distingue KRI, KPI et KCI, détaille une méthode de construction, des exemples cyber et finance ainsi que les erreurs à éviter, en complément de notre guide complet de la norme ISO 27001.

KRI : définition d'un indicateur clé de risque

Les recherches « kri def », « kri definition » ou « kri définition » renvoient toutes à la même notion de gestion des risques. Un indicateur clé de risque n'est pas une statistique isolée : c'est une mesure rattachée à un risque précis, comparée à des seuils décidés à l'avance et associée à une action prévue lorsque ces seuils sont franchis. Sans ce triptyque mesure, seuil et escalade, on obtient un chiffre intéressant, mais pas un outil de pilotage.

Concrètement, l'indicateur observe une cause ou un signal précurseur plutôt que la conséquence finale. Pour un risque de compromission par un service exposé à Internet, il suivra par exemple la part de vulnérabilités activement exploitées restées ouvertes au-delà du délai cible. Ce choix donne du temps pour agir : l'alerte arrive pendant que l'exposition se dégrade, et non après l'intrusion, lorsque seule la réponse à incident reste possible.

Indicateurs avancés et indicateurs retardés

On distingue deux familles. L'indicateur avancé (leading) mesure un facteur qui précède la matérialisation du risque : comptes à privilèges orphelins, retard de correctifs, sauvegardes non testées. L'indicateur retardé (lagging) constate ce qui s'est déjà produit : nombre d'incidents, pertes opérationnelles, durée d'indisponibilité. Un dispositif équilibré combine les deux, mais réserve l'essentiel de son attention aux signaux avancés, seuls capables d'éviter un dommage plutôt que de le documenter.

Le KRI ou la KRI : une question d'usage

L'acronyme anglais ne porte pas de genre. En français, on écrit généralement « le KRI », par accord avec « indicateur ». La forme « la KRI » apparaît dans certains documents traduits trop littéralement, sans changer le sens. Dans une politique interne, l'essentiel est de figer un glossaire commun : la même notion doit porter le même nom dans le registre des risques, le tableau de bord et les comptes rendus du comité, afin d'éviter toute ambiguïté lors d'un audit.

KRI, KPI et KCI : trois indicateurs, trois questions différentes

La confusion la plus fréquente consiste à présenter des indicateurs de performance comme des indicateurs de risque. Un KPI (Key Performance Indicator) mesure l'atteinte d'un objectif : taux de collaborateurs formés, nombre de projets livrés, respect d'un budget. Un KCI (Key Control Indicator) mesure le fonctionnement d'un contrôle : part des comptes couverts par l'authentification multifacteur, taux de revues d'habilitations réalisées. Le KRI, lui, mesure l'exposition résiduelle qui subsiste malgré les contrôles.

Le même chiffre peut changer de nature selon l'usage. Le taux de correctifs appliqués est un KPI pour l'équipe d'exploitation qui vise un objectif mensuel ; il devient un indicateur de risque une fois restreint aux actifs exposés et comparé à un seuil validé par la direction. La référence de comparaison, plus que la formule, fait la différence. Notre article sur le tableau de bord cybersécurité et ses KPIs pour le management détaille la partie performance.

KRI et KCI : un couple indissociable

L'association « kri kci » est au cœur des dispositifs bancaires de contrôle permanent. Pour chaque risque majeur, le KCI vérifie que le contrôle prévu fonctionne, tandis que le KRI vérifie que l'exposition reste dans les limites. Si le KCI est vert et le KRI rouge, le contrôle est probablement mal conçu ou insuffisant. Si le KCI est rouge et le KRI encore vert, le risque va se dégrader : c'est le moment d'agir, avant la matérialisation.

Le KRI en finance : l'héritage du risque opérationnel bancaire

La notion de « kri finance » vient du risque opérationnel bancaire. Dans ses principes révisés pour la gestion saine du risque opérationnel (mars 2021), le Comité de Bâle rappelle que sa revue de 2014 jugeait plusieurs principes insuffisamment appliqués, notamment pour les outils d'identification et d'évaluation comme les indicateurs clés de risque. Il décrit les métriques comme une source d'alerte précoce, utiles lorsqu'elles sont clairement reliées aux risques et contrôles et suivies dans le temps face à des seuils ou limites convenus.

Dans une banque, un assureur ou une société de gestion, les indicateurs couvrent plusieurs familles. En risque de crédit, on suit la dérive des encours douteux par segment. En liquidité, l'écart entre les ratios réglementaires et les limites internes. En risque opérationnel, la volumétrie des opérations en suspens, la rotation sur les postes clés ou les réclamations clients. Les assureurs relient ces mesures au profil de risque qu'ils évaluent dans l'ORSA (évaluation interne des risques et de la solvabilité) prévu par Solvabilité II.

KRI et DORA : les indicateurs de risque TIC du secteur financier

Applicable depuis le 17 janvier 2025, le règlement (UE) 2022/2554, dit DORA, fait de l'organe de direction le responsable ultime de la gestion du risque lié aux technologies de l'information et de la communication (TIC). Son article 6, paragraphe 8, impose une stratégie de résilience opérationnelle numérique qui fixe un niveau de tolérance au risque TIC cohérent avec l'appétence de l'entité, ainsi que des objectifs de sécurité de l'information assortis d'indicateurs de performance et de mesures clés du risque.

Le même article demande d'objectiver la situation de résilience à partir du nombre d'incidents majeurs déclarés et de l'efficacité des mesures préventives. Autrement dit, le régulateur attend à la fois des indicateurs retardés (incidents) et des indicateurs avancés (efficacité des protections). Pour une entité financière, le dispositif d'indicateurs n'est donc plus une bonne pratique facultative : c'est une pièce que l'Autorité de contrôle prudentiel et de résolution (ACPR) ou l'Autorité des marchés financiers (AMF) peuvent demander pour apprécier la robustesse du cadre de gestion du risque TIC.

Trois chantiers pour les équipes risques et sécurité

Pour une entité soumise à DORA, la mise en conformité des indicateurs passe par trois chantiers. D'abord, aligner la déclaration de tolérance au risque TIC sur l'appétence du groupe. Ensuite, rattacher chaque indicateur aux fonctions critiques ou importantes qu'il protège, afin de prioriser les mesures. Enfin, conserver la trace des revues par l'organe de direction : comptes rendus, décisions et plans d'action datés.

Relier chaque indicateur à l'appétence et à la tolérance au risque

Un indicateur de risque ne prend son sens qu'adossé à une déclaration d'appétence. Le Comité de Bâle reprend la définition du Conseil de stabilité financière : l'appétence au risque est le niveau agrégé et les types de risques qu'une organisation accepte de prendre, décidés à l'avance et dans les limites de sa capacité, pour atteindre ses objectifs. La tolérance au risque correspond à la variation acceptée autour de cette appétence. La capacité constitue la limite absolue à ne jamais franchir.

Ces trois notions se traduisent naturellement en zones de couleur. La zone verte correspond à une exposition conforme à l'appétence. La zone orange signale un dépassement de l'appétence qui reste dans la tolérance : le propriétaire du risque doit présenter un plan d'action. La zone rouge indique un dépassement de la tolérance : l'escalade vers la direction devient obligatoire, avec décision formelle de traitement, d'acceptation temporaire ou de transfert du risque.

Côté cybersécurité, la série NIST IR 8286, révisée en décembre 2025, explique comment remonter les risques des registres système vers le registre de risques de l'entreprise. Le volet IR 8286C décrit un cycle surveiller, évaluer, ajuster, dans lequel la stratégie, l'appétence, la tolérance et la capacité de risque orientent la performance attendue. Le cadre NIST CSF 2.0 prévoit de même, dans sa fonction GOVERN, des déclarations d'appétence et de tolérance établies et communiquées.

Traduire une phrase d'appétence en seuils chiffrés

Prenons une déclaration validée par un comité des risques : « nous n'acceptons pas qu'une vulnérabilité activement exploitée reste ouverte durablement sur un actif exposé à Internet ». L'indicateur associé mesure la part de ces vulnérabilités ouvertes au-delà de quinze jours, avec par exemple moins de 5 % en vert et plus de 15 % en rouge. Ces bornes illustratives se calibrent sur l'historique interne et la capacité réelle de correction. Retenez surtout qu'un indicateur sans seuil approuvé par la direction n'est qu'une statistique.

Construire un KRI fiable : méthode en sept étapes

La qualité d'un indicateur dépend moins de sa sophistication que de la rigueur de sa conception. Le guide NIST SP 800-55 volume 1, publié en décembre 2024, consacre une large place à la documentation des mesures, à la qualité des données, à l'incertitude et à la priorisation. Il aborde aussi le développement, le test et la validation des mesures avant leur diffusion. La méthode suivante applique ces principes à la construction d'un indicateur de risque.

1. Partir du registre des risques : sélectionnez les risques majeurs validés en comité, pas les données disponibles dans les outils.
2. Identifier le facteur d'exposition : demandez-vous quelle cause, si elle se dégrade, rend le scénario plus probable ou plus grave.
3. Écrire la formule et le périmètre : numérateur, dénominateur, actifs concernés, exclusions et règles d'arrondi, sans ambiguïté possible.
4. Désigner la source et le propriétaire : un système de référence unique pour la donnée et une personne nommée pour l'indicateur.
5. Fixer les seuils et l'escalade : dérivez-les de l'appétence, puis précisez qui est alerté, sous quel délai et avec quelle décision attendue.
6. Tester sur l'historique : vérifiez que l'indicateur aurait réagi avant les incidents passés et qu'il ne génère pas de fausses alertes permanentes.
7. Revoir périodiquement : réévaluez pertinence, seuils et qualité de la donnée chaque année et après tout incident significatif.

Critères de qualité d'un bon indicateur

Un bon indicateur de risque est sensible (il varie quand l'exposition varie), automatisable (sa collecte ne dépend pas d'un tableur manuel), compréhensible par un administrateur non spécialiste, comparable dans le temps grâce à une formule stable et actionnable, car son propriétaire dispose des leviers pour le faire évoluer. Un indicateur qui ne remplit pas ces critères risque d'être ignoré dès le deuxième comité, faute de crédibilité.

Exemples de KRI en cybersécurité par domaine de risque

Les indicateurs les plus utiles en sécurité de l'information portent sur l'exposition technique, les identités, les tiers et la résilience. Le tableau ci-dessous propose des exemples à adapter : formules et seuils doivent être recalibrés sur votre contexte, votre historique et votre appétence. Chaque ligne associe un indicateur de risque à un KCI (Key Control Indicator, indicateur de contrôle), afin de distinguer la dégradation de l'exposition de la défaillance du contrôle qui devrait la contenir.

Ces constats justifient de placer le délai de correction des vulnérabilités exploitées et l'exposition aux tiers parmi les premiers indicateurs suivis. Ils montrent aussi les limites d'un KPI global de correctifs : une organisation peut afficher un taux élevé tout en laissant ouvertes, sur ses équipements de bordure, précisément les failles que les attaquants exploitent. Le périmètre de mesure doit suivre le scénario de risque, pas la facilité de collecte.

Indicateurs pour les tiers et la chaîne d'approvisionnement

Le risque fournisseur se prête bien aux indicateurs avancés : part des prestataires critiques sans évaluation à jour, nombre de fournisseurs disposant d'un accès distant permanent, délai de notification contractuel non respecté. Ces mesures alimentent le registre d'information exigé par DORA pour les prestataires de services TIC et la sécurité de la chaîne d'approvisionnement attendue par NIS 2. Elles obligent surtout à tenir un inventaire fiable des tiers, condition préalable à toute mesure crédible.

Indicateurs pour l'IA générative et le Shadow AI

L'usage non encadré d'outils d'intelligence artificielle générative crée un risque de fuite de code source et de données sensibles. Les indicateurs pertinents portent sur le nombre de services d'IA non approuvés détectés, le volume de données classifiées envoyées vers ces services et la part des cas d'usage recensés ayant fait l'objet d'une analyse de risque. Notre guide sur le programme Shadow AI et sa gouvernance par le RSSI détaille la mise en place de ce suivi.

Seuils, escalade et reporting : faire vivre les KRI jusqu'au COMEX

Un indicateur n'a de valeur que s'il déclenche une décision. Le modèle des trois lignes de maîtrise, décrit par le Comité de Bâle, fournit une répartition claire : la première ligne (métiers, DSI) mesure et traite ; la deuxième ligne (gestion des risques, responsable de la sécurité des systèmes d'information ou RSSI, conformité) challenge les formules, les seuils et les plans d'action ; la troisième ligne (audit interne) vérifie de façon indépendante que le dispositif fonctionne et que les chiffres sont fiables.

Le reporting doit rester lisible. Pour un comité exécutif, cinq à dix indicateurs suffisent souvent, présentés avec leur tendance sur plusieurs périodes, leur statut de couleur, le propriétaire et l'action en cours. Les comités opérationnels peuvent suivre un niveau plus fin. L'important est la cohérence verticale : chaque indicateur de direction doit pouvoir être expliqué par les mesures détaillées qui l'alimentent, sans retraitement manuel opaque.

Une alerte rouge doit produire une décision tracée : plan d'action daté, acceptation temporaire signée par le propriétaire du risque, ou arbitrage budgétaire. Un indicateur qui reste rouge pendant plusieurs comités sans décision révèle un problème de gouvernance, pas de mesure. Pour structurer ce dialogue entre direction générale et sécurité, consultez notre article sur la gouvernance de la cybersécurité entre RSSI et COMEX.

Retour terrain : Cas typique rencontré en mission — le comité exécutif reçoit un tableau de bord dominé par des volumes d'activité : alertes traitées, correctifs déployés, collaborateurs sensibilisés. Tout apparaît en vert et aucune décision n'est demandée. En reformulant quelques indicateurs en exposition rapportée à un seuil validé, par exemple les vulnérabilités activement exploitées encore ouvertes sur les services exposés au-delà du délai cible, le rouge devient visible et rattaché à un propriétaire. Le plan de correction, jusque-là repoussé, est alors arbitré en séance. L'enseignement : moins d'indicateurs, chacun assorti d'un seuil et de la décision attendue.

Choisir la bonne fréquence de mesure

La fréquence dépend de la vitesse à laquelle le risque évolue. Une exposition technique comme les vulnérabilités ou les comptes à privilèges se mesure chaque semaine, voire chaque jour lorsque la collecte est automatisée. Un risque fournisseur ou de conformité se suit plutôt chaque mois ou chaque trimestre. Le reporting à la direction peut rester trimestriel, à condition qu'un franchissement du seuil rouge déclenche une alerte immédiate, sans attendre le prochain comité.

Automatiser le calcul d'un KRI : exemple outillé

La crédibilité d'un indicateur repose sur la reproductibilité de son calcul. L'exemple ci-dessous formalise une fiche d'indicateur au format YAML, puis un script Python qui calcule la part de vulnérabilités activement exploitées restées ouvertes au-delà du délai cible sur les actifs exposés. Les seuils sont des valeurs d'illustration à recalibrer : l'objectif est de montrer la chaîne complète, de la donnée brute au statut de couleur.

kri_id: KRI-VULN-03
intitule: Vulnérabilités KEV ouvertes au-delà du délai cible
risque_associe: R-07 Compromission via un service exposé à Internet
proprietaire: Responsable infrastructure (première ligne)
formule: nb_kev_ouvertes_hors_delai / nb_kev_detectees
perimetre: actifs exposés à Internet (référentiel CMDB)
source: export hebdomadaire du scanner de vulnérabilités
frequence: hebdomadaire
type: avancé
seuils:
  vert: "inférieur à 5 %"
  orange: "de 5 à 15 %"
  rouge: "supérieur à 15 %"
escalade:
  orange: plan d'action présenté au comité sécurité sous 30 jours
  rouge: alerte RSSI et DSI sous 48 h, information du comité des risques
kci_associe: KCI-SCAN-01 couverture du scanner sur l'inventaire exposé
revue: annuelle et après tout incident majeur

import csv
from datetime import date

SEUIL_VERT = 0.05
SEUIL_ORANGE = 0.15

def statut(valeur):
    if valeur < SEUIL_VERT:
        return "VERT"
    if valeur <= SEUIL_ORANGE:
        return "ORANGE"
    return "ROUGE"

def kri_kev(chemin_csv, delai_cible=15, jour=None):
    jour = jour or date.today()
    total, hors_delai = 0, 0
    with open(chemin_csv, newline="", encoding="utf-8") as f:
        for ligne in csv.DictReader(f):
            if ligne["expose_internet"] != "oui" or ligne["kev"] != "oui":
                continue
            total += 1
            age = (jour - date.fromisoformat(ligne["date_detection"])).days
            if ligne["statut"] != "corrigee" and age > delai_cible:
                hors_delai += 1
    valeur = hors_delai / total if total else 0.0
    return round(valeur, 3), statut(valeur)

print(kri_kev("export_scanner.csv"))

Le script filtre d'abord le périmètre défini dans la fiche, puis compte les vulnérabilités ouvertes au-delà du délai cible et renvoie la valeur avec son statut. En production, l'export provient directement de l'outil de gestion des vulnérabilités, le résultat est historisé en base et la bascule en rouge envoie une notification au propriétaire. Le code reste volontairement simple : un auditeur doit pouvoir relire la formule et la rejouer.

Fiabiliser la donnée source d'un KRI

La plupart des indicateurs défaillants le sont à cause de leur donnée, pas de leur formule. Un inventaire incomplet fausse le dénominateur, un scanner mal configuré sous-estime le numérateur. C'est pourquoi chaque indicateur de risque gagne à être accompagné d'un indicateur de couverture, comme la part des actifs exposés réellement analysés. Si la couverture chute, la valeur du KRI devient non significative et doit être signalée comme telle au comité.

La traçabilité complète la couverture. Pour chaque valeur présentée, il doit être possible de retrouver l'extraction d'origine, la version de la formule et la date de calcul. Conservez les exports bruts pendant la durée exigée par votre politique d'archivage et automatisez les contrôles de cohérence : variation brutale du dénominateur, source vide ou date d'extraction ancienne doivent bloquer la publication.

KRI et ISO 27001 : mesurer l'efficacité du SMSI

Aucun référentiel majeur n'impose une liste fermée d'indicateurs, mais tous exigent de prouver que le risque est surveillé et piloté. Pour un système de management de la sécurité de l'information (SMSI), les indicateurs clés de risque constituent la manière la plus économique de produire cette preuve. Un même indicateur bien conçu peut servir plusieurs cadres, ce qui limite la charge documentaire et les tableaux de bord concurrents.

Ce que demandent la clause 9.1 et l'ISO 27004

La clause 9.1 de l'ISO/IEC 27001:2022 demande de déterminer ce qui doit être surveillé et mesuré, les méthodes, les fréquences, les responsables et le moment de l'analyse. La norme ISO/IEC 27004:2016 fournit les lignes directrices pour évaluer la performance de la sécurité et l'efficacité du système de management ; sa révision est en cours. Notre tableau de bord KPI ISMS conforme ISO 27004 propose une base à compléter par vos indicateurs de risque.

Relier les indicateurs à l'appréciation des risques

La clause 6.1 de l'ISO 27001 impose des critères d'acceptation des risques : ce sont eux qui doivent servir de base aux seuils des indicateurs. Lors de la revue de direction, l'auditeur vérifie que les résultats de mesure sont analysés, que les dépassements donnent lieu à des actions et que le plan de traitement des risques évolue en conséquence. Un indicateur déconnecté de l'appréciation des risques reste une simple métrique d'exploitation.

KRI, NIS 2 et AI Act : piloter les nouvelles obligations

Les textes européens récents déplacent la responsabilité du risque numérique vers les dirigeants. Ils ne fixent pas d'indicateurs normalisés, mais exigent des preuves de supervision régulière. Un dispositif d'indicateurs de risque et de contrôle bien construit répond à cette attente, à condition de rattacher chaque mesure à l'article qu'elle documente et de conserver l'historique des décisions prises.

NIS 2 et le référentiel ReCyF

La directive NIS 2 (UE) 2022/2555 rend les organes de direction responsables de l'approbation et de la supervision des mesures de gestion des risques cyber, et impose des procédures pour évaluer l'efficacité de ces mesures. Les indicateurs de risque et de contrôle en sont la traduction directe. Pour structurer ce suivi, appuyez-vous sur notre tableau de bord de conformité NIS 2 et sur l'analyse de la couverture du référentiel ReCyF de l'ANSSI.

AI Act : surveiller les risques des systèmes d'IA

Le règlement (UE) 2024/1689 sur l'intelligence artificielle exige, pour les systèmes à haut risque, un système de gestion des risques continu et itératif sur tout le cycle de vie. Les indicateurs pertinents portent sur la dérive des performances du modèle, les incidents signalés, les écarts de qualité des données d'entraînement ou les contournements de la supervision humaine. Le guide AI Act 2026 pour les systèmes à haut risque précise ces obligations.

Erreurs fréquentes dans la conception des indicateurs de risque

Les mêmes défauts reviennent d'une organisation à l'autre, quel que soit le secteur. Ils ne tiennent presque jamais à un manque d'outils, mais à une conception trop rapide, menée à partir des données disponibles plutôt que des risques. Les identifier avant le premier comité évite de perdre la confiance de la direction, difficile à regagner une fois qu'un indicateur a été pris en défaut.

• Indicateurs de vanité : nombre d'attaques bloquées ou de courriels filtrés, qui rassurent sans mesurer l'exposition résiduelle.
• Catalogue pléthorique : des dizaines de mesures sans hiérarchie, dans lesquelles aucun signal ne ressort.
• Absence de propriétaire : un indicateur rouge que personne n'est chargé de faire revenir au vert.
• Seuils figés : des bornes jamais revues alors que le périmètre, la menace ou l'appétence ont changé.
• Moyennes trompeuses : une valeur globale satisfaisante qui masque un périmètre critique en dérive.
• Collecte manuelle : des chiffres retraités à la main, impossibles à reproduire lors d'un audit.

Le syndrome du tableau de bord « pastèque »

Un tableau de bord « pastèque » est vert à l'extérieur et rouge à l'intérieur : les indicateurs agrégés affichent une situation maîtrisée alors que les mesures détaillées révèlent des dérives. Ce biais naît souvent de seuils trop larges, de moyennes calculées sur des périmètres hétérogènes ou d'une pression implicite à présenter du vert. Exiger systématiquement la tendance et la valeur détaillée derrière chaque statut agrégé reste le meilleur antidote.

À lire aussi : les contrôles ITGC exigés par SOX ; le programme d'audit interne ; le MTTD comme KRI de détection.

Questions fréquentes

Conclusion

Un KRI utile tient en quatre éléments : un risque clairement identifié, une formule reproductible, des seuils dérivés de l'appétence approuvée par la direction et une escalade qui produit des décisions. En 2026, DORA, NIS 2, l'ISO 27001 et l'AI Act convergent vers la même attente : démontrer que le risque est mesuré et piloté, pas seulement décrit. Commencez par quelques indicateurs avancés sur vos risques majeurs, associez-leur un KCI, puis enrichissez progressivement le dispositif. Pour replacer ces indicateurs dans un système de management complet, appuyez-vous sur notre guide complet ISO 27001.