Sicurezza e GDPR nella fiscalizzazione cloud: cosa devono verificare le aziende italiane

Il passaggio della fiscalizzazione da un Registratore Telematico (RT) collocato accanto alla cassa a un'API cloud cambia dove vengono effettivamente elaborati i dati delle transazioni e come un'azienda deve valutare il rapporto con chi gestisce quell'infrastruttura. Di per sé, questo non modifica i due obblighi di conformità distinti previsti in Italia. Le norme italiane sui corrispettivi telematici richiedono già che i dati arrivino integri e inalterati all'Agenzia delle Entrate (AdE); il GDPR è un livello separato, a livello europeo, che disciplina come i dati personali contenuti in quelle transazioni vengono archiviati, trattati e protetti. Un'azienda che passa da hardware RT a un fornitore di fiscalizzazione cloud sta verificando entrambe le cose contemporaneamente, non sostituendo l'una con l'altra.

Punti chiave

• Le soluzioni di fiscalizzazione cloud continuano a richiedere la certificazione e l'omologazione dell'AdE per la funzione fiscale in sé; la conformità al GDPR è un requisito distinto e aggiuntivo che si affianca, non un suo sostituto. Ad agosto 2026 nessuna soluzione di fiscalizzazione cloud aveva completato l'omologazione dell'AdE: le prime omologazioni sono previste per la fine del 2026 o l'inizio del 2027.
• I ruoli della fiscalizzazione italiana sono distinti: il Produttore sviluppa il software, e l'Erogatore lo gestisce per i commercianti. La ISO 27001 è richiesta per entrambi i ruoli, ma gli obblighi del GDPR ricadono specificamente sull'Erogatore, il soggetto che effettivamente tratta i dati.
• Le trasmissioni dei corrispettivi telematici sono progettate per minimizzare i dati personali: il campo relativo al pagamento registra solo il metodo di pagamento e l'importo, non i dati completi della carta, e il codice fiscale di un cliente, quando viene rilevato, è sottoposto a hashing invece di essere memorizzato in chiaro. Le fatture e gli identificativi dei programmi fedeltà non fanno affatto parte del flusso di dati della fiscalizzazione.
• L'articolo 33 del GDPR richiede di notificare al Garante per la protezione dei dati personali una violazione di dati personali entro 72 ore dal momento in cui se ne ha conoscenza: chi effettivamente porta questo termine di 72 ore dipende da cosa stabilisce il contratto con il fornitore riguardo ai tempi di notifica tra responsabile e titolare del trattamento.
• La conservazione dei dati fiscali italiani fuori dall'UE non è solo uno scenario di trasferimento da gestire con clausole contrattuali standard: è espressamente e integralmente vietata dalla stessa specifica tecnica dell'AdE.
• Sono le condizioni contrattuali di un fornitore, non le sue affermazioni di marketing, a determinare chi è responsabile se un problema di sicurezza dei dati compromette i registri fiscali di un'azienda.

Quali dati elabora davvero la fiscalizzazione cloud?

I sistemi di fiscalizzazione cloud elaborano dati a livello di transazione, e parte di questi dati costituisce dati personali secondo il GDPR: è per questo che il GDPR si affianca alle regole fiscali italiane, e non ne resta fuori. Ma l'ambito è più ristretto di quanto suggerirebbe un confronto generico con un "sistema POS", perché i corrispettivi telematici sono progettati per minimizzare ciò che viene trasmesso:

• I dati di pagamento sono ridotti a tipo e importo. La trasmissione registra che una vendita è stata pagata con carta o in contanti e per quale importo, non il numero di carta o altri dati di pagamento.
• Il codice fiscale, quando presente, viene sottoposto a hashing. Quando viene rilevato il codice fiscale di un cliente, viene memorizzato in forma sottoposta a hashing invece che in chiaro.
• Le fatture sono un tipo di documento separato. Una fattura non fa parte della trasmissione dei corrispettivi telematici in sé, quindi non dovrebbe rientrare in un elenco di ciò che contiene il flusso di dati della fiscalizzazione.
• Gli identificativi dei programmi fedeltà non hanno alcuno status ufficiale nello schema. Non sono un campo riconosciuto nel modello di dati dei corrispettivi telematici.

Nulla di tutto questo esclude il sistema dall'ambito di applicazione del GDPR. Un tipo di pagamento con importo, o un codice fiscale sottoposto a hashing, possono comunque costituire dati personali se possono essere ricondotti a una persona: il hashing riduce ciò che viene esposto, ma non rende automaticamente il campo anonimo secondo le definizioni stesse del GDPR. Per un'azienda che valuta un fornitore, la domanda pratica è più circoscritta di "il GDPR si applica in generale ai dati POS": si tratta di capire quali campi specifici la trasmissione contiene realmente, e se le affermazioni del fornitore sulla minimizzazione dei dati corrispondono a ciò che la specifica dell'AdE stessa definisce.

Ruoli nella normativa italiana sulla fiscalizzazione: Produttore, Erogatore e dove si applica il GDPR

La normativa italiana sulla fiscalizzazione separa il soggetto che sviluppa una soluzione da quello che la gestisce per i commercianti, e questa distinzione conta sia per la certificazione che per il GDPR:

• Il Produttore sviluppa il software — i moduli PEM e PEL — in base alla specifica tecnica dell'AdE.
• L'Erogatore distribuisce la soluzione e la mantiene operativa per i commercianti, ed è il soggetto legalmente e operativamente responsabile verso l'AdE e verso il commerciante in caso di problemi.

La ISO 27001 è un requisito per entrambi i ruoli. Il GDPR, invece, no: gli obblighi del GDPR ricadono sull'Erogatore, perché è la parte che effettivamente gestisce il sistema e tratta i dati che vi transitano. Il ruolo di Produttore, da solo, non è rilevante ai fini del GDPR.

fiskaly riveste entrambi i ruoli per la propria soluzione di fiscalizzazione cloud. Quando fiskaly fornisce invece il software sottostante a una terza parte che agisce come Erogatore, quella terza parte ha bisogno sia di una soluzione certificata e omologata, sia di un proprio accreditamento come fornitore presso l'AdE: la certificazione del software da sola non sostituisce l'accreditamento proprio dell'Erogatore.

Cosa conferma la ISO 27001, e cosa lascia fuori?

La ISO 27001 certifica che un'organizzazione gestisce un sistema di gestione della sicurezza delle informazioni (ISMS) documentato, che copre la valutazione del rischio, i controlli di accesso e la risposta agli incidenti. Non conferma di per sé la conformità al GDPR, né la certificazione fiscale dell'AdE: è una dichiarazione su come un'azienda gestisce la sicurezza delle informazioni, non su ciò che una specifica soluzione certificata deve fare.

fiskaly è certificata ISO 27001 a livello di gruppo, incluso fiskaly Italia — il Trust Center di fiskaly ne documenta direttamente l'ambito. È un segnale rilevante per un'azienda che valuta un fornitore, ma risponde a una domanda diversa da quella se una soluzione di fiscalizzazione sia certificata per assolvere un obbligo legato ai corrispettivi telematici.

Certificazione e omologazione della funzione fiscale sono un processo in due fasi, e l'AdE stessa non "certifica" una soluzione. Prima, un organismo autorizzato — il CNR di Pisa e il Politecnico di Milano sono i due attualmente attivi — certifica che la soluzione soddisfa la specifica tecnica. Poi la Commissione Misuratori Fiscali decide sull'omologazione. Entrambi i passaggi sono necessari prima che una soluzione possa arrivare sul mercato. Ad agosto 2026 nessuna soluzione di fiscalizzazione basata su software aveva completato l'omologazione; fiskaly partecipa alla fase pilota dell'AdE e di SOGEI per la trasmissione basata su API, con il supporto del CNR di Pisa sul fronte della certificazione. Non bisogna considerare un percorso di fiscalizzazione cloud come già completamente certificato in Italia: bisogna verificare a che punto si trova realmente un determinato fornitore in quel processo.

Quali controlli di sicurezza impone la specifica dell'AdE?

La ISO 27001 descrive come un fornitore gestisce la sicurezza in termini generali; la specifica dell'AdE descrive cosa deve fare la soluzione certificata in sé, indipendentemente dalla postura di sicurezza generale del fornitore. Alcuni dei controlli prescritti dalla specifica:

• Il PEL comunica con il sistema dell'AdE tramite TLS 1.2 con autenticazione mutua X.509, utilizzando un certificato rilasciato al momento dell'accreditamento — lo stesso requisito si applica al software esterno che invoca le API della soluzione (§9.3 della specifica tecnica).
• Le chiavi private di firma devono risiedere in un'area protetta che impedisca l'estrazione e la duplicazione (§9.2).
• Ogni documento commerciale e ogni file di giornale viene firmato con un certificato per dispositivo, e i giornali riportano una catena di hash che rende rilevabili le sequenze alterate.
• L'Erogatore deve registrare tutti gli accessi ai dati archiviati (§9.7).

Si tratta di requisiti tecnici fissi che una soluzione certificata deve implementare, non di "best practice di sicurezza" opzionali che un fornitore può scegliere di saltare — per questo sono una questione separata dalla postura generale di un fornitore in materia di ISO 27001.

Cosa succede se un fornitore di fiscalizzazione cloud subisce una violazione dei dati?

L'articolo 33 del GDPR richiede a un titolare del trattamento di notificare al Garante per la protezione dei dati personali una violazione di dati personali entro 72 ore dal momento in cui ne ha conoscenza, e l'articolo 34 richiede di notificare direttamente gli interessati quando la violazione comporta un rischio elevato per i loro diritti.

Per un'azienda che utilizza un fornitore di fiscalizzazione cloud, la domanda pratica è chi porta questo termine di 72 ore. Se il fornitore agisce come responsabile del trattamento nell'ambito di un accordo ai sensi dell'articolo 28 del GDPR, il responsabile del trattamento deve notificare il titolare — l'azienda stessa — senza ingiustificato ritardo, in modo che l'azienda possa poi assolvere il proprio obbligo di 72 ore verso il Garante. Un contratto che non dice nulla sui tempi di notifica delle violazioni lascia l'azienda esposta al rischio di non rispettare quel termine senza una colpa diretta propria.

Dove vengono conservati i dati delle transazioni, e perché è importante?

La specifica tecnica dell'AdE richiede che l'infrastruttura di fiscalizzazione cloud si trovi all'interno dell'UE (§11.6). Non si tratta di una scelta con un'alternativa conforme al GDPR: la conservazione dei dati fiscali italiani fuori dall'UE è espressamente vietata dalla specifica stessa, indipendentemente da qualsiasi garanzia di trasferimento che un fornitore potrebbe altrimenti adottare.

Poiché i record delle transazioni elaborati per finalità fiscali spesso includono dati personali insieme ai dati fiscali, la conservazione all'interno dell'UE tiene inoltre l'azienda al di fuori delle regole separate del GDPR sui trasferimenti internazionali di dati, che altrimenti richiederebbero meccanismi come le clausole contrattuali standard per qualsiasi dato personale spostato fuori dall'UE. fiskaly conserva i dati fiscali su infrastruttura basata nell'UE, coperta dalla propria certificazione ISO 27001, il che risolve per impostazione predefinita sia il requisito di residenza dell'AdE sia la questione del trasferimento secondo il GDPR, senza richiedere una giustificazione separata per ogni cliente.

Quali condizioni contrattuali contano nella valutazione di un fornitore di fiscalizzazione cloud?

È la specifica dell'AdE, non il contratto, a decidere cosa succede ai dati fiscali di un commerciante in caso di uscita. L'Erogatore deve garantire l'accesso completo a tutti i dati archiviati ed esportarli in un formato standard "indipendentemente dalla forma contrattuale che disciplina l'utilizzo della soluzione" (§9.7), archiviarli in conformità al Decreto Ministeriale del 17 giugno 2014 (§9.8) e, alla cessazione, consegnare un File Archivio con i giornali, i documenti commerciali e un indice metadati.xml (§10.1–10.3). Nulla di tutto ciò è negoziabile in un contratto, perché si tratta di un obbligo normativo dell'Erogatore.

Quello che il contratto effettivamente disciplina è ciò che la specifica lascia aperto: velocità ed esportazione, costi e chi gestisce la migrazione; un accordo di trattamento dei dati ai sensi dell'articolo 28 del GDPR che indichi le specifiche attività di trattamento, i periodi di conservazione e i subresponsabili; e una finestra di notifica delle violazioni espressa in ore, non lasciata a "senza ingiustificato ritardo".

Prossimi passi

Passare da hardware RT a un fornitore di fiscalizzazione cloud significa valutare un rapporto di trattamento dei dati secondo i propri termini, oltre a un percorso di certificazione e omologazione fiscale che la maggior parte delle soluzioni sul mercato italiano non ha ancora completato. fiskaly SIGN IT funziona su infrastruttura certificata ISO 27001 con dati fiscali conservati su infrastruttura basata nell'UE, e il Trust Center di fiskaly documenta i controlli di sicurezza specifici alla base di quella certificazione. Per il processo di certificazione e omologazione in sé, la guida di fiskaly ai requisiti di certificazione per la fiscalizzazione cloud in Italia approfondisce la separazione tra Produttore ed Erogatore e i passaggi di certificazione, e il panorama fiscale in Italia nel 2026 descrive a che punto si trova oggi il più ampio passaggio dall'hardware al cloud. Una volta raccolti i dati fiscali, fiskaly SAFE si occupa dell'archiviazione pronta per la revisione degli stessi dati.

Ultimo aggiornamento: settembre 2026. Questo articolo ha finalità informative generali e non costituisce consulenza legale. Verificare i requisiti attuali con l'Agenzia delle Entrate, il Garante per la protezione dei dati personali e il GDPR stesso prima di scegliere un fornitore di fiscalizzazione cloud.