🏥NIS2 pentru Sănătate — termene, obligații, amenzi

Cadru documentat, abordare all-hazard, acoperind politici de risc, securitatea sistemelor, gestiunea incidentelor, business continuity (cu RTO/RPO documentate pentru ATI, salile de operatie, urgenta, farmacie, laboratoare), criptografie, MFA, training, controlul accesului si securitatea resurselor umane. NIS2 Art. 21(2) impune cele zece masuri minime (a-j), aliniate pe ISO/IEC 27001 si ISO/IEC 27002 [C3]. Pentru spitale, ENISA Technical Implementation Guidance v1.0 (2025) ramane ghidul tehnic de referinta — nu Reg. 2024/2690, care vizeaza juridic furnizorii de DNS, cloud, MSP, data centres si nu spitalele [C17]. Organul de conducere al entitatii (consiliul de administratie, board-ul, comitetul director) aproba si supravegheaza implementarea conform NIS2 Art. 20, cu raspundere personala [C14].

Pentru un spital cazut sub NIS2 in care un incident cibernetic atinge si date de pacienti, acelasi eveniment declanseaza doua fluxuri paralele de raportare. NIS2 Art. 23 catre CSIRT/DNSC: early warning in maxim 24h de la constientizare, notificare incident in 72h, raport final in maxim o luna [C4]. GDPR Art. 33 catre ANSPDCP: notificare bresa de date cu caracter personal in maxim 72h de la constientizare, daca exista risc pentru drepturile si libertatile persoanelor [C8]. Cele doua termene de 72h se masoara independent — momentul de start poate fi diferit (constientizarea "incidentului semnificativ" vs. constientizarea "incalcarii datelor cu caracter personal"). Practic, CISO + DPO impart un singur runbook care alimenteaza simultan formularul DNSC si formularul ANSPDCP, fara duplicari de munca si fara intarziere a vreunuia.

Datele de sanatate sunt categorie speciala de date cu caracter personal — GDPR Art. 9(1) interzice prelucrarea, cu exceptia situatiilor expres prevazute la Art. 9(2): consimtamant explicit, asistenta medicala / diagnostic medical, interes public in domeniul sanatatii publice, scopuri stiintifice etc. [C7]. Implementarea ceruta de NIS2 Art. 21(2)(h) (criptografie) + GDPR Art. 32 (masuri tehnice si organizatorice) include criptarea la transport (TLS 1.3) si la depozit pentru HIS/EHR/PACS/LIS, segregarea retelelor clinice de cele administrative, audit logging persistent, retentie minima pentru date identificabile, pseudonimizare/anonimizare pentru cercetare. Acordul cu producatorul HIS sau cu furnizorul cloud devine contract DPA + clauze de securitate, nu doar serviciu IT.

Pentru un spital, "business continuity" inseamna pacienti in ATI care nu raman fara monitorizare, blocuri operatorii care pot interveni in 24/7, farmacie care poate elibera medicatie. NIS2 Art. 21(2)(c) cere business continuity si crisis management ca cerinte minime [C3]. Practic: planuri offline functionale (formulare hartie, traseu manual laborator, decizii clinice fara HIS), exercitii anuale cu tabletop si simulari, backup-uri offline imutabile (cu rotire si testare restore), redundanta multi-site pentru imagistica si laboratoare. Lectia BackMyData / Hipocrate (februarie 2024) este ca spitalele care aveau backup-uri recente functionale au reluat activitatea rapid; cele care nu le testasera au stat zile sau saptamani in regim manual [C18].

Spitalul nu cumpara doar IT: cumpara CT, RMN, monitoare ATI, pompe de perfuzie, defibrilatoare conectate, sisteme PACS, sisteme de laborator (LIS) — toate cu firmware, software, conectivitate. NIS2 Art. 21(2)(d) cere securitatea lantului de aprovizionare [C3]. MDR (Reg. 2017/745) impune producatorilor cerinte esentiale de cybersecurity pentru dispozitive cu software, inclusiv risk management si security-by-design (Anexa I, sectiunile 14.2(d) si 17.2) [C9]; IVDR (Reg. 2017/746) le extinde la dispozitivele de diagnostic in vitro din 26 mai 2022 [C10]. Concret: clauze contractuale cu fiecare producator (SLA pe patching, SBOM, vulnerability disclosure), inventar tehnic al dispozitivelor cu IP/firmware, segregare retea pentru clase de dispozitive non-patch-abile, monitorizare comportamentala pentru anomalii. Lectia Dusseldorf 2020: backdoor pe Citrix CVE-2019-19781 a stat ~9 luni pe retea, in cele din urma a contribuit la moartea unui pacient transferat la alt spital.

Tip: Ransomware BackMyData (familia Phobos); vector RDP / acces la furnizor ICT tert

Impact: 26 spitale afectate (printre care Spitalul de Pediatrie Pitesti, primul care a raportat pe 10 februarie 2024); criptare date HIS; cerere de rascumparare 3,5 BTC (~157.000 EUR / ~180.000 USD la momentul atacului — februarie 2024). Majoritatea spitalelor afectate aveau backup-uri recente, restaurare relativ rapida. Incidentul a fost invocat in nota de fundamentare a OUG 155/2024 ca justificare directa a transpunerii NIS2 in Romania.

Lecția: Compromiterea unui singur furnizor de software (RSC) a propagat incidentul la 26 de spitale publice. NIS2 Art. 21(2)(d) si OUG 155/2024 cer evaluare si monitorizare contractuala continua a furnizorilor critici de servicii medicale ICT; segregare retea + backup-uri offline testate au salvat majoritatea unitatilor.

Tip: Ransomware DoppelPaymer; exploit pe Citrix CVE-2019-19781 (Shitrix), backdoor latent din decembrie 2019

Impact: Spitalul a iesit din sistemul de urgenta; o pacienta de 78 ani a fost transferata la un spital la ~32 km distanta si a decedat in timpul transportului — primul caz public de deces direct asociat unui atac ransomware. Procurorii din Koln au deschis o ancheta pentru omor din culpa. Operatorii DoppelPaymer au furnizat ulterior cheia de decriptare cand au realizat ca au lovit un spital.

Lecția: Patch-management deficitar (~9 luni intre publicarea patch-ului Citrix si exploatare) intr-un perimetru critic clinic a contribuit la prima moarte direct asociata public unui ransomware. NIS2 Art. 21(2)(e) si MDR Anexa I 17.2 cer gestionarea vulnerabilitatilor si security-by-design pentru dispozitivele si sistemele clinice.

Tip: Ransomware Qilin (3 iunie 2024); criptare retea Synnovis + exfiltrare date

Impact: Servicii de patologie pentru NHS Londra blocate. La King's College + Guy's and St Thomas' — 1.134 operatii planificate si 2.194 programari ambulatorii anulate in primele 13 zile. Analize de sange in capitala operationale la ~10% din capacitate. Cerere de rascumparare 50 mil. USD, refuzata. Peste 900.000 pacienti cu date potential exfiltrate.

Lecția: Un singur furnizor de patologie compromis a paralizat doua dintre cele mai mari trusturi NHS din Londra. NIS2 Art. 21(2)(d) si Planul de actiune UE 2025 pe sanatate cer harti detaliate ale dependentei de furnizori critici clinici (laboratoare, imagistica, farmacie).

Tip: Ransomware BlackCat / ALPHV (detectat 21 februarie 2024); intrare presupusa prin Citrix fara MFA

Impact: Cea mai mare bresa de date medicale din SUA. Intreruperi majore in procesarea retetelor, decontari medicale si plati pentru providers. UnitedHealth a furnizat peste 9 miliarde USD in finantare-puente catre furnizorii afectati. Impact financiar 2024 estimat la 1,90-2,05 USD/actiune. Date PHI/PII confirmate exfiltrate (22 screenshots publicate pe dark web). Call-center dedicat pentru 2 ani de credit monitoring gratuit clientilor afectati.

Lecția: Concentrarea de risc ICT in sanatate (un singur procesor de claims pentru cca o treime din SUA) a propagat incidentul la mii de spitale si farmacii. NIS2 Art. 21(2)(d) si Planul de actiune UE 2025 cer testarea concentrarii pe furnizori critici si scenarii de continuitate sub asumarea ca un furnizor mare cade.

GDPR — Regulamentul (UE) 2016/679 · Direct aplicabil din 25 mai 2018; ANSPDCP este autoritatea de supraveghere in Romania [C7][C8]

Datele de sanatate sunt categorie speciala — GDPR Art. 9(1) interzice prelucrarea cu exceptia situatiilor expres prevazute la Art. 9(2) [C7]. Art. 33 impune notificarea bresei catre ANSPDCP in 72h [C8]. Diferenta cheie fata de NIS2: GDPR e activat de bresa de date personale, NIS2 e activat de incident cibernetic semnificativ — pot coincide, dar nu obligatoriu. Sanctiunile sunt cumulative cu cele NIS2.

MDR — Regulamentul (UE) 2017/745 · Direct aplicabil din 26 mai 2021 [C9]

Pentru orice spital care opereaza dispozitive medicale cu software (CT, RMN, pompe, monitoare ATI, defibrilatoare conectate), producatorul are obligatii esentiale de cybersecurity sub MDR Anexa I 14.2(d) + 17.2 [C9]. Spitalul, ca utilizator, trebuie sa-si inventarieze parcul de dispozitive, sa segregheze retelele si sa pretinda SBOM + politica de patching contractuala. MDCG 2019-16 este ghidul tehnic principal.

IVDR — Regulamentul (UE) 2017/746 · Direct aplicabil din 26 mai 2022 [C10]

Extinde regimul MDR la dispozitivele de diagnostic in vitro (analizoare biochimice, hematologice, microbiologice, software de interpretare). Software-ul care conduce sau influenteaza un dispozitiv IVD cade in aceeasi clasa cu dispozitivul. Pentru laboratoare de spital si laboratoare medicale, IVDR + GDPR Art. 9 se aplica simultan cu NIS2 Art. 21(2)(d).

Cyber Resilience Act — Regulamentul (UE) 2024/2847 · Intrat in vigoare 10 decembrie 2024; obligatii principale aplicabile din 11 decembrie 2027, raportare vulnerabilitati active din 11 septembrie 2026 [C11]

CRA exclude explicit dispozitivele medicale acoperite de MDR/IVDR (Art. 2(2)(a)), pentru ca acelea raman sub Anexa I MDR/IVDR. Ramane relevant insa pentru produsele IT generice utilizate in spitale (sisteme HIS care nu sunt MDR, terminale, IoT facility, software administrativ, cititoare de carduri, sisteme de control acces, camere conectate). Spitalul devine cumparator pretentios: produsele cu elemente digitale trebuie sa aiba conformitate CRA inainte de plasare pe piata UE.

AI Act — Regulamentul (UE) 2024/1689 · Intrat in vigoare 1 august 2024; obligatii pentru AI high-risk aplicabile esalonat 24-36 luni [C12]

Pentru spitale care utilizeaza AI clinic (radiologie asistata, triaj, predictie de mortalitate, decizie terapeutica, IVD-uri cu AI), sistemele AI clasificate ca high-risk sub Anexa III sau prin armonizarea cu MDR au obligatii suplimentare: risk management, seturi de date de calitate, transparenta, human oversight, log-uri. AI Act se aplica cumulativ cu MDR + GDPR Art. 9 — practic, decizia clinica asistata de AI ramane sub raspunderea medicului si a institutiei.