IEC 62304 e Penetration Test nel Software Medicale

IEC 62304 (Medical Device Software – Software Life Cycle Processes) disciplina il ciclo di vita del software medicale: sviluppo, manutenzione, gestione delle anomalie, change control e classificazione della sicurezza. Quando il prodotto include web app cliniche, API, app companion, librerie terze, update remoti o servizi cloud, la conformità al processo non basta: serve dimostrare che il software regga davvero contro scenari di abuso realistici.

Senza evidenze tecniche allineate allo standard — scope corretto, finding collegati al risk management, remediation tracciabile e retest documentato — il dossier regolatorio resta esposto in fase di audit, vendor assessment o due diligence.

IEC 62304 e penetration test: cosa conta davvero

IEC 62304 conta sul piano tecnico perché disciplina processi che incidono direttamente sulla sicurezza e sull’affidabilità del software medicale. Quando il prodotto dipende da componenti connessi, integrazioni, update, backend o SOUP (software of unknown provenance), il penetration test aiuta a verificare se i controlli dichiarati reggano davvero. Il suo valore cresce quando l’output è leggibile anche in chiave release decision, risk review, audit e follow-up di remediation.

Per chi è rilevante

Questa guida è utile a:

• RA/QA Manager, CTO, Product Security Lead, Compliance Manager;
• team software medicale che devono collegare lifecycle process e rischio cyber;
• produttori di SaMD, software embedded, app companion e piattaforme healthtech;
• organizzazioni che affrontano audit, technical file review, vendor assessment o qualifica cliente.

Perché IEC 62304 conta anche sul piano tecnico

In un percorso IEC 62304, il rischio tecnico non si esaurisce nel bug fixing. Riguarda anche la tenuta di elementi che incidono sul ciclo di vita e sulla sicurezza del software: la classificazione del software e la severità delle conseguenze in caso di malfunzionamento o abuso; i componenti terze parti e SOUP che entrano nel prodotto; le interfacce verso portali clinici, API, app mobile, sistemi di supporto o backend; update, change control, manutenzione correttiva e gestione delle anomalie; ambienti cloud, accessi privilegiati e servizi digitali da cui dipende il funzionamento del software.

Per questo, anche quando la norma non prescrive letteralmente un penetration test, una verifica tecnica resta spesso necessaria per dimostrare che le misure implementate siano coerenti con il rischio reale.

Dove il penetration test crea valore

In questo contesto, il penetration test è utile soprattutto quando bisogna dimostrare che il software medicale non espone vulnerabilità sfruttabili su interfacce critiche; che ruoli clinici, amministrativi e tecnici non consentono escalation o accessi indebiti; che API, app companion, backend e workflow di aggiornamento reggono a scenari realistici; che le anomalie di sicurezza possano essere tradotte in priorità di remediation coerenti con la release; che retest e riesecuzione del test diano una prova concreta del miglioramento.

In pratica, il test aiuta a trasformare requisiti di lifecycle e safety in evidenze tecniche più concrete su esposizione, impatto e robustezza del prodotto.

Nei test su software medicale in percorso IEC 62304, i finding più ricorrenti riguardano componenti di classe B o C con interfacce web o API che non hanno ricevuto lo stesso livello di verifica delle funzionalità di core, update mechanism con autenticazione debole e dipendenze di terze parti non tracciate nel software lifecycle documentato.

Cosa chiedono auditor, notified body e buyer

Un notified body, un auditor FDA/MDR o un OEM che valuta il software lifecycle di un medical device rispetto a IEC 62304 chiede cose precise:

• La verifica tecnica copre le classi di sicurezza del software (A, B, C) e i componenti con maggiore impatto sulla safety;
• I finding sono collegati alle anomalie del software lifecycle e al risk management IEC 62304/14971;
• Le vulnerabilità trovate impattano integrità del dato clinico, disponibilità del servizio o sicurezza del paziente;
• Il piano di correzione è coerente con il software lifecycle e con i processi di change management documentati;
• Esiste un retest che chiude formalmente le anomalie prima della prossima release o della verifica regolatoria.

Mappatura tra aree di rischio, evidenze e attività

Area da validare	Evidenza utile	Attività ISGroup più adatta	Output atteso
Superfici web, portali clinici e backend	Vulnerabilità sfruttabili e impatto sul software	Web Application Penetration Testing	Executive summary, finding, remediation
App companion e componenti mobile	Abuso di logiche, auth gap, leakage locale	Mobile Application Security Testing	Dettaglio tecnico e priorità
Codice critico, librerie e componenti SOUP	Difetti applicativi e debolezze di implementazione	Code Review	Evidenze tecniche e indicazioni di fix
Architettura, update flow e change control	Mismatch tra controllo dichiarato e rischio reale	Secure Architecture Review	Lettura del rischio e percorso di remediation

Caso d’uso realistico

Uno scenario tipico è quello di un produttore o vendor healthtech che ha già procedure di sviluppo e documentazione di lifecycle, ma deve dimostrare che il software rilasciato non esponga vulnerabilità incompatibili con il profilo di rischio del prodotto. Quando arrivano audit, due diligence o review tecniche, le domande si spostano subito su API, ruoli, componenti terzi, autenticazione, aggiornamenti e ambienti di supporto. In quel momento il penetration test diventa utile perché collega il ciclo di vita del software alla prova tecnica del suo comportamento reale.

Un riferimento coerente è il case study del Web Application Penetration Test su Flora di Kelyon S.r.l., che mostra come una piattaforma software in ambito sanitario trasformi la sicurezza applicativa in un requisito di affidabilità verso utenti e stakeholder.

Errori comuni

• Pensare che lo standard renda opzionale la validazione tecnica;
• confondere qualità del processo di sviluppo e robustezza tecnica del software rilasciato;
• testare solo il front-end ignorando API, update flow, servizi di backend o componenti terzi;
• non collegare i finding al linguaggio di anomalia, rischio residuo e decisione di release;
• produrre un report tecnico senza executive summary, remediation plan e retest.

Domande frequenti su IEC 62304 e penetration test

• IEC 62304 prevede test di sicurezza nel software lifecycle?
• IEC 62304 richiede verifiche e validazioni del software, ma non specifica il penetration test come attività obbligatoria. Per software medicale connesso (classe B e C con componenti internet-facing, API o interfacce remote), MDR e FDA Guidance on Cybersecurity indicano la verifica della sicurezza come parte del software validation e del risk management, rendendo il penetration test di fatto atteso nei dossier regolatori.
• Come si collega IEC 62304 a IEC 62443 e alla cybersecurity dei medical device?
• IEC 62304 governa il software lifecycle del medical device; IEC 62443 governa la cybersecurity dei sistemi OT/industriali connessi. Per dispositivi medici connessi i due standard si sovrappongono: il software di IEC 62304 vive spesso in ambienti IEC 62443. MDR e FDA Guidance richiedono di considerare entrambi per i dispositivi con componenti di rete.
• Cosa si aspetta un notified body MDR sulla sicurezza del software?
• Che la classe di sicurezza software sia corretta e documentata, che le anomalie siano tracciate nel lifecycle, che i test di sicurezza siano parte del software validation plan e che le vulnerabilità trovate siano state valutate per il loro impatto sulla safety prima della messa in commercio.

Per collegare IEC 62304 a evidenze tecniche davvero spendibili, il primo passo utile è chiarire quali componenti del software lifecycle hanno più impatto sul rischio: interfacce esposte, app companion, librerie critiche, update o backend. È possibile combinare Secure Architecture Review, Code Review e Web Application Penetration Testing per ottenere un output più utile sia per il team tecnico sia per audit e governance.

Approfondimenti correlati

• Chi vuole capire quando il penetration test è davvero necessario in un percorso IEC 62304 può leggere quando il penetration test conta davvero per IEC 62304;
• per chi affronta audit, vendor assessment o deve costruire fiducia con il buyer, è disponibile l’approfondimento su IEC 62304 e le evidenze utili per audit e vendor assessment;
• per definire scope, deliverable e retest in modo operativo, è disponibile la guida pratica su scope, deliverable e retest per IEC 62304.