Guvernanța operatorilor asociați: ghid de audit pentru Articolul 26 din GDPR

Apelul a venit într-o dimineață de marți. Pentru CISO-ul de la CareConnect, un furnizor MedTech SaaS aflat în creștere rapidă, a fost momentul în care situația s-a schimbat fundamental.

La celălalt capăt al liniei era directorul de conformitate de la MetroHealth, principalul lor partener spitalicesc. Un pacient care utiliza platforma de monitorizare la distanță administrată în comun depusese cu o lună înainte o cerere de acces a persoanei vizate. Niciuna dintre organizații nu răspunsese complet. Fiecare considera că cealaltă era responsabilă.

Apoi departamentul juridic a redirecționat un al doilea mesaj. Un dezvoltator junior de la CareConnect expusese accidental un endpoint API necritic care includea identificatori limitați ai pacienților. Problema părea controlabilă, iar termenul de 72 de ore din GDPR pentru notificarea încălcării securității datelor cu caracter personal nu expirase încă. Dar aceeași întrebare a blocat ambele echipe.

Cine informează autoritatea de supraveghere? Cine comunică cu pacienții? Cine deține informarea privind confidențialitatea? Cine validează cererea persoanei vizate? Cine înregistrează decizia?

Acordul comercial era detaliat cu privire la creditele de serviciu, facturare, plafoanele de răspundere și etapele din foaia de parcurs a produsului. Era însă aproape tăcut în privința realității operaționale a guvernanței operatorilor asociați conform Articolului 26 din GDPR.

Aici eșuează multe parteneriate. Problema nu este că echipele de confidențialitate, juridic, securitate și achiziții nu au auzit niciodată expresia „acord între operatori asociați”. Problema este că nimeni nu poate demonstra, înainte de începerea prelucrării, cine este responsabil pentru transparență, temei juridic, drepturile persoanei vizate, escaladarea încălcărilor securității datelor cu caracter personal, obligații transmise în lanț către furnizori, transferuri, retenție, dovezi și comunicarea cu autoritățile de reglementare.

GDPR definește obligația. ISO/IEC 27701:2025 oferă echipelor de confidențialitate o structură de sistem de management. Politicile PIMS ale Clarysec, Zenith Blueprint: foaia de parcurs în 30 de pași a auditorului și Zenith Controls: ghidul de mapare a cerințelor de conformitate între cadre transformă Articolul 26 în dovezi operaționale pregătite pentru audit.

De ce eșuează guvernanța operatorilor asociați înainte ca cineva să observe

O relație de operatori asociați există atunci când două sau mai multe părți stabilesc împreună scopurile și mijloacele prelucrării datelor cu caracter personal. Declanșatorul nu este formularea din contract. Este autoritatea decizională.

În exemplul CareConnect și MetroHealth, CareConnect furnizează platforma, analiza datelor, arhitectura tehnică, interfața cu utilizatorul și fluxurile de date. MetroHealth furnizează relația cu pacientul, contextul clinic, modelul de serviciu și datele pacienților. Ambele influențează de ce sunt prelucrate datele cu caracter personal și cum funcționează prelucrarea. Acest lucru este foarte diferit de un furnizor care doar găzduiește o bază de date sau trimite mesaje pe baza unor instrucțiuni documentate.

Același tipar apare în campanii de educație financiară, parteneriate de asigurări integrate, piețe online, consorții de detectare a fraudei, platforme de sănătate conectată, programe de loialitate, ecosisteme de verificare a identității și colaborări de analiză a datelor. O bancă, un asigurător și o platformă SaaS pot decide împreună segmentele țintă, regulile de creare de profiluri, metricile de conversie și canalele de marketing. Un acord de prelucrare a datelor pentru o persoană împuternicită de operator nu va rezolva problema dacă părțile sunt, în realitate, operatori asociați.

Eșecurile practice sunt previzibile:

1. Informarea privind confidențialitatea spune puțin mai mult decât „putem partaja date cu parteneri”.
2. Inventarul activităților de prelucrare identifică părțile, dar nu alocarea obligațiilor.
3. Fluxul pentru drepturile persoanelor vizate nu are o rută pentru transmiterea, validarea sau soluționarea cererilor.
4. Planul de incidente spune „notificați departamentul juridic”, dar nu indică ce operator asociat conduce comunicarea externă.
5. Contractul este tratat ca documentație comercială, nu ca dovadă de responsabilitate.
6. Prevederile de încetare nu acoperă returnarea datelor, ștergerea, anonimizarea, eliminarea accesului sau păstrarea dovezilor.

Articolul 5 din GDPR face aceste eșecuri sensibile din perspectiva auditului, deoarece operatorii nu trebuie doar să respecte principii precum legalitatea, echitatea, transparența, limitarea scopului, minimizarea, exactitatea, limitarea stocării, integritatea, confidențialitatea și responsabilitatea. Ei trebuie să poată demonstra conformitatea. Articolul 6 adaugă cerința privind temeiul juridic. Articolul 3 poate aduce în domeniul de aplicare furnizori SaaS, fintech, health-tech și de analiză a datelor din afara UE atunci când oferă servicii persoanelor din UE sau le monitorizează comportamentul.

Lecția pentru CISO și managerii de conformitate este directă: guvernanța operatorilor asociați nu este „doar juridic”. Este un sistem de control interfuncțional care implică protecția datelor, securitatea, achizițiile, produsul, ingineria, suportul, răspunsul la incidente, marketingul și supravegherea executivă.

Principiul PIMS din ISO/IEC 27701:2025: decideți înainte de începerea prelucrării

Un Sistem de management al informațiilor privind confidențialitatea conform ISO/IEC 27701:2025 funcționează doar dacă rolurile de confidențialitate sunt stabilite înainte de începerea prelucrării. Aceasta este disciplina operațională care împiedică Articolul 26 să devină un exercițiu de reconstrucție post-incident.

Politica privind Sistemul de management al informațiilor privind confidențialitatea a Clarysec, clauza 4.2.2, prevede:

[Operator asociat] Responsabilul relației cu furnizorul / responsabilul de achiziție TREBUIE să documenteze în REG08 alocarea responsabilităților între operatorii asociați înainte de începerea prelucrării comune.

Expresia „înainte de începerea prelucrării comune” este punctul de control. Aceasta înseamnă înainte ca integrarea platformei să intre în producție, înainte ca tabloul de bord partajat să fie activat, înainte ca sincronizarea CRM să înceapă, înainte ca audiențele de campanie să fie activate și înainte ca cererile persoanelor vizate să înceapă să sosească.

Obligația de inventariere suport apare în Politica privind inventarul prelucrărilor PII și temeiul juridic, clauza 4.3.5:

[Operator asociat] Responsabilul relației cu furnizorul / responsabilul de achiziție TREBUIE să înregistreze în REG02 și REG08 scopul prelucrării efectuate de operatorii asociați și referința alocării responsabilităților înainte de începerea prelucrării de către operatorii asociați.

Împreună, aceste clauze creează lanțul de dovezi pe care auditorii îl așteaptă:

• REG02 înregistrează activitatea de prelucrare, scopul, categoriile de date, temeiul juridic, retenția, sistemele, destinatarii, transferurile și referința privind operatorii asociați.
• REG08 înregistrează acordul între operatori asociați și alocarea responsabilităților.
• REG07 înregistrează rezumatul de transparență destinat publicului.
• REG06 poate înregistra primirea cererilor de exercitare a drepturilor persoanelor vizate, rutarea, validarea, termenele-limită și dovezile răspunsului.
• REG10 înregistrează deciziile privind incidentele și evaluarea încălcării securității datelor cu caracter personal.

Acest lanț transformă Articolul 26 dintr-o declarație juridică într-un proces de sistem de management.

Începeți cu domeniul de aplicare, părțile interesate și o matrice RACI

Zenith Blueprint începe cu domeniul de aplicare și părțile interesate deoarece guvernanța operatorilor asociați eșuează atunci când părțile interesate și cerințele sunt identificate prea târziu.

În faza de fundamentare și leadership SMSI, Pasul 2, Nevoile părților interesate și domeniul de aplicare al SMSI, Zenith Blueprint recomandă o analiză a părților interesate care surprinde cerințele explicite și implicite:

Cum se identifică nevoile și așteptările: Pentru fiecare grup de părți interesate identificat, listați ce solicită acestea
în raport cu securitatea informației. Unele cerințe sunt explicite (legi, contracte,
SLA-uri), în timp ce altele sunt implicite (așteptări sau bune practici generale). Este util să:

✓ Revizuiți cerințele legale și de reglementare aplicabile contextului dumneavoastră (din analiza
contextului de la Pasul 1). Întocmiți o listă de clauze sau obligații specifice legate de securitatea
informației sau de confidențialitate.
✓ Revizuiți contractele și acordurile: multe contracte comerciale includ anexe de confidențialitate sau
securitate. Extrageți aceste cerințe.
✓ Organizați interviuri sau ateliere cu părțile interesate: implicați reprezentanți ai
fiecărui grup (de exemplu, un manager HR pentru perspectiva angajaților, un manager de vânzări pentru
așteptările clienților) pentru a le înțelege preocupările sau nevoile.
✓ Luați în considerare standardele din industrie sau codurile de practică pe care părțile interesate se așteaptă să le
urmați.

Pentru un acord auditabil între operatori asociați conform Articolului 26 din GDPR, analiza părților interesate ar trebui să includă clienți, pacienți, utilizatori, autorități de supraveghere, celelalte părți care acționează ca operatori, persoane împuternicite de operator, persoane subîmputernicite, asigurători, furnizori cloud, departamente interne, autorități de reglementare și organe de conducere.

Pasul 4, Roluri și responsabilități în SMSI, transformă apoi această analiză în asumarea responsabilității. Zenith Blueprint evidențiază valoarea unui model RACI:

✓ Responsabilitate operațională vs. răspundere finală: un instrument util aici este o matrice RACI (Responsible,
Accountable, Consulted, Informed). Pentru fiecare proces sau control major al SMSI, identificați
cine este Responsible (execută activitatea), cine este Accountable (răspunde în ultimă instanță, adesea un
manager), cine este Consulted (oferă contribuții) și cine este Informed.

Pentru operatorii asociați, RACI nu este opțională în practică. Fără aceasta, departamentul juridic presupune că echipa de confidențialitate răspunde la cerere, echipa de confidențialitate presupune că Suportul are coada de primire, Suportul presupune că partenerul va răspunde, iar termenul legal continuă să curgă.

Modelul Clarysec de dovezi pentru operatorii asociați

Un acord matur între operatori asociați ar trebui să fie înțeles într-o pagină și demonstrat în zece minute. Scopul nu este să îngroape echipele în documentație juridică. Scopul este ca responsabilitățile să fie vizibile, acceptate și testabile.

Politicile de confidențialitate ale Clarysec consolidează fiecare nivel.

Politica privind informările privind confidențialitatea și transparența, clauza 4.1.5, prevede:

[Operator asociat] Responsabilul pentru confidențialitate / managerul PIMS TREBUIE să înregistreze în REG07 rezumatul public al responsabilităților operatorilor asociați și punctul de contact înainte de lansarea sau modificarea semnificativă a prelucrării efectuate de operatorii asociați.

Politica de management al drepturilor persoanelor vizate privind PII, clauza 6.1.5, prevede:

[Operator asociat] Responsabilul pentru confidențialitate / managerul PIMS TREBUIE să documenteze responsabilitățile de gestionare a drepturilor și rutele de contact în REG02, REG06 sau REG08 înainte de începerea prelucrării de către operatorii asociați.

Politica de management al incidentelor și încălcărilor securității PII, clauza 4.2.5, adaugă:

[Operator asociat] Responsabilul pentru confidențialitate / managerul PIMS TREBUIE să verifice responsabilitatea convenită privind încălcarea securității datelor, responsabilitatea principală de comunicare și aranjamentul de coordonare înainte de orice notificare sau comunicare externă realizată de un operator asociat și TREBUIE să înregistreze decizia în REG08 și REG10.

Acesta este punctul în care ISO/IEC 27701:2025 și GDPR devin operaționale. Organizația nu doar afirmă că responsabilitățile sunt alocate. Ea arată unde sunt înregistrate, cine le-a aprobat, când au fost testate și cum sunt utilizate.

Exemplu practic: REG08 pentru o platformă de monitorizare la distanță

Să presupunem că CareConnect și MetroHealth operează împreună o platformă de monitorizare la distanță. Ambele decid de ce sunt prelucrate datele pacienților, ce date sunt colectate, cum sunt configurate alertele de monitorizare, cum este utilizată analiza datelor și cum interacționează pacienții cu serviciul.

Mai întâi, REG02 ar trebui să înregistreze activitatea de prelucrare:

• Denumirea prelucrării: serviciu de monitorizare la distanță a pacienților
• Rolul operatorului: operator asociat
• Părți: CareConnect și MetroHealth
• Scop: monitorizarea pacienților, coordonarea îngrijirii, îmbunătățirea serviciului, analiza datelor platformei
• Categorii PII: date de contact, identificatori de cont, observații clinice, evenimente ale dispozitivelor, interacțiuni de suport
• Verificare categorie specială: sunt prelucrate date privind sănătatea și sunt necesare măsuri de protecție sporite
• Temei juridic: documentat pentru fiecare parte și scop
• Retenție: definită de cerințe clinice, de platformă, juridice și operaționale
• Sisteme: aplicație mobilă, platformă de monitorizare, instrument de suport, depozit analitic, furnizor de identitate
• Destinatari: părțile care acționează ca operatori asociați, furnizorul de găzduire, furnizorii de suport, furnizorii de notificări
• Transferuri: acces la distanță și prelucrări din afara SEE evaluate
• Referință REG08: JC-2026-004

În al doilea rând, REG08 ar trebui să aloce responsabilitatea într-un mod pe care operatorii îl pot urma.

În al treilea rând, REG07 ar trebui să înregistreze rezumatul destinat publicului. Informarea privind confidențialitatea ar trebui să explice esența acordului comun într-un limbaj clar, să identifice operatorii asociați, să descrie responsabilitățile fiecăruia și să ofere un punct de contact utilizabil. Nu ar trebui să oblige pacienții sau utilizatorii să descifreze complexitatea operațională internă.

În al patrulea rând, testați fluxul înainte de lansare. Trimiteți o cerere de acces simulată la punctul de contact publicat. Confirmați că Suportul o identifică drept cerere privind drepturile persoanei vizate, o direcționează către echipa de confidențialitate, verifică REG08, solicită contribuția partenerului, înregistrează acțiunile în REG06 și produce un pachet de răspuns. Apoi derulați un exercițiu de simulare privind încălcarea securității datelor folosind un scenariu precum „un endpoint API expune identificatori ai pacienților către utilizatori neautorizați” sau „utilizatorii pentru care ștergerea este suprimată sunt incluși accidental într-o campanie de interacțiune”.

Aceste teste scot la iveală lacunele reale: căsuțe poștale fără responsabil desemnat, SLA-uri neclare cu partenerii, text neaprobat pentru informările privind confidențialitatea, înregistrări incomplete privind temeiul juridic, verificări lipsă pentru categorii speciale și proceduri de incident care nu nominalizează responsabilul comunicării externe.

Mapați Articolul 26 la controalele ISO/IEC 27002:2022 prin Zenith Controls

Un acord între operatori asociați nu este doar un artefact juridic. El trebuie susținut de controale tehnice și organizatorice. Zenith Controls ajută echipele să mapeze așteptările privind controalele din ISO/IEC 27001:2022 și ISO/IEC 27002:2022 la dovezi privind confidențialitatea, furnizorii, incidentele, cloud-ul și guvernanța.

Trei controale ISO/IEC 27002:2022 sunt deosebit de relevante.

Controlul 5.2, roluri și responsabilități privind securitatea informației, susține modelul operațional. Acesta se conectează la clauza 5.3 din ISO/IEC 27001:2022, roluri, responsabilități și autorități organizaționale. Susține și pregătirea pentru incidente, deoarece rolurile neclare subminează Controlul 5.24 din ISO/IEC 27002:2022, planificarea și pregătirea managementului incidentelor de securitate a informației. În guvernanța operatorilor asociați, Controlul 5.2 este locul în care RACI, responsabilii REG08, responsabilii de gestionarea DSR, responsabilii pentru încălcări ale securității datelor cu caracter personal și contactele de escaladare devin dovezi de audit.

Controlul 5.31, cerințe legale, statutare, de reglementare și contractuale, este locul în care Articolul 26 din GDPR devine parte a SMSI, nu doar o problemă juridică. Acesta susține identificarea și gestionarea responsabilității prevăzute la Articolul 5 din GDPR, a temeiului juridic prevăzut la Articolul 6, a alocării responsabilităților prevăzute la Articolul 26, a securității prevăzute la Articolul 32, a notificării autorității de supraveghere prevăzute la Articolul 33 și a comunicării către persoanele afectate prevăzute la Articolul 34. De asemenea, se conectează la clauza 4.2 din ISO/IEC 27001:2022, înțelegerea nevoilor și așteptărilor părților interesate, și la clauza 6.1.3, tratamentul riscurilor de securitate a informației.

Controlul 5.34, confidențialitatea și protecția PII, aduce protecția PII în modelul operațional de securitate. Este deosebit de important atunci când acordul utilizează analiza datelor în cloud, tablouri de bord partajate, camere curate de date, platforme de monitorizare, automatizare de marketing sau instrumente de suport. Măsurile de protecție conexe pot include Controlul 5.23 din ISO/IEC 27002:2022, securitatea informației pentru utilizarea serviciilor cloud, și Controlul 8.11, Mascarea datelor.

Ecosistemul ISO de suport contează, de asemenea. ISO/IEC 27018 ajută acolo unde serviciile de cloud public prelucrează PII. ISO/IEC 29100 oferă principii de confidențialitate precum transparența, consimțământul, scopul legitim, limitarea colectării, minimizarea datelor, limitarea utilizării, exactitatea, măsurile de protecție de securitate și responsabilitatea. ISO/IEC 27001:2022 oferă fundamentul de sistem de management prin context, părți interesate, domeniu de aplicare, leadership, evaluarea riscurilor, tratamentul riscurilor, Declarație de aplicabilitate, audit intern, revizuire de management și îmbunătățire continuă.

Contractele trebuie să corespundă modelului operațional

Un acord între operatori asociați nu poate exista doar într-o informare privind confidențialitatea. El trebuie reflectat în contracte, anexe, proceduri operaționale, proceduri de incident, rute de escaladare și prevederi de încetare.

Politica de conformitate juridică și de reglementare a Clarysec, clauza 5.3.1.2, include explicit tipurile de contracte în guvernanță, inclusiv:

Contracte care implică partajarea datelor, drepturi de proprietate intelectuală, limitări ale răspunderii sau clauze de audit

Politica de protecție a datelor și confidențialitate, clauza 5.1, stabilește fundamentul la nivel de întreprindere:

Organizația trebuie să mențină un cadru formal de guvernanță a confidențialității integrat în Sistemul de management al securității informației (SMSI) pentru aplicarea acestei politici.

Pentru IMM-uri, același principiu este dimensionat la realitatea operațională. Politica de protecție a datelor și confidențialitate-sme - IMM, clauza 5.2.1, prevede:

Coordonatorul pentru confidențialitate trebuie să mențină un registru al tuturor activităților de prelucrare a datelor cu caracter personal, inclusiv categoriile de date, scopul, temeiul juridic și perioadele de retenție

Clauza 5.2.2 adaugă:

Contractele cu terți care gestionează date cu caracter personal trebuie să includă clauze de protecție a datelor și trebuie revizuite de directorul general sau de consilierul juridic

Aceasta este guvernanță proporțională. O multinațională poate avea echipe separate de juridic, confidențialitate, achiziții, securitate, risc și conformitate. Un IMM se poate baza pe un coordonator pentru confidențialitate, director general și consilier juridic extern. Așteptarea privind dovezile rămâne aceeași: activitățile de prelucrare, responsabilitățile, temeiul juridic, informările privind confidențialitatea, gestionarea drepturilor, escaladarea incidentelor și obligațiile la încetare trebuie documentate și verificabile.

Zenith Blueprint, Pasul 23, Controale organizaționale, susține disciplina acordurilor cu furnizorii prin confidențialitate, responsabilități de control al accesului, măsuri tehnice și organizatorice, termene de raportare a incidentelor, drepturi de audit, controale pentru subcontractanți și prevederi de final de contract. În relațiile dintre operatori asociați, aceste clauze ar trebui adaptate la partajarea datelor și alocarea responsabilităților, nu copiate dintr-un model pentru persoane împuternicite de operator.

Guvernanța incidentelor și a încălcărilor securității datelor: decideți responsabilul înainte de încălcare

Încălcările securității datelor cu caracter personal în relații de operatori asociați devin haotice atunci când echipele așteaptă incidentul pentru a decide cine comunică extern.

GDPR definește o încălcare a securității datelor cu caracter personal ca o încălcare a securității care duce, în mod accidental sau ilegal, la distrugerea, pierderea, modificarea, divulgarea neautorizată sau accesul neautorizat la date cu caracter personal. Atunci când este necesar, notificarea autorității de supraveghere trebuie efectuată fără întârzieri nejustificate și, dacă este posibil, în termen de 72 de ore de la momentul luării la cunoștință. NIS2 și DORA pot adăuga așteptări suplimentare privind raportarea incidentelor cibernetice și comunicarea cu clienții.

Politica de răspuns la incidente-sme - IMM a Clarysec, clauza 5.3.2, surprinde disciplina termenelor:

Termenele de răspuns, inclusiv recuperarea datelor și obligațiile de notificare, trebuie documentate și aliniate cu cerințele legale, cum ar fi cerința GDPR de notificare în 72 de ore a încălcării securității datelor cu caracter personal.

Zenith Blueprint, Pasul 5, Comunicare, conștientizare și competență, subliniază planificarea comunicării externe, inclusiv cu clienții, autoritățile de reglementare, partenerii și publicul. Pentru operatorii asociați, matricea de incidente ar trebui să identifice cine realizează clasificarea inițială a încălcării securității datelor cu caracter personal, cine contactează celălalt operator, cine determină dacă PII sunt afectate, cine evaluează pragurile de notificare, cine redactează notificările către autorități, cine comunică cu persoanele, cine coordonează raportarea NIS2 sau DORA, cine aprobă declarațiile publice și cine înregistrează dovezile în REG10.

Dacă acordul implică o entitate financiară sub incidența DORA, procesul de incident ar trebui să susțină și clasificarea incidentelor majore legate de TIC, escaladarea către conducerea superioară, actualizările intermediare, raportarea finală și comunicarea cu clienții atunci când interesele financiare sunt afectate. Dacă organizația intră în domeniul de aplicare al NIS2, raportarea incidentelor semnificative poate necesita notificare etapizată și comunicare cu destinatarii serviciilor.

Cea mai sigură practică este un exercițiu de simulare comun înainte de lansare. Un scenariu bun obligă echipele să utilizeze REG08, REG10, procedura de incident, contactele partenerilor, șabloanele de notificare, arborii de escaladare și jurnalele de dovezi sub presiunea timpului.

Maparea cerințelor între cadre: Articolul 26 rareori există izolat

Acordurile între operatori asociați se află adesea în ecosisteme reglementate mai ample. O campanie fintech, o platformă de sănătate conectată, o relație de servicii administrate, o integrare de marketplace cloud sau un parteneriat de infrastructură digitală poate declanșa obligații dincolo de GDPR.

NIS2 se poate aplica entităților esențiale sau importante mijlocii și mari din sectoare precum infrastructura digitală, cloud computing, centre de date, furnizori de servicii administrate, furnizori de servicii de securitate administrate, piețe online, motoare de căutare și platforme de socializare. Articolul 20 din NIS2 plasează supravegherea managementului riscurilor de securitate cibernetică la nivelul organelor de conducere. Articolul 21 impune măsuri tehnice, operaționale și organizatorice, inclusiv analiza riscurilor, gestionarea incidentelor, continuitatea activității, securitatea lanțului de aprovizionare, dezvoltarea securizată, gestionarea vulnerabilităților, instruirea, criptarea, securitatea resurselor umane, controlul accesului, managementul activelor și autentificarea. Articolul 23 introduce raportarea etapizată pentru incidente semnificative.

DORA se aplică de la 17 ianuarie 2025 multor entități financiare. Acoperă managementul riscurilor TIC, raportarea incidentelor majore legate de TIC, testarea rezilienței operaționale digitale, riscul TIC asociat terților, aranjamentele contractuale cu furnizorii TIC și supravegherea furnizorilor terți critici de servicii TIC. Articolul 5 din DORA plasează guvernanța riscurilor TIC la nivelul organului de conducere. Articolele 8-14 acoperă identificarea activelor, protecția, detecția, continuitatea, backup-ul, recuperarea, lecțiile învățate, instruirea și comunicările de criză. Articolele 17-20 definesc ciclul de viață al incidentului și raportarea. Articolele 28-30 fac din riscul TIC asociat terților, clauzele contractuale, registre, riscul de concentrare, drepturile de audit și planificarea ieșirii obligații centrale.

NIST CSF 2.0 oferă un strat practic de integrare. Funcția GOVERN include obligații legale, de reglementare, contractuale, de confidențialitate și privind libertățile civile, responsabilitatea conducerii, apetitul la risc, politicile, supravegherea și riscul asociat furnizorilor. Rezultate precum GV.OC-03 și GV.SC-02 se aliniază natural cu dovezile pentru Articolul 26, deoarece cer ca obligațiile legale și rolurile partenerilor să fie înțelese, gestionate, comunicate și coordonate.

Avantajul modelului Clarysec este reutilizarea dovezilor. REG08 nu este doar o înregistrare GDPR. Susține responsabilitatea conform ISO/IEC 27701:2025, guvernanța ISO/IEC 27001:2022, claritatea rolurilor furnizorilor în NIST CSF 2.0, guvernanța terților în DORA atunci când sunt implicate servicii financiare și supravegherea de management în NIS2 atunci când entitatea intră în domeniul de aplicare.

Ce vor testa auditorii și autoritățile de reglementare

Revizorii diferiți vor aborda guvernanța operatorilor asociați prin lentile diferite, dar vor converge asupra aceleiași întrebări de bază: poate organizația să demonstreze că responsabilitatea funcționează?

Cea mai solidă postură de audit este trasabilitatea. Începeți cu cerința legală, conectați-o la politica PIMS, indicați înregistrarea din registru, arătați fluxul, apoi arătați dovezi de testare sau o înregistrare reală de caz.

De exemplu, Articolul 26 din GDPR impune alocarea responsabilităților între operatorii asociați. Politica privind Sistemul de management al informațiilor privind confidențialitatea solicită REG08 înainte de începerea prelucrării. REG08 arată alocarea responsabilităților pentru informări, drepturi, încălcări ale securității datelor cu caracter personal, retenție, managementul furnizorilor și contacte. REG07 arată rezumatul destinat publicului. O simulare DSR demonstrează că fluxul funcționează. Procesele-verbale ale revizuirii de management arată excepții, decizii și îmbunătățiri.

Aceasta este guvernanță auditabilă.

Revizuirea de management transformă riscul privind confidențialitatea în responsabilitate executivă

Guvernanța operatorilor asociați nu trebuie ascunsă într-un folder de confidențialitate. Ea aparține revizuirii de management deoarece afectează expunerea la reglementare, încrederea clienților, încrederea pacienților, pregătirea pentru incidente, riscul asociat furnizorilor, răspunderea contractuală și reziliența operațională.

ISO/IEC 27001:2022 impune angajamentul conducerii, roluri, resurse, alinierea politicilor, planificare bazată pe risc, evaluarea performanței și îmbunătățire continuă. NIS2 plasează obligații de supraveghere a securității cibernetice asupra organelor de conducere. DORA plasează responsabilitatea finală pentru riscul TIC asupra organului de conducere al entităților financiare.

Politica privind rolurile și responsabilitățile de guvernanță-sme - IMM a Clarysec, clauza 5.5, prevede:

Toate deciziile, excepțiile și escaladările semnificative de securitate trebuie înregistrate și trasabile.

Pentru organizațiile de tip enterprise, Politica privind rolurile și responsabilitățile de guvernanță, clauza 5.2, impune:

Trebuie menținut un Registru de roluri și responsabilități, care trebuie să includă:

Acest registru ar trebui să includă rolurile de guvernanță a confidențialității atunci când acestea afectează securitatea, răspunsul la incidente, asigurarea privind furnizorii, reziliența operațională și raportarea executivă. Excepțiile privind operatorii asociați ar trebui escaladate înainte de lansare, nu descoperite după o plângere.

Un pachet practic de materiale pentru revizuirea de management ar trebui să includă:

• Acorduri noi și modificate între operatori asociați
• Starea finalizării REG08
• Activități de prelucrare cu risc ridicat și starea DPIA, acolo unde este aplicabil
• Probleme deschise privind temeiul juridic sau transparența
• Performanța DSR și acțiuni restante ale partenerilor
• Rezultatele exercițiilor de simulare privind încălcările securității datelor cu caracter personal și lacune nerezolvate
• Dependențe de furnizori, persoane subîmputernicite, cloud și transferuri
• Excepții de la retenție și încetare
• Constatări de audit și starea remedierii
• Impactul raportării pentru GDPR, NIS2, DORA, NIST CSF 2.0 și COBIT 2019

O abordare Clarysec în cinci pași pentru a face Articolul 26 auditabil

Dacă organizația dumneavoastră partajează autoritatea decizională asupra prelucrării PII cu o altă parte, nu așteptați o plângere, un audit, o încălcare a securității datelor cu caracter personal sau o dispută cu partenerul pentru a clarifica responsabilitățile.

Utilizați această abordare în cinci pași:

1. Utilizați Pasul 2 din Zenith Blueprint pentru a identifica părțile interesate, cerințele legale, așteptările partenerilor, obligațiile de confidențialitate și domeniul de aplicare al reglementărilor.
2. Utilizați Pasul 4 din Zenith Blueprint pentru a construi o matrice RACI pentru informările privind confidențialitatea, temeiul juridic, drepturi, comunicarea privind încălcările securității datelor cu caracter personal, retenție, transferuri, furnizori, dovezi de audit și încetare.
3. Înregistrați activitatea de prelucrare în REG02 și alocarea responsabilităților între operatorii asociați în REG08 folosind setul de politici PIMS al Clarysec.
4. Mapați acordul prin Zenith Controls, în special Controlul 5.2, Controlul 5.31 și Controlul 5.34 din ISO/IEC 27002:2022.
5. Testați acordul printr-o simulare DSR și un exercițiu de simulare privind încălcarea securității datelor cu caracter personal înainte de începerea prelucrării.

CareConnect și MetroHealth nu aveau nevoie de mai multă aliniere informală. Aveau nevoie de o alocare documentată a responsabilităților, un rezumat destinat publicului, un flux pentru exercitarea drepturilor, o înregistrare privind coordonarea încălcării securității datelor cu caracter personal, clauze contractuale și dovezi ale revizuirii de management.

Aceasta este diferența dintre „am crezut că partenerul se ocupă” și „iată acordul aprobat, informarea privind confidențialitatea, fluxul, dovezile de testare și înregistrarea deciziei privind încălcarea securității datelor cu caracter personal”.

Clarysec vă poate ajuta să implementați guvernanța PIMS conform ISO/IEC 27701:2025, să o aliniați cu Articolul 26 din GDPR, să o integrați în SMSI-ul dumneavoastră conform ISO/IEC 27001:2022 și să produceți dovezi pregătite pentru audit pentru cerințele GDPR, NIS2, DORA, NIST CSF 2.0 și COBIT 2019.

Sunteți pregătit să înlocuiți ambiguitatea privind operatorii asociați cu dovezi pregătite pentru audit? Explorați Zenith Blueprint: foaia de parcurs în 30 de pași a auditorului, utilizați Zenith Controls: ghidul de mapare a cerințelor de conformitate între cadre sau contactați Clarysec pentru o evaluare PIMS și SMSI care transformă Articolul 26 într-un sistem operațional de control înainte ca următorul parteneriat să intre în producție.