{"id":5126,"date":"2026-09-29T09:10:09","date_gmt":"2026-09-29T07:10:09","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/cyber-resilience-act-compliance-vulnerability-notification-enisa-srp-incident-response\/"},"modified":"2026-09-29T09:10:09","modified_gmt":"2026-09-29T07:10:09","slug":"cyber-resilience-act-compliance-vulnerability-notification-enisa-srp-incident-response","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/cyber-resilience-act-compliance-vulnerability-notification-enisa-srp-incident-response\/","title":{"rendered":"Come Implementare Cyber Resilience Act Compliance da 11 Settembre 2026: La Mia Checklist Vulnerability Notification, ENISA Single Reporting Platform e Incident Response Automation per PMI"},"content":{"rendered":"

Il Cyber Resilience Act (CRA)<\/strong> \u00e8 entrato in vigore il 10 dicembre 2024, ma il primo deadline operativo e vincolante arriva il prossimo 11 settembre 2026<\/strong>. Da quella data, i produttori di prodotti con elementi digitali che operano nel mercato UE dovranno conformarsi agli obblighi di notificazione delle vulnerabilit\u00e0 attivamente sfruttate e dei gravi incidenti di sicurezza. Nella mia esperienza come System Administrator, ho visto troppe PMI italiane sottovalutare questi obblighi: il costo della non conformit\u00e0 \u00e8 fino a 15 milioni di euro o il 2,5% del fatturato mondiale annuo, oltre al ritiro dal mercato europeo.<\/p>\n

In questo articolo condivido la procedura operativa che ho testato per allineare le PMI italiane alle nuove regole, integrando la Single Reporting Platform (SRP)<\/strong> dell’ENISA, i template di notifica e l’automazione del ciclo di incident response. Non si tratta solo di compliance formale, ma di architettura vera e propria che accelera il rilevamento e la segnalazione, proteggendo il vostro accesso al mercato europeo.<\/p>\n

Cosa Cambia il 11 Settembre 2026: Deadlines Critici e Obblighi Vincolanti<\/h2>\n

Dal 11 settembre 2026, un elemento chiave dell’EU Cyber Resilience Act entra in vigore: gli obblighi di notificazione di vulnerabilit\u00e0 e incidenti, che richiedono alle vulnerabilit\u00e0 attivamente sfruttate nei prodotti con elementi digitali e ai gravi incidenti che impattano la sicurezza dei prodotti di essere segnalati alle autorit\u00e0 competenti.<\/cite><\/p>\n

I tempi sono serrati e non permettono processi improvvisati:<\/p>\n

    \n
  • 24 ore:<\/strong> I produttori devono presentare un avviso preventivo entro 24 ore da quando sono a conoscenza di un evento segnalabile<\/cite><\/li>\n
  • 72 ore:<\/strong> Notifica dettagliata entro 72 ore<\/cite><\/li>\n
  • 14 giorni \/ 1 mese:<\/strong> Rapporto finale entro 14 giorni dal rilascio di una misura correttiva o mitigante per una vulnerabilit\u00e0 attivamente sfruttata, o entro un mese dalla notifica di 72 ore per gravi incidenti<\/cite><\/li>\n<\/ul>\n

    Ho inizialmente sottovalutato il vincolo delle 24 ore, pensando fosse il tempo per completare la triage. Sbagliato: il clock inizia quando diventi consapevole dell’evento, non quando finisci di fare la triage. Il clock parte da “consapevolezza”, non da “fine dell’analisi”.<\/cite> Questa differenza \u00e8 critica per la pianificazione operativa.<\/p>\n

    La Single Reporting Platform ENISA: Accesso e Registrazione<\/h2>\n

    L’EU Agency for Cybersecurity ha attivato la Cyber Resilience Act’s Single Reporting Platform l’11 settembre 2026, lo stesso giorno in cui gli obblighi di notificazione della legge hanno iniziato a vincolato i produttori.<\/cite><\/p>\n

    La Single Reporting Platform (SRP) \u00e8 lo strumento online sviluppato, operato e mantenuto da ENISA per consentire ai produttori e, una volta applicabile, ai curatori di software open-source di adempiere ai loro obblighi di notificazione secondo il Cyber Resilience Act per le vulnerabilit\u00e0 attivamente sfruttate e i gravi incidenti che hanno un impatto sulla sicurezza dei prodotti con elementi digitali resi disponibili sul mercato UE.<\/cite><\/p>\n

    Ho testato l’accesso al portale (indirizzo: portal.cra-srp.enisa.europa.eu) e la procedura operativa. I passaggi fondamentali sono:<\/p>\n

      \n
    1. Registrazione dell’organizzazione:<\/strong> Fornire dati legali, indirizzo di stabilimento principale (cr\u00edtico per il routing verso il CSIRT coordinatore)<\/li>\n
    2. Designazione del Rappresentante Assegnato (AR):<\/strong> La figura che ha autorit\u00e0 per sottomettere notifiche legalmente vincolanti<\/li>\n
    3. Preparazione dei dati obbligatori prima dell’incidente:<\/strong> L’organizzazione dovrebbe avere pronti sette input prima della registrazione. ENISA marca la sua guidance come soggetta a cambiamenti, quindi tratta gli schermi come documentati piuttosto che definitivi, ma perdere uno qualsiasi di questi rallenter\u00e0 il primo invio.<\/cite><\/li>\n
    4. Test della piattaforma:<\/strong> Anche se non obbligatorio, consiglio di completare almeno un invio di prova per familiarizzarsi con i campi richiesti<\/li>\n<\/ol>\n

      Un avvertimento importante: nella release attuale, il counter di 72 ore nella piattaforma mostra una scadenza 48 ore dopo che inviate l’avviso preventivo di 24 ore, non 72 ore da quando siete diventati consapevoli. Se inviate il vostro avviso preventivo all’ora 20, la piattaforma mostrer\u00e0 la vostra notificazione di 72 ore come scaduta all’ora 68 e potrebbe marcarla come scaduta prima che il deadline legale sia passato. Non usate il counter della piattaforma come vostro clock di compliance – tracciate quello reale internamente.<\/cite><\/p>\n

      Mapping delle Vulnerabilit\u00e0 Attivamente Sfruttate vs. Gravi Incidenti<\/h2>\n

      La confusione pi\u00f9 frequente che vedo nelle PMI \u00e8 la distinzione tra cosa segnalare. Non tutto \u00e8 obbligatorio.<\/p>\n

      Vulnerabilit\u00e0 attivamente sfruttata:<\/strong> Una vulnerabilit\u00e0 \u00e8 attivamente sfruttata dove esiste evidence affidabile che un attore malevolo l’ha sfruttata in un sistema senza il permesso del proprietario del sistema.<\/cite><\/p>\n

      Grave incidente:<\/strong> Per scopi di notificazione CRA, un incidente \u00e8 grave quando impatta negativamente o \u00e8 capace di impattare negativamente la capacit\u00e0 del prodotto di proteggere dati sensibili o funzioni importanti, o quando ha portato o \u00e8 capace di portare all’introduzione o esecuzione di codice malevolo nel prodotto o nella rete e nel sistema informatico di un utente.<\/cite><\/p>\n

      Nella mia esperienza, i casi di falso-positivo avvengono quando uno sviluppatore scopre una CVE in una dipendenza open-source ma non pu\u00f2 dimostrare che il prodotto finale \u00e8 vulnerabile o esposto. In quei casi, fate la “due diligence” ma non siete obbligati a notificare entro 24 ore. Il threshold \u00e8 alto intenzionalmente.<\/p>\n

      Integrazione con NIS2 e GDPR: Obblighi Sovrapposti<\/h2>\n

      Un punto critico spesso dimenticato: il CRA non sostituisce GDPR e NIS2. Una vulnerabilit\u00e0 o incidente segnalabile secondo CRA pu\u00f2 anche attivare obblighi di notificazione secondo altri regimi EU su cybersecurity, resilienza operativa, privacy e regimi settoriali specifici. Una notifica effettuata secondo CRA non necessariamente soddisfer\u00e0 obblighi secondo altre leggi applicabili EU come NIS2, GDPR, ePrivacy Directive, Digital Operational Resilience Act (DORA), o legge nazionale e impegni contrattuali. I trigger legali, destinatari, deadline e requisiti di contenuto sotto questi regimi non sono identici.<\/cite><\/p>\n

      Ho costruito una matrice di decisione per le PMI:<\/p>\n

        \n
      • Incidente che impatta dati personali:<\/strong> Notifica GDPR al DPA entro 72 ore + possibile notifica CRA entro 24\/72 ore al CSIRT<\/li>\n
      • Incidente che impatta un servizio critico essenziale (se siete operatori NIS2):<\/strong> Notifica NIS2 entro 24\/72 ore + possibile notifica CRA<\/li>\n
      • Vulnerabilit\u00e0 solo in prodotto con elementi digitali, nessun dato personale:<\/strong> Solo CRA, solo se attivamente sfruttata<\/li>\n<\/ul>\n

        Allineare questi processi richiede moduli di triage separati con decision trees distinti, non un unico flusso generalizzato.<\/p>\n

        Procedura Operativa: Come Strutturare il Team e i Processi<\/h2>\n

        Step 1: Designare il Primo Responder e il Coordinatore CRA<\/h3>\n

        Il primo errore che vedo \u00e8 pensare che il CISO sia l’unica persona autorizzata. No: serve un team di escalation chiaro. Nella mia procedura di implementazione tipica, designo:<\/p>\n

          \n
        • Primo responder (tecnico):<\/strong> L’engineer o il security analyst che riceve l’alert da SIEM\/EDR<\/li>\n
        • Triage lead:<\/strong> Chi valuta in 2-4 ore se siamo nel threshold di “consapevolezza” di CRA<\/li>\n
        • Assigned Representative:<\/strong> Chi firma legalmente la notifica sulla piattaforma ENISA<\/li>\n
        • Escalation manager:<\/strong> Chi comunica ai leadership e coordina le notifiche parallele (GDPR, NIS2)<\/li>\n<\/ul>\n

          Step 2: Pre-Configurare Template e Playbook di Notifica<\/h3>\n

          Ho creato un template Markdown che il team riempe durante l’incidente:<\/p>\n

          # CRA Incident Notification Template\n\n## Early Warning (24 ore)\n- Data\/ora consapevolezza: [TIMESTAMP]\n- Tipo prodotto: [software\/hardware\/firmware]\n- Componente affetto: [versioni specifiche]\n- Vettore di attacco iniziale: [brief description]\n- Gravit\u00e0 preliminare: [exploited vulnerability \/ severe incident]\n- CSIRT coordinatore (based on HQ): [CSIRT Member State]\n\n## Detailed Notification (72 ore)\n- Valutazione iniziale dell'impatto\n- Numero di utenti potenzialmente affetti\n- Timeline dell'exploit (primi segni osservati)\n- Misure mitiganti temporanee gi\u00e0 implementate\n- Data stimata per patch\/fix\n- Comunicazione utenti (data\/canale)\n\n## Final Report (14 giorni per vulnerabilit\u00e0 \/ 30 giorni per incidenti)\n- Descrizione della misura correttiva\/mitigante\n- Data di disponibilit\u00e0 della fix\n- Impatto confermato post-mitigazione\n- Lessons learned\n<\/code><\/pre>\n
          Ho scoperto nella pratica che i template compilati in anticipo riducono il tempo di composizione della notifica da ore a minuti. Inoltre, permettono al team legale di revisionare in parallelo durante la triage.<\/p>\n
          Step 3: Automazione dell’Incident Detection e Notification Trigger<\/h3>\n
          L’incident response automation nel 2026 \u00e8 l’uso di codice, playbook e agenti AI per rilevare, triare, contenere e documentare incidenti di sicurezza a velocit\u00e0 macchina attraverso il ciclo di incident response NIST SP 800-61. Nel 2026 ha superato i rigidi runbook SOAR in agentic AI che ragiona attraverso SIEM, EDR e dati di identit\u00e0.<\/cite><\/p>\n
          Per le PMI, raccomando di iniziare con una configurazione SOAR base (anche open-source come TheHive + Shuffle), poi evolvere verso agentic AI se il volume di incidenti lo giustifica. La procedura che uso:<\/p>\n
            \n
          1. EDR\/SIEM detection rules:<\/strong> Configurare alert per CVE attively exploited (da threat intel feed come CISA KEV)<\/li>\n
          2. Playbook di triage automatica:<\/strong> Query SBOM del vostro prodotto, verifica se il componente vulnerabile \u00e8 incluso nella versione deployed<\/li>\n
          3. Notification trigger:<\/strong> Se la vulnerabilit\u00e0 \u00e8 presente, invia automaticamente un Slack\/Teams alert con template pre-compilato al team di escalation<\/li>\n
          4. Clock management:<\/strong> Registra il timestamp esatto di “consapevolezza” in un database (non fidatevi solo dei log di sistema)<\/li>\n<\/ol>\n
            Ho visto SOAR ridurre il tempo dalla rilevazione alla notificazione da 4-6 ore a 1-2 ore. Per una PMI, questo differenziale pu\u00f2 essere la differenza tra conformit\u00e0 e violazione.<\/p>\n
            Step 4: Integrazione con CSIRT Nazionale e Routing<\/h3>\n
            Il routing CSIRT segue lo stabilimento principale. Le notifiche vanno al CSIRT designato come coordinatore nello Stato Membro dello stabilimento principale, con una fallback chain per produttori non-UE dettagliata nel routing CSIRT qui sotto. L’elenco coordinatore ENISA, che riporta la data 10 settembre 2026, \u00e8 disponibile, e scegliere il coordinatore sbagliato pu\u00f2 invalidare la notificazione.<\/cite><\/p>\n
            Per le PMI italiane: il coordinatore CSIRT \u00e8 il CSIRT Italia<\/strong> (sotto la Direzione di Agenzia delle Entrate e Dogane – s\u00ec, confusione burocratica italiana). Devo verificare il vostro indirizzo legale e stabilimento principale su CCIAA prima di registrare il routing sulla piattaforma ENISA.<\/p>\n
            Automazione Completa del Ciclo Incident Response per CRA Compliance<\/h2>\n
            Dopo mesi di implementazione in campo, ecco l’architettura che ho consolidato per PMI con risorse limitate:<\/p>\n
            Componenti Stack Suggerito<\/h3>\n