DORA vs NIS2 : quelles obligations pour les prestataires IT ?

Pourquoi les prestataires IT confondent encore DORA et NIS2

La confusion est logique. Les deux textes parlent de cybersécurité, de gouvernance, de continuité, de gestion des incidents et de contrôle des prestataires. Pourtant, ils ne fonctionnent pas du tout de la même manière.

DORA est un règlement centré sur la résilience opérationnelle numérique du secteur financier. Il impose aux entités financières un cadre précis pour piloter leurs risques TIC et encadrer contractuellement leurs prestataires, avec en plus une supervision européenne spécifique pour certains prestataires TIC critiques.

NIS2 est une directive de cybersécurité plus large. Elle peut rendre certaines entreprises informatiques directement régulées si leur activité relève des secteurs visés, notamment la gestion des services TIC, et si elles remplissent les critères applicables de taille ou de qualification.

Le point clé pour un infogéreur est donc simple. Vous pouvez être concerné par DORA parce que vos clients financiers vous imposent des exigences contractuelles et des preuves de conformité, et être en parallèle directement concerné par NIS2 si votre activité entre dans son champ.

DORA : ce que vos clients financiers vont exiger de vous

DORA ne se limite pas à demander de « bonnes pratiques ». L’article 30 impose que les droits et obligations de l’entité financière et du prestataire TIC soient clairement répartis et mis par écrit, dans un document contractuel unique intégrant notamment les niveaux de service .

Autrement dit, un infogéreur ne peut plus se contenter d’un contrat commercial standard, d’annexes incomplètes ou de procédures internes non opposables. Ce que vos clients financiers attendent désormais, c’est un corpus formalisé, traçable, cohérent et auditable .

C’est exactement là que beaucoup de prestataires bloquent en pratique. Ils ont des procédures, parfois même des réflexes opérationnels solides, mais rien n’est réellement formalisé sous forme de politique, de procédure validée, de matrice de responsabilité ou de preuve exploitable en audit.

Les clauses qui doivent apparaître dans vos contrats DORA

Si vous intervenez pour une banque, une assurance, un acteur du paiement, une société de gestion ou un autre acteur financier, vos contrats doivent au minimum couvrir des éléments très précis.

1. Une description claire et complète des services fournis, avec l’indication du recours éventuel à la sous traitance et les conditions applicables.
2. Les lieux où les services sont fournis et où les données sont traitées ou stockées, avec une obligation d’information préalable en cas de changement.
3. Les engagements liés à la disponibilité, à l’authenticité, à l’intégrité et à la confidentialité des données, y compris les données personnelles.
4. Les modalités d’accès, de récupération et de restitution des données en cas de fin de contrat, d’insolvabilité ou d’arrêt d’activité du prestataire. (La Réversibilité)
5. Les niveaux de service, leurs mises à jour et, pour les fonctions critiques ou importantes, des objectifs de performance qualitatifs et quantitatifs suffisamment précis pour permettre un vrai suivi.
6. L’assistance du prestataire en cas d’incident TIC lié au service fourni, sans coût supplémentaire ou avec un coût défini à l’avance.
7. La coopération du prestataire avec les autorités compétentes et les autorités de résolution de l’entité financière.
8. Les droits de résiliation, les préavis minimaux, les droits d’accès, d’inspection et d’audit, ainsi que la coopération lors des contrôles sur site.
9. Les exigences de continuité d’activité, les plans de secours testés, les mesures de sécurité TIC et les politiques nécessaires au niveau du prestataire.
10. Une stratégie de sortie avec période de transition adaptée, afin de permettre au client financier de migrer vers un autre prestataire ou de réinternaliser le service sans rupture.

Pour les prestataires IT, le sujet n’est donc plus seulement technique. Il devient juridique, documentaire, organisationnel et probatoire.

NIS2 : quand un infogéreur devient directement régulé

Côté NIS2, la logique est différente. L’ANSSI rappelle qu’une entité peut entrer dans le périmètre si son activité relève d’un secteur ou sous secteur visé par la directive et si elle remplit les autres critères de définition d’une entité essentielle ou importante, notamment les seuils d’effectif, de chiffre d’affaires ou de bilan selon les cas.

L’ANSSI donne aussi une définition très utile du fournisseur de services gérés. Il s’agit d’une entité qui fournit des services liés à l’installation, à la gestion, à l’exploitation ou à l’entretien de produits, réseaux, infrastructures ou applications TIC, via une assistance ou une administration active, sur site ou à distance.

Pour un infogéreur, cette définition est centrale. Dès lors que vous administrez, exploitez, maintenez, supervisez ou assistez activement les environnements de vos clients, vous êtes précisément dans le type d’activité que NIS2 regarde de près.

NIS2 attend ensuite des mesures de gestion des risques et de cybersécurité structurées. Le texte vise notamment les politiques d’analyse des risques, la gestion des incidents, la continuité d’activité, la reprise après sinistre, la gestion de crise, la sécurité de la chaîne d’approvisionnement et la sécurité dans l’acquisition, le développement et la maintenance des systèmes d’information.

En clair, un infogéreur peut être confronté à deux niveaux d’exigence.

1. Des exigences contractuelles DORA portées par ses clients financiers .
2. Des obligations directes NIS2 si son activité et sa taille le placent dans le périmètre de la directive.

DORA vs NIS2 : la différence en un tableau

Sujet	DORA	NIS2
Logique du texte	Règlement sectoriel orienté résilience numérique du secteur financier cms	Directive de cybersécurité couvrant des entités essentielles ou importantes dans plusieurs secteurs streamlex+1
Votre exposition en tant que prestataire IT	Vous êtes surtout exposé via les exigences imposées par vos clients financiers et par leurs contrats, avec une supervision spécifique pour certains prestataires TIC critiques amf-france	Vous pouvez être directement régulé si votre activité relève de la gestion des services TIC ou d’un autre secteur visé et si les critères applicables sont remplis Memory+1
Point d’entrée principal	Le contrat, la gouvernance du risque tiers, la preuve de résilience et la capacité d’audit	Le périmètre d’activité, la taille, la gouvernance cyber et les mesures de gestion des risques prévues par la directive Memory+1
Ce que vos clients vont regarder	SLA, sécurité, continuité, sous traitance, localisation des données, incidents, audit, réversibilité	Politiques de sécurité, incidents, PRA, PCA, chaîne d’approvisionnement, maintenance et analyse de risque streamlex
Erreur la plus fréquente	Penser qu’un contrat commercial générique suffit	Penser qu’être “simple prestataire” suffit à sortir du périmètre

Les 4 écarts que nous voyons le plus chez les infogéreurs

Le premier écart, c’est la formalisation. L’entreprise travaille sérieusement, mais ses règles vivent dans des habitudes, des tickets, des échanges Teams ou des fichiers épars. En audit, cela ne vaut pas une politique validée, diffusée, tenue à jour et rattachée à des responsabilités claires.

Le deuxième écart concerne les ressources humaines. Les accès, les arrivées et départs, la sensibilisation, la gestion des habilitations sensibles ou les engagements de confidentialité existent souvent de manière implicite, alors que les clients régulés attendent des preuves nettes, cohérentes et opposables.

Le troisième écart, c’est la documentation technique. Beaucoup d’infogéreurs déploient des fonctions utiles et robustes, mais sans documentation structurée sur l’architecture, les dépendances, les sauvegardes, la journalisation, les scénarios de reprise ou les points de contrôle.

Le quatrième écart, souvent le plus bloquant, se situe dans les contrats. Les garanties attendues sur l’audit, l’assistance en cas d’incident, la localisation des données, la continuité, la sous traitance ou la réversibilité ne sont pas toujours prévues, ou le sont de manière trop vague pour satisfaire un client financier soumis à DORA .

Ce qu’un infogéreur doit mettre en place en 2026

La priorité n’est pas d’empiler des documents. La priorité est de construire un dispositif défendable, lisible et exploitable par un client, un auditeur ou un régulateur.

1. Qualifier votre exposition réglementaire

Commencez par trancher deux questions. Êtes vous un prestataire TIC de clients financiers soumis à DORA, et êtes vous potentiellement un fournisseur de services gérés au sens de NIS2 ?

Cette étape évite une erreur très coûteuse. Beaucoup d’entreprises travaillent leur cybersécurité sans cadrer leur périmètre réglementaire réel, puis découvrent trop tard que le sujet principal était le contrat, la preuve et la gouvernance.

2. Transformer vos pratiques en politiques

C’est le chantier le plus rentable. Si vous faites déjà les choses, il faut maintenant les transformer en politiques, procédures, registres, modèles et éléments de preuve.

En pratique, nous recommandons de formaliser au minimum les sujets suivants :

1. Gestion des accès et habilitations.
2. Gestion des incidents.
3. Sauvegarde, continuité et reprise.
4. Gestion des changements.
5. Gestion des vulnérabilités.
6. Gestion des fournisseurs et de la sous traitance.
7. Résilience Opérationnelle
8. Sécurité RH.
9. Journalisation et traçabilité.
10. Gestion documentaire.
11. Réversibilité et fin de contrat.

Cette logique rejoint d’ailleurs les attentes NIS2 en matière d’analyse des risques, de traitement des incidents, de continuité d’activité et de sécurité de la chaîne d’approvisionnement.

3. Reprendre vos contrats client et fournisseur

Un infogéreur doit traiter deux faces du risque. D’un côté, il doit être capable de répondre aux exigences de ses clients financiers. De l’autre, il doit encadrer ses propres fournisseurs pour ne pas transporter un risque non maîtrisé dans sa chaîne de service.

Cela suppose de revoir vos contrats, annexes techniques, SLA, clauses de sécurité, clauses de sous traitance, clauses d’audit, engagements de notification, modalités de coopération, mécanismes de réversibilité et localisation des traitements .

4. Préparer la preuve avant qu’on vous la demande

Le vrai sujet DORA c’est : Pouvons nous le démontrer rapidement, clairement et contractuellement ?.

C’est pourquoi nous conseillons toujours de construire un dossier de preuve simple, vivant et piloté. Politiques approuvées, procédures, matrice des rôles, inventaire des services, cartographie des sous traitants, clauses contractuelles, tests de continuité, suivi des incidents, revues périodiques et plan d action doivent pouvoir être produits sans improvisation.

Ce que les clients financiers attendent vraiment d’un prestataire IT

Ils n’attendent pas un discours rassurant. Ils attendent un prestataire capable de répondre vite, de fournir des documents cohérents, d’accepter un niveau de contrôle plus élevé et de démontrer qu’il maîtrise ses propres dépendances.

Ils attendent aussi un partenaire qui comprend leur contrainte réglementaire. DORA impose un encadrement écrit, une surveillance continue des prestations TIC, des droits d’audit, des exigences de continuité et des stratégies de sortie sur les services critiques ou importants .

Autrement dit, en 2026, un bon infogéreur vend de la confiance documentée.

Si vous servez des acteurs financiers, le bon réflexe n’est pas d’attendre la prochaine demande client. Chez Cyberstrat, nous vous accompagnons avec un Audit DORA orienté terrain, puis avec le suivi du plan d action attendu par la réglementation et dans la logique des attentes du régulateur, pour sécuriser vos contrats, vos politiques et vos preuves de conformité.