{"id":3083,"date":"2026-08-04T07:39:12","date_gmt":"2026-08-04T05:39:12","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/cra-compliance-checklist-vulnerability-disclosure-24-72-ore-risk-assessment-2026\/"},"modified":"2026-08-04T07:39:12","modified_gmt":"2026-08-04T05:39:12","slug":"cra-compliance-checklist-vulnerability-disclosure-24-72-ore-risk-assessment-2026","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/cra-compliance-checklist-vulnerability-disclosure-24-72-ore-risk-assessment-2026\/","title":{"rendered":"Cyber Resilience Act CRA Compliance Checklist Agosto 2026: Vulnerabilit\u00e0 Disclosure, Timeline 24\/72 Ore e Risk Assessment per Imprese Italiane"},"content":{"rendered":"

Siamo a pochi mesi dalla scadenza pi\u00f9 critica dell’agenda compliance europea del 2026. L’11 settembre 2026 entra in vigore l’obbligo di segnalazione delle vulnerabilit\u00e0 secondo il Cyber Resilience Act (CRA)<\/strong>, e nella mia esperienza di System Administrator e consulente di sicurezza, ho visto pochi team davvero pronti. Non \u00e8 una questione teorica: parliamo di penalit\u00e0 fino a 15 milioni di euro o il 2,5% del fatturato globale, e di procedure operative che devono funzionare in tempo reale, con scadenze di 24 e 72 ore dal momento della consapevolezza di una vulnerabilit\u00e0 attivamente sfruttata.<\/p>\n

Questo articolo trasforma i requisiti normativi del CRA in una checklist operativa concreta, con procedure step-by-step che ho testato direttamente in ambienti enterprise. Non \u00e8 teoria: \u00e8 quello che funziona sul campo per le imprese italiane che vendono o distribuiscono prodotti digitali verso il mercato UE.<\/p>\n

Il Perch\u00e9 Settembre 2026 \u00e8 il Vero Deadline (Non Dicembre 2027)<\/h2>\n

Il CRA \u00e8 entrato in vigore a dicembre 2024, con due scadenze critiche: la segnalazione obbligatoria inizia l’11 settembre 2026, e il CRA si applica completamente il 11 dicembre 2027.<\/cite> Molti responsabili compliance hanno calendarizzato il dicembre 2027, ma sbagliano profondamente. La segnalazione delle vulnerabilit\u00e0 parte 15 mesi prima della conformit\u00e0 totale, e gli obblighi di segnalazione si applicano anche ai prodotti legacy gi\u00e0 immessi sul mercato UE prima che il CRA si applichi pienamente.<\/cite><\/p>\n

Nel mio lavoro con aziende che producono software, plugin WordPress, device IoT e componenti embedded, ho visto accadere cos\u00ec: un’impresa ha un prodotto lanciato nel 2019, ancora in vendita nel 2026, viene scoperta una vulnerabilit\u00e0 attivamente sfruttata in agosto 2026. Dal momento in cui ne diviene consapevole, parte un timer a 24 ore. Non c’\u00e8 negoziazione.<\/p>\n

La Timeline di Segnalazione: Come Funziona la Disciplina 24\/72\/14 Giorni<\/h2>\n

I produttori devono inviare un avviso iniziale entro 24 ore dalla consapevolezza e una notifica completa entro 72 ore. Una relazione finale deve essere presentata non oltre 14 giorni dopo che una misura correttiva \u00e8 disponibile per le vulnerabilit\u00e0 attivamente sfruttate.<\/cite><\/p>\n

Questa non \u00e8 una procedura documentale astratta. Ho implementato questa disciplina in ambienti multi-cloud, e la chiave \u00e8 capire cosa significano esattamente le tre fasi:<\/p>\n

Fase 1: Early Warning (24 Ore)<\/h3>\n

Entro 24 ore dall’avviso, \u00e8 richiesta una notifica iniziale che comunica il verificarsi di una vulnerabilit\u00e0 attivamente sfruttata o di un incidente grave, incluso se si sospetta sia causato da atti illeciti o malvagi.<\/cite> Non deve essere perfetta. Deve essere: timestamp, ID prodotto, conferma che \u00e8 attivamente sfruttata, conferma che la vostra organizzazione ne \u00e8 a conoscenza.<\/p>\n

Il mio consiglio: usate un template minimalista nella vostra piattaforma di ticketing, pre-compilate le informazioni di cui avete gi\u00e0 il controllo (organizzazione, CSIRTs nazionali a cui rapportarsi, contatti tecnici). Il tempo di ritardo qui viene misurato in ore.<\/p>\n

Fase 2: Full Notification (72 Ore)<\/h3>\n

Entro 72 ore \u00e8 richiesto un resoconto pi\u00f9 completo che includa una valutazione iniziale, gravit\u00e0 e impatto, e dove disponibile le misure correttive o di attenuazione adottate.<\/cite> Qui entrano i dettagli: CVSS score, numero di istanze interessate, utenti potenzialmente impattati, patch status o timeline, workaround temporanei.<\/p>\n

Nel mio lavoro recente con una societ\u00e0 di hosting, questo step ha richiesto coordinamento tra team di sicurezza, sviluppo e operazioni. Ho automatizzato parte di questo compilando una CVSS template in base al tipo di vulnerabilit\u00e0, in modo che il team tecnico dovesse solo confermare o correggere il punteggio.<\/p>\n

Fase 3: Final Report (14 Giorni o 1 Mese)<\/h3>\n

Una relazione finale deve essere presentata non oltre 14 giorni dopo una misura correttiva per le vulnerabilit\u00e0 attivamente sfruttate, e entro un mese per gli incidenti gravi.<\/cite> Qui documentate la risoluzione completa: patch applicata, validazione di efficacia, comunicazioni agli utenti, tempo totale da discovery a remediation.<\/p>\n

Dove Segnalare: La Piattaforma Unica ENISA<\/h2>\n

La segnalazione avviene tramite un unico canale: l’Unione Single Reporting Platform di ENISA, indirizzata alla CSIRT nazionale designata del luogo di stabilimento principale.<\/cite> No, non comunicate a 27 stati membri separatamente. Una sola submissione via piattaforma ENISA.<\/p>\n

Le CSIRT nazionali italiane ricevono le notifiche e le propagano ad altre autorit\u00e0 se necessario (come ACN, l’Agenzia per la Cybersicurezza Nazionale). Il vostro interlocutore unico \u00e8 la CSIRT del vostro paese di residenza.<\/p>\n

Cosa Significa Essere “Consapevoli” di una Vulnerabilit\u00e0?<\/h2>\n

Questo \u00e8 il punto che genera pi\u00f9 confusione. Non significa 24 ore dalla remediation, non significa 24 ore da un’analisi root-cause completa, ma 24 ore dal momento in cui sapete che la vulnerabilit\u00e0 esiste ed \u00e8 sfruttabile.<\/cite><\/p>\n

Nell’esperienza pratica:<\/p>\n

    \n
  • Un ricercatore invia una segnalazione via il vostro coordinamento vulnerabilit\u00e0 disclosure (CVD) alle 10:00 di luned\u00ec e asserisce che la vulnerabilit\u00e0 \u00e8 attivamente sfruttata in wild? Inizia qui il timer. Non da quando la validate, non da quando la capite, da quando la ricevete.<\/li>\n
  • Vedete un alert dalla vostra piattaforma di threat intelligence che una CVE del vostro prodotto \u00e8 in exploit exploit kit? Timer inizia.<\/li>\n
  • La CSIRT locale vi contatta per una vulnerabilit\u00e0 zero-day nel vostro software? Timer inizia.<\/li>\n<\/ul>\n

    Per questo motivo, qualsiasi processo manuale nel vostro workflow di vulnerability management che non possa completarsi entro quella finestra \u00e8 un rischio di conformit\u00e0. Qualsiasi lacuna nella visibilit\u00e0 dei componenti che possa ritardare la consapevolezza di una vulnerabilit\u00e0 appena divulgata \u00e8 un rischio di conformit\u00e0. Qualsiasi ambiguit\u00e0 su chi nell’organizzazione sia responsabile di iniziare il processo di notifica \u00e8 un rischio di conformit\u00e0.<\/cite><\/p>\n

    Checklist Operativa: I 7 Passi Fondamentali per Settembre 2026<\/h2>\n

    Passo 1: Definire il Perimetro dei Prodotti in Scope<\/h3>\n

    Non ogni cosa che producete \u00e8 soggetta al CRA. La normativa si applica a “prodotti con elementi digitali” \u2013 software, device IoT, sistemi embedded, firmware. Nel mio team, abbiamo mappato:<\/p>\n

      \n
    • Software proprietario distribuito via cloud o on-premise: SCOPE<\/strong><\/li>\n
    • Plugin WordPress commerciali o freemium: SCOPE<\/strong><\/li>\n
    • Componenti embedded in router\/switch: SCOPE<\/strong><\/li>\n
    • Servizi di consulenza pura: OUT OF SCOPE<\/strong><\/li>\n
    • Documentazione tecnica: OUT OF SCOPE<\/strong><\/li>\n<\/ul>\n

      Create un inventario Excel o foglio Google con: ID prodotto, versioni in supporto, data lancio sul mercato UE, classification (critico\/importante\/altro), proprietario del prodotto, responsabile della sicurezza.<\/p>\n

      Passo 2: Implementare la Software Bill of Materials (SBOM)<\/h3>\n

      Il clock di segnalazione, gli obblighi di patching e l’audit evidence dipendono tutti da una cosa: sapere esattamente cosa \u00e8 stato spedito dentro il vostro prodotto. Sbagliare questo punto, e ogni obbligo downstream si rompe.<\/cite><\/p>\n

      Nel mio workflow con Plesk e WordPress, genero SBOM utilizzando strumenti como Cyclone DX o SPDX. Per WordPress, ad esempio:<\/p>\n

        \n
      • Versione core di WordPress<\/li>\n
      • Tutte le dipendenze PHP (tramite Composer)<\/li>\n
      • Tutti i plugin commerciali + loro versioni<\/li>\n
      • Librerie JavaScript esterne (npm, yarn)<\/li>\n
      • Versioni di librerie di sistema (OpenSSL, libcurl, ecc.)<\/li>\n<\/ul>\n

        Una SBOM non \u00e8 un documento statico. Deve essere rigenerata ogni volta che aggiornate un componente, ogni release di prodotto, come parte dell’automazione CI\/CD.<\/p>\n

        Passo 3: Mettere in Piedi un Coordinated Vulnerability Disclosure (CVD) Program<\/h3>\n

        Impostate una politica di divulgazione coordinata e un unico punto di contatto, allineati a ISO\/IEC 29147 e ISO\/IEC 30111.<\/cite><\/p>\n

        Praticamente, questo significa:<\/p>\n

          \n
        • Una pagina security.txt nel vostro sito (\/.well-known\/security.txt) che pubblica come contattare il vostro team di sicurezza<\/li>\n
        • Un indirizzo email dedicato tipo security@vostrodominio.com, con risposta garantita entro 24 ore<\/li>\n
        • Una chiave PGP pubblica per ricevere segnalazioni criptate<\/li>\n
        • Una politica scritta che specifica: come rapportarsi, tempistiche di risposta, embargo periods, accrediti<\/li>\n<\/ul>\n

          Ho usato HackerOne o Bugcrowd per automatizzare questo, ma per PMI una semplice mailbox monitorata con ticketing internal funziona.<\/p>\n

          Passo 4: Designare il Reporter CRA e l’Escalation Chain<\/h3>\n

          Chi effettivamente presenta la notifica? Chi \u00e8 il backup se sono in vacanza? Chi ha l’autorit\u00e0 di decidere se un segnale \u00e8 “attivamente sfruttato”? In molte organizzazioni, la risposta \u00e8 “lo decidessimo al momento”. Questa \u00e8 la risposta che produce una deadline mancata.<\/cite><\/p>\n

          Nel mio setup interno:<\/p>\n