Security and GDPR in Cloud Fiscalization: What Italian Businesses Should Check

Moving fiscalization from a Registratore Telematico (RT) sitting next to the till to a cloud API changes where transaction data physically runs and how a business needs to evaluate its relationship with whoever operates that infrastructure. It does not, on its own, change Italy's two separate compliance obligations. Italy's corrispettivi telematici rules already require that data reach the Agenzia delle Entrate (AdE) intact and unaltered; GDPR is a separate, EU-wide layer covering how any personal data inside those transactions gets stored, processed, and protected. A business switching from RT hardware to a cloud fiscalization provider is running both checks at once, not swapping one for the other.

Key takeaways

• Cloud fiscalization solutions still need AdE certification and homologation for the fiscal function itself; GDPR compliance is a separate, additional requirement layered on top, not a substitute for it. As of August 2026, no cloud fiscalization solution has completed AdE homologation yet — the first homologations are expected end of 2026 or early 2027.
• Italy's fiscalization roles are distinct: the Produttore (producer) builds the software, and the Erogatore (provider) operates it for merchants. ISO 27001 is required of both roles, but GDPR obligations fall specifically on the Erogatore, the entity actually processing the data.
• corrispettivi telematici transmissions are designed to minimize personal data: the payment field records only the payment method and amount, not full card details, and a customer's fiscal code, when captured, is hashed rather than stored in the clear. Invoices and loyalty-program identifiers aren't part of the fiscalization data stream at all.
• GDPR's Article 33 requires notifying Italy's Garante per la protezione dei dati personali within 72 hours of becoming aware of a personal data breach — who actually carries that clock depends on what the contract with the provider says about processor-to-controller notification timing.
• Non-EU storage of Italian fiscal data isn't just a transfer scenario to manage with Standard Contractual Clauses — it's explicitly prohibited outright by the AdE's own technical specification.
• A provider's contract terms, not its marketing claims, determine who is liable if a data security failure affects a business's fiscal records.

What data does cloud fiscalization actually process?

Cloud fiscalization systems process transaction-level data, and some of that data qualifies as personal data under GDPR, which is why GDPR sits alongside Italy's fiscal rules rather than outside them. But the scheme is narrower than a generic "POS system" comparison suggests, because corrispettivi telematici is designed to minimize what gets transmitted:

• Payment details are reduced to type and amount. The transmission records that a sale was paid by card or cash and for how much — not the card number or other payment credentials.
• The fiscal code, when present, is hashed. Where a customer's codice fiscale is captured, it is stored in hashed form rather than in the clear.
• Invoices are a separate document type. An invoice is not part of the corrispettivi telematici transmission itself, so it doesn't belong in a list of what the fiscalization data stream contains.
• Loyalty program identifiers have no official standing in the scheme. They aren't a recognized field in the corrispettivi telematici data model.

None of this takes the system out of GDPR's scope. A payment type and amount, or a hashed fiscal code, can still be personal data if it can be linked back to an individual — hashing narrows what's exposed, it doesn't automatically make the field anonymous under GDPR's own definitions. The practical point for a business evaluating a provider is narrower than "does GDPR apply generically to POS data": it's what specific fields the transmission actually carries, and whether the provider's claims about data minimization match what the AdE specification itself defines.

Roles under Italian fiscalization law: Produttore, Erogatore, and where GDPR applies

Italian fiscalization law separates the entity that builds a solution from the entity that operates it for merchants, and the distinction matters for both certification and GDPR:

• The Produttore (producer) develops the software — the PEM and PEL modules — against the AdE's technical specification.
• The Erogatore (provider) distributes the solution and keeps it running for merchants, and is the entity legally and operationally accountable to the AdE and to the merchant if something goes wrong.

ISO 27001 is a requirement for both roles. GDPR, however, is not: GDPR obligations fall on the Erogatore, because it is the party that actually operates the system and processes the data running through it. The Produttore role, on its own, is not GDPR-relevant.

fiskaly holds both roles for its own cloud fiscalization solution. Where fiskaly instead supplies the underlying software to a third party acting as Erogatore, that third party needs both a certified and homologated solution and its own AdE accreditation as a provider — the software's own certification path doesn't substitute for the Erogatore's own accreditation.

What does ISO 27001 confirm — and what does it leave out?

ISO 27001 certifies that an organization runs a documented information security management system (ISMS) covering risk assessment, access controls, and incident response. It does not itself confirm GDPR compliance, and it does not confirm AdE fiscal certification — it's a statement about how a company manages information security, not about what a specific certified solution is required to do.

fiskaly holds ISO 27001 certification across its group of companies, including fiskaly Italy — fiskaly's Trust Center documents the scope directly. That's a meaningful signal for a business evaluating a provider, but it answers a different question than whether a fiscalization solution is certified to handle a corrispettivi telematici obligation.

Certification and homologation for the fiscal function are a two-step process, and the AdE itself doesn't "certify" a solution. First, an authorized body — the CNR di Pisa and Politecnico di Milano are the two currently active ones — certifies that the solution meets the technical specification. Then the Commissione Misuratori Fiscali determines homologation. Both steps are necessary before a solution can go to market. As of August 2026, no software-based fiscalization solution has completed homologation yet; fiskaly is participating in the AdE and SOGEI pilot phase for API-based transmission, with the CNR di Pisa's support on the certification side. Don't treat a cloud fiscalization path as already fully certified in Italy — check where a specific provider actually stands in that process.

What security controls does the AdE specification mandate?

ISO 27001 describes how a provider manages security in general terms; the AdE specification describes what the certified solution itself has to do, independently of the provider's own security posture. Some of the controls the specification prescribes:

• The PEL communicates with the AdE system over TLS 1.2 with mutual X.509 authentication, using a certificate issued at accreditation — the same requirement applies to external software calling the solution's APIs (§9.3 of the technical specification).
• Private signing keys must sit in a secure area that prevents extraction and duplication (§9.2).
• Every commercial document and journal file is signed with a per-device certificate, and journals carry a hash chain that makes altered sequences detectable.
• The Erogatore must log all access to stored data (§9.7).

These are fixed technical requirements a certified solution must implement, not optional "security best practices" a provider can choose to skip — which is why they're a separate question from a provider's general ISO 27001 posture.

What happens if a cloud fiscalization provider has a data breach?

GDPR Article 33 requires a data controller to notify Italy's Garante per la protezione dei dati personali within 72 hours of becoming aware of a personal data breach, and Article 34 requires notifying affected individuals directly when the breach poses a high risk to their rights.

For a business using a cloud fiscalization provider, the practical question is who carries that 72-hour clock. If the provider is acting as a data processor under a GDPR Article 28 agreement, the processor must notify the controller — the business itself — without undue delay, so the business can then meet its own 72-hour obligation to the Garante. A contract that's silent on breach notification timing leaves the business exposed to missing that window through no direct fault of its own.

Where is the transaction data stored, and why does that matter?

The AdE's technical specification requires cloud fiscalization infrastructure to sit within the EU (§11.6). This isn't framed as a choice with a GDPR-compliant workaround: storing Italian fiscal data outside the EU is explicitly prohibited by the specification itself, regardless of any transfer safeguard a provider might otherwise put in place.

Because transaction records processed for fiscal purposes frequently include personal data alongside fiscal data, EU-based storage also keeps a business out of GDPR's separate rules on international data transfers, which would otherwise require mechanisms like Standard Contractual Clauses for any personal data moved outside the EU. fiskaly stores fiscal data on EU-based infrastructure covered by its ISO 27001 certification, which keeps both questions — the AdE residency requirement and the GDPR transfer question — closed by default rather than requiring a separate justification for every customer.

What contract terms matter when evaluating a cloud fiscalization provider?

The AdE specification, not the contract, decides what happens to a merchant's fiscal data on exit. The Erogatore must give full access to all stored data and export it in a standard format "regardless of the contractual form governing use of the solution" (§9.7), archive it under the Ministerial Decree of 17 June 2014 (§9.8), and on termination hand over a File Archivio with the journals, commercial documents, and a metadati.xml index (§10.1–10.3). None of that is negotiable in a contract, because it's a regulatory requirement on the Erogatore.

What the contract actually covers is what the specification leaves open: export speed, cost, and who handles the migration; a GDPR Article 28 data processing agreement naming the specific processing activities, retention periods, and sub-processors; and a breach notification window stated in hours, not left to "without undue delay."

Next steps

Switching from RT hardware to a cloud fiscalization provider means evaluating a data processing relationship on its own terms, alongside a fiscal certification and homologation path that most solutions in the Italian market haven't completed yet. fiskaly SIGN IT runs on ISO 27001-certified infrastructure with fiscal data stored on EU-based infrastructure, and fiskaly's Trust Center documents the specific security controls behind that certification. For the certification and homologation process itself, fiskaly's guide to cloud fiscalization certification requirements in Italy covers the Produttore/Erogatore split and the certification steps in more detail, and the fiscal landscape in Italy in 2026 covers where the wider shift from hardware to cloud currently stands. Once fiscal data is collected, fiskaly SAFE handles the audit-ready archiving side of the same data.

Last updated: September 2026. This article is general guidance, not legal advice. Confirm current requirements against the Agenzia delle Entrate, the Garante per la protezione dei dati personali, and GDPR itself before selecting a cloud fiscalization provider.