In breve: un contratto con un fornitore IT non dovrebbe menzionare la sicurezza solo di sfuggita, ma regolarla in concreto: chi aggiorna quali componenti, in quale termine e con quale prova, come si informa sulle vulnerabilità critiche, chi collabora in caso di incidente, come si conservano i log e si gestiscono gli accessi e che cosa accade all'uscita. Questa pagina offre indicazioni generali e non è consulenza legale; i contratti li verifica un avvocato.
La domanda posta da PHP2Shell: chi è responsabile?
Il 21/10/2026 alle 16:00, ora tedesca, il progetto PHP ha pubblicato le patch. Il BSI (Ufficio federale tedesco per la sicurezza informatica) ha raccomandato l'aggiornamento immediato o, dove non fosse possibile, di scollegare temporaneamente dalla rete i server web. In molte aziende dopo non è iniziato il lavoro, ma la ricerca della responsabilità. L'agenzia rimandava all'hoster, l'hoster al contratto, e nel contratto c'era scritto «manutenzione a consuntivo».
Simili lacune nel contratto non sono un caso isolato. Molti contratti con agenzie e fornitori furono conclusi quando si trattava di costruire un sito, non del suo esercizio sicuro negli anni. Una vulnerabilità critica nel runtime PHP, che non riguarda né il CMS né il codice dell'applicazione, cade allora facilmente tra le sedie di tutti.
Che cosa dovrebbe regolare sulla sicurezza un contratto con un fornitore IT
La panoramica seguente indica i punti che nella pratica si sono rivelati importanti. Non sostituisce una verifica giuridica, ma aiuta a riconoscere lacune nel contratto esistente.
| Punto di regolamentazione | Che cosa dovrebbe essere stabilito | Rapporto con PHP2Shell |
|---|---|---|
| Ambito della prestazione | Quali livelli vengono curati: sistema operativo, runtime PHP, server web, CMS, plugin, codice proprio | Il runtime PHP mancava spesso nell'elenco |
| Termini per gli aggiornamenti | Graduati in base alla gravità, con regola di eccezione per le emergenze | Vulnerabilità critica con CVSS v4.0 9.2 |
| Riavvio e prova | Gli aggiornamenti valgono come completati solo dopo il riavvio di tutti i processi, con attestazione scritta | I soli nuovi file non chiudono la vulnerabilità |
| Informazione | Notifica attiva in caso di vulnerabilità critiche, con valutazione e piano | Molti clienti hanno dovuto chiedere da soli |
| Collaborazione in caso di incidenti | Supporto per analisi, messa in sicurezza, ripristino, referente | Ricerca di tracce dopo la patch |
| Log | Tipo, conservazione, consegna su richiesta | La stampa specializzata ha consigliato di mettere al sicuro i log dal 20/10 |
| Accessi | Account personali, autenticazione a due fattori, elenco di tutti gli accessi | Chi aveva in realtà accesso? |
| Subappaltatori | Chi altro è coinvolto, informazione in caso di cambio | L'hoster dell'hoster |
| Fine vita del software | Avviso con congruo anticipo prima della fine del supporto, piano di migrazione | PHP 8.2 termina il 31/12/2026 |
| Uscita | Consegna di dati, documentazione e accessi, revoca dei diritti | Cambio dopo un incidente |
Termini e prove: i punti che contano di più
I termini sono il nucleo. Una formulazione come «tempestivamente» nel caso grave non aiuta. Concordi i termini separati per gravità e stabilisca da che cosa si misuri la gravità, ad esempio dalla classificazione del produttore o del BSI. Per situazioni eccezionali dovrebbe valere una regola di emergenza: chi è raggiungibile, chi decide se un sistema venga temporaneamente scollegato dalla rete e come si fatturi l'impegno aggiuntivo.
Altrettanto importante è la prova. Con PHP2Shell il numero di versione visualizzato spesso diceva poco, perché distribuzioni e hoster installano le correzioni come backport. Una prova attendibile indica lo stato dei pacchetti, il momento dell'installazione e il riavvio di tutti i processi PHP. Quali indicazioni contino esattamente lo descrive Come chiedere al suo hoster lo stato delle patch. Inserisca queste indicazioni nel contratto come contenuto obbligatorio.
Si faccia consegnare dal fornitore, insieme al contratto, una matrice dei compiti: una riga per componente, una colonna per compito, in ogni cella un nome. Le lacune emergono allora subito, molto prima che arrivi la prossima segnalazione.
Accessi, subappaltatori e uscita
I fornitori hanno bisogno di accessi, e sono proprio questi una frequente via d'attacco. Stabilisca che ogni persona riceva un account proprio, che l'autenticazione a due fattori sia obbligatoria dove la tecnica lo consente e che lei possa richiedere in qualsiasi momento un elenco aggiornato di tutti gli accessi. I collaboratori usciti dal fornitore devono essere rimossi tempestivamente da tutti i sistemi.
Se il fornitore stesso lavora con partner, ad esempio un data center o un team forense specializzato, dovrebbe saperlo. Se uno di questi partner tratta dati personali, si aggiungono obblighi in materia di protezione dei dati. Altro nell'articolo Trattamento dei dati per conto terzi quando i fornitori accedono ai server.
L'uscita è ciò che alla conclusione del contratto si dimentica più spesso. Stabilisca che alla fine del contratto dati, configurazione, documentazione e credenziali vengano consegnati per intero, tutti gli accessi del fornitore revocati e ciò confermato per iscritto. Proprio dopo un incidente, altrimenti, un cambio ordinato è difficile.
Verificare i contratti esistenti: come procedere
Non deve rinegoziare tutti i contratti. Per cominciare basta una procedura pragmatica:
- Raccogliere tutti i contratti con agenzie, hoster e fornitori IT che riguardano siti o server.
- Confrontare ogni contratto con la tabella sopra e contrassegnare i punti aperti.
- Sollevare per iscritto con il fornitore le lacune principali, iniziando da ambito della prestazione, termini e prova.
- Fissare i risultati in un accordo integrativo e farli verificare da un punto di vista giuridico.
- Riprendere la matrice dei compiti nel piano d'emergenza.
Per la direzione questo passo è anche una questione di diligenza. Chi regola con chiarezza le responsabilità e documenta le decisioni si trova in una posizione migliore se in seguito vengono poste domande. Informazioni di fondo le offre Responsabilità della direzione in caso di vulnerabilità IT. La tipica ripartizione dei compiti sui server gestiti la descrive Server gestito: chiarire la responsabilità.
Come aiuta concretamente PHP SOS?
- Leggiamo i suoi contratti e le descrizioni delle prestazioni esistenti dal punto di vista tecnico e contrassegniamo quali componenti e compiti mancano.
- Redigiamo una matrice dei compiti per tutti i siti e server, che può concordare con i suoi fornitori.
- Formuliamo i requisiti tecnici su termini, prove e canali di segnalazione che il suo avvocato può riprendere nel contratto.
- Dove nessuno è responsabile, assumiamo noi stessi i compiti con un contratto di manutenzione della sicurezza dall'ambito chiaramente descritto.
Conclusione: un buon contratto non impedisce una vulnerabilità, ma impedisce che nel caso grave si perda tempo con la domanda su chi sia responsabile. Questa pagina è un'informazione generale e non consulenza legale.
Domande frequenti
Un fornitore IT deve installare gli aggiornamenti di sicurezza senza incarico?
Dipende dal contratto. Senza una regolamentazione chiara spesso è controverso se gli aggiornamenti rientrino nella prestazione dovuta. Il contratto dovrebbe quindi stabilire espressamente chi aggiorna quali componenti e in quale termine. Per la valutazione giuridica nel singolo caso è competente un avvocato.
Mi serve in più un contratto di trattamento dei dati (AVV)?
Se il fornitore tratta per conto suo dati personali o può accedervi, di regola serve un contratto di trattamento dei dati ai sensi dell'art. 28 GDPR. Non sostituisce il contratto di servizio, ma lo integra. Lo chiarisca con il suo responsabile della protezione dei dati.
Quali termini per gli aggiornamenti di sicurezza sono usuali?
Non esistono valori fissi. È sensata una graduazione in base alla gravità, ad esempio termini separati per vulnerabilità critiche, alte e restanti. Importante è che i termini siano per iscritto e contengano una regola di eccezione per le emergenze come PHP2Shell.
Che cosa succede agli accessi quando il contratto termina?
Dovrebbe regolarlo il contratto: restituzione o cancellazione dei dati, consegna di credenziali e documentazione, revoca di tutti gli accessi del fornitore e una conferma in merito.