Modello di governance per le licenze software: ruoli, percorsi decisionali e livelli di escalation per i responsabili IT

Un modello di governance per le licenze software non è un documento da riporre nel cassetto, ma il manuale operativo su come la vostra azienda governa in modo affidabile i diritti d’uso (ossia le installazioni, gli accessi e le modalità di esercizio consentiti contrattualmente). In assenza di ruoli chiari e percorsi decisionali si manifestano in pratica tre danni tipici: costi inutili per acquisti duplicati e metriche errate, rischi di compliance in caso di vendor-audit (verifiche del fornitore) e attriti operativi perché gli amministratori non sanno chi approva cosa e quali evidenze devono essere archiviate.

Il nucleo di una governance delle licenze funzionante è semplice: chi decide cosa, su quale base, in quale lasso di tempo e con quale escalation, quando mancano informazioni o aumentano i rischi. Il RESTo è cura coerente dei dati, controlli tracciabili e un processo che si integri nei flussi di ticketing e di approvvigionamento. Questo contributo fornisce una struttura attuabile per la Direzione IT, Compliance, Security e il Management – con modelli, ausili decisionali e prospettiva di audit.

Modello di governance per le licenze software nella pratica

In molte organizzazioni il «gestione delle licenze» esiste come miscela di Excel, approvazioni via e-mail e interlocuzioni sporadiche con l’ufficio acquisti. Questo funziona finché non si presenta un audit, un cambio di modello di licenza (per es. da licenza per dispositivo a licenza per utente) o una migrazione verso il cloud che mette sotto pressione il sistema. Allora emergono punti di rottura che quasi sempre hanno le stesse cause:

• Termini e metriche poco chiari: «utente», «dispositivo», «core», «istanza», «tenant», «named user» – senza glossario e responsabilità le decisioni diventano incoerenti. (Per esempio core è un nucleo di CPU e spesso la base per la licenza dei server.)
• Responsabilità distribuita senza diritto decisionale: l’operazione vede le installazioni, gli acquisti vedono i contratti, le unità di business ordinano, la Compliance verifica a campione – ma nessuno è «Accountable» per il risultato complessivo.
• Assenza di evidenza documentale: anche se siete correttamente licenziati, fallite in un audit per mancanza di evidenze: assegnazione degli utenti, protocolli di deprovisioning, versioni contrattuali, prove di migrazione.
• Le eccezioni diventano la regola: «solo velocemente per il progetto», «solo temporaneamente», «solo per test» – senza data di scadenza, obbligo di ripristino e controllo RESTano sovrautilizzi permanenti.
• Focus sugli strumenti invece che sul processo: gli strumenti SAM (Software Asset Management) aiutano, ma senza governance i dati non vengono mantenuti, le eccezioni non vengono decise e le approvazioni non sono documentate.

Un modello di governance solido affronta esattamente questi punti di rottura: rende le decisioni ripetibili, auditabili e operativamente realizzabili.

Elementi costitutivi di un modello di governance per le licenze software

Un modello completo è composto da sei elementi costitutivi che devono cooperare. Potete partire con un set «Minimum Viable Governance» e poi estenderlo.

• Policy-Set: regole vincolanti (per es. regole di acquisto e installazione, uso del cloud, policy open source, processo per le eccezioni).
• Ruoli & responsabilità: chi è responsabile, tenuto a rendere conto, consultato, informato (RACI).
• Percorsi decisionali: approvazioni definite in base a rischio, costi, classificazione dei dati e modalità operative.
• Livelli di escalation: quando da un ticket scatta una decisione, quando un’escalation al management, quando un blocco.
• Modello dei dati e delle evidenze: quali dati sono „system of record“ (sistema di riferimento), quali evidenze vengono conservate e per quanto tempo.
• Ritmo di controllo e reporting: KPI, revisioni, prontezza all’audit, gestione delle deviazioni.

Modello dei ruoli: chi deve essere coinvolto – e per cosa?

La governance delle licenze è trasversale. L’errore più comune è delegare tutto all’IT o all’ufficio acquisti. È utile una suddivisione per domini decisionali: contratto/diritti d’uso, utilizzo tecnico, rischio/conformità, budget/contributo al valore.

Ruoli principali (consigliati)

• License Owner (IT): responsabilità tecnica complessiva per la compliance delle licenze e il coordinamento. Questo ruolo dà priorità alla remediation (correzione) e decide in caso di conflitti tra esercizio e acquisti. In molte aziende è sensato come IT Asset Manager o responsabile SAM.
• Contract Owner (Acquisti/Vendor Management): gestisce la documentazione contrattuale, condizioni di prezzo e durata, finestre di disdetta, regole di True-up/True-down (adeguamento verso l’alto/verso il basso). Importante: il Contract Owner non decide da solo sulle metriche tecniche delle licenze.
• Service Owner (Esercizio IT): è responsabile del funzionamento stabile dei sistemi/servizi coinvolti e fornisce i dati tecnici di utilizzo (inventario, istanze, core dei server, virtualizzazione, cluster).
• Information Security Officer / delegato CISO: valuta i requisiti di sicurezza, la fattibilità delle opzioni di deployment (On-Prem, Cloud, SaaS) e controlla i rischi derivanti dalla shadow IT.
• Compliance/Protezione dei dati: verifica i requisiti normativi (es. conservazione, sedi dei dati, audit-trail), contribuisce alla produzione delle evidenze e ai processi di audit.
• Finance/Controlling: definisce la logica dei centri di costo, Showback/Chargeback (trasparenza dei costi interni/riaddebitamento) e supporta le analisi TCO (Total Cost of Ownership).
• Responsabili di funzione (Business Owner): sono responsabili del budget e del valore d’uso; confermano il fabbisogno, l’assegnazione degli utenti e il deprovisioning in caso di cambio ruolo.

Ruoli opzionali (a seconda di dimensioni/regolamentazione)

• Audit Liaison: punto di contatto centrale per gli audit dei fornitori, coordina scadenze, comunicazione e pacchetti di evidenze.
• Cloud Center of Excellence (CCoE): quando sono rilevanti molte metriche cloud (Tenant, Subscription, chiamate API).
• Consulenza legale: per metriche complesse, questioni di responsabilità, clausole di audit, controllo delle esportazioni.

Modello RACI: definire chiaramente le responsabilità

Una matrice RACI impone chiarezza: Responsible (esecutore), Accountable (responsabile, decisore finale), Consulted (coinvolto), Informed (da informare). È fondamentale: per ogni tema esattamente una „A“.

RACI – Modello di governance per le licenze software (struttura esemplificativa)

Tema / Attività                               | License Owner | Service Owner | Acquisti/Contract | Security | Compliance/DSB | Finance | Reparto
-----------------------------------------------|-------------|--------------|------------------|---------|----------------|---------|-----------
Redigere/modificare la politica di licenza (Policy) | A           | C            | C                | C       | C              | C       | I
Gestire un inventario supportato da tool (Discovery) | C           | A/R          | I                | I       | I              | I       | I
Interpretare le metriche di licenza (es. Core)     | A/R         | C            | C                | C       | C              | I       | I
Verificare la richiesta di acquisto (software standard)   | A           | C            | R                | C       | C              | C       | R
Autorizzazione di deroga (es. test, temporanea)    | A           | R            | C                | C       | C              | I       | R
Deprovisioning in caso di uscita/cambio di ruolo      | A           | R            | I                | I       | I              | I       | R
Coordinare la risposta ad audit (Vendor Audit)     | A           | C            | C                | C       | C              | I       | I
Rapporto trimestrale: Compliance & costi            | A/R         | C            | C                | C       | C              | C       | I
Escalation per rischio/sovrautilizzo              | A           | R            | C                | C       | C              | C       | I

Consiglio pratico: archiviate la RACI come documento controllato (versioning) e rispecchiate le responsabilità nelle categorie dei ticket e nei moduli. Quando RACI e ticket divergono, vince sempre il ticket — e la governance perde.

Percorsi decisionali: approvazioni basate sul rischio invece che sullintuizione

Un errore comune è avere un processo di approvazione uniforme per tutto. È preferibile un modello di approvazione basato sul rischio che consideri costi, impatto sulla sicurezza e complessità delle licenze. Obiettivo: bassa attrito nei casi standard, controllo rigoroso per casi costosi o critici per audit.

Criteri decisionali collaudati

• Costi e vincoli: durata contrattuale, finestre di disdetta, quantitativi minimi, clausole di adeguamento dei prezzi.
• Complessità delle metriche di licenza: Core/Socket/Cluster, ambienti virtuali, Multiplexing, accesso indiretto (es. accessi tramite interfacce che possono essere soggetti a licenza).
• Modalità di deployment: On-Prem, IaaS, PaaS, SaaS; per il SaaS spesso Identity/SSO e Offboarding sono leve di compliance.
• Classificazione dei dati: dati personali, segreti commerciali, dati soggetti a regolamentazione.
• Impatto operativo: cicli di patch e release, EOL/EOS (End of Life/End of Support), dipendenze dalle piattaforme.
• Esposizione ad audit: storico del fornitore, clausole di audit, punti critici noti nel modello di licenza.

Percorso di approvazione pragmatico (3 livelli)

• Livello 1 – Standard: approvato tramite voci di catalogo predefinite (es. Office-Add-on, Standard-Client). Responsabili: Reparto + IT (License Owner), Documentazione: ticket + assegnazione in IAM (Identity and Access Management).
• Livello 2 – Controllato: per costi più elevati o metriche più complesse. Verifica aggiuntiva da parte del Service Owner e della Security. Documentazione: valutazione rapida del rischio + controllo delle metriche.
• Fase 3 – Critica: piattaforme strategiche, sistemi rilevanti per audit o regolamentazione. Decisione nel Board di governance delle licenze (vedi sotto) con Acquisti, Compliance, Sicurezza, Direzione IT. Prova: verbale della decisione, revisione contrattuale, piano di uscita.

Board di governance: piccolo organismo, agenda chiara, timebox rigide

Per le decisioni di fase 3 e i conflitti ricorrenti vale la pena istituire un Board di governance delle licenze. Non si tratta di un progetto di ampia portata: 30–45 minuti ogni due–quattro settimane spesso sono sufficienti, se il lavoro preparatorio è fatto. È importante un’agenda fissa, altrimenti diventa un club di discussione.

Agenda minima (ripetibile)

• Deviazioni: Dove siamo sovrautilizzati/sotto-licenziati o abbiamo lacune nei dati?
• Eccezioni: Quali autorizzazioni temporanee stanno scadendo? Cosa verrà dismesso?
• Contratti & rinnovi: Cosa deve essere deciso entro 90/180 giorni (finestra di disdetta)?
• Prontezza per l’audit: I pacchetti di evidenza sono completi? Quali controlli sono dovuti?
• Modifiche tecniche: Virtualizzazione, cluster, migrazioni cloud con impatto sulle licenze.

Livelli di escalation: quando da «ticket» diventa «rischio»

Escalation non significa «alzare la voce», ma ristabilire la capacità decisionale quando tempo, rischio o costi lo impongono. Definite i livelli di escalation in modo che si integrino nei processi di incident e change.

Modello di escalation collaudato (E0–E3)

• E0 – Risolvibile a livello operativo: mancano assegnazioni, lista utenti non chiara, duplicato nell’inventario. Obiettivo: chiarimento da parte del Service Owner/License Owner entro SLA definite (es. 5 giorni lavorativi).
• E1 – Deviazione di compliance senza pressione di audit acuta: si rileva sovrautilizzo, ma nessuna notifica di audit. Piano di azione con scadenza, decisione sul budget preparata.
• E2 – Rischio di audit/contrattuale: notifica di audit, scadenza in corso, o clausola contrattuale minacciata (es. ri-licenza con penale). Audit Liaison + decisione del Board, immediata conservazione delle evidenze.
• E3 – Rischio critico / Stop: rischio massiccio (legale/finanziario) o shadow-IT critica per la sicurezza. Misure immediate: stop agli acquisti per i prodotti coinvolti, blocchi tecnici (es. liste di blocco/proxy), decisione del management per la gestione del rischio.

Importante: le escalation richiedono modelli decisionali predefiniti, altrimenti il livello si disperde nelle riunioni. I prossimi paragrafi forniscono la struttura necessaria.

Prospettiva audit: quali evidenze vogliono effettivamente vedere gli auditor

Gli audit dei vendor seguono spesso uno schema: il produttore richiede una vista Entitlement (quali diritti avete contrattualmente) e una vista Deployment-/Usage (come viene effettivamente utilizzato). La vostra governance deve unire entrambe le viste – e farlo in forma riproducibile.

Evidenze tipiche (lista di controllo pratica)

• Contratti & diritti: contratti firmati, ordini, certificati di licenza, emendamenti, definizioni delle metriche, accordi di supporto.
• Dati di asset e inventario: inventario di dispositivi e server, topologia di virtualizzazione, sottoscrizioni cloud, assegnazione del software agli asset.
• Dati di identità: elenchi utenti da IAM/HR (Joiner/Mover/Leaver), appartenenze ai gruppi, log SSO, modelli di ruolo.
• Prove di change: quando i sistemi sono stati migrati, scalati, dismessi? Ticket di change, finestre di manutenzione, approvazioni.
• Eccezioni & remediation: deviazioni approvate e con scadenza, piani di azione, protocolli di disinstallazione/deprovisioning.
• Interpretazione documentata: se le metriche sono complesse: interpretazione scritta, concordata con acquisti/ufficio legale, in modo da poter argomentare in modo coerente durante l’audit.

Audit-Readiness non significa avere tutto perfetto in ogni momento. Significa: potete consegnare in tempi brevi pacchetti affidabili e verificabili, senza azioni frenetiche di raccolta dati nei reparti.

Modello dei dati e „System of Record“: senza fonti affidabili non c’è governance

In ambiti di licenze la governance spesso fallisce per questioni di dati: quale fonte è autorevole? HR, IAM, CMDB (Configuration Management Database), Endpoint-Management, portale cloud, SAM-Tool? Definite per dominio dati una fonte primaria e stabilite le procedure di riconciliazione.

Modello dati minimo (cosa vi serve almeno)

• Catalogo prodotti: denominazione univoca del prodotto, produttore, metrica di licenza, versione, stato di supporto, clausole critiche.
• Entitlements: diritti acquistati, periodi di validità, riferimento contrattuale, assegnazione alle unità organizzative.
• Deployments/Nutzung: installazioni/istanze, assegnazione utenti, percorsi di accesso (anche tramite interfacce), contesto ambientale (Prod/Test/Dev).
• Regole di assegnazione: come da „utilizzo“ si determina un „utilizzo soggetto a licenza“ secondo la prospettiva contrattuale.
• Eccezioni: motivazione, approvatore, data di scadenza, punto di controllo, responsabile del ripristino.

Esempio: regola di policy semplice per eccezioni a tempo determinato

Policy: Eccezioni di licenza a tempo determinato

- Ogni eccezione richiede:
  - Motivazione aziendale
  - Valutazione del rischio (Security/Compliance)
  - Data di scadenza (max. 90 giorni)
  - Responsabile del ripristino (Nome/Ruolo)
  - Evidenza su come viene verificato il ripristino

- Senza data di scadenza nessuna approvazione.
- Rinnovo solo dopo nuova verifica e approvazione del Board a partire dal 2° rinnovo.
- Le eccezioni sono riportate mensilmente (numero, scadute, classe di rischio).

Il punto di forza di regole di questo tipo: sono semplici, misurabili e conducono automaticamente a percorsi decisionali chiari.

Controlli in esercizio: come la governance si integra in ticket, change e IAM

La governance delle licenze è efficace se integrata nei processi operativi esistenti. Tre punti di integrazione offrono di solito la leva maggiore:

1) IAM e processi HR (Joiner/Mover/Leaver)

Molti modelli di licenza dipendono dalle persone (Named User, Premium-Rollen). In questo caso l’offboarding è il punto di controllo critico. Collegate l’assegnazione delle licenze a ruoli/gruppi, non a concessioni manuali individuali. E definite chi conferma la necessità funzionale (reparto di competenza) e chi la applica tecnicamente (IT).

2) Processi di change e release

Modifiche a virtualizzazione, dimensione dei cluster, assegnazione delle CPU, strutture multi-tenant o sottoscrizioni cloud possono cambiare gli obblighi di licenza. Nei template di change dovrebbe perciò essere presente un campo obbligatorio: „Impatto sulla licenza verificato?“ incluso il responsabile.

3) Approvvigionamento e catalogo software

Se i dipendenti acquisiscono licenze direttamente con carta di credito, tramite marketplace o tramite shadow-IT, perdete il controllo. Un catalogo centrale con alternative chiare e un percorso standard rapido riduce la shadow-IT meglio dei soli divieti. Importante: il percorso standard deve essere più veloce della scorciatoia.

Regolamentazione e requisiti interni: cosa va tipicamente considerato

La governance delle licenze coinvolge diverse dimensioni obbligatorie. Senza sostituire una consulenza legale, queste richieste vanno verificate sistematicamente:

• Protezione dei dati (DSGVO): trattamento per conto, trasferimenti di dati, controlli di accesso e politiche di cancellazione – particolarmente rilevante per SaaS e dati di telemetria.
• Sicurezza delle informazioni: requisiti minimi per l’autenticazione (es. MFA), registrazione dei log, gestibilità delle patch, gestione delle vulnerabilità, configurazione sicura.
• Conservazione & tracciabilità: audit-trail per decisioni e change; tempi di conservazione per contratti, ordini e evidenze.
• Controlli finanziari: principio delle quattro mani per costi elevati, limiti di budget, tracciabilità dei rinnovi.
• Controllo export/Sanzioni (a seconda di settore/area): può essere rilevante per determinati prodotti/fornitori, soprattutto in gruppi internazionali.

Implementazione pratica: radicate questi punti come domande di verifica nelle approvazioni di livello 2 e livello 3, non come generici „da notare“.

Supporto alle decisioni: prioritizzazione per costi, rischio e impatto operativo

La direzione IT necessita di priorità, non solo di trasparenza. Uno schema semplice ed efficace è la combinazione di rischio di licenza (Audit/Compliance) e rischio operativo (Disponibilità/Sicurezza) più pressione sui costi (Rinnovo/Scalabilità). Da ciò emergono aree di intervento chiare:

• Forte pressione di audit + costi elevati: chiarimento immediato delle metriche, pulizia dei dati, eventuale preparazione alla negoziazione e controllo rapido dell’utilizzo (Deprovisioning).
• Elevata pressione operativa + complessità delle licenze: Change‑Stop per modifiche che incidono sulle licenze finché interpretazione e misurabilità non sono chiare; altrimenti i team incorporano involontariamente condizioni che richiedono una retro‑licenza.
• Ampia Shadow‑IT: focus sul catalogo, percorsi standard rapidi, rilevazione tecnica (CASB/Proxy/Endpoint) e sanzioni/comunicazione chiare.
• Sottoliscenziazione senza urgenza: piano d’azione, ma con evidenze solide; altrimenti il tema costerà caro al prossimo audit.

Modelli e checklist per l’attuazione rapida

I seguenti modelli sono volutamente sintetici, in modo da poter essere trasferiti in sistemi ticket, pagine Word/Confluence o strumenti GRC.

Checklist: Nuovo impiego software (Fase 2/3)

• Necessità & ambito: chi lo utilizza, quanti utenti/server, quali ambienti (Prod/Test/Dev), quale durata?
• Metrica di licenza: in base a quali unità si fattura/licenzia? Come viene misurato (fonte)?
• Architettura tecnica: modalità di deployment, multitenancy, cluster/failover, interfacce (API), automazione.
• Requisiti di sicurezza: autenticazione, modello di ruoli, logging, processo di patch, gestione delle vulnerabilità e delle configurazioni.
• Protezione dei dati/Conformità: tipologie di dati, ubicazione dei dati, trattamento per conto (DPA), piano di cancellazione, tracciabilità delle evidenze.
• Gestione operativa: monitoring, backup/RESTore, responsabilità, EOL/EOS, piano di emergenza.
• Piano di uscita: come usciamo (export dei dati, scadenze, dipendenze), quali costi si generano al cambio?
• Decisione: livello di approvazione, autorizzatore, validità, condizioni.

Checklist: Revisione mensile della governance delle licenze

• Top‑10 prodotti per costi e/o esposizione ad audit
• Eccesso di utilizzo / Sottoliscenziazione: stato, cause, azioni, scadenze
• Eccezioni: nuove, in scadenza, in ritardo
• Rinnovi a 90/180 giorni: necessità decisionale, situazione dati, strategia di negoziazione
• Indicatori di Shadow‑IT: nuovi domini, nuove sottoscrizioni SaaS, installazioni sconosciute
• Modifiche all’infrastruttura con impatto sulle licenze (cluster, cloud, VDI)

Modello: Nota di escalation (per E2/E3)

Nota di escalation – rischio licenza

1) Motivo / Trigger:
   - (es. notifica di audit, rilevato eccesso di utilizzo, clausola contrattuale)

2) Prodotti/servizi interessati:
   - Prodotto:
   - Service Owner:
   - Riferimento contrattuale:

3) Base fattuale (stato attuale):
   - Entitlements (diritti acquistati):
   - Utilizzo misurato (fonte/data):
   - Lacune nei dati / assunzioni:

4) Valutazione del rischio:
   - Finanziario (range, se possibile):
   - Conformità/Audit:
   - Operatività/Sicurezza:

5) Proposta di azione (opzioni):
   A) Misure immediate (0–7 giorni):
   B) Breve termine (fino a 30 giorni):
   C) Medio termine (fino a 90 giorni):

6) Necessità decisionale:
   - Chi deve decidere (RACI – A):
   - Scadenza:

7) Evidenze / Allegati:
   - (estratto contrattuale, report inventario, lista IAM, ticket di change)

Tooling: Cosa dovRESTe automatizzare – e cosa no

L’automazione è conveniente dove i dati cambiano frequentemente e la manutenzione manuale fallisce: assegnazioni utenti, discovery, deprovisioning, conciliazione delle sottoscrizioni cloud. Meno sensato è automatizzare l’interpretazione di clausole contrattuali complesse – qui servono decisioni documentate, non una black box.

Automatizzare (alto beneficio, effetti collaterali limitati)

• Confronto HR/IAM ↔ assegnazione licenze (alla partenza dell’utente le licenze vengono revocate)
• Rilevamento di installazioni/agenti e assegnazione agli asset
• Report regolari: sovrautilizzo, installazioni non assegnate, utenti inattivi
• Promemoria per date di scadenza delle eccezioni e finestre di rinnovo

Lasciare volutamente manuale (ma standardizzare)

• Interpretazione delle metriche (documentare per iscritto, versionare)
• Approvazione delle eccezioni critiche
• Comunicazione per gli audit (un canale, responsabile chiaro)

Conclusione: la governance è un modello di gestione, non un riflesso di controllo

Un modello di governance per le licenze software ha successo quando accelera le decisioni, rende i rischi visibili e mantiene gli audit pianificabili – senza bloccare l’operatività. Il passo decisivo non è lo strumento, ma la chiara definizione dei ruoli (RACI), delle approvazioni basate sul rischio e dei livelli di escalation. Iniziate con il minimo: ruoli chiave definiti, un percorso di approvazione a tre livelli, un processo per le eccezioni con data di scadenza e una revisione mensile. Quando questo meccanismo funziona, è possibile ampliare il modello dei dati, l’automazione e la struttura del board – e la gestione delle licenze passa dall’antincendio permanente a un processo operativo controllabile.

Per questo ambito sono importanti anche la governance della gestione delle licenze e il Software Asset Management (SAM). Il contributo inquadra questi aspetti in modo chiaro e mostra cosa conta nella pratica quotidiana.