DORA : rendre les droits d’audit techniquement exécutables
Inscrire un droit d’audit dans un contrat ne suffit pas. Le fournisseur doit pouvoir produire les preuves attendues sans improviser un accès dangereux à ses systèmes.
Article rédigé automatiquement par une intelligence artificielle, à titre informatif. Il peut contenir des imprécisions et ne constitue pas un conseil juridique.
Le règlement (UE) 2022/2554, dit DORA, impose aux entités financières de mieux encadrer leurs contrats portant sur des services TIC. Pour les services qui soutiennent une fonction critique ou importante, son article 30, paragraphe 3, point e), prévoit notamment des droits de suivi comprenant l’accès, l’inspection et l’audit, ainsi que la possibilité de prendre copie des documents pertinents. DORA ne transforme pas automatiquement chaque fournisseur en entité financière régulée. Il crée toutefois une contrainte contractuelle très concrète : le fournisseur doit être en mesure de rendre ces droits effectifs. Une clause large, suivie d’un processus vague ou inexistant, déplace simplement le problème jusqu’au premier contrôle.
L’audit n’est pas un accès administrateur
Un droit d’audit ne signifie pas qu’un client, son auditeur ou une autorité doit recevoir un accès sans limite à la production. Cette interprétation créerait de nouveaux risques : exposition des données d’autres clients, fuite de secrets techniques, modification involontaire d’une configuration ou contournement de la séparation des rôles. L’enjeu consiste à fournir une visibilité suffisante, vérifiable et traçable, dans un périmètre maîtrisé. Cela suppose de distinguer l’examen documentaire, l’entretien avec les responsables, l’observation d’une opération, l’extraction de journaux, la visite d’un site et le test technique. Ces modalités ne donnent pas accès aux mêmes informations et ne présentent pas le même niveau de risque. Les traiter comme une demande unique appelée « audit » est une mauvaise base opérationnelle.
Préparer un chemin de preuve
- Définir le périmètre de service auditable : composants exploités, fonctions couvertes, lieux de traitement, responsabilités partagées et dépendances nécessaires à la prestation. Le périmètre contractuel doit pouvoir être rapproché d’un inventaire technique tenu à jour.
- Associer chaque exigence à une preuve identifiable : configuration approuvée, historique de changement, journal d’accès, résultat de test, compte rendu d’incident, contrôle de sauvegarde ou mesure de niveau de service. Une politique générale ne prouve pas à elle seule son application.
- Prévoir des identités temporaires et nominatives pour les examens techniques, avec authentification forte, droits minimaux, durée limitée et journalisation. Les comptes partagés ou permanents accordés à l’occasion d’un audit sont difficilement défendables.
- Isoler les éléments concernant d’autres clients. Dans un environnement mutualisé, les extractions doivent être filtrées, les données sensibles masquées lorsque cela est nécessaire et les consultations réalisées dans un espace contrôlé. La confidentialité ne doit pas servir à refuser toute preuve, mais elle doit structurer sa production.
- Organiser la conservation et l’export des éléments. Les formats doivent rester lisibles, les horodatages cohérents et l’origine des documents démontrable. Une capture d’écran isolée, sans contexte ni date fiable, constitue une preuve fragile.
Tester le dispositif avant la demande
Le moment d’éprouver ce mécanisme n’est pas l’arrivée d’un auditeur. Un exercice interne permet de vérifier qui reçoit la demande, qui en valide le périmètre, quels délais sont réalistes et quelles équipes produisent les éléments. Il révèle aussi les dépendances oubliées : journaux détenus par un sous-traitant, preuves accessibles seulement depuis un outil donné, documents non versionnés ou responsabilité mal attribuée entre exploitation et sécurité. Les rapports indépendants, certifications et audits mutualisés peuvent contribuer au dispositif d’assurance, selon le contexte et les stipulations applicables. Ils ne doivent pas être présentés comme un remplacement automatique de tout droit contractuel d’accès, d’inspection ou d’audit. Le fournisseur doit savoir expliquer ce que chaque rapport couvre, sa période de validité, ses exclusions et les écarts encore ouverts. La bonne unité de travail n’est donc pas le document remis, mais la chaîne complète reliant une exigence, un contrôle, son exécution et une preuve reproductible.
La portée exacte des droits d’audit dépend du service, de la criticité de la fonction soutenue, du contrat et des règles applicables à l’entité concernée. Cet article présente des principes opérationnels généraux et ne constitue pas un avis juridique. Avant signature, les équipes juridiques, sécurité, exploitation et conformité doivent vérifier ensemble que les clauses peuvent être exécutées sans compromettre les données, les autres clients ou la stabilité du service.
Regulation (EU) 2022/2554, known as DORA, requires financial entities to place stronger controls around contracts for ICT services. For services supporting a critical or important function, Article 30(3)(e) notably provides for monitoring rights that include access, inspection and audit, as well as the right to take copies of relevant documents. DORA does not automatically turn every provider into a regulated financial entity. It does, however, create a concrete contractual constraint: the provider must be able to make these rights effective. A broad clause followed by a vague or non-existent process merely postpones the problem until the first review.
An audit is not administrator access
An audit right does not mean that a client, its auditor or an authority should receive unrestricted access to production systems. That interpretation would create new risks: exposure of other clients’ data, disclosure of technical secrets, accidental configuration changes or circumvention of role separation. The objective is to provide sufficient, verifiable and traceable visibility within a controlled scope. This requires a distinction between document review, interviews with accountable staff, observation of an operation, log extraction, a site visit and technical testing. These methods do not expose the same information or carry the same level of risk. Treating them as a single request labelled “audit” is a poor operational starting point.
Build an evidence path
- Define the auditable service scope: operated components, covered functions, processing locations, shared responsibilities and dependencies required to deliver the service. The contractual scope must be reconcilable with an up-to-date technical inventory.
- Map each requirement to identifiable evidence: an approved configuration, change history, access log, test result, incident record, backup control or service-level measurement. A general policy does not, by itself, prove that the policy is applied.
- Provide temporary, named identities for technical reviews, with strong authentication, minimum privileges, limited duration and logging. Shared or permanent accounts created for an audit are difficult to justify.
- Separate information relating to other clients. In a shared environment, extracts must be filtered, sensitive data masked where necessary and reviews conducted in a controlled space. Confidentiality must not become a reason to refuse all evidence, but it must shape how evidence is produced.
- Organise evidence retention and export. Formats must remain readable, timestamps consistent and document provenance demonstrable. An isolated screenshot without context or a reliable date is weak evidence.
Test the process before a request
The arrival of an auditor is not the right time to test this mechanism. An internal exercise can verify who receives the request, who approves its scope, which timeframes are realistic and which teams produce the evidence. It also exposes overlooked dependencies: logs held by a subcontractor, evidence available only through a particular tool, unversioned documents or unclear ownership between operations and security. Independent reports, certifications and pooled audits may contribute to the assurance framework, depending on the context and applicable terms. They should not be presented as an automatic replacement for every contractual right of access, inspection or audit. The provider must be able to explain what each report covers, its validity period, its exclusions and any unresolved findings. The correct unit of work is therefore not the document delivered, but the complete chain connecting a requirement, a control, its execution and reproducible evidence.
The exact scope of audit rights depends on the service, the criticality of the supported function, the contract and the rules applying to the entity concerned. This article outlines general operational principles and does not constitute legal advice. Before signature, legal, security, operations and compliance teams should jointly verify that the clauses can be executed without compromising data, other clients or service stability.