Supervisione dei fornitori MDR per NIS2, DORA e GDPR

Alle 02:13 di un lunedì mattina, il fornitore MDR apre un’allerta ad alta gravità: accesso da posizione impossibile, regole di casella di posta sospette e un account privilegiato utilizzato da un endpoint non gestito. L’analista SOC effettua l’escalation tramite il portale di ticketing. Il responsabile IT sta dormendo. Il CFO riceve un avviso di phishing da un contatto bancario prima che il canale interno per gli incidenti si attivi. Alle 07:30, il CISO deve rispondere a tre domande scomode.

Chi aveva l’autorità per dichiarare un incidente?

Possiamo dimostrare che il fornitore MDR disponeva dei log corretti, li ha conservati abbastanza a lungo e ha preservato le evidenze?

Se sono stati consultati dati personali, la funzione legale può rispettare le tempistiche di valutazione della violazione previste dal GDPR mentre le Operations preparano la segnalazione NIS2 o DORA?

Un mese dopo, l’auditor esterno chiede le stesse evidenze con un tono diverso. Il report PDF del fornitore MDR è utile, ma non basta. L’auditor vuole i dati grezzi dell’allerta, i file di log completi, la traccia di escalation, il registro decisionale interno, la registrazione del riesame del fornitore e la prova che l’organizzazione fosse in grado di verificare in modo indipendente quanto accaduto.

Questo è il problema della supervisione dei fornitori MDR nel 2026. Le organizzazioni esternalizzano rilevamento e risposta perché mantenere una capacità SOC interna è costoso, assumere personale è difficile e l’attività delle minacce è continua. Ma il rilevamento esternalizzato non trasferisce la responsabilità. Ai sensi di NIS2, gli organi di gestione restano responsabili dell’approvazione e della supervisione delle misure di gestione dei rischi di cibersicurezza. Ai sensi di DORA, le entità finanziarie restano pienamente responsabili del rischio ICT di terze parti, inclusi servizi ICT critici, supporto agli incidenti, diritti di audit, subappalto ed exit. Ai sensi del GDPR, i titolari del trattamento devono dimostrare un’adeguata sicurezza del trattamento, soprattutto quando i responsabili trattano telemetria, dati degli endpoint, identificativi utente, indirizzi IP, contenuti e-mail, log o immagini forensi.

Il divario pratico raramente riguarda solo il contratto MDR. Riguarda la catena delle evidenze tra il contratto e il servizio in esercizio: instradamento delle allerte, accesso privilegiato, conservazione dei log, soglie di escalation, evidenze dell’incidente, trasparenza sui subappaltatori, clausole per i responsabili del trattamento, riesami del servizio, esercitazioni tabletop e reportistica alla direzione.

Un programma difendibile di supervisione dei fornitori MDR richiede un unico modello operativo in grado di sostenere più interlocuzioni di audit. ISO/IEC 27001:2022 fornisce questa dorsale.

La supervisione MDR parte dalla responsabilità, non dalla console SOC

Un errore frequente è trattare l’onboarding MDR come un progetto tecnico: distribuire agenti EDR, inoltrare log di identità, configurare allerte, concordare un canale Teams o Slack e andare in produzione. Questo può migliorare il rilevamento, ma non dimostra la governance.

NIS2 rende esplicito il punto. I soggetti essenziali e importanti devono attuare misure tecniche, operative e organizzative adeguate e proporzionate per la gestione dei rischi di cibersicurezza. Article 21 include analisi del rischio, trattamento dell’incidente, continuità operativa, sicurezza della catena di fornitura, igiene informatica, controllo degli accessi, gestione degli asset, crittografia e autenticazione a più fattori. Article 20 eleva il tema alla responsabilità degli organi di gestione, richiedendo approvazione e supervisione di tali misure.

I fornitori MDR spesso ricadono contemporaneamente in diverse aree di NIS2 Article 21:

• Trattamento dell’incidente, perché il fornitore esegue il triage, effettua l’escalation e può raccomandare il contenimento.
• Sicurezza della catena di fornitura, perché il fornitore è un prestatore di servizi diretto con impatto operativo sulla sicurezza.
• Controllo degli accessi, perché il fornitore può accedere a console, log, strumenti endpoint o tenant cloud.
• Registrazione e monitoraggio, perché il rilevamento dipende da copertura, conservazione e correlazione dei log.
• Igiene informatica, perché le risultanze MDR spesso evidenziano debolezze di patching, identità o configurazione.
• Continuità operativa, perché una risposta tardiva può interrompere servizi critici.

Per le entità finanziarie, DORA rafforza il modello operativo. DORA si applica dal 17 gennaio 2025 e richiede gestione del rischio ICT, segnalazione degli incidenti, test di resilienza, condivisione delle informazioni e gestione del rischio ICT di terze parti. Chiarisce inoltre che, per le entità finanziarie identificate anche ai sensi di NIS2, DORA opera come atto giuridico dell’Unione settoriale per gli obblighi di cibersicurezza sovrapposti. Una banca regolamentata, un istituto di pagamento, un’impresa di investimento, un assicuratore o un prestatore di servizi per cripto-attività non può limitarsi a dire: “Se ne occupa il nostro fornitore MDR.” DORA si aspetta che l’entità classifichi gli incidenti ICT, gestisca e monitori i fornitori terzi di servizi ICT, mantenga registri degli accordi di servizio ICT, definisca diritti contrattuali, testi la resilienza, svolga analisi della causa radice e segnali per fasi gli incidenti gravi connessi all’ICT.

Il GDPR aggiunge una prospettiva diversa. Se la telemetria MDR include identificativi utente, indirizzi IP, metadati e-mail, registrazioni di autenticazione, artefatti degli endpoint o file contenenti dati personali, si applicano i principi di sicurezza e responsabilizzazione del GDPR. Article 5 include integrità, riservatezza e accountability. La sicurezza del trattamento prevista dall’Article 32 diventa una questione pratica di evidenze: i log erano protetti, l’accesso era limitato, la cifratura era utilizzata ove appropriato, i responsabili del trattamento erano governati e l’organizzazione può dimostrare che cosa è accaduto?

Il messaggio è coerente in tutti e tre i regimi: si può delegare l’attività operativa, ma non la responsabilità.

ISO/IEC 27001:2022 trasforma l’MDR in un processo verificabile in audit

Un SGSI correttamente attuato e basato su ISO/IEC 27001:2022 trasforma la supervisione dei fornitori MDR da promessa di vendor management a modello operativo basato su evidenze. La clausola 8.1 è particolarmente importante perché richiede alle organizzazioni di controllare i processi, prodotti e servizi forniti dall’esterno che sono rilevanti per il SGSI. L’MDR è esattamente questo: un processo fornito dall’esterno che può incidere su risposta agli incidenti, privacy, resilienza, segnalazione normativa e continuità operativa.

Le aree più importanti dell’Annex A di ISO/IEC 27001:2022 per la supervisione MDR includono rapporti con i fornitori, requisiti di sicurezza negli accordi con i fornitori, gestione del rischio della catena di fornitura ICT, monitoraggio dei servizi dei fornitori, gestione degli incidenti, gestione delle evidenze, registrazione, monitoraggio, controllo degli accessi, accesso privilegiato, crittografia e preparazione alla continuità operativa.

Zenith Controls: The Cross-Compliance Guide di Clarysec Zenith Controls è il riferimento di cross-compliance per questo lavoro. Mappa i controlli ISO/IEC 27002:2022 su altri requisiti, controlli correlati, aspettative di audit ed evidenze di attuazione. Per la supervisione MDR, tre controlli ISO/IEC 27002:2022 sono centrali: 5.19 per i rapporti con i fornitori, 5.22 per il monitoraggio dei servizi dei fornitori e la gestione delle modifiche, e 8.15 per la registrazione. Sono supportati da 5.20 accordi con i fornitori, 5.21 sicurezza della catena di fornitura ICT, 5.24-5.28 gestione degli incidenti e trattamento delle evidenze, 5.34 privacy e PII, 5.36 conformità, 8.16 attività di monitoraggio, 8.17 sincronizzazione dell’orario, 8.18 uso di programmi di utilità privilegiati e 8.8 gestione delle vulnerabilità tecniche.

Questo è rilevante perché una carenza di audit sull’MDR raramente significa “assenza di MDR”. Di solito significa una di queste cose:

• Il fornitore MDR non era classificato come critico.
• Le clausole contrattuali non includevano notifica degli incidenti, accesso alle evidenze o diritti di audit.
• I log non sono stati conservati abbastanza a lungo per indagare un evento segnalato.
• L’accesso del fornitore era condiviso, persistente o non monitorato.
• Il cliente non ha riesaminato le prestazioni MDR rispetto agli SLA.
• Subappaltatori o sub-responsabili non erano approvati.
• Gli obblighi di notifica delle violazioni dei dati personali non erano allineati ai workflow di incidente.
• Le evidenze non sono state preservate in modo utile ai fini forensi.
• La direzione non disponeva di metriche che mostrassero se il servizio MDR riduceva il rischio.

Zenith Controls descrive chiaramente il rapporto tra aspettative verso i fornitori e accordi:

“5.19 definisce le aspettative di sicurezza su come i fornitori devono trattare le informazioni dell’organizzazione. 5.20 formalizza tali aspettative assicurando che contratti o accordi includano esplicitamente clausole di sicurezza, come requisiti di riservatezza, conformità alle politiche di sicurezza e procedure di notifica degli incidenti. Senza 5.20, i requisiti identificati in 5.19 potrebbero non essere giuridicamente azionabili.”

Per l’MDR, questa frase è la lezione di governance. Se il contratto non impone al fornitore di conservare i log, fornire evidenze, cooperare negli incidenti, limitare il subappalto, supportare gli audit e rispettare le tempistiche di escalation, il servizio SOC può essere utile sul piano operativo ma debole in sede di audit.

Che cosa deve dimostrare il contratto MDR prima della prima allerta

Un buon contratto MDR non è solo un ordine commerciale. È un documento di controllo. DORA Articles 28 to 30 richiedono che il rischio ICT di terze parti sia gestito lungo tutto il ciclo di vita, inclusi registri dei contratti ICT, classificazione della criticità, due diligence precontrattuale, approcci di audit e ispezione, diritti di risoluzione, strategie di exit, descrizioni chiare dei servizi, livelli di servizio, ubicazioni del servizio e del trattamento dei dati, impegni di protezione dei dati, assistenza sugli incidenti e cooperazione con le autorità. NIS2 Article 21 richiede la sicurezza della catena di fornitura per fornitori diretti e prestatori di servizi. Il GDPR richiede ruoli di titolare e responsabile del trattamento, garanzie del responsabile, clausole di protezione dei dati ed evidenze di sicurezza del trattamento.

La libreria di politiche Clarysec traduce tali obblighi in requisiti contrattuali e operativi pratici. Nella Politica aziendale di risposta agli incidenti Politica di risposta agli incidenti, l’MDR è trattato esplicitamente come capacità di incidente di terza parte governata:

“L’integrazione con servizi di terze parti, inclusi Managed Detection and Response (MDR), Security Incident and Event Management (SIEM) e fornitori di analisi forense, deve essere governata da accordi sul livello di servizio (SLA) chiaramente definiti e da disposizioni di non divulgazione.”

Questa clausola è importante perché i fornitori MDR spesso ricevono informazioni altamente sensibili prima che l’organizzazione sappia se un incidente è soggetto a segnalazione. La telemetria può includere nomi utente, percorsi dei file, oggetti e-mail, hostname interni, indirizzi IP, diagrammi di rete e indicatori di compromissione. Le disposizioni di non divulgazione proteggono l’organizzazione durante l’indagine e supportano l’accountability ai sensi del GDPR.

La Politica aziendale di sicurezza delle terze parti e dei fornitori Politica di sicurezza delle terze parti e dei fornitori aggiunge due clausole che gli auditor si aspettano di vedere quando riesaminano la supervisione MDR:

“Diritti di audit, ispezione e richiesta di evidenze di sicurezza”

e:

“Uso di subappaltatori soggetto a previo consenso scritto”

Per le PMI, lo stesso principio di governance viene proporzionato, ma non eliminato. La Politica di sicurezza delle terze parti e dei fornitori - PMI Politica di sicurezza delle terze parti e dei fornitori - PMI richiede il principio del privilegio minimo:

“Ai fornitori deve essere concesso accesso solo ai sistemi e ai dati minimi necessari per svolgere la loro funzione.”

Richiede inoltre:

“Restrizioni a ulteriore subappalto senza approvazione”

Queste clausole sono particolarmente rilevanti per l’MDR. Molti fornitori utilizzano team SOC su più livelli, fornitori di piattaforme, partner di threat intelligence, servizi di analisi cloud o personale di supporto regionale. Se soggetti a valle possono accedere ai log del cliente o a dati personali, il cliente deve disporre di meccanismi di visibilità e approvazione. In termini DORA, questo rientra nella supervisione del subappalto e del rischio di concentrazione. In termini GDPR, è governance dei sub-responsabili. In termini NIS2, è gestione del rischio della catena di fornitura.

Checklist essenziale per la supervisione MDR

Un rapporto difendibile con un fornitore MDR deve essere verificabile. La seguente checklist combina requisiti contrattuali, operativi e di evidenza in un’unica vista di controllo.

Questa checklist deve essere integrata in approvvigionamento, onboarding, riesame periodico e test degli incidenti. Se manca un elemento, l’organizzazione deve trattarlo come rischio del fornitore, non come problema documentale.

Sette domini di evidenza attesi dagli auditor

Per rendere la supervisione MDR pronta per l’audit, Clarysec raccomanda di predisporre un fascicolo di evidenze MDR organizzato in sette domini. Questo fascicolo deve risiedere nel SGSI, non in una cartella acquisti che nessuno riesamina.

Questa tabella cambia la conversazione con il fornitore. Invece di chiedere “Ci state monitorando?”, l’organizzazione chiede: “Possiamo dimostrare, ogni trimestre, che il servizio MDR resta efficace, conforme e allineato alla nostra propensione al rischio?”

La registrazione è il ponte tra rilevamento ed evidenze di conformità

MDR senza una registrazione affidabile è attività investigativa esternalizzata basata su ipotesi. Il fornitore può rilevare alcune minacce, ma l’organizzazione non può dimostrare ambito, cronologia, causa radice o impatto.

Il controllo 8.15 di ISO/IEC 27002:2022 riguarda la registrazione. Zenith Controls classifica la registrazione come controllo di rilevamento a supporto di riservatezza, integrità e disponibilità, allineato al concetto di cibersicurezza Detect e alla capacità di gestione degli eventi di sicurezza delle informazioni. Collega direttamente la registrazione ad attività di monitoraggio, valutazione degli eventi, risposta agli incidenti, lezioni apprese, accesso privilegiato, sincronizzazione dell’orario, controllo degli accessi, privacy, raccolta delle evidenze, gestione delle vulnerabilità e monitoraggio della sicurezza fisica.

Per questo la registrazione è centrale per le evidenze NIS2, DORA e GDPR Article 32. La segnalazione NIS2 Article 23 per incidenti significativi richiede un preallarme entro 24 ore dalla conoscenza, una notifica entro 72 ore e un rapporto finale non oltre un mese dalla notifica. La segnalazione DORA degli incidenti gravi connessi all’ICT richiede classificazione, escalation, comunicazione, analisi della causa radice e report finale. L’accountability GDPR richiede alle organizzazioni di dimostrare cosa è accaduto ai dati personali e se le misure di sicurezza erano adeguate.

La Politica di registrazione e monitoraggio - PMI di Clarysec Politica di registrazione e monitoraggio - PMI fornisce un semplice controllo contrattuale per le organizzazioni più piccole che utilizzano fornitori esterni:

“I contratti devono imporre ai fornitori di conservare i log per almeno 12 mesi e di fornire accesso su richiesta”

Per gli ambienti aziendali, la Politica di registrazione e monitoraggio Politica di registrazione e monitoraggio aggiunge il requisito di integrazione operativa:

“Deve fornire dati di log su richiesta o integrarsi con la piattaforma SIEM/aggregatore di log dell’organizzazione.”

Queste clausole risolvono un problema ricorrente nella risposta agli incidenti: durante un’indagine, il fornitore MDR afferma che l’evento è più vecchio della finestra di conservazione ricercabile, che i log sono disponibili solo tramite esportazione forense a pagamento oppure che il SIEM del cliente non contiene l’arricchimento del fornitore e le azioni degli analisti. Se l’accesso ai log non è definito in anticipo, la cronologia dell’incidente diventa frammentata.

Un solido modello di registrazione MDR deve definire fonti di log obbligatorie, tipi di evento, periodi di conservazione, protezione dell’integrità, approvazioni di accesso, sincronizzazione dell’orario, formati di esportazione e regole di correlazione tra piattaforme del cliente e del fornitore. Deve inoltre coprire le azioni del fornitore, incluse modifiche alle regole di rilevamento, comandi di isolamento endpoint, accessi amministrativi, note degli analisti ed esportazioni di evidenze.

Gli standard ISO di supporto rafforzano questo approccio. ISO/IEC 27035-1:2023 e ISO/IEC 27035-2:2023 collegano la registrazione a rilevamento degli incidenti, triage e analisi centralizzata. ISO/IEC 27701:2021 aggiunge la registrazione specifica per la privacy delle attività di trattamento delle PII. ISO/IEC 27017:2021 e ISO/IEC 27018:2020 aggiungono aspettative di registrazione per cloud e PII nel cloud, in particolare quando i fornitori trattano dati dei clienti in ambienti di cloud pubblico. ISO/IEC 27005:2024 inquadra una registrazione insufficiente come questione di trattamento del rischio, non come semplice lacuna di tooling.

Risposta agli incidenti: l’MDR può effettuare escalation, ma la direzione deve decidere

I fornitori MDR rilevano e forniscono consulenza. L’organizzazione responsabile dichiara gli incidenti, valuta l’impatto normativo, comunica con le autorità e decide se sia richiesta la notifica di una violazione dei dati personali.

Questa distinzione è importante perché la gravità MDR non equivale automaticamente a un incidente significativo NIS2, a un incidente grave connesso all’ICT ai sensi di DORA o a una violazione dei dati personali ai sensi del GDPR. Il fornitore può etichettare un’allerta come “ad alta gravità”, ma l’organizzazione deve decidere se sono stati interessati servizi critici, se sono stati compromessi dati personali, se i clienti devono essere notificati, se le autorità di regolamentazione devono essere informate e se la direzione deve approvare un’azione di contenimento con impatto operativo.

La Politica di risposta agli incidenti - PMI di Clarysec Politica di risposta agli incidenti - PMI è esplicita:

“Le terze parti devono agire in conformità agli accordi sottoscritti, che devono includere clausole di notifica delle violazioni dei dati personali e obblighi di cooperazione nella risposta.”

Questa clausola è il punto in cui le evidenze GDPR Article 32 incontrano la risposta operativa agli incidenti. Se il fornitore MDR osserva una sospetta esfiltrazione di dati da un endpoint contenente dati personali, deve sapere con quale rapidità notificare, chi notificare, quali evidenze preservare e come supportare la valutazione del titolare del trattamento.

Zenith Blueprint: An Auditor’s 30-Step Roadmap di Clarysec Zenith Blueprint fornisce il metodo di test. Nella fase Controls in Action, Step 19, Zenith Blueprint indica ai team di convalidare operativamente registrazione e monitoraggio:

“Selezionare un incidente o evento recente e dimostrare come è stato tracciato tramite i log. Se sono utilizzate funzionalità di integrità dei log (ad esempio verifica dell’hash), documentare anche questo. Confermare che l’allertamento sia funzionante (ad esempio accessi non riusciti o elevazioni dei privilegi generano allerte).”

Lo stesso step riguarda identità e accesso privilegiato:

“Per gli account privilegiati, verificare che la MFA sia applicata, che i ruoli amministrativi siano separati (account in stile admin_john utilizzati solo per attività amministrative) e che esista un elenco aggiornato degli utenti privilegiati.”

Nel contesto MDR, l’elenco degli utenti privilegiati deve includere gli account del fornitore, non solo i dipendenti. Se il fornitore MDR dispone di accesso alla console, diritti di isolamento endpoint, diritti di amministrazione EDR o accesso in lettura a log sensibili, tali account devono rientrare nel riesame.

Lo Step 23 di Zenith Blueprint fornisce poi la struttura di test per incidenti e fornitori:

“Selezionare un evento recente o condurre un’esercitazione tabletop per convalidare il piano. Acquisire e registrare tutte le decisioni, i ruoli e le comunicazioni (5.26), e aggiornare il piano con le lezioni apprese (5.27). Confermare che siano in essere procedure per preservare evidenze forensi (5.28), inclusi snapshot dei log, backup e isolamento sicuro dei sistemi interessati.”

Un’esercitazione tabletop realistica deve includere il fornitore MDR. Utilizzare uno scenario come account privilegiato compromesso, isolamento endpoint, sospetto accesso alla casella di posta, possibile esposizione di dati payroll ed escalation di allerta fuori dall’orario lavorativo. Il test deve verificare se il tempo del fornitore MDR decorre dal rilevamento, dalla notifica al cliente o dalla presa d’atto del cliente. Questa distinzione è importante quando i termini normativi dipendono da consapevolezza e punti decisionali.

Costruire un pacchetto di supervisione MDR su una singola allerta in 90 minuti

Un modo rapido per evidenziare le lacune è scegliere una recente allerta MDR ad alta gravità e costruire una traccia di evidenze di una pagina. Questo esercizio pratico funziona bene prima di audit, riesami del consiglio di amministrazione e rinnovi contrattuali.

1. Partire dal ticket di allerta. Acquisire marcatura temporale, regola di rilevamento, asset interessato, utente, gravità, note dell’analista MDR e percorso di escalation.
2. Recuperare la clausola contrattuale o lo SLA che indica il tempo di risposta atteso per tale gravità.
3. Recuperare l’elenco delle fonti di log che dimostra quali sistemi hanno alimentato l’allerta, ad esempio EDR, provider di identità, firewall, gateway di sicurezza e-mail e log di audit cloud.
4. Confermare che i log siano conservati secondo la politica e che l’evento storico possa ancora essere recuperato.
5. Verificare se l’analista MDR ha avuto accesso a un ambiente del cliente. In caso affermativo, acquisire account nominativo, evidenze MFA, log di sessione e approvazione.
6. Documentare la decisione lato cliente: evento chiuso, incidente dichiarato, valutazione legale avviata, contenimento eseguito o rischio accettato.
7. Se possono essere coinvolti dati personali, registrare l’analisi dei ruoli GDPR, il titolare della valutazione della violazione e se sono stati attivati obblighi di notifica del responsabile del trattamento.
8. Chiudere con le lezioni apprese: tuning, nuovo rilevamento, modifica degli accessi, aggiornamento del playbook o problema SLA del fornitore.

Questa traccia su una singola allerta è efficace perché collega contratto, registrazione, accesso, risposta agli incidenti, privacy e supervisione della direzione in un’unica catena di evidenze. Se non è possibile costruirla per un’allerta recente, probabilmente non sarà possibile costruirla sotto pressione normativa.

Il monitoraggio dei fornitori è dove la maggior parte dei programmi MDR si indebolisce

Molte organizzazioni svolgono due diligence prima di firmare un contratto MDR e poi si fermano. Non basta per ISO/IEC 27001:2022, NIS2, DORA o GDPR. I servizi MDR cambiano continuamente: nuove regole di rilevamento, nuovi team di analisti, nuovi sub-responsabili, nuove regioni dati, nuove capacità EDR, nuove integrazioni, nuovi feed di threat intelligence e nuovi modelli di supporto.

Il controllo 5.22 di ISO/IEC 27002:2022 riguarda monitoraggio, riesame e gestione delle modifiche dei servizi dei fornitori. Zenith Controls spiega che 5.22 si basa sui controlli relativi ai rapporti e agli accordi con i fornitori, assicurando monitoraggio e gestione continui dopo l’avvio del servizio. È collegato a sicurezza durante le interruzioni, gestione delle vulnerabilità, conformità, controllo degli accessi e progettazione sicura.

DORA Articles 28 to 30 rendono questo aspetto particolarmente importante per le entità finanziarie. Richiedono monitoraggio continuo, registri degli accordi ICT di terze parti, distinzioni di criticità, due diligence, diritti di audit e ispezione, diritti di risoluzione, strategie di exit, livelli di servizio, assistenza sugli incidenti, cooperazione con le autorità e, per funzioni critiche o importanti, obiettivi di servizio, test di contingency e cooperazione nei test di penetrazione guidati dalle minacce ove pertinente.

Zenith Blueprint, fase Controls in Action, Step 23, fornisce la struttura del ciclo di vita del fornitore:

“Compilare un elenco completo dei fornitori e prestatori di servizi attuali (5.19) e classificarli in base all’accesso a sistemi, dati o controllo operativo.”

Prosegue:

“Per ogni fornitore critico, identificare se utilizza subappaltatori (sub-responsabili) che possono accedere ai dati o ai sistemi.”

Un riesame pratico del servizio MDR deve essere svolto trimestralmente per gli ambienti critici e almeno annualmente per gli ambienti a rischio inferiore. L’agenda deve includere conformità agli SLA per gravità, allerte oggetto di escalation, veri positivi, falsi positivi, escalation mancate, stato di salute delle fonti di log, modifiche degli accessi privilegiati, nuove integrazioni, nuove regioni, subappaltatori, sub-responsabili, modifiche alle regole di rilevamento, prestazioni di supporto agli incidenti, richieste di evidenze, rischi aperti, azioni correttive e preparazione all’exit.

Questo non è micromanagement. È il ciclo di assurance che dimostra che l’organizzazione governa attivamente un fornitore di sicurezza critico.

Mappatura cross-compliance: un unico set di controlli MDR, cinque conversazioni di audit

Il valore di ISO/IEC 27001:2022 consiste nel fornire alle organizzazioni un ciclo SGSI coerente per molteplici conversazioni di conformità. Lo stesso pacchetto di evidenze per la supervisione MDR può essere mappato su NIS2, DORA, GDPR, NIST CSF 2.0 e COBIT 2019.

NIST CSF 2.0 è utile per la comunicazione. La sua funzione GOVERN richiede che gli obblighi legali, normativi, contrattuali e di privacy siano compresi e gestiti, che ruoli e autorità siano definiti, che il rischio di cibersicurezza sia integrato nella gestione del rischio aziendale e che i rischi dei fornitori siano comunicati e monitorati.

COBIT 2019 è utile per gestione e assurance. Gli auditor orientati a COBIT spesso si concentrano meno su un singolo controllo e più sul fatto che obiettivi di governance, gestione dei servizi, titolarità del rischio e monitoraggio delle prestazioni funzionino come sistema.

Come gli auditor testeranno la supervisione dei fornitori MDR

Auditor diversi usano lenti diverse, ma tutti vogliono evidenze che l’organizzazione controlli il rapporto.

Un auditor ISO/IEC 27001:2022 inizierà da ambito di applicazione, parti interessate, valutazione del rischio, Dichiarazione di Applicabilità, piano di trattamento del rischio ed evidenze operative. Se l’MDR rientra nell’ambito, l’auditor si aspetterà che i processi forniti dall’esterno siano controllati nel SGSI. Potrà campionare rapporti con i fornitori, accordi con i fornitori, monitoraggio dei servizi dei fornitori, registrazione, monitoraggio, risposta agli incidenti, trattamento delle evidenze e controllo degli accessi.

Un supervisore DORA si concentrerà sulla resilienza operativa e sul rischio sistemico. Potrà esaminare in dettaglio la valutazione della criticità, il registro dei servizi ICT, l’analisi del rischio di concentrazione, la strategia di exit, la classificazione degli incidenti, i diritti di audit e le evidenze che il fornitore MDR può supportare la segnalazione normativa.

Un auditor GDPR o un reviewer privacy si concentrerà sulla governance titolare-responsabile del trattamento. Chiederà il DPA, la due diligence sul responsabile del trattamento, i controlli sui sub-responsabili, le misure di sicurezza per i log contenenti dati personali, i controlli di conservazione, le registrazioni di valutazione della violazione e le evidenze a supporto dell’Article 32.

Un auditor COBIT o ISACA esaminerà le evidenze di governance: titolarità del rischio dei fornitori, workflow di approvvigionamento, verbali di riesame del servizio, tracciamento dei problemi SLA, azione correttiva, qualità delle evidenze e se la direzione riceve metriche significative.

La richiesta di audit più rivelatrice è semplice: “Mostratemi una singola allerta MDR dal rilevamento alla chiusura.” Se potete mostrare aspettativa contrattuale, fonte di log, allerta, escalation, decisione, conservazione delle evidenze, valutazione privacy, remediation e reportistica alla direzione, la vostra supervisione MDR è matura. Se potete mostrare solo un ticket del fornitore, avete monitoraggio ma governance debole.

Reportistica alla direzione: il consiglio di amministrazione non ha bisogno di packet capture

NIS2 e DORA collocano entrambe la responsabilità a livello di organo di gestione. Consigli di amministrazione e dirigenti non hanno bisogno di telemetria grezza. Hanno bisogno di metriche di supervisione MDR rilevanti per il rischio.

Una dashboard MDR trimestrale utile include:

• Fonti di log critiche onboardate rispetto a quelle attese.
• Percentuale di asset critici coperti dall’MDR.
• Allerte ad alta gravità per categoria e servizio aziendale.
• Tempo medio dal rilevamento alla notifica al cliente.
• Tempo medio dalla presa d’atto del cliente alla decisione.
• Violazioni SLA e azioni del fornitore non risolte.
• Stato del riesame degli account privilegiati del fornitore.
• Modifiche di subappaltatori o sub-responsabili.
• Incidenti che richiedono valutazione di notifica legale, normativa o al cliente.
• Lezioni apprese attuate.

Questa dashboard deve alimentare il riesame della direzione del SGSI, gli aggiornamenti del trattamento del rischio e il riesame dei fornitori. Ai sensi di ISO/IEC 27001:2022, la leadership deve assicurare che il SGSI sia allineato alla direzione strategica, che le risorse siano disponibili, che le responsabilità siano assegnate, che la comunicazione funzioni e che avvenga il miglioramento continuo. Le metriche MDR sono un modo pratico per dimostrare che le operazioni di sicurezza esternalizzate sono governate dalla direzione, non lasciate agli amministratori degli strumenti.

Errori comuni nella supervisione MDR da correggere prima degli audit 2026

Le lacune più comuni sono normali fallimenti di governance.

Primo, le organizzazioni dimenticano che i fornitori MDR possono trattare dati personali. I log di sicurezza sono talvolta trattati come “dati tecnici”, ma possono contenere dati personali e, occasionalmente, contenuti sensibili. L’analisi dei ruoli GDPR e le clausole per i responsabili del trattamento devono essere completate prima dell’onboarding, non durante una violazione.

Secondo, la conservazione dei log viene presunta anziché contrattualizzata. Se obblighi normativi, forensi o verso i clienti richiedono evidenze per mesi, il modello di conservazione MDR e SIEM deve supportarlo. Il requisito della politica PMI per la conservazione dei log del fornitore per 12 mesi è una baseline pratica per molti ambienti.

Terzo, l’accesso di terze parti è eccessivamente permissivo. Gli account del fornitore devono essere nominativi, protetti da MFA, monitorati, riesaminati e limitati nel tempo ove possibile. Account condivisi e sessioni amministrative non gestite creano rischio di audit e di risposta agli incidenti.

Quarto, le soglie degli incidenti sono ambigue. La gravità MDR non equivale automaticamente a incidente legale, incidente grave connesso all’ICT ai sensi di DORA, incidente significativo NIS2 o violazione dei dati personali ai sensi del GDPR. Il playbook deve definire chi prende ciascuna decisione.

Quinto, i subappaltatori sono invisibili. Se il fornitore MDR cambia piattaforme di analisi, regioni di supporto o responsabili a valle, cambia il profilo di rischio del cliente. Previo consenso scritto e riesame periodico sono essenziali.

Sesto, i riesami del servizio si concentrano solo sul volume dei ticket. I riesami maturi esaminano allerte mancate, modifiche di tuning, stato di salute delle fonti di log, recupero delle evidenze, accesso del fornitore, cooperazione sugli incidenti e obblighi contrattuali.

Passaggi successivi: rendere il fornitore MDR pronto per l’audit con Clarysec

Se il vostro fornitore MDR è già in esercizio, non attendete che un’autorità di regolamentazione, un auditor del cliente o un incidente scoprano che le evidenze sono incomplete. Iniziate da un’allerta recente e costruite la traccia. Poi classificate il fornitore, riesaminate il contratto, convalidate la registrazione, testate l’escalation, confermate le clausole per i responsabili del trattamento, riesaminate gli accessi e pianificate il monitoraggio dei fornitori.

Clarysec può aiutarvi ad applicarlo rapidamente utilizzando:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint per un’attuazione per fasi, incluso lo Step 19 per registrazione, monitoraggio e validazione degli accessi, e lo Step 23 per i controlli di gestione dei fornitori e degli incidenti.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls per mappare i controlli ISO/IEC 27002:2022 5.19, 5.22 e 8.15 sulle aspettative di audit di NIS2, DORA, GDPR, NIST e COBIT.
• Template di politiche Clarysec, inclusi Politica di risposta agli incidenti, Politica di sicurezza delle terze parti e dei fornitori, Politica di registrazione e monitoraggio, Politica di risposta agli incidenti - PMI, Politica di sicurezza delle terze parti e dei fornitori - PMI, Politica di registrazione e monitoraggio - PMI e Politica di protezione dei dati e privacy - PMI.

L’MDR è uno degli investimenti di sicurezza più preziosi che un’organizzazione possa effettuare. Nel 2026, questo valore deve essere dimostrato tramite governance, evidenze e supervisione responsabile. Se desiderate un pacchetto pratico di supervisione MDR mappato su ISO/IEC 27001:2022, NIS2, DORA e GDPR Article 32, Clarysec può aiutarvi a costruirlo prima che la prossima allerta diventi la prossima risultanza dell’audit.