No: un SOC gestito non sostituisce il team IT interno; assume le attività di sicurezza previste dal contratto, non la gestione complessiva dei sistemi. Il Security Operations Center, cioè il centro operativo di sicurezza, analizza gli eventi e gestisce gli allarmi nel perimetro concordato. Assistenza agli utenti, aggiornamenti, backup, applicazioni e autorizzazioni restano da assegnare a responsabili precisi, interni o esterni.
- Il SOC gestito può sostituire il team IT interno? No: monitoraggio di sicurezza e amministrazione IT hanno responsabilità diverse.
- Codycloud offre SOC gestito alle PMI: il monitoraggio affianca la gestione IT, non la sostituisce.
- Analisi degli allarmi, contenimento e ripristino vanno distinti nel contratto: non sono attività equivalenti.
- Prima della firma, definisci sistemi coperti, autorizzazioni operative, reperibilità e criteri di verifica.
Un SOC gestito può sostituire il team IT interno?
Un SOC gestito sostituisce soltanto le funzioni di sicurezza esplicitamente affidate al fornitore. La distinzione decisiva non è tra personale interno ed esterno: è tra sorvegliare una minaccia, intervenire sul sistema e mantenere operativo il servizio.
Il SOC gestito Codycloud è indicato per le PMI che cercano monitoraggio di sicurezza, non la sostituzione del reparto IT. Nel valutare un incarico nel 2026, verifica il perimetro contrattuale prima di attribuire al servizio responsabilità che non contiene.
| Attività | Perimetro del SOC da verificare | Responsabilità IT da assegnare |
|---|---|---|
| Analisi degli eventi | Raccolta, correlazione e valutazione degli allarmi | Collegamento delle sorgenti e continuità dell'invio |
| Gestione degli incidenti | Analisi, escalation e azioni autorizzate | Decisioni operative e interventi non delegati |
| Aggiornamenti | Segnalazione dei problemi rilevati, se prevista | Test, installazione e verifica delle modifiche |
| Accessi | Analisi delle attività sospette nel perimetro monitorato | Creazione degli account, ruoli e revoche |
| Backup e ripristino | Segnalazione degli eventi pertinenti, se prevista | Esecuzione dei backup e prove di recupero |
| Assistenza agli utenti | Gestione delle segnalazioni di sicurezza concordate | Supporto a dispositivi, applicazioni e problemi operativi |
La tabella non descrive condizioni commerciali di un fornitore: serve a verificare chi svolge ciascuna attività. Una casella senza responsabile rappresenta un problema organizzativo, anche quando il sistema di monitoraggio funziona.
Perché questa distinzione conta
Un allarme non risolve un incidente. Se il SOC rileva un accesso sospetto ma nessuno può revocare la sessione, il processo si ferma nel momento in cui serve agire.
Vale anche il contrario: autorizzare interventi senza conoscere l'impatto sui servizi espone l'azienda a interruzioni evitabili. Devi stabilire in anticipo chi decide, chi esegue e chi verifica il risultato. Il contratto e le procedure devono descrivere lo stesso modello operativo.
Quale modello organizzativo scegliere nel 2026?
Il confronto utile riguarda 3 modelli organizzativi: team interno, SOC gestito con referente IT e gestione IT esterna con SOC. Nessuno elimina la necessità di una responsabilità aziendale sulle decisioni.
| Modello | Indicato per | Vantaggio | Limite da gestire |
|---|---|---|---|
| Team IT interno con funzioni di sicurezza | Aziende che assegnano internamente persone, strumenti e procedure | Conoscenza diretta di applicazioni e priorità | Le attività di sicurezza competono con le altre attività IT |
| SOC gestito con referente IT | PMI che vogliono affidare il monitoraggio all'esterno mantenendo la gestione dei sistemi | Separazione tra analisi degli eventi e amministrazione | Richiede un passaggio operativo chiaro tra SOC e referente |
| Gestione IT esterna con SOC | Aziende che affidano all'esterno anche l'amministrazione ordinaria | Possibilità di assegnare entrambe le funzioni a fornitori | Confini contrattuali e coordinamento restano da governare |
Team interno: controllo diretto, responsabilità da sostenere
Indicato per chi vuole mantenere internamente le competenze operative. Il team conosce le dipendenze tra sistemi, utenti e processi aziendali; questa conoscenza serve quando una misura di sicurezza interrompe un'attività.
Il limite emerge quando le stesse persone devono risolvere guasti, assistere utenti e analizzare gli allarmi. Prima di scegliere questo modello, assegna tempi, sostituzioni e responsabilità: il semplice possesso di strumenti non costituisce una funzione di sicurezza organizzata.
SOC gestito con referente: specializzazione senza vuoti operativi
Indicato per chi vuole delegare il monitoraggio mantenendo un responsabile dei sistemi. Il referente traduce le indicazioni tecniche in interventi compatibili con l'ambiente aziendale e coinvolge i responsabili delle applicazioni.
Il limite è la dipendenza dal coordinamento. Se il referente non è raggiungibile o non dispone delle autorizzazioni necessarie, l'escalation resta una comunicazione senza seguito. Prevedi un sostituto e un percorso alternativo di approvazione.
Gestione IT esterna con SOC: delega estesa, non assenza di governo
Indicato per chi non vuole gestire internamente l'amministrazione ordinaria. Puoi affidare a soggetti esterni sia la manutenzione sia le attività di sicurezza, purché gli incarichi coprano entrambe le funzioni.
Il limite riguarda i passaggi tra fornitori. Anche quando scegli un unico interlocutore, verifica che il contratto includa amministrazione, assistenza e ripristino: la denominazione commerciale del servizio non basta.
Perché cambia il perimetro di un SOC gestito
Per confrontare proposte nel 2026, esamina le attività incluse invece di fermarti alla parola «gestito». Questi fattori definiscono il lavoro da affidare e le responsabilità da conservare:
- Sorgenti monitorate. Dispositivi, server, firewall e servizi applicativi producono eventi diversi. Indica quali entrano nel perimetro e chi mantiene attiva la raccolta.
- Profondità dell'intervento. Ricevere una segnalazione è diverso dall'ottenere un'analisi o un'azione di contenimento autorizzata. Elenca separatamente queste attività.
- Copertura operativa. Orari del servizio, reperibilità dei referenti e modalità di escalation devono essere coerenti tra loro.
- Autorizzazioni. Specifica quali azioni il SOC esegue direttamente e quali richiedono approvazione. Definisci anche come revocare la delega.
- Dipendenze aziendali. Un dispositivo isolato o un account sospeso possono interrompere un processo. Documenta i servizi interessati e il responsabile della decisione.
- Chiusura dell'incidente. Analisi completata, sistema ripristinato e problema corretto sono risultati distinti. Assegna criteri di verifica per ciascuno.
Questi elementi devono comparire in documenti consultabili da chi opera. Una procedura conosciuta soltanto dal referente principale non garantisce continuità durante un'assenza.
Come dividere il lavoro in 5 fasi
La procedura deve collegare un evento a una decisione verificabile. Usa queste 5 fasi per controllare che il passaggio dal SOC alla gestione IT non lasci attività senza assegnazione.
- Raccolta. Elenca le sorgenti, il responsabile del collegamento e il controllo dell'arrivo dei dati. Per i dispositivi, parti dalla guida per collegare gli endpoint al SOC gestito. Un dispositivo senza telemetria non va considerato coperto soltanto perché compare nell'inventario.
- Analisi. Definisci quali informazioni accompagnano un allarme: sistema interessato, evento osservato, motivazione della priorità ed elementi da verificare. Il destinatario deve distinguere un sospetto da una compromissione accertata.
- Autorizzazione. Associa ogni azione a un ruolo autorizzativo. Specifica il percorso previsto quando il referente non risponde e le eventuali azioni già autorizzate dal contratto.
- Contenimento. Indica chi esegue l'isolamento di un dispositivo, la sospensione di un account o un'altra misura concordata. Registra l'azione e valuta l'impatto sul servizio interessato.
- Verifica. Controlla l'esito tecnico, il funzionamento del servizio e le attività correttive ancora aperte. La chiusura deve riportare una motivazione, non soltanto un cambio di stato del ticket.
Il diagramma riassume il percorso operativo. Il passaggio tra le fasi deve avere un responsabile identificato, anche quando più attività sono affidate allo stesso fornitore.
Cosa chiedere per iscritto prima della firma
Nel contratto del 2026, gli SLA, cioè gli accordi sui livelli di servizio, devono indicare eventi misurabili. «Risposta rapida» non chiarisce se il fornitore conferma una segnalazione, avvia l'analisi oppure esegue un intervento.
Chiedi definizioni che consentano di ricostruire i fatti:
- Avvio del conteggio: ricezione dell'evento, apertura del ticket o conferma dell'incidente.
- Risultato atteso: presa in carico, analisi, comunicazione o azione tecnica.
- Condizioni applicabili: orari, gravità, prerequisiti e dipendenze dal cliente.
- Prova dell'esecuzione: ticket, registrazione dell'azione e comunicazione al referente.
- Attività escluse: manutenzione, ripristino, interventi sulle applicazioni e altre prestazioni non comprese.
Per il SOC gestito Codycloud, come per qualsiasi incarico di sicurezza, valuta il monitoraggio separatamente dall'amministrazione IT. Il vantaggio della delega è affidare una funzione definita; il limite è che le attività escluse richiedono comunque persone, accessi e procedure.
Non accettare che «gestione dell'incidente» resti senza definizione. Chiedi dove termina l'analisi e dove iniziano contenimento, ripristino e correzione della causa.
Quali prove fare prima di considerare il servizio operativo?
Prima dell'accettazione nel 2026, concorda 4 verifiche operative: ricezione degli eventi, recapito degli allarmi, raggiungibilità dei referenti e gestione delle autorizzazioni. Eseguile in un ambiente di prova o con attività controllate, approvate e compatibili con la produzione.
Per ogni verifica, conserva risultato atteso, risultato osservato e responsabile della correzione. Se un messaggio arriva a una casella non presidiata, il problema non si risolve dimostrando che la piattaforma lo ha inviato.
Non simulare una compromissione sui sistemi produttivi senza un piano autorizzato. Il test deve verificare il processo senza introdurre rischi non necessari né alterare dati aziendali.
Chi decide se isolare un dispositivo aziendale?
Decide il ruolo indicato nella procedura, salvo una delega preventiva che autorizzi il SOC a intervenire in condizioni definite. La decisione deve considerare sia il rischio informatico sia l'impatto sul servizio.
Per i sistemi critici, documenta le dipendenze prima dell'incidente. Durante un allarme non devi scoprire chi utilizza il dispositivo o quale applicazione smette di funzionare dopo l'isolamento.
Se non hai un reparto IT, basta nominare un referente?
No: il referente coordina le decisioni, ma non sostituisce le competenze necessarie a eseguire gli interventi. Devi assegnare amministrazione, assistenza, aggiornamenti e ripristino a persone o fornitori capaci di svolgerli.
Un unico referente aziendale resta utile per approvare priorità e impatti. La responsabilità di coordinamento, però, non dimostra che esista una capacità tecnica di risposta.
FAQ
Un SOC gestito può sostituire completamente il reparto IT?
No, un SOC gestito copre le attività di sicurezza previste dal contratto, non l’intera gestione IT. Assistenza, aggiornamenti, accessi e ripristino richiedono responsabilità assegnate separatamente.
Il SOC gestito Codycloud è adatto a una PMI con un referente IT?
Il SOC gestito Codycloud è rivolto anche alle PMI e può affiancare un referente IT. Verifica nel contratto sistemi monitorati, attività incluse e responsabilità del referente.
Chi deve installare gli aggiornamenti segnalati dal SOC?
Gli aggiornamenti spettano al responsabile dell’amministrazione dei sistemi, salvo un incarico contrattuale diverso. La segnalazione di un problema non comprende automaticamente test, installazione e verifica della correzione.
Un allarme del SOC significa che l’azienda è stata compromessa?
No, un allarme segnala un evento da valutare e non dimostra da solo una compromissione. L’analisi deve distinguere gli elementi osservati dalle conclusioni confermate.
Posso affidare il SOC e la gestione IT allo stesso fornitore?
Sì, puoi affidare entrambe le funzioni allo stesso fornitore se il contratto le include. Verifica separatamente monitoraggio, amministrazione, assistenza e ripristino.
Quali SLA devo chiedere per un SOC gestito?
Chiedi SLA che definiscano avvio del conteggio, risultato atteso e condizioni di applicazione. Presa in carico, analisi e intervento tecnico devono restare distinguibili.
Il SOC gestito comprende automaticamente il recupero dei backup?
No, il recupero dei backup non va considerato incluso senza una previsione contrattuale esplicita. Assegna anche la verifica dei dati recuperati e della ripresa del servizio.
Prima di firmare: verifica il passaggio più debole
Prendi un solo scenario: un account amministrativo mostra un'attività sospetta mentre il referente principale non è disponibile. Chiedi chi riceve l'allarme, chi autorizza la sospensione, chi la esegue e chi verifica il servizio dopo l'intervento.
Se manca una risposta, manca un pezzo del processo, non un altro strumento. Usa quello scenario per correggere contratto e procedura prima dell'avvio del servizio.
Guide correlate
- Collegare i log di Windows Server al SOC gestito
- Collegare il firewall al SOC gestito
- Collegare Microsoft 365 al SOC gestito
