# Creare un piano di emergenza IT per i web server

> Creare un piano di emergenza IT per i web server: ruoli, contatti, inventario dei sistemi, regole decisionali e vie di notifica, per essere pronti nel caso concreto.

Fonte: https://phpsos.de/it/compliance/notfallplan-erstellen/  
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:** un piano di emergenza IT per i web server stabilisce in anticipo chi decide nel caso concreto, chi si può raggiungere, quali sistemi possono essere interessati e quali passaggi seguono in quale ordine. Chi vuole creare un piano di emergenza IT non ha bisogno di un manuale voluminoso, ma di poche pagine aggiornate, raggiungibili anche senza IT funzionante. La situazione intorno a PHP2Shell è una buona occasione per farlo adesso.

## Perché un piano di emergenza fa risparmiare tempo e danni

Nel caso concreto le prime ore vanno spesso perse a cercare: chi ha l'accesso all'hoster? Dove sono i backup? Chi decide se lo shop va offline? Chi deve essere informato? Un piano di emergenza risponde a queste domande prima, con calma.

PHP2Shell ha mostrato quanto possa essere breve il tempo. Il 20/10/2026 php.net ha annunciato le patch, il 21/10 alle 16:00 ora tedesca sono state pubblicate e il BSI (l'Ufficio federale tedesco per la sicurezza informatica) ha raccomandato l'aggiornamento immediato o lo spegnimento temporaneo. Le aziende con un piano sapevano chi chiamare e quali server controllare. Altre hanno dovuto prima scoprire dove giri PHP.

## Creare un piano di emergenza IT: i componenti

Un piano pratico per i web server comprende queste parti:

**1. Ruoli e decisioni.** Chi guida nell'emergenza, chi sostituisce, chi può spegnere i sistemi, chi parla verso l'esterno? Annoti nomi e sostituti.

**2. Elenco dei contatti.** Referenti interni, hoster, agenzia, fornitore di servizi IT, responsabile della protezione dei dati, consulenza legale, assicurazione cyber con numero di polizza, autorità di controllo della protezione dei dati competente, il punto di contatto centrale Cybercrime del Suo Land. Questo elenco deve essere disponibile stampato.

**3. Inventario dei sistemi.** Ogni sito web, shop e portale con server, hoster, modalità di esecuzione, versione di PHP, applicazione, responsabile e tipo di dati trattati.

**4. Regole decisionali.** A quali condizioni mettiamo un sistema offline? Chi può deciderlo? Che cosa vale di notte e nel fine settimana?

**5. Procedure.** Brevi sequenze di passaggi per i casi tipici: vulnerabilità critica nota, sospetto di intrusione, sito deturpato, dati fuoriusciti, estorsione.

**6. Vie di notifica.** Chi verifica un obbligo di notifica ai sensi dell'art. 33 GDPR, possibilmente entro 72 ore dal momento in cui se ne ha conoscenza? Chi notifica al BSI in caso di obbligo NIS2? Chi informa l'assicuratore?

**7. Ripristino.** Dove sono i backup, chi può ripristinarli, quanto tempo richiede, quando è stato testato per l'ultima volta?

## Esempio: procedura «vulnerabilità PHP critica»

Una procedura può presentarsi così, come è servita con PHP2Shell:

| Passaggio | Chi | Risultato |
|---|---|---|
| Valutare la segnalazione (php.net, BSI) | Responsabili IT | sistemi interessati secondo l'inventario |
| Installare l'aggiornamento, riavviare tutti i worker | Amministratore o fornitore di servizi | Prova con stato dei pacchetti e orario dei processi |
| Dove non è possibile l'aggiornamento: misure transitorie o offline | Decide la direzione | decisione documentata |
| Salvare i log, cercare tracce | Amministratore o analisi forense | riscontro o nessun riscontro |
| In caso di riscontro: avviare la procedura di incidente | Direzione dell'emergenza | verificare le vie di notifica |

Importante: una patch chiude la vulnerabilità, ma non rimuove il malware introdotto prima. Per questo la ricerca di tracce rientra stabilmente nella procedura.

> **Consiglio:**
> Stabilisca per quanto tempo si conservano i log del web server e dove si trovano al di fuori del server. Con PHP2Shell la stampa specializzata ha raccomandato di conservare i log a partire dal 20/10/2026. Chi conserva i log solo per pochi giorni non può attuare simili raccomandazioni.

## Prevenzione che rende efficace il piano

Un piano vale quanto le condizioni che ci stanno dietro. Verifichi se esistono backup secondo la regola 3-2-1 e se sono testati, vedi [Backup secondo la regola 3-2-1](https://phpsos.de/it/ratgeber/backups-3-2-1/). Chiarisca per iscritto con hoster e agenzia chi si assume che cosa in caso di vulnerabilità critiche. Tenga a disposizione le credenziali di accesso per le emergenze, in modo sicuro ma raggiungibile, ad esempio in un password manager protetto con accesso di emergenza.

Prepari inoltre modelli di testo: informazione interna, comunicazione ai clienti, avviso su una pagina statica di manutenzione. Indicazioni in merito si trovano alla pagina [Comunicazione di crisi dopo un attacco](https://phpsos.de/it/compliance/krisenkommunikation/).

## Esercitarsi e mantenere aggiornato

Un piano mai esercitato contiene quasi sempre lacune. Una volta all'anno simuli uno scenario, ad esempio «vulnerabilità PHP critica il venerdì pomeriggio», e annoti dove si inceppa. Per cominciare basta un test semplice: una seconda persona riesce, senza l'aiuto della prima, a raggiungere l'hoster, ripristinare un backup e mettere il sito in modalità di manutenzione? Se no, nel piano manca qualcosa, per lo più un accesso, un numero di telefono o una descrizione. Proprio queste lacune le esercitazioni devono rendere visibili, prima che si faccia sul serio. Aggiorni il piano dopo ogni esercitazione e dopo ogni modifica sostanziale. Come cornice metodologica si prestano l'IT-Grundschutz del BSI e lo standard BSI 200-4 sul Business Continuity Management.

Le questioni giuridiche, ad esempio sugli obblighi di notifica, il piano non le chiarisce in modo definitivo. Fa sì che le persone giuste vengano coinvolte per tempo. Questa pagina è un'informazione generale e non costituisce consulenza legale.

## Come aiuta concretamente PHP SOS?

- Creiamo con Lei l'inventario dei sistemi dei Suoi web server, comprese modalità di esecuzione e versione di PHP.
- Scriviamo le procedure tecniche per gli scenari tipici e le concordiamo con hoster e agenzia.
- Conduciamo un'esercitazione e riportiamo i risultati nel piano.
- Nel caso concreto ci occupiamo del lato tecnico tramite l'[incident response](https://phpsos.de/it/leistungen/incident-response/), su richiesta con la copertura di un [contratto di manutenzione della sicurezza](https://phpsos.de/it/leistungen/security-wartungsvertrag/).


## Domande frequenti

**Quanto deve essere ampio un piano di emergenza IT?**  
Il più breve possibile, il più dettagliato necessario. Per i web server bastano spesso poche pagine con contatti, elenco dei sistemi, regole decisionali e procedure. Più dell'ampiezza conta che sia aggiornato e che nel caso concreto lo si trovi.

**Dove conservo il piano di emergenza?**  
In almeno un luogo raggiungibile anche senza IT funzionante, ad esempio stampato o su un dispositivo separato. Un piano che si trova solo sul server interessato o nella rete aziendale bloccata non serve nel caso concreto.

**Ogni quanto va verificato il piano?**  
Almeno una volta all'anno e dopo ogni modifica sostanziale, ad esempio un cambio di hoster o un nuovo software. È sensata una breve esercitazione in cui si simula uno scenario.

**Esistono modelli del BSI?**  
Il BSI tratta la gestione delle emergenze nell'ambito dell'IT-Grundschutz e nello standard BSI 200-4 sul Business Continuity Management. Si prestano come cornice; per i web server vale la pena redigere una versione concisa e pratica.

## Fonti

- [IT-Grundschutz del BSI](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [BSI](https://www.bsi.bund.de/)
- [Art. 33 GDPR](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [Polizia: panoramica delle ZAC](https://www.polizei.de/)
