Rapporto sui risultati

4.11 Requisiti in materia di protezione e sicurezza dei dati per terzi (cpv. 1 lett. f)

K3, VZK, ZAD nonché i Cantoni ZH e NW chiedono di verificare la necessità delle disposizioni riportate al numero 4.11. in caso affermativo, si dovrebbe sondare la possibilità di sostituirle con regolamentazioni generali e astratte nell'OCIP. OFAC vorrebbe sapere perché al numero 4.11 non si fa riferimento ai requisiti dell’articolo 10a LPD. Posta considera opportuno il registro di terzi di cui al numero 4.11.1 e chiede quale sia lo scopo del visto apposto dal responsabile della sicurezza dei dati. La formulazione è troppo vaga. Il termine «IT-Infrastrukturkomponenten» dovrebbe essere definito in modo più preciso, altrimenti bisognerebbe inserire nell’elenco anche Intel, Samsung, Microsoft ecc. Chiede quindi di stralciare la richiesta di visto e la formulazione «unter Umständen». In riferimento al numero 4.11.2, SQS evidenzia che la prima frase dovrebbe essere completata nel modo seguente: «Gemeinschaften müssen sicherstellen, dass kein Datenzugriff […]». Tessaris segnala degli errori di ortografia al numero 4.11.2 e chiede cosa s’intende in questo contesto per «Intermediäre» rispetto a «Dritte». Posta vorrebbe conoscere la differenza fra il numero 4.11.3 e il numero 4.11.4. Secondo privatim i contratti di cui al numero 4.11.5 dovrebbero assolutamente contenere le seguenti clausole: disposizioni secondo cui i terzi devono garantire che vengano autorizzati ad accedere ai dati solo i collaboratori che ne hanno veramente bisogno per adempiere al loro compito; una dichiarazione di confidenzialità per i collaboratori che li vincoli al segreto professionale anche oltre il termine del loro contratto di lavoro; divieto di trasferire i dati a terzi senza il consenso della comunità. La disposizione al numero 4.11.5.4 dovrebbe inoltre precisare chi ha diritto alla verifica periodica: i gestori della comunità o il responsabile della protezione dei dati della comunità? Sarebbe poi opportuno disciplinare che la comunità è autorizzata ad avvalersi di terzi competenti per effettuare tale verifica. Privatim desidera una riformulazione dei numeri da 4.11.5.5 a 4.11.5.7 e consiglia di evitare i rapporti di subappalto. Più persone sono coinvolte nelle procedure, più diventa difficile mantenere una visione d’insieme e il controllo. La disposizione dovrebbe pertanto essere modificata in modo da consentire solo in via eccezionale i rapporti di subappalto e solo previo consenso della comunità (un consenso puntuale e non generale).

4.12 Controllo e verifica dei servizi (cpv. 1 lett. f)

K3, VZK, ZAD e il Cantone ZH ribadiscono il parere espresso sul numero 4.11. SQS ripete l’osservazione fatta sull’articolo 11 capoverso 2 OCIP e sul numero 4.12.1 e propone di stralciare che il servizio di certificazione funge da centro di notifica per tutti gli eventi considerati rilevanti per la sicurezza.

4.13 Obbligo di notifica degli incidenti di sicurezza (cpv. 2)

K3, VZK, ZAD e il Cantone ZH ribadiscono il parere espresso sul numero 4.11 e 4.12, mentre FMH ripete il commento fatto sul numero 4.5.1.1. SQS non approva che il servizio di certificazione assuma il ruolo di centro di notifica per eventi di sicurezza. In questo punto non si dovrebbe neanche definire una procedura di notifica da parte delle comunità. Propone di cancellare il servizio di certificazione come centro di notifica e di stralciare il brano di frase «die Zertifizierungsstelle und» dal numero 4.13.1. ISSS segnala che in base a prescrizioni in altri contesti, p. es. nell’UE-RGPD, anche i pazienti devono essere informati di eventi rilevanti per la sicurezza se questi comportano per loro un potenziale rischio. Il numero 4.13.1 deve essere completato con la seguente frase: «[…] Zudem müssen Gemeinschaften formale Verfahren für das unverzügliche Melden von Vorfällen an die betroffenen Patienten, durch welche die Verletzung des Schutzes personenbezogener Daten voraussichtlich ein hohes Risiko für die persönlichen Rechte und Freiheiten dieser Patienten zur Folge hat, definiert haben».

4.14 Sicurezza di esercizio (cpv. 3)

4.14.1: HIN osserva riguardo al numero 4.14.1.1.1 che si tratta giustamente di un’autenticazione forte a 2 fattori. Sempre a riguardo, SQS chiede di precisare a partire da quando un’autenticazione a 2 fattori possa essere considerata forte. In riferimento al numero 4.14.1.1, KSSG scrive che l’applicazione di un’autenticazione a 2 fattori nei sistemi operativi, in particolare nelle banche dati e altri componenti