Sicherheit und DSGVO bei der Cloud-Fiskalisierung: Was italienische Unternehmen prüfen sollten

Der Wechsel der Fiskalisierung von einem Registratore Telematico (RT), der direkt an der Kasse steht, zu einer Cloud-API verändert, wo die Transaktionsdaten physisch verarbeitet werden, und wie ein Unternehmen seine Beziehung zu demjenigen bewerten muss, der diese Infrastruktur betreibt. Für sich genommen ändert das nichts an Italiens zwei getrennten Compliance-Pflichten. Italiens Vorschriften zu den corrispettivi telematici verlangen bereits, dass die Daten vollständig und unverändert bei der Agenzia delle Entrate (AdE), der italienischen Steuerbehörde, ankommen; die DSGVO ist eine separate, EU-weite Ebene, die regelt, wie personenbezogene Daten innerhalb dieser Transaktionen gespeichert, verarbeitet und geschützt werden. Ein Unternehmen, das von RT-Hardware zu einem Cloud-Fiskalisierungsanbieter wechselt, prüft beide Anforderungen gleichzeitig – es tauscht nicht die eine gegen die andere aus.

Das Wichtigste in Kürze

• Cloud-Fiskallösungen benötigen weiterhin die AdE-Zertifizierung und -Homologation für die fiskalische Funktion selbst; die DSGVO-Konformität ist eine separate, zusätzliche Anforderung, die darauf aufbaut, kein Ersatz dafür. Stand August 2026 hat noch keine Cloud-Fiskallösung die AdE-Homologation abgeschlossen – die ersten Homologationen werden Ende 2026 oder Anfang 2027 erwartet.
• Italiens Fiskalisierungsrollen sind klar getrennt: Der Produttore (Hersteller) entwickelt die Software, und der Erogatore (Anbieter) betreibt sie für die Händler. ISO 27001 ist für beide Rollen erforderlich, aber die DSGVO-Pflichten liegen speziell beim Erogatore, der Stelle, die die Daten tatsächlich verarbeitet.
• Die Übermittlungen der corrispettivi telematici sind darauf ausgelegt, personenbezogene Daten zu minimieren: Das Zahlungsfeld erfasst nur Zahlungsart und Betrag, nicht die vollständigen Kartendaten, und der Steuercode eines Kunden wird, sofern erfasst, gehasht statt im Klartext gespeichert. Rechnungen und Kundenkarten-Kennungen sind überhaupt nicht Teil des Fiskalisierungsdatenstroms.
• Artikel 33 der DSGVO verlangt, dass eine Verletzung des Schutzes personenbezogener Daten innerhalb von 72 Stunden nach Kenntnisnahme dem Garante per la protezione dei dati personali (der italienischen Datenschutzbehörde) gemeldet wird – wer diese 72-Stunden-Uhr tatsächlich trägt, hängt davon ab, was der Vertrag mit dem Anbieter zur Meldefrist zwischen Verarbeiter und Verantwortlichem festlegt.
• Die Speicherung italienischer Fiskaldaten außerhalb der EU ist nicht nur ein Übermittlungsszenario, das mit Standardvertragsklauseln zu regeln ist – sie ist durch die technische Spezifikation der AdE selbst ausdrücklich und vollständig untersagt.
• Die Vertragsbedingungen eines Anbieters, nicht seine Marketingaussagen, entscheiden darüber, wer haftet, wenn ein Sicherheitsvorfall die Fiskaldaten eines Unternehmens betrifft.

Welche Daten verarbeitet die Cloud-Fiskalisierung tatsächlich?

Cloud-Fiskalisierungssysteme verarbeiten Daten auf Transaktionsebene, und ein Teil dieser Daten gilt nach der DSGVO als personenbezogene Daten – deshalb steht die DSGVO neben Italiens Fiskalvorschriften und nicht außerhalb davon. Der Umfang ist jedoch enger, als ein allgemeiner Vergleich mit einem "POS-System" vermuten lässt, denn die corrispettivi telematici sind darauf ausgelegt, das Übermittelte zu minimieren:

• Zahlungsdaten werden auf Art und Betrag reduziert. Die Übermittlung erfasst, dass ein Verkauf per Karte oder bar bezahlt wurde und in welcher Höhe – nicht die Kartennummer oder andere Zahlungsdaten.
• Der Steuercode wird, sofern vorhanden, gehasht. Wird der codice fiscale eines Kunden erfasst, wird er in gehashter Form gespeichert, nicht im Klartext.
• Rechnungen sind ein eigener Dokumententyp. Eine Rechnung ist nicht Teil der Übermittlung der corrispettivi telematici selbst und gehört daher nicht in eine Liste dessen, was der Fiskalisierungsdatenstrom enthält.
• Kundenkarten-Kennungen haben in dem Schema keinen offiziellen Status. Sie sind kein anerkanntes Feld im Datenmodell der corrispettivi telematici.

Das nimmt das System nicht aus dem Anwendungsbereich der DSGVO heraus. Eine Zahlungsart mit Betrag oder ein gehashter Steuercode können weiterhin personenbezogene Daten sein, wenn sie sich einer Person zuordnen lassen – Hashing verringert, was offengelegt wird, macht das Feld aber nicht automatisch anonym im Sinne der DSGVO. Für ein Unternehmen, das einen Anbieter bewertet, ist die praktische Frage enger gefasst als "gilt die DSGVO generell für POS-Daten": Es geht darum, welche konkreten Felder die Übermittlung tatsächlich enthält, und ob die Aussagen des Anbieters zur Datenminimierung mit dem übereinstimmen, was die AdE-Spezifikation selbst festlegt.

Rollen im italienischen Fiskalisierungsrecht: Produttore, Erogatore und wo die DSGVO greift

Das italienische Fiskalisierungsrecht trennt die Stelle, die eine Lösung entwickelt, von der Stelle, die sie für die Händler betreibt – und dieser Unterschied ist sowohl für die Zertifizierung als auch für die DSGVO relevant:

• Der Produttore (Hersteller) entwickelt die Software – die Module PEM und PEL – nach der technischen Spezifikation der AdE.
• Der Erogatore (Anbieter) vertreibt die Lösung und hält sie für die Händler am Laufen; er ist die Stelle, die gegenüber der AdE und dem Händler rechtlich und operativ verantwortlich ist, wenn etwas schiefgeht.

ISO 27001 ist für beide Rollen vorgeschrieben. Die DSGVO hingegen nicht: Die DSGVO-Pflichten liegen beim Erogatore, weil er die Partei ist, die das System tatsächlich betreibt und die durchlaufenden Daten verarbeitet. Die Rolle des Produttore ist für sich genommen nicht DSGVO-relevant.

fiskaly nimmt für seine eigene Cloud-Fiskalisierungslösung beide Rollen wahr. Liefert fiskaly stattdessen die zugrunde liegende Software an einen Dritten, der als Erogatore auftritt, braucht dieser Dritte sowohl eine zertifizierte und homologierte Lösung als auch seine eigene AdE-Akkreditierung als Anbieter – die Zertifizierung der Software allein ersetzt nicht die eigene Akkreditierung des Erogatore.

Was bestätigt ISO 27001 – und was lässt die Norm offen?

ISO 27001 zertifiziert, dass eine Organisation ein dokumentiertes Informationssicherheits-Managementsystem (ISMS) betreibt, das Risikobewertung, Zugriffskontrollen und Vorfallreaktion umfasst. Die Norm bestätigt weder die DSGVO-Konformität noch die fiskalische AdE-Zertifizierung – sie ist eine Aussage darüber, wie ein Unternehmen die Informationssicherheit steuert, nicht darüber, was eine konkrete zertifizierte Lösung leisten muss.

fiskaly ist konzernweit nach ISO 27001 zertifiziert, einschließlich fiskaly Italien – das Trust Center von fiskaly dokumentiert den Umfang direkt. Das ist ein aussagekräftiges Signal für ein Unternehmen, das einen Anbieter bewertet, beantwortet aber eine andere Frage als die, ob eine Fiskalisierungslösung zertifiziert ist, um eine Pflicht der corrispettivi telematici zu erfüllen.

Zertifizierung und Homologation für die fiskalische Funktion sind ein zweistufiger Prozess, und die AdE selbst "zertifiziert" keine Lösung. Zunächst bestätigt eine autorisierte Stelle – derzeit sind das CNR di Pisa und das Politecnico di Milano – dass die Lösung die technische Spezifikation erfüllt. Anschließend entscheidet die Commissione Misuratori Fiscali über die Homologation. Beide Schritte sind erforderlich, bevor eine Lösung auf den Markt kommen kann. Stand August 2026 hat noch keine softwarebasierte Fiskalisierungslösung die Homologation abgeschlossen; fiskaly nimmt an der Pilotphase von AdE und SOGEI für die API-basierte Übermittlung teil, unterstützt durch CNR di Pisa auf der Zertifizierungsseite. Man sollte einen Cloud-Fiskalisierungsweg in Italien nicht als bereits vollständig zertifiziert behandeln – prüfen Sie, wo ein konkreter Anbieter in diesem Prozess tatsächlich steht.

Welche Sicherheitskontrollen schreibt die AdE-Spezifikation vor?

ISO 27001 beschreibt, wie ein Anbieter Sicherheit allgemein steuert; die AdE-Spezifikation beschreibt, was die zertifizierte Lösung selbst leisten muss – unabhängig von der allgemeinen Sicherheitslage des Anbieters. Einige der von der Spezifikation vorgeschriebenen Kontrollen:

• Der PEL kommuniziert mit dem System der AdE über TLS 1.2 mit gegenseitiger X.509-Authentifizierung, mit einem bei der Akkreditierung ausgestellten Zertifikat – dieselbe Anforderung gilt für externe Software, die die APIs der Lösung aufruft (§9.3 der technischen Spezifikation).
• Private Signaturschlüssel müssen sich in einem gesicherten Bereich befinden, der Extraktion und Duplizierung verhindert (§9.2).
• Jedes Handelsdokument und jede Journaldatei wird mit einem gerätebezogenen Zertifikat signiert, und die Journale tragen eine Hash-Kette, die veränderte Abfolgen erkennbar macht.
• Der Erogatore muss jeden Zugriff auf gespeicherte Daten protokollieren (§9.7).

Das sind feste technische Anforderungen, die eine zertifizierte Lösung umsetzen muss, keine optionalen "Best Practices", die ein Anbieter auslassen könnte – deshalb sind sie eine eigene Frage, getrennt von der allgemeinen ISO-27001-Haltung eines Anbieters.

Was passiert, wenn ein Cloud-Fiskalisierungsanbieter von einer Datenschutzverletzung betroffen ist?

Artikel 33 der DSGVO verlangt, dass ein Verantwortlicher eine Verletzung des Schutzes personenbezogener Daten innerhalb von 72 Stunden nach Kenntnisnahme dem Garante per la protezione dei dati personali meldet, und Artikel 34 verlangt, betroffene Personen direkt zu benachrichtigen, wenn die Verletzung ein hohes Risiko für ihre Rechte darstellt.

Für ein Unternehmen, das einen Cloud-Fiskalisierungsanbieter nutzt, ist die praktische Frage, wer diese 72-Stunden-Uhr trägt. Handelt der Anbieter als Auftragsverarbeiter im Rahmen einer Vereinbarung nach Artikel 28 DSGVO, muss der Verarbeiter den Verantwortlichen – das Unternehmen selbst – unverzüglich benachrichtigen, damit das Unternehmen seine eigene 72-Stunden-Pflicht gegenüber dem Garante erfüllen kann. Ein Vertrag, der zur Meldefrist bei Datenschutzverletzungen keine Angaben macht, setzt das Unternehmen dem Risiko aus, dieses Zeitfenster ohne eigenes direktes Verschulden zu verpassen.

Wo werden die Transaktionsdaten gespeichert, und warum spielt das eine Rolle?

Die technische Spezifikation der AdE verlangt, dass die Infrastruktur der Cloud-Fiskalisierung innerhalb der EU liegt (§11.6). Das ist nicht als Wahlmöglichkeit mit einer DSGVO-konformen Alternative gefasst: Die Speicherung italienischer Fiskaldaten außerhalb der EU ist durch die Spezifikation selbst ausdrücklich untersagt, unabhängig von jeder Übermittlungssicherung, die ein Anbieter ansonsten einrichten könnte.

Da Transaktionsdatensätze, die für fiskalische Zwecke verarbeitet werden, häufig zusammen mit den Fiskaldaten auch personenbezogene Daten enthalten, hält die Speicherung in der EU ein Unternehmen zudem aus den separaten DSGVO-Regeln zu internationalen Datenübermittlungen heraus, die andernfalls Mechanismen wie Standardvertragsklauseln für jede aus der EU verlagerte personenbezogene Angabe erfordern würden. fiskaly speichert Fiskaldaten auf EU-basierter Infrastruktur, die von der ISO-27001-Zertifizierung abgedeckt ist – damit sind sowohl die AdE-Residenzpflicht als auch die DSGVO-Übermittlungsfrage standardmäßig geklärt, ohne dass für jeden Kunden eine gesonderte Begründung nötig wäre.

Welche Vertragsbedingungen zählen bei der Bewertung eines Cloud-Fiskalisierungsanbieters?

Nicht der Vertrag, sondern die AdE-Spezifikation entscheidet, was beim Austritt mit den Fiskaldaten eines Händlers geschieht. Der Erogatore muss vollständigen Zugriff auf alle gespeicherten Daten gewähren und sie in einem Standardformat exportieren – "unabhängig von der vertraglichen Form, die die Nutzung der Lösung regelt" (§9.7) –, sie gemäß dem Ministerialdekret vom 17. Juni 2014 archivieren (§9.8) und bei Beendigung ein File Archivio mit den Journalen, den Handelsdokumenten und einem metadati.xml-Index übergeben (§10.1–10.3). Nichts davon ist vertraglich verhandelbar, weil es sich um eine regulatorische Pflicht des Erogatore handelt.

Was der Vertrag tatsächlich abdeckt, ist das, was die Spezifikation offenlässt: Exportgeschwindigkeit, Kosten und wer die Migration übernimmt; eine Vereinbarung zur Auftragsverarbeitung nach Artikel 28 DSGVO, die die konkreten Verarbeitungstätigkeiten, Aufbewahrungsfristen und Unterauftragsverarbeiter benennt; und ein in Stunden festgelegtes Meldefenster bei Datenschutzverletzungen, statt es bei "unverzüglich" zu belassen.

Nächste Schritte

Der Wechsel von RT-Hardware zu einem Cloud-Fiskalisierungsanbieter bedeutet, eine Datenverarbeitungsbeziehung nach eigenen Maßstäben zu bewerten – zusätzlich zu einem fiskalischen Zertifizierungs- und Homologationsweg, den die meisten Lösungen auf dem italienischen Markt noch nicht abgeschlossen haben. fiskaly SIGN IT läuft auf ISO-27001-zertifizierter Infrastruktur mit Fiskaldaten auf EU-basierter Infrastruktur, und das Trust Center von fiskaly dokumentiert die konkreten Sicherheitskontrollen hinter dieser Zertifizierung. Für den Zertifizierungs- und Homologationsprozess selbst behandelt fiskalys Leitfaden zu den Zertifizierungsanforderungen für die Cloud-Fiskalisierung in Italien die Trennung von Produttore und Erogatore sowie die Zertifizierungsschritte ausführlicher, und die Fiskallandschaft in Italien 2026 zeigt, wo der breitere Wandel von Hardware zur Cloud derzeit steht. Sobald die Fiskaldaten erfasst sind, übernimmt fiskaly SAFE die revisionssichere Archivierung derselben Daten.

Letzte Aktualisierung: September 2026. Dieser Artikel dient der allgemeinen Orientierung und ist keine Rechtsberatung. Prüfen Sie aktuelle Anforderungen vor der Wahl eines Cloud-Fiskalisierungsanbieters bei der Agenzia delle Entrate, dem Garante per la protezione dei dati personali und der DSGVO selbst.