Cartographie DORA du prestataire TIC #
Pour une entité financière, se doter d’un canal de signalement n’est pas un achat de logiciel ordinaire. Le règlement (UE) 2022/2554 (DORA) s’applique depuis le 17 janvier 2025 et fait d’EthicsPortal un prestataire tiers de services TIC : la relation passe par votre processus de gestion du risque lié aux tiers TIC, figure dans votre registre d’informations et doit comporter les clauses contractuelles de l’article 30.
Cette page fournit des informations relevant du prestataire. Elle ne constitue ni un conseil juridique, ni une certification de conformité, ni une garantie d’adéquation réglementaire, ni une partie d’un contrat client. L’entité financière doit vérifier ces informations au regard de sa propre classification, de son évaluation des risques et de l’usage prévu.
Le modèle contractuel DORA présente les sujets qu’une commande DORA bilatérale doit couvrir. Sa publication, un abonnement, l’acceptation du DPA ou une classification unilatérale ne le rendent pas contraignant. Les engagements DORA ne naissent qu’après signature par les deux parties d’une commande délimitée comportant des annexes fixes, des tarifs d’assistance et des conditions de transition.
DORA n’impose pas de canal de signalement. Il encadre la façon dont vous vous en dotez. L’obligation découle de la directive 2019/1937 — qui, en vertu de l’Art. 8(4) , s’applique aux entités relevant des actes de l’Union sur les services financiers et la lutte contre le blanchiment indépendamment de leur effectif — ainsi que des règles sectorielles résumées sur la page services financiers .
Dernière mise à jour : 2026-09-06.
Comment lire cette page #
| Statut | Signification |
|---|---|
| Commande DORA requise | Le point doit être complété et intégré dans une commande DORA bilatérale signée avant de devenir contractuel |
| Publié | L’information requise est publiée sur ce site et peut être reprise telle quelle dans votre registre ou votre évaluation |
| Partiel | Acquis sur le fond, avec une limite énoncée — la limite est nommée, pas éludée |
| Non proposé | Indisponible. Le motif est indiqué et le point figure parmi les points ouverts lorsqu’il est corrigeable |
Le service entre-t-il dans le champ pour vous ? #
Deux qualifications, dans cet ordre.
Est-ce un service TIC ? Oui. EthicsPortal est fourni en software-as-a-service et relève du type S19 (services en nuage : SaaS) dans la taxonomie des services TIC utilisée par le registre d’informations.
Soutient-il une fonction critique ou importante ? Cette qualification vous appartient, elle n’est pas la nôtre à affirmer. Les éléments dont vous avez besoin :
- La fonction soutenue est une obligation légale de conformité, non une activité agréée. Ses délais légaux se comptent en jours et en mois — 7 jours pour l’accusé de réception, 3 mois pour le retour d’information au titre de la directive 2019/1937 — face à un objectif de temps de rétablissement (RTO) de 4 heures. Une indisponibilité ne consomme aucune fraction significative de ces délais.
- Le service ne détient aucun fonds de clients, n’exécute aucune transaction et ne se trouve sur aucune chaîne de paiement, de négociation, de règlement ou de système bancaire central. Il n’est intégré à aucun de vos systèmes : il fonctionne de façon autonome et ne peut donc pas propager une défaillance vers l’intérieur.
- Il traite en revanche des informations susceptibles d’être protégées par le secret dans votre secteur, ce qui rend les mesures de confidentialité ci-dessous pertinentes quelle que soit la qualification retenue.
Le résultat dépend de votre évaluation documentée au titre de l’article 3, point 22, notamment de la question de savoir si une perturbation ou une prestation défaillante compromettrait sensiblement le respect continu de vos obligations réglementaires. Les faits ci-dessus éclairent cette évaluation sans en prédéterminer le résultat.
Données du registre d’informations #
Les champs dont une entité financière a besoin pour le registre d’informations prévu à l’article 28, paragraphe 3, de DORA et au règlement d’exécution (UE) 2024/2956 — pour le prestataire direct et pour la chaîne de sous-traitance.
Prestataire direct #
| Champ | Valeur |
|---|---|
| Dénomination | Yaroslav Shmarov, entrepreneur individuel (jednoosobowa działalność gospodarcza), exerçant sous le nom EthicsPortal |
| Pays d’immatriculation | 🇵🇱 Pologne |
| Adresse | ul. Obrzeżna 1A, 02-691 Varsovie, Pologne |
| Code d’identification | Numéro fiscal polonais (NIP) 5272755790 |
| Type de code d’identification | VAT — code ITS applicable à un numéro de TVA |
| Type de service TIC | S19 — services en nuage : SaaS |
| Fonction soutenue | Canal de signalement interne au sens de la directive 2019/1937 et des règles sectorielles applicables |
| Pays de fourniture du service | 🇩🇪 Allemagne |
| Pays de stockage des données | 🇩🇪 Allemagne (Nuremberg) |
| Sensibilité des données stockées | À apprécier selon votre propre classification. Le contenu des signalements, l’identité de l’auteur et les messages sont chiffrés au repos au niveau du champ ; voir Sécurité |
| Recours à la sous-traitance | Oui — la chaîne figure ci-dessous et est publiée sur /subprocessors/ |
| Droit applicable au contrat | 🇵🇱 Pologne (CGU §13 ) |
| Soutien à une fonction critique ou importante de l’entité | Qualification de l’entité financière — voir champ d’application |
À propos du code d’identification. EthicsPortal ne dispose pas d’identifiant d’entité juridique (LEI). L’opérateur est un entrepreneur individuel inscrit au CEIDG polonais et non une société inscrite au KRS, de sorte qu’aucun identifiant unique européen (EUID) ne lui est attribué non plus. Utilisez le NIP ci-dessus avec le type de code VAT. L’obtention d’un LEI figure parmi les points ouverts ; il sera publié ici dès son attribution.
Chaîne de sous-traitance #
La liste des sous-traitants ultérieurs au titre du RGPD et la chaîne de services DORA ne sont pas identiques. Le tableau contient les prestataires directs dont les composants soutiennent le Service. EthicsPortal occupe le rang 1 et les prestataires directs le rang 2. Il n’affirme pas que la chaîne s’arrête là : les prestataires en aval n’ont pas encore été validés aux fins du registre. Pour une fonction critique ou importante, cette validation doit être achevée avant l’acceptation de la qualification.
| Sous-traitant | Pays | Type de service TIC | Rang | Ce qu’il traite |
|---|---|---|---|---|
| Hetzner Online GmbH | 🇩🇪 Allemagne | S17 — services en nuage : IaaS | 2 | Serveur applicatif, base de données, stockage des pièces jointes — toutes les données de signalement |
| Mailjet SAS (Sinch) | 🇫🇷 France | S19 — services en nuage : SaaS | 2 | Adresses e-mail des gestionnaires et acheminement des notifications. Aucun contenu de signalement |
| AppSignal B.V. | 🇳🇱 Pays-Bas | S19 — services en nuage : SaaS | 2 | Télémétrie d’erreurs et de performance des interfaces gestionnaires. Les adresses IP des auteurs ne sont jamais journalisées |
Toutes les données de signalement sont traitées dans l’UE. Les dénominations légales, identifiants, sociétés mères, lieux exacts de fourniture et rangs aval applicables doivent être confirmés au moyen de preuves fournisseurs à jour avant toute remise du registre à l’autorité compétente.
Tout changement de sous-traitant est notifié au moins 30 jours à l’avance ; vous pouvez vous y opposer et résilier à défaut d’accord (DPA §6.4 ).
Article 30, paragraphe 2 — clauses de base #
Elles s’appliquent à tout contrat de services TIC, quelle que soit la qualification.
| Art. 30, § 2 | Exigence | Statut | Où |
|---|---|---|---|
| point a | Description des fonctions et services ; indication du caractère autorisé de la sous-traitance et de ses conditions | DPA / CGU + commande requise | Le DPA §2 et le §8 fournissent le périmètre standard et la chaîne de sous-traitance. Une commande DORA doit fixer le service couvert et les conditions de sous-traitance TIC |
| point b | Lieux — régions ou pays — de fourniture et de traitement des données, avec préavis en cas de changement | Publié + commande requise | Lieux actuels sur /subprocessors/ et Sécurité#Infrastructure . La commande DORA doit fixer les lieux applicables et le préavis de changement |
| point c | Disponibilité, authenticité, intégrité et confidentialité des données, y compris à caractère personnel | DPA / CGU + publié | Le DPA §6.3 et /security/ décrivent les contrôles contractuels et opérationnels standard |
| point d | Accès, récupération et restitution des données dans un format aisément accessible en cas d’insolvabilité, de résolution, de cessation d’activité ou de fin du contrat | Partiel + commande DORA requise | Les exports standard et les droits de restitution/effacement du DPA existent. Les formats supplémentaires, délais, mesures de continuité et limites d’incapacité doivent être fixés dans la commande ; voir le modèle §5 |
| point e | Description des niveaux de service, y compris leurs mises à jour | Publié + commande requise | /sla/ décrit l’offre standard. La commande doit identifier la version contraignante et le processus de modification |
| point f | Assistance en cas d’incident TIC sans coût supplémentaire ou à un coût déterminé ex ante | Commande DORA requise | Les notifications ordinaires et les informations déjà produites sont incluses. L’assistance DORA propre au client exige des heures incluses et un tarif fixé ex ante dans la commande ; voir le modèle §6 |
| point g | Pleine coopération avec les autorités compétentes et les autorités de résolution | Commande requise | Le périmètre et la procédure doivent figurer dans la commande signée ; voir le modèle §7 |
| point h | Droits de résiliation et préavis minimaux | Commande DORA requise | La résiliation ordinaire suit les CGU. Les motifs DORA et préavis minimaux doivent figurer dans la commande signée ; voir le modèle §9 |
| point i | Conditions de participation aux programmes de sensibilisation à la sécurité TIC et aux formations à la résilience opérationnelle numérique (art. 13, § 6) | Commande DORA requise | Le format, la fréquence, les heures incluses et le tarif fixé ex ante doivent figurer dans la commande ; voir le modèle §8 |
Article 30, paragraphe 3 — clauses étendues (fonctions critiques ou importantes) #
Ces sujets ne s’appliquent que si une commande DORA signée par les deux parties qualifie le Service comme soutenant une fonction critique ou importante. Une classification unilatérale ne les active pas.
| Art. 30, § 3 | Exigence | Statut | Où |
|---|---|---|---|
| point a | Description complète des niveaux de service assortie d’objectifs de performance quantitatifs et qualitatifs précis | Base publiée + commande requise | /sla/ décrit l’offre standard. La commande signée doit fixer les objectifs contraignants, la mesure, le rapport et les mesures correctives |
| point b | Préavis et obligations de signalement, y compris pour tout événement ayant une incidence significative sur la fourniture du service | Commande requise | La commande signée doit définir les événements significatifs, le contenu des rapports et les délais de préavis |
| point c | Plans de continuité testés et mesures de sécurité TIC appropriées | Publié | Plan de continuité avec déclencheurs et objectifs de reprise ; politique de sécurité de l’information ; registre des risques . Les tests de restauration s’exécutent chaque mois en CI et la fraîcheur des sauvegardes est surveillée en continu (Sécurité ) |
| point d | Participation aux tests de pénétration fondés sur la menace (art. 26-27) | Commande + cahier des charges requis | Le périmètre, la sécurité, les responsabilités, l’environnement et tous les coûts doivent être convenus par écrit ; voir le modèle §8 |
| point e | Droits illimités d’accès, d’inspection et d’audit, y compris par l’autorité compétente | Commande requise ; validation de la chaîne ouverte | La commande doit préserver les droits requis tout en fixant la logistique ordinaire et les tarifs d’assistance convenus ex ante. L’accès aux fournisseurs n’existe que s’il est vérifié ; voir le modèle §7 |
| point f | Stratégies de sortie assorties d’une période de transition obligatoire et adéquate | Commande DORA requise | La durée, la poursuite du service, les exports, la migration, les frais, la coopération du client et les limites d’incapacité doivent être fixés dans la commande ; voir le modèle §10 |
Article 28 — les obligations qui l’entourent #
| Disposition | Ce qu’elle exige de vous | Ce que nous fournissons |
|---|---|---|
| Art. 28, § 1-2 | Gérer le risque lié aux tiers TIC dans votre propre cadre, proportionnellement au contrat | Le corpus de preuves publié : sécurité , sous-traitants , plan de continuité , registre des risques , registre des incidents , cartographie des contrôles ISO/IEC 27001:2022 annexe A , questionnaire CAIQ |
| Art. 28, § 3 | Tenir un registre d’informations et le communiquer à votre autorité compétente | Les données du prestataire ci-dessus constituent une base ; la qualification, les champs propres à l’entité et la chaîne indirecte validée restent à la charge de l’entité financière |
| Art. 28, § 4 | Diligence raisonnable avant la conclusion du contrat | Le même corpus de preuves, plus une AIPD pré-remplie pour le traitement lui-même |
| Art. 28, § 7 | Droit de résiliation en cas de manquement grave, d’entrave à la supervision ou de faiblesses dans la gestion du risque TIC | Doit figurer dans la commande DORA signée ; la résiliation ordinaire reste régie par les CGU |
| Art. 28, § 8 | Stratégie de sortie documentée et testée — exigée uniquement pour les services TIC soutenant une fonction critique ou importante | Obligation du client ; les exports standard la soutiennent, tandis qu’une période de transition contraignante exige une commande DORA signée |
| Art. 29 | Évaluer le risque de concentration TIC avant de contracter | La concentration se situe au niveau de l’infrastructure : les données de signalement résident chez un unique sous-traitant IaaS, dans une seule région. Nous le disons franchement pour que cela entre dans votre évaluation |
Points ouverts #
Publiés parce qu’une lacune nommée peut être évaluée, tandis qu’une lacune éludée finira par être découverte.
| Point | Pourquoi cela compte | Statut |
|---|---|---|
| Identifiant d’entité juridique (LEI) | Votre registre d’informations privilégie un LEI ou un EUID ; aucun des deux n’existe aujourd’hui pour un entrepreneur individuel polonais, d’où l’usage du NIP comme autre identifiant | En cours d’obtention |
| Test de pénétration indépendant | Demandé dans toute évaluation de prestataire du secteur financier | Aucun enregistré — /trust/ |
| Procédure en cas d’indisponibilité de l’opérateur | Art. 30, § 2, point d) — accès et restitution en cas de cessation d’activité | En cours — plan de continuité §8 , registre des risques R-01 |
| Assurance de responsabilité cyber | Demandée dans toute évaluation de prestataire du secteur financier | À l’étude — /trust/ |
| Commande DORA signée et validation des sous-traitants CIF | L’article 30 exige un dossier contractuel durable complet ; le règlement (UE) 2025/532 exige la chaîne matérielle | Modèle publié ; signature bilatérale et vérification par prestataire requises avant tout engagement CIF |
Pologne : la communication cloud UKNF abrogée #
La communication de l’UKNF du 23 janvier 2020 relative au traitement d’informations par les entités supervisées dans le nuage public ou hybride — le komunikat chmurowy — a été abrogée le 17 janvier 2025, jour de l’entrée en application de DORA. La KNF l’a retirée en même temps que les résolutions sectorielles sur la gestion informatique (résolution 6/2025 abrogeant la 7/2013, qui avait édicté la recommandation D pour les banques ; 7/2025 abrogeant la 615/2016 ; 8/2025 abrogeant les résolutions 409 à 411 et 413/2014), au motif que leur objet recoupe les obligations découlant de DORA et de ses actes d’exécution.
Concrètement : la notification préalable de 14 jours à l’UKNF et le formulaire de l’annexe 1 ne s’appliquent plus. Vos obligations passent désormais par DORA et le registre d’informations.
De nombreuses politiques cloud internes, questionnaires fournisseurs et classements sectoriels reprennent encore la liste de contrôle de cette communication. C’est pour cette raison, et pour cette seule raison, que la correspondance ci-dessous est conservée. Elle décrit un standard qui n’est plus en vigueur.
| Exigence de la communication | Position d’EthicsPortal |
|---|---|
| VII.4.1 a) — partage des responsabilités en matière de sécurité, de continuité, de RTO/RPO, SLA annoncé et méthode de mesure | /sla/ : 99,5 % par mois, RPO 24 h, RTO 4 h, mesure externe. Répartition responsable/sous-traitant au DPA §2 |
| VII.4.1 b) — indication claire des lieux de traitement et de leurs modalités de vérification | Nuremberg, Allemagne — précisé par composant sur Sécurité#Infrastructure et /subprocessors/ |
| VII.4.1 c)-e) — droit applicable et juridiction ; conformité au RGPD ; propriété des informations traitées | Droit polonais, tribunaux de Varsovie (CGU §13 ) ; DPA au titre de l’article 28 du RGPD ; données restituées ou effacées au choix du client (DPA §6.8 ) |
| VII.4.1 f)-g) — garanties, assurances, plafonds de responsabilité | Responsabilité plafonnée à 12 mois de redevances (CGU §11 ) ; aucune police cyber en place — voir points ouverts |
| VII.4.1 h)-i) — sous-traitants nommés avec lieu et périmètre, responsabilité transparente | /subprocessors/ et DPA §8 ; le prestataire répond de ses sous-traitants comme de lui-même (DPA §6.12 ) |
| VII.4.1 m)-n) — droit d’inspection et droit du superviseur d’exercer ses missions de contrôle | Le DPA §6.9 prévoit la coopération d’audit standard du RGPD. Les droits d’autorité propres à DORA exigent une commande signée et la validation des prestataires en aval. Sur pièces et à distance — il n’existe aucun local propre à inspecter |
| VII.4.1 q) — règles et délais de restitution ou d’effacement des informations | DPA §6.8 |
| VII.4.1 s) — échange d’informations sur la sécurité et la gestion des incidents | Notification des violations sans retard injustifié après prise de connaissance (DPA §6.6 ) ; registre des incidents public |
| VII.6.1 — conformité du prestataire aux normes ISO 20000, 27001, 22301, 27017, 27018 | Non certifié. Publié à la place : une cartographie des contrôles ISO/IEC 27001:2022 annexe A couvrant les 93 contrôles, avec statut et preuves. Le sous-traitant d’infrastructure détient une certification ISO 27001 dans son propre périmètre |
| VII.6.2 — centre de données EN 50600 classe 3 ou ANSI/TIA-942 Tier III | Non démontré. La certification ISO/IEC 27001 de Hetzner ne prouve ni EN 50600 classe 3 ni ANSI/TIA-942 Tier III |
| VII.6.3 — centre de données situé dans l’EEE | L’application principale, la base de données et les pièces jointes sont hébergées à Nuremberg, en Allemagne. Cela ne garantit pas une chaîne de messagerie et de télémétrie exclusivement européenne ; voir le DPA |
| VII.6.4 — absence d’accès par défaut, moindre privilège pour les interventions, séparation des locataires, secure-by-default | L’accès privilégié est limité à l’opérateur nommé ; les contrôles peuvent être présentés lors de l’évaluation fournisseur. Les événements définis relatifs aux signalements et aux comptes sont inscrits dans un journal d’audit en ajout seul, mais pas chaque consultation individuelle. Le contenu des signalements, l’identité de l’auteur et les messages sont chiffrés au niveau du champ, de façon non déterministe ; les locataires sont logiquement séparés (Sécurité ) |
| VII.7 — chiffrement « at rest » et « in transit », gestion des clés | Partiel. TLS protège le transport et certains champs des signalements sont chiffrés dans l’application, mais les sauvegardes de base de données et les pièces jointes ne sont pas chiffrées comme objets entiers au repos (Sécurité ). Les clés sont gérées par le sous-traitant ; les clés du client ne sont pas prises en charge (DPA §6.11 ) |
| VII.8 — journalisation, protection des journaux, MFA pour les accès privilégiés | Journal en écriture seule au niveau de la base de données ; authentification à deux facteurs disponible pour les comptes gestionnaires et administrateurs (Sécurité ) |
| IX — notification à l’UKNF avant le début du traitement | Sans objet depuis l’abrogation |
Ce qu’il faut demander ensuite #
Documents communiqués de manière contrôlée plutôt que publiés : DPA signé, extrait d’immatriculation et justificatif fiscal, questionnaire de sécurité complété, synthèse des accès privilégiés en production et réponses écrites sur la continuité d’activité et l’offboarding. Demande à support@ethicsportal.eu .
Pour l’obligation de signalement elle-même plutôt que pour son acquisition, voir services financiers et établissements de monnaie électronique et de paiement .
Dernière mise à jour: