Tiers dans le TLPT DORA : autorisations et tests mutualisés

La décision que ce guide vous aide à prendre

Un contrat de service n’autorise pas nécessairement des tests offensifs sur l’infrastructure d’un fournisseur. Identifiez les dépendances TIC pertinentes et clarifiez rapidement la participation, les autorisations et les contraintes des environnements partagés. Faites apparaître les responsabilités de l’entité financière lors de l’évaluation de tout dispositif de test mutualisé.

Une fonction critique dépasse rarement les limites de l’entité

Les entités financières s’appuient sur des prestataires tiers de services TIC pour des fonctions susceptibles d’être incluses dans un TLPT. DORA encadre cette participation et exige des accords pour toute participation pertinente. L’externalisation d’une dépendance ne dégage pas l’entité financière de sa responsabilité.

La définition du périmètre doit distinguer la fonction à tester, les systèmes qui la prennent en charge et les autorisations légales requises pour tester ces systèmes. Un contrat d’utilisation d’un service n’autorise pas nécessairement à mener des tests offensifs contre celui-ci.

Identifier la dépendance avant de sélectionner les scénarios

Documentez ce que le prestataire prend en charge, les systèmes ou processus susceptibles d’être concernés et si le service est partagé avec d’autres clients. Établissez rapidement les circuits de contact contractuels et opérationnels.

Un scénario peut dépendre de services d’identité, de l’hébergement, des communications ou d’un processus opérationnel externalisé. Si la participation est présumée sans avoir été convenue, le calendrier et la valeur probante de la mission peuvent tous deux en pâtir.

Convenir de la participation et des mesures de protection opérationnelles

• Identifier le prestataire concerné et toute dépendance importante à la sous-traitance.
• Obtenir les autorisations et les accords contractuels nécessaires à l’activité proposée.
• Clarifiez les limites du tenant, les actions interdites et les effets sur les autres clients.
• Définissez les voies d’escalade, les conditions d’arrêt et la coordination des incidents.
• Convenir du traitement des éléments probants, des accès, de la confidentialité et de la diffusion des rapports.

N’exposez pas d’autres clients à l’exercice et ne considérez pas automatiquement que toute la plateforme du prestataire entre dans le périmètre. L’équipe de contrôle, le prestataire et la procédure de l’autorité doivent partager une compréhension commune des limites.

Quand des tests mutualisés peuvent être pertinents

DORA prévoit des dispositifs de tests mutualisés dans les circonstances décrites à l’article 26, notamment lorsque la participation à un test pourrait nuire à la qualité ou à la sécurité du service fourni à d’autres clients, ou à la confidentialité. Ces dispositifs doivent respecter les conditions applicables et le processus de supervision.

Un rapport générique de test d’intrusion d’un prestataire ne constitue pas automatiquement un TLPT mutualisé et ne remplace pas les obligations d’une entité. Déterminez quelles fonctions, quels participants et quels risques le dispositif proposé couvre réellement, et comment sa reconnaissance sera gérée.

Intégrez le sujet au premier brief

Indiquez aux prestataires de tests potentiels quelles dépendances TIC sont susceptibles d’être importantes et quels dispositifs de participation sont déjà en place. Présentez les autorisations en attente comme des dépendances, et non comme des exclusions dissimulées.

La meilleure étape suivante consiste souvent à établir une cartographie plus précise et à convenir d’un canal de contact. Des scénarios détaillés pourront ensuite être élaborés dans le cadre d’un périmètre à la fois pertinent et autorisé.

Préparer un brief de participation adapté aux dépendances

Décrivez la fonction assurée par le prestataire, la limite de service concernée, la participation proposée et les preuves attendues. Identifiez les interlocuteurs en mesure d’aborder le périmètre technique, l’autorisation contractuelle et les mesures de protection opérationnelles. Une demande générale visant à « soutenir notre TLPT » laisse trop de place à l’interprétation. Distinguez les activités portant sur la configuration du service propre à l’entité de celles qui affectent une plateforme partagée ou l’environnement d’un autre client.

Le guide des identités cloud dans la fintech aide à formuler une comparaison ciblée entre principal, ressource et opération. Le guide du périmètre d’achat des tests bancaires montre comment conserver les autorisations manquantes sous forme d’hypothèses explicites. Ces méthodes de préparation sont utiles dans le cadre du processus plus large de coordination TLPT.

Convenir de la manière dont les éléments probants du prestataire sont intégrés à la clôture

Déterminez quelles observations le prestataire peut fournir, qui peut y accéder et comment elles seront corrélées à la chronologie de l’exercice. Consignez toute limite liée à une infrastructure partagée, à la confidentialité ou à la conservation. Les éléments de preuve fournis par un prestataire doivent être identifiés comme tels et accompagnés du contexte et des limites pertinents, plutôt que présentés comme une action observée de manière indépendante par l’équipe de test.

Si la participation ou la méthode proposée ne peut pas faire l’objet d’un accord, faites remonter cette dépendance dans le processus de gouvernance applicable. Ne l’omettez pas sans le signaler tout en maintenant une affirmation générale sur la couverture de la fonction. Consignez le motif, l’incidence sur les scénarios et toute solution de remplacement approuvée. Les responsables des tests et l’entité disposent ainsi d’une base claire pour décider du traitement de cette limite, et une hypothèse commerciale ne devient pas une autorisation de test non documentée.

Poursuivez votre préparation

• Définir le périmètre d’un TLPT
• Questions relatives aux achats