Due diligence tecnica: 7 ambiti che investitori e fondatori devono verificare

Una checklist rigorosa di due diligence tecnica deve verificare sette ambiti: codice e architettura, infrastruttura e scalabilità, sicurezza e conformità, dati e sistemi di IA, team e processi, proprietà intellettuale e integrazioni. Il risultato non è mai un’etichetta di promosso o bocciato. È un registro dei rischi, un piano di interventi correttivi e un giudizio di affidabilità legato all’operazione. Si parte chiedendo l’accesso ai repository, un diagramma dell’architettura, i log degli incidenti recenti e qualsiasi valutazione d’impatto sulla protezione dei dati agli atti.

---

In breve:

• Una verifica seria della qualità del codice richiede accesso ai repository, ai report sulla copertura dei test, ai log di rilascio e ai diagrammi aggiornati dell’architettura, non a dei riassunti.

• La valutazione dell’infrastruttura deve concentrarsi su scalabilità, test dei backup, piani di disaster recovery e storico degli incidenti, con la prova che le procedure sono state testate.

• La due diligence sulla sicurezza richiede risultati dei penetration test, pratiche di cifratura, politiche di accesso e prove di un patching attivo, oltre alle valutazioni d’impatto sulla privacy quando servono.

• Valutare i sistemi di IA significa verificare inventari dei dati, documentazione dei modelli, monitoraggio della deriva e processi di supervisione umana, non solo le capacità dichiarate.

• Capire la maturità del team vuol dire analizzare le dipendenze da singole persone, l’andamento della retention, la frequenza dei rilasci, i piani di risposta agli incidenti e la gestione del debito tecnico.

---

Valutare la qualità del codice e l’architettura di sistema

Una buona architettura lascia tracce. Cerca un design modulare, una copertura dei test che significhi qualcosa, pipeline automatizzate di build e rilascio, una gestione pulita delle dipendenze e l’abitudine alla revisione del codice, non una regola che esiste solo sulla carta. Una documentazione che corrisponde davvero al sistema in esecuzione è più rara di quanto dovrebbe, e la sua assenza è già di per sé un segnale.

Chiedi l’accesso diretto, non una presentazione che riassume il codice. Gli artefatti giusti ti dicono più in un’ora di quanto il racconto di un fondatore ti dica in un giorno.

• Accesso al repository con la cronologia dei commit, non solo un’istantanea esportata.

• Report dei test unitari e di integrazione con l’andamento della copertura nel tempo.

• Log CI/CD che mostrino la frequenza delle build e il tasso di fallimento.

• Diagrammi dell’architettura che rispecchino il sistema attuale, non la versione del pitch deck iniziale.

• Manifesti delle dipendenze come package-lock.json o go.sum, per avere visibilità sulla catena di fornitura.

• Pull request recenti e note di rilascio che mostrino come vengono rilasciate davvero le modifiche.

Un codice senza test automatici, con un unico rilascio monolitico o con dipendenze ferme da anni non è squalificante, ma cambia i costi e i tempi di qualsiasi roadmap post-acquisizione. Metti a budget il tempo per gli interventi correttivi invece di dare per scontato che basti una patch veloce a colmare il divario.

Infrastruttura, hosting e scalabilità sotto carico reale

La resilienza operativa è il punto in cui le promesse sulla carta incontrano la realtà più in fretta. Esamina l’architettura di hosting, se il sistema è distribuito su più zone di disponibilità o più regioni, come è configurato l’autoscaling e quanto l’azienda dipende da un singolo fornitore cloud o da un singolo ingegnere che conosce la configurazione. Il lock-in verso un fornitore non è automaticamente un male, ma deve essere un rischio noto e messo a prezzo, non una sorpresa.

Backup e disaster recovery meritano un esame specifico, perché sono l’ambito che più spesso viene descritto invece che dimostrato.

• I valori di recovery time objective e recovery point objective, con la prova che sono stati testati.

• Un piano di disaster recovery e runbook scritti, non solo la convinzione che qualcuno saprà cosa fare.

• Uno storico documentato degli incidenti, con cosa si è rotto e come è stato risolto.

• Dashboard di monitoraggio e obiettivi di servizio definiti.

• Postmortem recenti, che mostrino se il team impara dai guasti o li ripete.

Se un team non riesce a mostrarti un ripristino di backup testato o un postmortem recente, considera quella lacuna una voce di costo a breve termine, non una nota a piè di pagina. La nostra pagina dei casi studio raccoglie esempi di hosting su più sedi e di runbook operativi costruiti proprio per reggere questo tipo di esame.

Livello di sicurezza e conformità alla protezione dei dati

Le prove in materia di sicurezza devono essere concrete: report dei penetration test, risultati delle scansioni di vulnerabilità, politiche di gestione delle identità e degli accessi, pratiche di cifratura e una cadenza di patching davvero rispettata e non solo auspicata. Un team che non riesce a produrre un report di penetration test dell’ultimo anno, o che considera «non abbiamo subito violazioni» una prova di sicurezza, ti sta dicendo qualcosa di importante.

La conformità in materia di privacy va di pari passo con la sicurezza. L’EDÖB confirms that Swiss data protection law is technology-neutral e si applica pienamente ai sistemi di IA: i titolari del trattamento devono quindi integrare la protezione dei dati fin dalla progettazione e per impostazione predefinita, e possono dover svolgere una valutazione d’impatto formale per i trattamenti ad alto rischio. Verifica che esista una valutazione completata dove il volume o la sensibilità dei dati personali lo richiede, ed esamina i contratti con i responsabili del trattamento per le clausole sul trasferimento dei dati e sulla loro ubicazione.

• Report recenti di penetration test o di scansione delle vulnerabilità, con lo stato degli interventi correttivi.

• Politiche di gestione delle identità e degli accessi che definiscano chi può raggiungere i sistemi di produzione.

• Prova della cifratura dei dati a riposo e in transito.

• Una cadenza di patching documentata e la prova che venga rispettata.

• Una valutazione d’impatto sulla protezione dei dati dove ricorrono trattamenti ad alto rischio.

• Contratti con responsabili e sub-responsabili del trattamento che coprano il trasferimento di dati all’estero.

Si prevede che il European Cyber Resilience Act imponga obblighi di cybersicurezza lungo tutto il ciclo di vita ai prodotti con elementi digitali venduti nell’UE a partire all’incirca dal 2027. Se il prodotto dell’azienda target include software, elaborazione di dati da remoto o viene commercializzato nell’UE, aggiungi alla verifica un rapido controllo di applicabilità del CRA: il prodotto contiene elementi digitali, elabora dati da remoto ed è destinato alla distribuzione nell’UE?

Governance dei dati, analisi e controlli sui sistemi di IA

Le pratiche sui dati rivelano quanto un team sia davvero disciplinato. Chiedi un inventario dei dati, una politica di conservazione, un dizionario dei dati e set di dati di esempio che ti permettano di verificare le affermazioni invece di prenderle per buone. Un’azienda che non sa mostrare una mappa chiara di quali dati detiene e perché si porta dietro una responsabilità nascosta, a prescindere da cosa dica il suo pitch deck.

Le funzioni di IA richiedono un livello di esame a sé; strumenti come l’AI Overview Checker possono aiutare a ottimizzare la documentazione per le AI Overviews di Google. Chiedi la documentazione delle fonti dei dati di addestramento, eventuali model card che descrivano uso previsto e limiti, le metriche di validazione e il monitoraggio predisposto per intercettare la deriva del modello dopo il rilascio. La guida EFK’s audit approach for AI systems raccomanda di esaminare i sistemi di IA in tre fasi del ciclo di vita: pianificazione, sviluppo ed esercizio, con documentazione e monitoraggio richiesti lungo tutto il percorso e non solo al lancio.

• Un inventario dei dati che indichi cosa viene raccolto, dove risiede e per quanto tempo viene conservato.

• Un dizionario dei dati che colleghi i campi al loro significato per il business.

• Documentazione dei modelli con le fonti dei dati di addestramento e i limiti noti.

• Prove del monitoraggio della deriva ed eventuale passaggio di revisione umana per le decisioni automatizzate.

• Mappe della provenienza dei dati e log degli accessi che mostrino chi tocca i dati sensibili e quando.

La supervisione umana sugli output dell’IA è un controllo pratico che conviene verificare di persona, non accettare come semplice dichiarazione di principio: chiedi di vedere il flusso di validazione, non solo i numeri sull’accuratezza che ne derivano.

Valutare il team di sviluppo e il debito tecnico

La tecnologia dura quanto il team che la mantiene. Esamina l’organigramma alla ricerca di dipendenze da singole persone, l’andamento recente della retention e se i piani di assunzione corrispondono alla roadmap che l’azienda presenta agli investitori. Un sistema brillante mantenuto da un solo ingegnere insostituibile è un punto di rottura unico, non un patrimonio.

La maturità dei processi conta quanto il numero di persone. Guarda come avvengono le revisioni del codice, con che frequenza escono i rilasci, chi è responsabile della risposta agli incidenti e se esistono runbook per gli scenari che contano di più.

• Analisi dell’organigramma per individuare eventuali punti critici di rottura unici.

• Dati recenti su retention e turnover degli ingegneri, confrontati con i piani di assunzione.

• Prove di una pratica costante di revisione del codice, non un’eccezione occasionale.

• Frequenza dei rilasci e storico dei rollback degli ultimi mesi.

• Un processo documentato di risposta agli incidenti con responsabili nominati.

• Un elenco del debito tecnico con priorità e monitoraggio dei tempi di risoluzione.

Il debito tecnico in sé non è un campanello d’allarme: ogni sistema maturo ne porta un po’. Quello che conta è se il team sa nominarlo, quantificarlo e mostrare un piano credibile per ridurlo nel tempo.

Titolarità della proprietà intellettuale e rischi sulle licenze

Un investitore non può contare su codice che l’azienda non possiede davvero. Verifica che ogni ingegnere, dipendente o collaboratore esterno, abbia firmato un accordo di cessione che trasferisce i diritti di proprietà intellettuale all’azienda. Le cessioni mancanti sono una delle sorprese più frequenti e più costose che emergono a trattativa avanzata.

L’uso di open source merita un passaggio a parte. Esegui una scansione delle licenze su tutte le dipendenze e segnala qualsiasi condizione restrittiva, come gli obblighi copyleft che potrebbero costringere a divulgare codice proprietario.

• Contratti di lavoro e di collaborazione con clausole esplicite di cessione della proprietà intellettuale.

• Contributor license agreement per eventuali contributi esterni o della community.

• Un report di scansione delle licenze su tutte le dipendenze open source in uso.

• Note di copyright coerenti con la titolarità dichiarata.

• Contratti con fornitori e collaboratori esaminati per vincoli di cedibilità ed esclusiva.

• Eventuali brevetti depositati rilevanti per la tecnologia centrale.

Quando documentazione o codice riutilizzati sono coperti da una licenza share-alike come i Creative Commons BY-SA terms, accertati che l’azienda sia consapevole degli obblighi di attribuzione e riutilizzo che ne derivano.

Mappare la complessità delle integrazioni e le dipendenze esterne

Ogni integrazione esterna è una dipendenza che il team acquirente eredita. Costruisci un inventario completo dei servizi collegati, dai gestori dei pagamenti agli strumenti di analisi fino alle API interne, insieme alle condizioni contrattuali e alle garanzie di versioning di ciascuno. Un sistema che si appoggia in silenzio a una versione deprecata di una API è un costo di migrazione pronto a saltare fuori.

La resilienza in caso di guasto dice quanto l’elenco stesso delle integrazioni. Chiedi cosa succede quando un servizio di terze parti va giù: il sistema degrada in modo controllato, riprova con criterio oppure si blocca del tutto trascinandosi dietro altre funzioni?

• Un inventario completo delle integrazioni esterne con condizioni contrattuali e date di rinnovo.

• Specifiche delle API e impegni sul versioning per ogni dipendenza.

• Prove di logiche di ritentativo e di comportamenti di ripiego durante i disservizi di terze parti.

• Suite di test di integrazione che dimostrino i flussi end-to-end, non solo mock a livello di unità.

• Condizioni contrattuali di uscita nel caso in cui un rapporto con un fornitore debba chiudersi.

Un’azienda con una dozzina di integrazioni non documentate e senza logiche di ripiego non è per forza un cattivo investimento, ma il lavoro di migrazione e stabilizzazione va messo a prezzo nell’operazione, non scoperto dopo la chiusura.

Come condurre la verifica, dall’avvio al rapporto finale

Un processo strutturato evita che la due diligence tecnica si trasformi in una pesca a strascico senza fine. Il flusso qui sotto si adatta da uno sprint di due settimane a un incarico più lungo, a seconda delle dimensioni dell’operazione.

1. Firma un accordo di riservatezza e tieni una call di avvio per definire perimetro, tempi e chi, dalla parte dell’azienda target, risponderà alle domande.

2. Invia nella prima settimana una richiesta di documentazione ordinata per priorità: accesso ai repository, diagramma dell’architettura, log degli incidenti ed eventuali valutazioni d’impatto sulla protezione dei dati agli atti.

3. Nella seconda settimana chiedi materiali più approfonditi: scansioni delle licenze, report dei test, contratti con i fornitori e dettagli dell’organigramma.

4. Conduci una verifica tecnica diretta, affiancata da colloqui strutturati con il CTO, gli ingegneri di riferimento e chiunque sia responsabile di sicurezza o conformità.

5. Valuta ogni ambito con una griglia semplice a tre assi: se esistono prove, quanto sono solide e quale impatto sul business avrebbe una lacuna.

6. Componi un registro dei rischi e un piano di interventi correttivi, ordinati per gravità e costo stimato di risoluzione.

7. Consegna una sintesi dei rischi di una pagina per la direzione, sostenuta da un allegato tecnico, più un calendario degli interventi e, dove sono emerse lacune nella guida tecnica, l’opzione di una direzione tecnica ad interim.

Consiglio: Fai le stesse tre domande a ogni ingegnere che intervisti, non solo al CTO: cosa si rompe più spesso, cosa sistemeresti per primo con più tempo a disposizione e cosa temi di più che un revisore esterno possa trovare.

Il documento finale deve permettere a un investitore non tecnico di capire il livello di rischio in cinque minuti e, allo stesso tempo, dare a un lettore tecnico abbastanza materiale nell’allegato per verificare in autonomia ogni conclusione.

Come Ampersand affronta audit e responsabilità tecnica

Uno studio software specializzato svolge audit del software e due diligence tecnica da Zurigo, con ingegneri senior che guidano la verifica dal primo contatto fino al rapporto finale, invece di passarla a personale junior. Questa continuità conta, perché chi pone le domande nei colloqui è la stessa persona che poi deve difendere le conclusioni.

Due incarichi mostrano l’ampiezza di questo lavoro: Habitects AG, dove Ampersand si è occupata di tutto il lato tecnico di una piattaforma per la ristrutturazione di bagni fino alla fusione completa, e Repa Immobiliare, dove un portafoglio immobiliare è passato dalla carta a un software costruito per funzionare offline fin dalla progettazione. Entrambi hanno richiesto la stessa disciplina che pretende una due diligence tecnica: verificare ciò che esiste, documentare ciò che manca e costruire un piano credibile per andare avanti.

Davide Morotti

Come svolgere bene una due diligence tecnica

Eseguire questa checklist internamente richiede tempo di ingegneria vero, che la maggior parte dei fondatori e degli investitori non ha da parte, e una verifica fatta di corsa si lascia sfuggire proprio i problemi che diventano cari dopo la chiusura. Ampersand Labs si occupa di audit del software e di due diligence tecnica come servizio continuativo, con ingegneri senior che svolgono davvero il lavoro di analisi invece di delegarlo verso il basso.

L’incarico è adatto ai fondatori che preparano un round e vogliono sapere cosa troverà un acquirente prima che lo trovi, e agli investitori che hanno bisogno di una lettura tecnica indipendente su un’azienda target entro tempi stretti. Quando la verifica fa emergere lacune nella guida o nella capacità di consegna, Ampersand offre anche un supporto da CTO ad interim per portare avanti il piano di interventi, invece di lasciarlo come un documento che nessuno esegue.

I dettagli sul servizio di audit e due diligence tecnica, insieme al perimetro degli incarichi, sono sulla pagina della consulenza ingegneristica, mentre le informazioni aggiornate su piani e prezzi sono sulla pagina dei prezzi. Scrivici per definire una verifica in base ai tempi della tua operazione.

Fonti

Tre riferimenti reggono la parte normativa di questa checklist. Il NCSC’s P042 ISDS concept offre un modello per documentare le misure di sicurezza e il rischio residuo. Le indicazioni dell’EDÖB sull’esternalizzazione chiariscono che il titolare resta responsabile dei dati anche dopo aver delegato il trattamento a un fornitore. La panoramica sul CRA citata sopra aiuta a determinare gli obblighi UE sul ciclo di vita per i prodotti con elementi digitali.

• EDÖB confirms that Swiss data protection law is technology-neutral

• European Cyber Resilience Act

• EFK’s audit approach for AI systems

FAQ

Cosa deve contenere una checklist di due diligence?

Una checklist completa di due diligence tecnica copre qualità del codice e dell’architettura, infrastruttura e scalabilità, sicurezza e conformità normativa, governance di dati e IA, maturità di team e processi, titolarità della proprietà intellettuale e rischio legato alle integrazioni con terze parti. Ogni ambito deve produrre prove concrete e non rassicurazioni verbali, che confluiscono in un registro dei rischi consolidato e in un piano di interventi correttivi.

Che cos’è la due diligence tecnica?

La due diligence tecnica è una verifica strutturata del software, dell’infrastruttura, della sicurezza e del team di sviluppo di un’azienda, svolta prima di un investimento o di un’acquisizione per confermare le affermazioni e far emergere i rischi. Di solito produce una valutazione dei rischi, un piano di interventi correttivi con priorità e un giudizio di affidabilità che incide sulle condizioni dell’operazione o sulla valutazione.

Che cos’è una checklist CDD?

La customer due diligence, spesso abbreviata in CDD, è un processo di conformità che gli istituti finanziari usano per verificare l’identità dei clienti e valutarne il rischio, ed è cosa diversa dalla due diligence tecnica trattata in questa checklist. Se sei arrivato a questo termine cercando indicazioni su come esaminare la tecnologia, i controlli su codice, infrastruttura, sicurezza e team descritti sopra sono l’equivalente utile per le operazioni che riguardano software e tecnologia.

Quali sono le «quattro P» della due diligence?

Le definizioni delle «quattro P» variano da settore a settore e non esiste una versione autorevole valida nello specifico per la due diligence tecnica. Per un’operazione software o tecnologica, la struttura a sette ambiti di questa checklist, che copre codice, infrastruttura, sicurezza, dati, team, proprietà intellettuale e integrazioni, offre un quadro più affidabile di un generico modello in quattro parti.

Consigliati

• Audit software e due diligence tecnica a Zurigo

• CTO ad interim a Zurigo, responsabile tecnico frazionale e a tempo parziale