Break & fix: perché chiamare il tecnico solo quando si rompe costa più di quanto sembra

di Daniele Curto — Amministratore e fondatore, DC Consult SRL · 21 agosto 2026 · lettura 11 min

Il modello a chiamata sembra il più prudente: si paga solo quando serve. Il punto è che la fattura non è il costo, ed è solo una parte di ciò che l'azienda sostiene. Qui proviamo a guardare l'altra parte: come sono orientati gli incentivi, quali costi restano fuori dalla fattura, e dove la normativa rende il modello reattivo strutturalmente incompatibile.

Come nasce il modello a chiamata

Il break & fix — si chiama il tecnico quando qualcosa non funziona, si paga l'intervento — non è nato da un errore di valutazione. È il risultato di una storia coerente: per anni l'informatica in azienda ha significato oggetti. Un server, delle stampanti, dei PC. Oggetti che si guastano e si riparano, esattamente come un impianto o un macchinario. Un modello di manutenzione a chiamata era, in quel contesto, la scelta razionale.

Nel bilancio l'IT è finito nella colonna dei costi, e ci è rimasto. Da lì una logica difensiva perfettamente comprensibile: se è un costo, l'obiettivo è comprimerlo. Si spende quando è inevitabile, cioè quando qualcosa è già fermo.

Cosa è cambiato, senza che il modello cambiasse con esso: i processi aziendali non usano più l'informatica, ci girano dentro. Ordini, magazzino, fatturazione, produzione, comunicazione con i clienti. Quando l'IT si ferma, non si ferma un ufficio: si ferma l'azienda. L'oggetto è diventato infrastruttura, ma il contratto è rimasto quello dell'oggetto.

Il break & fix non è un modello sbagliato in astratto. È un modello tarato su un'azienda che non esiste più.

Il problema non è il prezzo, sono gli incentivi

Nel modello a chiamata il fornitore genera fatturato quando qualcosa si rompe. Il cliente sostiene una spesa solo quando qualcosa si è già rotto. Ne deriva una conseguenza che non richiede la cattiva fede di nessuno:

• per il cliente, ogni euro speso in prevenzione è un euro speso per un problema che non si è manifestato — quindi, dal suo punto di vista informativo, per un problema che non c'era
• per il fornitore, ogni ora investita in prevenzione riduce il numero di interventi futuri, cioè riduce il proprio fatturato

Nessuno dei due ha un interesse economico a prevenire. Entrambi si comportano in modo razionale rispetto al proprio incentivo, e il risultato aggregato è un sistema che aspetta il guasto. Non è un problema di persone, è un problema di struttura del contratto.

Nel modello a gestione continuativa il segno si inverte: il fornitore è remunerato per il periodo, non per l'intervento. Ogni guasto evitato è margine che resta al fornitore e attività che non si interrompe per il cliente. È la prima volta che i due interessi puntano nella stessa direzione.

Per onestà: anche la gestione continuativa ha un incentivo distorto proprio, cioè sottoinvestire nel servizio una volta acquisito il canone. Si controlla con obiettivi di servizio misurabili e verificabili — motivo per cui le domande da fare al fornitore contano più della scelta del modello.

I costi che non compaiono in fattura

Il paragone tra i due modelli fatto solo sulle fatture è falsato, perché il break & fix scarica una parte del costo su voci che non arrivano al fornitore.

• Il fermo. Personale pagato che non produce, ordini non evasi, consegne slittate, clienti che chiamano. È il costo maggiore e non compare in nessuna fattura IT.
• La diagnosi da zero. Chi interviene su un'infrastruttura che non conosce spende la prima parte del tempo a capire com'è fatta. Quel tempo si paga a tariffa oraria, di nuovo, ad ogni intervento.
• La conoscenza che non si accumula. Senza documentazione mantenuta nel tempo, ogni intervento riparte dalle stesse domande. Il sapere sull'infrastruttura resta nella testa di chi c'era, e se ne va con lui.
• Il debito tecnico. Sotto pressione si risolve, non si sistema. Ogni soluzione rapida lascia una configurazione non pulita che diventa la causa del guasto successivo.
• Le decisioni prese in emergenza. Sostituzioni scelte per disponibilità immediata, non per adeguatezza. Si paga due volte: subito e quando va rifatto.
• L'assenza di un dato di riferimento. Senza monitoraggio continuo non esiste una linea di base. Non si sa se un sistema si sta degradando: si scopre che era degradato quando si ferma.
• La spesa che non si conosce. Chi lavora a chiamata non ha un dato aggregato della propria spesa IT: è distribuita tra interventi occasionali, acquisti hardware, licenze rinnovate da uffici diversi e ore di fermo mai contabilizzate. La domanda utile non è quanto si dovrebbe spendere, ma quanto si sta già spendendo — e se lo si sa.
• L'incertezza sui tempi. Senza un accordo sui livelli di servizio, la domanda "quando ripartiamo?" non ha risposta contrattuale. Ha una risposta che dipende dall'agenda di chi deve intervenire.

Il modello a chiamata non è più economico. Ha una spesa più bassa e un costo più alto, e la differenza tra i due la paga l'azienda in una voce che nessuno le presenta.

Il punto in cui il modello si rompe da solo: la compliance

Fino a qui il confronto è economico, e su un'analisi economica si può legittimamente dissentire. La normativa introduce un vincolo che non è negoziabile.

• L'art. 24 del D.lgs. 138/2024 include tra le misure minime di gestione del rischio la continuità operativa, ivi compresa la gestione dei backup e il ripristino in caso di disastro, la gestione degli incidenti, la valutazione dell'efficacia delle misure e la sicurezza della catena di approvvigionamento. Sono misure continuative: non esiste un modo di soddisfarle a chiamata, perché il presupposto è che qualcuno le mantenga e le verifichi nel tempo, non che intervenga dopo. Sul solo backup, il metodo e la verifica di ripristino sono trattati nella guida Backup 3-2-1-1-0.
• L'art. 25 del D.lgs. 138/2024 impone la pre-notifica di un incidente significativo entro 24 ore e la notifica completa entro 72. Un modello in cui il fornitore viene contattato dopo l'accaduto e interviene secondo disponibilità non è compatibile con una finestra di 24 ore, perché richiede rilevazione, qualificazione e notifica dentro quel termine.
• L'art. 23 del D.lgs. 138/2024 pone in capo agli organi di amministrazione e direttivi l'approvazione e la sorveglianza sull'attuazione delle misure. Non è materia che si delega verso l'esterno con un contratto a consumo: la responsabilità resta al vertice aziendale.
• L'art. 32, par. 1, lett. b) e c) del Regolamento (UE) 2016/679 richiede disponibilità e resilienza dei sistemi e la capacità di ripristinare tempestivamente la disponibilità dei dati. Vale per qualunque titolare del trattamento, indipendentemente dalla dimensione e dal perimetro NIS.

L'effetto a cascata. Anche un'impresa fuori perimetro può trovarsi a dover soddisfare requisiti di sicurezza per via contrattuale, come fornitore di un soggetto NIS: la Determinazione ACN 127437/2026 ha introdotto l'elencazione dei fornitori rilevanti. Un fornitore che non sa dire con quale frequenza verifica i backup del proprio cliente non può rispondere a un questionario di assessment. Il test di perimetro e gli obblighi sono nella guida NIS2 e PMI: come capire se sei nel perimetro.

La normativa non impone di scegliere un modello di servizio. Impone un risultato — misure mantenute, verificate e documentate nel tempo — che un modello reattivo non è strutturalmente in grado di produrre. Non è un argomento commerciale: è un vincolo di compatibilità.

La figura che manca: chi decide e chi ha le chiavi

Chi decide

Nel modello a chiamata manca un ruolo che nessuno nota perché non ha mai avuto un nome in azienda: quello di chi decide. Il tecnico chiamato in emergenza esegue, e fa bene il suo lavoro. Ma le scelte che contano — cosa aggiornare, cosa sostituire, quale rischio accettare e quale coprire, con quale priorità e con quale spesa — vengono prese di fatto da chi ha alzato il telefono, che è la persona meno attrezzata per prenderle. Non per incompetenza: per assenza di informazioni.

Cosa fa questo ruolo, quando esiste:

• tiene una fotografia aggiornata dell'infrastruttura, e quindi sa cosa c'è e in che stato
• stabilisce un ordine di priorità tra gli interventi, invece di eseguirli nell'ordine in cui si rompono
• valuta e coordina i fornitori — connettività, gestionale, cloud — che altrimenti dialogano solo con chi ha il problema del momento
• porta all'organo amministrativo un quadro leggibile: cosa è coperto, cosa non lo è, cosa costerebbe coprirlo
• mantiene la documentazione, che è l'unica cosa che resta all'azienda quando cambia il fornitore o la persona

L'art. 23 del D.lgs. 138/2024 pone in capo agli organi di amministrazione e direttivi l'approvazione delle misure di gestione del rischio e la sorveglianza sulla loro attuazione. È una responsabilità che presuppone un flusso informativo continuo verso il vertice. Un fornitore che interviene a chiamata non produce quel flusso, e non perché non voglia: perché non è ciò per cui è stato ingaggiato. La norma non chiede di assumere un IT Manager. Chiede un risultato — decisioni informate e sorvegliate — che senza qualcuno che presidi il ruolo nessuno è in grado di produrre.

Per una PMI un IT Manager interno a tempo pieno è spesso fuori scala, per costo e per volume di attività. È la ragione per cui la funzione viene esternalizzata in forma continuativa, con un referente stabile. Il punto non è chi occupi il ruolo, ma che il ruolo esista e abbia un nome.

Chi ha le chiavi

Qui cambia il piano del discorso: non si parla di governo ma di privilegi tecnici, e la questione non è organizzativa. È di conformità.

Chi ha accesso amministrativo ai sistemi aziendali può leggere, modificare, esportare e cancellare dati personali: quelli dei dipendenti, dei clienti, dei fornitori. È un ruolo tecnico con effetti diretti sulla protezione dei dati.

L'art. 29 del GDPR stabilisce che chiunque agisca sotto l'autorità del titolare o del responsabile del trattamento e abbia accesso a dati personali tratti tali dati soltanto su istruzione del titolare, salvo che lo richieda il diritto dell'Unione o nazionale. L'art. 32, par. 4 ribadisce l'obbligo di titolare e responsabile di garantire questo vincolo. Ne segue una conseguenza concreta: l'accesso amministrativo va attribuito a soggetti individuati, entro un ambito di autorizzazione definito, e deve essere tracciabile.

Come si presenta invece la situazione tipica nel modello a chiamata — constatazione, non accusa:

• una credenziale amministrativa condivisa, in uso da anni, di cui non si sa con precisione chi sia in possesso
• accessi remoti attivi da interventi conclusi molto tempo prima, mai revocati
• nessuna registrazione di chi sia entrato, quando e per fare cosa
• nessuna istruzione documentata sull'ambito di ciò che quell'accesso autorizza a fare
• tecnici diversi, di aziende diverse, che nel corso del tempo hanno avuto le stesse chiavi

Non è un problema di modello contrattuale, è un'autorizzazione al trattamento non documentata. E la prova è una domanda sola: chi ha oggi accesso amministrativo ai tuoi sistemi, con quali credenziali, e dove è scritto? Se la risposta richiede una telefonata per essere ricostruita, la risposta è che non lo sai.

Il tema tocca due punti già trattati altrove: la sicurezza della catena di approvvigionamento richiamata dall'art. 24 nella guida NIS2 e PMI e il criterio di immutabilità della guida Backup 3-2-1-1-0, che è precisamente una domanda su chi detiene privilegi.

Quando il break & fix è la scelta giusta

Il modello a chiamata è economicamente sensato quando:

• le postazioni sono pochissime e l'infrastruttura è minima, senza server né applicativi gestionali critici
• un fermo di una giornata non blocca l'attività: il lavoro può proseguire in altra forma
• non ci sono dati personali oltre l'ordinario né obblighi settoriali specifici
• l'azienda non è fornitore ICT di soggetti che debbano verificare la propria catena di approvvigionamento
• esiste già competenza interna che presidia manutenzione, aggiornamenti e verifica dei backup

In questi casi un canone è denaro speso per una copertura che non serve, e proporlo comunque sarebbe vendere male. Il discrimine non è la dimensione dell'azienda: è quanto si ferma l'attività quando si ferma l'informatica. Se la risposta è "tutto", il modello a chiamata è un rischio non prezzato.

Le domande da fare al proprio fornitore

Questa checklist è utile a prescindere dal modello scelto e a prescindere da chi eroga il servizio.

• Con quale frequenza verificate che i backup siano ripristinabili, e dove è registrato l'esito dell'ultima verifica?
• Esiste una documentazione aggiornata della mia infrastruttura, e posso averne copia?
• Come vengo a sapere che un sistema ha un problema: mi arriva un alert o mi accorgo che non funziona?
• In caso di fermo, entro quanto tempo interviene qualcuno, e questo tempo è scritto da qualche parte?
• Chi ha oggi accesso amministrativo ai miei sistemi, con quali credenziali individuali, e dove è documentato l'ambito di ciò che è autorizzato a fare?
• Chi decide le priorità sulla mia infrastruttura, e a chi riferisce?
• Se domani cambio fornitore, cosa mi viene consegnato?
• Chi ha aggiornato per ultimo firmware, sistemi e applicativi, e quando?
• Se un mio cliente mi invia un questionario di sicurezza, chi lo compila e con quali dati?

Se non si ottiene risposta a queste domande, il problema non è il modello contrattuale. È che nessuno sta guardando.