# Emergenza IT: incaricare subito un fornitore per il web server

> Emergenza IT sul web server? Siamo il fornitore che interviene da remoto, conserva le tracce e bonifica. Ci chiami o scriva su WhatsApp.

Fonte: https://phpsos.de/it/soforthilfe/it-notfall-dienstleister/  
Stato: 25/10/2026  
Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6

**In breve:** è stato colpito? Ci chiami. La aiutiamo. Se ha un'emergenza IT sul web server e nessun esperto a disposizione, ci incarichi con un solo messaggio: ce ne occupiamo dal primo messaggio, lavoriamo da remoto senza trasferte e mettiamo tutto per iscritto, fino alla conclusione e alla documentazione dell'incidente.

> **Agire subito:**
> **Ora non cancelli nulla e non reinstalli nulla.** Nemmeno come preparazione per il fornitore. Lo stato del sistema è il mezzo di prova più importante. [Segnali l'emergenza](https://phpsos.de/it/notfall/) e chiariremo insieme accessi e ruoli.

## È stato colpito? Quando serve un fornitore per le emergenze

Non ogni disservizio è un incidente di sicurezza. Un fornitore per le emergenze ha senso se è vero almeno uno di questi punti:

- Il Suo web server si comporta in modo anomalo e in azienda nessuno sa individuarne la causa.
- C'è il sospetto di codice dannoso, di un'intrusione o di dati usciti.
- L'hoster ha bloccato il servizio o richiede una bonifica.
- La Sua versione di PHP è vecchia o non chiarita e non sa se le vulnerabilità PHP2Shell siano state sfruttate.
- La Sua IT interna o l'agenzia non è raggiungibile o non ha esperienza con gli incidenti.

Il sospetto basta. Se può cavarsela da solo o se ha bisogno di supporto lo si può valutare con la pagina [Risolvere da soli o chiamare un fornitore?](https://phpsos.de/it/blog/selbst-beheben-oder-dienstleister/).

## Che cosa fare subito

1. **Congelare lo stato.** Nessuna modifica al server, nessuna operazione di pulizia, nessun aggiornamento alla cieca.
2. **Elencare gli accessi.** Quali accessi a pannello, SSH, CMS e database esistono e chi li gestisce?
3. **Informare l'hoster.** Gli chieda di conservare log e snapshot. Non nasconda nulla di ciò che deve sapere.
4. **Stabilire il decisore.** Chi in azienda autorizza spegnimenti, riavvii e cambi di password?
5. **Chiarire la situazione dei dati.** Sul sistema ci sono dati personali, dati di pagamento o segreti aziendali?
6. **Informare gli interessati.** Il responsabile della protezione dei dati e, se esiste, l'assicuratore cyber.
7. **Incaricare il fornitore.** Ci chiami o ci scriva su WhatsApp. Ce ne occupiamo dal primo messaggio.

## Come si svolge l'incarico

Un'emergenza non tollera un lungo iter contrattuale, ma non tollera nemmeno lacune in materia di responsabilità e protezione dei dati. Per questo procediamo in quest'ordine:

1. **Primo colloquio:** ascoltiamo la situazione e poniamo le poche domande necessarie per una prima valutazione.
2. **Concordare il perimetro:** chiariamo insieme quali sistemi possiamo verificare, chi decide e come ci scambiamo le informazioni.
3. **Regolare la protezione dei dati:** se accediamo a sistemi con dati personali, discutiamo l'accordo necessario sul trattamento per conto terzi. I fondamenti sono spiegati nella pagina [Trattamento per conto terzi con accesso al server](https://phpsos.de/it/blog/auftragsverarbeitung-serverzugriff/).
4. **Predisporre l'accesso:** ci dà solo i diritti necessari per l'incarico. Al termine gli accessi vengono revocati.
5. **Lavoro e relazioni:** ci facciamo sentire con aggiornamenti intermedi e mettiamo per iscritto i risultati.

Come confrontare in generale i fornitori lo spiega [Scegliere un fornitore di sicurezza IT: 12 domande](https://phpsos.de/it/blog/sicherheitsdienstleister-auswaehlen/). Gli obblighi contrattuali in materia di sicurezza sono trattati in [Contratti con i fornitori: regolare con chiarezza gli obblighi di sicurezza](https://phpsos.de/it/blog/dienstleistervertrag-sicherheit/).

## In concreto, come aiuta PHP SOS?

1. **Quadro della situazione:** che cosa è successo, quali server sono in funzione, quali versioni di PHP e quale modalità di esecuzione (PHP-FPM, mod_php, LiteSpeed) sono in uso?
2. **Salvare e chiudere:** salviamo log, file e database. Poi eliminiamo la causa: patch, configurazione o blocco degli accessi, con riavvio di tutti i processi PHP.
3. **Verificare e bonificare:** cerchiamo web shell, backdoor, cronjob e accessi estranei e li rimuoviamo, oppure ricostruiamo da fonti pulite.
4. **Rafforzare e riferire:** riceve una relazione con linea temporale, ritrovamenti e raccomandazioni. Per incidenti più estesi passiamo a una [Incident response](https://phpsos.de/it/leistungen/incident-response/).

Se in un primo momento si tratta solo della vulnerabilità PHP e della prova della patch, è adatta l'[assistenza urgente PHP2Shell per aziende](https://phpsos.de/it/leistungen/php2shell-soforthilfe/). Se c'è codice dannoso, il punto di partenza giusto è la [rimozione del malware](https://phpsos.de/it/leistungen/malware-entfernung/).

## Come riconoscere un fornitore di emergenza serio

In un'emergenza molti si rivolgono al primo fornitore che capita. Tre domande aiutano a fare ordine in pochi minuti. Primo: si salva prima e si modifica solo dopo? Chi «mette in ordine» subito, compromette il chiarimento successivo. Secondo: viene messo per iscritto ciò che è stato trovato e fatto? Senza documentazione né assicuratori né responsabili della protezione dei dati possono farne qualcosa. Terzo: vengono indicati i limiti? Con un fornitore che dichiara tutto fattibile prima di aver visto il sistema occorre prudenza.

Verifichi anche se il fornitore comprende la Sua modalità di esecuzione. PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed si comportano in modo diverso nella patch, e dopo l'aggiornamento tutti i processi devono essere riavviati, altrimenti nella memoria continua a girare il vecchio stato.

## Che cosa un fornitore di emergenza non può fare

Conviene conoscere in anticipo i limiti. Nessun fornitore può ricostruire a posteriori log che non sono mai stati scritti o sono già stati sovrascritti. Se mancano tracce, indichiamo apertamente le lacune. Nessuno può nemmeno assicurare che un sistema bonificato non verrà mai più attaccato. E la consulenza legale non fa parte del nostro incarico: le domande su obblighi di notifica, responsabilità e assicurazione vanno a responsabile della protezione dei dati, avvocato e assicuratore, ai quali forniamo i fatti tecnici.

## Che cosa dovrebbe inviarci

- breve descrizione dell'incidente e del momento in cui è emerso
- domini e server interessati e, per quanto nota, la versione di PHP
- nome dell'hoster e tipo di contratto (hosting condiviso, vServer, root server, server gestito)
- una persona di riferimento con potere decisionale
- i backup esistenti e il loro stato

## Perché PHP SOS

Lavoriamo Made in Germany e da oltre 25 anni, con la nostra rete di partner di professionisti della cybersicurezza, ci specializziamo nella sicurezza informatica. Parla con un interlocutore fisso, lavoriamo da remoto in tutta la Germania e in Europa e documentiamo ogni passaggio. Diciamo apertamente che cosa è provato e che cosa no, e non facciamo promesse che nessun fornitore serio può fare. Il nostro ordine è sempre lo stesso: prima salvare, poi modificare, poi riferire.

## È stato colpito? Ci chiami. La aiutiamo.

Non continui a cercare il fornitore adatto mentre l'incidente è in corso. Ci chiami o ci scriva su WhatsApp: ce ne occupiamo dal primo messaggio. [Segnali subito l'emergenza](https://phpsos.de/it/notfall/).


## Domande frequenti

**Come riconosco un buon fornitore per le emergenze IT?**  
Conserva le tracce prima di cambiare qualcosa, distingue apertamente tra ciò che è provato e ciò che è supposto, documenta ogni passaggio e non promette miracoli. Diffidi di affermazioni come «tutto garantito pulito», perché nessuno può assicurarlo con serietà.

**Di quali accessi ha bisogno un fornitore in un'emergenza IT?**  
Di regola dell'accesso SSH o al pannello del server, dell'accesso al backend del CMS e al database oppure della Sua autorizzazione a parlare con l'hoster. Dia solo ciò che serve e annoti chi ha ricevuto quale accesso e quando.

**Per l'accesso remoto mi serve un contratto di trattamento dei dati?**  
Se un fornitore accede a sistemi con dati personali, di norma serve una disciplina del trattamento per conto terzi (art. 28 GDPR). La valutazione spetta al responsabile della protezione dei dati o agli avvocati. Lo chiariamo con Lei fin dall'inizio.

**Qual è la differenza tra incident response e rimozione del malware?**  
La rimozione del malware ripulisce un sistema infetto. L'incident response ha una portata più ampia: comprende quadro della situazione, contenimento, bonifica, comunicazione e follow-up, spesso su più sistemi.

**Devo coinvolgere il mio hoster?**  
Spesso sì, ad esempio per snapshot, log o la rimozione di blocchi. Ci coordiniamo con il Suo hoster, se Lei lo consente. Che cosa si possa verificare dipende dai diritti che riceviamo.

## Fonti

- [BSI: Ufficio federale tedesco per la sicurezza informatica](https://www.bsi.bund.de/)
- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [GDPR art. 33: notifica all'autorità di controllo](https://dsgvo-gesetz.de/art-33-dsgvo/)