IEC 62304: scope, deliverable e retest per un penetration test efficace

Impostare correttamente scope, deliverable e retest è la condizione che rende un penetration test davvero utile in un percorso IEC 62304 (Medical Device Software – Software Life Cycle Processes): senza questo allineamento, il test produce un PDF poco spendibile fuori dal team tecnico.

Se scope, evidenze, remediation e retest non sono collegati al ciclo di vita del software medicale, il team regolatorio non dispone degli elementi necessari per rispondere a un audit di notified body né per supportare la dichiarazione di conformità.

In breve: cosa serve per IEC 62304

Per rendere il penetration test davvero utile a IEC 62304, occorre definire uno scope realistico, collegare i finding al rischio del software medicale, produrre deliverable riutilizzabili e chiudere il ciclo con remediation e retest verificato. Senza questo collegamento, il test non aiuta il team regolatorio a rispondere a un audit di notified body né a supportare la dichiarazione di conformità.

Problemi pratici che questa guida aiuta a risolvere

La guida è utile quando si deve:

• Definire uno scope realistico rispetto alla release o al modulo da verificare;
• Capire quali deliverable servono davvero a management, auditor e buyer;
• Evitare report tecnici poco riusabili;
• Collegare remediation e retest a evidenze davvero spendibili.

Checklist di preparazione al test

• Inventario aggiornato dei componenti software medicale, moduli e release in scope;
• Release, build o versione oggetto del test;
• Owner tecnici e referenti di business;
• Ambienti inclusi ed esclusi;
• Mappa ruoli, profili e privilegi;
• Endpoint, integrazioni e componenti terzi rilevanti;
• Meccanismi di update, patching e change control coinvolti;
• Finestre temporali e vincoli operativi;
• Criteri di severità condivisi;
• Percorso di remediation e retest già previsto.

Deliverable attesi

Output	Perché serve	Chi lo usa
Executive summary	Sintetizza rischio, release e priorità	Direzione, compliance, buyer
Dettaglio tecnico	Consente riproduzione e correzione	Team IT, Dev, Sec
Evidenza di sfruttabilità	Mostra che il rischio è concreto	Auditor, buyer, security lead
Piano di remediation	Ordina tempi, owner e dipendenze	Owner tecnici e management
Retest	Conferma la chiusura delle criticità	Auditor, clienti, governance

Report utile e report debole a confronto

Report utile	Report debole
Collega finding e rischio del software	Elenca vulnerabilità senza contesto
Distingue release, modulo e perimetro testato	Scope ambiguo o incompleto
Dà priorità di remediation	Lascia solo output tecnici grezzi
Include retest o percorso di chiusura	Non verifica le correzioni
È leggibile anche da management e auditor	È usabile solo da chi ha eseguito il test

Errori comuni da evitare

• Scope incompleto: costruito su un solo front-end quando il prodotto reale include API, backend, app o servizi di supporto;
• Esclusioni critiche: ruoli privilegiati, integrazioni rilevanti o componenti terzi non inclusi nel perimetro;
• Disallineamento dalla release: test non coordinato con il change control in corso;
• Assenza di executive summary: il report non è leggibile da management e auditor;
• Finding scollegati dal rischio: vulnerabilità non contestualizzate rispetto al software medicale o al processo di remediation;
• Remediation non tracciata: le correzioni non sono documentate né verificabili;
• Nessun retest finale: il ciclo rimane aperto senza conferma tecnica delle chiusure.

Come ISGroup struttura il percorso

ISGroup può strutturare un percorso più efficace combinando Secure Architecture Review, Code Review, Web Application Penetration Testing e, quando esistono app companion, Mobile Application Security Testing. In questo modo il test diventa una prova tecnica leggibile e un supporto concreto al miglioramento del software lifecycle.

Domande frequenti su IEC 62304 e penetration test

• Cosa deve contenere un report utile anche per il management?
• Per un software dispositivo medico in percorso IEC 62304, il management deve vedere quale release, quali Safety Class e componenti software sono stati testati, quali finding modificano il profilo di sicurezza della release rispetto alla documentazione di progettazione, e se le correzioni sono state chiuse prima del rilascio. Il report deve essere riusabile nel dossier tecnico del dispositivo.
• Quanto conta il retest in un percorso IEC 62304?
• In IEC 62304 le modifiche al software del dispositivo seguono un processo controllato: ogni correzione è una change che deve essere verificata. Il retest è la prova tecnica che la change ha risolto il problema senza introdurre nuovi rischi, e il suo output alimenta la documentazione di verifica e validazione richiesta per il ciclo di vita del software.
• Un vulnerability assessment può sostituire questo tipo di test?
• Per un software in Safety Class B o C, la domanda rilevante non è solo se esiste una vulnerabilità, ma se quella vulnerabilità può causare un danno al paziente o compromettere la funzione terapeutica del dispositivo. Un VA non risponde a questa domanda: serve un test che colleghi la vulnerabilità al contesto di uso clinico e valuti l’impatto sulla sicurezza del dispositivo.

Per evitare un penetration test generico e ottenere evidenze davvero utili per IEC 62304, il primo passo è definire scope, deliverable e percorso di retest in funzione della release e delle interfacce critiche. È possibile combinare Secure Architecture Review, Code Review e Web Application Penetration Testing per dare al lavoro più profondità tecnica e continuità operativa.

Approfondimenti correlati

• La guida principale su IEC 62304 e penetration test offre il quadro completo del tema e il contesto normativo di riferimento;
• L’articolo su quando il penetration test conta davvero per IEC 62304 aiuta a valutare se e quando il test è effettivamente necessario;
• La sezione su evidenze utili per audit e vendor assessment IEC 62304 approfondisce cosa produrre per supportare notified body e buyer.