La risposta in breve
La due diligence tecnologica verifica se un acquirente potrà comprendere, gestire e sviluppare la tecnologia dopo l'operazione. Il venditore dovrebbe collegare ogni affermazione a prove su architettura, repository, release, sicurezza, resilienza, dati, licenze, persone e debito tecnico. L'obiettivo non è un sistema perfetto né un accumulo di documenti, ma un dossier coerente che indichi responsabili, date dei test ed eccezioni note.
Partire da affermazioni, prove e perimetro
La verifica tecnica fa parte dell'esame complessivo dell'impresa. Il Portale PMI svizzero spiega che la due diligence informa decisione d'acquisto, prezzo e contratto. Il perimetro dipende anche da ciò che sarà trasferito. Professionisti qualificati devono definire le questioni legali dell'operazione concreta.
Crei un indice prima di caricare i file. Ogni affermazione importante deve indicare documento, responsabile, data ed eventuale eccezione. «I deployment sono automatizzati» deve rimandare alla pipeline, a un'esecuzione recente e a un sostituto identificato.
| Affermazione | Prova | Responsabile | Ultimo test | Stato |
|---|---|---|---|---|
| La produzione può essere ripristinata | Runbook e rapporto di ripristino | Responsabile piattaforma | Data effettiva | Verde, giallo o rosso |
| Gli accessi sono controllati | Ruoli e revisione | Responsabile sicurezza | Data effettiva | Eccezioni |
In un acquisto di azioni, la verifica può coprire l’intera storia operativa e il perimetro delle responsabilità della società. In un acquisto di attività, può concentrarsi su tecnologia, contratti e diritti effettivamente trasferiti. Il consulente qualificato definisce il perimetro adatto.
Documentare architettura, inventario e modifiche
Mostri applicazioni, dati, hosting, integrazioni, fornitori critici e confini di fiducia. Affianchi un inventario con proprietario tecnico, ciclo di vita e dipendenze. Un diagramma senza responsabili invecchia; un inventario senza relazioni nasconde le concentrazioni.
Segua una release rappresentativa dalla modifica approvata a build, test, deployment, rollback e monitoraggio. Se un passaggio dipende dalla memoria del fondatore o di un solo ingegnere, registratelo nel piano di rimedio.
- Architettura e flussi di dati
- Inventario di applicazioni, infrastrutture e fornitori
- Repository, proprietà e accessi
- Build, test, release e rollback
- Ambienti e configurazione
- Roadmap, fine vita e debito tecnico
Rendere verificabili sicurezza e resilienza
La raccomandazioni di protezione di base dell'UFCS unisce misure organizzative e tecniche. Colleghi identità, accessi privilegiati, patch, vulnerabilità, log, incident response e formazione a persone responsabili.
Un backup diventa prova quando il ripristino è stato testato. Documenti ambito, frequenza, conservazione, separazione dalla produzione e ultima esercitazione. Elencate gli incidenti rilevanti con impatto, risposta, correzione e stato.
La domanda pratica è: una seconda persona può distribuire, ripristinare e reagire senza conoscenze non documentate?
Controllare dati e divulgazione
Una data room non annulla protezione dei dati, riservatezza o obblighi contrattuali. Le indicazioni dell'IFPDT sottolineano scopo, proporzionalità e accesso limitato. Inventari dati personali, finalità, ubicazioni, responsabili esterni, conservazione, cancellazione e trasferimenti. Faccia valutare l'applicazione della legge svizzera al caso concreto.
Usi una divulgazione progressiva: prima controlli e dati aggregati; informazioni identificabili solo quando necessarie, con destinatari, oscuramento, scadenza e registro.
Verificare licenze, titolarità e persone chiave
Colleghi ogni componente centrale a repository, autore o fornitore, rapporto di lavoro o incarico, cessione o licenza e dipendenze terze. Mantenga un inventario open source con licenze e obblighi. La guida sulla proprietà intellettuale del software approfondisce la provenienza.
Assegni un responsabile primario e un sostituto a ogni sistema critico. Includete dipendenti, collaboratori e fornitori, accessi privilegiati e capacità di passaggio. La mappa mostra le dipendenze da una sola persona.
Usare un registro verde, giallo e rosso
Esempio illustrativo: una società SaaS svizzera dichiara di testare il ripristino operativo ogni trimestre. La direttiva è aggiornata, ma l'ultimo ripristino completo risale a undici mesi fa e solo il fondatore possiede una credenziale cloud d'emergenza. Lo stato è giallo o rosso. Il piano assegna un responsabile piattaforma, programma un test, crea un accesso d'emergenza governato separatamente e registra l'esito.
Il colore serve alla priorità. Definisca ogni stato e conservate i fatti. Un'eccezione documentata con responsabile e data è più credibile di una rassicurazione non riproducibile.
- Elencare le affermazioni nei materiali di vendita.
- Associare artefatti e responsabili.
- Testare un processo per area critica.
- Registrare eccezioni e rilievo commerciale.
- Correggere le lacune principali quando ragionevole.
- Tenere un registro delle divulgazioni.
Anticipare le domande dietro la checklist
L'acquirente non valuta la tecnologia in isolamento. Collega i fatti tecnici alla continuità dei clienti, agli investimenti futuri e alle dichiarazioni discusse nell'operazione. Per ogni sistema critico preparate una scheda con scopo, utenti, carico attuale, livello di servizio, responsabile, possibile modalità di guasto e investimento previsto. Separi i fatti osservati dalle previsioni. Se la capacità oltre il carico attuale non è stata testata, mostrate le prove disponibili e il prossimo test invece di promettere scalabilità illimitata.
Prepari il percorso documentale per le domande tipiche. Come riceve accesso un nuovo ingegnere? Quali cambiamenti richiedono revisione? Chi autorizza una release urgente? Come sono separate le configurazioni dei clienti? Cosa accade se un fornitore critico non è disponibile? Quali componenti sono vicini alla fine vita? Come vengono ordinate le vulnerabilità? Ogni risposta dovrebbe indicare regola, traccia di sistema, esempio recente e persona responsabile. Faccia provare il processo a una persona che normalmente non lo esegue.
Riconcili roadmap, budget, impegni con i clienti e debito tecnico. Una roadmap piena di funzionalità ma priva di sicurezza, piattaforma e ciclo di vita genera dubbi. Separi lavoro promesso ai clienti, priorità interne e idee opzionali. Documenti dipendenze e processo decisionale nei conflitti. L'acquirente vuole vedere come il management trasforma i vincoli in un piano.
Controllare la qualità prima di aprire la data room
Verifichi date, entità, ambienti e definizioni in tutti i documenti. Architettura, fornitori, incidenti, organico e materiali finanziari devono descrivere la stessa impresa alla stessa data. Elimini i duplicati obsoleti conservando la cronologia. Indichi chiaramente le bozze. Se una policy prevede revisioni trimestrali degli accessi, confermate che i verbali esistano per i sistemi citati.
Durante la due diligence tenete un registro delle domande. Assegni responsabile, scadenza, fonti e approvazione. Rendete visibili le correzioni. Una correzione controllata crea fiducia; un file sostituito senza spiegazione genera dubbi sull'intero dataset. Separi fatti, interpretazione legale e previsioni e inviateli allo specialista adatto.
Preparare la verifica senza bloccare l'attività
Partite dai sistemi che incidono su clienti, ricavi, diritti o continuità. Nominate un coordinatore, mantenete la responsabilità tecnica nel team e versionate l'indice. Secondo il Portale PMI, una raccolta anticipata risparmia tempo e costi; caricamenti indiscriminati creano rumore e rischio.
Chiedete: cosa è critico, cosa può fallire, chi reagisce, quali diritti passano, quali impegni limitano le modifiche e quali investimenti sono previsti? Riconcili le risposte con i materiali commerciali e finanziari, quindi leggete la guida per vendere un'impresa IT in Svizzera.
Il dossier è pronto per una verifica controllata quando ogni affermazione rilevante dispone di prova attuale, responsabile, data del test, eccezioni documentate e classe di divulgazione approvata.
Le domande dei titolari
Che cos'è la due diligence tecnologica?
È una revisione strutturata di tecnologia, operazioni, sicurezza, diritti, persone e rischi noti nell'ambito di una transazione. Il perimetro va adattato all’impresa e all’operazione prevista.
Quando dovrebbe iniziare il venditore?
Prima di contattare un ampio gruppo di acquirenti, così resta tempo per testare i processi, correggere contraddizioni e controllare i dati sensibili. Una prova interna mostra quali evidenze o responsabilità mancano ancora.
Cosa contiene una data room tecnica?
Un indice può comprendere architettura, inventari, release, sicurezza, recovery, dati, licenze, titolarità, persone e debito tecnico. L'accesso va gestito per fasi.
Ogni problema deve essere risolto?
No. Dia priorità all'impatto su clienti, continuità, diritti e operazione. Documenti con precisione ciò che rimane.
La checklist è un parere legale o di sicurezza?
No. Serve alla preparazione. Le questioni dipendenti dai fatti richiedono specialisti svizzeri qualificati.
Fonti e approfondimenti
Redazione Continuum
Ricerche e strumenti pratici per orientare i titolari. Continuum offre una prima prospettiva indipendente e, su richiesta, contatti pertinenti. La consulenza legale, fiscale e valutativa specifica per una transazione spetta a professionisti qualificati.
Il Suo prossimo passo