IEC 82304 e penetration test per product safety software sanitario

IEC 82304 (Health Software – Part 1: General Requirements for Product Safety) definisce i requisiti di sicurezza del prodotto per health software distribuito su piattaforme general-purpose: quando il prodotto dipende da autenticazione, aggiornamenti, configurazioni, cloud, API, app mobile o portali amministrativi, il tema centrale diventa dimostrare che il software resti sicuro, affidabile e gestibile lungo tutto il suo ciclo di vita operativo.

Senza evidenze tecniche credibili su esposizione, impatto e remediation, scope, retest e dossier regolatario rischiano di restare incompleti di fronte ad auditor, buyer sanitari e notified body.

In breve: IEC 82304 e product safety tecnica

IEC 82304 conta sul piano tecnico perché copre design, validazione, installazione, manutenzione e gestione in esercizio del software sanitario. Quando il prodotto vive su ambienti general-purpose — portali, backend, app companion, servizi cloud e integrazioni — il penetration test aiuta a verificare se i controlli dichiarati reggano davvero. Il suo valore cresce quando l’output è leggibile in chiave di sicurezza del prodotto, rischio residuo, continuità operativa e fiducia di terze parti.

A chi si rivolge questa guida

Questa guida è utile a:

• RA/QA Manager, CTO, Product Owner, Compliance Manager;
• Team che devono collegare product safety, rischio cyber e affidabilità del software;
• Vendor healthtech, produttori di SaMD e piattaforme software sanitarie su ambienti general-purpose;
• Organizzazioni che affrontano audit, vendor assessment, qualifica cliente o review di sicurezza.

Perché IEC 82304 conta anche sul piano tecnico

In un percorso IEC 82304, il rischio tecnico non riguarda solo vulnerabilità isolate, ma tutto ciò che può compromettere la sicurezza del prodotto software nel suo uso reale:

• Applicazioni web, API, backend e app mobile che sostengono funzioni sanitarie o amministrative;
• Installazione, aggiornamenti, configurazioni e change management del prodotto;
• Dipendenze cloud, servizi terzi e integrazioni che influiscono su disponibilità e integrità del software;
• Ruoli privilegiati, ambienti multi-tenant e dati sanitari o sensibili trattati dal sistema;
• Mismatch tra sicurezza dichiarata del prodotto e comportamento effettivo in esercizio.

Per questo, anche quando la norma non richiede letteralmente un penetration test, una verifica tecnica diventa spesso necessaria per capire se il prodotto sia davvero difendibile, mantenibile e affidabile.

Dove il penetration test produce evidenze utili

In questo contesto, il penetration test è utile soprattutto quando bisogna dimostrare che:

• Il perimetro esposto del prodotto non presenti vulnerabilità facilmente sfruttabili;
• Ruoli, autorizzazioni, aggiornamenti e configurazioni non creino condizioni di abuso realistiche;
• Applicazioni, API e componenti digitali reggano a scenari di attacco compatibili con l’uso reale del software;
• Remediation e retest producano una prova leggibile anche da auditor, buyer o management.

In pratica, il test aiuta a trasformare i requisiti di product safety in evidenze tecniche più concrete su esposizione, impatto, mantenibilità e robustezza operativa del software. Nei test su health software in percorso IEC 82304, i finding più ricorrenti riguardano portali di accesso ai dati del paziente privi di controlli di autorizzazione adeguati tra ruoli, meccanismi di aggiornamento del software non autenticati e API di integrazione con sistemi clinici che espongono dati senza limitazioni sul volume esportabile.

Cosa chiedono buyer, auditor e stakeholder

Un notified body, un regulatory affairs manager o un buyer sanitario che valuta health software rispetto a IEC 82304 chiede cose concrete:

• Il software è stato classificato correttamente per classe di safety (A, B, C) e la verifica tecnica copre i componenti con maggiore impatto?
• I finding tecnici sono stati valutati per il loro impatto su safety del paziente, integrità del dato clinico e continuità del servizio?
• Il piano di correzione è coerente con il ciclo di vita del software e con il risk management IEC 14971?
• Il software di terze parti integrato è stato incluso nel perimetro di verifica o è stato giustificato il motivo dell’esclusione?
• Esiste un retest che chiude formalmente le anomalie prima della distribuzione o dell’aggiornamento del prodotto?

Mappatura tra requisiti, rischio ed evidenze

Area da validare	Evidenza utile	Attività ISGroup più adatta	Output atteso
Superfici web, portali di gestione e backend	Vulnerabilità sfruttabili e impatto sul prodotto	Web Application Penetration Testing	Executive summary, finding, remediation
App companion e componenti mobili	Abuso di logiche, leakage locale, auth gap	Mobile Application Security Testing	Dettaglio tecnico e priorità
Codice critico e componenti software del prodotto	Difetti implementativi e debolezze di sicurezza	Code Review	Evidenze tecniche e indicazioni di fix
Architettura del prodotto, dipendenze e flusso di aggiornamento	Mismatch tra safety dichiarata e rischio reale	Secure Architecture Review	Lettura del rischio e percorso di remediation

Caso d’uso: vendor healthtech in fase di audit

Uno scenario tipico è quello di un vendor healthtech che distribuisce un software sanitario su infrastruttura general-purpose e deve dimostrare che il prodotto, oltre a funzionare, resti sicuro durante installazione, uso, aggiornamento e manutenzione. Quando arrivano audit, due diligence o vendor review, le domande si spostano su autenticazione, API, segregazione dei ruoli, dipendenze cloud, gestione delle patch e continuità del servizio. In quel momento il penetration test diventa utile per tradurre la product safety in evidenza tecnica concreta.

Un riferimento coerente è il case study sul Web Application Penetration Test condotto su Flora di Kelyon S.r.l., che mostra come un software in ambito sanitario debba essere credibile non solo sul piano funzionale, ma anche su affidabilità e protezione del dato.

Errori comuni da evitare

• Pensare che lo standard renda opzionale la validazione tecnica;
• Confondere sicurezza del prodotto e semplice hardening di un singolo ambiente;
• Limitare lo scope a un solo componente quando il prodotto reale dipende da più superfici e servizi;
• Non collegare i finding a continuità, mantenibilità e rischio residuo del software;
• Produrre un report tecnico senza executive summary, remediation plan e retest.

Domande frequenti su IEC 82304 e penetration test

• Qual è la differenza tra IEC 82304 e IEC 62304 per il penetration test?
• IEC 62304 governa il processo di sviluppo del software come parte di un medical device. IEC 82304 definisce i requisiti di sicurezza del prodotto software sanitario autonomo — non necessariamente un dispositivo medico MDR, ma qualsiasi health software. Per entrambi, il penetration test serve a verificare che le misure di sicurezza dichiarate reggano davvero, ma il contesto regolatorio e gli stakeholder di riferimento sono diversi.
• Cosa include IEC 82304 che non è coperto dalle normative generali sulla cybersecurity?
• Requisiti specifici per la safety del paziente, per la continuità del servizio in contesti clinici e per la gestione del ciclo di vita del software sanitario nel tempo — inclusi aggiornamenti, manutenzione e fine vita. Questi elementi non sono coperti da standard generici come ISO 27001 o OWASP, che non considerano il contesto di uso sanitario e l’impatto sulla safety del paziente.
• Come si usa la verifica tecnica nel dossier regolatario MDR/FDA per health software?
• I finding del test entrano nella documentazione tecnica come evidenze della verifica di sicurezza del prodotto. Per MDR, alimentano il Technical File; per FDA (510k, De Novo o PMA), supportano il Cybersecurity Testing documentation come richiesto dalla FDA Guidance. Un report ben strutturato con scope, finding, impatto sulla safety e retest accelera la revisione regolatoria.

Per collegare IEC 82304 a evidenze tecniche davvero spendibili, il primo passo utile è chiarire quali componenti del prodotto hanno più impatto sulla sicurezza e sulla continuità operativa. È possibile combinare Secure Architecture Review, Code Review, Web Application Penetration Testing e, quando serve, Mobile Application Security Testing per ottenere un output più utile sia per il team tecnico sia per audit e governance.

Approfondimenti correlati

• Per capire quando il penetration test è davvero necessario in un percorso IEC 82304, l’approfondimento su IEC 82304 e quando il penetration test conta davvero offre un’analisi pratica dei casi d’uso;
• Per gestire audit, vendor assessment e fiducia del buyer con evidenze solide, la guida su IEC 82304 e le evidenze utili per audit e vendor assessment chiarisce cosa produrre e come presentarlo;
• Per definire scope, deliverable e retest in modo coerente con lo standard, la guida pratica su IEC 82304, scope, deliverable e retest fornisce un riferimento operativo completo.