ENISA mută securitatea spitalelor în contractele de achiziție

Pe 22 iulie, ENISA a publicat ghidul actualizat pentru securitatea cibernetică în achizițiile spitalelor și furnizorilor de servicii medicale. Documentul de 69 de pagini se adresează celor care definesc, evaluează și administrează achizițiile: conducere, responsabili de achiziții, inginerie clinică, IT, securitate, juridic și furnizori. Mesajul central este practic—securitatea trebuie să intre în caietul de sarcini și în contract înainte ca dispozitivul medical, serviciul cloud sau sistemul clinic să intre în rețea.

Publicația este unul dintre primele rezultate ale Planului de acțiune al UE pentru securitatea cibernetică a spitalelor și furnizorilor medicali. ENISA a anunțat și un acord de contribuție de 6 milioane de euro cu Comisia Europeană, pe trei ani, pentru dezvoltarea unui mecanism de sprijin și a unui catalog de servicii organizat în jurul pregătirii, detecției, răspunsului și guvernanței.

Planifică, selectează, administrează: securitate pe tot ciclul contractual

Ghidul împarte achiziția în trei etape. În planificare, entitatea medicală identifică riscul, stabilește standardele și introduce cerințe măsurabile în documentație. În selecție, o echipă multidisciplinară evaluează dovezi, nu doar declarații generale. În administrare, organizația urmărește performanța, incidentele, vulnerabilitățile, mentenanța și scoaterea sigură din uz pe toată durata relației.

Astfel, securitatea trece de la rolul de verificator tehnic târziu la cel de participant în achiziție. Furnizorul nu poate fi evaluat doar prin funcția clinică, preț sau un certificat ISO. Decizia trebuie să acopere durata suportului, procesul de patching și disclosure, subcontractorii, responsabilitățile la incident, recuperarea, logarea, controlul accesului și o strategie de ieșire care protejează datele și continuitatea actului medical.

Clauze care transformă promisiunea de securitate în obligație

• Cere furnizorilor să raporteze vulnerabilitățile și incidentele fără întârzieri nejustificate, într-o fereastră definită și aliniată procesului propriu de raportare NIS2
• Stabilește termene pentru remedierile critice, cere dovezi de patching și tratează nerezolvarea ca problemă contractuală, nu doar ca solicitare informală de suport
• Definește răspunderea, subcontractorii aprobați și obligația de a transmite aceleași cerințe de securitate pe întregul lanț
• Impune acces de mentenanță autorizat și limitat, cu MFA, canale criptate și evidența schimbărilor făcute de personalul furnizorului
• Specifică cerințe de continuitate, backup, failover și recuperare, apoi testează-le raportat la timpul maxim de indisponibilitate tolerat de serviciul clinic
• Include ieșirea sigură: export utilizabil al datelor, ștergere verificată, returnarea activelor, sprijin pentru tranziție și plan pentru insolvență sau end-of-life

Folosirea AI trebuie declarată chiar dacă AI nu este produsul

ENISA extinde verificarea dincolo de produsele promovate ca AI-enabled. Un furnizor poate folosi un serviciu AI terț pentru dezvoltare software, suport, testare de securitate, documentație sau analiză de date. Documentația trebuie să identifice scopul, furnizorul modelului, tipul de deployment, subprocesatorii, categoriile de date, retenția, controlul uman, logarea și notificarea schimbărilor materiale.

Ghidul spune că informațiile sensibile medicale, personale, de securitate sau infrastructură nu trebuie trimise către servicii AI externe și nici folosite la dezvoltarea modelelor fără autorizare explicită, bazată pe evaluări juridice, de confidențialitate, cyber și risc clinic. Contractul trebuie să definească utilizările AI permise și interzise și ștergerea prompturilor, rezultatelor, logurilor și datelor derivate la încetare.

Checklist inițial pentru entitățile medicale din România

• Construiește un registru al furnizorilor critici și leagă fiecare furnizor de dispozitivele, aplicațiile, fluxurile de date și serviciile clinice dependente
• Adaugă în șabloanele de achiziție controale minime: criptare în tranzit și repaus, MFA, audit logging, update-uri sigure, disclosure, contact de incident și date de suport
• Cere dovezi verificabile—arhitectură, istoric de patch-uri, rezultate ale testelor, certificate cu domeniu clar, teste de recuperare și subprocesatori nominalizați—nu doar un chestionar da/nu
• Folosește un comitet de evaluare mixt, cu achiziții, clinic, tehnic, securitate, privacy și juridic
• Înregistrează excepțiile acceptate, controalele compensatorii, proprietarul riscului și data expirării înainte de semnarea contractului
• Introdu fiecare sistem cumpărat în inventarul de active și fluxul de vulnerabilități chiar din ziua recepției, apoi urmărește advisory-urile, patch-urile și suportul până la retragere

Ghidul nu înlocuiește legislația din România

ENISA aliniază ghidul cu NIS2, GDPR, regulile pentru dispozitive medicale și Spațiul european al datelor privind sănătatea, dar precizează că nu înlocuiește cerințele naționale. Spitalele și furnizorii din România trebuie să coreleze recomandările cu statutul juridic, regulile sectoriale, cadrul achiziției și obligațiile din transpunerea națională NIS2.

Rezultatul util este un lanț de dovezi: cerință aprobată, răspunsul furnizorului, evaluare, clauză contractuală, activ instalat, vulnerabilitate, dovada patch-ului și verificare periodică. Awarely Monitor poate lega activul și furnizorul de CVE-uri, responsabili, termene și dovezi păstrate, astfel încât controlul achiziției să continue și după semnarea contractului.