La sicurezza e la compliance in cloud ERP nel 2026 si fondano su cinque pilastri: infrastruttura certificata (ISO 27001, SOC 2), trattamento dei dati conforme al GDPR con hosting nell’UE, rispetto delle direttive NIS2 e DORA, DPIA elaborata per le operazioni a rischio e logging auditabile di ogni modifica. Per le PMI europee ciò significa documentazione dimostrabile, misure tecniche (2FA, crittografia, politiche di conservazione) e garanzie contrattuali verso i fornitori ICT — altrimenti si rischiano sanzioni da 10.000 EUR fino a 10 milioni EUR o 2% del fatturato.
Il cloud ERP negli ultimi cinque anni è passato da “alternativa rischiosa” a scelta predefinita anche per settori conservativi come edilizia, produzione e sanità. Con questo cambiamento è mutato anche il quadro normativo — se il GDPR del 2018 fu la “prima ondata”, il 2026 porta la seconda: NIS2, DORA, AI Act e linee guida rafforzate dell’EDPB. Questo articolo pillar riassume tutto ciò che una PMI europea deve sapere prima di scegliere, implementare e gestire un sistema cloud ERP dal punto di vista della sicurezza e della compliance.
L’articolo è diviso in dieci sezioni — dal quadro giuridico alle certificazioni, misure tecniche, audit log, vendor due diligence, fino a esempi pratici di deployment con Modulario. Alla fine trovate un indice verso quattro articoli cluster dedicati ai singoli temi: ISO 27001 per le PMI, NIS2 in pratica, DORA per il settore finanziario e DPIA per ERP/CRM.
Perché il 2026 è un anno cruciale per la sicurezza cloud ERP
Tre fattori si sono incontrati in una stessa finestra temporale e cambiano radicalmente le regole del gioco:
-
Trasposizione NIS2. Le leggi nazionali di recepimento della NIS2 sono in vigore dal 2025/2026 e ampliano il perimetro regolamentato da decine a migliaia di imprese in tutta Europa. Una media impresa con 50+ dipendenti nei settori produzione, trasporti, distribuzione alimentare, servizi ICT o infrastrutture digitali è con alta probabilità coinvolta.
-
DORA (Digital Operational Resilience Act). In vigore dal 17 gennaio 2025. Riguarda non solo banche e assicurazioni, ma anche i loro ICT third-party providers — inclusi i fornitori SaaS di ERP/CRM, se servono soggetti regolamentati. Questo significa che il vostro fornitore ERP deve soddisfare i requisiti DORA se i vostri clienti sono banche o fintech.
-
Linee guida EDPB 2025 + AI Act. Il Comitato europeo per la protezione dei dati ha pubblicato nel 2025 nuove linee guida sui sistemi AI che trattano dati personali, sugli archivi cloud fuori dall’UE e sulle catene di fornitura. Al contempo l’AI Act ha introdotto obblighi per i sistemi AI ad alto rischio (HR scoring, credit scoring), spesso integrati nei moduli ERP.
Il risultato: la pressione normativa nel 2026 è notevolmente superiore a qualsiasi periodo precedente e ignorarla non è più una strategia praticabile. Al contempo è maturato l’ecosistema dei fornitori — le moderne piattaforme ERP EU-native come Modulario offrono compliance “out of the box”, che rappresenta una strada molto più economica rispetto alla costruzione di un’infrastruttura propria.
Quadro giuridico: UE vs. CLOUD Act
Il tema più sottovalutato nella scelta di un cloud ERP è la giurisdizione del fornitore. Non riguarda solo la posizione fisica dei server, ma anche la sede della società madre.
CLOUD Act e Schrems II
Il CLOUD Act americano (2018) consente alle autorità federali statunitensi di richiedere alle società US (incluse le loro filiali europee) l’accesso ai dati dei clienti indipendentemente dal luogo in cui i dati sono conservati. Questo significa che anche se AWS Francoforte conserva i vostri dati a Francoforte, Amazon Web Services Inc. a Seattle può essere legalmente costretta a consegnarli.
La Corte di Giustizia dell’UE lo ha confermato come problema nel caso Schrems II (C-311/18) — non esiste una protezione equivalente per i dati personali dei cittadini UE trasferiti negli USA. Dopo l’annullamento dell’EU-US Data Privacy Framework nell’estate 2023, per i dati critici è rimasta una sola soluzione pragmatica: fornitori EU-nativi con giurisdizione esclusivamente europea.
| Scenario | Rischio CLOUD Act | Conformità GDPR |
|---|---|---|
| Fornitore US + datacenter US | Alto | Problematica |
| Fornitore US + datacenter UE (AWS Francoforte, Azure DE) | Medio | Media, richiede SCC + TIA |
| Fornitore UE + datacenter UE | Nessuno | Piena |
| Fornitore UE + datacenter UE + ISO 27001 + DPA | Nessuno | Piena + auditabile |
Modulario rientra nell’ultima categoria — società europea, hosting esclusivamente nell’UE, certificazione ISO 27001, DPA standardizzata.
Perché è importante per le PMI europee
Molte PMI pensano che il CLOUD Act “non le riguardi, perché non siamo una banca”. La realtà è però diversa:
- Contratti B2B. I grandi clienti (automotive, multinazionali, banche, pubblica amministrazione) nel 2026 richiedono DPA in cui il fornitore confermi esplicitamente di non essere soggetto al CLOUD Act. Senza questo non si supera il vendor due diligence.
- Dati sensibili dei dipendenti. I dati retributivi, sanitari e HR dei cittadini UE sono tra i più rigorosamente regolamentati. Conservarli presso un fornitore US senza TIA (Transfer Impact Assessment) è una violazione dell’art. 44-49 GDPR.
- Regolamentazione settoriale. Pubblica amministrazione, sanità e settore finanziario nel 2026 hanno de facto il divieto di cloud US per i dati primari.
Per maggiori dettagli su come Modulario gestisce la giurisdizione esclusivamente UE, vedere la pagina Sicurezza.
ISO 27001: perché è oggi lo standard minimo
ISO/IEC 27001 è lo standard internazionale per il sistema di gestione della sicurezza delle informazioni (SGSI). Per un fornitore cloud ERP nel 2026 è de facto il biglietto d’ingresso minimo — senza ISO 27001 non si accede al vendor due diligence della maggior parte delle medie imprese e di tutte le grandi.
Cosa significa la certificazione in pratica
ISO 27001 non è solo carta. Un vero audit copre:
- Politiche e procedure (114 controlli nell’Annex A): dall’onboarding dei dipendenti alla gestione delle crisi fino alla dismissione dell’hardware.
- Analisi dei rischi di ogni asset (server, database, risorsa umana, fornitore).
- Misure tecniche: crittografia, segregazione delle reti, monitoring, MFA, backup.
- Misure organizzative: formazione, code of conduct, vendor management, incident response.
- Audit periodici: interno 1× anno, audit di sorveglianza esterno 1× anno, ricertificazione ogni 3 anni.
Modulario ha ottenuto la certificazione ISO 27001 nel 2024 e mantiene attivamente la documentazione completa. Per i dettagli su come Modulario ha affrontato l’audit, vedere l’articolo cluster Cosa significa ISO 27001 per le PMI.
Relazione tra ISO 27001 e SOC 2
Nel contesto US domina SOC 2 (Service Organization Control), nell’UE ISO 27001. Sono complementari — SOC 2 è un report annuale di una società di audit che valuta i trust services criteria (sicurezza, disponibilità, confidenzialità, integrità del trattamento, privacy), mentre ISO 27001 è un certificato del sistema. Il fornitore ideale ha entrambi; per le PMI europee però ISO 27001 è la priorità, perché è riconosciuta internazionalmente anche nel B2B due diligence UE.
GDPR nel contesto del cloud ERP
Il GDPR (Regolamento UE 2016/679) in un deployment cloud ERP ha alcune specificità che una checklist standard non copre.
Ruoli: titolare vs. responsabile del trattamento
Nel sistema ERP/CRM il cliente è il titolare del trattamento (controller) e il fornitore ERP è il responsabile del trattamento (processor). Questo rapporto deve essere formalizzato nell’accordo per il trattamento dei dati (DPA) ai sensi dell’art. 28 GDPR, che specifica:
- oggetto, durata e natura del trattamento,
- tipologie di dati personali e categorie di interessati,
- obblighi del responsabile (riservatezza, misure tecniche, sub-responsabili, audit),
- elenco dei sub-responsabili (provider hosting, Sentry, provider email, ecc.) con approvazione esplicita del titolare.
Modulario fornisce una DPA standardizzata come parte di ogni contratto — senza necessità di ulteriori negoziazioni con un avvocato.
Politiche di conservazione: cosa cambia nel 2026
Le normative UE (fiscali, archivistiche e di settore) stabiliscono diversi periodi di conservazione per diverse tipologie di dati:
| Categoria di dati | Conservazione (UE) | Note |
|---|---|---|
| Fatture, documenti contabili | 10 anni | Direttiva UE 2006/112, normative nazionali |
| Prospetti paga e registrazioni | 5-10 anni | Normative previdenziali nazionali |
| Contratto di lavoro, fascicolo personale | Variabile per legge nazionale | Normative archivistiche |
| Consensi marketing | Fino a revoca / 24 mesi | GDPR + ePrivacy |
| Log di accesso (audit log) | Min. 6 mesi, raccomandato 3 anni | NIS2 + settoriali |
| Snapshot di backup | Secondo la politica di conservazione | Coerente con i dati primari |
L’ERP deve consentire la cancellazione automatica alla scadenza della conservazione e al contempo non cancellare dati ancora necessari per adempiere a obblighi legali. Modulario risolve questo attraverso politiche di conservazione configurabili a livello di attributo.
Richieste degli interessati (DSAR)
Gli artt. 15-22 GDPR conferiscono alla persona fisica il diritto di accesso, rettifica, cancellazione, portabilità e limitazione. L’ERP deve consentire l’export di tutti i dati personali relativi a una persona in formato strutturato entro 30 giorni. In Modulario è una funzione nativa con log auditabile.
NIS2: la nuova ondata di regolamentazione informatica
La Direttiva NIS2 (UE 2022/2555) è entrata in vigore il 16 gennaio 2023 e gli Stati membri avevano fino al 17 ottobre 2024 per recepirla nel diritto nazionale. La maggior parte degli Stati membri ha rispettato o è vicina a questa scadenza con leggi nazionali sulla sicurezza informatica.
Chi è interessato da NIS2
NIS2 amplia la direttiva NIS1 del 2016 da pochi settori a 18 settori divisi in essential e important entities. Per le PMI europee il cambiamento chiave è:
- Le medie imprese (50-250 dipendenti / 10-50 milioni EUR di fatturato) nei settori interessati sono automaticamente regolamentate.
- I settori includono: produzione, distribuzione alimentare, trasporti, gestione dei rifiuti, infrastrutture digitali, servizi ICT, pubblica amministrazione, sanità, ricerca.
- L’eccezione per le imprese più piccole è ristretta — se siete un fornitore “critico” nella catena di fornitura, non si applica.
Principali obblighi
Il soggetto regolamentato deve:
- Gestire i rischi informatici — risk assessment, misure, documentazione.
- Introdurre misure tecniche e organizzative: MFA, crittografia, backup, incident response, BCP/DRP, supply chain security.
- Segnalare gli incidenti alle autorità competenti (CSIRT nazionali, autorità di settore) entro 24h (early warning) / 72h (notifica incidente) / 1 mese (report finale).
- Gestire la catena di fornitura — dimostrare che i principali fornitori ICT (incluso il SaaS ERP) soddisfano misure adeguate.
Sanzioni: fino a 10 milioni EUR o 2% del fatturato mondiale (essential entities), 7 milioni EUR / 1,4% (important entities). La responsabilità personale dei dirigenti è esplicita in NIS2.
Per un’analisi dettagliata della NIS2 per le PMI europee con passi pratici, vedere l’articolo cluster Direttiva NIS2: obblighi per le aziende.
DORA: per il settore finanziario e i loro fornitori ICT
Il Digital Operational Resilience Act (Regolamento UE 2022/2554) è in vigore dal 17 gennaio 2025 e si applica direttamente (senza transposi). Riguarda i soggetti finanziari regolamentati — banche, assicurazioni, imprese di investimento, piattaforme cripto, istituti di pagamento — ma il suo impatto attraverso il rischio ICT di terze parti coinvolge anche i loro fornitori SaaS ERP/CRM.
I cinque pilastri DORA
- Gestione del rischio ICT — framework completo, responsabilità a livello di CdA.
- Gestione degli incidenti — reporting, classificazione, coordinamento.
- Test di resilienza operativa digitale — incluso il threat-led penetration testing (TLPT) per i soggetti più grandi.
- Gestione del rischio ICT di terze parti — registro dei fornitori, funzioni critiche, requisiti contrattuali.
- Condivisione delle informazioni — volontaria, ma supportata.
Cosa significa per il SaaS ERP
Se vendete ERP a banche, assicurazioni o clienti fintech, dovete:
- Stipulare contratti con clausole DORA esplicite (diritto di audit, strategia di uscita, regole di sub-outsourcing, localizzazione dei dati).
- Fornire ambienti di test per TLPT e test di resilienza operativa.
- Avere un Business Continuity Plan (BCP) e un Disaster Recovery Plan (DRP) con RTO/RPO definiti.
- Dimostrare la localizzazione dei dati nell’UE.
Per le PMI clienti fuori dal settore finanziario DORA non si applica direttamente, ma i fornitori ICT DORA-ready offrono un livello superiore di maturità, di cui beneficiano anche le imprese non finanziarie.
Per la checklist completa dei requisiti DORA, vedere l’articolo cluster Direttiva DORA e ERP per il settore finanziario.
Audit log: il cuore della sicurezza auditabile
Senza audit log non si ha né conformità GDPR, né reporting NIS2, né audit SOC 2/ISO 27001, né capacità forense dopo un incidente. L’audit log è la spina dorsale tecnica di tutto il resto.
Cosa deve contenere l’audit log
Per un cloud ERP, il perimetro minimo:
- Chi — account utente (inclusi account API e tecnici).
- Quando — timestamp UTC con precisione al secondo, idealmente millisecondi.
- Cosa — record specifico (entity ID, attributo), valore prima e dopo.
- Da dove — indirizzo IP, user agent, session ID.
- Azione — read / create / update / delete / export.
- Risultato — success / failure / authorization denied.
L’audit log deve essere immutabile (o almeno append-only con rilevamento delle modifiche), crittografato e conservato al di fuori del database applicativo (tipicamente write-only log storage).
Audit log di Modulario
Modulario fornisce audit log nativo per ogni modifica in ogni modulo — dalla fatturazione al magazzino alle HR. I log sono accessibili tramite UI (per gli amministratori) e tramite API (per le integrazioni SIEM). La conservazione è configurabile, default 12 mesi.
Esempio pratico: se nel modulo Finanze qualcuno modifica l’importo di una fattura dopo la sua emissione, l’audit log conserva entrambe le versioni + identificazione utente + timestamp. In caso di controllo IVA o audit interno si dispone di una traccia completa.
DPIA: quando è obbligatoria e come elaborarla
La Valutazione d’Impatto sulla Protezione dei Dati (DPIA) ai sensi dell’art. 35 GDPR è obbligatoria quando il trattamento dei dati personali presenta probabilmente un rischio elevato per i diritti e le libertà degli interessati. Nel contesto ERP/CRM ciò riguarda principalmente:
- Monitoraggio sistematico dei dipendenti (lettori di badge, sistema di videosorveglianza collegato al modulo HR).
- Trattamento di categorie particolari (dati sanitari, biometria) su larga scala.
- Decisioni automatizzate con effetti giuridici (HR scoring, credit scoring).
- Dati su minori o gruppi vulnerabili su larga scala.
- Uso innovativo di tecnologie (AI, sensori IoT con identificazione delle persone).
Struttura della DPIA
La DPIA deve contenere ai sensi dell’art. 35 par. 7:
- Descrizione sistematica del trattamento.
- Valutazione della necessità e proporzionalità.
- Valutazione dei rischi per gli interessati.
- Misure per mitigare i rischi.
Per il deployment di ERP/CRM Modulario forniamo un template DPIA con controlli predefiniti e descrizione delle misure tecniche (crittografia, audit log, accesso basato su ruoli, conservazione). Il cliente lo integra con le proprie specificità (tipologie di trattamento, base giuridica, interessati).
La guida completa alla DPIA per deployment ERP/CRM + template + errori comuni sono nell’articolo cluster DPIA per sistemi ERP/CRM.
AI Act e la sua intersezione con l’ERP
Il Regolamento UE sull’intelligenza artificiale (AI Act, 2024/1689) è entrato in vigore nell’agosto 2024 con applicazione progressiva — i divieti per alcune pratiche sono in vigore dal febbraio 2025, gli obblighi per i sistemi ad alto rischio dall’agosto 2026. Per cloud ERP e CRM con funzionalità AI questo ha diversi impatti diretti.
Categorie di rischio dell’AI Act
| Categoria | Esempi in ERP/CRM | Obblighi |
|---|---|---|
| Vietati | Scoring sociale dei dipendenti per decisioni HR, identificazione biometrica in tempo reale per sorveglianza | Divieto |
| Alto rischio | AI scoring dei candidati, credit scoring dei clienti, pianificazione predittiva dei turni | Conformity assessment, registrazione, monitoraggio, trasparenza |
| Rischio limitato | Chatbot, riassunti AI di documenti, analisi del sentiment | Trasparenza (informare l’utente) |
| Rischio minimo | Filtro spam, categorizzazione automatica dei prodotti | Nessun obbligo specifico |
Sovrapposizione con GDPR DPIA
Per i sistemi AI ad alto rischio nell’ERP che trattano dati personali è necessaria una DPIA combinata + AI conformity assessment. Questo significa documentare non solo i rischi per gli interessati, ma anche la documentazione tecnica del modello, dei dataset, del bias, della precisione e della robustezza.
Moduli AI di Modulario
Le funzionalità AI di Modulario (suggerimenti di testo, sintesi di documenti, rilevamento anomalie in contabilità) sono progettate nella categoria rischio limitato — informano l’utente che l’output è generato dall’AI, l’utente ha sempre la possibilità di override. In questo modo si evita la complessa regolamentazione dei sistemi ad alto rischio e il cliente non deve effettuare un AI conformity assessment.
Se il cliente richiede use-case AI ad alto rischio (HR scoring, decisioni creditizie automatizzate), forniamo documentazione e supporto per il conformity assessment, sottolineando però la complessità normativa.
Vendor due diligence: come scegliere un fornitore sicuro
Prima di firmare un contratto con un fornitore cloud ERP, verificate almeno questi punti:
| Area | Domanda chiave | Risposta accettabile |
|---|---|---|
| Giurisdizione | Sede della società madre? | UE |
| Hosting | Dove sono i datacenter? | UE (DE, FR, NL, PL, IT) |
| Certificazioni | ISO 27001 / SOC 2? | Certificazione ISO 27001 attiva |
| DPA | Template già pronto? | Sì, aggiornato per il 2026 |
| Sub-responsabili | Elenco pubblico? | Sì + pre-approval per i nuovi |
| Audit log | Nativo? Conservazione? | Min. 12 mesi, immutabile |
| 2FA / SSO | Obbligatorio per gli amministratori? | Sì, supporto SAML/OIDC |
| Crittografia | At rest + in transit? | AES-256, TLS 1.3 |
| Backup / DR | RTO / RPO? | RTO < 8h, RPO < 1h |
| Incident response | SLA di notifica? | < 24h |
| Strategia di uscita | Export in formato standard? | Sì (CSV, JSON, API) |
| GDPR DSAR | Supporto nativo? | Sì, < 30 giorni |
Consiglio: richiedete al fornitore un whitepaper sulla sicurezza o un trust center. Se non li ha, è un segnale d’allarme.
Crittografia, chiavi e zone di sicurezza
La crittografia nel 2026 è già un table stake — nessun fornitore SaaS serio può offrire un deployment commerciale senza crittografia sia at rest che in transit. La domanda si è però spostata: chi detiene le chiavi e come vengono gestite?
Crittografia at rest
Nel cloud ERP esistono tre modelli pratici:
- Provider-managed keys (default). Le chiavi sono gestite dal provider SaaS, l’utente non vede la loro rotazione o conservazione. Il più semplice, il meno controllo. Adatto per il 90% delle PMI.
- Customer-managed keys (BYOK). Il cliente genera le proprie chiavi tramite il proprio KMS (AWS KMS, Azure Key Vault, HashiCorp Vault) e le fornisce al provider. Maggiore controllo, ma operazione più complessa. Adatto per i settori regolamentati.
- Hold-your-own-key (HYOK). Il cliente detiene le chiavi nel proprio HSM, il provider si collega tramite API sicura per ogni richiesta. Massimo controllo, ma notevolmente più lento e costoso. Adatto per use-case estremamente sensibili.
Modulario di default offre provider-managed keys con AES-256 e rotazione trasparente ogni 90 giorni. Per i clienti regolamentati offriamo l’opzione BYOK su richiesta.
Crittografia in transit
TLS 1.3 è il minimo nel 2026. TLS 1.0 e 1.1 sono deprecati dal 2020, TLS 1.2 è tollerato solo per i client legacy. Per le comunicazioni interne tra microservizi si usa mTLS (mutual TLS) con rotazione dei certificati tramite PKI interno.
Modulario utilizza internamente mTLS per tutte le chiamate service-to-service e TLS 1.3 per API e UI esterne. HSTS con preload è attivato per tutti i domini pubblici.
Crittografia dei backup e immutabilità
I backup sono spesso bersaglio degli attacchi ransomware — se l’attaccante cifra sia i dati primari che i backup, il recovery è impossibile senza pagare il riscatto. Lo standard moderno:
- Backup crittografati allo stesso modo dei dati primari (spesso chiave diversa).
- Immutable storage (S3 Object Lock, Azure Immutable Blob) — non può essere eliminato né modificato durante il periodo di conservazione.
- Copie air-gapped — geograficamente e di rete separate dalla produzione.
Architettura backup Modulario: snapshot full giornalieri + incrementali orari, crittografati AES-256, replica multi-region (DE + un secondo datacenter UE), conservazione 30 giorni, immutable storage per 7 giorni.
Identità, autenticazione e autorizzazione
Tre livelli che spesso si confondono, ma ognuno risolve un problema diverso:
Autenticazione (chi sei)
- Password + 2FA (TOTP/WebAuthn) — minimo per il 2026.
- SSO tramite SAML 2.0 o OIDC — per deployment aziendali. Modulario supporta Azure AD, Google Workspace, Okta, Keycloak, Auth0, ADFS.
- Passkey (WebAuthn/FIDO2) — accesso passwordless, resistente al phishing. Modulario supporta dal 2025.
- Token hardware (YubiKey) — per accessi estremamente sensibili.
Autorizzazione (cosa puoi fare)
- Role-Based Access Control (RBAC) — l’utente ha un ruolo, il ruolo ha i permessi. Standard per il 95% dei casi d’uso.
- Attribute-Based Access Control (ABAC) — permessi granulari in base agli attributi (tempo, posizione, tipo di record, sensitivity label). Avanzato.
- Field-level security — alcuni attributi di un’entità sono visibili solo per ruoli selezionati (es. stipendi nel fascicolo personale).
Modulario implementa un RBAC ibrido + permessi per attributo tramite il modulo Persone, con field-level security per i moduli sensibili (HR, finanze).
Audit dell’identità
Ogni autenticazione, autorizzazione e modifica dei permessi deve essere loggata. In caso di incidente NIS2/DORA la prima domanda del regolatore è: “chi aveva accesso ai dati interessati in quel momento?”
Backup, BCP e DRP: tre concetti che non sono sinonimi
Backup
Copia dei dati conservata in un’altra posizione. Serve per il ripristino in caso di perdita (guasto tecnico, errore umano, ransomware). Definita da due metriche:
- RPO (Recovery Point Objective) — perdita massima accettabile di dati. Modulario default RPO < 1 ora (incrementali orari).
- RTO (Recovery Time Objective) — tempo massimo accettabile di ripristino. Modulario default RTO < 8 ore (tipicamente < 2 ore).
Business Continuity Plan (BCP)
Piano di come l’azienda continua a operare durante e dopo un incidente. Copre non solo l’IT, ma anche persone, fornitori, comunicazione, processi alternativi.
Per le PMI il BCP minimo contiene:
- Elenco dei processi critici e priorità di ripristino
- Dati di contatto delle persone chiave e dei fornitori
- Siti di lavoro alternativi (piano work-from-home)
- Piano di comunicazione verso clienti e regolatori
- Test del BCP min. 1× anno (table-top exercise)
Disaster Recovery Plan (DRP)
La parte tecnica del BCP — come ripristinare concretamente i sistemi IT. Per i clienti cloud ERP la maggior parte del DRP è eseguita dal fornitore; il cliente ha bisogno di un DRP proprio per i suoi sistemi on-premise e le integrazioni.
Modulario esegue il test DR 2× anno con documentazione dei risultati, che condividiamo con i clienti durante gli audit.
Incident response e forensica
Senza un processo preparato non si rispetta il termine di 24 ore di NIS2/DORA, la notifica GDPR di 72 ore né l’SLA interno verso il cliente.
Struttura del processo di incident response
- Detection — monitoraggio automatizzato (SIEM, anomaly detection) + segnalazioni manuali (dipendenti, clienti).
- Triage — classificazione (severity, scope, categoria).
- Containment — limitazione immediata della propagazione (isolamento dell’account compromesso, blocco IP, disabilitazione del modulo).
- Eradication — rimozione della causa (patch, key rotation, reset account).
- Recovery — ripristino dei sistemi e verifica dell’integrità.
- Post-incident review — root cause analysis, lessons learned, aggiornamento delle misure.
Capacità forense
Dopo un incidente dovete saper rispondere a:
- Quando è successo? (timeline)
- Quali dati sono stati coinvolti? (scope)
- Qual è la causa? (root cause)
- Come prevenirlo in futuro? (remediation)
Senza un audit log immutabile con conservazione sufficiente la forensica è impossibile. L’audit log di Modulario è integrato ed esportabile nei sistemi SIEM del cliente (Splunk, Elastic, QRadar).
Comunicazione durante un incidente
- Interna — alta direzione, legale, PR, IT, team interessati.
- Verso i regolatori — CSIRT nazionale (NIS2), Garante per la protezione dei dati (GDPR), autorità di vigilanza finanziaria (DORA per il settore finanziario).
- Verso clienti e interessati — in modo trasparente, tempestivo, secondo gli SLA contrattuali e l’art. 34 GDPR.
Un template di comunicazione preparato nel runbook di incident response fa risparmiare ore critiche.
Applicazione pratica: sicurezza in Modulario
Per non restare a livello astratto, ecco un panorama concreto di come Modulario implementa quanto sopra:
- Giurisdizione EU-nativa — società europea, senza sub-responsabili US per i dati primari.
- Certificazione ISO 27001 — attiva dal 2024, re-auditata annualmente.
- Hosting UE — Francoforte + secondo datacenter UE (multi-region per HA), nessun dato fuori dall’UE.
- Audit log nativo in ogni modulo, conservazione 12 mesi, configurabile.
- Role-based access control — permessi granulari a livello di attributo, ruoli configurabili.
- 2FA / SSO — TOTP, WebAuthn, SAML 2.0, OIDC.
- Crittografia — AES-256 at rest, TLS 1.3 in transit.
- DPA + elenco sub-responsabili — disponibili pubblicamente, standardizzati.
- Backup — full giornalieri + incrementali orari, conservazione 30 giorni, replica multi-region.
- Supporto DSAR — export dei dati personali su richiesta entro 30 giorni tramite UI.
- Politiche di conservazione GDPR — automatizzate per modulo (fatture 10 anni, HR per tipologia, marketing 24 mesi).
Costi della (non) compliance: perché l’investimento vale
Gli investimenti in sicurezza e compliance sembrano a prima vista un puro costo. Il calcolo reale mostra però che la non-compliance è 3-10× più costosa della compliance. Ecco un esempio modellistico per una media impresa manifatturiera europea (80 dipendenti, fatturato 12 milioni EUR):
| Voce | Scenario compliance | Scenario non-compliance |
|---|---|---|
| Implementazione ISO 27001 + audit | 15.000 EUR / primo anno | 0 EUR |
| Processo GDPR + DPA | 5.000 EUR / anno | 0 EUR |
| Audit di sorveglianza ISO | 3.000 EUR / anno | 0 EUR |
| Assicurazione cyber | 8.000 EUR / anno | 16.000 EUR / anno (tariffa maggiorata) |
| Formazione dipendenti | 2.000 EUR / anno | 0 EUR |
| Totale compliance | 33.000 EUR / anno | 16.000 EUR / anno |
| Rischio sanzione GDPR (probabilità 5%) | 0 EUR | 25.000 EUR (sanzione media UE × probabilità) |
| Rischio sanzione NIS2 (3%) | 0 EUR | 30.000 EUR (valore atteso) |
| Rischio ransomware (12%) | 5.000 EUR (recovery da backup) | 60.000 EUR (downtime + riscatto + reputazione) |
| Gare perse (che richiedono ISO/DPA) | 0 EUR | 100.000 EUR / anno (modello: 3 gare perse) |
| Totale risk-adjusted | 38.000 EUR / anno | 231.000 EUR / anno |
Rapporto 6:1 a favore della compliance — e questo senza considerare i benefici intangibili come reputazione, fiducia dei clienti, capacità di ottenere investimenti.
Modulario in questo modello fornisce un’ulteriore risparmio — poiché offriamo una piattaforma certificata ISO 27001 con audit log, hosting UE e DPA standardizzata, il cliente non deve costruire la propria infrastruttura e risparmia ulteriori 8-15.000 EUR annui al livello tecnico.
Indice cluster: approfondimenti per singoli temi
Questo articolo pillar copre un’ampia agenda. Se volete approfondire un’area specifica, consultate questi articoli cluster:
- ISO 27001 per le PMI: cosa significa — quando la certificazione è obbligatoria, come si svolge l’audit, i benefici per il cliente.
- Direttiva NIS2: obblighi per le aziende — chi è interessato in Europa, obblighi chiave, sanzioni, processo di preparazione e relazione con ERP/CRM.
- Direttiva DORA: settore finanziario e ERP — chi deve conformarsi, requisiti per i provider ICT di terze parti (incluso SaaS ERP), checklist pratica.
- DPIA per sistemi ERP/CRM — quando è obbligatoria, come elaborarla per il deployment Modulario, template, errori comuni.
Riepilogo e raccomandazioni
La sicurezza e la compliance nel cloud ERP nel 2026 non sono un nice-to-have — sono un prerequisito di esistenza. La pressione arriva da ogni direzione: regolatori (NIS2, DORA, GDPR), clienti B2B (vendor due diligence), assicuratori (la polizza cyber richiede prove), banche (DORA tramite third-party risk).
Per le PMI europee ci sono tre percorsi pragmatici:
- Build: team IT proprio, on-premise / private cloud, certificazione propria. Costo: centinaia di migliaia di EUR annui. Adatto solo per grandi imprese con 200+ dipendenti e dati sensibili.
- Buy SaaS non-UE: economico, rapido, ma con rischio CLOUD Act e GDPR problematico. Adatto solo per use-case non critici.
- Buy SaaS EU-nativo con ISO 27001: la scelta più razionale per il 95% delle PMI. Compliance “out of the box”, costi prevedibili, giurisdizione esclusivamente UE.
Modulario rientra nella terza categoria. Se volete sapere come potreste raggiungere uno stato GDPR + NIS2 ready in 6-8 settimane invece di 6-12 mesi, consultate le nostre misure di sicurezza o contattateci tramite una consulenza gratuita.
Domande frequenti
Ogni PMI deve avere la certificazione ISO 27001? No, ISO 27001 non è generalmente obbligatoria. Tuttavia diventa de facto obbligatoria nei rapporti B2B con grandi clienti (automotive, banche, pubblica amministrazione) e nei settori regolamentati NIS2. Per le PMI è spesso più efficiente scegliere un fornitore ERP/SaaS già certificato ISO 27001 piuttosto che costruirla internamente.
Qual è la differenza tra NIS2 e DORA? NIS2 è una direttiva orizzontale per la sicurezza informatica di 18 settori nell’UE (produzione, trasporti, energia, sanità, ICT…). DORA è un regolamento settoriale solo per il settore finanziario, ma in pratica più stringente con impatto diretto sui fornitori ICT. Alcune organizzazioni ricadono sotto entrambi — una banca è contemporaneamente NIS2 essential entity e DORA financial entity, con DORA prevalente (lex specialis).
Basta un cloud ERP con hosting nell’UE per essere conformi al GDPR? L’hosting nell’UE è condizione necessaria, non sufficiente. Servono anche: DPA con il fornitore (art. 28 GDPR), elenco dei sub-responsabili, politiche di conservazione, audit log, supporto DSAR, misure tecniche (crittografia, 2FA, RBAC) e misure organizzative (incident response, vendor management). Idealmente anche la certificazione ISO 27001 del fornitore come prova di adeguatezza.
Quando è necessaria la DPIA per il deployment di un nuovo modulo ERP? Sempre quando il nuovo modulo presenta alto rischio: trattamento di categorie particolari su larga scala, monitoraggio sistematico dei dipendenti, decisioni automatizzate, o tecnologie innovative (AI scoring, biometria). Per un modulo contabile o di magazzino standard la DPIA di solito non è necessaria, ma è raccomandata la documentazione dell’analisi dei rischi. La guida dettagliata è nell’articolo cluster sulla DPIA.
Quali sono le sanzioni massime nel 2026? GDPR: 20 milioni EUR o 4% del fatturato mondiale (il valore più alto). NIS2: 10 milioni EUR o 2% del fatturato (essential), 7 milioni EUR o 1,4% (important). DORA: fino all’1% del fatturato giornaliero per la durata della violazione (fino a 6 mesi). AI Act: 35 milioni EUR o 7% del fatturato per pratiche vietate. Più responsabilità personale dei dirigenti in NIS2 e DORA.