Supervision des prestataires MDR pour NIS2, DORA et GDPR

À 02 h 13 un lundi matin, le prestataire MDR ouvre une alerte de gravité élevée : déplacement latéral, règles de boîte aux lettres suspectes et utilisation d’un compte à privilèges depuis un terminal non géré. L’analyste SOC déclenche l’escalade via le portail de tickets. Votre responsable informatique dort. Le CFO reçoit une alerte de phishing transmise par un contact bancaire avant même que le canal interne de gestion des incidents ne soit activé. À 07 h 30, le CISO doit répondre à trois questions sensibles.

Qui avait l’autorité pour déclarer un incident ?

Pouvons-nous prouver que le prestataire MDR disposait des bons journaux, qu’ils ont été conservés suffisamment longtemps et que les éléments de preuve ont été préservés ?

Si des données à caractère personnel ont été consultées, la fonction juridique peut-elle respecter les délais d’évaluation d’une violation au titre du GDPR pendant que les opérations préparent un signalement NIS2 ou DORA ?

Un mois plus tard, l’auditeur externe demande les mêmes éléments de preuve, sur un ton différent. Le rapport PDF du prestataire MDR est utile, mais insuffisant. L’auditeur veut les données brutes d’alerte, les fichiers journaux complets, la piste d’escalade, le journal interne des décisions, l’enregistrement de revue du fournisseur et la preuve que l’organisation pouvait vérifier de manière indépendante ce qui s’est produit.

Voilà le problème de la supervision des prestataires MDR en 2026. Les organisations externalisent la détection et la réponse parce que la capacité SOC interne est coûteuse, le recrutement difficile et l’activité des menaces permanente. Mais externaliser la détection ne signifie pas externaliser la responsabilité. Au titre de NIS2, les organes de direction restent responsables de l’approbation et de la supervision des mesures de gestion des risques de cybersécurité. Au titre de DORA, les entités financières demeurent pleinement responsables du risque lié aux tiers TIC, y compris les services TIC critiques, l’appui à la gestion des incidents, les droits d’audit, la sous-traitance et la sortie. Au titre du GDPR, les responsables du traitement doivent démontrer une sécurité du traitement appropriée, notamment lorsque des sous-traitants traitent de la télémétrie, des données de terminaux, des identifiants utilisateur, des adresses IP, du contenu de courriels, des journaux ou des images forensic.

L’écart pratique tient rarement au seul contrat MDR. Il se situe dans la chaîne probatoire entre le contrat et le service en production : routage des alertes, accès à privilèges, conservation des journaux, seuils d’escalade, éléments de preuve liés aux incidents, transparence sur les sous-traitants, clauses de sous-traitance de traitement, revues de service, exercices sur table et rapports à la direction.

Un programme défendable de supervision des prestataires MDR nécessite un modèle opérationnel unique capable de répondre à plusieurs discussions d’audit. ISO/IEC 27001:2022 fournit cette colonne vertébrale.

La supervision du MDR commence par la responsabilité, pas par la console SOC

Une erreur courante consiste à traiter l’intégration MDR comme un projet technique : déployer des agents EDR, transférer les journaux d’identité, configurer les alertes, convenir d’un canal Teams ou Slack, puis passer en production. Cela peut améliorer la détection, mais ne démontre pas la gouvernance.

NIS2 rend le sujet explicite. Les entités essentielles et importantes doivent mettre en œuvre des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées de gestion des risques de cybersécurité. Article 21 couvre l’analyse des risques, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, la cyberhygiène, le contrôle d’accès, la gestion des actifs, la cryptographie et l’authentification multifacteur. Article 20 élève ces sujets au niveau de la responsabilité des organes de direction, en exigeant l’approbation et la supervision de ces mesures.

Les prestataires MDR couvrent souvent plusieurs domaines de NIS2 Article 21 en même temps :

• Gestion des incidents, parce que le prestataire effectue le triage, déclenche l’escalade et peut recommander le confinement.
• Sécurité de la chaîne d’approvisionnement, parce que le prestataire est un prestataire de services direct ayant un impact sur la sécurité opérationnelle.
• Contrôle d’accès, parce que le prestataire peut accéder à des consoles, des journaux, des outils de terminaux ou des tenants cloud.
• Journalisation et surveillance, parce que la détection dépend de la couverture de journalisation, de la conservation et de la corrélation.
• Cyberhygiène, parce que les constats MDR exposent souvent des faiblesses de correctifs, d’identité ou de configuration.
• Continuité d’activité, parce qu’une réponse tardive peut perturber des services critiques.

Pour les entités financières, DORA renforce le modèle opérationnel. DORA s’applique depuis le 17 janvier 2025 et impose la gestion des risques liés aux TIC, le signalement des incidents, les tests de résilience, le partage d’informations et la gestion du risque lié aux tiers TIC. DORA précise également que, pour les entités financières également identifiées au titre de NIS2, DORA constitue l’acte juridique sectoriel de l’Union pour les obligations de cybersécurité qui se recoupent. Une banque réglementée, un établissement de paiement, une entreprise d’investissement, un assureur ou un prestataire de services sur crypto-actifs ne peut pas simplement dire : « Notre prestataire MDR s’en occupe. » DORA attend de l’entité qu’elle classe les incidents liés aux TIC, gère et surveille les prestataires tiers de services TIC, tienne des registres des accords de services TIC, définisse les droits contractuels, teste la résilience, réalise l’analyse de la cause racine et signale les incidents majeurs liés aux TIC par étapes.

Le GDPR ajoute un angle différent. Si la télémétrie MDR inclut des identifiants utilisateur, des adresses IP, des métadonnées de courriels, des enregistrements d’authentification, des artefacts de terminaux ou des fichiers contenant des données à caractère personnel, les principes de sécurité et de responsabilité du GDPR s’appliquent. Article 5 couvre l’intégrité, la confidentialité et la responsabilité. Article 32 sur la sécurité du traitement devient une question pratique d’éléments de preuve : les journaux étaient-ils protégés, l’accès était-il limité, le chiffrement était-il utilisé lorsque cela était approprié, les sous-traitants étaient-ils gouvernés, et l’organisation peut-elle démontrer ce qui s’est produit ?

Le message est cohérent dans les trois régimes : vous pouvez déléguer l’exécution, mais vous ne pouvez pas déléguer la responsabilité.

ISO/IEC 27001:2022 transforme le MDR en processus auditable

Un SMSI bien mis en œuvre sur la base d’ISO/IEC 27001:2022 transforme la supervision des prestataires MDR d’une promesse de gestion des fournisseurs en un modèle opérationnel fondé sur des éléments de preuve. La clause 8.1 est particulièrement importante, car elle impose aux organisations de maîtriser les processus, produits et services fournis par des tiers qui sont pertinents pour le SMSI. Le MDR correspond exactement à cette situation : un processus fourni par un tiers qui peut affecter la réponse aux incidents, la vie privée, la résilience, le reporting réglementaire et la continuité d’activité.

Les domaines les plus importants de l’Annexe A d’ISO/IEC 27001:2022 pour la supervision MDR comprennent les relations avec les fournisseurs, les exigences de sécurité dans les accords avec les fournisseurs, la gestion des risques de la chaîne d’approvisionnement TIC, la surveillance des services fournisseurs, la gestion des incidents, le traitement des éléments de preuve, la journalisation, la surveillance, le contrôle d’accès, l’accès à privilèges, la cryptographie et la préparation à la continuité d’activité.

Zenith Controls: The Cross-Compliance Guide de Clarysec Zenith Controls est la référence de conformité croisée pour ce travail. Il cartographie les mesures ISO/IEC 27002:2022 avec d’autres exigences, contrôles associés, attentes d’audit et éléments de preuve de mise en œuvre. Pour la supervision MDR, trois mesures ISO/IEC 27002:2022 sont centrales : 5.19 pour les relations avec les fournisseurs, 5.22 pour la surveillance des services fournisseurs et la gestion des changements, et 8.15 pour la journalisation. Elles sont soutenues par 5.20 accords avec les fournisseurs, 5.21 sécurité de la chaîne d’approvisionnement TIC, 5.24 à 5.28 gestion des incidents et traitement des éléments de preuve, 5.34 vie privée et PII, 5.36 conformité, 8.16 activités de surveillance, 8.17 synchronisation des horloges, 8.18 utilisation des programmes utilitaires à privilèges et 8.8 gestion des vulnérabilités techniques.

C’est important, car un échec d’audit MDR ne se résume presque jamais à « pas de MDR ». Il indique généralement l’un des points suivants :

• Le prestataire MDR n’était pas classé comme critique.
• Les clauses contractuelles ne couvraient pas la notification des incidents, l’accès aux éléments de preuve ou les droits d’audit.
• Les journaux n’étaient pas conservés suffisamment longtemps pour investiguer un événement signalé.
• L’accès du prestataire était partagé, persistant ou non surveillé.
• Le client ne revoyait pas la performance MDR au regard des SLA.
• Les sous-traitants ou sous-traitants ultérieurs n’étaient pas approuvés.
• Les obligations de notification des violations de données à caractère personnel n’étaient pas alignées avec les workflows de gestion des incidents.
• Les éléments de preuve n’étaient pas préservés d’une manière exploitable en forensic.
• La direction ne disposait d’aucun indicateur démontrant si le service MDR réduisait le risque.

Zenith Controls énonce clairement la relation entre les attentes envers les fournisseurs et les accords :

« 5.19 définit les exigences de sécurité concernant la manière dont les fournisseurs doivent traiter les informations de l’organisation. 5.20 formalise ces attentes en veillant à ce que les contrats ou accords incluent explicitement des clauses de sécurité, telles que des obligations de confidentialité, la conformité aux politiques de sécurité et des procédures de notification des incidents. Sans 5.20, les exigences identifiées dans 5.19 peuvent ne pas être juridiquement opposables. »

Pour le MDR, cette phrase est la leçon de gouvernance. Si le contrat n’impose pas au prestataire de conserver les journaux, de fournir les éléments de preuve, de coopérer lors des incidents, de restreindre la sous-traitance, de soutenir les audits et de respecter les délais d’escalade, le service SOC peut être utile opérationnellement, mais faible en audit.

Ce que le contrat MDR doit prouver avant la première alerte

Un bon contrat MDR n’est pas seulement un bon de commande commercial. C’est un document de contrôle. DORA Articles 28 à 30 imposent que le risque lié aux tiers TIC soit géré tout au long du cycle de vie, y compris les registres des contrats TIC, la classification de la criticité, les diligences précontractuelles, les modalités d’audit et d’inspection, les droits de résiliation, les stratégies de sortie, les descriptions claires des services, les niveaux de service, les lieux de fourniture du service et de traitement des données, les engagements de protection des données, l’assistance aux incidents et la coopération avec les autorités. NIS2 Article 21 impose la sécurité de la chaîne d’approvisionnement pour les fournisseurs directs et prestataires de services. Le GDPR exige la définition des rôles de responsable du traitement et de sous-traitant, les garanties du sous-traitant, les clauses de protection des données et les éléments de preuve de sécurité du traitement.

La bibliothèque de politiques Clarysec traduit ces obligations en exigences contractuelles et opérationnelles pratiques. Dans l’Enterprise Incident Response Policy Incident Response Policy, le MDR est explicitement traité comme une capacité de gestion des incidents fournie par un tiers et encadrée par la gouvernance :

« L’intégration avec des services tiers, notamment les prestataires Managed Detection and Response (MDR), Security Incident and Event Management (SIEM) et d’analyse forensic, doit être encadrée par des accords de niveau de service (SLA) clairement définis et des dispositions de non-divulgation. »

Cette clause est importante, car les prestataires MDR reçoivent souvent des informations très sensibles avant que l’organisation ne sache si un incident est notifiable. La télémétrie peut inclure des noms d’utilisateur, des chemins de fichiers, des objets de courriels, des noms d’hôtes internes, des adresses IP, des schémas réseau et des indicateurs de compromission. Les dispositions de non-divulgation protègent l’organisation pendant l’investigation et soutiennent la responsabilité au titre du GDPR.

L’Enterprise Third party and supplier security policy Third party and supplier security policy ajoute deux clauses que les auditeurs s’attendent à voir lorsqu’ils examinent la supervision MDR :

« Droits d’audit, d’inspection et de demande d’éléments de preuve de sécurité »

et :

« Recours à des sous-traitants soumis à un consentement écrit préalable »

Pour les PME, le même principe de gouvernance est adapté à l’échelle de l’organisation, mais il n’est pas supprimé. La Third-Party and Supplier Security Policy - SME Third-Party and Supplier Security Policy - SME exige le moindre privilège :

« Les fournisseurs ne doivent se voir accorder l’accès qu’aux systèmes et données strictement nécessaires à l’exécution de leur fonction. »

Elle exige également :

« Restrictions à toute sous-traitance supplémentaire sans approbation »

Ces clauses sont particulièrement pertinentes pour le MDR. De nombreux prestataires utilisent des équipes SOC à plusieurs niveaux, des fournisseurs de plateformes, des partenaires de renseignement sur les menaces, des services d’analyse cloud ou du personnel de support régional. Si des parties en aval peuvent accéder aux journaux client ou à des données à caractère personnel, le client doit disposer de mécanismes de visibilité et d’approbation. En termes DORA, cela relève de la supervision de la sous-traitance et du risque de concentration. En termes GDPR, il s’agit de la gouvernance des sous-traitants ultérieurs. En termes NIS2, cela relève de la gestion des risques de la chaîne d’approvisionnement.

La liste de contrôle essentielle de supervision MDR

Une relation défendable avec un prestataire MDR doit pouvoir être testée. La liste de contrôle suivante combine les exigences contractuelles, opérationnelles et probatoires dans une vue de contrôle unique.

Cette liste de contrôle doit être intégrée aux achats, à l’onboarding, aux revues périodiques et aux tests de gestion des incidents. Si un élément manque, l’organisation doit le traiter comme un risque fournisseur, et non comme un simple sujet documentaire.

Sept domaines d’éléments de preuve attendus par les auditeurs

Pour rendre la supervision MDR conforme aux attentes d’audit, Clarysec recommande de constituer un dossier d’éléments de preuve MDR organisé en sept domaines. Ce dossier doit être intégré au SMSI, et non conservé dans un dossier achats que personne ne revoit.

Ce tableau change le dialogue avec le prestataire. Au lieu de demander : « Nous surveillez-vous ? », l’organisation demande : « Pouvons-nous prouver, chaque trimestre, que le service MDR reste efficace, conforme et aligné sur notre appétence au risque ? »

La journalisation est le lien entre la détection et les éléments de preuve de conformité

Un MDR sans journalisation fiable relève de l’approximation externalisée. Le prestataire peut détecter certaines menaces, mais l’organisation ne peut pas prouver le périmètre, la chronologie, la cause racine ou l’impact.

La mesure ISO/IEC 27002:2022 8.15 couvre la journalisation. Zenith Controls classe la journalisation comme un contrôle détectif soutenant la confidentialité, l’intégrité et la disponibilité, aligné sur le concept de cybersécurité Detect et sur la capacité de gestion des événements de sécurité de l’information. Elle relie directement la journalisation aux activités de surveillance, à l’évaluation des événements, à la réponse aux incidents, au retour d’expérience, à l’accès à privilèges, à la synchronisation des horloges, au contrôle d’accès, à la vie privée, à la collecte des éléments de preuve, à la gestion des vulnérabilités et à la surveillance de la sécurité physique.

C’est pourquoi la journalisation est centrale pour les éléments de preuve NIS2, DORA et GDPR Article 32. Le signalement des incidents significatifs au titre de NIS2 Article 23 exige une alerte précoce dans les 24 heures suivant la prise de connaissance, une notification dans les 72 heures et un rapport final au plus tard un mois après la notification. Le signalement des incidents majeurs liés aux TIC au titre de DORA exige la classification, l’escalade, la communication, l’analyse de la cause racine et le rapport final. La responsabilité au titre du GDPR impose aux organisations de démontrer ce qui s’est produit concernant les données à caractère personnel et si les mesures de sécurité étaient appropriées.

La Logging and Monitoring Policy - SME de Clarysec Logging and Monitoring Policy - SME fournit un contrôle contractuel simple pour les petites organisations utilisant des prestataires externes :

« Les contrats doivent imposer aux prestataires de conserver les journaux pendant au moins 12 mois et d’en fournir l’accès sur demande »

Pour les environnements d’entreprise, la Logging and Monitoring Policy Logging and Monitoring Policy ajoute l’exigence d’intégration opérationnelle :

« Doit fournir les données de journaux sur demande ou s’intégrer à la plateforme SIEM/d’agrégation des journaux de l’organisation. »

Ces clauses résolvent un problème récurrent de réponse aux incidents : pendant une investigation, le prestataire MDR indique que l’événement est plus ancien que la fenêtre de conservation consultable, que les journaux ne sont disponibles que via un export forensic payant, ou que le SIEM du client ne contient pas l’enrichissement du prestataire ni les actions de l’analyste. Si l’accès aux journaux n’est pas défini à l’avance, la chronologie de l’incident devient fragmentée.

Un modèle robuste de journalisation MDR doit définir les sources de journaux obligatoires, les types d’événements, les périodes de conservation, la protection de l’intégrité, les approbations d’accès, la synchronisation temporelle, les formats d’export et les règles de corrélation entre les plateformes du client et du prestataire. Il doit également couvrir les actions du prestataire, notamment les changements de règles de détection, les commandes d’isolement de terminaux, les accès administratifs, les notes d’analystes et les exports d’éléments de preuve.

Les normes ISO de soutien renforcent cette approche. ISO/IEC 27035-1:2023 et ISO/IEC 27035-2:2023 relient la journalisation à la détection des incidents, au triage et à l’analyse centralisée. ISO/IEC 27701:2021 ajoute la journalisation propre à la vie privée des activités de traitement de PII. ISO/IEC 27017:2021 et ISO/IEC 27018:2020 ajoutent des attentes de journalisation cloud et de PII dans le cloud, notamment lorsque des prestataires traitent des données client dans des environnements de cloud public. ISO/IEC 27005:2024 présente une journalisation insuffisante comme un sujet de traitement des risques, et non comme une simple lacune d’outillage.

Réponse aux incidents : le MDR peut déclencher l’escalade, mais la direction doit décider

Les prestataires MDR détectent et conseillent. L’organisation responsable déclare les incidents, évalue l’impact réglementaire, communique avec les autorités et décide si une notification de violation de données à caractère personnel est requise.

Cette distinction est importante, car la gravité MDR ne correspond pas automatiquement à un incident significatif NIS2, à un incident majeur lié aux TIC au titre de DORA ou à une violation de données à caractère personnel au titre du GDPR. Le prestataire peut qualifier une alerte de « gravité élevée », mais l’organisation doit décider si des services critiques ont été affectés, si des données à caractère personnel ont été compromises, si les clients doivent être notifiés, si les autorités de régulation doivent être informées et si la direction doit approuver une action de confinement ayant un impact opérationnel.

L’Incident Response Policy - SME de Clarysec Incident Response Policy - SME est directe :

« Les tiers doivent agir conformément aux accords signés, lesquels doivent inclure des clauses de notification des violations de données à caractère personnel et des obligations de coopération lors de la réponse. »

Cette clause est le point de rencontre entre les éléments de preuve GDPR Article 32 et la réponse opérationnelle aux incidents. Si le prestataire MDR observe une exfiltration de données suspectée depuis un terminal contenant des données à caractère personnel, il doit savoir à quelle vitesse notifier, qui notifier, quels éléments de preuve préserver et comment soutenir l’évaluation du responsable du traitement.

Zenith Blueprint: An Auditor’s 30-Step Roadmap de Clarysec Zenith Blueprint fournit la méthode de test. Dans la phase Controls in Action, Step 19, le Zenith Blueprint demande aux équipes de valider opérationnellement la journalisation et la surveillance :

« Sélectionnez un incident ou événement récent et démontrez comment vous l’avez retracé à l’aide de vos journaux. Si des fonctionnalités d’intégrité des journaux, par exemple la vérification de hachage, sont utilisées, documentez-les également. Confirmez que l’alerte fonctionne, par exemple que des échecs de connexion ou des élévations de privilèges déclenchent des alertes. »

La même étape couvre l’identité et l’accès à privilèges :

« Pour les comptes à privilèges, vérifiez que MFA est appliquée, que les rôles administrateur sont séparés, par exemple des comptes de type admin_john utilisés uniquement pour les tâches d’administration, et qu’une liste à jour des utilisateurs à privilèges existe. »

Dans le contexte MDR, la liste des utilisateurs à privilèges doit inclure les comptes du prestataire, et pas seulement les employés. Si le prestataire MDR dispose d’un accès console, de droits d’isolement de terminaux, de droits d’administration EDR ou d’un accès en lecture à des journaux sensibles, ces comptes doivent être inclus dans la revue.

Step 23 du Zenith Blueprint fournit ensuite la structure de test des incidents et des fournisseurs :

« Sélectionnez un événement récent ou conduisez un exercice sur table afin de valider votre plan. Capturez et journalisez toutes les décisions, tous les rôles et toutes les communications (5.26), puis mettez à jour le plan avec les enseignements tirés (5.27). Confirmez que des procédures sont en place pour préserver les éléments de preuve forensic (5.28), y compris les instantanés de journaux, les sauvegardes et l’isolement sécurisé des systèmes affectés. »

Un exercice sur table réaliste doit inclure le prestataire MDR. Utilisez un scénario tel qu’un compte à privilèges compromis, l’isolement d’un terminal, un accès suspect à une boîte aux lettres, une exposition possible de données de paie et une escalade d’alerte en dehors des heures ouvrées. Le test doit vérifier si l’horloge du prestataire MDR démarre à la détection, à la notification du client ou à l’accusé de réception par le client. Cette distinction compte lorsque les délais réglementaires dépendent de la prise de connaissance et des points de décision.

Constituer un dossier de supervision MDR pour une alerte en 90 minutes

Un moyen rapide d’exposer les lacunes consiste à choisir une alerte MDR récente de gravité élevée et à construire une trace probatoire d’une page. Cet exercice pratique fonctionne bien avant les audits, les revues du conseil d’administration et les renouvellements de contrat.

1. Commencez par le ticket d’alerte. Capturez l’horodatage, la règle de détection, l’actif affecté, l’utilisateur, la gravité, les notes de l’analyste MDR et le circuit d’escalade.
2. Récupérez la clause contractuelle ou le SLA indiquant le délai de réponse attendu pour cette gravité.
3. Récupérez la liste des sources de journaux prouvant quels systèmes ont alimenté l’alerte, tels que l’EDR, le fournisseur d’identité, le pare-feu, la passerelle de sécurité de la messagerie et les journaux d’audit cloud.
4. Confirmez que les journaux sont conservés conformément à la politique et que l’événement historique peut encore être récupéré.
5. Vérifiez si l’analyste MDR a accédé à un environnement client. Si oui, capturez le compte nominatif, les éléments de preuve MFA, les journaux de session et l’approbation.
6. Documentez la décision côté client : événement clôturé, incident déclaré, évaluation juridique déclenchée, confinement réalisé ou risque accepté.
7. Si des données à caractère personnel peuvent être concernées, consignez l’analyse des rôles au titre du GDPR, le propriétaire de l’évaluation de la violation et le déclenchement éventuel des obligations de notification du sous-traitant.
8. Clôturez avec les enseignements tirés : ajustement, nouvelle détection, changement d’accès, mise à jour du playbook ou problème de SLA fournisseur.

Cette trace d’une alerte est puissante, car elle relie le contrat, la journalisation, les accès, la réponse aux incidents, la vie privée et la supervision par la direction dans une seule chaîne probatoire. Si vous ne pouvez pas la construire pour une alerte récente, vous ne pourrez probablement pas la construire sous pression réglementaire.

La surveillance des fournisseurs est le point faible de nombreux programmes MDR

De nombreuses organisations réalisent une diligence raisonnable avant de signer un contrat MDR, puis s’arrêtent. Ce n’est pas suffisant pour ISO/IEC 27001:2022, NIS2, DORA ou GDPR. Les services MDR évoluent en continu : nouvelles règles de détection, nouvelles équipes d’analystes, nouveaux sous-traitants ultérieurs, nouvelles régions de données, nouvelles capacités EDR, nouvelles intégrations, nouveaux flux de renseignement sur les menaces et nouveaux modèles de support.

La mesure ISO/IEC 27002:2022 5.22 traite de la surveillance, de la revue et de la gestion des changements des services fournisseurs. Zenith Controls explique que 5.22 s’appuie sur les contrôles relatifs aux relations avec les fournisseurs et aux accords afin d’assurer une surveillance et une gestion continues après le démarrage du service. Elle est liée à la sécurité pendant les perturbations, à la gestion des vulnérabilités, à la conformité, au contrôle d’accès et à l’ingénierie sécurisée.

DORA Articles 28 à 30 rendent ce point particulièrement important pour les entités financières. Ils imposent la surveillance continue, les registres des accords avec des tiers TIC, les distinctions de criticité, la diligence raisonnable, les droits d’audit et d’inspection, les droits de résiliation, les stratégies de sortie, les niveaux de service, l’assistance aux incidents, la coopération avec les autorités et, pour les fonctions critiques ou importantes, les objectifs de service, les tests de contingence et la coopération aux tests d’intrusion fondés sur la menace lorsque cela est pertinent.

Le Zenith Blueprint, dans la phase Controls in Action, Step 23, fournit la structure de cycle de vie fournisseur :

« Compilez une liste complète des fournisseurs et prestataires de services actuels (5.19), puis classez-les selon leur accès aux systèmes, aux données ou au contrôle opérationnel. »

Il poursuit :

« Pour chaque fournisseur critique, identifiez s’il utilise des sous-traitants ou sous-traitants ultérieurs susceptibles d’accéder à vos données ou systèmes. »

Une revue pratique du service MDR doit être organisée chaque trimestre pour les environnements critiques et au moins une fois par an pour les environnements à moindre risque. L’ordre du jour doit inclure la conformité aux SLA par gravité, les alertes escaladées, les vrais positifs, les faux positifs, les escalades manquées, l’état de santé des sources de journaux, les changements d’accès à privilèges, les nouvelles intégrations, les nouvelles régions, les sous-traitants, les sous-traitants ultérieurs, les changements de règles de détection, la performance du support aux incidents, les demandes d’éléments de preuve, les risques ouverts, les actions correctives et la préparation à la sortie.

Ce n’est pas de la microgestion. C’est la boucle d’assurance qui prouve que l’organisation gouverne activement un fournisseur de sécurité critique.

Cartographie de conformité croisée : un jeu de contrôles MDR, cinq discussions d’audit

La valeur d’ISO/IEC 27001:2022 est de fournir aux organisations un cycle SMSI cohérent pour plusieurs discussions de conformité. Le même dossier d’éléments de preuve de supervision MDR peut être cartographié avec NIS2, DORA, GDPR, NIST CSF 2.0 et COBIT 2019.

NIST CSF 2.0 est utile pour la communication. Sa fonction GOVERN exige que les obligations légales, réglementaires, contractuelles et de vie privée soient comprises et gérées, que les rôles et autorités soient définis, que le risque de cybersécurité soit intégré à la gestion des risques de l’organisation et que les risques fournisseurs soient communiqués et surveillés.

COBIT 2019 est utile pour la direction et l’assurance. Les auditeurs orientés COBIT se concentrent souvent moins sur un contrôle isolé que sur le fonctionnement systémique des objectifs de gouvernance, de la gestion des services, de la propriété des risques et de la surveillance de la performance.

Comment les auditeurs testeront la supervision des prestataires MDR

Les auditeurs utilisent des angles différents, mais ils veulent tous des éléments de preuve montrant que l’organisation maîtrise la relation.

Un auditeur ISO/IEC 27001:2022 commencera par le domaine d’application, les parties intéressées, l’appréciation des risques, la Déclaration d’applicabilité, le plan de traitement des risques et les éléments de preuve opérationnels. Si le MDR est dans le périmètre, l’auditeur s’attendra à ce que les processus fournis par des tiers soient maîtrisés dans le cadre du SMSI. Il pourra échantillonner les relations avec les fournisseurs, les accords avec les fournisseurs, la surveillance des services fournisseurs, la journalisation, la surveillance, la réponse aux incidents, le traitement des éléments de preuve et le contrôle d’accès.

Un superviseur DORA se concentrera sur la résilience opérationnelle et le risque systémique. Il pourra examiner l’évaluation de criticité, le registre des services TIC, l’analyse du risque de concentration, la stratégie de sortie, la classification des incidents, les droits d’audit et les éléments de preuve montrant que le prestataire MDR peut soutenir le reporting réglementaire.

Un auditeur GDPR ou un réviseur vie privée se concentrera sur la gouvernance responsable du traitement-sous-traitant. Il demandera le DPA, la diligence raisonnable du sous-traitant, les contrôles relatifs aux sous-traitants ultérieurs, les mesures de protection applicables aux journaux contenant des données à caractère personnel, les contrôles de conservation, les enregistrements d’évaluation des violations et les éléments de preuve soutenant Article 32.

Un auditeur COBIT ou ISACA examinera les éléments de preuve de gouvernance : propriété du risque fournisseur, workflow d’approvisionnement, comptes rendus de revue de service, suivi des problèmes SLA, action corrective, qualité des éléments de preuve et réception par la direction d’indicateurs significatifs.

La demande d’audit la plus révélatrice est simple : « Montrez-moi une alerte MDR de la détection à la clôture. » Si vous pouvez montrer l’attente contractuelle, la source de journal, l’alerte, l’escalade, la décision, la préservation des éléments de preuve, l’évaluation de la vie privée, la remédiation et le reporting à la direction, votre supervision MDR est mature. Si vous ne pouvez montrer qu’un ticket fournisseur, vous avez de la surveillance mais une gouvernance faible.

Reporting à la direction : le conseil d’administration n’a pas besoin de captures de paquets

NIS2 et DORA placent tous deux la responsabilité au niveau des organes de direction. Les conseils d’administration et les dirigeants n’ont pas besoin de télémétrie brute. Ils ont besoin d’indicateurs de supervision MDR pertinents au regard du risque.

Un tableau de bord MDR trimestriel utile comprend :

• Sources de journaux critiques intégrées par rapport aux sources attendues.
• Pourcentage d’actifs critiques couverts par le MDR.
• Alertes de gravité élevée par catégorie et service métier.
• Délai moyen entre la détection et la notification au client.
• Délai moyen entre l’accusé de réception du client et la décision.
• Manquements aux SLA et actions prestataire non résolues.
• Statut de revue des comptes à privilèges du prestataire.
• Changements de sous-traitants ou de sous-traitants ultérieurs.
• Incidents nécessitant une évaluation de notification juridique, réglementaire ou client.
• Enseignements tirés mis en œuvre.

Ce tableau de bord doit alimenter la revue de direction du SMSI, les mises à jour du traitement des risques et la revue des fournisseurs. Au titre d’ISO/IEC 27001:2022, la direction doit veiller à ce que le SMSI soit aligné sur l’orientation stratégique, que les ressources soient disponibles, que les responsabilités soient attribuées, que la communication fonctionne et que l’amélioration continue soit effective. Les indicateurs MDR constituent un moyen pratique de montrer que les opérations de sécurité externalisées sont gouvernées par la direction, et non laissées aux seuls administrateurs d’outils.

Lacunes fréquentes de supervision MDR à corriger avant les audits 2026

Les écarts les plus courants sont des défaillances de gouvernance ordinaires.

Premièrement, les organisations oublient que les prestataires MDR peuvent traiter des données à caractère personnel. Les journaux de sécurité sont parfois traités comme des « données techniques », alors qu’ils peuvent contenir des données à caractère personnel et parfois des contenus sensibles. L’analyse des rôles au titre du GDPR et les clauses de sous-traitance doivent être finalisées avant l’intégration, et non pendant une violation.

Deuxièmement, la conservation des journaux est supposée plutôt que contractualisée. Si les obligations réglementaires, forensic ou client exigent des éléments de preuve pendant plusieurs mois, le modèle de conservation MDR et SIEM doit le permettre. L’exigence de la politique SME relative à une conservation des journaux du prestataire pendant 12 mois constitue une base pratique pour de nombreux environnements.

Troisièmement, l’accès des tiers est trop permissif. Les comptes du prestataire doivent être nominatifs, protégés par MFA, surveillés, revus et limités dans le temps lorsque cela est possible. Les comptes partagés et les sessions administratives non gérées créent un risque d’audit et de réponse aux incidents.

Quatrièmement, les seuils d’incident sont ambigus. La gravité MDR ne correspond pas automatiquement à un incident juridique, à un incident majeur lié aux TIC au titre de DORA, à un incident significatif NIS2 ou à une violation de données à caractère personnel au titre du GDPR. Le playbook doit définir qui prend chaque décision.

Cinquièmement, les sous-traitants sont invisibles. Si le prestataire MDR change de plateformes d’analyse, de régions de support ou de sous-traitants ultérieurs, le profil de risque du client change. Le consentement écrit préalable et la revue périodique sont essentiels.

Sixièmement, les revues de service se limitent au volume de tickets. Les revues matures examinent les alertes manquées, les changements d’ajustement, l’état de santé des sources de journaux, la récupération des éléments de preuve, les accès du prestataire, la coopération lors des incidents et les obligations contractuelles.

Prochaines étapes : rendre votre prestataire MDR prêt pour l’audit avec Clarysec

Si votre prestataire MDR est déjà en production, n’attendez pas qu’une autorité de régulation, un auditeur client ou un incident révèle que vos éléments de preuve sont incomplets. Commencez par une alerte récente et construisez la trace. Classez ensuite le prestataire, revoyez le contrat, validez la journalisation, testez l’escalade, confirmez les clauses de sous-traitance, revoyez les accès et planifiez la surveillance fournisseur.

Clarysec peut vous aider à rendre cela opérationnel rapidement au moyen de :

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint pour une mise en œuvre par phases, notamment Step 19 pour la journalisation, la surveillance et la validation des accès, et Step 23 pour les contrôles de gestion des fournisseurs et des incidents.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls pour cartographier les mesures ISO/IEC 27002:2022 5.19, 5.22 et 8.15 avec les attentes d’audit NIS2, DORA, GDPR, NIST et COBIT.
• Les modèles de politiques Clarysec, notamment Incident Response Policy, Third party and supplier security policy, Logging and Monitoring Policy, Incident Response Policy - SME, Third-Party and Supplier Security Policy - SME, Logging and Monitoring Policy - SME et Data Protection and Privacy Policy - SME.

Le MDR est l’un des investissements de sécurité les plus utiles qu’une organisation puisse réaliser. En 2026, cette valeur doit être prouvée par la gouvernance, les éléments de preuve et une supervision responsable. Si vous souhaitez constituer un dossier pratique de supervision MDR cartographié avec ISO/IEC 27001:2022, NIS2, DORA et GDPR Article 32, Clarysec peut vous aider à le bâtir avant que la prochaine alerte ne devienne le prochain constat d’audit.