Introduzione: La Cybersecurity nella PA come Servizio Essenziale

L’evoluzione del pericolo: Da compliance a resilienza operativa

Perché l’approccio tradizionale (SIEM on-premise) non basta più

Il Contesto Normativo Italiano: Il Quadro Legale del SOC per la PA

GDPR e notifica Data Breach: Il ruolo del SOC come earliest warning

NIS2 Directive e le nuove sanzioni: Cosa cambia per Comuni e Enti Pubblici

Acquisizioni Pubbliche: Bando Gare e criteri di aggiudicazione per il SOCaaS

Cloud da Pubblica Amministrazione (SPC): Integrazione con il fornitore SOC

Definizioni e Modelli Operativi: SOC on-premise vs SOC as a Service

La struttura del SOC: L’importanza del triage e delle Threat Intelligence

Managed Detection and Response (MDR) vs SOC tradizionale: Quale serve alla PA?

Analisi dei costi Total Cost of Ownership (TCO) vs OPEX nel modello SaaS

Framework di Valutazione: I 6 Pilastri per la Scelta del Partner

1. Competenze Tecniche: Log Management, EDR e analisi comportamentale

2. Coverage e Integrazione: Endpoint, Cloud, Network e Identità

3. SLA e Incident Response: Tempi di risposta e orchestrazione degli interventi

3. SLA e Incident Response: Tempi di risposta e orchestrazione degli interventi

Nel mondo della sicurezza informatica per la Pubblica Amministrazione, gli SLA (Service Level Agreement) sono il contratto sociale tra il fornitore e l’ente. Definiscono con precisione matematica cosa aspettarsi, eliminando ambiguità che potrebbero costare caro in caso di incidente. Per una PA, un ritardo nella risposta non è solo un disservizio tecnico, ma può configurare un rischio di interruzione di servizi essenziali per i cittadini. Valutare il partner non solo sulle promesse, ma sulla capacità di orchestrazione degli interventi.

Il cuore di ogni SLA è il Tempo di Risposta. Non tutti gli eventi hanno la stessa priorità. Un buon fornitore deve distinguere chiaramente tra:

• Incidente critico (P1): Ransomware, interruzione totale di servizi pubblici, violazione massiccia di dati personali. Target: risposta entro 15 minuti (24/7), avvio del containment in meno di un’ora. Il silenzio radio è inaccettabile.
• Incidente alto (P2): Tentativi di intrusione rilevati, servizi degradati, exploit su sistemi non critici. Target: risposta entro 1 ora, investigazione iniziale entro 4 ore.
• Incidente medio (P3): Vulnerabilità software, attività sospette isolate. Target: risposta entro 4 ore lavorative.
• Richiesta di supporto (P4): Falsi positivi, richieste informative. Target: risposta entro 1-2 giorni lavorativi.

Oltre ai tempi, il fattore chiave è l’Orchestrazione degli Interventi. La tecnologia SOC 24/7 (SIEM, XDR) genera allarmi, ma l’efficacia deriva dalla capacità di orchestrare la risposta. Chiedi al partner come integra le sue procedure con quelle della tua PA. Esempio pratico: il SOC rileva un attacco. L’orchestrazione non si limita a notificare via email. Attiva un playbook automatizzato che isola la workstation compromessa, avvisa l’RSPP della PA, blocca l’accesso ai database critici e avvia il processo di evidenza digitale per eventuali autorità investigative (come il Nucleo Speciale di Polizia Postale).

Un dettaglio fondamentale per la PA è la Gestione delle Comunicazioni. In caso di P1, il fornitore deve garantire una conference bridge dedicata immediata, coinvolgendo non solo il CISO della PA, ma anche il Dirigente responsabile del servizio interrotto e, se necessario, l’ufficio stampa istituzionale. La tempestività è tutto: una violazione di dati va notificata al Garante Privacy (DPA) entro 72 ore dalla scoperta. Un partner SOC as a service in Italia deve avere esperienza diretta con le procedure normative italiane ed europee (NIS2, GDPR), essendo in grado di tradurre tecnicismi in report comprensibili per le corti o per gli organi di controllo.

Attenzione alle “fini di settimana lunghe”: gli SLA devono coprire 365 giorni all’anno. Un ente pubblico non si ferma mai; la sicurezza nemmeno. Valuta attentamente se il provider offre Back-up del SOC (in caso di guasto del centro primario) e garantisce lo stesso livello di servizio tramite team duplicati.

Prima di firmare, richiedi simulazioni di incident response. È l’unico modo per testare, in un ambiente controllato, se i tempi dichiarati sono una realtà operativa o solo una clausola contrattuale. In un contesto di risorse limitate e budget vincolati, la rapidità di reazione è il miglior investimento in sicurezza.

4. Trasparenza e Reportistica: Dashboards per il CIO e report per l’AGID

4. Trasparenza e Reportistica: Dashboards per il CIO e report per l’AGID

Per una Pubblica Amministrazione, la trasparenza non è solo un requisito normativo, ma un pilastro fondamentale per la fiducia verso i cittadini e verso gli enti di controllo. Valutare come il fornitore di SOC as a Service comunica lo stato di sicurezza è quindi cruciale. Il partner giusto deve offrire visibilità continua e chiara, traducendo dati complessi in informazioni utili per decisioni strategiche e conformità normativa.

Dashboards in tempo reale per il CIO e la Direzione

Il Chief Information Officer (CIO) e la Direzione IT necessitano di una visione immediata e contestualizzata del proprio assetto di sicurezza. Una dashboard efficace non deve limitarsi a mostrare il numero di allarmi, ma deve rispondere a domande strategiche: qual è il mio livello di esposizione al rischio? Quali asset sono più critici? Quale trend di minacce stiamo osservando?

Un buon dashboard per il CIO include solitamente:

• Indici di rischio calcolati: Valutazioni quantitative del rischio basate su vulnerabilità e impatto potenziale, che permettono di priorizzare gli interventi.
• MTTD e MTTR: Tempo medio di rilevamento (Mean Time to Detect) e tempo medio di risoluzione (Mean Time to Respond), indicatori chiave della prontezza dell’organizzazione.
• Coverage degli asset monitorati: La percentuale di dispositivi e reti effettivamente coperti dal servizio di sorveglianza.
• Heatmap delle minacce: Visualizzazione grafica delle tipologie di attacco più frequenti contro la PA (es. tentativi di phishing, ransomware, DDoS) e dei settori più colpiti.

Questi strumenti non sono solo di monitoraggio, ma consentono al CIO di dimostrare con dati oggettivi il valore dell’investimento in cybersecurity e di giustificare budget futuri.

Reportistica conforme per l’AGID e l’ANAC

Oltre alla gestione interna, la PA deve rispondere a obblighi stringenti. Il partner SOC deve fornire report automatizzati e standardizzati, pronti per essere presentati all’AGID (Agenzia per l’Italia Digitale) per quanto riguarda i requisiti di sicurezza dei sistemi informativi, e all’ANAC (Autorità Nazionale Anticorruzione) in contesti di gara o verifica.

Questi documenti non sono semplici estratti di dati, ma report di conformità che attestano l’avvenuto monitoraggio, l’analisi degli incidenti e le procedure di risposta applicate. La capacità del fornitore di fornire reportistica auditabile e facilmente comprensibile per i revisori contabili e legali riduce drasticamente il carico amministrativo e il rischio di non conformità.

Scegliere un partner che garantisca elevati standard di trasparenza significa investire in governance della sicurezza solida e misurabile.

5. Dati in Italia: Sovranità, Residenza e Data Sovereignty

Quando si sceglie un fornitore di SOC as a service per la Pubblica Amministrazione italiana, la gestione dei dati è un pilastro imprescindibile. La sovranità dei dati, intesa come la garanzia che i dati rimangano sotto la giurisdizione e il controllo italiano ed europeo, è fondamentale per la compliance normativa e per la sicurezza nazionale. È essenziale verificare che il partner scelto operi con server fisicamente ubicati in Italia o nell’Unione Europea, garantendo che nessun dato venga trasferito in giurisdizioni extra-UE senza adeguate tutele.

La residenza dei dati non è solo una questione tecnica, ma un requisito legale. Il fornitore deve essere in grado di dimostrare, attraverso certificazioni e report di audit, che i dati dei clienti, specialmente quelli sensibili della PA, siano archiviati e processati in conformità con il GDPR e con le specifiche linee guida dell’Agenzia per la Cybersicurezza Nazionale (ACN). La data sovereignty, o sovranità digitale, implica anche il controllo completo sui propri dati: il partner deve garantire l’accesso, la portabilità e la cancellazione dei dati in qualsiasi momento, senza vincoli tecnici o contrattuali.

Un’attenta valutazione di questi aspetti non solo mitiga i rischi legali e di sicurezza, ma rafforza la fiducia tra la PA e il suo partner tecnologico, assicurando che la trasformazione digitale avvenga su basi solide e compliant.

6. Esperienza nel Settore Pubblico: Casistica e referenze verificabili

Un partner affidabile per la cybersecurity della PA deve dimostrare esperienza diretta nel settore pubblico, caratterizzato da normative specifiche e processi contrattuali rigidi. La casistica reale è il miglior indicatore di affidabilità: chiedi casi di studio dettagliati su enti simili al tuo, con problemi analoghi (es. compliance GDPR, continuità operativa, gestione incidenti). Verifica referenze contattando direttamente gli enti citati, preferibilmente tramite il tuo ufficio gare o tecnico. Chiedi specificamente come il partner ha gestito la gestione degli accessi privilegiati, la patch management in ambienti eterogenei e la documentazione per auditor esterni. Attenzione alle “referenze generiche” senza contatti diretti. Un fornitore maturo conosce il ciclo di vita degli appalti pubblici, le tempistiche e le esigenze di trasparenza, garantendo soluzioni scalabili e non dipendenti da vendor specifici.

Aspetti Contrattuali e Vendor Lock-in nella PA

La scelta di un partner per un SOC as a Service in Italia, specialmente per una Pubblica Amministrazione, non è una mera decisione tecnica, ma un atto di governo che si traduce in un vincolo contrattuale di medio-lungo periodo. Il rischio più sottile e insidioso in questo contesto è il vendor lock-in, ovvero la dipendenza eccessiva da un unico fornitore che può rendere complessa, costosa o addirittura impossibile la migrazione verso alternative future, minando l’autonomia decisionale dell’Ente.

Per evitare che il contratto diventi una gabbia, è fondamentale analizzare con precisione gli aspetti contrattuali prima della firma. Di seguito, una guida operativa per la valutazione.

1. La clausola di exit e la portabilità dei dati

Il punto più critico. Il contratto deve prevedere una clausola di recesso dettagliata (exit strategy) che non sia solo formale, ma tecnicamente attuabile. Chiediti:

• Formato dei log e dei dati: I dati (log, allerte, report) vengono forniti in formati standard e aperti (es. JSON, CSV, PDF/A) o in formati proprietari?
• Completezza: Il fornitore garantisce la consegna di tutta la storia dei dati e delle configurazioni ( asset inventory, regole di detection) in un formato leggibile e importabile?
• Costi di exit: Il contratto specifica costi aggiuntivi per l’estrazione e la migrazione dei dati? Una prassi corretta prevede che la restituzione dei dati sia inclusa nel canone o a costi di semplice ripristino (cost-based), non a scopo di lucro.
• Disattivazione: Sono previsti tempi tecnici certi per la disattivazione del servizio e la rimozione dei dati dai sistemi del provider (compliance GDPR)?

2. Service Level Agreement (SLA) misurabili e indipendenti

Nella PA, gli SLA non sono promesse di servizio, ma obblighi contrattuali la cui violazione deve comportare penali o crediti. Evita SLA vaghi come “risposta rapida”.

• MTTD (Mean Time to Detect): Tempo medio di rilevamento della minaccia. Obiettivo: < 30 minuti per criticità elevata.
• MTTR (Mean Time to Respond): Tempo medio di risposta/mitigazione. Obiettivo: < 1 ora per incident critico.
• Disponibilità del SOC: Servizio 24/7/365 con copertura anche nei festivi.
• Indipendenza delle metriche: Le metriche di performance devono essere misurate tramite sistemi di monitoraggio indipendenti (es. strumenti di telemetria) o dashboard condivise, non affidate esclusivamente all’autodichiarazione del fornitore.

3. Governance e trasparenza delle piattaforme

Il vendor lock-in non riguarda solo i dati, ma anche le tecnologie utilizzate. Spesso i SOC as a Service basano l’offerta su piattaforme proprietarie o licenze software complesse.

• Proprietà intellettuale: La PA deve avere chiaro chi possiede le configurazioni personalizzate (regole YARA, playbook di risposta) sviluppate dal provider durante il contratto.
• Open Source vs. Proprietario: Preferire fornitori che utilizzano stack tecnologici aperti o basati su licenze commerciali trasferibili (es. SIEM open source con supporto commerciale vs. piattaforme chiuse in SaaS). Se è SaaS, assicurati che l’export dei dati sia garantito contrattualmente.
• Audit e Visibilità: Il contratto deve garantire alla PA il diritto di audit (sia diretto che tramite terze parti certificate) sui processi operativi del SOC. Non poter vedere “dietro le quinte” è un forte indicatore di lock-in tecnico.

4. Clausole di compliance normativa e aggiornamento

La PA è soggetta a normative stringenti (GDPR, NIS 2, GDPR per le banche dati sanitarie, Codice dell’Amministrazione Digitale). Il contratto deve prevedere:

• Adeguamento normativo: Se cambia la legge (es. nuove direttive NIS 2 o linee guida ACN), il fornitore deve adeguare il servizio a proprio carico o specificare i costi aggiuntivi?
• Responsabilità: In caso di data breach causato da negligenza del SOC, la ripartizione delle responsabilità e le coperture assicurative (polizza RC professionale) devono essere chiare e adeguate al rischio.
• Sub-fornitori: Se il partner appalta parti del servizio (es. NOC in India), deve essere notificato e garantito lo stesso livello di compliance e sicurezza.

5. Canone e flessibilità economica

Il modello di pricing deve essere allineato alle esigenze di trasparenza della PA.

• Modello a consumo vs. Fisso: Il mercato offre modelli basati sul numero di endpoint, volume di log o utenti. Per la PA, un modello “fisso” o basato su blocchi scalabili è spesso più prevedibile, ma deve consentire la riduzione dei costi in caso di riduzione dell’infrastruttura.
• Rinegoziazione: Prevedere clausole di revisione del canone (es. annualmente) basate su KPI di efficienza o inflazione, evitando automatismi di rinnovo tacito a prezzi maggiorati.
• Costi nascosti: Verificare chiaramente i costi per formazione aggiuntiva, richieste di report speciali, interventi di consulenza fuori SLA o attivazione di nuovi connector per sistemi legacy.

Valutare questi aspetti richiede competenze trasversali (legali, tecniche e procurement). Una corretta stesura contrattuale trasforma il fornitore da un semplice venditore di servizi a un partner strategico, garantendo alla PA sicurezza, trasparenza e la libertà di scelta nel tempo.

Clause 24 e proprietarietà dei dati: Chi detiene i log delle attività?

Nella clausola 24 del regolamento 2022/2554 (DORA) e nelle linee guida per la sicurezza dei dati, la proprietà dei log delle attività di sicurezza è un punto critico e spesso dibattuto per la PA. La normativa stabilisce che il titolare del trattamento – nella maggior parte dei casi la pubblica amministrazione – rimane il soggetto principale responsabile della protezione dei dati personali.

Quando si valuta un fornitore di SOC as a service Italia per la PA, è fondamentale chiarire fin da subito la suddivisione dei ruoli e la gestione dei log. Il regolamento prevede che il fornitore (responsabile del trattamento) operi esclusivamente secondo le istruzioni del titolare, ma in caso di incidente di sicurezza la responsabilità legale e normativa resta in capo alla PA. Pertanto, la proprietà giuridica dei log delle attività di sicurezza – che contengono informazioni su accessi, tentativi di intrusione e altri eventi di sicurezza – deve essere definita nel contratto di fornitura.

Un partner affidabile deve garantire che i log siano conservati in un ambiente sicuro, in conformità con le normative vigenti, e che la PA abbia accesso completo e inalterato a tali dati. È anche importante che il fornitore non utilizzi i log per finalità proprie, salvo esplicita autorizzazione e nel rispetto dei principi di proporzionalità e trasparenza. Infine, la gestione dei log deve essere tracciata e documentata, con procedure chiare per la conservazione, la cancellazione e la notifica di eventuali violazioni. Una corretta definizione di questi aspetti nella clausola 24 protegge sia la PA che il fornitore, garantendo compliance normativa e sicurezza informatica.

Exit Strategy: Come evitare la dipendenza tecnologica dal provider

Un provider SOC as a service deve essere valutato anche per la sua capacità di gestire il passaggio di consegne in qualsiasi momento, senza creare lock‑in tecnologico o procedure blindate. Il contratto di outsourcing dei servizi di sicurezza per la PA, a norma del Codice degli Appalti, deve includere una chiara exit strategy per garantire continuità, trasparenza e rispetto del principio di rotazione.

Prima di firmare, chiedi chiarimenti su:

• Proprietà dei dati e configurazioni: tutte le informazioni (log, indici, policy, report) sono disponibili in formato standard (es. CSV, JSON, STIX) e scaricabili in qualsiasi momento?
• Documentazione tecnica operativa: viene fornita documentazione aggiornata su architettura, integrazioni, procedure di escalation e tutela della continuità operativa?
• Transizione assistita: il fornitore si impegna a un periodo di affiancamento (es. 60‑90 giorni) e a formare il tuo staff interno per gestire in autonomia i processi?
• Indipendenza dalle piattaforme: la soluzione è basata su tecnologie open‑source o standard documentati, evitando dipendenze da tool proprietari non trasferibili?

Verifica inoltre che il contratto preveda penali per mancata collaborazione durante l’exit e l’obbligo di trasferire ogni conoscenza necessaria. Una exit strategy ben definita preserva la tua autonomia strategica e ti permette di cambiare provider senza rischi per la sicurezza.

Service Level Agreement (SLA): KPI misurabili e penali per mancata osservanza

Service Level Agreement (SLA): KPI misurabili e penali per mancata osservanza

La corretta valutazione del partner SOC as a service per la Pubblica Amministrazione passa inevitabilmente attraverso la definizione di uno SLA stringente, che traduca i criteri di selezione in parametri oggettivi, misurabili e contrattualmente vincolanti. La definizione di KPI (Key Performance Indicator) specifici per la sicurezza informatica è essenziale per garantire trasparenza e accountability, specialmente in un contesto normativo come quello della sicurezza pubblica.

Un SLA efficace deve includere metriche concrete legate alla performance dei servizi. Tra i KPI più critici vi sono:

• MTTD (Mean Time to Detect): tempo medio di identificazione di una minaccia. Obiettivo ideale: inferiore a 1 ora.
• MTTR (Mean Time to Respond): tempo medio di contenimento ed erogazione del primo intervento. Obiettivo: entro 4 ore dall’allerta.
• Disponibilità del servizio (Uptime): garanzia di accesso alla console di monitoraggio e reporting. Target: 99.9% annuo.
• Qualità dei report: tempestività e completezza degli report di compliance (es. invio entro il 5 del mese successivo).

È fondamentale prevedere un sistema di penali proporzionato e sfumato basato sul concetto di Service Credit (rimborso forfettario) in caso di mancato raggiungimento degli obiettivi. Ad esempio, una riduzione del 10% del canone per ogni ora di slittamento sull’MTTD oltre la soglia contrattuale, o una penale crescente per la mancata erogazione di report critici. Il contratto deve dettagliare anche le grace period e le esclusioni, per evitare contestazioni su eventi di forza maggiore, ma mantenendo alto il livello di accountability verso il cittadino.

Questa definizione rigorosa trasforma lo SLA da mera formalità a strumento di garanzia effettiva.

Checklist Pratica per la Ricerca di Mercato (RFI/RFP)

Checklist Pratica per la Ricerca di Mercato (RFI/RFP)

Se stai valutando un fornitore per un servizio SOC dedicato alla Pubblica Amministrazione, la fase di ricerca di mercato è decisiva per individuare il partner più affidabile. Non si tratta solo di confrontare listini, ma di strutturare un processo che garantisca trasparenza, conformità e valutazione oggettiva. Per darti una struttura concreta, abbiamo elaborato una checklist operativa da seguire nella stesura di una RFI (Request for Information) o di una RFP (Request for Proposal).

Preparazione della documentazione di gara

Prima di emettere una richiesta formale, è fondamentale definire con precisione i requisiti tecnici e organizzativi. Per la PA, questo passaggio deve includere un’analisi preliminare dei processi aziendali da proteggere, delle normative applicabili (GDPR, NIS 2, Codice dell’Amministrazione Digitale) e dei requisiti di sicurezza fisica e logica degli asset da monitorare.

Checklist pre-gara:

• Mappatura degli asset critici: elencare sistemi, applicazioni, database e infrastrutture fisiche/virtuali, specificando il livello di criticità.
• Definizione dello scope operativo: indicare se il SOC dovrà gestire solo l’analisi degli eventi (monitoraggio) o anche l’incident response e la gestione dei sandbox (isolamento).
• Requisiti normativi: specificare la necessità di aderenza al DPCM 13 gennaio 2022 (riguardante la sicurezza cibernetica nella PA) e agli standard ISO 27001/27035.
• Requisiti di residenza dei dati: stabilire se i dati di log e di traffico debbano rimanere entro confini nazionali o in UE (compliance con le normative sulla localizzazione dei dati).
• Stima del volume di eventi: quantificare approssimativamente il numero di eventi giornalieri/annuali per dimensionare correttamente il servizio.

Esempio pratico: un Comune con 200 utenti e un parco macchine di 150 server potrebbe stimare un flusso di circa 2-3 milioni di eventi al giorno. Questa stima è cruciale per valutare l’offerta: un fornitore che non chiede questi dati rischia di proporre soluzioni sottodimensionate o sovradimensionate.

Criteri di selezione del fornitore: la valutazione qualitativa

Nella RFI/RFP, il prezzo è importante, ma non deve essere l’unico discrimine. Per la PA, la continuità operativa e la sicurezza sono beni giuridici indisponibili. È necessario inserire criteri di valutazione che analizzino la solidità del partner e la qualità del servizio.

Punti critici da verificare nella valutazione del fornitore:

1. Team Operativo e SLA: Il servizio è gestito 24/7 da personale certificato (es. CISSP, CISM) o è un servizio di “solo orario ufficio”? Chiedi specifiche sul turno di notte e festivi. Verifica gli SLA garanti (es. tempo di risposta all’alert critico < 15 minuti).
2. Infrastruttura del SOC: Il fornitore utilizza piattaforme proprietarie o soluzioni EDR/XDR standard di mercato (es. CrowdStrike, SentinelOne)? Una soluzione basata su tecnologie “vendor-agnostic” offre maggiore flessibilità.
3. Metodologia di analisi (Threat Hunting): Il servizio include solo analisi basate su regole predefinite o anche analisi comportamentali e hunting proattivo delle minacce (TTPs)?
4. Reporting e Compliance: Il fornitore fornisce report mensili automatici formati per la responsabilità (RA) della PA? I report sono accessibili tramite piattaforma self-service?
5. Formazione e Awareness: Il contratto include sessioni di formazione annuali per il personale della PA sulla sicurezza informatica?

Come strutturare la scheda tecnica nella RFP

La scheda tecnica deve contenere domande specifiche per eliminare l’ambiguità. Ecco una struttura suggerita per il modulo di offerta:

• Architettura del servizio: Descrivere il flusso di dati, il punto di demarcazione (se il monitoring agent viene installato on-premise o è cloud-only), e i protocolli di comunicazione sicuri (es. API REST con OAuth2, TLS 1.3).
• Integrazione: Specificare la compatibilità con gli strumenti esistenti (SIEM on-premise, firewall, Active Directory). Chiedere la garanzia di interoperabilità.
• KPI e Metriche di performance: Definire i metrici di servizio. Esempi: MTTR (Mean Time to Resolution), numero di falsi positivi, tempo medio di rilevamento (MTTD).
• Procedure di Escalation: Richiedere il dettaglio delle procedure di comunicazione in caso di incidente critico: chi contattare, canali di notifica (es. PEC, app dedicate), piani di risposta pre-definiti.
• Business Continuity & Disaster Recovery: Chiedere la descrizione del piano di continuità operativa del fornitore stesso. Cosa succede se il suo SOC è colpito da un attacco? Deve avere ridondanze geografiche.

Errore comune da evitare: accettare clausole contrattuali standard che prevedono l’aggiornamento unilaterale delle versioni software. Per la PA, ogni aggiornamento che modifica il trattamento dei dati deve essere preventivamente validato.

Analisi economica: Costi Diretti, Indiretti e Penali

L’offerta economica va letta attentamente. Spesso il costo base (subscription fee) non include tutti gli accessori necessari. Nella RFP, chiedi una scomposizione dettagliata dei costi.

Tabella di analisi costi da richiedere in offerta:

Voce di Costo	Incluso nell’offerta base?	Costo aggiuntivo stimato	Note per la PA
Implementazione (Setup)	Si/No	€ 0 – € 10.000	Spesso inclusa su contratti annuali > 20k€. Verificare.
Licenze EDR/Tool di monitoraggio	Si/No	Per endpoint/server	Se il fornitore fornisce la licenza, valutare il TCO (Total Cost of Ownership).
Costi di Onboarding formazione	Si/No	€ 500 – € 2.000/giorno	Critico per allineare le procedure interne della PA.
Overage (eventi in eccesso)	No	€ 0,0X per evento	Definire un tetto massimo prevedibile per evitare costi imprevisti.
Penale per disservizio (SLA)	Si/No	Credito di servizio	Chiedere percentuali decrescenti in base alla gravità del disservizio.

Checklist finale per la firma del contratto

Prima di firmare, verifica che siano presenti le seguenti clausole a tutela della PA:

• CLAUSOLA DI RISERVATEZZA (NDA): Obbligo di segretezza totale su architettura, vulnerabilità rilevate e dati processati.
• TRATTAMENTO DEI DATI: Il fornitore deve figurare come “Responsabile del trattamento” (art. 28 GDPR) con incarico specifico e revocabile.
• REVOCA E PASSAGGIO DI GESTIONE: In caso di recesso, il fornitore deve fornire tutti i dati in formato standard (es. JSON, CSV) e assistere tecnica per il trasferimento al nuovo provider entro 30 giorni.
• ASSET DI PROPRIETÀ INTELLETTUALE: Chiara proprietà dei log e dei report generati: devono essere di esclusiva proprietà dell’ente pubblico.

Seguendo questa checklist, la ricerca del partner SOC as a service in Italia diventa un processo strutturato che minimizza i rischi e massimizza il valore per la Pubblica Amministrazione. Ricorda: un buon partner non vende solo tecnologia, ma offre una metodologia collaudata di sicurezza.

Domande tecniche da porre durante la valutazione dei vendor

Domande tecniche da porre durante la valutazione dei vendor

Per una Public Administration, la scelta del partner SOC as a Service non è solo un acquisto tecnologico, ma una decisione strategica che impatta direttamente sulla continuità operativa e sulla compliance normativa. Ecco le domande tecniche fondamentali da porre durante la valutazione dei vendor per assicurarsi un partner realmente allineato alle esigenze della PA.

1. Architettura e Integrazione

Chiedi: “Quale modello di SOC adottate (on-premise, cloud, ibrido) e come garantite l’integrazione con le nostre infrastrutture esistenti? Supportate connectori standard per i nostri sistemi critici (es. ERP della PA, archivi digitali, piattaforme diagnostico)?”. Un partner valido deve dimostrare un approccio flessibile che minimizzi il time-to-value senza richiedere la riscrittura dei nostri sistemi legacy.

2. Coverage Threat e Intelligence

Domanda cruciale: “Quali sono le vostre fonti di threat intelligence e come le adattate al contesto specifico della PA? Monitorate minacce verticalizzate sul settore pubblico (es. Ransomware targeting enti locali, attacchi APT)?”. Il partner deve garantire un’intelligence contestualizzata, non un feed generico, con un focus specifico sugli asset della pubblica amministrazione.

3. Tempi di Rilevamento e Response (MTTD/MTTR)

Chiedi specifici: “Quali sono i vostri SLA garanti per Mean Time to Detect (MTTD) e Mean Time to Respond (MTTR)? Come gestite le 24/7, inclusi festivi e notti? Quali sono i protocolli di escalation definiti?”. Richiedi esempi concreti di reportistica e dashboard in tempo reale accessibili ai nostri responsabili della sicurezza.

4. Compliance e Auditabilità

La conformità è non negoziabile: “Quali sono i vostri certificazioni (ISO 27001, SOC 2 Type II) e come garantite la tracciabilità completa delle attività per soddisfare le richieste di audit (es. AGID, Garante Privacy)? Il servizio è conforme al NIS2 e al Perimeter Unico della PA?”. Richiedi dettagli su come il sistema supporta la documentazione per gli audit di compliance.

5. Modello Operativo e Team Dedicato

Infine, chiarisci il modello: “Il servizio è gestito da un team dedicato con esperienza nel settore pubblico italiano? Come avviene la comunicazione in caso di incidente critico? Supportate la partecipazione a Tavoli di crisi tecnici?”. Un partner che comprende la PA deve parlare il nostro linguaggio normativo e operativo.

Prima di concludere, verifica che ogni risposta sia documentata e supportata da SLA contrattuali chiari, evitando promesse vaghe che non reggerebbero a un’analisi di due diligence tecnica.

Pronto a valutare un partner che parla il linguaggio della tua PA? Scarica la nostra Checklist di Valutazione Vendor SOC e contattaci per una consulenza personalizzata.

Simulazione di attacco e Proof of Concept (PoC): Cosa chiedere?

Per valutare un fornitore SOCaaS, la fase di simulazione e Proof of Concept (PoC) è determinante: non si tratta di una semplice dimostrazione tecnologica, ma di una validazione concreta dell’efficacia operativa. Per una PA, il PoC deve essere strutturato in modo da rivelare capacità, processi e valore reale.

Richiedi una simulazione di attacco controllata, ideata su uno scenario realistico per il tuo ente (ad esempio, un tentativo di ransomware sul sistema di gestione documentale o un attacco di phishing mirato contro il personale). La simulazione non deve limitarsi a tecniche visibili, ma includere anche attività laterali e persistence per testare la capacità di rilevamento a più livelli. Verifica che l’attività sia preventivamente approvata tramite accordo specifico (SLA) e che siano prese tutte le precauzioni per non impattare la produzione.

Chiedi poi un Proof of Concept (PoC) guidato, della durata di 2-4 settimane, focalizzato su due aspetti chiave:

• Onboarding e visibilità: come vengono integrati i tuoi asset (server, workstation, firewall) e quali sono i primi segnali di anomalia rilevati.
• Tempi di risposta e escalation: definisci chiaramente le finestre di intervento, i contatti e le procedure per gli alert di severità critica, misurando il Time to Detect (TTD) e il Time to Respond (TTR) su un campione di allarmi.

Al termine del PoC, pretendi un report di sintesi con metriche chiare (copertura di monitoraggio, alert generati vs. veri positivi, tempo medio di risposta) e una demo dello strumento SIEM/SOC, evidenziando la personalizzazione per il tuo contesto normativo (GDPR, NIS2, codice dell’amministrazione digitale). Questo ti permetterà di confrontare i fornitori non sulle promesse, ma sui risultati misurabili.

Piano di Implementazione e Governance

Strategia di Implementazione SOC as a Service per la Pubblica Amministrazione

Fasi di onboarding: Da contratto firmato a full visibility

L’onboarding di un fornitore SOC as a service per la PA è un processo strutturato che trasforma la firma del contratto in piena operatività e controllo. Il percorso ideale si articola in fasi chiare e tracciabili.

Fase 1: Kick-off e raccolta informazioni (1-2 settimane)

Dopo il contratto, il partner deve condurre un’analisi approfondita della tua infrastruttura IT. Per la PA, questo include la documentazione delle banche dati, dei sistemi critici (es. anagrafe, sistemi tributari), delle interfacce verso il cittadino e dei flussi di dati sensibili. Il partner deve comprendere il tuo ecosistema digitale, le esigenze normative specifiche e le eventuali esigenze di sovranità dei dati.

Actionable: Prepara un’analisi del tuo perimetro di sicurezza, includendo un inventario dei sistemi, la classificazione dei dati e l’elenco dei dispositivi connessi.

Fase 2: Integrazione tecnica e configurazione (2-4 settimane)

Il fornitore implementa gli strumenti di monitoraggio (agenti SIEM, sensori NDR, soluzioni EDR) nel tuo ambiente. Per le amministrazioni pubbliche, è cruciale che l’integrazione avvenga in modalità non intrusiva e che venga garantita la continuità operativa. In questa fase vengono configurati gli alert, le basi di conoscenza per l’analisi comportamentale e i collegamenti con gli strumenti di ticketing interni.

Actionable: Verifica che vengano mappati i processi di incident response, definendo chiari SLA di rilevazione e contenimento del rischio.

Fase 3: Test e validazione (1 settimana)

Si eseguono test mirati per simulare scenari di attacco e verificare la corretta captazione degli eventi. Questa fase è fondamentale per il collaudo, specialmente negli organi pubblici, dove ogni modifica al sistema deve essere validata internamente.

Actionable: Richiedi un report di test firmato digitalmente che attesti la conformità del sistema agli standard richiesti (es. NIS2, GDPR).

Fase 4: Go-live e transizione al managed service

Il servizio diventa operativo 24/7. Viene assegnato un Technical Account Manager (TAM) dedicato, a stretto contatto con i tuoi referenti di sicurezza. Viene attivato il portale di gestione per il tuo staff, con accessi basati sul principio del minimo privilegio.

Actionable: Pianifica una riunione di handover con i team IT e di sicurezza per il trasferimento delle conoscenze operative e documentali.

Fase 5: Transizione alla visibility e ottimizzazione continua

Dopo le prime 4-6 settimane di funzionamento, il fornitore fornisce i primi report di sintesi operativa. Inizia la fase di tuning, in cui le regole di analisi vengono ottimizzate per ridurre il rumore di fondo e concentrarsi sulle minacce reali. Il tuo team interno guadagna progressivamente visibilità completa sullo stato di sicurezza.

Actionable: Utilizza il portale dashboard per monitorare gli indicatori di performance e partecipare ai review meeting trimestrali.

Il Comitato di Sicurezza: Ruolo interno vs Ruolo del fornitore esterno

Formazione del personale PA: Come collaborare con il SOC 24/7

Conclusioni: Strategia a Lungo Termine per la Ciber-resilienza

Domande Frequenti (FAQ)

È obbligatorio che i dati del SOC risiedano fisicamente in Italia?

Sebbene il GDPR non imponga la residenza fisica dei dati (l’export è lecito se verso paesi con adeguato livello di protezione), per la Pubblica Amministrazione è preferibile, e spesso richiesto dai bandi di gara, che i dati (soprattutto i log) risiedano nell’Unione Europea o preferibilmente in Italia. Questo riduce i rischi di complessità burocratica e garantisce il controllo diretto in caso di indagini o audit da parte dell’AGID o del Garante Privacy.

Qual è la differenza tra SOC as a Service e MDR (Managed Detection and Response)?

Un SOC tradizionale (spesso gestito in remoto) fornisce monitoraggio continuo, gestione degli alert e reportistica. L’MDR è un’evoluzione che include non solo la rilevazione ma anche la risposta attiva agli incidenti. Per la PA, il modello MDR è spesso più efficace perché non si limita ad avvisare, ma agisce per isolare la minaccia, riducendo il time-to-containment, essenziale per mantenere operativi i servizi pubblici.

Come si concilia l’accesso 24/7 del fornitore esterno con i requisiti di sicurezza degli enti pubblici?

L’accesso del partner SOC viene gestito tramite un modello ‘Least Privilege’ (minimo privilegio) e tunnel cifrati (VPN o VPC peering). È fondamentale che il fornitore utilizzi sistemi di autenticazione forte e che tutte le sessioni siano registrate (audit log). Per la PA, è prassi comune limitare l’accesso a specifici segmenti di rete, escludendo zone critiche come i sistemi di posta elettronica certificata (PEC) o gli archivi anagrafici, salvo necessità di indagine su un evento sospetto.

Quanto costa in media un servizio SOC per un piccolo Comune italiano?

Il costo varia drasticamente in base al numero di endpoint, server e la complessità dell’infrastruttura. Indicativamente, per un piccolo Comune (200-500 utenti/endpoint), il costo mensile di un SOCaaS può variare tra i 1.500€ e i 4.000€. È cruciale valutare il prezzo non in assoluto, ma rispetto al TCO, evitando costi nascosti per ingaggio, onboarding o log retention oltre i termini contrattuali.

Il fornitore SOC può sostituire il responsabile della sicurezza della PA?

No. La normativa (in particolare il GDPR e il D.lgs 82/2005) richiede la figura del Responsabile della Protezione dei Dati (RPD/DPO) e, per la sicurezza informatica, il responsabile interno. Il fornitore SOC agisce come ‘Responsabile del Trattamento’ (art. 28 GDPR) per la gestione dei log e degli incidenti, ma la responsabilità finale e la governance strategica rimangono in capo alla Pubblica Amministrazione.

Come valutare la maturità di un vendor SOC che non ha referenze nella PA?

Se il vendor non ha referenze dirette in PA, valutate il suo track record in settori regolamentati simili (banche, assicurazioni, healthcare). Chiedete certificazioni internazionali (ISO 27001, SOC 2 Type II) e verificate l’esperienza tecnica del team di analisti (certificazioni SANS, EC-Council). Inoltre, richiedete un periodo di prova (PoC) di 30 giorni su un campione di log per verificare l’efficacia delle detection rules.

Contattaci

contattaci per saperne di più