Riscul legat de terți în RGPD, NIS2 și DORA

Același furnizor poate genera obligații privind protecția datelor, securitatea cibernetică și reziliența operațională. Un furnizor de salarizare prelucrează date cu caracter personal; un furnizor de servicii gestionate deține acces privilegiat; o platformă cloud susține aplicații critice pentru business. Uneori, un singur furnizor face toate trei.

O evidență comună a furnizorului ajută echipele să coordoneze evaluarea, cu condiția ca fiecare obligație să rămână identificabilă. Pentru un CTO, provocarea practică este legarea angajamentelor contractuale de realitatea tehnică: ce poate accesa furnizorul, cum se propagă defecțiunile, ce controale sunt dovedite și dacă organizația își poate reveni sau poate pleca.

Stabiliți aplicabilitatea înainte de a combina evaluările

Aceste instrumente se suprapun, dar nu se aplică tuturor organizațiilor sau furnizorilor în același mod.

Articolul 28 din RGPD impune operatorilor să recurgă la persoane împuternicite care oferă garanții suficiente. Un acord în temeiul articolului 28 nu este adecvat doar pentru că un furnizor primește date: stabiliți mai întâi rolul efectiv în prelucrare.

Articolele 20–23 din NIS2 vizează supravegherea de către conducere, măsurile de gestionare a riscurilor și raportarea incidentelor semnificative. NIS2 este o directivă transpusă prin legislația națională, așa că domeniul de aplicare și procedurile necesită verificări specifice fiecărei jurisdicții.

DORA se aplică din 17 ianuarie 2025. El acoperă în principal anumite entități financiare; furnizorii TIC obișnuiți se pot confrunta cu cerințe contractuale ale clienților, în timp ce furnizorii TIC critici desemnați au un regim de supraveghere separat. Pentru entitățile financiare acoperite, DORA funcționează ca drept sectorial specific al UE pentru domeniile relevante din NIS2. Nu duplicați automat ambele seturi de controale.

Construiți evidența în jurul dependenței

Porniți de la serviciu, nu de la chestionarul pentru furnizori. Un singur furnizor poate oferi mai multe servicii, cu date, accese și importanță operațională diferite.

Ca bază practică, consemnați:

• Serviciul, entitatea juridică a furnizorului, responsabilul de business, responsabilul tehnic și evaluatorii.
• Funcțiile, sistemele, integrările și accesul privilegiat susținute.
• Categoriile de date cu caracter personal, scopurile prelucrării, locațiile și subcontractanții.
• Cerințele de disponibilitate, obiectivele de recuperare și perturbarea tolerabilă.
• Furnizorii subiacenți, dependențele contractuale și alternativele realiste.
• Obligațiile aplicabile, datele dovezilor, lacunele nerezolvate și deciziile.

Identificați ce funcții ar eșua sau s-ar degrada după o compromitere sau o întrerupere. Un furnizor care stochează puține date sensibile poate controla totuși autentificarea sau pipeline-urile de implementare. Invers, un serviciu cu risc scăzut privind disponibilitatea poate expune date cu caracter personal foarte sensibile.

Păstrați aceste dimensiuni separate, în loc să le comprimați într-un singur scor neexplicat de „risc ridicat”. Pentru entitățile financiare acoperite de DORA, legați acest inventar operațional de registrul de informații obligatoriu privind aranjamentele contractuale TIC; o listă generică de furnizori nu este neapărat suficientă.

Reutilizați dovezile fără a reutiliza orbește concluziile

Un raport de securitate, o hartă a fluxurilor de date sau un test de recuperare pot sprijini mai multe revizuiri. Verificați domeniul serviciului, perioada de raportare, excluderile, excepțiile și responsabilitățile clientului înainte de a vă baza pe ele.

De exemplu, un raport care acoperă infrastructura furnizorului nu acoperă neapărat accesul personalului său de suport la înregistrările clienților. O politică de backup documentată nu arată că restaurarea respectă cerințele de recuperare ale aplicației dumneavoastră.

Mențineți o matrice dovezi–întrebări:

Un certificat ISO sau un raport SOC 2 sprijină asigurarea în limitele domeniului său; niciunul nu stabilește conformitatea cu RGPD sau NIS2. Păstrați raționamentul evaluatorului, nu doar documentul încărcat. Evaluarea asigurărilor de securitate ar trebui să fie o revizuire tehnică repetabilă, nu o verificare a insignelor.

Traduceți cerințele în contracte și controale

În temeiul articolului 28 din RGPD, clauzele pentru persoana împuternicită trebuie să trateze obiectul, durata, natura și scopul prelucrării, tipurile de date și categoriile de persoane. Ele acoperă, de asemenea, instrucțiunile documentate, confidențialitatea, securitatea, condițiile privind subcontractanții, asistența, ștergerea sau returnarea, precum și obligațiile de informare și audit. Transferurile internaționale necesită o evaluare separată în temeiul capitolului V; găzduirea în UE singură nu tranșează chestiunile privind accesul sau transferurile ulterioare.

Articolul 21 din NIS2 include securitatea lanțului de aprovizionare și luarea în considerare a vulnerabilităților și practicilor de securitate cibernetică ale furnizorilor direcți. Așteptările contractuale practice pot include restricții de acces, tratarea vulnerabilităților, cooperarea în caz de incident și furnizarea de dovezi. Adaptați-le serviciului și cerințelor naționale, în loc să tratați un singur pachet universal de clauze ca fiind suficient din punct de vedere juridic.

Articolul 30 din DORA precizează dispozițiile contractuale TIC, cu cerințe suplimentare pentru serviciile care susțin funcții critice sau importante. Analizați descrierile serviciilor, locațiile, protecția și recuperarea datelor, asistența, rezilierea și drepturile de supraveghere relevante. Aceste funcții critice sau importante necesită o atenție deosebită acordată nivelurilor de serviciu, raportării, măsurilor de contingență, cooperării la testare, drepturilor de audit și aranjamentelor de tranziție.

Verificați apoi implementarea. Dacă un contract promite acces administrativ restricționat, obțineți dovezi ale separării rolurilor, autentificării, aprobării și jurnalizării. Dacă promite ștergerea, stabiliți ce se întâmplă cu backupurile și cu înregistrările păstrate. Atribuiți lacunele juridice și pe cele tehnice evaluatorilor potriviți.

Proiectați predările din incidente înainte de un incident

Politica de răspuns la incidente a unui furnizor poate sprijini o evaluare de securitate, lăsând totuși nerezolvate obligațiile de notificare. Precizați canalele de contact, acoperirea escaladării, informațiile inițiale, așteptările privind actualizările și responsabilitatea pentru păstrarea dovezilor.

În temeiul articolelor 33–34 din RGPD, persoana împuternicită notifică operatorul fără întârzieri nejustificate. Operatorul evaluează notificarea către autoritatea de supraveghere fără întârzieri nejustificate și, dacă este posibil, în termen de 72 de ore de la luarea la cunoștință, cu excepția cazului în care încălcarea nu este susceptibilă să genereze un risc pentru drepturile și libertățile persoanelor. Un risc ridicat poate impune informarea persoanelor, sub rezerva unor excepții. Consemnați raționamentul atunci când notificarea nu este necesară.

Etapele de raportare la nivelul UE prevăzute de NIS2 pentru incidentele semnificative includ o avertizare timpurie în 24 de ore, o notificare în 72 de ore și, în general, un raport final în termen de o lună de la notificare; verificați normele naționale și sectoriale. DORA are propriul cadru de raportare pentru incidentele majore legate de TIC. Nu înlocuiți aceste evaluări cu un singur indicator de „încălcare” pentru furnizor.

Ca recomandare practică, exersați un incident la un furnizor folosind informații incomplete. Testați dacă echipele pot stabili serviciile afectate, expunerea, impactul operațional și deciziile de raportare fără a aștepta un raport final privind cauza principală.

Exemplu practic: un serviciu, trei căi de revizuire

Să presupunem, cu titlu ilustrativ, că o entitate financiară acoperită folosește o platformă găzduită de suport pentru clienți care prelucrează date cu caracter personal și susține o funcție pe care entitatea a clasificat-o drept critică sau importantă în temeiul DORA.

Furnizorul pune la dispoziție un raport de asigurare, o politică privind incidentele și un rezumat al testului de recuperare. Securitatea constată că controalele de acces administrativ sunt dovedite, dar testul de recuperare exclude integrarea clientului.

Protecția datelor identifică separat un proces neclar de modificare a subcontractanților și aranjamente nerezolvate privind transferurile pentru accesul de la distanță. Revizuirea DORA constată că asistența pentru tranziție și dispozițiile relevante privind auditul necesită atenție.

Planul de acțiune rezultat este concret:

• Responsabilul tehnic testează recuperarea integrării și documentează rezultatul.
• Evaluatorul pentru protecția datelor rezolvă întrebările privind subcontractanții și transferurile.
• Departamentele juridic și de achiziții tratează lacunele contractuale.
• Responsabilul care răspunde decide dacă utilizarea temporară este acceptabilă, cu condiții și o dată de revizuire.

Dovezile sunt reutilizate, dar niciuna dintre cele trei concluzii nu este dedusă din alta. O revizuire de securitate trecută cu succes nu închide lacunele privind protecția datelor sau reziliența.

Monitorizați modificările, concentrarea și o ieșire executabilă

Stabiliți frecvența revizuirilor în funcție de dependență și de risc. Declanșați revizuiri suplimentare după incidente, modificări majore ale serviciului, subcontractanți noi, schimbări ale locației datelor, schimbări de proprietate sau reînnoirea contractului.

Priviți dincolo de numele furnizorilor: mai multe servicii pot depinde de aceeași regiune cloud, același furnizor de identitate sau același subcontractant. Evaluați perturbările corelate și dacă alternativa propusă are aceeași dependență. Articolul 29 din DORA vizează în mod explicit evaluarea riscului de concentrare TIC.

Mențineți un plan de ieșire proporțional care acoperă exportul datelor, migrarea, continuitatea, revocarea accesului și dovezile ștergerii. Testați utilizabilitatea exportului și identificați cine poate opera înlocuitorul. Un drept de reziliere este mai util atunci când organizația îl poate exercita efectiv.

Și consecințele diferă. RGPD are niveluri de sancțiuni specifice încălcărilor; NIS2 impune regimuri naționale de sancțiuni, cu plafoane diferite pentru entitățile esențiale și cele importante. Sancțiunile DORA pentru entitățile financiare depind de aranjamentele aplicabile, în timp ce sancțiunile din cadrul supravegherii furnizorilor critici sunt distincte. Nu modelați expunerea folosind o singură presupusă amendă universală.

Începeți cu o singură dependență cu consecințe

Alegeți un furnizor care susține o funcție importantă. Reconciliați inventarul serviciilor sale, contractele, dovezile, riscurile deschise și ipotezele de ieșire. Încheiați cu responsabili desemnați și concluzii separate, datate, pentru fiecare obligație aplicabilă.

În Secani, echipele pot modela serviciul și furnizorul extern, pot lega cerințele și controalele de dovezi și pot urmări lacunele ca sarcini cu responsabili. Deciziile revizuite de oameni, linkurile către surse, comentariile și marcajele temporale păstrează raționamentul. Astfel se sprijină un context comun al furnizorului fără a ascunde judecățile distincte privind protecția datelor, securitatea și reziliența.