Obblighi di Rilevazione DORA, NIS2, PCI DSS e SEC

Gli obblighi di rilevamento normativo sono i risultati di sicurezza che DORA, NIS2, PCI DSS v4.0.1, e le regole di divulgazione SEC richiedono a un’organizzazione di raggiungere e dimostrare attraverso il rilevamento, il monitoraggio, la registrazione e la divulgazione.

Nessuno di questi quattro regimi prescrive uno strumento di rilevamento specifico. Solo DORA nomina il rilevamento come obbligo autonomo. Ogni framework richiede un risultato: rilevamento tempestivo, monitoraggio continuo, registrazione strutturata o divulgazione tempestiva. La capacità di rilevamento è ciò che l’evidenza implica, non un controllo che qualsiasi regolatore impone di nome.

MITRE ATT&CK organizza tali evidenze in una struttura che un revisore può interrogare per categoria di comportamento avversario. ATT&CK non è richiesto da DORA, NIS2, PCI DSS o dalle regole SEC.

DORA è lex specialis o una legge specifica che prevale su una legge generale. L’articolo 1(2) di DORA lo rende un atto giuridico specifico dell’Unione per i fini dell’articolo 4 di NIS2. Un’entità finanziaria nel campo di applicazione di DORA applica DORA per la gestione dei rischi ICT e la segnalazione degli incidenti. NIS2 raggiunge la catena di fornitura non finanziaria di una banca, non la banca stessa.

Quali prove di rilevamento supportano gli obblighi sotto PCI DSS 4.0 e DORA?

Entrambi PCI DSS v4.0.1 e DORA trattano il rilevamento come un mezzo per un fine probatorio. La regolamentazione chiede se i rilevamenti generano i registri richiesti dall’obbligo di monitoraggio, non se esistono rilevamenti.

Cinque classi di prove portano quella prova. Entrambi i regimi le richiedono nella sostanza.

Classe di prova	PCI DSS v4.0.1	DORA
Fonti di log raccolte	Requisito 10: catturare i log di audit, conservare la cronologia	Articolo 9(1): monitorare e controllare continuamente la sicurezza e il funzionamento dei sistemi ICT; Articolo 10(3): monitorare l’attività degli utenti, le anomalie ICT e gli incidenti ICT
Regole implementate, con propietario	Requisito 11: rilevamento/prevenzione delle intrusioni, rilevamento dei cambiamenti in atto	Articolo 10: più livelli di controllo, soglie di allarme definite e criteri
Prova di attivazione	Requisito 10: rivedere i log, rilevare i guasti del sistema di controllo	Articolo 10: gli allarmi si sono attivati e hanno raggiunto il personale responsabile
Storia delle modifiche	Requisito 11: rilevamento e manomissione dei cambiamenti	Articolo 17: processo documentato di gestione degli incidenti con follow-up delle cause radice
Rapporto di copertura datato	Requisito 10.5.1: cronologia dei log di audit conservata per almeno 12 mesi, gli ultimi tre mesi disponibili immediatamente (Libreria di documenti PCI SSC)	Articolo 10(1): meccanismi di rilevamento regolarmente testati in conformità con l’articolo 25

La PCI DSS v4.0 è stata ritirata il 31 dicembre 2024 e PCI DSS v4.0.1 è l’unica versione attiva (PCI SSC, giugno 2024). I 51 requisiti futuri sono stati resi effettivi il 31 marzo 2025 (PCI SSC, agosto 2024). L’H2 sopra usa “PCI DSS 4.0” per corrispondere alla query del ricercatore.

Una regola di rilevamento che si implementa ma non genera alcun record auditabile è invisibile a un valutatore.

Quali obblighi di rilevamento e monitoraggio impongono effettivamente DORA, NIS2, PCI DSS 4.0 e le regole di divulgazione SEC?

Ciascun regime impone un obbligo di risultato piuttosto che un mandato di strumento. La tabella seguente mappa ciascun obbligo alle prove di rilevamento che implica.

Regime	Articolo o Requisito	Obbligo	Prova di rilevamento implicata
DORA	Art 9(1), Art 10(3)	Monitorare e controllare continuamente la sicurezza e il funzionamento dei sistemi ICT (Art 9(1)); monitorare l’attività degli utenti, le anomalie ICT e gli incidenti ICT (Art 10(3))	Inventario delle fonti di log, registri di raccolta continua
DORA	Art 10(1), (2)	Rilevare attività anomale; più livelli di controllo con soglie di allarme e criteri, inclusi allarmi automatici al personale incaricato della risposta agli incidenti; meccanismi di rilevamento regolarmente testati ai sensi dell’articolo 25	Inventario delle regole con proprietari, giustificazione delle soglie, prova che gli allarmi hanno raggiunto i responsabili, registri di test
DORA	Art 17	Rilevare, gestire e notificare gli incidenti ICT con follow-up delle cause radice	Documentazione del processo, registri di rilevamento e gestione per incidente
DORA	Art 19 + Regolamento delegato (UE) 2025/301	Segnalare gli incidenti maggiori all’autorità competente	Record di rilevamento e classificazione con data e ora (notifica iniziale entro 4 ore dalla classificazione dell’incidente come maggiore e non oltre 24 ore dopo essere venuti a conoscenza; rapporto intermedio entro 72 ore dalla notifica iniziale; rapporto finale entro un mese dalla rapporto intermedio)
NIS2	Art 21(2)	Misure di gestione dei rischi, inclusa la gestione degli incidenti (punto (b)) e politiche per valutare l’efficacia delle misure (punto (f)); doveri di monitoraggio e registrazione sono contenuti nei regolamenti di attuazione di seguito, non nell’articolo 21 stesso	Misure documentate, registri di rilevamento
NIS2	Art 23(4)	Notifica di incidente significativo	Primo avviso entro 24 ore dalla conoscenza, notifica dell’incidente entro 72 ore, rapporto finale non oltre un mese dopo la notifica dell’incidente
NIS2	Regolamento di attuazione (UE) 2024/2690	Monitoraggio e registrazione (sezione 3.2 dell’allegato) per i tipi di entità undici nell’articolo 1(1), compresi i fornitori di servizi di sicurezza gestiti	Registri di logging espliciti per entità coperte
PCI DSS v4.0.1	Req 10	Registrare e monitorare tutti gli accessi ai componenti del sistema e ai dati del titolare della carta	I log di audit sono stati esaminati almeno quotidianamente (10.4.1), revisione automatica dei log (10.4.1.1), storico dei log mantenuto (10.5.1), rilevati, segnalati e risolti tempestivamente i guasti dei sistemi di controllo della sicurezza critici (10.7, 10.7.2); testo nel Libreria di documenti PCI SSC
PCI DSS v4.0.1	Req 11	Testare regolarmente la sicurezza dei sistemi e delle reti	Registri di rilevamento e prevenzione delle intrusioni (11.5.1), avvisi di rilevamento delle modifiche (11.5.2), avvisi di rilevamento delle modifiche e manomissioni delle pagine di pagamento (11.6.1)
SEC	8-K Elemento 1.05	Divulgare gli incidenti materiali entro quattro giorni lavorativi dalla determinazione della materialità, che deve essere effettuata senza ritardi irragionevoli dopo la scoperta (Modulo 8-K, Elemento 1.05)	Processo di determinazione della materialità, registri di rilevamento degli incidenti
SEC	S-K Elemento 106	Descrivere i processi per valutare, identificare e gestire i rischi materiali di cybersecurity nel rapporto annuale 10-K (Elemento 1C)	Processo di identificazione dei rischi documentato, inclusa la capacità di rilevamento

DORA (Regolamento (UE) 2022/2554, in applicazione dal 17 gennaio 2025) è direttamente applicabile. I suoi orologi di segnalazione sono impostati da Regolamento delegato (UE) 2025/301: notifica iniziale entro 4 ore dalla classificazione di un incidente come maggiore e non oltre 24 ore dopo essere venuti a conoscenza, un rapporto intermedio entro 72 ore dalla notifica iniziale e un rapporto finale entro un mese dal rapporto intermedio. Poiché il primo orologio inizia al rilevamento e classificazione, la linea temporale dell’incidente stessa è una prova auditabile.

NIS2 (Direttiva (UE) 2022/2555) vincola attraverso la legge di trasposizione di ogni Stato membro, non direttamente. Il termine di trasposizione era il 17 ottobre 2024 (articolo 41). Il 7 maggio 2025 la Commissione europea ha inviato pareri motivati a 19 Stati membri per non aver notificato la piena trasposizione, e l’8 luglio 2026 ha deferito l’Irlanda, la Spagna, la Francia e i Paesi Bassi alla Corte di giustizia. Il 20 gennaio 2026 la Commissione ha proposto emendamenti a NIS2 (COM(2026) 13) che toccano l’articolo 21(5) e aggiungono paragrafi sul ransomware all’articolo 23, lasciando inalterati gli interventi dell’articolo 21(2) e gli orologi di segnalazione dell’articolo 23(4). L’obbligo che un acquirente deve affrontare dipende dalla legge di trasposizione dello Stato membro.

Regolamento di attuazione (UE) 2024/2690, pubblicato il 18 ottobre 2024 e in vigore dal 7 novembre 2024, stabilisce requisiti espliciti di monitoraggio e registrazione (sezione 3.2 dell’allegato) per fornitori di servizi DNS, registri di nomi TLD, cloud computing, data center, reti di distribuzione dei contenuti, fornitori di servizi e sicurezza gestita, mercati online, motori di ricerca, piattaforme di social networking e fornitori di servizi di fiducia. Questo raggiunge gli MSSP come entità regolamentate di diritto proprio, distinte dalle obbligazioni dei loro clienti.

PCI DSS v4.0.1 è l’unica versione attiva. I requisiti 10 e 11 trasportano gli obblighi di rilevamento e monitoraggio.

SEC (regola finale Rilascio 33-11216, adottato il 26 luglio 2023) è una regola di divulgazione e governance, non un mandato di controllo di rilevamento. Il rilevamento è derivato: un registrante non può determinare la materialità senza la capacità di rilevare e valutare gli incidenti. La conformità all’Elemento 1.05 è stata richiesta dal 18 dicembre 2023 per la maggior parte dei registranti e dal 15 giugno 2024 per le società a rendicontazione ridotta.

Quali prove cercano tipicamente i revisori per confermare che i nostri sistemi di rilevamento sono efficaci?

Cinque classi di prove si ripetono in questi regimi. Una percentuale di copertura da sola non è prova per nessuno di loro.

#	Classe di prova	Che cosa prova
1	Fonti di log raccolte	Quale telemetria è acquisita, da quali sistemi, e che la raccolta è continua. Il revisore controlla se il monitoraggio è in esecuzione, non se è stato configurato una volta.
2	Regole implementate	Regole di rilevamento in atto, ciascuna mappata all’obbligo che supporta e alla sua ATT&CK tecnica ove applicabile, con un proprietario.
3	Prova di attivazione	Regole attivate su eventi reali o simulati e gli avvisi hanno raggiunto i responsabili. Una regola impiegata che non è mai stata attivata è non testata dal punto di vista del revisore.
4	Storia delle modifiche	Chi ha cambiato una regola, quando e perché: controllo delle versioni, tracciabilità delle revisioni e una motivazione documentata per ogni modifica.
5	Rapporto di copertura datato	Rapporto puntuale con una data, in modo che tendenza e attualità siano dimostrabili. Un rapporto non datato non prova nulla circa quando la copertura esisteva.

ATT&CK funziona come il raccordo che rende queste evidenze interrogabili per comportamento avversario. Un ID tecnica è metadato attaccato a prove già esistenti (fonti di dati, regole implementate, record di attivazione) in modo che le prove diventino recuperabili per categoria di comportamento. ATT&CK non è richiesto da nessuno di questi quattro regimi. Organizza le prove contro gli obblighi che impongono.

Puoi mostrare a un revisore chi ha cambiato una regola, quando e perché?

Detection-as-Code risponde a ciò. Ogni regola di rilevamento è un artefatto versionato nel controllo del codice sorgente. La storia delle modifiche registra autore, data e ora, approvazione della revisione e motivo del cambiamento.

Questa tracciabilità si mappa a obblighi specifici:

L’articolo 17 di DORA richiede un processo documentato di gestione degli incidenti con follow-up delle cause radice.

PCI DSS v4.0.1 Il requisito 11 include il rilevamento dei cambiamenti e della manomissione.

L’Elemento 106 della SEC si aspetta che un registrante descriva i suoi processi di identificazione dei rischi.

Ogni framework chiede se l’organizzazione governa le regole di rilevamento come artefatti controllati, non semplicemente se esistono regole.

Il test operativo: data una regola che si è attivata lo scorso trimestre, il team può produrre la sua completa genealogia? Chi l’ha scritta, chi l’ha recensita, quando è stata modificata l’ultima volta, perché, a quale obbligo si mappa e quale tecnica affronta. Una piattaforma di contenuti di rilevamento che gestisce le regole come codice versionato produce questa tracciabilità come sottoprodotto delle operazioni normali.

Dove le regole vengono modificate in una console senza controllo delle versioni, il revisore non ha alcuna provenienza per lo stato attuale della regola. La governance Detection-as-Code rimuove quell’ambiguità per costruzione.

Come diventa la copertura di rilevamento una voce di conformità?

La capacità di rilevamento tende a situarsi nei budget operativi, visibile al manager SOC, invisibile al CFO. Tre fatti rendono la copertura una conversazione per il consiglio di amministrazione.

Gli orologi di segnalazione iniziano al rilevamento. L’orologio di classificazione di 4 ore di DORA e l’orologio di materialità di quattro giorni lavorativi della SEC iniziano entrambi quando l’organizzazione rileva o diventa consapevole. Un rilevamento più rapido è l’inizio della cronologia della conformità.

L’evidenza di rilevamento è auditabile. Le cinque classi di prove sopra riportate sono ciò che un revisore esamina. Produrle costa tempo e personale, indipendentemente dal fatto che il team costruisca le proprie regole o sottoscriva una fonte di contenuti di rilevamento.

Il tempo di copertura è misurabile. La finestra tra una tecnica pubblica e un rilevamento convalidato che si attiva nell’ambiente dell’organizzazione è tracciabile.

Un team di ingegneria richiede capacità di rilevamento in termini di personale e strumenti. Un team di conformità la richiede in termini di produzione di evidenze. Il secondo inquadramento collega la spesa per il rilevamento a un obbligo normativo che il consiglio già traccia.

Un audit di postura SIEM produce la mappa di copertura che i revisori cercano: regole mappate a MITRE ATT&CK, fonti di log mappate alla stessa matrice e le lacune elencate con un piano.

Contatta le Vendite

Dove ciò non tiene

Si applicano diverse limitazioni.

Non tutti gli obblighi mappano al rilevamento. L’Elemento 1.05 della SEC richiede la divulgazione, non controlli specifici. L’articolo 21 di NIS2 e DORA includono sicurezza della catena di fornitura, continuità aziendale e gestione degli accessi. Nessuno di questi mappe alle tecniche ATT&CK. ATT&CK organizza il sottogruppo di rilevamento e monitoraggio, non l’intera superficie di conformità.

La trasposizione di NIS2 è incompleta. Dove la legge di trasposizione di uno Stato membro non è in vigore, gli articoli 21 e 23 di NIS2 non sono localmente applicabili. Gli emendamenti proposti nel gennaio 2026 non rinumerano gli articoli 21 o 23.

Le regole della SEC sono contestate. The petizione di revoca contro l’Elemento 1.05, presentata il 22 maggio 2025 da cinque associazioni di commercio bancario e dei valori mobiliari (File SEC n. 4-856), rimane irrisolta: al 21 settembre 2026, la SEC non ha proposto alcuna modifica all’Elemento 1.05, anche se i ricorrenti hanno rinnovato la richiesta in una lettera di commento dell’aprile 2026 nell’ambito della revisione del Regolamento S-K della Commissione. Una dichiarazione del 21 maggio 2024 di Erik Gerding, allora Direttore della Divisione di Finanza delle Corporazioni, ha chiarito che l’Elemento 1.05 è riservato agli incidenti che un registrante ha determinato essere materiali e ha incoraggiato la divulgazione di altri incidenti sotto un elemento diverso come l’Elemento 8.01; la Divisione ha seguito con Interpretazioni di Conformità e Divulgazione il 24 giugno 2024.

I numeri dei sotto-requisiti seguono v4.0.1. I sotto-requisiti PCI DSS citati qui (10.4.1, 10.4.1.1, 10.5.1, 10.7, 10.7.2, 11.5.1, 11.5.2, 11.6.1) utilizzano la numerazione v4.0.1; lo standard stesso è nella Libreria di documenti PCI SSC, e il Requisito 10.7.2 si applica a tutte le entità dal 31 marzo 2025.

ATT&CK è un raccordo, non un obbligo normativo. Mappare i rilevamenti alle tecniche ATT&CK organizza le prove. Non solleva da alcun obbligo normativo e nessun framework esaminato qui lo richiede.

DORA è lex specialis per le entità finanziarie. Una banca nel campo di applicazione DORA non applica gli articoli 21 e 23 di NIS2 in aggiunta per la propria gestione del rischio ICT e il reporting degli incidenti. NIS2 raggiunge la catena di fornitura non finanziaria di una banca, non le operazioni ICT della banca stessa.

LISTA DI CONTROLLO DELLE EVIDENZE DI AUDIT: OBBLIGHI DI RILEVAMENTO
 
1. FONTI DI LOG RACCOLTE

 [ ] Inventario delle fonti di telemetria acquisite

   [ ] Prova di raccolta continua (non puntuale)

   [ ] Ogni fonte mappata ai sistemi, beni e

       obblighi che copre 

2. REGOLE IMPLEMENTATE

 [ ] Inventario delle regole di rilevamento con proprietari nominati

   [ ] Ogni regola mappata all'obbligo normativo che supporta

   [ ] Ogni regola mappata alla tecnica ATT&CK ove applicabile

       (raccordo, non richiesto dalla normativa)

   [ ] Soglie di allarme documentate con giustificazione
 
3. PROVA DI ATTIVAZIONE

 [ ] Prova che le regole si sono attivate su eventi reali o emulati

   [ ] Registri che gli avvisi hanno raggiunto i soccorritori designati

   [ ] Registri di test datati per i meccanismi di rilevamento

       (Articolo 10 di DORA)

4. STORIA DELLE MODIFICHE
   
 [ ] Versionamento per ogni regola di rilevamento

       (Detection-as-Code)

   [ ] Autore, revisore, data e ora e giustificazione per ogni cambiamento

   [ ] Traccia di revisione e approvazione

   [ ] Registri di rilevamento di cambiamenti e manomissioni

5. RAPPORTO DI COPERTURA DATATO

 [ ] Rapporto di copertura puntuale con una data

   [ ] Copertura misurata rispetto al set di tecniche prioritario,

       non all'intera matrice ATT&CK

   [ ] Dati di tendenza che mostrano la copertura nel tempo

   [ ] Rapporti per ambiente (non un numero aggregato)

ELEMENTI SPECIFICI PER REGIME

   [ ] DORA: soglie di allarme documentate con giustificazione

       (Articolo 10)

   [ ] DORA: timestamp degli incidenti sugli orologi di segnalazione

       (4h dalla classificazione / 24h dalla presa di coscienza,

       72h intermedio, 1 mese finale)

   [ ] NIS2: prove mappate alla legge nazionale trasposta,

       non solo al testo della direttiva

   [ ] PCI DSS v4.0.1: mantenimento dei log per requisiti

       applicabili

   [ ] SEC: processo di determinazione della materialità documentato

       (Elemento 1.05)

   [ ] SEC: controllo da parte del consiglio di amministrazione e ruolo

        di gestione descritti (Elemento 106)

NOTE

- ATT&CK è il raccordo usato per organizzare queste prove.

  Non è richiesto da DORA, NIS2, PCI DSS, o dalle regole SEC.

- DORA è lex specialis: una banca nel campo di applicazione DORA applica DORA,

  non gli articoli 21 e 23 di NIS2, per la gestione del rischio ICT.

- PCI DSS v4.0.1 è l'unica versione attiva

  (v4.0 è stato ritirato il 31 dicembre 2024).

- Ogni specifica normativa in questo documento è convalidata

  da ciso-cto-sme prima della pubblicazione.

FAQ

Quali prove di rilevamento supportano gli obblighi sotto PCI DSS 4.0 e DORA?

Entrambi i regimi richiedono prove di rilevamento e monitoraggio continui, non solo prove che gli strumenti di rilevamento siano impiegati. Le cinque classi di prove sono: fonti di log raccolte, regole di rilevamento implementate con proprietari, prova che quelle regole si attivano, storia delle modifiche con controllo delle versioni e un rapporto di copertura datato. MITRE ATT&CK organizza queste prove per categoria di comportamento avversario. ATT&CK non è richiesto da nessuno dei due framework.

Quali prove cercano i revisori per confermare che i sistemi di rilevamento sono efficaci?

I revisori cercano cinque classi di prove: quali fonti di telemetria sono raccolte e che la raccolta è continua, regole di rilevamento mappate agli obblighi e tecniche ATT&CK con proprietari nominati, prova che quelle regole si attivano su eventi reali o simulati, storia delle modifiche controllata per ogni regola, e un rapporto di copertura puntuale datato. Una percentuale di copertura da sola, senza i registri di supporto sottostanti, non è prova.

La mappatura dei rilevamenti a MITRE ATT&CK soddisfa un regolatore?

ATT&CK è il raccordo che organizza le prove di rilevamento per comportamento avversario. Rende le prove interrogabili e riportabili per tecnica. Non assolve di per sé ad alcun obbligo normativo. DORA, NIS2, PCI DSS e le regole della SEC chiedono prove di operatività: monitoraggio, rilevamento, registrazione e divulgazione. ATT&CK organizza quelle prove. Nessun framework esaminato qui lo richiede.

Quali sono le tempistiche di segnalazione degli incidenti sotto DORA e NIS2?

Sotto DORA, il Regolamento Delegato (UE) 2025/301 definisce gli orologi per gli incidenti maggiori: notifica iniziale entro 4 ore dalla classificazione dell’incidente come maggiore (non oltre 24 ore dalla presa di coscienza), un rapporto intermedio entro 72 ore dalla notifica iniziale e un rapporto finale entro un mese dal rapporto intermedio. Sotto NIS2, gli incidenti significativi richiedono un avviso iniziale entro 24 ore dalla presa di coscienza, una notifica dell’incidente entro 72 ore, e un rapporto finale non oltre un mese dopo la notifica dell’incidente. Entrambi gli orologi iniziano al rilevamento, rendendo il timestamp di rilevamento stesso un record auditabile.

La Custom Content Engineering di SOC Prime implementa rilevamenti nel tuo SIEM o EDR e fornisce documentazione di alto livello sul loro scopo, funzione e utilizzo.

Contatta le Vendite