A cura dell’Avv. Carmine Coviello – aggiornato al 6 ottobre 2026.
Risposta breve: un audit delle licenze software verifica quali programmi, servizi SaaS e componenti open source usa realmente l’impresa, chi può utilizzarli, su quanti dispositivi o ambienti, per quali attività e con quali prove contrattuali. L’obiettivo non è soltanto evitare usi eccedenti: serve anche a eliminare abbonamenti inutilizzati, ricostruire la titolarità del software sviluppato su misura, preparare una due diligence e rendere gestibile l’uscita da un fornitore.
La conformità non si dimostra con una fattura isolata. Occorre collegare inventario tecnico, ordini, condizioni di licenza, assegnazioni agli utenti, contratti con sviluppatori e log di utilizzo. Per questo l’audit deve coinvolgere ufficio legale, IT, acquisti, amministrazione e responsabili delle unità operative.
Che cos’è un audit delle licenze software?
È una verifica documentale e tecnica del diritto dell’organizzazione a installare, accedere, riprodurre, modificare o distribuire software. Il perimetro comprende applicazioni installate, macchine virtuali, servizi cloud, account SaaS, librerie incorporate nei prodotti, codice commissionato a terzi e strumenti utilizzati da consulenti o società del gruppo.
La base giuridica non coincide con il solo contratto. La Direttiva 2009/24/CE sulla protezione giuridica dei programmi per elaboratore tutela i programmi mediante il diritto d’autore e disciplina, tra l’altro, gli atti riservati, l’uso da parte del legittimo acquirente, la copia di riserva e l’interoperabilità. In Italia, la Legge 22 aprile 1941, n. 633 nel testo vigente include i programmi per elaboratore tra le opere protette.
Il punto operativo è semplice: acquistare l’accesso a un programma non significa acquistare automaticamente il codice o tutti i diritti patrimoniali. Portata, durata e trasferibilità dipendono dalla legge applicabile e dalle condizioni negoziate.
Quali software devono entrare nel perimetro?
| Categoria | Prova da raccogliere | Rischio tipico |
|---|---|---|
| Software proprietario installato | Ordine, EULA, numero licenze, dispositivi e utenti | Installazioni o accessi oltre il limite |
| SaaS e cloud | Contratto, piano, account, società abilitate e rinnovi | Account inattivi, uso da affiliate non incluse, rinnovi automatici |
| Open source | Elenco componenti, versione, licenza, notice e modalità di distribuzione | Obblighi di attribuzione o messa a disposizione non gestiti |
| Software sviluppato su misura | Contratto, specifiche, verbali, repository e cessioni | Diritti rimasti allo sviluppatore o a un subfornitore |
| Strumenti gratuiti o trial | Termini d’uso e prova della finalità consentita | Uso commerciale escluso o periodo di prova scaduto |
Un inventario efficace non si limita alle applicazioni approvate. Deve cercare anche strumenti installati autonomamente dai dipendenti, plug-in, librerie scaricate dai repository, account acquistati con carte aziendali e servizi attivati direttamente dai reparti. Questo fenomeno, spesso definito “shadow IT”, rende incompleta qualsiasi verifica basata solo sulla contabilità.
Come si svolge l’audit in otto fasi?
1. Definire società, sedi e ambienti
Il perimetro deve chiarire quali entità del gruppo, dipendenti, collaboratori, dispositivi, server e ambienti cloud rientrano nella verifica. Una licenza intestata alla capogruppo non autorizza necessariamente tutte le controllate.
2. Costruire l’inventario tecnico
Si raccolgono applicazioni, versioni, installazioni, utenti nominativi, accessi concorrenti, istanze virtuali e componenti incorporate. Una software bill of materials può aiutare a censire le dipendenze, ma non prova da sola che le condizioni di licenza siano rispettate.
3. Ricostruire il fascicolo contrattuale
Per ogni prodotto servono contratto, ordine, condizioni accettate, fatture, rinnovi, allegati tecnici, corrispondenza rilevante e prove di dismissione. Per rapporti transfrontalieri è utile coordinare territorio, legge applicabile, assistenza e restrizioni: la guida sulla licenza software internazionale approfondisce questo profilo.
4. Confrontare diritti acquistati e uso effettivo
Il confronto va fatto metrica per metrica: utente, dispositivo, processore, istanza, volume, fatturato, ambiente di produzione o sviluppo. Le definizioni contrattuali contano più delle etichette commerciali e possono cambiare tra versioni o rinnovi.
5. Verificare titolarità e catena dei diritti
Nel software su misura occorre distinguere proprietà del codice preesistente, sviluppi realizzati per il cliente, componenti di terzi, documentazione e diritti sulle modifiche. NDA e obblighi di riservatezza non sostituiscono una disciplina espressa dei diritti patrimoniali. È utile coordinare questa verifica con la guida sugli NDA nei rapporti con i fornitori.
6. Classificare gli scostamenti
Ogni anomalia va descritta con prova, impatto, responsabile e rimedio. Conviene separare: possibile uso senza copertura; documentazione mancante; costo inefficiente; rischio open source; dipendenza dal fornitore; problema di sicurezza o continuità.
7. Correggere senza perdere le prove
Prima di cancellare account o disinstallare programmi si conserva la fotografia dello stato rilevato. Le azioni possono includere riallocazione di licenze, acquisto integrativo, rinegoziazione, sostituzione del componente, regolarizzazione documentale o cessazione controllata.
8. Istituire un controllo periodico
L’audit diventa utile nel tempo solo se rinnovi, onboarding, offboarding, acquisti e sviluppo software alimentano un registro aggiornato. Un controllo trimestrale leggero può prevenire la ricostruzione emergenziale in occasione di una contestazione o di un’operazione societaria.
Licenza proprietaria, SaaS, open source e sviluppo custom
Software proprietario. Il controllo riguarda installazioni, utenti e parametri di calcolo. Devono essere lette anche le clausole di audit del fornitore: preavviso, accesso ai sistemi, riservatezza dei dati raccolti, soggetto verificatore e gestione delle differenze.
SaaS. Non essendoci necessariamente un’installazione locale, il rischio si sposta su account, identità, società abilitate, volumi, export dei dati e rinnovo. Il contratto dovrebbe chiarire restituzione o cancellazione dei dati, formati di esportazione e assistenza alla migrazione.
Open source. “Gratuito” non significa privo di condizioni. Occorre identificare la licenza della versione effettivamente utilizzata, distinguere uso interno e distribuzione e verificare notice, attribuzioni e obblighi collegati alla modifica o alla combinazione. Le conclusioni dipendono dal componente e dal modo in cui viene impiegato.
Software custom. Il rischio maggiore può essere l’assenza di una catena documentata dei diritti. Vanno verificati dipendenti, freelance, software house, subappaltatori e componenti preesistenti. Il repository e i verbali di consegna sono prove importanti, ma non sostituiscono le clausole di cessione o licenza.
Quali clausole contrattuali meritano attenzione?
- Soggetti autorizzati: dipendenti, consulenti, affiliate, clienti o outsourcer.
- Metrica: utenti nominativi o concorrenti, dispositivi, server, processori, consumi o transazioni.
- Ambiente: sviluppo, test, disaster recovery e produzione.
- Territorio e trasferimento: uso all’estero, cessione, change of control e riorganizzazioni.
- Audit del fornitore: preavviso, metodo, riservatezza, costi e contestazione dei risultati.
- Proprietà degli sviluppi: codice preesistente, personalizzazioni, documentazione e miglioramenti.
- Open source e terze parti: elenco, approvazione, garanzie e aggiornamenti.
- Continuità ed uscita: livelli di servizio, escrow quando pertinente, portabilità e cancellazione dei dati.
Queste verifiche assumono maggiore importanza quando l’impresa utilizza sistemi generativi o integra contenuti prodotti con strumenti di IA. L’approfondimento sui controlli contrattuali e probatori per i contenuti AI aiuta a organizzare ruoli, input, output e autorizzazioni. Sul sito istituzionale è disponibile anche l’area dedicata a intelligenza artificiale e proprietà intellettuale.
Perché l’audit conta in una due diligence?
Prima di un investimento o di una cessione, l’acquirente vuole sapere se il software essenziale può continuare a essere usato e se l’impresa possiede davvero gli sviluppi dichiarati. Contratti non trasferibili, licenze intestate a persone fisiche, dipendenze open source non censite e accessi condivisi possono influire su garanzie, condizioni sospensive e prezzo.
La checklist sulla due diligence IP e sulla data room mostra come organizzare titolarità, licenze e rimedi prima del processo. Per prodotti digitali è opportuno coordinare anche la protezione del segno: la guida alle Classi di Nizza per software, app e SaaS distingue le classi rilevanti per software scaricabile, servizi commerciali, telecomunicazioni, formazione e SaaS.
Cosa fare se emerge una non conformità?
Non conviene reagire con dichiarazioni affrettate o cancellazioni indiscriminate. Occorre preservare contratti, log e inventari; verificare la metrica; distinguere errore tecnico, carenza documentale e uso eccedente; stimare le opzioni di regolarizzazione; centralizzare i contatti con il fornitore. Se è arrivata una richiesta di audit, vanno esaminati poteri contrattuali, perimetro delle informazioni richieste e obblighi di riservatezza prima di consegnare dati.
Il video dello Studio Copyright: come funziona offre un inquadramento divulgativo sul diritto d’autore e sulla possibilità di concedere in licenza i diritti patrimoniali, con un riferimento espresso anche al software.
Checklist essenziale per l’impresa
- Esiste un inventario aggiornato di software, SaaS e componenti open source?
- Ogni voce è collegata a contratto, ordine, versione e responsabile interno?
- Utenti, dispositivi, ambienti e società del gruppo rispettano il perimetro?
- Gli account di dipendenti cessati sono stati revocati o riallocati?
- Il software custom ha una catena documentata dei diritti?
- Sono censiti componenti di terzi e relative notice?
- Rinnovi automatici, variazioni di prezzo e diritti di recesso sono monitorati?
- Sono definite esportazione e cancellazione dei dati alla fine del rapporto?
- È pronta una procedura interna per eventuali richieste di audit?
Domande frequenti
Una fattura dimostra la conformità della licenza?
Dimostra l’acquisto, ma non sempre l’esatto diritto d’uso. Occorre collegarla alla versione delle condizioni applicabili, alla metrica acquistata e agli utenti o ambienti effettivi.
Il software open source può essere usato in un prodotto commerciale?
Spesso sì, ma con condizioni che cambiano a seconda della licenza e della modalità d’integrazione o distribuzione. La verifica deve essere fatta sul componente e sulla versione concreta, non sull’etichetta generica “open source”.
Il cliente possiede automaticamente il software commissionato?
Non è prudente presumere una titolarità integrale. Il contratto dovrebbe disciplinare codice preesistente, sviluppi, documentazione, componenti di terzi, modifiche e diritti di utilizzo o cessione.
Quando conviene eseguire l’audit?
Prima di rinnovi rilevanti, migrazioni cloud, fusioni, investimenti, acquisizioni, lancio di un prodotto software o risposta a una richiesta del fornitore. È utile anche come controllo periodico.
Un inventario automatico è sufficiente?
No. Gli strumenti tecnici rilevano installazioni e componenti, ma il giudizio di conformità richiede interpretazione dei contratti, verifica della titolarità e confronto con l’uso organizzativo.
Richiedere un audit delle licenze software
Per ricostruire inventario, contratti, titolarità del codice e rischi prima di un rinnovo, di una contestazione o di un’operazione societaria, è possibile richiedere una consulenza per l’audit delle licenze software e della documentazione IP.
Le informazioni sono generali e non sostituiscono l’esame delle licenze, dei contratti e dell’architettura tecnica del caso concreto.