Due normative cardine per il settore sanitario con requisiti orizzontali sulla cybersecurity: il Cyber Resilience Act (CRA) e la Direttiva NIS2. Principio interpretativo sulla distribuzione dell’accountability è che il CRA impone al fabbricante di consegnare un prodotto sicuro mentre la NIS2 impone alla struttura sanitaria di operare in modo sicuro. Sono due catene di responsabilità distinte che si incontrano nel momento in cui la struttura acquista e utilizza il prodotto del fabbricante.
Indice degli argomenti
Cyber Resilience Act e Direttiva NIS 2
Il settore sanitario italiano si trova oggi al centro di una trasformazione normativa senza precedenti in materia di cybersicurezza. Due regolamenti europei di portata orizzontale — il Cyber Resilience Act (Reg. UE 2024/2847, di seguito CRA) e la Direttiva NIS2 (Dir. UE 2022/2555), recepita in Italia con il D.Lgs. 138/2024 — entrano in vigore a distanza ravvicinata e disciplinano aspetti complementari ma strutturalmente distinti della sicurezza informatica in sanità. Comprenderli separatamente, prima ancora che nelle loro sinergie, è il presupposto per una corretta attribuzione delle responsabilità e per una pianificazione efficace della compliance.
Il punto di partenza è una distinzione concettuale fondamentale: le due normative operano su soggetti diversi, con logiche di accountability radicalmente differenti.
- Il CRA è una norma centrata sul prodotto e sulla responsabilità – principalmente/direttamente – del fabbricante;
- la NIS2 è una norma centrata sull’organizzazione e sulla responsabilità della struttura che eroga servizi essenziali.
Questa differenza non è solo classificatoria: determina chi risponde, davanti a quale autorità, per quale condotta e con quale sanzione.
L’accountability del fabbricante sotto il Cyber Resilience Act
Il Cyber Resilience Act costruisce un regime di accountability del fabbricante che copre l’intero ciclo di vita del prodotto digitale, dal momento della progettazione fino alla dismissione. La responsabilità non nasce al momento della vendita, ma al momento in cui il prodotto viene concepito: il principio secure by design and by default impone che le scelte architetturali e di sviluppo incorporino la sicurezza come requisito primario, non come funzionalità aggiuntiva.
Per il fabbricante di tecnologie sanitarie — vendor di sistemi HIS/EMR, fornitore di infrastrutture di rete, produttore di dispositivi IoT non rientranti nel MDR — il CRA introduce una responsabilità oggettiva di prodotto ancorata alla conformità tecnica. La marcatura CE, che a partire dall’11 dicembre 2027 dovrà attestare anche la conformità ai requisiti di cybersicurezza, diventa il documento che cristallizza questa responsabilità: apponendola, il fabbricante dichiara che il prodotto è stato progettato, sviluppato, testato e documentato secondo i requisiti essenziali dell’Allegato I del CRA, e che dispone di un processo attivo di gestione delle vulnerabilità.
La catena di accountability del fabbricante si articola su tre livelli temporali distinti e cumulativi. Prima dell’immissione sul mercato il fabbricante deve aver condotto la valutazione del rischio informatico, predisposto la documentazione tecnica (inclusa la Software Bill of Materials, SBOM) e completato la procedura di valutazione della conformità. Durante la vita commerciale del prodotto deve mantenere attivo il processo di gestione delle vulnerabilità, rilasciare aggiornamenti per almeno 10 anni e notificare all’ENISA le vulnerabilità attivamente sfruttate entro 24 ore. Al termine della vita utile deve comunicare in modo chiaro la data di fine supporto, consentendo alle strutture acquirenti di pianificare le misure compensative.
| Fase del ciclo di vita | Obbligo CRA del fabbricante | Conseguenza in caso di inadempimento |
| Progettazione e sviluppo | Secure by design, threat modeling, SDLC sicuro, SBOM. | Prodotto non conformabile; impossibilità di ottenere marcatura CE. |
| Pre-commercializzazione | Valutazione del rischio, documentazione tecnica, valutazione della conformità, Dichiarazione UE. | Divieto di immissione sul mercato UE; sanzioni fino a 15 M€ o 2,5% fatturato. |
| Post-commercializzazione | Gestione vulnerabilità, aggiornamenti ≥10 anni, notifica ENISA entro 24h, CVD pubblico. | Ritiro dal mercato; sanzioni fino a 10 M€ o 2% fatturato. |
| Fine vita (End Of Life) | Comunicazione anticipata della data EOL, misure transitorie per gli utenti. | Responsabilità per danni derivanti da vulnerabilità non comunicate. |
L’accountability della struttura ospedaliera sotto la NIS2
La struttura sanitaria — ospedale pubblico, clinica privata accreditata, laboratorio di analisi, IRCCS — non produce i dispositivi digitali, ma è il soggetto centrale della NIS2. Il D.Lgs. 138/2024 individua nel settore sanitario uno dei settori ad alta criticità (Allegato I) e qualifica le strutture come soggetti essenziali o soggetti importanti in funzione delle dimensioni e della natura del servizio. Il Ministero della Salute è designato Autorità di settore NIS per il comparto sanitario (art. 11 D.Lgs. 138/2024).
L’accountability della struttura sotto la NIS2 è di tipo organizzativo-gestionale: non si misura sulla qualità tecnica dei prodotti acquistati, ma sulla capacità dell’organizzazione di governare il proprio rischio informatico, reagire agli incidenti e garantire la continuità dei servizi essenziali. Questa responsabilità è esplicitamente estesa agli organi di vertice: il D.Lgs. 138/2024 responsabilizza formalmente gli organi di amministrazione e direzione, che devono approvare le misure di gestione del rischio, supervisionarne l’attuazione e rispondere — anche a titolo personale — delle violazioni.
La NIS2 introduce un cambiamento culturale profondo: la cybersicurezza non è più una questione tecnica delegata al reparto IT, ma una funzione di governance aziendale con responsabilità che risalgono fino al Direttore Generale e al Consiglio di Amministrazione. In un contesto dove un attacco ransomware può causare la cancellazione di migliaia di interventi e compromettere la sicurezza dei pazienti — come dimostrato dall’attacco WannaCry del 2017 che coinvolse oltre 80 strutture del National Health Service britannico — l’adeguamento alla NIS2 è anzitutto un atto di responsabilità istituzionale.
| Ambito NIS2 | Obbligo della struttura sanitaria | Responsabile interno |
| Governance del rischio | Adottare misure tecniche e organizzative proporzionate; valutazione aggiornata almeno annualmente. | Organo di amministrazione / DG |
| Notifica degli incidenti | Pre-notifica ACN entro 24h; notifica completa entro 72h; relazione finale entro 1 mese. | CISO / Responsabile IT + DG |
| Supply chain security | Valutare la sicurezza informatica dei fornitori ICT (art. 24 D.Lgs. 138/2024). | Ufficio acquisti + CISO |
| Formazione del personale | Formare dirigenti, clinici e personale amministrativo sul rischio cyber. | DG + HR + CISO |
| Business continuity | Piani di continuità operativa e disaster recovery per i sistemi informativi critici. | DG + IT |
| Registrazione ACN | Iscriversi e mantenere aggiornato il profilo sulla piattaforma ACN; designare punto di contatto. | Punto di contatto designato |
Il punto di incontro: dove le due accountability si intersecano
Le due catene di responsabilità si incontrano in un momento preciso e giuridicamente rilevante: il contratto di fornitura tra il vendor di tecnologie e la struttura sanitaria. La struttura che acquista un prodotto con marcatura CE CRA-conforme può confidare che il fabbricante abbia adempiuto ai propri obblighi di sicurezza; ma rimane interamente responsabile, ai sensi della NIS2, di come quel prodotto viene integrato nell’infrastruttura, configurato, aggiornato e monitorato nel tempo.
La supply chain security prevista dall’art. 24, comma 2, lett. d) del D.Lgs. 138/2024 impone alla struttura di valutare attivamente la sicurezza dei propri fornitori ICT: la marcatura CE del Cyber Resilience Act diventa uno dei criteri oggettivi da includere nei capitolati di gara e nelle procedure di vendor qualification, ma non esaurisce la due diligence richiesta. La conformità del fornitore non esime la struttura sanitaria dalla propria accountability NIS2.
Esempio concreto: un sistema PACS acquistato da un ospedale. Il fabbricante risponde (CRA) della sicurezza del software, della gestione delle vulnerabilità e della comunicazione degli aggiornamenti. L’ospedale risponde (NIS2) dell’integrazione sicura in rete, della configurazione degli accessi, della tempestiva installazione degli aggiornamenti e della notifica all’ACN in caso di incidente che comprometta la continuità del servizio radiologico.
La matrice operativa di accountability per il management sanitario
Per i vertici delle strutture sanitarie la lettura integrata delle due normative può essere sintetizzata in una matrice operativa. Il Cyber Resilience Act è lo strumento con cui l’Unione europea responsabilizza il mercato a monte, garantendo che i prodotti acquistati siano sicuri per costruzione. La NIS2 è lo strumento con cui responsabilizza le organizzazioni a valle, garantendo che i servizi essenziali siano gestiti con adeguata maturità cyber. La struttura sanitaria ben governata opera su entrambi i fronti: seleziona fornitori CRA-conformi e gestisce l’organizzazione in conformità NIS2.
| Domanda di accountability | Fabbricante (CRA) | Struttura sanitaria (NIS2) |
| Il prodotto era sicuro al momento della vendita? | Sì — marcatura CE e documentazione tecnica. | Non applicabile direttamente. |
| Le vulnerabilità note sono state comunicate? | Sì — notifica ENISA entro 24h (art. 14 CRA). | La struttura deve verificare e installare gli aggiornamenti. |
| L’aggiornamento di sicurezza è disponibile? | Sì — obbligo di supporto ≥10 anni. | La struttura risponde del mancato aggiornamento installato. |
| Il prodotto è integrato in modo sicuro? | Non applicabile (responsabilità del fabbricante esaurita). | Sì — configurazione, segmentazione di rete, controllo accessi. |
| L’incidente è stato notificato all’autorità? | Sì, per vulnerabilità attivamente sfruttata: notifica ENISA. | Sì, per incidente significativo: notifica ACN entro 24h. |
| Chi governa il rischio organizzativo? | Non applicabile. | Sì — organi di vertice, CISO, piano di risk management. |
Cos’è il Cyber Resilience Act e perché impatta il settore sanitario
Il Regolamento (UE) 2024/2847 del Parlamento europeo e del Consiglio, meglio noto come Cyber Resilience Act (CRA), è il primo atto legislativo dell’Unione europea che introduce requisiti orizzontali e vincolanti di cybersicurezza per tutti i prodotti hardware e software dotati di elementi digitali commercializzati nel mercato unico. Pubblicato nella Gazzetta Ufficiale dell’Unione europea il 20 novembre 2024, il regolamento è entrato in vigore il 10 dicembre 2024 e sarà pienamente applicabile a partire dall’11 dicembre 2027.
L’impulso normativo nasce da dati ricercati: i prodotti digitali presentano vulnerabilità diffuse e ricevono aggiornamenti di sicurezza insufficienti o incoerenti, esponendo utenti e organizzazioni a rischi sistemici. Il CRA si propone di invertire questa tendenza imponendo il principio del secure by design and by default lungo l’intero ciclo di vita del prodotto.
Perché il settore sanitario è coinvolto
Il settore sanitario è esposto in modo peculiare alle minacce informatiche: i dati trattati sono intrinsecamente particolari (art. 9 GDPR); i sistemi integrano dispositivi legacy – nel senso di tecnologie con protocolli/standard non più supportati; quindi, obsoleti e il cui aggiornamento di sicurezza o di sistema risulta oneroso per l’organizzazione- con infrastrutture cloud e il blocco di un sistema ospedaliero può avere conseguenze dirette sulla vita dei pazienti.
Il Rapporto Clusit 2026 registra un calo degli incidenti nel 2025 pubblicando un primo segnale positivo, tuttavia, riporta altresì che la cybersecurity healthcare in Italia presenta ancora criticità strutturali significative perché le infrastrutture difensive del settore sanitario italiano non sono riuscite a prevenire né fermare gli attacchi avvenuti, nemmeno quelli non particolarmente sofisticati [1].
Il Cyber Resilience Act impatta il settore sanitario per due vie distinte:
(i) indirettamente, quale normativa orizzontale che fissa standard minimi di cybersicurezza per i prodotti con elementi digitali forniti alle strutture sanitarie da produttori e vendor ICT;
(ii) direttamente, in sinergia con la Direttiva NIS2 recepita in Italia con il D.Lgs. 138/2024, che qualifica ospedali, laboratori e fornitori di dispositivi medici critici come soggetti ad alta criticità sottoposti a obblighi di sicurezza e notifica. È tuttavia fondamentale precisare che i dispositivi medici ai sensi del Regolamento (UE) 2017/745 (MDR) sono esplicitamente esclusi dall’ambito di applicazione del CRA, in quanto già coperti da normativa settoriale equivalente. Ciò non esime però produttori e strutture sanitarie dall’adeguarsi ai requisiti del quadro normativo complessivo.
Requisiti essenziali di sicurezza per i dispositivi medici connessi
Per i dispositivi medici connessi, il quadro normativo applicabile è il Regolamento (UE) 2017/745 (MDR), che all’Allegato I, Requisito Generale di Sicurezza e Prestazione (RGSP) n. 17.2, impone ai fabbricanti di integrare la cybersicurezza nel processo di gestione del rischio. Una della norme tecniche di riferimento – mutuata dal settore industriale- è la EN 62443 (IEC 62443) in ambito ICS/SCADA e le linee guida MDCG 2019-16 rev.1 sulla cybersecurity dei dispositivi medici, emesse dal Medical Device Coordination Group della Commissione europea.
Requisiti MDR per la cybersicurezza
- Sicurezza della configurazione e autenticazione: il dispositivo deve consentire l’identificazione e l’autenticazione degli utenti e impedire accessi non autorizzati, incluso il controllo dei privilegi di accesso.
- Integrità dei dati e protezione della trasmissione: i dati clinici trasmessi tra dispositivo e sistemi informativi ospedalieri (HIS, LIS, PACS) devono essere protetti con protocolli crittografici adeguati (es. TLS 1.2+).
- Gestione degli aggiornamenti: il fabbricante deve garantire la distribuzione di aggiornamenti di sicurezza per tutta la vita utile prevista del dispositivo.
- Rilevamento e risposta agli incidenti: il dispositivo deve fornire funzionalità di logging e audit trail per consentire l’analisi forense in caso di incidente.
- Minimizzazione della superficie di attacco: i servizi e le porte di rete non necessari devono essere disabilitati per impostazione predefinita.
Software as Medical Device (SaMD)
Una categoria critica è rappresentata dal Software as Medical Device (SaMD): software autonomo (app cliniche, sistemi di supporto alle decisioni cliniche, algoritmi di diagnostica per immagini basati su IA) che soddisfa la definizione di dispositivo medico. Per il SaMD si applica integralmente il MDR, con classificazione del rischio secondo le regole dell’Allegato VIII e valutazione della conformità obbligatoria presso un Organismo Notificato per le classi IIa, IIb e III. La Commissione europea ha pubblicato apposite linee guida MDCG 2019-11 rev.1 per la qualificazione e classificazione del SaMD.
Classificazione dei prodotti con elementi digitali in ambito clinico
Il Cyber Resilience Act adotta una struttura di classificazione dei Prodotti con Elementi Digitali (PED) in tre categorie principali, con un trattamento differenziato degli obblighi di valutazione della conformità in base alla criticità del prodotto. L’Allegato III del regolamento, aggiornato dall’Atto di esecuzione (UE) 2025/2392 pubblicato il 1° dicembre 2025, elenca analiticamente le categorie di prodotti importanti e critici.
Prodotti non critici (circa il 90% del mercato)
Comprendono la vasta maggioranza dei prodotti digitali per uso generico (es. dischi rigidi, assistenti vocali). Per questi prodotti il fabbricante effettua un’autovalutazione della conformità. In ambito ospedaliero rientrano in questa categoria strumenti software accessori non direttamente connessi alla diagnostica o alla terapia.
Prodotti importanti — Classe I
Includono: sistemi di gestione dell’identità e degli accessi, browser, gestori di password, software anti-malware, VPN e sistemi di gestione delle reti. In contesto sanitario sono rilevanti i sistemi di Identity and Access Management (IAM) per il controllo degli accessi ai sistemi clinici e le soluzioni VPN per la connettività sicura tra strutture.
Prodotti importanti — Classe II
Includono: hypervisor, sistemi di runtime per container, firewall, sistemi di rilevamento e prevenzione delle intrusioni (IDS/IPS) e microprocessori resistenti alle manomissioni. Questi prodotti, ampiamente diffusi nelle infrastrutture IT ospedaliere, richiedono il coinvolgimento obbligatorio di un Organismo Notificato per la valutazione della conformità.
Il rapporto con il MDR: regola di esclusione e complementarità
Principio chiave: i dispositivi medici ai sensi del Reg. (UE) 2017/745 sono esclusi dal campo di applicazione del CRA (art. 2, par. 2 CRA). Tuttavia, i sistemi informativi ospedalieri (HIS, EMR, PACS, RIS) che non soddisfano la definizione di dispositivo medico rientrano nel perimetro CRA se connessi a reti. La distinzione è cruciale per determinare il regime di conformità applicabile.
Il produttore di un dispositivo medico connesso deve rispettare il MDR per gli aspetti di cybersicurezza del dispositivo stesso, mentre l’infrastruttura di rete e i sistemi di supporto possono ricadere sotto il CRA o la NIS2 a seconda delle caratteristiche. Questa dualità normativa richiede un’analisi puntuale caso per caso.
Cyber Resilience Act: obblighi di cybersecurity per produttori e fornitori di software medici
Il CRA introduce una catena di responsabilità lungo l’intera supply chain digitale, articolando obblighi differenziati per fabbricanti, rappresentanti autorizzati, importatori e distributori.
I fabbricanti gestiscono l’impatto normativo più significativo.
Obblighi dei fabbricanti
- Progettazione e sviluppo sicuri: implementare un Secure Development Lifecycle (SDLC) con threat modeling, code review e penetration testing.
- Valutazione del rischio informatico: condurre e documentare una valutazione continuativa dei rischi di cybersicurezza, aggiornata a ogni modifica significativa del prodotto.
- Gestione delle vulnerabilità della supply chain: il fabbricante è responsabile della sicurezza anche dei componenti di terze parti integrati nel prodotto (es. librerie open source, componenti firmware).
- Aggiornamenti di sicurezza: garantire la disponibilità di aggiornamenti per almeno 10 anni o per l’intera durata di vita prevista del prodotto, se superiore.
- Notifica delle vulnerabilità: segnalare all’ENISA e all’autorità nazionale competente le vulnerabilità attivamente sfruttate entro 24 ore dall’identificazione (art. 14 CRA; applicabile dall’11 settembre 2026).
- Punto di contatto pubblico: mantenere un canale ufficiale per la ricezione delle segnalazioni di vulnerabilità da parte di ricercatori e utenti.
- Documentazione tecnica: predisporre e mantenere aggiornata la documentazione tecnica di sicurezza a supporto della marcatura CE.
Obblighi specifici per i fornitori di software medici (HIS, EMR, PACS)
I sistemi informativi clinici che non rientrano nel perimetro MDR ma che elaborano dati sanitari e sono connessi in rete sono soggetti al CRA. I fornitori di tali sistemi devono:
- Implementare l’autenticazione a più fattori (MFA) per tutti gli accessi amministrativi e remoti.
- Garantire la cifratura dei dati a riposo e in transito, con particolare attenzione alle cartelle cliniche elettroniche e ai referti diagnostici.
- Fornire contrattualmente garanzie sul supporto alla sicurezza per tutta la durata del contratto, includendo la gestione delle vulnerabilità.
- Comunicare proattivamente alle strutture sanitarie clienti l’insorgenza di vulnerabilità significative e i relativi aggiornamenti correttivi.
Gestione delle vulnerabilità e ciclo di vita del software sanitario
La gestione del ciclo di vita delle vulnerabilità è uno dei pilastri del CRA e, nell’ambito sanitario, si intreccia con i requisiti post-market del MDR e con le norme del D.Lgs. 138/2024 di recepimento della NIS2. Il framework complessivo può essere sintetizzato in quattro fasi operative.
Identificazione e divulgazione coordinata
Il Cyber Resilience Act richiede che i fabbricanti istituiscano un processo formale di Coordinated Vulnerability Disclosure (CVD), pubblicando le modalità per segnalare vulnerabilità tramite un indirizzo di contatto pubblico. Il framework europeo di riferimento è la norma EN ISO/IEC 29147 (Vulnerability disclosure) integrata dalla EN ISO/IEC 30111 (Vulnerability handling processes). In caso di vulnerabilità attivamente sfruttata, la notifica a ENISA e all’autorità competente nazionale deve avvenire entro 24 ore.
Valutazione del rischio clinico
In ambito sanitario, la valutazione di una vulnerabilità software non può prescindere dall’analisi dell’impatto clinico potenziale. Un aggiornamento correttivo che richiede il riavvio di un sistema di monitoraggio in terapia intensiva comporta un rischio clinico che deve essere bilanciato rispetto al rischio informatico della vulnerabilità. Il fabbricante di un dispositivo medico deve documentare questa valutazione nell’ambito del proprio Sistema di Gestione del Rischio (ISO 14971) e comunicarla all’Organismo Notificato competente in caso di modifiche significative.
Deployment degli aggiornamenti
Le strutture sanitarie devono definire procedure operative per il testing e il rilascio sicuro degli aggiornamenti di sicurezza in ambienti clinici, minimizzando l’impatto sulla continuità operativa. Il CRA non esenta i prodotti dal ricevere aggiornamenti per via della complessità dell’ambiente di deployment: il fabbricante resta responsabile della disponibilità dell’aggiornamento, ma la struttura sanitaria è responsabile dell’installazione tempestiva.
End-of-life e sistemi legacy
Il CRA impone al fabbricante di comunicare chiaramente la data di fine supporto (end-of-life) del prodotto. Per i sistemi legacy ospedalieri che non possono ricevere aggiornamenti, la struttura sanitaria deve adottare misure compensative documentate (network segmentation, applicazione di whitelist, monitoraggio rafforzato) e valutare l’impatto in termini di conformità NIS2.
Come cambia la marcatura CE dopo l’entrata in vigore del Cyber Resilience Act
Prima dell’entrata in vigore del Cyber Resilience Act, la marcatura CE per i prodotti software non implicava alcuna garanzia specifica di cybersicurezza: attestava la conformità ai requisiti essenziali pertinenti della direttiva applicabile (es. compatibilità elettromagnetica, sicurezza elettrica), ma non affrontava le vulnerabilità informatiche. Con il CRA, il quadro cambia radicalmente.
Nuovo significato della marcatura CE
A partire dall’11 dicembre 2027, nessun prodotto con elementi digitali potrà essere immesso sul mercato UE senza marcatura CE che attesti anche la conformità ai requisiti di cybersicurezza del CRA. Il prodotto dovrà essere ‘sicuro per impostazione predefinita’ (secure by default), privo di vulnerabilità note sfruttabili al momento dell’immissione e dotato di meccanismi di aggiornamento.
Procedura di valutazione della conformità
Il percorso verso la marcatura CE varia in funzione della classificazione del prodotto:
- Prodotti non critici: autovalutazione da parte del fabbricante con redazione della documentazione tecnica e della Dichiarazione di Conformità UE.
- Prodotti di Classe I (importanti): il fabbricante può effettuare autovalutazione oppure ricorrere a un Organismo Notificato per una valutazione di terza parte del processo di sviluppo.
- Prodotti di Classe II (importanti): valutazione obbligatoria da parte di un Organismo Notificato, che può certificare il prodotto o il processo di sviluppo adottando schemi europei di certificazione della cybersicurezza basati sui Common Criteria.
- Prodotti altamente critici (individuati caso per caso dalla Commissione): certificazione europea obbligatoria secondo gli schemi del Cybersecurity Act (Reg. UE 2019/881).
Impatto sui dispositivi medici
I dispositivi medici regolamentati dal MDR continuano a seguire il percorso di marcatura CE previsto da tale regolamento, che include già la valutazione della cybersicurezza nell’ambito del processo di valutazione della conformità. La marcatura CE apposta su un dispositivo medico non è fungibile con quella richiesta dal CRA, trattandosi di regimi normativi separati.
Documentazione tecnica e valutazione della conformità per le aziende
La documentazione tecnica è l’elemento cardine del sistema di conformità del CRA. Il fabbricante deve predisporla prima dell’immissione sul mercato e mantenerla aggiornata per almeno 10 anni dopo l’ultima immissione. I contenuti minimi richiesti dall’Allegato VII del CRA comprendono:
- Descrizione generale del prodotto: finalità d’uso, architettura di sistema, interfacce hardware e software, protocolli di comunicazione.
- Analisi del rischio di cybersicurezza: documentazione del threat model, delle vulnerabilità identificate e delle misure di mitigazione adottate, con riferimento a standard tecnici (es. ISO/IEC 27001, IEC 62443, ETSI EN 303 645).
- Politica di gestione delle vulnerabilità: procedure di CVD, modalità di rilascio degli aggiornamenti, canali di comunicazione agli utenti.
- Software Bill of Materials (SBOM): inventario completo dei componenti software del prodotto, incluse librerie di terze parti e dipendenze open source, con indicazione delle versioni e dello stato di aggiornamento rispetto alle vulnerabilità note (CVE).
- Test di sicurezza: risultati dei test di sicurezza condotti (penetration test, analisi statica e dinamica del codice, fuzzing), con relativi piani di remediation.
- Dichiarazione di Conformità UE: documento firmato dal fabbricante attestante la conformità ai requisiti essenziali del Cyber Resilience Act.
Software Bill of Materials (SBOM): uno strumento di trasparenza
Il requisito SBOM è tra le novità più impattanti per l’industria del software sanitario. Implica la capacità di tracciare ogni componente di terze parti integrato nel prodotto, identificare tempestivamente le vulnerabilità note tramite i database CVE/NVD e dimostrare all’autorità di sorveglianza la gestione attiva della supply chain del software. Per i vendor di sistemi HIS/EMR con architetture complesse e numerose dipendenze, l’implementazione di processi SBOM richiede investimenti significativi in tooling (es. CycloneDX, SPDX) e governance.
[1] Il Rapporto Clusit 2026 segnala 10 cyber attacchi di successo nel 2025 — prima diminuzione registrata da anni (erano 13 nel 2024): Quota sul totale incidenti italiani: 1,8%; 14° posto nella classifica italiana (era al 10° nel 2024): forte scivolata verso il basso. Forte divergenza rispetto al dato globale, dove Healthcare è al 3° posto: il rapporto la legge come un segnale parzialmente positivo.
Tecniche di attacco registrate: DDoS 40% (tecnica prevalente), Undisclosed 30%, Malware 20% in diminuzione; Phishing / Social Engineering 10% marginale, Vulnerabilità in fortissima diminuzione (era 31% nel 2024) Identity Theft 0% azzerato.
