Un contratto ICT non dovrebbe limitarsi a descrivere un servizio in termini generici. Deve trasformare un rapporto tecnico in un insieme verificabile di attività, responsabilità, livelli di servizio, dipendenze, regole di sicurezza e condizioni di uscita. Questo è particolarmente importante quando il fornitore gestisce infrastrutture, cloud, Microsoft 365, endpoint, backup, rete o sistemi che incidono direttamente sulla continuità operativa dell’azienda.
La qualità del contratto dipende prima di tutto dalla precisione del perimetro. Più l’oggetto è ambiguo, maggiore è il rischio che cliente e fornitore attribuiscano significati diversi a termini come “assistenza”, “monitoraggio”, “presa in carico”, “ripristino”, “manutenzione” o “sicurezza”.
Cos’è un contratto ICT
Un contratto ICT è un accordo che disciplina la fornitura di prodotti, software, infrastrutture o servizi informatici. Può riguardare un progetto a termine, un servizio ricorrente, attività di supporto, cloud, outsourcing, sviluppo software, cybersecurity o una combinazione di queste componenti.
Non esiste un unico modello valido per tutti i casi. Un contratto per un progetto di migrazione Microsoft 365 ha logiche diverse da un contratto di help desk, da un servizio Managed Services o da un accordo SaaS. Per questo il documento deve essere costruito partendo dal servizio effettivamente acquistato e dalle dipendenze operative del cliente.
1. Definire il perimetro tecnico senza ambiguità
La prima sezione operativa deve chiarire cosa è incluso e cosa è escluso. L’elenco dovrebbe identificare sistemi, sedi, utenti, piattaforme, apparati, applicazioni, ambienti cloud e attività coperte. Quando il servizio è continuativo, conviene associare al contratto un inventario o un allegato tecnico aggiornabile.
- asset e servizi inclusi nel perimetro;
- attività ricorrenti e attività a richiesta;
- modalità di supporto remoto e on-site;
- orari di copertura e finestre di manutenzione;
- attività esplicitamente escluse;
- prerequisiti e dipendenze a carico del cliente;
- fornitori terzi e servizi che restano sotto responsabilità esterna.
2. SLA: distinguere presa in carico, risposta e ripristino
Uno SLA efficace usa indicatori misurabili e definizioni univoche. “Risposta rapida” non è uno SLA. È necessario stabilire da quando parte il conteggio, quale evento lo interrompe, quali orari sono inclusi e come cambia il livello di servizio in base alla priorità.
È utile distinguere almeno tempo di presa in carico, tempo di prima risposta, obiettivo di ripristino o workaround e, quando pertinente, disponibilità del servizio. Penali, service credit o meccanismi premiali possono essere previsti, ma non sono componenti automatici di ogni SLA: devono essere negoziati e collegati a metriche realmente controllabili dal fornitore.
3. Priorità, escalation e responsabilità: la RACI tecnica
La classificazione delle priorità deve dipendere dall’impatto sul business e non solo dalla gravità tecnica apparente. Un problema su un singolo notebook può essere urgente per un ruolo critico; un alert su un sistema ridondato può avere impatto minore. Il contratto dovrebbe quindi descrivere criteri di priorità, canali di escalation e soggetti autorizzati ad aprire richieste critiche.
Per i servizi più complessi è utile affiancare una matrice RACI che indichi chi è Responsible, Accountable, Consulted e Informed per attività come patching, backup, gestione identità, firewall, licensing, incident response, change e rapporti con vendor terzi.
CTA - Assistenza informatica con SLA Se l’esigenza è operativa e riguarda help desk, ticketing, supporto sistemistico e tempi di presa in carico concordati, vai alla pagina assistenza informatica per aziende. |
4. Sicurezza, accessi privilegiati e gestione degli incidenti
Quando il fornitore accede a sistemi critici, il contratto dovrebbe definire requisiti minimi per account amministrativi, autenticazione forte, registrazione degli accessi, segregazione dei privilegi, gestione delle credenziali, logging e revoca degli accessi alla cessazione del rapporto.
Devono essere inoltre definite le procedure per incidenti cyber: canale di escalation, reperibilità prevista dal servizio, informazioni da condividere, conservazione dei log, collaborazione con il cliente e coordinamento con eventuali soggetti terzi. I tempi contrattuali interni non devono essere confusi con eventuali termini di notifica previsti dalla normativa applicabile al cliente.
Definizione tecnica del perimetro
Se devi strutturare scope, responsabilità, dipendenze tecniche o una roadmap prima della contrattualizzazione, consulta consulenza informatica per aziende.
5. GDPR e trattamento dei dati personali
Se il fornitore tratta dati personali per conto del cliente, il rapporto deve essere disciplinato anche secondo l’articolo 28 del GDPR. In questo scenario il contratto o l’atto collegato deve descrivere materia e durata del trattamento, natura e finalità, tipologie di dati, categorie di interessati e obblighi delle parti.
La qualifica di responsabile del trattamento non deriva però automaticamente dal fatto che il soggetto sia un fornitore IT. Deve essere valutato il ruolo effettivo nel trattamento. Se il fornitore opera come responsabile, vanno gestiti anche sub-responsabili, misure di sicurezza, assistenza al titolare, audit e restituzione o cancellazione dei dati al termine del rapporto.
6. NIS2: la sicurezza della supply chain entra nel rapporto con i fornitori
Per i soggetti che rientrano nel perimetro del D.Lgs. 138/2024, che recepisce la direttiva NIS2, la gestione del rischio comprende anche la sicurezza della catena di approvvigionamento e i rapporti con fornitori e prestatori di servizi. Questo rende opportuno tradurre i requisiti di sicurezza rilevanti in clausole verificabili, senza trasformare il contratto in una semplice dichiarazione di conformità.
Nel concreto possono essere disciplinati requisiti di sicurezza minimi, gestione delle vulnerabilità, controllo degli accessi, notifica degli incidenti rilevanti per il servizio, subfornitura, continuità, evidenze e diritto di verifica, calibrandoli sul rischio e sul ruolo del fornitore.
7. DORA: requisiti contrattuali specifici per il settore finanziario
Le entità finanziarie soggette al Regolamento (UE) 2022/2554 - DORA devono considerare requisiti ulteriori quando utilizzano servizi ICT di terze parti. L’articolo 30 disciplina elementi contrattuali specifici, con requisiti rafforzati quando il servizio supporta funzioni critiche o importanti.
La presenza di DORA non rende automaticamente ogni contratto ICT identico: il contenuto va determinato in funzione del soggetto, del servizio e della criticità della funzione supportata.
8. Pubblica Amministrazione: contratti ICT e servizi cloud
Nel settore pubblico il contratto ICT deve essere coordinato con la disciplina degli appalti e con le regole specifiche applicabili ai servizi digitali. Per il cloud della PA, nel 2026 il riferimento è il Regolamento unico ACN per le infrastrutture e i servizi cloud, adottato con Decreto Direttoriale n. 21007/24 e applicabile dal 1° agosto 2024.
È quindi preferibile evitare formulazioni generiche come “fornitore qualificato AgID” e verificare invece, per lo specifico servizio e per la classificazione dei dati e dei servizi della PA, i requisiti ACN applicabili e la modalità di acquisizione prevista.
9. Exit strategy, portabilità e fine rapporto
Una delle sezioni più importanti è quella che disciplina l’uscita. Il contratto dovrebbe stabilire cosa accade a credenziali, documentazione, configurazioni, dati, backup, licenze, tenant, domini, certificati, chiavi, apparati e account amministrativi alla cessazione del servizio.
L’exit plan deve definire tempi, formato delle informazioni, attività di handover, collaborazione con il nuovo fornitore, costi delle attività straordinarie e responsabilità durante la transizione. Il periodo non va fissato con una durata standard valida per tutti: dipende da complessità, quantità di asset e criticità del servizio.
10. Assistenza, consulenza e Managed Services: contratti diversi
Un contratto di assistenza disciplina soprattutto ticket, supporto utenti, interventi sistemistici, orari, priorità e SLA. Un contratto di consulenza è normalmente legato ad analisi, progettazione, deliverable e attività a progetto. Un contratto Managed Services include invece presa in carico continuativa di uno specifico perimetro, strumenti di monitoraggio, manutenzione preventiva, reportistica e procedure operative ricorrenti.
Le tre modalità possono convivere nello stesso rapporto, ma devono rimanere distinguibili: attività incluse nel canone, attività a consumo e progetti straordinari devono avere regole economiche e operative separate.
Managed Services Per un modello continuativo con monitoraggio, manutenzione, sicurezza e governance operativa del perimetro IT, consulta Managed Services IT per aziende. |
Come funziona un contratto di assistenza tecnica informatica
Nexsys si occupa di assistenza tecnica da oltre quindici anni, garantendo un servizio efficace ed efficiente. Poter contare sulla disponibilità di un contratto di assistenza tecnica informatica rappresenta una decisione strategica e garantisce supporto per il personale, assicurando sicurezza e continuità al business.
Prevediamo interventi periodici, on-site e da remoto, monitoriamo costantemente le verifiche dei backup, gli apparati di rete, gli aggiornamenti e l’installazione di software e dei sistemi, effettuiamo prove di ripristino e check periodici e favoriamo la protezione contro virus e malware.
Rispondiamo in tempi rapidi per garantire la ripresa dell’operatività e limitare i tempi di blocco. Collaboriamo con gli utenti per permettere loro di imparare dall’esperienza ed aumentare il proprio livello di autonomia nell’utilizzo dei sistemi.
Checklist tecnica prima di firmare un contratto ICT
- Il perimetro è identificato per sistemi, utenti, sedi e servizi?
- Sono esplicitate le esclusioni?
- Gli SLA distinguono presa in carico, risposta e ripristino?
- Le priorità dipendono da impatto e urgenza?
- Sono definite responsabilità e dipendenze del cliente?
- Sono disciplinati accessi privilegiati e revoca degli account?
- È chiaro chi gestisce backup, restore test e continuità?
- Se applicabile, è presente un accordo ex art. 28 GDPR coerente con il ruolo effettivo?
- Sono gestiti subfornitori e servizi terzi?
- Sono definite procedure di incident escalation?
- Sono presenti regole di change management?
- L’exit strategy disciplina dati, credenziali, documentazione e handover?
- Le clausole di sicurezza sono coerenti con eventuali obblighi NIS2, DORA o di settore?
Hai bisogno di aiuto sul tuo contratto IT?
A seconda della tua situazione, possiamo aiutarti su 3 fronti:
⚖️ Devi negoziare un contratto IT?
Ti supportiamo nella valutazione tecnica delle clausole SLA,
perimetro e responsabilità.
🔧 Cerchi un fornitore di managed services?
SLA documentati, monitoring 24/7, prezzi bloccati. Da 25+ anni
partner di PMI italiane.
📍 Sei in Veneto?
Primo incontro gratuito e senza impegno. 45 minuti per definire
le priorità.
FAQ sui contratti ICT
Cos’è un contratto ICT?
È un accordo che disciplina la fornitura di prodotti, software o servizi informatici, definendo perimetro, responsabilità, livelli di servizio, sicurezza, condizioni economiche e modalità di cessazione.
Cosa deve contenere un contratto di assistenza informatica?
Deve descrivere almeno perimetro ed esclusioni, modalità di apertura ticket, orari di copertura, priorità, SLA, escalation, responsabilità del cliente e del fornitore, attività incluse e regole per gli interventi fuori perimetro.
SLA e tempo di risoluzione sono la stessa cosa?
No. Lo SLA può distinguere presa in carico, prima risposta, workaround, ripristino e disponibilità. Ogni metrica deve indicare condizioni di misura, orari e dipendenze.
Un contratto ICT deve sempre includere un DPA GDPR?
No. L’accordo ex articolo 28 GDPR è necessario quando il fornitore tratta dati personali per conto del cliente in qualità di responsabile o sub-responsabile. Il ruolo deve essere valutato sul trattamento effettivo.
La NIS2 incide sui contratti con i fornitori IT?
Per i soggetti nel perimetro NIS2, la gestione del rischio comprende anche la sicurezza della catena di approvvigionamento. I requisiti rilevanti verso fornitori e prestatori di servizi devono quindi essere governati anche contrattualmente quando appropriato.
DORA impone clausole specifiche nei contratti ICT?
Sì, per le entità finanziarie soggette a DORA. L’articolo 30 del Regolamento UE 2022/2554 prevede elementi contrattuali specifici, con requisiti ulteriori per servizi ICT che supportano funzioni critiche o importanti.
Come si evita il vendor lock-in alla fine del contratto?
Definendo prima della firma un’exit strategy con restituzione di credenziali e documentazione, portabilità dei dati, gestione delle licenze e degli asset, supporto all’handover e cancellazione dei dati quando prevista.
Qual è la differenza tra assistenza IT e Managed Services?
L’assistenza è centrata sulla gestione di richieste e problemi; i Managed Services includono una presa in carico continuativa del perimetro con monitoraggio, manutenzione preventiva, procedure ricorrenti e reportistica, secondo quanto definito nel contratto.