fiskaly.

10 min temps de lecture

Sécurité et RGPD dans la fiscalisation cloud : ce que les entreprises italiennes doivent vérifier

Comment le RGPD et les exigences de sécurité des données de l'AdE s'appliquent à la fiscalisation cloud en Italie, la séparation entre Produttore et Erogatore, et ce qu'il faut vérifier chez un prestataire avant de quitter le matériel RT.

Icône de cadenas superposée à un flux de données, représentant la sécurité et les garanties du RGPD dans la fiscalisation cloud

Sécurité et RGPD dans la fiscalisation cloud : ce que les entreprises italiennes doivent vérifier

Faire passer la fiscalisation d'un Registratore Telematico (RT) installé près de la caisse à une API cloud change l'endroit où les données de transaction sont physiquement traitées, ainsi que la façon dont une entreprise doit évaluer sa relation avec l'opérateur de cette infrastructure. Cela ne change pas en soi les deux obligations de conformité distinctes qui existent en Italie. Les règles italiennes sur les corrispettivi telematici exigent déjà que les données parviennent intactes et non altérées à l'Agenzia delle Entrate (AdE), l'administration fiscale italienne ; le RGPD constitue une couche distincte, applicable à l'échelle de l'UE, qui régit la manière dont les données personnelles contenues dans ces transactions sont stockées, traitées et protégées. Une entreprise qui passe d'un matériel RT à un prestataire de fiscalisation cloud vérifie les deux exigences à la fois, elle n'en remplace pas une par l'autre.

Points clés

  • Les solutions de fiscalisation cloud ont toujours besoin de la certification et de l'homologation de l'AdE pour la fonction fiscale elle-même ; la conformité au RGPD est une exigence distincte et supplémentaire qui s'ajoute, et non un substitut. En août 2026, aucune solution de fiscalisation cloud n'avait encore achevé l'homologation de l'AdE — les premières homologations sont attendues fin 2026 ou début 2027.
  • Les rôles de la fiscalisation italienne sont distincts : le Produttore (producteur) développe le logiciel, et l'Erogatore (fournisseur) l'exploite pour les commerçants. La norme ISO 27001 est exigée pour les deux rôles, mais les obligations du RGPD reposent spécifiquement sur l'Erogatore, l'entité qui traite réellement les données.
  • Les transmissions des corrispettivi telematici sont conçues pour minimiser les données personnelles : le champ de paiement n'enregistre que le mode de paiement et le montant, pas les détails complets de la carte, et le code fiscal d'un client, lorsqu'il est saisi, est haché plutôt que stocké en clair. Les factures et les identifiants de programmes de fidélité ne font pas du tout partie du flux de données de fiscalisation.
  • L'article 33 du RGPD impose de notifier au Garante per la protezione dei dati personali (l'autorité italienne de protection des données) toute violation de données personnelles dans un délai de 72 heures après en avoir eu connaissance — qui porte effectivement ce délai de 72 heures dépend de ce que prévoit le contrat avec le prestataire concernant les délais de notification entre le sous-traitant et le responsable du traitement.
  • Le stockage des données fiscales italiennes hors UE n'est pas seulement un cas de transfert à encadrer par des clauses contractuelles types — il est explicitement et totalement interdit par la spécification technique de l'AdE elle-même.
  • Ce sont les conditions contractuelles d'un prestataire, et non ses arguments marketing, qui déterminent qui est responsable en cas de défaillance de sécurité des données affectant les registres fiscaux d'une entreprise.

Quelles données la fiscalisation cloud traite-t-elle réellement ?

Les systèmes de fiscalisation cloud traitent des données au niveau de la transaction, et une partie de ces données constitue des données personnelles au sens du RGPD, ce qui explique que le RGPD s'applique en parallèle des règles fiscales italiennes plutôt qu'en dehors. Mais le périmètre est plus restreint que ce que suggérerait une comparaison générique avec un « système de caisse », car les corrispettivi telematici sont conçus pour minimiser ce qui est transmis :

  • Les données de paiement sont réduites au type et au montant. La transmission indique qu'une vente a été payée par carte ou en espèces et pour quel montant — pas le numéro de carte ni d'autres identifiants de paiement.
  • Le code fiscal, lorsqu'il est présent, est haché. Lorsque le codice fiscale d'un client est saisi, il est stocké sous forme hachée plutôt qu'en clair.
  • Les factures constituent un type de document distinct. Une facture ne fait pas partie de la transmission des corrispettivi telematici elle-même, elle n'a donc pas sa place dans une liste de ce que contient le flux de données de fiscalisation.
  • Les identifiants de programmes de fidélité n'ont aucun statut officiel dans le dispositif. Ce n'est pas un champ reconnu dans le modèle de données des corrispettivi telematici.

Rien de tout cela ne fait sortir le système du champ d'application du RGPD. Un type de paiement associé à un montant, ou un code fiscal haché, peuvent rester des données personnelles s'ils peuvent être rattachés à une personne — le hachage réduit ce qui est exposé, il ne rend pas automatiquement le champ anonyme au sens des définitions du RGPD lui-même. Pour une entreprise qui évalue un prestataire, la question pratique est plus précise que « le RGPD s'applique-t-il de manière générale aux données de caisse » : il s'agit de savoir quels champs précis la transmission contient réellement, et si les affirmations du prestataire sur la minimisation des données correspondent à ce que définit la spécification de l'AdE elle-même.

Les rôles dans le droit italien de la fiscalisation : Produttore, Erogatore et le champ d'application du RGPD

Le droit italien de la fiscalisation distingue l'entité qui développe une solution de celle qui l'exploite pour les commerçants, et cette distinction compte à la fois pour la certification et pour le RGPD :

  • Le Produttore (producteur) développe le logiciel — les modules PEM et PEL — conformément à la spécification technique de l'AdE.
  • L'Erogatore (fournisseur) distribue la solution et la maintient en fonctionnement pour les commerçants ; c'est l'entité juridiquement et opérationnellement responsable envers l'AdE et le commerçant en cas de problème.

La norme ISO 27001 est exigée pour les deux rôles. Le RGPD, en revanche, ne l'est pas : les obligations du RGPD reposent sur l'Erogatore, car c'est la partie qui exploite réellement le système et traite les données qui y circulent. Le rôle de Produttore, à lui seul, n'est pas concerné par le RGPD.

fiskaly cumule les deux rôles pour sa propre solution de fiscalisation cloud. Lorsque fiskaly fournit plutôt le logiciel sous-jacent à un tiers agissant en tant qu'Erogatore, ce tiers a besoin à la fois d'une solution certifiée et homologuée et de sa propre accréditation en tant que prestataire auprès de l'AdE — la certification du logiciel lui-même ne remplace pas l'accréditation propre de l'Erogatore.

Que confirme la norme ISO 27001, et qu'exclut-elle ?

La norme ISO 27001 certifie qu'une organisation exploite un système de management de la sécurité de l'information (SMSI) documenté, couvrant l'évaluation des risques, les contrôles d'accès et la réponse aux incidents. Elle ne confirme ni la conformité au RGPD, ni la certification fiscale de l'AdE — c'est une déclaration sur la manière dont une entreprise gère la sécurité de l'information, pas sur ce qu'une solution certifiée donnée doit accomplir.

fiskaly détient la certification ISO 27001 à l'échelle de son groupe d'entreprises, y compris fiskaly Italie — le Trust Center de fiskaly documente directement ce périmètre. C'est un signal utile pour une entreprise qui évalue un prestataire, mais cela répond à une question différente de celle de savoir si une solution de fiscalisation est certifiée pour répondre à une obligation liée aux corrispettivi telematici.

La certification et l'homologation de la fonction fiscale forment un processus en deux étapes, et l'AdE elle-même ne « certifie » pas une solution. D'abord, un organisme autorisé — le CNR di Pisa et le Politecnico di Milano sont les deux organismes actuellement actifs — certifie que la solution respecte la spécification technique. Ensuite, la Commissione Misuratori Fiscali statue sur l'homologation. Les deux étapes sont nécessaires avant qu'une solution puisse être commercialisée. En août 2026, aucune solution de fiscalisation logicielle n'avait achevé l'homologation ; fiskaly participe à la phase pilote de l'AdE et de SOGEI pour la transmission par API, avec le soutien du CNR di Pisa sur le volet certification. Il ne faut pas considérer qu'un dispositif de fiscalisation cloud est déjà pleinement certifié en Italie — il convient de vérifier où en est réellement un prestataire donné dans ce processus.

Quels contrôles de sécurité la spécification de l'AdE impose-t-elle ?

La norme ISO 27001 décrit la manière dont un prestataire gère la sécurité de façon générale ; la spécification de l'AdE décrit ce que la solution certifiée elle-même doit faire, indépendamment de la posture de sécurité générale du prestataire. Voici quelques-uns des contrôles prescrits par la spécification :

  • Le PEL communique avec le système de l'AdE via TLS 1.2 avec authentification mutuelle X.509, à l'aide d'un certificat délivré lors de l'accréditation — la même exigence s'applique au logiciel externe qui appelle les API de la solution (§9.3 de la spécification technique).
  • Les clés privées de signature doivent se trouver dans une zone sécurisée empêchant leur extraction et leur duplication (§9.2).
  • Chaque document commercial et chaque fichier de journal est signé avec un certificat propre à l'appareil, et les journaux comportent une chaîne de hachage qui permet de détecter les séquences altérées.
  • L'Erogatore doit journaliser tous les accès aux données stockées (§9.7).

Ce sont des exigences techniques fixes qu'une solution certifiée doit mettre en œuvre, et non de simples « bonnes pratiques de sécurité » optionnelles qu'un prestataire pourrait choisir d'ignorer — c'est pourquoi elles constituent une question distincte de la posture ISO 27001 générale d'un prestataire.

Que se passe-t-il en cas de violation de données chez un prestataire de fiscalisation cloud ?

L'article 33 du RGPD impose à un responsable du traitement de notifier au Garante per la protezione dei dati personali toute violation de données personnelles dans un délai de 72 heures après en avoir eu connaissance, et l'article 34 impose de notifier directement les personnes concernées lorsque la violation présente un risque élevé pour leurs droits.

Pour une entreprise qui utilise un prestataire de fiscalisation cloud, la question pratique est de savoir qui porte ce délai de 72 heures. Si le prestataire agit en tant que sous-traitant dans le cadre d'un accord conforme à l'article 28 du RGPD, le sous-traitant doit notifier le responsable du traitement — l'entreprise elle-même — sans délai indu, afin que l'entreprise puisse ensuite respecter sa propre obligation de 72 heures envers le Garante. Un contrat qui ne dit rien sur les délais de notification des violations expose l'entreprise au risque de manquer ce délai sans faute directe de sa part.

Où sont stockées les données de transaction, et pourquoi cela compte-t-il ?

La spécification technique de l'AdE exige que l'infrastructure de fiscalisation cloud se trouve au sein de l'UE (§11.6). Ce n'est pas présenté comme un choix disposant d'une alternative conforme au RGPD : le stockage des données fiscales italiennes hors UE est explicitement interdit par la spécification elle-même, quelle que soit la garantie de transfert qu'un prestataire pourrait par ailleurs mettre en place.

Comme les enregistrements de transaction traités à des fins fiscales incluent souvent des données personnelles en plus des données fiscales, le stockage au sein de l'UE permet aussi à une entreprise d'échapper aux règles distinctes du RGPD sur les transferts internationaux de données, qui exigeraient sinon des mécanismes tels que les clauses contractuelles types pour toute donnée personnelle déplacée hors de l'UE. fiskaly stocke les données fiscales sur une infrastructure basée dans l'UE couverte par sa certification ISO 27001, ce qui règle par défaut à la fois l'exigence de résidence de l'AdE et la question de transfert du RGPD, sans nécessiter de justification distincte pour chaque client.

Quelles clauses contractuelles importent lors de l'évaluation d'un prestataire de fiscalisation cloud ?

C'est la spécification de l'AdE, et non le contrat, qui décide de ce qu'il advient des données fiscales d'un commerçant en cas de sortie. L'Erogatore doit donner un accès complet à toutes les données stockées et les exporter dans un format standard « quelle que soit la forme contractuelle régissant l'utilisation de la solution » (§9.7), les archiver conformément au décret ministériel du 17 juin 2014 (§9.8), et remettre, à la fin de la relation, un File Archivio comprenant les journaux, les documents commerciaux et un index metadati.xml (§10.1–10.3). Rien de tout cela n'est négociable dans un contrat, car il s'agit d'une obligation réglementaire de l'Erogatore.

Ce que le contrat couvre réellement, c'est ce que la spécification laisse ouvert : la vitesse et le coût de l'export, et qui gère la migration ; un accord de traitement de données conforme à l'article 28 du RGPD précisant les activités de traitement, les durées de conservation et les sous-traitants ; et un délai de notification des violations exprimé en heures, plutôt que laissé à « sans délai indu ».

Prochaines étapes

Passer d'un matériel RT à un prestataire de fiscalisation cloud implique d'évaluer une relation de traitement de données selon ses propres termes, en plus d'un parcours de certification et d'homologation fiscale que la plupart des solutions du marché italien n'ont pas encore achevé. fiskaly SIGN IT fonctionne sur une infrastructure certifiée ISO 27001, avec des données fiscales stockées sur une infrastructure basée dans l'UE, et le Trust Center de fiskaly documente les contrôles de sécurité précis derrière cette certification. Pour le processus de certification et d'homologation lui-même, le guide de fiskaly sur les exigences de certification de la fiscalisation cloud en Italie détaille la séparation entre Produttore et Erogatore ainsi que les étapes de certification, et le paysage fiscal en Italie en 2026 fait le point sur l'état actuel de la transition plus large du matériel vers le cloud. Une fois les données fiscales collectées, fiskaly SAFE prend en charge l'archivage de ces mêmes données, prêt pour un audit.

Dernière mise à jour : septembre 2026. Cet article constitue une information générale et ne saurait être considéré comme un conseil juridique. Vérifiez les exigences en vigueur auprès de l'Agenzia delle Entrate, du Garante per la protezione dei dati personali et du RGPD lui-même avant de choisir un prestataire de fiscalisation cloud.

Ce que couvrent respectivement l'ISO 27001, le RGPD et la certification de l'AdE

ISO 27001RGPDCertification AdE
CouvreSystème de management de la sécurité de l'informationTraitement licite des données personnellesExactitude fiscale et inviolabilité des données de transaction
Organisme certificateurOrganismes de certification ISO accréditésAuto-évaluation, contrôlée par le GaranteUn organisme autorisé (par ex. CNR di Pisa, Politecnico di Milano) certifie d'abord la solution ; la Commissione Misuratori Fiscali l'homologue ensuite
Confirme la conformité fiscale ?NonNonOui, une fois l'homologation de l'AdE obtenue
Confirme la conformité en matière de données personnelles ?Indirectement (contrôles de sécurité)OuiNon
Obligation de notification des violationsInterne au SMSI72 heures auprès du Garante (art. 33)Signalement obligatoire des anomalies du PEL, distinct du RGPD

Questions fréquentes sur la sécurité et le RGPD dans la fiscalisation cloud en Italie

Moins que ce que suggérerait une comparaison générique avec un système de caisse. Les transmissions des corrispettivi telematici enregistrent le type et le montant du paiement, pas les détails complets de la carte, et hachent le code fiscal d'un client lorsqu'il est saisi. Les factures et les identifiants de programmes de fidélité ne font pas du tout partie du flux de données de fiscalisation — il s'agit de types de documents distincts, ou ils n'ont simplement pas de place officielle dans le dispositif.

Non. L'ISO 27001 certifie qu'un système de management de la sécurité de l'information est en place ; la conformité au RGPD est une exigence légale distincte portant sur le traitement licite des données personnelles, que l'ISO 27001 soutient sans la certifier elle-même.

Dans le cadre d'un accord de traitement des données conforme à l'article 28 du RGPD, le sous-traitant notifie généralement le responsable du traitement (l'entreprise) sans délai indu après avoir eu connaissance d'une violation, afin que l'entreprise puisse respecter sa propre obligation de notification de 72 heures auprès du Garante per la protezione dei dati personali en vertu de l'article 33.

Non, et le processus comporte deux étapes. Un organisme autorisé, tel que le CNR di Pisa ou le Politecnico di Milano, certifie d'abord la solution, et la Commissione Misuratori Fiscali décide ensuite de l'homologation — l'AdE elle-même ne « certifie » pas une solution. Si l'Erogatore qui exploite la solution est une entreprise différente du Produttore qui l'a développée, cet Erogatore a également besoin de sa propre accréditation auprès de l'AdE, en plus de toute certification déjà obtenue par le logiciel sous-jacent.

La spécification technique de l'AdE (§11.6) exige que l'infrastructure de fiscalisation cloud soit située au sein de l'UE — le stockage des données fiscales italiennes hors UE n'est pas autorisé du tout, indépendamment de toute garantie prévue par le RGPD. Comme les enregistrements de transaction incluent souvent des données personnelles en plus des données fiscales, le stockage dans l'UE permet aussi à l'entreprise d'échapper aux règles distinctes du RGPD sur les transferts internationaux de données, qui exigeraient sinon des mécanismes tels que les clauses contractuelles types.

Un accord de traitement des données conforme à l'article 28 du RGPD précisant les activités de traitement concrètes et les sous-traitants, ainsi qu'un délai de notification des violations exprimé en heures. Ce qui n'a pas sa place dans le contrat, car il s'agit d'une obligation réglementaire et non d'une clause négociable, c'est l'obligation de l'Erogatore de donner un accès complet aux données stockées et de les exporter sur demande, de les archiver conformément au décret ministériel du 17 juin 2014, et de remettre un File Archivio complet en cas de fin de la relation.

Intéressé ? Demandez un premier rendez-vous

  • Nous sommes là pour répondre à toutes vos questions et trouver la solution idéale.
  • Plus de 2 000 clients font confiance à nos solutions de fiscalisation. Nous sommes à vos côtés !

Optionnel

Optionnel

En savoir plus sur la fiscalisation cloud en Italie

Jeune femme payant à la caisse dans un magasin de vêtements.

4 min temps de lecture

Le paysage fiscal en Italie en 2026: la fiscalisation cloud est le présent

En dépassant les limites des dispositifs physiques, cette technologie basée sur les API permet aux éditeurs de logiciels d'intégrer la conformité fiscale directement dans leur code. Face aux échéances de 2026 pour la connexion POS-RT et la transmission des données de vente via logiciel, passer au cloud signifie choisir la scalabilité, la sécurité et des mises à jour réglementaires automatiques.

Lire l'article

4 min temps de lecture

Fiscalisation cloud en Italie 2026 : exigences de certification et guide complet

À partir de 2026, la transmission des données de vente à l’Agence fiscale italienne pourra également s’effectuer via des solutions cloud. Mais comment obtenir la certification requise ? Découvrez dans notre guide les étapes clés pour les éditeurs de logiciels et fabricants de POS.

Lire l'article
Une cliente payant à la caisse en Italie

4 min temps de lecture

fiskaly accède à la plateforme de test avec sa solution cloud

Grâce à notre collaboration avec l'Agence Italienne des Revenus (Agenzia delle Entrate), AssoSoftware et le CNR de Pise, nous avons officiellement obtenu l'accès à la plateforme de test SOGEI pour fiskaly SIGN IT. Notre solution permet aux fournisseurs de points de vente (POS) de transmettre les données fiscales via des API, éliminant les contraintes matérielles tout en garantissant une conformité continue, sécurisée et évolutive.

Lire l'article