Ce este supply chain risk management? Ghid NIS2 pentru riscul cibernetic al furnizorilor

Alexandru Ana, Chief Executive Officer

Un incident de securitate nu intră întotdeauna prin ușa din față. De multe ori ajunge în organizație printr-un furnizor de software care primește o actualizare compromisă, prin contul administrativ al unui MSP sau printr-o platformă cloud pe care o foloseai fără să te gândești vreodată că ar putea pica. Perimetrul tău poate fi impecabil. Furnizorul tău, mai puțin.

 

Supply chain risk management înseamnă gestionarea sistematică a riscurilor cibernetice care vin din relația cu furnizorii și prestatorii de servicii.

 

NIS2 cere entităților esențiale și importante să trateze aceste riscuri într-un mod adecvat și proporțional, inclusiv pe cele asociate furnizorilor direcți. Nu vorbim despre un audit unic, nici despre o bifă anuală într-un tabel. Vorbim despre un ciclu care se repetă: cartografiere, evaluare, verificare, contractare, monitorizare și reevaluare.

Ecosistemul de terți al unei organizații moderne: fiecare conexiune este o potențială cale de intrare.

 

De ce lanțul furnizorilor a devenit o suprafață extinsă de atac

Acum zece ani, securitatea însemna în mare parte să-ți aperi propria rețea. Astăzi, o companie medie rulează pe zeci de servicii externe pe care nu le controlează direct. Fiecare dintre ele deschide o cale posibilă către datele și sistemele tale.

 

Dependența crescută de servicii terțe

Lista furnizorilor cu relevanță de securitate s-a lungit mult. Intră aici o grămadă de categorii pe care, până nu demult, nici nu le priveam ca „risc”:

• • platforme cloud și IaaS;

• • aplicații SaaS folosite zilnic de echipe întregi;

• • furnizori de servicii gestionate (MSP) și de securitate gestionată (MSSP);

• • integratori și furnizori software;

• • servicii de backup și de gestionare a identității;

• • furnizori OT și IoT, tot mai prezenți în mediile industriale.

Pentru România, un reper util vine de la Eurostat. În 2024, aproximativ 24,9% dintre întreprinderi utilizau servicii cloud plătite, o cifră sub media europeană. Nu înseamnă automat că restul funcționează în medii hibride sau legacy, dar arată că o parte importantă a infrastructurii naționale încă trece prin configurații mixte, mai greu de standardizat și de verificat.

 

Diferența dintre riscul direct și riscul moștenit

Aici apare o distincție pe care multe organizații o ratează. Riscul direct vine din accesul sau serviciul furnizorului cu care ai contract semnat. Îl vezi, îl cunoști, poți discuta cu el. Riscul moștenit vine din subcontractorii și platformele pe care furnizorul tău le folosește la rândul lui.

Poți fi afectat de o breșă la o companie cu care nu ai nicio relație contractuală. MSP-ul tău folosește un instrument de monitorizare, acel instrument e compromis, iar tu ești în lista victimelor. Nu știai nici măcar că instrumentul există.

 

De ce nu este suficientă securizarea infrastructurii proprii

O organizație poate avea controale solide și tot să rămână expusă. Punctele slabe nu sunt neapărat la tine. Pot fi la cine are cheia:

• • un cont administrativ al MSP-ului, cu privilegii largi asupra sistemelor tale;

• • o integrare API care rămâne activă mult după ce a încetat să mai fie necesară;

• • o bibliotecă software compromisă, inclusă într-o aplicație pe care o folosești;

• • un furnizor cloud indisponibil într-un moment prost;

• • un subcontractor pe care nimeni nu l-a verificat vreodată.

ENISA confirmă în analizele sale de peisaj al amenințărilor că atacurile asupra furnizorilor terți, a serviciilor digitale și a mediilor cloud au continuat să genereze incidente cu impact extins. Rapoartele nu oferă un singur procent universal valabil pentru „incidentele din supply chain”, pentru că definițiile variază. Concluzia practică rămâne însă aceeași: dependența de terți nu mai este un detaliu de care te ocupi când ai timp.

Rețea de furnizori IT interconectați, cu furnizori cloud, software și MSP legați prin linii de securitate

 

Ce cere concret NIS2 pentru managementul furnizorilor

Directiva NIS2 nu lasă securitatea lanțului de aprovizionare la latitudinea bunului simț. O trece explicit în lista măsurilor de gestionare a riscului cibernetic.

 

Securitatea lanțului de aprovizionare în articolul 21

Articolul 21 din Directiva NIS2 include securitatea lanțului de aprovizionare printre măsurile obligatorii și se referă direct la relațiile cu furnizorii și prestatorii de servicii. Textul vizează aspectele de securitate ale relației cu fiecare furnizor direct, nu doar politica internă a organizației. Practic, nu mai poți spune „furnizorii mei sunt problema lor”. Securitatea lor devine, într-o anumită măsură, și problema ta.

 

Proporționalitatea nu înseamnă cerințe opționale

O confuzie frecventă: unii interpretează „proporțional” ca pe o scuză de a face mai puțin. Nu asta e ideea. Proporționalitatea înseamnă că intensitatea verificărilor trebuie calibrată după relevanța furnizorului, nu redusă la minim. Ce iei în calcul:

• • impactul potențial asupra organizației;

• • nivelul de acces al furnizorului la sisteme și date;

• • criticitatea serviciului oferit;

• • sensibilitatea datelor implicate;

• • gradul de dependență operațională;

• • cât de ușor poate fi înlocuit.

Un furnizor de papetărie și un MSP cu acces de administrator nu merită același tratament. Primul cere verificări minime. Al doilea cere o analiză serioasă, documentată, repetată.

 

Contextul legislativ din România

La nivel național, NIS2 a fost transpusă prin OUG 155/2024, aprobată și modificată ulterior prin Legea 124/2025. Nu intru în analiza juridică detaliată, pentru că scopul articolului e operațional. Un punct merită reținut: verificarea și controlul sunt legate de existența unor dovezi documentate, nu doar de declarații sau politici generale. O politică scrisă frumos, fără dovada că e aplicată, nu te ajută în fața unui control DNSC. Formularea exactă a obligațiilor trebuie verificată în normele și actele subsecvente aplicabile la momentul la care implementezi.

 

Ce nu acoperă acest articol

Ca să rămânem pe subiect, nu discutăm aici cine trebuie să respecte NIS2, cum te înregistrezi la DNSC, care sunt toate termenele și sancțiunile sau cum arată autoevaluarea generală. Acestea sunt subiecte separate, tratate pe paginile dedicate de cerințe NIS2.

Aici ne ocupăm strict de riscul cibernetic al furnizorilor și de procesul prin care îl ții sub control.

 

Etapa 1: Cartografierea furnizorilor critici și a dependențelor

Nu poți proteja ce nu știi că ai. Primul pas nu e tehnic, e de inventariere. Și e etapa pe care cele mai multe organizații o tratează superficial, pentru că pare plictisitoare.

Harta dependențelor arată ce se întâmplă dacă un furnizor nu mai poate presta serviciul, nu doar cine este el.

 

Cum construiești inventarul ecosistemului de terți

Inventarul trebuie să treacă dincolo de furnizorii cu contract direct. Include toate entitățile care:

• • accesează datele tale, oricât de limitat;

• • administrează sau configurează sisteme;

• • susțin procese esențiale de business;

• • furnizează componente software integrate în aplicațiile tale;

• • oferă mentenanță sau suport cu acces la mediu;

• • pot influența continuitatea unui serviciu.

 

Cum identifici furnizorii critici

Dintr-o listă de zeci, doar câțiva sunt cu adevărat critici. Criteriile care te ajută să-i separi:

• • accesul la date sensibile;

• • accesul privilegiat la sisteme;

• • nivelul de integrare tehnică;

• • dependența operațională reală;

• • lipsa unei alternative viabile;

• • timpul necesar pentru înlocuire;

• • impactul asupra continuității dacă serviciul dispare.

 

Cum mapezi fluxurile de date și punctele de acces

Pentru fiecare furnizor relevant, urmărește concret unde intră în organizația ta. Un tabel simplu cu sistemele accesate, aplicațiile conectate, datele primite și transmise, conturile privilegiate, integrările API, locația datelor, subcontractorii implicați și procesele interne dependente îți oferă mai multă claritate decât orice document de politică.

 

Registru de furnizori sau hartă de dependențe?

Diferența e subtilă, dar schimbă tot. Registrul îți spune cine este furnizorul. Harta îți arată ce se întâmplă dacă furnizorul nu mai poate presta serviciul. Primul e util pentru contabilitate. Al doilea e util pentru reziliență. Ai nevoie de ambele, dar harta e cea care te salvează într-o criză.

 

De ce Excel-ul îmbătrânește imediat

Un registru static devine inutil aproape imediat. Realitatea se mișcă mai repede decât un fișier actualizat „când avem timp”. Apar furnizori noi, se modifică contracte, se adaugă subcontractori, se extind accesuri, se schimbă arhitecturi, apar incidente, ies servicii din suport. Dacă registrul nu prinde aceste schimbări pe măsură ce se întâmplă, lucrezi cu o fotografie veche a unei realități care s-a schimbat. Un registru dinamic, actualizat la fiecare eveniment relevant, e singura variantă care ține pasul.

 

Etapa 2: Evaluarea riscului proporțional cu impactul

După ce ai lista, urmează partea în care decizi cât de mult te preocupă fiecare nume de pe ea. Greșeala clasică e să-i tratezi pe toți la fel.

 

De ce nu trebuie evaluați toți furnizorii la fel

O abordare uniformă pare corectă pe hârtie. În practică e una dintre cele mai ineficiente alegeri. Trimiți chestionare identice de 80 de întrebări unui curier și unui furnizor cloud. Curierul le completează la întâmplare, furnizorul cloud le ignoră politicos, iar tu consumi efortul echipei pe furnizori cu impact redus. Rezultatul: birocrație, chestionare fără valoare și atenție insuficientă exact acolo unde conta.

 

Tiering: trei niveluri de criticitate

Clasificarea pe niveluri rezolvă problema. Nu trebuie complicată, trei trepte sunt de regulă suficiente.

Nivel	Profil	Caracteristici tipice
1. Critic	Risc ridicat	Acces direct la rețea, acces la date sensibile, sisteme SCADA sau OT, cloud pentru servicii esențiale, imposibilitate de înlocuire rapidă.
2. Mediu-ridicat	Risc moderat	Servicii importante, acces limitat, date operaționale, impact semnificativ dar cu alternative disponibile.
3. Standard	Risc redus	Acces minim, date cu sensibilitate limitată, impact operațional scăzut, înlocuire relativ simplă.

 

Matricea impact-probabilitate

Nivelul de criticitate îți spune cât de mult poate durea. Probabilitatea îți spune cât de des s-ar putea întâmpla. Combinate, îți dau o imagine mai bună decât oricare separat. O matrice care leagă aceste două axe de tipul de verificare, frecvența reevaluării, responsabilul intern și măsura de tratare transformă intuiția într-un proces repetabil.

Matricea impact-probabilitate leagă fiecare furnizor de o măsură de tratare și un responsabil clar.

 

Ce indicatori intră în evaluare

Scorul de risc nu iese dintr-o singură întrebare. Se construiește din mai mulți indicatori: impactul asupra continuității, rezultatele analizei de impact asupra business-ului (BIA), sensibilitatea datelor, nivelul accesului tehnic, dependența de furnizor, substituibilitatea, riscul de concentrare și maturitatea controalelor sale.

 

Cele cinci dimensiuni ale due diligence

Un cadru util pentru structurarea analizei vine din publicația NIST SP 1326, care propune cinci dimensiuni de luat în calcul:

1. 1. proprietatea, controlul și influența asupra furnizorului;

1. 1. proveniența produsului sau a serviciului;

1. 1. reziliența furnizorului în fața incidentelor;

1. 1. practicile sale de securitate de bază;

1. 1. poziția pe care o ocupă în lanțul de aprovizionare.

Un scor de risc fără un plan de tratare, un responsabil și un termen rămâne un număr frumos într-un tabel. Fără cele trei, nu schimbă nimic.

 

Etapa 3: Verificări de securitate, due diligence și dovezi

Clasificarea îți spune pe cine să verifici în profunzime. Etapa asta e despre cum o faci, fără să transformi procesul într-un ritual gol.

 

Chestionare adaptate la profilul furnizorului

Un furnizor cloud, un MSP, un furnizor software și un curier nu pot fi evaluați cu aceeași listă de întrebări. Întrebi un furnizor cloud despre separarea clienților. N-are sens să întrebi curierul același lucru. Chestionarul trebuie croit pe tipul de risc pe care îl aduce furnizorul, nu copiat dintr-un șablon universal.

 

Ce întrebi un MSP sau un furnizor cloud înainte de contractare

Pentru furnizorii cu acces privilegiat, câteva întrebări fac diferența între o relație sănătoasă și o surpriză neplăcută:

• • cine are acces administrativ la sistemele tale și cum e el controlat;

• • cum sunt monitorizate conturile privilegiate;

• • cum sunt separați clienții, într-un mediu multi-tenant;

• • cum gestionează incidentele și în cât timp te anunță;

• • ce subcontractori folosește;

• • cum sunt recuperate datele în caz de dezastru;

• • cum poate fi încheiat serviciul, cu tot cu datele tale.

 

Furnizorul declară versus furnizorul demonstrează

O declarație într-un chestionar nu e o dovadă. Separă clar cele două registre: răspunsul la chestionar e o afirmație, politica e o intenție, certificarea e un semnal, raportul de audit e o constatare, testul tehnic e o verificare, iar dovada de remediere arată că problema chiar a fost rezolvată. Pentru furnizorii critici, vrei cât mai mult din partea dreaptă a acestei scale.

 

Certificări și rapoarte terțe

Certificările ajută, dar nu sunt interschimbabile și nu acoperă automat riscul specific serviciului pe care îl cumperi. Printre cele pe care le poți analiza: ISO 27001, SOC 2, rapoarte de pen-test, rapoarte de audit, rapoarte de control intern și evaluări ale suprafeței de atac. Un furnizor certificat ISO 27001 pe un alt departament decât cel care te servește pe tine nu îți oferă garanția pe care pare să ți-o ofere. Verifică scopul certificării, nu doar existența ei.

 

Software, dezvoltare securizată și open source

Pentru furnizorii de software, lista de verificare se mută spre cod: proveniența codului, procesul de dezvoltare securizată, componentele externe folosite, modul de gestionare a vulnerabilităților, politica de actualizări, existența unui SBOM (lista componentelor software) și, important, componentele care au ieșit din suport. O bibliotecă populară, dar abandonată de autor, e o bombă cu ceas în aplicația ta.

 

Evaluarea externă nu înlocuiește analiza internă

Serviciile de cyber rating, monitorizarea externă și testarea vulnerabilităților sunt semnale utile. Îți spun ceva despre cum arată furnizorul din afară. Nu îți spun însă ce date accesează la tine, ce prevede contractul, cine răspunde de ce și cum arată planul tău de continuitate dacă el pică. Corelează semnalul extern cu realitatea internă, altfel ai doar jumătate din imagine.

 

Etapa 4: Cerințe contractuale și reziliența relației

Verificările de dinainte de semnare sunt importante. Contractul e însă cel care rămâne în picioare când lucrurile merg prost. Aici transformi așteptările în obligații.

 

Clauzele de securitate din SLA și anexele contractuale

Un contract bine construit acoperă, printre altele, cerințe tehnice și organizaționale de securitate, obligația de notificare a incidentelor, cooperarea la investigații, dreptul de audit, accesul la rapoarte, gestionarea vulnerabilităților, instruirea personalului furnizorului, măsurile de continuitate, recuperarea datelor și procedura de returnare sau ștergere a datelor la final de relație.

 

Notificarea incidentelor în cascadă

Dacă furnizorul tău are un incident și te anunță peste două săptămâni, notificarea nu mai folosește la nimic. Furnizorul trebuie să te anunțe suficient de rapid cât să poți confirma impactul, să activezi planul intern, să verifici sistemele dependente, să păstrezi dovezile și să respecți propriile obligații de raportare. Atenție la o capcană aici: nu orice furnizor are automat aceleași termene legale ca tine, entitatea NIS2. Termenul lui de notificare către tine trebuie stabilit prin contract, nu presupus.

 

Cum definești responsabilitatea partajată

În mediile cloud și de servicii gestionate, confuzia despre „cine răspunde de ce” e o sursă constantă de incidente. Un tabel clar de responsabilitate partajată elimină ambiguitatea:

Activitate	Cine o face de obicei
Configurarea controalelor de securitate	Furnizor, cu validare internă
Aprobarea accesului	Organizația
Monitorizarea activității	Împărțit, conform SLA
Păstrarea dovezilor	Ambele părți
Gestionarea incidentelor	Furnizor, cu notificare
Revocarea accesului	Organizația
Testarea recuperării	Furnizor, raportat intern
Aprobarea excepțiilor	Organizația

 

Subcontractori și riscul nth-party

Furnizorul tău are și el furnizori. Aceia au, la rândul lor, alți furnizori. Aici intervine riscul nth-party, lanțul care se extinde dincolo de ce vezi direct. Contractul ar trebui să ceară aprobarea subcontractorilor, notificarea schimbărilor, obligații de securitate echivalente transmise mai departe, acces la informații relevante, o procedură de contestare și un flux clar de notificare. Nu poți verifica fiecare verigă, dar poți cere furnizorului direct să-și asume lanțul lui.

 

Hyperscaler versus furnizor local

Cu un hyperscaler, clauzele sunt standardizate și spațiul de negociere e practic inexistent. Semnezi ce ți se oferă. Cu un furnizor local, ai de regulă mai multă flexibilitate, poți negocia dreptul de audit și termene personalizate. Când dreptul de audit direct nu e realist, cum se întâmplă cu marile platforme, compensezi prin cerere de certificări recunoscute, rapoarte independente și clauze contractuale ferme. Măsura compensatorie nu e la fel de bună ca verificarea directă, dar e mai bună decât nimic.

 

Etapa 5: Reevaluarea periodică, incidentele și planul de ieșire

Un furnizor verificat acum doi ani poate fi azi complet diferit. A fost achiziționat, și-a schimbat subcontractorii, a trecut printr-un incident. Reevaluarea nu e un moft, e ce ține procesul în viață.

Monitorizarea continuă semnalează riscul; reevaluarea periodică îl confirmă și declanșează acțiunea.

 

Monitorizare continuă versus verificare punctuală

Verificarea punctuală îți dă o imagine la un moment dat. Monitorizarea continuă urmărește ce se schimbă între verificări: expirarea dovezilor, vulnerabilități noi, schimbări de subcontractori, incidente publice, modificări în infrastructură, schimbări financiare îngrijorătoare, modificări de serviciu sau ieșirea unor componente din suport. Un semnal automat de risc nu e o concluzie completă. Îți spune unde să te uiți, nu ce să faci.

 

Ce faci când furnizorul critic este compromis

Când un furnizor critic are o breșă, ordinea acțiunilor contează. Un flux care funcționează:

1. 1. notifici furnizorul și ceri detalii;

1. 1. confirmi impactul asupra ta;

1. 1. limitezi accesul furnizorului la sistemele tale;

1. 1. verifici sistemele dependente de el;

1. 1. activezi planul de continuitate;

1. 1. păstrezi dovezile pentru investigație;

1. 1. comunici intern către cine trebuie;

1. 1. faci analiza post-incident;

1. 1. reevaluezi furnizorul și relația cu el.

 

Când declanșezi o reevaluare

Reevaluarea nu are doar un calendar. Are și declanșatori. O faci la un incident, la o schimbare de subcontractor, la extinderea accesului, la achiziția furnizorului de către altă companie, la o modificare contractuală majoră, la o schimbare de arhitectură, la o vulnerabilitate gravă sau la reînnoirea contractului. Oricare dintre acestea schimbă profilul de risc.

 

Planul de ieșire și vendor lock-in

Nicio relație nu durează la nesfârșit. Un plan de ieșire gândit din timp te scapă de dependența toxică numită vendor lock-in. Ce acoperă: exportul datelor, formatul în care le primești, durata migrării, suportul furnizorului în tranziție, revocarea accesului, gestionarea backupurilor, ștergerea datelor, testarea alternativei și costurile reale ale trecerii. Întrebarea de verificat e simplă: dacă ar trebui să plec mâine de la furnizorul ăsta, cât m-ar costa și cât ar dura?

 

KPI și KRI pentru SCRM

Fără indicatori, nu știi dacă procesul funcționează. Câțiva utili de urmărit:

• • procentul furnizorilor critici efectiv evaluați;

• • numărul de dovezi actualizate față de cele expirate;

• • lacunele de securitate rămase deschise;

• • timpul mediu de remediere;

• • numărul furnizorilor fără plan de ieșire;

• • timpul de notificare a incidentelor de către furnizori;

• • numărul de subcontractori neverificați.

 

Implementarea cadrului SCRM și rolul Security OptiApp

Toate etapele de mai sus par multe. Puse într-un ciclu repetabil, devin gestionabile. Ideea nu e să faci tot deodată, ci să ai un ritm.

 

Ciclul de implementare în șase pași

1. 1. inventarierea furnizorilor;

1. 1. cartografierea dependențelor;

1. 1. clasificarea după impact;

1. 1. due diligence proporțional cu criticitatea;

1. 1. integrarea cerințelor în contracte;

1. 1. monitorizarea și reevaluarea periodică.

 

Cine deține procesul

SCRM nu e doar treaba IT-ului. Implică IT-ul, echipa de securitate, achizițiile, departamentul juridic, proprietarul procesului de business afectat, managementul și responsabilul de conformitate. Dacă nimeni nu deține procesul explicit, el se diluează între toți și nu-l face nimeni.

 

Sursa unică de adevăr

Informația împrăștiată prin e-mailuri, foldere și fișiere Excel separate e o rețetă pentru haos. Toate datele relevante ar trebui reunite într-un sistem actualizat: furnizori, riscuri, contracte, dovezi, incidente, remedieri, termene și planuri de ieșire. Când un auditor sau un control DNSC cere o dovadă, ar trebui să o găsești în minute, nu în zile.

 

Rolul Security OptiApp

Aici se potrivește practic o soluție ca Security OptiApp. Platforma centralizează postura tehnică și documentația, ține o bibliotecă de dovezi, registre de risc și de incidente, planuri de remediere, politica de securitate a lanțului de aprovizionare și chestionarele primite de la auditori sau clienți. În plus, mapează constatările pe măsurile NIS2, ceea ce reduce timpul petrecut la corelarea manuală.

De precizat: Security OptiApp nu evaluează automat toți furnizorii externi și nu înlocuiește un audit, o certificare sau autoevaluarea DNSC. Rolul ei e să fie sursa unică de adevăr pentru postura ta și pentru dovezile tale, nu un substitut pentru procesul de due diligence. Pagina publică prezintă deja politica de securitate a lanțului, biblioteca de dovezi și funcția de completare a chestionarelor. Mai multe pe Security OptiApp.

Managementul riscului furnizorilor nu e un proiect cu dată de final. E un proces care are nevoie de un responsabil, de un ritm de reevaluare, de o sursă unică de adevăr, de dovezi actualizate, de contracte aplicabile și de planuri de continuitate și de ieșire. Lipsește oricare dintre ele, și cadrul devine fragil exact când ai mai multă nevoie de el.

 

Obiectivul nu este doar să demonstrezi conformitatea în fața unui control. Este să menții serviciile funcționale și să reduci impactul atunci când un furnizor devine indisponibil sau este compromis. Pentru că întrebarea nu e dacă se va întâmpla, ci când.

 

Întrebări frecvente despre supply chain risk management

Ce înseamnă supply chain risk management?

Este procesul continuu prin care o organizație identifică, evaluează și tratează riscurile cibernetice care vin din relația cu furnizorii și prestatorii de servicii, de la cartografiere până la reevaluare periodică.

Care este diferența dintre furnizor critic și furnizor obișnuit?

Un furnizor critic are acces privilegiat la sisteme sau date sensibile, susține procese esențiale și este greu de înlocuit. Un furnizor obișnuit are acces minim și impact operațional redus, iar o eventuală problemă la el nu oprește business-ul.

Ce este riscul nth-party?

Este riscul care vine din subcontractorii furnizorului tău și din furnizorii acelor subcontractori. Poți fi afectat de o breșă la o companie cu care nu ai nicio relație contractuală directă.

Sunt suficiente certificările furnizorului?

Nu. Certificările precum ISO 27001 sau SOC 2 sunt semnale utile, dar nu sunt interschimbabile și nu acoperă automat riscul specific serviciului pe care îl cumperi. Verifică întotdeauna scopul certificării.

Cum se evaluează un MSP sau un furnizor cloud?

Cu un chestionar adaptat profilului lui, concentrat pe acces administrativ, monitorizarea conturilor privilegiate, separarea clienților, gestionarea incidentelor, subcontractori și proceduri de recuperare a datelor.

Ce trebuie să conțină contractul?

Cerințe tehnice și organizaționale de securitate, obligația de notificare a incidentelor, dreptul de audit, gestionarea vulnerabilităților, continuitatea, recuperarea datelor și procedura de ștergere a datelor la final de relație.

Cât de des trebuie reevaluat un furnizor?

Depinde de criticitate. Furnizorii critici se reevaluează mai des, iar reevaluarea se declanșează și la evenimente precum incidente, schimbări de subcontractor, extinderi de acces sau reînnoirea contractului.

Ce faci când furnizorul nu acceptă auditul?

Compensezi prin certificări recunoscute, rapoarte independente de audit și clauze contractuale ferme. E cazul tipic al hyperscalerilor, unde dreptul de audit direct nu este realist.

Ce este vendor lock-in?

Este dependența excesivă de un furnizor, care face dificilă sau costisitoare migrarea către o alternativă. Un plan de ieșire bine gândit, cu export de date și teste de migrare, reduce acest risc.

Supply chain risk management înlocuiește autoevaluarea NIS2?

Nu. Este o componentă a managementului riscului cerut de NIS2, dar nu înlocuiește autoevaluarea generală, înregistrarea la DNSC sau celelalte obligații de conformitate.

 

Despre Echipa Optimizor

Consultanță și servicii IT gestionate pentru organizații cu infrastructuri hibride. Specializare în securitate, conformitate NIS2 și ecosistemul Microsoft, cu certificările ISO 20000-1 și ISO 9001. Optimizor este dezvoltatorul soluției Security OptiApp și furnizor de servicii IT gestionate în România. Analiza din acest articol se bazează pe surse publice primare și pe practica operațională a echipei, fără ajustări favorabile produsului propriu. Cerințele legale concrete trebuie verificate în normele și actele subsecvente aplicabile la data implementării.

 

Surse

1. 1. Directiva (UE) 2022/2555 (NIS2), articolul 21 privind măsurile de gestionare a riscurilor de securitate cibernetică. Parlamentul European și Consiliul UE, 2022. eur-lex.europa.eu
   2. Cloud computing statistics on the use by enterprises. Eurostat, date 2024. ec.europa.eu/eurostat
   3. ENISA Threat Landscape. European Union Agency for Cybersecurity (ENISA), 2024. enisa.europa.eu
   4. NIST SP 1326, Cyber Supply Chain Risk Management due diligence dimensions. National Institute of Standards and Technology, 2024. csrc.nist.gov
   5. Legea nr. 124/2025 privind aprobarea OUG 155/2024 (transpunerea NIS2). Portal legislativ, 2025. legislatie.just.ro
   6. OUG nr. 155/2024 privind securitatea cibernetică. Portal legislativ, 2024. legislatie.just.ro

1.  

1.  

1.  

1.  

1.