SaaS vs. On‑Premise: Quadro decisionale per conformità e sovranità dei dati

La decisione SaaS vs. On‑Premise diventa in molte organizzazioni realmente critica solo quando i requisiti di conformità e di sovranità dei dati si concretizzano: dove si trovano i dati? Chi ha accesso amministrativo? Come si supera un audit senza affidarsi a ipotesi? E come ci si può eventualmente ritirare senza dover affrontare progetti di migrazione di mesi sotto pressione temporale?

In pratica, «cloud o no» raramente è la vera domanda. Ciò che conta è se il modello operativo scelto soddisfa i vostri requisiti di conformità legale, verificabilità (audit), gestione del rischio e gestibilità operativa — lungo l’intero ciclo di vita, non solo al Go‑Live. Questo contributo fornisce un quadro decisionale solido che mette IT‑management, Compliance, Security, Procurement e Direzione su una logica di valutazione comune. Il focus è su attuabilità, responsabilità e controlli documentabili.

Chiarire i termini: sovranità dei dati, residenza dei dati e responsabilità condivisa

Sovranità dei dati non significa solo «i dati sono presso di noi». Indica la capacità di far rispettare l’uso dei dati: controllare gli accessi, gestire le chiavi, avviare cancellazioni con evidenza, esportare dati e mantenere la capacità di intervenire in caso di conflitti (p. es. richieste delle autorità). Residenza dei dati è più RESTrittiva: descrive in quale regione o paese i dati sono memorizzati e trattati.

Nel contesto SaaS si lavora spesso con il concetto di responsabilità condivisa: fornitore e cliente si dividono le responsabilità. Non è un termine di marketing, ma deve essere tradotto in controlli concreti. Tipico: il fornitore è responsabile della piattaforma (data center, sicurezza di base, patching dell’applicazione SaaS), il cliente è responsabile delle identità, dei ruoli, della classificazione dei dati, delle autorizzazioni, della configurazione e dell’uso corretto. In ambiente On‑Premise la responsabilità ricade quasi interamente su di voi — ma in cambio le evidenze e i diritti di intervento sono completamente nelle vostre mani.

Perché la «conformità» non basta senza la prospettiva dell’audit

Molti requisiti sono soddisfatti solo quando risultano verificabili: tramite revisione interna, revisori esterni, audit dei clienti o autorità. È fondamentale poter rispondere in modo chiaro alle seguenti domande:

• Quali controlli esistono? (p. es. controllo degli accessi, registrazione/log, gestione delle chiavi, backup/ripristino)
• Come vengono implementati i controlli? (configurazione, processi, responsabili)
• Come si dimostra l’efficacia? (log, report, protocolli di test, evidenze di change)
• Come si reagisce alle deviazioni? (processo di gestione degli incidenti, escalation, azioni correttive)

Un fornitore SaaS può fornire molte evidenze (p. es. rapporti SOC), ma non necessariamente quelle rilevanti per la vostra azienda. Viceversa, On‑Premise può teoricamente coprire tutto, ma nella pratica fallisce per carenze di risorse umane, maturità dei processi o mancanza di documentazione. Il quadro decisionale deve quindi rappresentare entrambe le dimensioni: controllabilità e effettiva capacità operativa.

SaaS vs. On‑Premise: le principali dimensioni decisionali

Invece di una lista generale Pro/Contro, è efficace una valutazione lungo dimensioni stabili. Ogni dimensione viene infine tradotta in requisiti che può ancorare in RFP, nel contratto e nella gestione operativa.

1) Classificazione dei dati e requisito di protezione come punto di partenza

Senza classificazione dei dati, le discussioni su SaaS vs. On‑Premise sfociano in decisioni istintive. Una classificazione pragmatica (es. pubblica / interna / riservata / strettamente riservata) è sufficiente se usata con coerenza. È importante definire il requisito di protezione: riservatezza, integrità, disponibilità e tracciabilità (Audit Trail).

Regola pratica: maggiore è il requisito di protezione, più stringenti devono essere le misure di controllo tecniche (es. gestione delle chiavi) e le misure di controllo organizzative (es. processi di autorizzazione). Questo può essere soddisfatto da SaaS – ma solo se i meccanismi offerti si adattano al suo modello.

2) Accesso, diritti amministrativi e separazione dei tenant

Nelle ambienti SaaS la domanda più critica spesso non è “il fornitore può vedere i dati?”, ma chi può intervenire amministrativamente e in quali condizioni. Ciò include accessi di supporto, accessi di emergenza, subprocessori e il modello interno di autorizzazioni del fornitore. La separazione dei tenant (Multi‑Tenancy) è comune nel SaaS. Non è intrinsecamente insicura, ma richiede separazione tecnica e organizzativa documentabile e chiare garanzie sugli ambienti di test, staging e produzione.

On‑Premise le offre il massimo controllo sugli accessi amministrativi – ma questo significa anche che deve effettivamente implementare MFA, Privileged Access Management (PAM, cioè accessi amministrativi controllati con registrazione) e hardening. Senza queste misure, “On‑Premise” non è automaticamente più sicuro.

3) Crittografia e gestione delle chiavi (KMS, BYOK, HYOK)

La crittografia è argomento rilevante per la sovranità dei dati solo se la gestione delle chiavi è adeguata. Alcuni termini che ricorrono spesso nelle trattative di approvvigionamento:

• KMS (Key Management Service): servizio per la gestione delle chiavi crittografiche, inclusa la rotazione e le regole di accesso.
• BYOK (Bring Your Own Key): Lei fornisce la chiave, il fornitore la utilizza nella sua infrastruttura, spesso sotto il suo controllo per quanto riguarda rotazione/disattivazione.
• HYOK (Hold Your Own Key): le chiavi RESTano nel suo ambiente; il fornitore non può decifrare senza la sua collaborazione. Questo è più impegnativo dal punto di vista tecnico e non è disponibile in tutti i SaaS.

Per la compliance è centrale: chi può attivare, ruotare e bloccare le chiavi? E: quali dati e come sono crittografati? (at REST, cioè a riposo; in transit, cioè in transito; eventualmente lato client). On‑Premise tipicamente consente il pieno controllo, ma richiede processi maturi (rotazione, backup delle chiavi, scenari di recovery).

4) Logging, Audit Trail e conservazione delle prove

La auditabilità dipende dai log: chi ha consultato, modificato, esportato o cancellato quali dati e quando? Per molti regimi (controllo interno, protezione dei dati, standard di sicurezza) è necessaria una catena di eventi tracciabile. Nel SaaS è importante poter esportare i dati grezzi (es. eventi amministrativi) e sapere per quanto tempo vengono conservati. Nell’On‑Premise è fondamentale che il logging non sia solo ‚attivato‘, ma venga analizzato centralmente e memorizzato con bassa suscettibilità di manomissione (principio Write‑Once‑Read‑Many o archiviazione a prova di revisione).

Per la fase di procurement una domanda concreta è determinante: Il sistema può inviare i log al vostro SIEM (Security Information and Event Management, analisi centrale della sicurezza), con livello di dettaglio sufficiente e interfacce stabili?

5) Residenza dei dati, subprocessori e trasferimenti transfrontalieri

Le normative sulla protezione dei dati e i requisiti di settore richiedono spesso chiarezza su dove avviene il trattamento e chi è coinvolto. Nel SaaS la catena dei subprocessori è centrale: hosting, supporto, monitoring, risposta agli incidenti, provider di posta elettronica, sistemi di ticketing. Serve trasparenza, processi di modifica e possibilità di opposizione. L’On‑Premise riduce questa catena, ma la sostituisce con fornitori propri (es. manutenzione, data center, servizi gestiti) — anche questi vanno coinvolti in modo chiaro, contrattuale e organizzativo.

6) Business Continuity: backup, RESTore, RTO/RPO, operatività d’emergenza

Conformità e sovranità dei dati riguardano anche la disponibilità. Due metriche dovrebbero figurare in ogni decisione:

• RPO (Recovery Point Objective): perdita massima di dati tollerabile in termini di tempo (es. 15 minuti).
• RTO (Recovery Time Objective): tempo massimo di ripristino tollerabile (es. 4 ore).

Il SaaS può essere performante su questi aspetti, ma è necessario verificare cosa è garantito contrattualmente: frequenza dei backup, test di RESTore, resilienza a guasti regionali, dipendenza dai servizi di identità, tempi di risposta del supporto in caso di incidente grave. L’On‑Premise può essere ottimizzato esattamente sui vostri RTO/RPO — richiede però pianificazione, ridondanza hardware, test di RESTore regolari e runbook affidabili.

7) Change e patch management come fattore di conformità

Nel SaaS le modifiche avvengono spesso in modo continuo. Questo è positivo per gli aggiornamenti di sicurezza, ma può introdurre rischi per la validazione, le interfacce e i processi di business. Diventa rilevante per la conformità quando è necessario tracciare e valutare le modifiche: quali release sono previste? Esistono note di rilascio? Ci sono preavvisi? È possibile disabilitare o ‚bloccare‘ funzionalità?

Nell’On‑Premise gestite voi patch e release. Questo riduce le sorprese, ma aumenta il rischio che gli aggiornamenti rimangano arretrati. In un audit ‚avremmo potuto applicare la patch‘ non è una giustificazione se vulnerabilità note RESTano aperte per mesi.

Trasformare i requisiti normativi in una logica di verifica attuabile

Indipendentemente dal fatto che vi orientiate a standard ISO, requisiti di settore o quadri normativi: è fondamentale tradurre in requisiti verificabili. Esempi di driver comuni (non esaustivi):

• Protezione dei dati (es. DSGVO): trattamento per conto, politiche di cancellazione, diritti degli interessati, misure tecniche e organizzative.
• NIS2: responsabilità di gestione, misure di sicurezza, processi di notifica, rischi nella supply chain.

Importante per „Approvvigionamento“: questi fattori non vanno inseriti come buzzword in un RFP, ma come requisiti di controllo concreti con evidenze, responsabilità e diritti di verifica.

Quadro decisionale: dai requisiti a una selezione robusta

Il seguente quadro funziona come flusso operativo, che può essere integrato in approvvigionamento, governance e pianificazione del progetto. Obbliga a chiarire i punti aperti precocemente – prima che il contratto e l’architettura tecnica creino fatti compiuti.

Fase 1: definire i Minimum Controls (non negoziabili)

Definite una lista di Minimum Controls che si applicano indipendentemente dal modello operativo. Esempi:

• MFA per tutti gli accessi amministrativi; principio dei ruoli con Least Privilege (minimi privilegi necessari).
• Audit trail tracciabile per azioni critiche (p. es. modifiche alle autorizzazioni, esportazioni, cancellazioni).
• Residenza dei dati definita o deroga motivata con controlli sui trasferimenti.
• Crittografia in transito e a riposo; gestione delle chiavi documentata, inclusa la rotazione.
• Piano di backup/RESTore con test di ripristino regolari e RTO/RPO chiari.
• Processo di gestione degli incidenti con tempi di segnalazione, punti di contatto e supporto forense.

Questi Minimum Controls sono il nucleo della vostra posizione di conformità. Se un fornitore (o la vostra stessa organizzazione On‑Prem) non può soddisfarli, la discussione si chiude o è necessaria un’accettazione formale del rischio a livello dirigenziale.

Fase 2: mappatura dei controlli e definizione delle responsabilità (RACI)

Per ogni obiettivo di controllo dovRESTe stabilire chi è Responsible (esecutore), Accountable (responsabile), Consulted (consultato) e Informed (informato). Soprattutto con il SaaS si creano lacune quando tutti presumono ‚il fornitore se ne occuperà‘.

Tipici trabocchetti RACI sono la gestione delle identità (SSO, quindi Single Sign‑On), la gestione delle autorizzazioni, le esportazioni di dati, le richieste di cancellazione, le decisioni sulle chiavi e la conservazione dei log. Questi punti dovrebbero comparire come voci separate nella vostra matrice.

Fase 3: creare un piano delle evidenze per gli audit

Un piano delle evidenze è un elenco di prove che potete fornire con un clic. Esempi:

• Estratto di configurazione su MFA/SSO e ruoli amministrativi
• Registro di un test di ripristino (data, portata, risultato, deviazioni)
• Approvazioni di change per modifiche rilevanti per la sicurezza
• Elenco dei sub-processori inclusa la cronologia delle modifiche
• Estratto dagli eventi SIEM per azioni critiche (ridotto ai dati necessari)

Importante: pianificate le evidenze in modo che siano disponibili anche se il tenant SaaS è bloccato o i sistemi On‑Prem sono isolati durante un incidente.

Fase 4: strategia di uscita e portabilità come capitolo obbligatorio

La conformità e la sovranità dei dati non terminano con l’esercizio, ma con l’uscita. Un piano di exit è più di ‚possiamo esportare‘. Comprende:

• Esportazione dei dati: formati, completezza (incl. metadati, audit trail), frequenza, automazione.
• Identità e autorizzazioni: come verranno migrate o ricostruite ruoli, gruppi e strutture di autorizzazione?
• Interfacce: quali integrazioni dipendono dal sistema (ERP, DMS, IAM, BI)? Come verrà effettuato il passaggio?
• Scadenze: Per quanto tempo i dati RESTano disponibili dopo la risoluzione? Come avviene la cancellazione comprovabile?
• Dipendenze: workflow proprietari, modelli di dati, report, automazioni.

Se questi punti non sono assicurati contrattualmente e tecnicamente, il Vendor Lock‑in non rimane una «sensazione», ma si trasforma in un concreto blocco alla migrazione.

Checklist per l’approvvigionamento (RFP): confrontare in modo auditabile SaaS vs. On‑Premise

La checklist che segue è deliberatamente formulata in modo da poter essere inserita in un RFP, in una lista di due‑diligence o in un foglio di valutazione interno.

A) Dati e protezione dei dati

• Quali categorie di dati vengono trattate? Esistono funzioni per la classificazione/labeling dei dati?
• Dove avviene l’elaborazione e l’archiviazione (regioni)? Esiste una garanzia vincolante sulla residenza dei dati?
• Come vengono comunicati i subprocessori? Esiste notifica preventiva, diritto di obiezione, diritti di uscita?
• Come vengono eseguite le richieste di cancellazione e come vengono dimostrate (incl. backup, repliche, log)?
• La soluzione supporta i diritti degli interessati (accesso, cancellazione, esportazione) entro termini praticabili?

B) Sicurezza e controllo degli accessi

• Supporto per SSO (ad es. SAML/OIDC) e MFA, incl. accessi admin e accessi API?
• Modello dei ruoli: principio del minimo privilegio, ruoli personalizzati, ruoli admin separati, account Break‑Glass (accesso di emergenza) con registrazione?
• Crittografia: in transito / a riposo; opzioni per BYOK/HYOK; rotazione delle chiavi; auditabilità delle azioni sulle chiavi?
• Limitazioni di rete e accesso: IP‑Allowlisting, connettività privata, isolamento dei tenant?

C) Audit, logging e evidenze

• Quali audit‑log sono disponibili (azioni admin, accessi ai dati, esportazioni, eventi di autenticazione)?
• Per quanto tempo i log sono conservati e possono essere esportati (integrazione SIEM)?
• Quali report di controllo indipendenti sono disponibili (ad es. report SOC) e con quale aggiornamento?
• Come viene documentato il change‑management (release notes, finestre di manutenzione, opzioni di rollback)?

D) Operatività, resilienza e supporto

• RTO/RPO definiti, frequenza dei backup, test di ripristino, evidenze?
• Incident‑response: referenti, escalation, tempi di notifica, supporto forense, post‑mortem?
• SLA: disponibilità, orari di supporto, tempi di risposta, prioritizzazione, logica delle compensazioni?
• Dipendenze: provider IAM, consegna e‑mail, DNS, limiti di rate API, finestre di manutenzione?

E) Uscita, portabilità, fine del contratto

• Esportazioni standardizzate (dati + metadata + audit trail), documentate e regolarmente testabili?
• Termini e condizioni alla risoluzione: accesso ai dati, esportazione, cancellazione, costi?
• Supporto alla migrazione: documentazione tecnica, stabilità delle interfacce, finestre di migrazione?

Componenti di modello: requisiti minimi come testo di policy

Per evitare che i requisiti esistano solo „nella testa“, è utile un breve blocco di policy copiabile. È volutamente generico e deve essere adattato alla vostra organizzazione.

POLICY: Selezione e gestione di soluzioni SaaS e On-Premise con requisito di protezione 'confidenziale' o superiore

1. Identità & Zugriff
- L'accesso amministrativo richiede MFA ed è associato a una persona (niente account condivisi).
- Ruoli e permessi seguono il principio del privilegio minimo e vengono ri-certificati almeno ogni trimestre.
- Gli accessi di emergenza (Break-Glass) sono documentati, limitati nel tempo e completamente registrati.

2. Daten & Schlüssel
- I dati sono cifrati in transito e a riposo.
- La gestione delle chiavi è documentata (rotazione, revoca, recovery). Dove possibile, si preferiscono chiavi controllate dal cliente.

3. Logging & Audit
- Eventi rilevanti per la sicurezza (Auth, azioni amministrative, esportazioni, cancellazioni) sono registrati in modo a prova di revisione.
- I log sono esportabili e vengono correlati centralmente (SIEM o equivalente).

4. Resilienz
- RTO/RPO sono definiti e verificati mediante test di ripristino regolari.
- I processi di incident (segnalazione, escalation, comunicazione) sono disciplinati contrattualmente e a livello organizzativo.

5. Exit
- L'esportazione dei dati e la cancellazione alla fine del contratto sono tecnicamente possibili, documentate e garantite contrattualmente.
- Il piano di exit è valutato prima della firma del contratto e riesaminato almeno annualmente.

Valutare realistamente costi e rischio: TCO incontra l’onere della compliance

La questione dei costi viene spesso ridotta ai soli costi di licenza. Per i requisiti di compliance e sovranità dei dati è invece decisivo quanto sforzo richiedano le controlli e la produzione di evidenze. Blocchi di costo tipici:

• SaaS: licenze, moduli aggiuntivi (Security/Compliance), integrazione SIEM, opzioni di esportazione dati/backup, supporto enterprise, oneri contrattuali e di audit, eventualmente costi per opzioni di crittografia controllate dal cliente.
• On‑Premise: hardware/virtualizzazione, storage/backup, segmenti di rete, hardening, finestre di patch, reperibilità 24/7, monitoring/SIEM, sforzo di personale per esercizio e documentazione, test di ripristino, lifecycle‑management.

Un errore comune: l’On‑Premise viene conteggiato come „gratuito“ con team esistenti, mentre il SaaS è percepito come „costoso“. In audit però conta se l’esercizio e la documentazione vengono effettivamente eseguiti. Se On‑Premise significa che per mancanza di capacità saltano patch, rotazione delle chiavi o test di RESTore, il rischio di compliance diventa rapidamente una questione di management.

Modelli decisionali tipici e opzioni ibride sensate

Nella pratica raramente è bianco o nero. Spesso si ottengono modelli robusti attraverso combinazioni:

• SaaS con rigoroso controllo di identità e dati: SSO/MFA obbligatori, modello di ruoli RESTrittivo, export verso SIEM, regole chiare per subprocessor, residenza dei dati fissata contrattualmente.
• On‑Premise per processi core con elevata esigenza di protezione: quando la sovranità dei dati e la prossimità all’integrazione prevalgono e disponete della maturità operativa.
• Ibrido: i dati sensibili RESTano on‑prem (ad es. in una conservazione dati interna), il SaaS fornisce workflow/UX; le interfacce vengono progettate in modo da permettere la minimizzazione dei dati e la pseudonimizzazione.

Per l’approvvigionamento è importante: l’ibrido non è una via d’uscita dalla responsabilità, ma aumenta la complessità di integrazione e governance. In compenso può segmentare i flussi di dati in modo da ridurre i rischi di compliance.

Documento decisionale: modello di scoring con accettazione del rischio

Per le decisioni degli organi collegiali è utile uno scoring semplice, che non illuda che tutto sia esattamente misurabile. È collaudata una scala 0–3 per dimensione (0 = non soddisfatto, 3 = completamente soddisfatto) più criteri obbligatori. Dimensioni tipicamente ponderate in ambito compliance/sovranità dei dati:

• Residenza dei dati e controllo sui subprocessori
• Titolarità delle chiavi (BYOK/HYOK) e evidenze di cifratura
• Auditabilità (log, report, report di verifica indipendenti)
• Identity & Access (capacità SSO/MFA/PAM)
• BCP/DR (RTO/RPO, prove di ripristino)
• Capacità di exit (export, cancellazione, portabilità)
• Operatività (risorse, competenze, runbook, monitoring)

Importante è l’ultimo passo: se si sceglie un modello purché singole dimensioni non siano sufficientemente soddisfatte, è necessaria una accettazione del rischio documentata con piano di misure, Owner e scadenza. Senza questa disciplina il „SaaS vs. On‑Premise“ diventerà in seguito una contesa sulle responsabilità.

Conclusione: la scelta giusta è quella che sapete governare in modo dimostrabile

SaaS vs. On‑Premise non è una questione di fede, ma di controlli governabili. Il SaaS può supportare bene la compliance e la sovranità dei dati, se identità, logging, controllo dei subprocessori, gestione delle chiavi e pianificazione dell’exit sono regolati in modo chiaro. L’On‑Premise può fornire la massima sovranità su dati e controllo, ma richiede maturità nell’operazione, documentazione, disciplina di patching e test di ripristino.

Se adottate il quadro descritto qui – Minimum Controls, RACI, piano delle evidenze e capitolo sull’exit – otterrete una decisione che non solo suona bene in fase di acquisto, ma sostiene anche in audit e in caso di crisi.

Per questo tema sono rilevanti anche i requisiti di compliance. L’articolo inquadra questi aspetti in modo comprensibile e mostra a cosa pRESTare attenzione nella pratica quotidiana.