Contracte NIS2 cu furnizorii, susținute de dovezi ISO 27001

Este ora 07:40 într-o zi de luni. CISO-ul unei platforme logistice care utilizează servicii cloud deschide un e-mail de la un furnizor de servicii managed detection and response. Mesajul este scurt, prudent și inconfortabil: furnizorul a detectat acces suspect la un mediu de suport utilizat de mai mulți clienți. Detaliile sunt limitate. Furnizorul promite o actualizare „cât mai curând posibil”.
La 08:15, managerul de conformitate întreabă dacă situația ar putea declanșa raportarea conform NIS2. La 08:40, departamentul de achiziții caută contractul. La 09:10, secretarul organului de conducere solicită o informare privind răspunderea managementului. La 10:00, departamentul juridic întreabă dacă acordul include notificare în 24 de ore, drepturi de audit, controale pentru subcontractanți, acces la dovezi, obligații privind continuitatea activității, returnarea datelor și prevederi privind ștergerea.
Nimeni nu vrea să descopere în timpul unui incident activ că acordul cu un furnizor critic menționează doar „măsuri rezonabile de securitate”.
În acest punct, clauzele contractuale NIS2 cu furnizorii încetează să mai fie formulări juridice standard și devin controale operaționale. Pentru entitățile esențiale și importante, guvernanța furnizorilor face acum parte din responsabilitatea organului de conducere, dovezile pentru autoritatea de supraveghere, pregătirea pentru incidente, asigurarea solicitată de clienți, conformitatea privind protecția datelor și planificarea rezilienței. Un contract semnat nu este suficient. Organizația trebuie să demonstreze că riscurile asociate furnizorilor sunt identificate, aprobate, tratate, monitorizate și susținute prin dovezi.
Abordarea Clarysec pornește de la un principiu simplu: dacă o clauză privind furnizorul nu poate fi monitorizată, dovedită și testată, nu este un control.
Zenith Blueprint: Foaia de parcurs în 30 de pași pentru auditori poziționează relațiile cu furnizorii în faza Controale în acțiune, Pasul 23, unde acordurile, monitorizarea, integrarea, reevaluarea și dovezile de audit sunt transformate în activități practice ale SMSI. Zenith Controls: Ghidul de corelare a cerințelor de conformitate între cadre corelează apoi controalele ISO/IEC 27002:2022 privind furnizorii cu NIS2, DORA, GDPR, NIST, COBIT 2019, standarde ISO suport și metodologii de audit.
Rezultatul este un model de guvernanță a furnizorilor pe care îl pot utiliza achizițiile, departamentul juridic, securitatea, protecția datelor și organul de conducere.
De ce NIS2 transformă contractele cu furnizorii în înregistrări probante
NIS2 Article 20 impune organelor de conducere ale entităților esențiale și importante să aprobe măsurile de management al riscurilor de securitate cibernetică, să supravegheze implementarea acestora și să răspundă pentru încălcări. Article 21 impune măsuri tehnice, operaționale și organizaționale adecvate și proporționale, inclusiv analiza riscului, gestionarea incidentelor, continuitatea activității, securitatea lanțului de aprovizionare, achiziția și mentenanța securizate, evaluarea eficacității, igiena cibernetică, criptografia, securitatea resurselor umane, controlul accesului, managementul activelor și MFA, după caz.
Article 21(3) explicitează verificarea prealabilă a furnizorilor. Organizațiile trebuie să ia în considerare vulnerabilitățile specifice furnizorilor direcți și furnizorilor de servicii, calitatea generală a produselor și a practicilor de securitate cibernetică, precum și procedurile de dezvoltare securizată.
Această formulare creează o obligație practică: relațiile cu furnizorii trebuie să fie bazate pe risc, aplicabile contractual și revizuibile. Un chestionar de furnizor salvat într-un folder nu este suficient. Un contract generic fără termen de notificare a incidentelor, fără drepturi de acces la dovezi și fără vizibilitate asupra subcontractanților nu este suficient. O certificare a furnizorului pe care nu a revizuit-o nimeni nu este suficientă.
ISO/IEC 27001:2022 oferă modelul operațional. Clauzele 4.1-4.4 impun organizației să înțeleagă contextul, părțile interesate, obligațiile legale și contractuale, domeniul de aplicare al SMSI și dependențele. Clauzele 5.1-5.3 impun leadership, politică, roluri și raportare. Clauzele 6.1.1-6.1.3 impun evaluarea riscurilor, tratarea riscurilor și Declarația de aplicabilitate. Clauzele 8.1-8.3 impun control operațional, evaluări repetate ale riscurilor și rezultate documentate.
Pentru guvernanța furnizorilor, cele mai importante controale din Anexa A ISO/IEC 27002:2022 includ:
- A.5.19 Securitatea informației în relațiile cu furnizorii
- A.5.20 Tratarea securității informației în acordurile cu furnizorii
- A.5.21 Managementul securității informației în lanțul de aprovizionare TIC
- A.5.22 Monitorizarea, revizuirea și managementul schimbărilor serviciilor furnizorilor
- A.5.24 Planificarea și pregătirea managementului incidentelor
- A.5.25 Evaluarea și decizia privind evenimentele de securitate a informației
- A.5.26 Răspunsul la incidente de securitate a informației
- A.5.27 Învățarea din incidente de securitate a informației
- A.5.28 Colectarea dovezilor
- A.5.29 Securitatea informației pe durata întreruperilor
- A.5.30 Pregătirea TIC pentru continuitatea activității
- A.5.31 Cerințe legale, statutare, de reglementare și contractuale
- A.5.34 Confidențialitatea și protecția PII
- A.8.8 Managementul vulnerabilităților tehnice
- A.8.13 Backup-ul informațiilor
- A.8.15 Jurnalizare
- A.8.16 Activități de monitorizare
- A.8.24 Utilizarea criptografiei
- A.8.32 Managementul schimbărilor
Elementul esențial este asumarea responsabilității. O clauză are valoare redusă dacă nimeni nu deține riscul, nimeni nu revizuiește dovezile, nimeni nu urmărește excepțiile și nimeni nu escaladează neconformitatea.
Politica Enterprise Politica de securitate privind terții și furnizorii precizează explicit acest lucru:
„Drepturi de audit, inspecție și solicitare a dovezilor de securitate”
Din secțiunea „Cerințe de guvernanță”, clauza de politică 5.3.4.
Pentru IMM-uri, Politica de securitate privind terții și furnizorii pentru IMM-uri stabilește aceeași așteptare practică:
„Drepturi de audit sau disponibilitatea dovezilor de conformitate”
Din secțiunea „Cerințe de guvernanță”, clauza de politică 5.3.4.
Această distincție contează. O organizație mai mică poate să nu poată audita la fața locului fiecare furnizor cloud major, dar poate solicita acces la dovezi de asigurare, cum ar fi domeniul certificării ISO/IEC 27001:2022, rapoarte SOC, sinteze ale testelor de penetrare, atestări privind remedierea vulnerabilităților, sinteze ale incidentelor, rapoarte ale testelor de continuitate a activității și confirmări privind ștergerea datelor.
Coloana vertebrală cu trei controale a asigurării furnizorilor conform NIS2
În modelul Clarysec de corelare a cerințelor de conformitate între cadre, trei controale ISO/IEC 27002:2022 formează coloana vertebrală a guvernanței furnizorilor conform NIS2: 5.19, 5.20 și 5.22.
A.5.19 identifică riscul asociat furnizorului
Controlul A.5.19, Securitatea informației în relațiile cu furnizorii, este fundamentul. Acesta impune organizațiilor să protejeze informațiile și activele accesate, prelucrate, stocate sau administrate de furnizori.
Zenith Controls îl clasifică drept control preventiv care acoperă confidențialitatea, integritatea și disponibilitatea, cu conceptul de securitate cibernetică „Identificare” și capabilitatea operațională „Securitatea relațiilor cu furnizorii”. Acesta conectează A.5.19 cu A.5.20, A.5.21, A.5.14, A.5.36 și A.5.10. În termeni practici, organizația identifică riscul asociat furnizorilor, definește așteptările de securitate, controlează expunerea lanțului de aprovizionare TIC, protejează transferul de informații, monitorizează conformitatea și extinde obligațiile privind utilizarea acceptabilă către părți externe.
Pentru NIS2, acest lucru se corelează direct cu Article 21(2)(d) privind securitatea lanțului de aprovizionare și cu Article 21(3) privind verificarea prealabilă a furnizorilor. Pentru GDPR, susține cerința de a utiliza persoane împuternicite de operator care oferă garanții suficiente. Pentru DORA, susține managementul riscului asociat terților TIC, verificarea prealabilă precontractuală, revizuirea criticității, riscul de concentrare și supravegherea pe întregul ciclu de viață.
A.5.20 transformă cerința într-o obligație executorie
Controlul A.5.20, Tratarea securității informației în acordurile cu furnizorii, transformă așteptările de securitate în obligații contractuale. Zenith Controls explică în mod clar relația dintre A.5.19 și A.5.20:
„5.20 reprezintă formalizarea contractuală a nevoilor și riscurilor de securitate identificate în cadrul 5.19. În timp ce 5.19 presupune evaluarea riscurilor asociate terților și definirea așteptărilor de securitate, 5.20 asigură caracterul obligatoriu al acestor așteptări prin contracte sau acorduri privind nivelul de serviciu (SLA). Fără 5.20, măsurile de securitate identificate în 5.19 nu ar avea caracter aplicabil.”
Aici deciziile privind riscul NIS2 devin clauze: notificarea încălcării securității datelor, drepturi de audit și de acces la dovezi, criptare, controlul accesului, managementul vulnerabilităților, aprobarea subcontractanților, transfer securizat, continuitate, cooperare cu autoritățile de reglementare, suport pentru ieșire și ștergerea datelor.
A.5.22 dovedește că acordul este activ
Controlul A.5.22, Monitorizarea, revizuirea și managementul schimbărilor serviciilor furnizorilor, împiedică transformarea asigurării privind furnizorii într-un exercițiu unic de integrare. Zenith Controls leagă A.5.22 de A.5.19 și A.5.20, dar și de A.5.29 privind securitatea informației pe durata întreruperilor, A.8.8 managementul vulnerabilităților tehnice, A.5.36 conformitatea cu politicile, regulile și standardele pentru securitatea informației, A.5.15 controlul accesului și A.8.27 arhitectura securizată a sistemelor și principiile de inginerie.
Acest lucru contează deoarece serviciile furnizorilor se schimbă. Locațiile datelor se schimbă. Persoanele subîmputernicite se schimbă. Apar vulnerabilități. Certificările expiră. Apar tipare ale incidentelor. Un furnizor care era acceptabil anul trecut poate fi prea riscant astăzi.
Ce ar trebui să includă clauzele contractuale NIS2 cu furnizorii
Zenith Blueprint, faza Controale în acțiune, Pasul 23, oferă un set practic de arii pentru acordurile cu furnizorii:
„Ariile-cheie tratate în mod obișnuit în acordurile cu furnizorii includ:
✓ Obligații de confidențialitate, inclusiv domeniu, durată și restricții privind divulgarea către terți; ✓ Responsabilități privind controlul accesului, cum ar fi cine poate accesa datele dvs., modul în care sunt gestionate credențialele și ce monitorizare este implementată; ✓ Măsuri tehnice și organizatorice pentru protecția datelor, criptare, transmitere securizată, backup și angajamente de disponibilitate; ✓ Termene și protocoale de raportare a incidentelor, adesea cu intervale definite (de exemplu, „notificare în termen de 24 de ore”); ✓ Drept de audit, inclusiv frecvență, domeniu și acces la dovezi relevante (de exemplu, rapoarte de teste de penetrare, SoA, certificări); ✓ Controale pentru subcontractanți, prin care furnizorul este obligat să transmită obligații de securitate echivalente partenerilor săi din aval; ✓ Prevederi la încetarea contractului, cum ar fi returnarea sau distrugerea datelor, recuperarea activelor și dezactivarea conturilor.”
Din faza Controale în acțiune, Pasul 23: controale organizaționale.
O clauză NIS2 solidă privind furnizorii este suficient de specifică pentru a fi testată. „Furnizorul trebuie să mențină o securitate adecvată” este slab. „Furnizorul trebuie să notifice contactul de securitate al clientului în termen de 24 de ore cu privire la incidente confirmate sau suspectate care afectează sistemele clientului, datele clientului, disponibilitatea serviciului sau obligațiile de raportare de reglementare” este verificabil.
| Aria clauzei | Scop NIS2 | Ancoră ISO/IEC 27001:2022 și ISO/IEC 27002:2022 | Dovezi de asigurare |
|---|---|---|---|
| Bază de referință pentru securitatea furnizorului | Demonstrează practici adecvate de securitate cibernetică înainte de integrare | Clauzele 6.1.2, 6.1.3, 8.1, Anexa A 5.19 și 5.20 | Evaluarea riscurilor furnizorului, chestionar de securitate, domeniul certificării, atestare privind controalele, plan de remediere |
| Notificarea incidentelor | Susține avertizarea timpurie, notificarea, evaluarea impactului și raportarea finală | Anexa A 5.24, 5.25, 5.26, 5.27, 5.28 și 5.20 | Clauză privind incidentele, matrice de escaladare, model de raport de incident, înregistrare a testului de notificare |
| Drepturi de audit și de acces la dovezi | Permit solicitări de dovezi din partea autorităților de supraveghere, auditului intern, clienților și auditorilor de certificare | Anexa A 5.20, 5.22, 5.36 | Clauză privind dreptul de audit, raport SOC, domeniul certificatului ISO/IEC 27001:2022, sinteză a testului de penetrare, registru de urmărire a problemelor |
| Obligații transmise în lanț către subcontractanți | Tratează riscul asociat părților de nivel patru și lanțurile de dependență față de furnizori | Anexa A 5.19, 5.20, 5.21, 5.22 | Listă de persoane subîmputernicite, proces de aprobare a subcontractanților, clauză de transmitere în lanț a obligațiilor, dovezi de notificare a schimbărilor |
| Controlul accesului și MFA | Controlează accesul furnizorului la sisteme, portaluri de suport, API-uri și date | Anexa A 5.15, 5.16, 5.17, 5.18, 8.5 | Inventar al conturilor furnizorului, revizuirea drepturilor de acces, dovezi MFA, jurnale de acces privilegiat, listă de verificare la încetarea accesului |
| Cooperare privind vulnerabilitățile și patch-urile | Susține managementul vulnerabilităților, mentenanța securizată și remedierea coordonată | Anexa A 8.8, 8.9, 8.25, 8.28, 8.29, 5.22 | SLA privind vulnerabilitățile, rapoarte privind patch-urile, informări de securitate, aprobări ale excepțiilor, dovezi de remediere |
| Continuitate și recuperare | Reduce întreruperile operaționale și riscul de dependență față de furnizori | Anexa A 5.29, 5.30, 8.13 | Sinteză BCP, raport de test DR, angajamente RTO și RPO, dovezi ale testelor de backup |
| Protecția datelor și transfer securizat | Protejează confidențialitatea, integritatea, disponibilitatea și viața privată în prelucrarea de către furnizor | Anexa A 5.14, 5.31, 5.34, 8.24 | Acord de prelucrare a datelor (DPA), înregistrări de transfer, standarde de criptare, cartografierea fluxului de date |
| Ieșire și returnarea datelor | Evită dependența de furnizor, drepturile de acces reziduale și datele orfane după încetare | Anexa A 5.11, 5.20, 5.22 | Plan de ieșire, certificat de ștergere a datelor, înregistrare privind returnarea activelor, dovezi de revocare a accesului |
Clauzele privind incidentele trebuie să corespundă termenelor de raportare NIS2
NIS2 Article 23 creează un model etapizat de raportare pentru incidente semnificative: o avertizare timpurie în termen de 24 de ore de la luarea la cunoștință, o notificare a incidentului în termen de 72 de ore, rapoarte intermediare atunci când sunt solicitate și un raport final în termen de o lună de la notificarea incidentului. Un incident semnificativ este cel care a cauzat sau este capabil să cauzeze perturbări operaționale grave, pierderi financiare ori prejudicii materiale sau nemateriale considerabile altor persoane.
Contractele cu furnizorii trebuie să susțină această cronologie. Dacă unui furnizor critic de servicii administrate îi ia patru zile să confirme dacă mediile clienților au fost afectate, clientul își poate rata propria fereastră de raportare de reglementare.
Politica Enterprise Politica de securitate privind terții și furnizorii impune:
„Termene de notificare a încălcării securității datelor (de exemplu, în termen de 24 sau 72 de ore, în funcție de criticitate și de cerințele de reglementare)”
Din secțiunea „Cerințe de guvernanță”, clauza de politică 5.3.3.
Politica pentru IMM-uri Politica de securitate privind terții și furnizorii pentru IMM-uri impune, de asemenea, termene definite de notificare a încălcării securității datelor în secțiunea „Cerințe de guvernanță”, clauza de politică 5.3.3.
Pentru incidentele care implică PII, politica Enterprise Politica de management al incidentelor și încălcărilor privind PII conectează raportarea de securitate cibernetică, sectorială financiară, către clienți și către destinatarii serviciului:
„[Condițional] Responsabilul pentru protecția datelor / Managerul PIMS TREBUIE să coordoneze orice raportare necesară privind incidentele sectoriale, de securitate cibernetică, din sectorul financiar, către clienți sau către destinatarii serviciului atunci când un incident PII cu impact ridicat atinge un prag de raportare aplicabil și TREBUIE să înregistreze autoritatea, destinatarul, termenul, transmiterea și dovezile de confirmare în REG01 și REG10.”
Din secțiunea „Notificare și comunicări”, clauza de politică 4.4.6.
Aceasta este dovadă NIS2 matură: nu doar un e-mail de notificare, ci o înregistrare a autorității, destinatarului, termenului, transmiterii, confirmării, impactului, cauzei principale și acțiunilor ulterioare.
Aliniere cu protecția datelor și DORA fără programe duplicate pentru furnizori
Mulți furnizori NIS2 prelucrează și date cu caracter personal. GDPR Article 28 impune operatorilor să utilizeze persoane împuternicite de operator care oferă garanții suficiente și să definească obligațiile persoanei împuternicite într-un contract scris. GDPR Article 5 impune responsabilitate pentru prelucrarea securizată și legală. Obligațiile GDPR privind încălcările securității datelor impun, de asemenea, cooperare rapidă atunci când incidentele furnizorilor afectează date cu caracter personal.
Politica Enterprise Politica de management al protecției datelor privind persoanele împuternicite de operator, persoanele subîmputernicite și terții stabilește punctul de control pentru aprobare:
„[Ambele] Responsabilul de furnizori / achiziții TREBUIE să se asigure că toate contractele cu persoane împuternicite de operator și persoane subîmputernicite includ asistență privind protecția datelor, asigurare de securitate, interfață pentru incidente prin PII15, returnare sau ștergere prin PII10, corelare a transferului prin PII13 și cooperare privind auditul sau asigurarea înainte de aprobare.”
Din secțiunea „Controale privind contractele și instrucțiunile documentate”, clauza de politică 4.3.6.
Aceasta impune și revizuirea dovezilor înainte de aprobare:
„[Toți] Responsabilul securității informației TREBUIE să revizuiască dovezile de asigurare a securității pentru fiecare relație cu o persoană împuternicită de operator, persoană subîmputernicită sau terț care are acces la PII sau găzduiește PII înainte de aprobare și TREBUIE să înregistreze rezultatul în REG08 sau REG12.”
Din secțiunea „Verificare prealabilă și evaluarea riscurilor”, clauza de politică 4.2.2.
DORA adaugă un alt nivel atunci când furnizorul deservește o entitate financiară. DORA Articles 28-30 impun guvernanța terților TIC, registre ale contractelor de servicii TIC, verificare prealabilă bazată pe risc, evaluarea criticității, analiza riscului de concentrare, drepturi de audit și inspecție, drepturi de încetare, strategii de ieșire și prevederi contractuale obligatorii. Article 30 este deosebit de relevant, deoarece impune conținut contractual privind descrierea serviciilor, locațiile, protecția datelor, accesul și recuperarea, nivelurile serviciilor, asistența în incidente, cooperarea cu autoritățile, drepturile de audit, subcontractarea, măsurile de continuitate și asistența la tranziție.
Răspunsul practic nu constă în trei programe separate pentru furnizori, pentru NIS2, GDPR și DORA. Este un singur model armonizat de dovezi privind furnizorii, corelat între cadre.
| Perspectivă de conformitate | Ce trebuie să demonstreze programul pentru furnizori | Implementare Clarysec și ISO/IEC 27001:2022 |
|---|---|---|
| NIS2 | Măsuri de risc cibernetic aprobate de management, securitatea lanțului de aprovizionare, verificarea prealabilă a furnizorilor, gestionarea incidentelor, continuitate, controlul accesului, evaluarea eficacității | Context SMSI, tratarea riscului, SoA, A.5.19, A.5.20, A.5.21, A.5.22, A.5.24-A.5.30 |
| GDPR | Persoanele împuternicite de operator oferă garanții suficiente, contractele definesc obligațiile, iar securitatea și asistența privind încălcările securității datelor pot fi demonstrate | DPA, revizuirea dovezilor persoanei împuternicite de operator, registru PII, A.5.31, A.5.34, A.8.24, politici de protecție a datelor |
| DORA | Riscul asociat terților TIC este guvernat, înregistrat, monitorizat, controlat contractual, verificabil prin audit și pregătit pentru ieșire | Evaluarea criticității, registrul contractelor TIC, drepturi de audit, plan de ieșire, dovezi BCP, A.5.20 și A.5.22 |
| NIST CSF 2.0 | Cerințele privind furnizorii sunt guvernate, prioritizate, incluse în contracte, monitorizate și integrate în răspunsul la incidente și recuperare | GV.SC-01-GV.SC-10 corelate cu ciclul de viață al furnizorului, registru de dovezi, proceduri operaționale de răspuns |
| COBIT 2019 | Acordurile cu furnizorii, performanța, riscurile, incidentele și acțiunile corective sunt gestionate și revizuite | APO10 acorduri cu furnizorii și monitorizare, riscul asociat furnizorilor și supravegherea serviciilor în DSS, urmărirea problemelor |
NIST CSF 2.0 este util deoarece Funcția GOVERN impune înțelegerea dependențelor, obligațiilor legale, obligațiilor contractuale, apetitului la risc, politicilor, responsabilității și supravegherii. Categoria sa privind lanțul de aprovizionare, GV.SC, acoperă rolurile furnizorilor, criticitatea, cerințele contractuale, verificarea prealabilă, monitorizarea, includerea în incidente, monitorizarea ciclului de viață și prevederile de încheiere a relației.
Un flux de lucru Clarysec pentru integrarea unui furnizor critic
Presupunem că integrați un furnizor de servicii de securitate gestionate care va monitoriza telemetrie pentru endpoint-uri, va primi alerte care conțin identificatori de utilizator și va susține triajul incidentelor pentru o organizație aflată în domeniul de aplicare al NIS2.
Pasul 1: clasificați furnizorul
Înregistrați furnizorul în registrul furnizorilor cu descrierea serviciului, sistemele și datele accesate, implicarea PII, susținerea serviciilor esențiale sau importante, accesul privilegiat, țările de furnizare a serviciului, subcontractanții, dependențele de părți de nivel patru, ratingul de criticitate, deținătorul riscului, responsabilul de achiziții și revizorul de securitate a informației.
Acest lucru implementează clauzele ISO/IEC 27001:2022 4.2, 4.3, 6.1.2 și 8.1 prin conectarea cerințelor părților interesate, dependențelor, asumării riscului și controlului operațional.
Pasul 2: corelați riscul cu SoA
În Zenith Blueprint, faza Managementul riscurilor, Pasul 13, Clarysec recomandă corelarea reglementărilor în registrul de riscuri sau în SoA:
„Corelați reglementările: dacă anumite controale sunt implementate special pentru conformitatea cu GDPR, NIS2 sau DORA, puteți nota acest lucru fie în Registrul de riscuri (ca parte a justificării impactului riscului), fie în notele SoA.”
Din faza Managementul riscurilor, Pasul 13: Planificarea tratamentului riscurilor și Declarația de aplicabilitate.
Pentru MSSP, includeți cel puțin A.5.19, A.5.20, A.5.21, A.5.22, A.5.24-A.5.28, A.5.29, A.5.30, A.5.31, A.5.34, A.8.8, A.8.15, A.8.16 și A.8.24.
Pasul 3: impuneți clauze executorii
Utilizați o anexă de securitate pentru furnizori care impune notificare inițială a incidentelor în 24 de ore, actualizare detaliată în 72 de ore, raportare finală a incidentelor, MFA pentru acces privilegiat, conturi nominale de utilizator, controale pentru subcontractanți, transfer securizat, criptare, dovezi de asigurare, cooperare cu autoritățile de reglementare, dovezi BCP și DR, suport pentru ieșire, returnarea sau ștergerea datelor și revocarea accesului.
Politica Enterprise Politica de management al riscului de dependență față de furnizori oferă cerința privind continuitatea:
„Acolo unde este aplicabil, o cerință ca furnizorul să mențină propriile planuri de continuitate a activității (BCP/DRP) și planuri de gestionare a incidentelor, să le testeze și să ne furnizeze sinteze sau rapoarte de testare la cerere.”
Din secțiunea „Cerințe de implementare”, clauza de politică 6.8.4.
Pasul 4: construiți pachetul de dovezi de asigurare
Înainte de aprobare, solicitați acordul semnat, SLA-ul, anexa de securitate, domeniul certificării ISO/IEC 27001:2022 sau o asigurare echivalentă, raportul SOC acolo unde este disponibil, sinteza executivă a testului de penetrare, sinteza managementului vulnerabilităților, sinteza procedurii de răspuns la incidente, sinteza testului BCP sau DR, atestarea privind controlul accesului și MFA, lista subcontractanților, procedura de ștergere a datelor și de ieșire și DPA acolo unde se prelucrează PII.
Politica pentru IMM-uri Politica de securitate privind terții și furnizorii pentru IMM-uri face măsurabile dovezile contractuale de bază:
„Acorduri și SLA-uri semnate”
Din secțiunea „Aplicare și conformitate”, clauza de politică 8.3.2.1.
Aceasta identifică și dovezile recurente privind furnizorii:
„Certificări de securitate valabile sau dovezi actualizate privind controalele”
Din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.3.1.2.
Pentru verificarea prealabilă mai amplă a furnizorilor, Politica de audit și monitorizare a conformității prevede:
„Verificarea prealabilă a furnizorilor trebuie să includă revizuirea certificărilor (de exemplu, ISO 27001, SOC 2), a chestionarelor de securitate și a înregistrărilor privind incidentele.”
Pasul 5: monitorizați pe baza criticității
Politica Enterprise Politica de management al protecției datelor privind persoanele împuternicite de operator, persoanele subîmputernicite și terții impune monitorizare trimestrială pentru relațiile PII cu risc ridicat:
„[Toți] Responsabilul de furnizori / achiziții TREBUIE să monitorizeze trimestrial relațiile active cu persoane împuternicite de operator și persoane subîmputernicite cu risc ridicat și anual celelalte relații active cu persoane împuternicite de operator și persoane subîmputernicite pentru PII, în raport cu condițiile de verificare prealabilă, statutul contractului, statutul asigurării, problemele deschise și datele de revizuire din REG08.”
Din secțiunea „Monitorizare continuă, asistență, interfață de divulgare și ieșire”, clauza de politică 4.5.1.
Astfel devine real A.5.22. Revizuirea trebuie să stabilească dacă furnizorul rămâne în limitele apetitului la risc, dacă dovezile sunt actuale, dacă există probleme deschise, dacă au avut loc incidente și dacă schimbările serviciului necesită reevaluare.
Cum vor testa auditorii clauzele NIS2 privind furnizorii
Auditorii rareori încep prin a citi politica în mod izolat. Ei selectează eșantioane de furnizori și urmăresc lanțul de dovezi.
Un auditor ISO/IEC 27001:2022 va solicita inventarul furnizorilor, clasificarea de risc, criteriile privind furnizorii, înregistrările de verificare prealabilă, contractele, dovezile, corelarea SoA și istoricul monitorizării. Pentru Anexa A 5.20, auditorul va verifica dacă acordurile eșantionate conțin clauze executorii. Pentru Anexa A 5.22, auditorul va testa dacă rapoartele au fost revizuite, excepțiile au fost înregistrate și acțiunile au fost urmărite.
O autoritate competentă NIS2 se poate concentra pe măsura în care practicile de securitate cibernetică ale furnizorilor și procedurile de dezvoltare securizată au fost evaluate conform Article 21(3). Un revizor orientat spre DORA poate solicita intrări în registrul contractelor TIC, strategii de ieșire, analiza riscului de concentrare și prevederile obligatorii din Article 30. Un auditor de protecție a datelor poate testa contractele cu persoanele împuternicite de operator, obligațiile transmise în lanț către persoanele subîmputernicite, interfețele pentru încălcarea securității datelor și dovezile privind garanțiile suficiente.
| Perspectiva auditului | Test de audit probabil | Constatare frecventă |
|---|---|---|
| Auditor ISO/IEC 27001:2022 | Eșantionarea furnizorilor cu risc ridicat și compararea evaluării riscurilor, clauzelor contractuale, aplicabilității SoA și înregistrărilor de monitorizare | Controalele privind furnizorii sunt incluse în SoA, dar nu sunt susținute prin dovezi în contracte sau revizuiri |
| Audit SMSI în stil ISO/IEC 27007 | Interviuri cu achizițiile, juridicul, IT și proprietarii de servicii pentru verificarea funcționării fluxului de lucru | Revizuirea de securitate a fost ocolită pentru integrarea urgentă a unui furnizor |
| Auditor COBIT 2019 | Testarea managementului acordurilor cu furnizorii, monitorizării performanței și guvernanței acțiunilor corective | Contractul impune rapoarte trimestriale, dar nimeni nu le revizuiește sau escaladează |
| Auditor ISACA ITAF | Inspectarea calității dovezilor, a controalelor conturilor și a înregistrărilor de încetare | Conturile furnizorilor rămân active după încetarea contractului |
| Evaluator NIST | Verificarea controalelor pentru servicii de sisteme externe, a dovezilor de evaluare a furnizorilor și a monitorizării continue | Riscul asociat furnizorului a fost evaluat o singură dată și nu a mai fost actualizat după schimbarea serviciului |
| Auditor de protecție a datelor | Revizuirea contractelor cu persoanele împuternicite de operator, obligațiilor transmise în lanț către persoanele subîmputernicite, interfeței privind încălcarea securității datelor și dovezilor privind garanțiile suficiente | DPA există, dar dovezile de asigurare a securității nu au fost revizuite |
Politica Enterprise Politica de securitate și control al accesului pentru PII arată cum controlul accesului, vulnerabilitățile, configurația, monitorizarea și criptografia se corelează cu ISO/IEC 27001:2022:
„ISO/IEC 27001:2022 — Clauza 6.1.3; Clauza 8.1; controalele din Anexa A 8.1, 8.2, 8.3, 8.5, 8.8, 8.9, 8.15, 8.16, 8.20, 8.24. Abordate prin clauzele [4.1.1; 4.1.2; 4.2.1; 4.2.3; 4.3.2; 4.4.1; 4.4.2; 4.5.1; 4.5.2; 4.6.1; 4.6.3; 4.7.1; 4.7.4; 4.7.5; 4.8.1; 4.8.2; 7.1.1; 7.1.2].”
Din secțiunea „Standarde și cadre de referință”, clauza de politică 13.9.
Atunci când un furnizor are acces la PII, sisteme privilegiate sau date de monitorizare, dovezile privind controlul accesului nu sunt separate de asigurarea privind furnizorii. Ele fac parte din aceeași pistă de audit.
Capcana achizițiilor: contracte semnate fără operațiuni de asigurare
Cel mai frecvent eșec al guvernanței furnizorilor conform NIS2 nu este absența contractelor. Este decalajul dintre limbajul contractual și activitatea operațională zilnică.
Un contract poate impune sinteze anuale ale testelor de penetrare, dar niciun responsabil nu le solicită. Poate impune notificarea incidentelor în 24 de ore, dar furnizorul are doar o adresă generică de suport. Poate impune aprobarea subcontractanților, dar achizițiile nu primesc niciodată notificări de schimbare. Poate include drepturi de audit, dar organizația nu are un proces de evaluare a excepțiilor din rapoartele SOC. Poate impune ștergerea datelor la ieșire, dar IT nu validează niciodată dezactivarea conturilor.
Zenith Blueprint, faza Controale în acțiune, Pasul 23, explică modul în care controalele privind furnizorii devin operaționale:
„În practică, acest control devine operațional prin:
✓ evaluări de risc ale furnizorilor, ✓ chestionare de verificare prealabilă înainte de angajament, ✓ modele contractuale cu termeni de securitate integrați, ✓ liste de verificare pentru integrarea furnizorilor care includ alocarea accesului și configurarea monitorizării, ✓ reevaluări continue, mai ales atunci când domeniul furnizorului se schimbă, apar incidente sau se apropie reînnoirile.
Iar acest control nu se oprește la furnizorii de nivel unu. Furnizorul dvs. poate externaliza către propriii furnizori, iar riscul poate rămâne în continuare la dvs.”
Acesta este mesajul NIS2 pentru organul de conducere: externalizarea livrării serviciului nu externalizează responsabilitatea.
Listă de verificare pentru remedierea contractelor NIS2 cu furnizorii
Începeți cu primii 20 de furnizori după criticitate și derulați un exercițiu de remediere concentrat:
- Identificați furnizorii care susțin servicii esențiale sau importante.
- Confirmați dacă fiecare furnizor prelucrează PII, susține servicii reglementate sau are acces privilegiat.
- Desemnați un responsabil de business, un responsabil de achiziții și un revizor de securitate.
- Verificați dacă evaluarea riscurilor furnizorului este actuală și aliniată cu domeniul real al serviciului.
- Confirmați că acordul include cerințe de bază de securitate, notificarea incidentelor, drepturi de audit sau de acces la dovezi, controale pentru subcontractanți, continuitate, transfer securizat, controlul accesului, cooperare privind vulnerabilitățile și clauze de ieșire.
- Confirmați că termenele privind încălcarea securității datelor susțin necesitățile de escaladare în 24 de ore și 72 de ore, acolo unde este relevant.
- Solicitați dovezi de asigurare actualizate, inclusiv certificări, rapoarte SOC, sinteze ale testelor de penetrare, teste BCP sau DR și istoricul incidentelor.
- Revizuiți dovezile, nu doar le stocați.
- Înregistrați excepțiile și atribuiți responsabili pentru remediere.
- Actualizați SoA și registrul de riscuri acolo unde controalele privind furnizorii susțin NIS2, GDPR, DORA sau angajamentele față de clienți.
- Programați frecvența monitorizării în funcție de criticitatea furnizorului.
- Testați o cale de escaladare a unui incident al furnizorului.
- Testați o cale de încetare a relației cu un furnizor, inclusiv returnarea datelor, ștergerea, recuperarea activelor și revocarea accesului.
Dacă nu puteți demonstra aceste puncte pentru un furnizor critic, contractul nu este încă pregătit pentru audit.
Transformați clauzele privind furnizorii în dovezi pentru autoritatea de supraveghere
Guvernanța furnizorilor conform NIS2 este acum o disciplină operațională activă. Autoritățile de supraveghere, clienții, auditorii de certificare, echipele de protecție a datelor, partenerii din sectorul financiar și organele de conducere nu vor întreba doar dacă există clauze privind furnizorii. Vor întreba dacă aceste clauze sunt bazate pe risc, aplicabile, monitorizate, susținute prin dovezi și conectate la raportarea incidentelor, continuitate, controlul accesului, managementul vulnerabilităților, obligațiile transmise în lanț către subcontractanți și ieșire.
Clarysec ajută organizațiile să închidă acest decalaj prin Zenith Blueprint, care transformă controalele privind furnizorii în faze SMSI, tratarea riscului, intrări SoA, rutine de integrare și dovezi de audit. Zenith Controls corelează controalele ISO/IEC 27002:2022 privind furnizorii A.5.19, A.5.20 și A.5.22 cu NIS2, DORA, GDPR, NIST, COBIT 2019, standarde ISO suport și metodologii de audit. Politicile Clarysec privind furnizorii și protecția datelor oferă structura clauzelor, așteptările privind dovezile și rutinele de monitorizare care fac asigurarea privind furnizorii defensabilă.
Următoarea acțiune este simplă: selectați cinci furnizori critici, eșantionați-le contractele, corelați fiecare clauză cu tratarea riscului ISO/IEC 27001:2022 și cu controalele din Anexa A, solicitați dovezi de asigurare actuale și derulați un exercițiu de simulare pentru notificarea incidentelor în 24 de ore. Dacă lanțul de dovezi se întrerupe, seturile de instrumente Clarysec vă oferă structura necesară pentru a-l remedia înainte ca un incident, o revizuire din partea unui client sau o solicitare a autorității de supraveghere să o facă în locul dvs.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


