Obblighi di penetration test per normativa: guida mondiale (2026)

Le normative parlano di penetration test in tre modi diversi, e la differenza cambia sia ciò che devi acquistare sia ciò che devi mettere per iscritto.

• Obbligo esplicito: il testo nomina il test e fissa una frequenza o un evento scatenante. NYDFS §500.5(a)(1), PCI DSS 11.3 e 11.4, i CSCC sauditi per i sistemi critici, il Livello 3 del CMMC e, per le istituzioni designate, il TLPT DORA. Se l'intervallo salta, nessuna valutazione del rischio lo compensa.
• Obbligo basato sul rischio: test o gestione delle vulnerabilità sono obbligatori, ma tipo e frequenza discendono dalla tua valutazione del rischio. Art. 21 NIS2, il programma di test DORA (con una soglia annuale sulle funzioni essenziali o importanti e scansioni settimanali), APRA CPS 234, analisi dei rischi e valutazione HIPAA, ECC 2-11 saudita («periodicamente») e, in Italia, le misure ACN per i soggetti essenziali («periodicamente e prima della messa in esercizio»).
• Aspettativa di vigilanza: linee guida che non sono legge ma con cui l'autorità ti confronta, come la sezione 13 delle MAS TRM, la CPG 234 dell'APRA, il Cyber Assessment Framework dell'NCSC, la NIST SP 800-66r2 e, per la sanità, le HICP di HHS 405(d).

Le norme basate sul rischio non sono più morbide. Quando una norma ti lascia scegliere la frequenza, chi ispeziona verifica che la scelta sia scritta, discenda dalla valutazione del rischio e sia stata davvero applicata. E una delle normative di questa guida non impone alcun test: le regole SEC sulla disclosure, che però si aspettano che i processi descritti ogni anno esistano davvero.

Ogni voce qui sotto rimanda a una guida dettagliata che cita il testo punto per punto e le sue fonti primarie. Dove gli elenchi dicono «Chi può testare», descrivono ciò che il testo richiede, non chi sia più adatto a farlo.

NIS2, con il regolamento di esecuzione (UE) 2024/2690 e le misure ACN italiane. Guida dettagliata: VA/PT e NIS2: D.Lgs. 138/2024 e misure ACN.

• Ambito: soggetti essenziali e importanti ai sensi della direttiva (UE) 2022/2555. Il regolamento 2024/2690 vincola un elenco preciso di fornitori digitali: DNS, registri dei domini di primo livello, cloud, data center, CDN, MSP, MSSP, mercati online, motori di ricerca, social network e servizi fiduciari.
• Cosa è richiesto: gestione e divulgazione delle vulnerabilità e politiche per valutare l'efficacia delle misure (art. 21(2), lettere e) e f)); la direttiva non nomina mai il penetration test. Il regolamento 2024/2690 chiede una politica di security testing e, ove opportuno, scansioni di vulnerabilità. In Italia la misura ACN ID.RA-01 impone ai soggetti essenziali vulnerability assessment e/o penetration test almeno sui sistemi rilevanti.
• Frequenza: basata sul rischio; «a intervalli pianificati» per il 2024/2690; in Italia «periodicamente e comunque prima della messa in esercizio», con le misure ACN da adottare entro 18 mesi dalla comunicazione di inserimento (ottobre 2026 per chi è in elenco dal 2025, 31 luglio 2027 per chi è inserito per la prima volta nel 2026).
• Chi può testare: nessun testo impone un tester esterno o certificato. Il regolamento 2024/2690 chiede competenze di audit e indipendenza per il riesame indipendente dell'approccio complessivo, non per ogni singolo test.
• Evidenze: relazioni di VA/PT con ogni vulnerabilità e il suo impatto (ID.RA-01), un piano di gestione delle vulnerabilità approvato dai vertici (ID.RA-08), criticità e mitigazione per ogni finding (punto 6.5 del 2024/2690), registri di correzione e retest.

Programma di test DORA, articoli 24 e 25. Guida dettagliata: test di resilienza DORA oltre il TLPT.

• Ambito: tutte le entità finanziarie del regolamento (UE) 2022/2554 tranne le microimprese, che testano con un approccio basato sul rischio più leggero (art. 25(3)).
• Cosa è richiesto: un programma di test basato sul rischio; l'art. 25(1) elenca i test previsti, dalle scansioni di vulnerabilità alla revisione del codice sorgente fino al penetration test. Il regolamento non impone un penetration test su ogni sistema ogni anno, ma le sole scansioni sono difficili da difendere dove la domanda è la sfruttabilità.
• Frequenza: almeno una volta l'anno, test adeguati su tutti i sistemi e le applicazioni ICT a supporto di funzioni essenziali o importanti (art. 24(6)); scansione automatica delle vulnerabilità di quegli asset almeno settimanale (RTS 2024/1774, art. 10(2)).
• Chi può testare: soggetti indipendenti, interni o esterni; i tester interni richiedono risorse sufficienti e l'assenza di conflitti di interesse (art. 24(4)).
• Evidenze: la mappa dalle funzioni essenziali o importanti ai sistemi, una matrice dei test, la documentazione dell'indipendenza e un registro dei finding con una fase di convalida che conferma ogni correzione (art. 24(5)).

Threat-led penetration testing (TLPT) DORA, articoli 26 e 27. Guide dettagliate: il TLPT nel DORA e il playbook sull'ingaggio TLPT.

• Ambito: solo le entità finanziarie individuate dalle autorità secondo i criteri e l'elenco predefinito dell'RTS 2025/1190, per esempio enti creditizi G-SII e O-SII, depositari centrali di titoli, controparti centrali e i maggiori istituti di pagamento e di moneta elettronica.
• Cosa è richiesto: un test di red team guidato dall'intelligence sui sistemi di produzione a supporto di funzioni essenziali o importanti, con una fase attiva di almeno 12 settimane, seguita da replay ed esercizio di purple teaming.
• Frequenza: almeno ogni tre anni. Dalla notifica all'attestazione l'ingaggio richiede realisticamente da 12 a 18 mesi.
• Chi può testare: il fornitore di threat intelligence è sempre esterno; tester interni solo con l'approvazione dell'autorità, e tester esterni ogni tre test; gli enti creditizi significativi vigilati nell'SSM usano solo tester esterni. I fornitori devono rispettare le soglie di esperienza, referenze e assicurazione dell'art. 5(2) dell'RTS.
• Evidenze: documento di definizione del perimetro approvato dall'organo di gestione, report del red team e del blue team, rapporto di sintesi, piano di correzione con analisi delle cause e attestazione dell'autorità (art. 26(7) DORA).

NYDFS 23 NYCRR Part 500, §500.5. Guida dettagliata: penetration test nella NYDFS Part 500.

• Ambito: covered entity autorizzate ai sensi del Banking Law, dell'Insurance Law o del Financial Services Law dello Stato di New York. Chi gode dell'esenzione limitata del §500.19(a) è esentato dal §500.5.
• Cosa è richiesto: penetration test sia dall'interno sia dall'esterno del perimetro dei sistemi informativi; scansioni automatiche più una revisione manuale dei sistemi non coperti; monitoraggio delle nuove vulnerabilità; correzione tempestiva con priorità basata sul rischio.
• Frequenza: penetration test almeno annuale; scansioni con la frequenza stabilita dalla valutazione del rischio e subito dopo ogni modifica rilevante dei sistemi.
• Chi può testare: un soggetto qualificato, interno o esterno. La Part 500 non definisce «qualificato»: documenta esperienza, indipendenza e metodologia.
• Evidenze: report di test con entrambe le prospettive, registri delle scansioni e delle correzioni a supporto della comunicazione annuale del 15 aprile, firmata dal vertice esecutivo e dal CISO; la documentazione si conserva per cinque anni.

HIPAA Security Rule. Guida dettagliata: penetration test e HIPAA.

• Ambito: covered entity e business associate che trattano informazioni sanitarie elettroniche protette (ePHI).
• Cosa è richiesto: oggi, un'analisi dei rischi accurata e approfondita (§164.308(a)(1)(ii)(A)) e una valutazione periodica tecnica e non tecnica (§164.308(a)(8)); la norma non nomina mai né il penetration test né le scansioni. La proposta HHS di gennaio 2025 li aggiungerebbe entrambi.
• Frequenza: nessuna nella norma in vigore. La proposta imporrebbe scansioni almeno ogni sei mesi e un penetration test almeno ogni 12 mesi; al 30 settembre 2026 non è definitiva, e l'agenda regolatoria più recente indica l'adozione per luglio 2027.
• Chi può testare: nessuna norma impone un tester esterno. La proposta chiede una persona qualificata, e le HICP di HHS 405(d) ammettono personale interno qualificato o partner esterni.
• Evidenze: inventario, analisi dei rischi, risultati di scansioni e test, correzioni e retest, conservati per sei anni (§164.316(b)). Nel fissare le sanzioni HHS deve considerare le pratiche di sicurezza riconosciute adottate nei 12 mesi precedenti (Public Law 116-321).

PCI DSS v4.0.1, requisiti 11.3 e 11.4 (pagamenti con carta, in tutto il mondo). Guida dettagliata: PCI DSS 11.3 e 11.4.

• Ambito: chi memorizza, elabora o trasmette dati delle carte di pagamento. Se e come convalidare la conformità lo stabiliscono i circuiti di pagamento e l'acquirer, non il PCI SSC.
• Cosa è richiesto: scansioni di vulnerabilità interne ed esterne (11.3); penetration test interni ed esterni secondo una metodologia documentata (da 11.4.1 a 11.4.3); test ripetuti per verificare le correzioni (11.4.4); test di segmentazione (11.4.5).
• Frequenza: scansioni almeno ogni tre mesi e dopo modifiche significative; penetration test almeno ogni 12 mesi e dopo modifiche significative; test di segmentazione ogni 12 mesi, o ogni sei mesi per i service provider (11.4.6).
• Chi può testare: una risorsa interna qualificata o un soggetto esterno qualificato, con indipendenza organizzativa, non necessariamente un QSA o un ASV. Le scansioni esterne trimestrali devono provenire da un Approved Scanning Vendor del PCI SSC.
• Evidenze: la metodologia, 12 mesi di report di test con le qualifiche dei tester, quattro trimestri di scansioni ASV superate e di scansioni interne, registri di correzione e retest, registri delle modifiche; risultati conservati per almeno 12 mesi.

CMMC, 32 CFR Part 170. Guida dettagliata: evidenze per la Fase 2 del CMMC.

• Ambito: fornitori della difesa i cui sistemi informativi elaborano, conservano o trasmettono FCI o CUI. Dal 10 novembre 2026 (Fase 2) il DoD intende richiedere lo status Level 2 (C3PAO) come condizione di aggiudicazione nei bandi applicabili.
• Cosa è richiesto: al Livello 2 (NIST SP 800-171 Rev. 2), scansione delle vulnerabilità (3.11.2), correzione in base al rischio (3.11.3) e valutazioni periodiche dei controlli (3.12.1); il Livello 3 aggiunge il penetration test (3.12.1e).
• Frequenza: «periodicamente» significa un intervallo definito da te e non superiore a un anno; al Livello 3 penetration test almeno annuale o quando si apportano modifiche di sicurezza significative.
• Chi può testare: i test li esegue il fornitore; un C3PAO valuta il Livello 2 e il DIBCAC della DCMA il Livello 3. Per il 3.12.1e il NIST si aspetta un team con le competenze adeguate e obiettivo nella valutazione.
• Evidenze: artefatti in forma definitiva, con hash e conservati per sei anni (§170.17(c)(4)), comprese le frequenze definite, i risultati delle scansioni, i piani d'azione e i report dei test.

Regole SEC sulla disclosure cyber. Guida dettagliata: playbook SEC Form 8-K Item 1.05.

• Ambito: società che presentano relazioni ai sensi del Securities Exchange Act del 1934.
• Cosa è richiesto: nessun test. Un Form 8-K Item 1.05 entro quattro giorni lavorativi dalla valutazione che un incidente è rilevante, e una descrizione annuale della gestione del rischio cyber ai sensi del Regulation S-K Item 106.
• Frequenza: nessuna per i test; la descrizione dell'Item 106 compare in ogni relazione annuale.
• Chi può testare: il tema non è trattato. L'Item 106 chiede se la società si avvale di assessor, consulenti, auditor o altri terzi.
• Evidenze: se la relazione annuale dice che la società esegue penetration test regolari, conserva i report datati, i registri di correzione e la reportistica al board che lo dimostrano.

CBEST, la valutazione guidata dall'intelligence di Bank of England, PRA e FCA. Guida dettagliata: penetration test nel Regno Unito: CBEST e CAF.

• Ambito: istituzioni e infrastrutture dei mercati finanziari che i regolatori scelgono nel ciclo di vigilanza, che chiedono un CBEST con il consenso del regolatore o a cui viene richiesto dopo un incidente.
• Cosa è richiesto: un penetration test guidato dall'intelligence sui sistemi in produzione dietro gli important business service, seguito da un piano di rimedio che il regolatore segue. Il CBEST non ha un esito superato o non superato.
• Frequenza: su richiesta, senza un ciclo fisso. Un CBEST dura in media da 9 a 12 mesi, con circa 14 settimane di penetration test.
• Chi può testare: fornitori di threat intelligence e di penetration test accreditati CBEST e membri CREST, guidati da persone certificate.
• Evidenze: specifica del perimetro, registri di accreditamento e certificazione dei fornitori, piani di test e di gestione del rischio, report finale, piano di rimedio e aggiornamenti inviati al regolatore.

Cyber Assessment Framework (CAF) v4.0 dell'NCSC. Stessa guida dettagliata.

• Ambito: organizzazioni la cui gestione del rischio cyber sulle funzioni essenziali viene valutata, da loro stesse o da valutatori indipendenti come i regolatori. L'NCSC non ha poteri regolatori: chiedi al tuo regolatore se e come il CAF si applica.
• Cosa è richiesto: il risultato B4.d (gestione delle vulnerabilità) si aspetta test regolari per comprendere a fondo le vulnerabilità e una mitigazione tempestiva; A2.c (assurance) si aspetta metodi scelti conoscendone i limiti, compresi i rischi del penetration test negli ambienti operativi.
• Frequenza: «regolarmente» e «di recente», senza un intervallo fisso.
• Chi può testare: il tuo team per i test regolari; il livello «achieved» del B4.d richiede anche una verifica con test di terze parti. L'NCSC raccomanda tester CHECK per le organizzazioni del governo britannico (HMG).
• Evidenze: il registro dell'esposizione alle vulnerabilità note, tracciamento e date di mitigazione, i risultati dei tuoi test, i report dei test di terze parti e le ragioni di ogni metodo di assurance.

Singapore: sezione 13 delle Technology Risk Management Guidelines della MAS. Guida dettagliata: penetration test e MAS TRM.

• Ambito: istituzioni finanziarie vigilate dalla MAS. Le linee guida non sono legge, ma la MAS considera quanto un'istituzione ne rispetta lo spirito; per le banche, il Notice FSM-N06, vincolante, impone tempi di patch coerenti con il rischio di ogni vulnerabilità.
• Cosa è richiesto: vulnerability assessment regolare con un perimetro minimo; penetration test in produzione con adeguate salvaguardie; test black box e grey box per i servizi finanziari online; esercitazioni di simulazione di attacco avversario; un processo di correzione con tempi per livello di gravità.
• Frequenza: i sistemi direttamente accessibili da internet almeno una volta l'anno e a ogni modifica o aggiornamento rilevante (13.2.4); gli altri test con una frequenza commisurata a criticità ed esposizione.
• Chi può testare: non è indicato un tipo di tester; il test deve fornire la valutazione approfondita richiesta dal 13.2.1.
• Evidenze: registri di VA, report di PT con tipo di test e salvaguardie in produzione, inventario dei sistemi esposti su internet con le date dei test, registri delle esercitazioni e registro delle correzioni.

Australia: Prudential Standard CPS 234 dell'APRA. Guida dettagliata: test di sicurezza nella APRA CPS 234.

• Ambito: tutti i soggetti vigilati dall'APRA, tra cui ADI, assicuratori danni, compagnie vita, assicuratori sanitari privati e RSE licensee, con le relative holding non operative.
• Cosa è richiesto: un programma sistematico di test dei controlli di sicurezza, vincolante dal 1° luglio 2019. La CPS 234 non nomina mai il penetration test; la guida CPG 234 dell'APRA include penetration test e test di red team tra le tecniche.
• Frequenza: commisurata a minacce, criticità, conseguenze, esposizione ad ambienti non fidati e cambiamenti (par. 27), con un riesame del programma almeno annuale (par. 31). La CPG 234 si aspetta un insieme sufficiente di controlli testato almeno ogni anno e test durante tutto l'anno sui controlli esposti ad ambienti non fidati.
• Chi può testare: specialisti competenti e funzionalmente indipendenti (par. 30). Non serve un tester esterno; per la CPG 234 indipendenza significa tester senza responsabilità operative sui controlli che verificano.
• Evidenze: il programma e le sue motivazioni, report di test con i ruoli dei tester, documentazione dell'indipendenza, finding ed escalation. Una debolezza rilevante dei controlli che non si può correggere in tempi adeguati va notificata all'APRA entro 10 giorni lavorativi (par. 36).

Arabia Saudita: Essential Cybersecurity Controls (ECC-2:2024) e Critical Systems Cybersecurity Controls (CSCC) dell'NCA. Guida dettagliata: penetration test in Arabia Saudita: ECC dell'NCA.

• Ambito: enti governativi e relative società ed entità collegate, in Arabia Saudita e all'estero, e soggetti privati che possiedono, gestiscono o ospitano infrastrutture critiche nazionali. I CSCC aggiungono controlli per i sistemi che l'organizzazione ritiene critici.
• Cosa è richiesto: vulnerability assessment periodico con correzione in base alla gravità (ECC 2-10); penetration test che coprano almeno tutti i servizi erogati verso l'esterno e i loro componenti tecnici (ECC 2-11). Per i sistemi critici i CSCC estendono il perimetro a tutti i servizi interni ed esterni.
• Frequenza: «periodicamente» secondo l'ECC. Secondo i CSCC, vulnerability assessment almeno mensile e penetration test almeno ogni sei mesi sui sistemi critici.
• Chi può testare: l'ECC non lo dice e i CSCC chiedono un team qualificato. L'ECC 1-8 impone un riesame e un audit indipendenti dei controlli da parte di soggetti diversi dalla funzione cybersecurity.
• Evidenze: documenti dei requisiti approvati, elenco dei sistemi critici, registri di VA che mostrano la cadenza mensile, report di penetration test con perimetro, data e team, e risultati dell'audit indipendente.

Emirati Arabi Uniti e altri Paesi del Golfo non sono ancora trattati in questa guida.

La maggior parte delle normative qui sopra chiede le stesse sei cose con parole diverse. Costruisci il programma attorno a queste una volta sola, poi sovrapponi le frequenze e le regole sui tester di ciascuna normativa.

1. Perimetro da un unico inventario. Ogni normativa parte da un elenco: sistemi rilevanti (ACN), sistemi a supporto di funzioni essenziali o importanti (DORA), ambiente dei dati dei titolari di carta e sistemi critici (PCI DSS), sistemi che trattano ePHI (HIPAA), sistemi direttamente accessibili da internet (MAS TRM), sistemi critici (CSCC). Tieni un solo inventario degli asset, etichetta ogni asset con le normative che si applicano e scrivi ogni esclusione con il suo motivo.
2. Una metodologia scritta. Il PCI DSS 11.4.1 la richiede espressamente, il regolamento 2024/2690 chiede test secondo una metodologia documentata e il TLPT segue l'RTS. Copri i test dall'interno e dall'esterno (NYDFS, PCI DSS), i test black box e grey box (MAS TRM), le regole d'ingaggio e le salvaguardie per i sistemi di produzione.
3. Frequenza fissata dalla normativa più severa che si applica. Quando un asset ricade in più normative vince l'intervallo più breve: per esempio scansioni settimanali sugli asset delle funzioni essenziali DORA, scansioni trimestrali per il PCI DSS, assessment mensile e test semestrali sui sistemi critici sauditi, e almeno un penetration test annuale per NYDFS e PCI DSS. Registra anche gli eventi scatenanti: le modifiche significative o rilevanti richiedono nuove scansioni o nuovi test per PCI DSS, NYDFS e MAS TRM.
4. Indipendenza documentata. Per ogni test, chi l'ha eseguito, con quali qualifiche e perché è indipendente dai sistemi testati. Dove una normativa indica un soggetto accreditato o esterno (scansioni ASV, fornitori CBEST, fornitore di threat intelligence del TLPT, verifica di terze parti del CAF), quel soggetto non è facoltativo.
5. Un unico registro dei finding. Sfruttabilità, priorità basata sul rischio, responsabile, data obiettivo ed eventuale rischio accettato con la relativa approvazione. Lo chiedono l'art. 24(5) DORA, il §500.5(c) NYDFS, il 13.6 delle MAS TRM e il 3.12.2 del CMMC.
6. Retest, poi approvazione. Un finding si chiude quando il retest è superato (PCI DSS 11.4.4, art. 24(5) DORA). L'approvazione ha forme diverse in ogni normativa: il piano di gestione delle vulnerabilità approvato dai vertici (ACN), il perimetro del TLPT approvato dall'organo di gestione (DORA), la comunicazione annuale firmata dal vertice esecutivo e dal CISO (NYDFS), l'escalation al Board o all'alta direzione (APRA), l'affermazione annuale (CMMC). Conserva le approvazioni insieme alle evidenze.

La conservazione segue la stessa regola: vince il periodo più lungo. Sei anni per la documentazione HIPAA e gli artefatti CMMC, cinque anni per la documentazione NYDFS, almeno 12 mesi per i risultati dei test PCI DSS.

Zero Hunt è un red team AI autonomo per reti e infrastrutture che gira su un'appliance on-premise, su AI privata, con human in the loop. In tutte queste normative svolge lo stesso compito: produce evidenze di test nei mesi tra un test e l'altro che regolatori e assessor richiedono a soggetti specifici. Per la categoria in generale vedi il penetration test automatizzato.

• Test black box e gray box continui. Campagne dall'esterno e con i privilegi di un utente standard, eseguite una volta, ogni giorno, ogni settimana, ogni mese o con una pianificazione personalizzata, e dopo ogni modifica: i test legati a un evento non aspettano uno slot di ingaggio.
• Finding dimostrati sfruttabili, poi ritestati. Ogni finding registra se è stato sfruttato nel tuo ambiente, il dato che serve alla correzione basata sul rischio, e ogni correzione si ritesta con la stessa prova.
• Evidenze mappate su 34 framework. Tra questi NIS2, DORA e TIBER-EU, NYDFS Part 500, HIPAA, PCI DSS 4.0.1, CMMC, le regole SEC, MAS TRM, APRA CPS 234, CBEST, UK CAF e NCA saudita, con report di conformità esportabili. Il motore non mappa sui codici delle misure ACN, e alcuni suoi riferimenti ai controlli non seguono la numerazione dei regolatori: il collegamento dei report ai paragrafi resta nella tua documentazione.
• Approvazione umana dei passi rischiosi. Cinque livelli di autonomia stabiliscono cosa deve attendere un operatore, e i proof of concept di exploit possono restare in attesa di revisione. Vedi human in the loop.
• Registri che reggono. Ogni tentativo di attacco è una voce firmata Ed25519 in una catena di hash SHA-256 per campagna, verificabile offline, e i report esportati sono firmati ECDSA.
• Nessun dato del cliente lascia l'appliance. I modelli girano sull'appliance senza servizi AI esterni, quindi i test non aggiungono un terzo da valutare; in modalità air-gapped sono disattivati anche i download da fonti pubbliche. Vedi red team AI on-premise.

Cosa non sostituisce: l'ASV del PCI, un QSA o un C3PAO, i fornitori accreditati CBEST, i tester del TLPT e il fornitore esterno di threat intelligence, la verifica di terze parti richiesta dal B4.d del CAF, i riesami indipendenti previsti dal regolamento 2024/2690 e dall'ECC 1-8 saudita, o il tester qualificato e indipendente che diverse normative indicano. Non rende indipendente il tuo team e non decide se sei conforme. Per capire quali di queste normative si applicano a te e dove le tue evidenze hanno lacune, prenota una call di readiness di 30 minuti.

Ogni fatto di questa guida è tratto dalle guide dettagliate collegate sopra, ciascuna con il proprio elenco completo di fonti primarie. I testi principali:

• Direttiva (UE) 2022/2555 (NIS2) (EUR-Lex)
• Regolamento di esecuzione (UE) 2024/2690 (EUR-Lex)
• Allegato 2 ACN, misure di sicurezza di base per i soggetti essenziali (PDF, acn.gov.it)
• Regolamento (UE) 2022/2554 (DORA) (EUR-Lex)
• Regolamento delegato (UE) 2024/1774, RTS sul quadro di gestione dei rischi ICT (EUR-Lex)
• Regolamento delegato (UE) 2025/1190, RTS sul TLPT (EUR-Lex)
• 23 NYCRR Part 500 modificato dal Second Amendment (NYDFS, PDF)
• 45 CFR Part 164, Subpart C, Security Standards (eCFR)
• Proposta di modifica della HIPAA Security Rule, 90 FR 898 (Federal Register)
• PCI Data Security Standard (PCI SSC)
• 32 CFR Part 170, programma CMMC (eCFR)
• Release 33-11216, Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure (SEC)
• MAS Technology Risk Management Guidelines, gennaio 2021 (PDF, mas.gov.sg)
• APRA Prudential Standard CPS 234 Information Security (apra.gov.au)
• CBEST Implementation Guide 2024 (Bank of England)
• NCSC CAF v4.0, Principle B4 System security (ncsc.gov.uk)
• NCA Essential Cybersecurity Controls ECC-2:2024 (PDF, nca.gov.sa)
• NCA Critical Systems Cybersecurity Controls CSCC-1:2019 (PDF, nca.gov.sa)