Supravegherea furnizorilor MDR pentru NIS2, DORA și GDPR

La 02:13, într-o dimineață de luni, furnizorul MDR deschide o alertă de severitate ridicată: autentificare geografic improbabilă, reguli suspecte în căsuța poștală și un cont privilegiat utilizat de pe o stație de lucru neadministrată. Analistul SOC escaladează alerta prin portalul de tichete. Managerul IT doarme. Directorul financiar primește o avertizare de phishing de la un contact bancar înainte ca, intern, canalul de incident să fie activat. La 07:30, CISO se confruntă cu trei întrebări incomode.

Cine avea autoritatea să declare un incident?

Putem demonstra că furnizorul MDR avea jurnalele corecte, le-a păstrat suficient timp și a conservat dovezile?

Dacă au fost accesate date cu caracter personal, poate departamentul juridic să respecte termenele de evaluare a încălcării prevăzute de GDPR în timp ce operațiunile pregătesc raportarea NIS2 sau DORA?

O lună mai târziu, auditorul extern solicită aceleași dovezi, pe un ton diferit. Raportul PDF al furnizorului MDR este util, dar nu este suficient. Auditorul solicită datele brute ale alertelor, fișierele complete de jurnalizare, traseul de escaladare, jurnalul intern al deciziilor, înregistrarea revizuirii furnizorului și dovada că organizația a putut verifica independent ce s-a întâmplat.

Aceasta este problema supravegherii furnizorilor MDR în 2026. Organizațiile externalizează detecția și răspunsul deoarece capacitatea SOC internă este costisitoare, recrutarea este dificilă, iar activitatea amenințărilor este constantă. Însă detecția externalizată nu înseamnă responsabilitate externalizată. În temeiul NIS2, organele de conducere rămân responsabile pentru aprobarea și supravegherea măsurilor de management al riscurilor de securitate cibernetică. În temeiul DORA, entitățile financiare rămân pe deplin responsabile pentru riscul TIC asociat terților, inclusiv pentru serviciile TIC critice, suportul pentru incidente, drepturile de audit, subcontractare și ieșirea din relație. În temeiul GDPR, operatorii trebuie să demonstreze securitatea adecvată a prelucrării, în special atunci când persoanele împuternicite gestionează telemetrie, date de pe stații de lucru, identificatori de utilizator, adrese IP, conținut de e-mail, jurnale sau imagini criminalistice.

Lacuna practică nu este, de regulă, doar contractul MDR. Este lanțul de dovezi dintre contract și serviciul operațional: rutarea alertelor, accesul privilegiat, păstrarea jurnalelor, pragurile de escaladare, dovezile de incident, transparența subcontractanților, clauzele pentru persoanele împuternicite, revizuirile serviciului, exercițiile tabletop și raportarea către management.

Un program defensabil de supraveghere a furnizorilor MDR are nevoie de un singur model operațional care să susțină mai multe discuții de audit. ISO/IEC 27001:2022 oferă această coloană vertebrală.

Supravegherea MDR începe cu responsabilitatea, nu cu consola SOC

O greșeală frecventă este tratarea înrolării MDR ca pe un proiect tehnic: implementarea agenților EDR, redirecționarea jurnalelor de identitate, configurarea alertelor, agrearea unui canal Teams sau Slack și intrarea în producție. Acest lucru poate îmbunătăți detecția, dar nu demonstrează guvernanța.

NIS2 explicitează problema. Entitățile esențiale și importante trebuie să implementeze măsuri tehnice, operaționale și organizaționale adecvate și proporționale pentru managementul riscurilor de securitate cibernetică. Article 21 include analiza riscului, gestionarea incidentelor, continuitatea activității, securitatea lanțului de aprovizionare, igiena cibernetică, controlul accesului, managementul activelor, criptografia și autentificarea multifactor. Article 20 ridică această cerință la nivelul responsabilității organului de conducere, impunând aprobarea și supravegherea acestor măsuri.

Furnizorii MDR se suprapun adesea peste mai multe arii NIS2 Article 21 simultan:

• Gestionarea incidentelor, deoarece furnizorul face triaj, escaladează și poate recomanda izolarea.
• Securitatea lanțului de aprovizionare, deoarece furnizorul este un prestator direct de servicii cu impact asupra securității operaționale.
• Controlul accesului, deoarece furnizorul poate accesa console, jurnale, instrumente pentru stații de lucru sau tenant-uri cloud.
• Jurnalizare și monitorizare, deoarece detecția depinde de acoperirea jurnalizării, retenție și corelare.
• Igienă cibernetică, deoarece constatările MDR expun frecvent puncte slabe de patching, identitate sau configurare.
• Continuitatea activității, deoarece răspunsul întârziat poate perturba servicii critice.

Pentru entitățile financiare, DORA intensifică modelul operațional. DORA se aplică de la 17 ianuarie 2025 și impune managementul riscurilor TIC, raportarea incidentelor, testarea rezilienței, schimbul de informații și managementul riscurilor TIC asociate terților. De asemenea, clarifică faptul că, pentru entitățile financiare identificate și în temeiul NIS2, DORA funcționează ca act juridic sectorial al Uniunii pentru obligațiile de securitate cibernetică suprapuse. O bancă reglementată, o instituție de plată, o firmă de investiții, un asigurător sau un furnizor de servicii privind criptoactivele nu poate spune pur și simplu: „Furnizorul nostru MDR se ocupă de asta.” DORA impune entității să clasifice incidentele TIC, să gestioneze și să monitorizeze furnizorii terți de servicii TIC, să mențină registre ale acordurilor de servicii TIC, să definească drepturi contractuale, să testeze reziliența, să efectueze analiza cauzei-rădăcină și să raporteze etapizat incidentele majore legate de TIC.

GDPR adaugă o altă perspectivă. Dacă telemetria MDR include identificatori de utilizator, adrese IP, metadate de e-mail, înregistrări de autentificare, artefacte ale stațiilor de lucru sau fișiere care conțin date cu caracter personal, atunci se aplică principiile GDPR privind securitatea și responsabilitatea. Article 5 include integritatea, confidențialitatea și responsabilitatea. Article 32 privind securitatea prelucrării devine o întrebare practică de dovezi: au fost protejate jurnalele, a fost limitat accesul, a fost utilizată criptarea acolo unde era adecvat, au fost guvernate persoanele împuternicite și poate organizația demonstra ce s-a întâmplat?

Mesajul este consecvent în toate cele trei regimuri: puteți delega activitatea, dar nu puteți delega responsabilitatea.

ISO/IEC 27001:2022 transformă MDR într-un proces verificabil prin audit

Un SMSI bine implementat, bazat pe ISO/IEC 27001:2022, transformă supravegherea furnizorilor MDR dintr-o promisiune de management al furnizorilor într-un model operațional bazat pe dovezi. Clause 8.1 este deosebit de importantă deoarece impune organizațiilor să controleze procesele, produsele și serviciile furnizate extern care sunt relevante pentru SMSI. MDR este exact acest lucru: un proces furnizat extern care poate afecta răspunsul la incidente, confidențialitatea, reziliența, raportarea de reglementare și continuitatea activității.

Cele mai importante arii din Anexa A ISO/IEC 27001:2022 pentru supravegherea MDR includ relațiile cu furnizorii, cerințele de securitate din acordurile cu furnizorii, managementul riscului lanțului de aprovizionare TIC, monitorizarea serviciilor furnizorilor, gestionarea incidentelor, gestionarea dovezilor, jurnalizarea, monitorizarea, controlul accesului, accesul privilegiat, criptografia și pregătirea pentru continuitatea activității.

Zenith Controls: The Cross-Compliance Guide de la Clarysec Zenith Controls este referința de conformitate încrucișată pentru această activitate. Acesta mapează controalele ISO/IEC 27002:2022 la alte cerințe, controale conexe, așteptări de audit și dovezi de implementare. Pentru supravegherea MDR, trei controale ISO/IEC 27002:2022 sunt centrale: 5.19 pentru relațiile cu furnizorii, 5.22 pentru monitorizarea serviciilor furnizorilor și managementul schimbărilor, și 8.15 pentru jurnalizare. Acestea sunt susținute de 5.20 acordurile cu furnizorii, 5.21 securitatea lanțului de aprovizionare TIC, 5.24 până la 5.28 gestionarea incidentelor și a dovezilor, 5.34 confidențialitatea și informațiile cu caracter personal (PII), 5.36 conformitatea, 8.16 activitățile de monitorizare, 8.17 sincronizarea ceasurilor, 8.18 utilizarea programelor utilitare privilegiate și 8.8 managementul vulnerabilităților tehnice.

Acest lucru contează deoarece un eșec de audit MDR rareori spune „nu există MDR”. De obicei, spune una dintre următoarele:

• Furnizorul MDR nu a fost clasificat ca fiind critic.
• Clauzele contractuale nu includeau notificarea incidentelor, accesul la dovezi sau drepturi de audit.
• Jurnalele nu au fost păstrate suficient timp pentru investigarea unui eveniment raportat.
• Accesul furnizorului era partajat, persistent sau nemonitorizat.
• Clientul nu a revizuit performanța MDR față de SLA-uri.
• Subcontractanții sau persoanele subîmputernicite nu au fost aprobate.
• Obligațiile de notificare a încălcării datelor cu caracter personal nu au fost aliniate cu fluxurile de gestionare a incidentelor.
• Dovezile nu au fost conservate într-un mod util din punct de vedere criminalistic.
• Managementul nu avea metrici care să arate dacă serviciul MDR a redus riscul.

Zenith Controls descrie clar relația dintre așteptările privind furnizorii și acorduri:

„5.19 stabilește așteptările de securitate privind modul în care furnizorii trebuie să gestioneze informațiile organizației. 5.20 formalizează aceste așteptări asigurând că în contracte sau acorduri sunt incluse explicit clauze de securitate, cum ar fi cerințe de confidențialitate, respectarea politicilor de securitate și proceduri de notificare a incidentelor. Fără 5.20, cerințele identificate în 5.19 pot să nu fie executorii din punct de vedere juridic.”

Pentru MDR, acea frază este lecția de guvernanță. Dacă prin contract nu se impune furnizorului să păstreze jurnalele, să furnizeze dovezi, să coopereze în incidente, să restricționeze subcontractarea, să susțină auditurile și să respecte termenele de escaladare, serviciul SOC poate fi util operațional, dar slab din perspectiva auditului.

Ce trebuie să demonstreze contractul MDR înainte de prima alertă

Un contract MDR bun nu este doar un formular comercial de comandă. Este un document de control. DORA Articles 28 to 30 impun gestionarea riscului TIC asociat terților pe întregul ciclu de viață, inclusiv registre ale contractelor TIC, clasificarea criticității, verificare prealabilă înainte de contractare, abordări de audit și inspecție, drepturi de încetare, strategii de ieșire, descrieri clare ale serviciilor, niveluri de serviciu, locații ale serviciului și prelucrării datelor, angajamente privind protecția datelor, asistență în incidente și cooperare cu autoritățile. NIS2 Article 21 impune securitatea lanțului de aprovizionare pentru furnizorii direcți și furnizorii de servicii. GDPR impune roluri de operator și persoană împuternicită, garanții ale persoanei împuternicite, clauze de protecție a datelor și dovezi privind securitatea prelucrării.

Biblioteca de politici Clarysec transpune aceste obligații în cerințe contractuale și operaționale practice. În Politica enterprise de răspuns la incidente Politica de răspuns la incidente, MDR este tratat explicit ca o capabilitate terță guvernată pentru incidente:

„Integrarea cu servicii terțe, inclusiv Managed Detection and Response (MDR), Security Incident and Event Management (SIEM) și furnizori de analiză criminalistică digitală, trebuie guvernată prin acorduri privind nivelul serviciilor (SLA) clar definite și clauze de confidențialitate.”

Această clauză contează deoarece furnizorii MDR primesc adesea informații foarte sensibile înainte ca organizația să știe dacă un incident este raportabil. Telemetria poate include nume de utilizator, căi de fișiere, subiecte de e-mail, nume interne de gazde, adrese IP, diagrame de rețea și indicatori de compromitere. Clauzele de confidențialitate protejează organizația în timpul investigației și susțin responsabilitatea conform GDPR.

Politica enterprise de securitate privind terții și furnizorii Politica de securitate privind terții și furnizorii adaugă două clauze pe care auditorii se așteaptă să le vadă la revizuirea supravegherii MDR:

„Drepturi de audit, inspecție și solicitare de dovezi de securitate”

și:

„Utilizarea subcontractanților condiționată de consimțământul prealabil scris”

Pentru IMM-uri, același principiu de guvernanță este dimensionat proporțional, dar nu eliminat. Politica de securitate privind terții și furnizorii - IMM Politica de securitate privind terții și furnizorii - IMM impune principiul privilegiului minim:

„Furnizorilor trebuie să li se acorde acces numai la sistemele și datele minime necesare pentru îndeplinirea funcției lor.”

De asemenea, impune:

„Restricții privind subcontractarea ulterioară fără aprobare”

Aceste clauze sunt deosebit de relevante pentru MDR. Mulți furnizori utilizează echipe SOC pe niveluri, furnizori de platforme, parteneri de informații privind amenințările, servicii de analiză cloud sau personal regional de suport. Dacă părțile din aval pot accesa jurnalele clientului sau date cu caracter personal, clientul are nevoie de vizibilitate și mecanisme de aprobare. În termenii DORA, aceasta face parte din supravegherea subcontractării și a riscului de concentrare. În termenii GDPR, este guvernanța persoanelor subîmputernicite. În termenii NIS2, este managementul riscului lanțului de aprovizionare.

Lista esențială de verificare pentru supravegherea MDR

O relație defensabilă cu un furnizor MDR trebuie să poată fi testată. Următoarea listă de verificare combină cerințele contractuale, operaționale și de dovezi într-o singură perspectivă de control.

Această listă de verificare trebuie integrată în achiziții, înrolare, revizuire periodică și testarea incidentelor. Dacă lipsește un element, organizația trebuie să îl trateze ca risc asociat furnizorului, nu ca problemă administrativă.

Șapte domenii de dovezi așteptate de auditori

Pentru ca supravegherea MDR să susțină auditul, Clarysec recomandă construirea unui dosar de dovezi MDR organizat în șapte domenii. Acest dosar trebuie să se afle în SMSI, nu într-un folder de achiziții pe care nu îl revizuiește nimeni.

Acest tabel schimbă conversația cu furnizorul. În loc să întrebe „Ne monitorizați?”, organizația întreabă: „Putem demonstra, în fiecare trimestru, că serviciul MDR rămâne eficace, conform și aliniat la apetitul nostru la risc?”

Jurnalizarea este puntea dintre detecție și dovezile de conformitate

MDR fără jurnalizare fiabilă este doar o presupunere externalizată. Furnizorul poate detecta unele amenințări, dar organizația nu poate demonstra domeniul de aplicare, cronologia, cauza-rădăcină sau impactul.

Controlul ISO/IEC 27002:2022 8.15 acoperă jurnalizarea. Zenith Controls clasifică jurnalizarea ca un control de detecție care susține confidențialitatea, integritatea și disponibilitatea, aliniat la conceptul de securitate cibernetică Detect și la capabilitatea de management al evenimentelor de securitate a informațiilor. Acesta leagă direct jurnalizarea de activitățile de monitorizare, evaluarea evenimentelor, răspunsul la incidente, lecțiile învățate, accesul privilegiat, sincronizarea ceasurilor, controlul accesului, confidențialitate, colectarea dovezilor, managementul vulnerabilităților și monitorizarea securității fizice.

De aceea jurnalizarea este centrală pentru dovezile NIS2, DORA și GDPR Article 32. Raportarea incidentelor semnificative conform NIS2 Article 23 impune o avertizare timpurie în termen de 24 de ore de la luarea la cunoștință, notificare în termen de 72 de ore și un raport final cel târziu la o lună după notificare. Raportarea incidentelor majore legate de TIC conform DORA impune clasificare, escaladare, comunicare, analiza cauzei-rădăcină și raportare finală. Responsabilitatea GDPR impune organizațiilor să demonstreze ce s-a întâmplat cu datele cu caracter personal și dacă măsurile de securitate au fost adecvate.

Politica de jurnalizare și monitorizare - IMM de la Clarysec Politica de jurnalizare și monitorizare - IMM oferă un control contractual simplu pentru organizațiile mai mici care utilizează furnizori externi:

„Contractele trebuie să impună furnizorilor păstrarea jurnalelor timp de cel puțin 12 luni și furnizarea accesului la cerere”

Pentru mediile enterprise, Politica de jurnalizare și monitorizare Politica de jurnalizare și monitorizare adaugă cerința de integrare operațională:

„Trebuie să furnizeze date de jurnalizare la cerere sau să se integreze cu platforma SIEM/de agregare a jurnalelor a organizației.”

Aceste clauze rezolvă o problemă recurentă de răspuns la incidente: în timpul unei investigații, furnizorul MDR spune că evenimentul este mai vechi decât fereastra de retenție căutabilă, că jurnalele sunt disponibile doar printr-un export criminalistic contra cost sau că SIEM-ul clientului nu conține îmbogățirile furnizorului și acțiunile analiștilor. Dacă accesul la jurnale nu este definit în avans, cronologia incidentului devine fragmentată.

Un model solid de jurnalizare MDR trebuie să definească sursele obligatorii de jurnalizare, tipurile de evenimente, perioadele de retenție, protecția integrității, aprobările de acces, sincronizarea timpului, formatele de export și regulile de corelare între platformele clientului și ale furnizorului. De asemenea, trebuie să acopere acțiunile furnizorului, inclusiv schimbările regulilor de detecție, comenzile de izolare a stațiilor de lucru, accesul administrativ, notele analiștilor și exporturile de dovezi.

Standardele ISO de suport consolidează această abordare. ISO/IEC 27035-1:2023 și ISO/IEC 27035-2:2023 conectează jurnalizarea cu detectarea incidentelor, triajul și analiza centralizată. ISO/IEC 27701:2021 adaugă jurnalizarea specifică protecției vieții private pentru activitățile de prelucrare a informațiilor cu caracter personal (PII). ISO/IEC 27017:2021 și ISO/IEC 27018:2020 adaugă așteptări privind jurnalizarea în cloud și pentru informații cu caracter personal (PII) în cloud, în special atunci când furnizorii prelucrează date ale clienților în medii cloud public. ISO/IEC 27005:2024 tratează jurnalizarea insuficientă ca pe o problemă de tratare a riscului, nu doar ca pe o lacună de instrumente.

Răspunsul la incidente: MDR poate escalada, dar managementul trebuie să decidă

Furnizorii MDR detectează și oferă recomandări. Organizația responsabilă declară incidentele, evaluează impactul de reglementare, comunică cu autoritățile și decide dacă este necesară notificarea încălcării datelor cu caracter personal.

Această distincție contează deoarece severitatea MDR nu echivalează automat cu un incident semnificativ NIS2, un incident major legat de TIC conform DORA sau o încălcare a datelor cu caracter personal conform GDPR. Furnizorul poate eticheta o alertă ca „severitate ridicată”, dar organizația trebuie să decidă dacă au fost afectate servicii critice, dacă datele cu caracter personal au fost compromise, dacă trebuie notificați clienții, dacă trebuie informate autoritățile de reglementare și dacă managementul trebuie să aprobe o acțiune de izolare cu impact operațional.

Politica de răspuns la incidente - IMM de la Clarysec Politica de răspuns la incidente - IMM este directă:

„Terții trebuie să acționeze în conformitate cu acordurile semnate, care trebuie să includă clauze de notificare a încălcării datelor cu caracter personal și obligații de cooperare în răspuns.”

Această clauză este punctul în care dovezile GDPR Article 32 se întâlnesc cu răspunsul operațional la incidente. Dacă furnizorul MDR observă suspiciuni de exfiltrare de date de pe o stație de lucru care conține date cu caracter personal, furnizorul trebuie să știe cât de rapid notifică, pe cine notifică, ce dovezi conservă și cum susține evaluarea operatorului.

Zenith Blueprint: An Auditor’s 30-Step Roadmap de la Clarysec Zenith Blueprint oferă metoda de testare. În faza Controls in Action, Step 19, Zenith Blueprint cere echipelor să valideze operațional jurnalizarea și monitorizarea:

„Alegeți un incident sau eveniment recent și demonstrați cum l-ați urmărit folosind jurnalele. Dacă sunt utilizate caracteristici de integritate a jurnalelor (de exemplu, verificare hash), documentați și acest lucru. Confirmați că alertarea este funcțională (de exemplu, autentificările eșuate sau escaladarea privilegiilor declanșează alerte).”

Același pas abordează identitatea și accesul privilegiat:

„Pentru conturile privilegiate, verificați că MFA este impusă, rolurile de administrator sunt segregate (conturi de tip admin_john utilizate numai pentru sarcini administrative) și există o listă curentă a utilizatorilor privilegiați.”

În context MDR, lista utilizatorilor privilegiați trebuie să includă conturile furnizorului, nu doar angajații. Dacă furnizorul MDR are acces la console, drepturi de izolare a stațiilor de lucru, drepturi de administrare EDR sau acces de citire la jurnale sensibile, aceste conturi trebuie incluse în revizuire.

Step 23 din Zenith Blueprint oferă apoi structura de testare pentru incidente și furnizori:

„Selectați un eveniment recent sau desfășurați un exercițiu de tip tabletop pentru a valida planul. Capturați și jurnalizați toate deciziile, rolurile și comunicările (5.26) și actualizați planul cu lecțiile învățate (5.27). Confirmați că există proceduri pentru conservarea probelor criminalistice (5.28), inclusiv instantanee ale jurnalelor, backup-uri și izolarea securizată a sistemelor afectate.”

Un exercițiu tabletop realist trebuie să includă furnizorul MDR. Utilizați un scenariu precum compromiterea unui cont privilegiat, izolarea unei stații de lucru, acces suspect la căsuța poștală, posibilă expunere a datelor de salarizare și escaladarea unei alerte în afara programului de lucru. Testul trebuie să verifice dacă ceasul furnizorului MDR pornește la detecție, la notificarea clientului sau la confirmarea de primire de către client. Această distincție contează atunci când termenele de reglementare depind de luarea la cunoștință și de punctele decizionale.

Construiți în 90 de minute un pachet MDR pentru o singură alertă

O modalitate rapidă de a expune lacunele este alegerea unei alerte MDR recente de severitate ridicată și construirea unei urme de dovezi pe o pagină. Acest exercițiu practic funcționează bine înainte de audituri, revizuiri ale consiliului și reînnoiri contractuale.

1. Începeți cu tichetul alertei. Capturați marcajul temporal, regula de detecție, activul afectat, utilizatorul, severitatea, notele analistului MDR și calea de escaladare.
2. Extrageți clauza contractuală sau SLA-ul care arată timpul de răspuns așteptat pentru acea severitate.
3. Obțineți lista surselor de jurnalizare care demonstrează ce sisteme au alimentat alerta, cum ar fi EDR, furnizorul de identitate, firewall-ul, gateway-ul de securitate e-mail și jurnalele de audit cloud.
4. Confirmați că jurnalele sunt păstrate conform politicii și că evenimentul istoric poate fi încă recuperat.
5. Verificați dacă analistul MDR a accesat vreun mediu al clientului. Dacă da, capturați contul nominal, dovada MFA, jurnalele de sesiune și aprobarea.
6. Documentați decizia din partea clientului: eveniment închis, incident declarat, evaluare juridică declanșată, izolare efectuată sau risc acceptat.
7. Dacă pot fi implicate date cu caracter personal, înregistrați analiza rolurilor GDPR, proprietarul evaluării încălcării și dacă au fost declanșate obligațiile de notificare ale persoanei împuternicite.
8. Închideți cu lecțiile învățate: ajustare, detecție nouă, schimbare de acces, actualizare de playbook sau problemă SLA cu furnizorul.

Această urmă pentru o singură alertă este puternică deoarece conectează contractul, jurnalizarea, accesul, răspunsul la incidente, confidențialitatea și supravegherea managementului într-un singur lanț de dovezi. Dacă nu o puteți construi pentru o alertă recentă, probabil nu o veți putea construi sub presiune de reglementare.

Monitorizarea furnizorilor este locul în care majoritatea programelor MDR slăbesc

Multe organizații efectuează verificarea prealabilă înainte de semnarea unui contract MDR, apoi se opresc. Acest lucru nu este suficient pentru ISO/IEC 27001:2022, NIS2, DORA sau GDPR. Serviciile MDR se schimbă continuu: reguli noi de detecție, echipe noi de analiști, persoane subîmputernicite noi, regiuni noi de date, capabilități EDR noi, integrări noi, fluxuri noi de informații privind amenințările și modele noi de suport.

Controlul ISO/IEC 27002:2022 5.22 abordează monitorizarea, revizuirea și managementul schimbărilor pentru serviciile furnizorilor. Zenith Controls explică faptul că 5.22 se bazează pe controalele privind relațiile și acordurile cu furnizorii, asigurând monitorizarea și managementul continuu după inițierea serviciului. Acesta se conectează la securitatea în timpul perturbărilor, managementul vulnerabilităților, conformitate, controlul accesului și inginerie securizată.

DORA Articles 28 to 30 fac acest lucru deosebit de important pentru entitățile financiare. Acestea impun monitorizare continuă, registre ale acordurilor cu terți TIC, diferențieri de criticitate, verificare prealabilă, drepturi de audit și inspecție, drepturi de încetare, strategii de ieșire, niveluri de serviciu, asistență în incidente, cooperare cu autoritățile și, pentru funcțiile critice sau importante, ținte de serviciu, testare a planurilor de contingență și cooperare pentru testare de penetrare bazată pe amenințări, acolo unde este relevant.

Zenith Blueprint, faza Controls in Action, Step 23, oferă structura ciclului de viață al furnizorilor:

„Compilați o listă completă a furnizorilor și furnizorilor de servicii actuali (5.19) și clasificați-i pe baza accesului la sisteme, date sau control operațional.”

Continuă:

„Pentru fiecare furnizor critic, identificați dacă utilizează subcontractanți (persoane subîmputernicite) care vă pot accesa datele sau sistemele.”

O revizuire practică a serviciului MDR trebuie organizată trimestrial pentru mediile critice și cel puțin anual pentru mediile cu risc mai redus. Agenda trebuie să includă respectarea SLA pe severități, alerte escalate, alerte confirmate, fals pozitive, escaladări ratate, starea surselor de jurnalizare, schimbări ale accesului privilegiat, integrări noi, regiuni noi, subcontractanți, persoane subîmputernicite, schimbări ale regulilor de detecție, performanța suportului în incidente, cereri de dovezi, riscuri deschise, acțiuni corective și pregătirea pentru ieșire.

Aceasta nu este micromanagement. Este bucla de asigurare care demonstrează că organizația guvernează activ un furnizor critic de securitate.

Mapare de conformitate încrucișată: un set de controale MDR, cinci discuții de audit

Valoarea ISO/IEC 27001:2022 constă în faptul că oferă organizațiilor un ciclu SMSI coerent pentru mai multe discuții de conformitate. Același pachet de dovezi pentru supravegherea MDR poate fi mapat la NIS2, DORA, GDPR, NIST CSF 2.0 și COBIT 2019.

NIST CSF 2.0 este util pentru comunicare. Funcția GOVERN impune ca obligațiile juridice, de reglementare, contractuale și de confidențialitate să fie înțelese și gestionate, rolurile și autoritățile să fie definite, riscul de securitate cibernetică să fie integrat în managementul riscurilor la nivel de întreprindere, iar riscurile asociate furnizorilor să fie comunicate și monitorizate.

COBIT 2019 este util pentru management și asigurare. Auditorii orientați pe COBIT se concentrează adesea mai puțin pe un singur control și mai mult pe funcționarea ca sistem a obiectivelor de guvernanță, managementului serviciilor, deținerii riscului și monitorizării performanței.

Cum vor testa auditorii supravegherea furnizorilor MDR

Auditori diferiți folosesc perspective diferite, dar toți doresc dovezi că organizația controlează relația.

Un auditor ISO/IEC 27001:2022 va începe cu domeniul de aplicare, părțile interesate, evaluarea riscurilor, Declarația de aplicabilitate, planul de tratare a riscurilor și dovezile operaționale. Dacă MDR este în domeniu, auditorul se va aștepta ca procesele furnizate extern să fie controlate în cadrul SMSI. Poate eșantiona relațiile cu furnizorii, acordurile cu furnizorii, monitorizarea serviciilor furnizorilor, jurnalizarea, monitorizarea, răspunsul la incidente, gestionarea dovezilor și controlul accesului.

Un supraveghetor DORA se va concentra pe reziliența operațională și riscul sistemic. Poate examina evaluarea criticității, registrul serviciilor TIC, analiza riscului de concentrare, strategia de ieșire, clasificarea incidentelor, drepturile de audit și dovezile că furnizorul MDR poate susține raportarea de reglementare.

Un auditor GDPR sau un revizor de confidențialitate se va concentra pe guvernanța operator-persoană împuternicită. Va solicita DPA-ul, verificarea prealabilă a persoanei împuternicite, controalele pentru persoanele subîmputernicite, măsurile de protecție pentru jurnalele care conțin date cu caracter personal, controalele de retenție, înregistrările evaluării încălcării și dovezile care susțin Article 32.

Un auditor COBIT sau ISACA va inspecta dovezile de guvernanță: deținerea riscului asociat furnizorilor, fluxul de achiziții, procesele-verbale ale revizuirii serviciilor, urmărirea problemelor SLA, acțiunea corectivă, calitatea dovezilor și dacă managementul primește metrici relevante.

Cea mai revelatoare solicitare de audit este simplă: „Arătați-mi o alertă MDR de la detecție până la închidere.” Dacă puteți arăta așteptarea contractuală, sursa de jurnalizare, alerta, escaladarea, decizia, conservarea dovezilor, evaluarea confidențialității, remedierea și raportarea către management, supravegherea MDR este matură. Dacă puteți arăta doar un tichet de furnizor, aveți monitorizare, dar guvernanță slabă.

Raportarea către management: consiliul nu are nevoie de capturi de pachete

NIS2 și DORA plasează ambele responsabilitatea la nivelul organului de conducere. Consiliile și executivii nu au nevoie de telemetrie brută. Au nevoie de metrici de supraveghere MDR relevante pentru risc.

Un tablou de bord MDR trimestrial util include:

• Surse critice de jurnalizare înrolate față de cele așteptate.
• Procentul activelor critice acoperite de MDR.
• Alerte de severitate ridicată pe categorie și serviciu de business.
• Timpul mediu de la detecție la notificarea clientului.
• Timpul mediu de la confirmarea de primire a clientului la decizie.
• Încălcări SLA și acțiuni nerezolvate ale furnizorului.
• Starea revizuirii conturilor privilegiate ale furnizorului.
• Schimbări ale subcontractanților sau persoanelor subîmputernicite.
• Incidente care necesită evaluarea notificării juridice, de reglementare sau către client.
• Lecții învățate implementate.

Acest tablou de bord trebuie să alimenteze revizuirea de management a SMSI, actualizările tratamentului riscului și revizuirea furnizorilor. În temeiul ISO/IEC 27001:2022, conducerea trebuie să se asigure că SMSI este aliniat cu direcția strategică, resursele sunt disponibile, responsabilitățile sunt atribuite, comunicarea funcționează și are loc îmbunătățirea continuă. Metricile MDR sunt o modalitate practică de a demonstra că operațiunile de securitate externalizate sunt guvernate de management, nu lăsate administratorilor de instrumente.

Lacune frecvente în supravegherea MDR de remediat înaintea auditurilor din 2026

Cele mai frecvente lacune sunt eșecuri obișnuite de guvernanță.

În primul rând, organizațiile uită că furnizorii MDR pot prelucra date cu caracter personal. Jurnalele de securitate sunt uneori tratate ca „date tehnice”, dar pot conține date cu caracter personal și ocazional conținut sensibil. Analiza rolurilor GDPR și clauzele pentru persoanele împuternicite trebuie finalizate înainte de înrolare, nu în timpul unei încălcări.

În al doilea rând, retenția jurnalelor este presupusă, nu contractată. Dacă obligațiile de reglementare, criminalistice sau față de clienți impun dovezi pentru luni de zile, modelul de retenție MDR și SIEM trebuie să susțină acest lucru. Cerința politicii pentru IMM-uri privind retenția jurnalelor furnizorului timp de 12 luni este o bază practică pentru multe medii.

În al treilea rând, accesul terților este prea permisiv. Conturile furnizorilor trebuie să fie nominale, protejate prin MFA, monitorizate, revizuite și limitate în timp acolo unde este fezabil. Conturile partajate și sesiunile administrative neadministrate creează risc de audit și de răspuns la incidente.

În al patrulea rând, pragurile de incident sunt ambigue. Severitatea MDR nu echivalează automat cu un incident juridic, un incident major legat de TIC conform DORA, un incident semnificativ NIS2 sau o încălcare a datelor cu caracter personal conform GDPR. Playbook-ul trebuie să definească cine ia fiecare decizie.

În al cincilea rând, subcontractanții sunt invizibili. Dacă furnizorul MDR schimbă platformele de analiză, regiunile de suport sau persoanele împuternicite din aval, profilul de risc al clientului se schimbă. Consimțământul prealabil scris și revizuirea periodică sunt esențiale.

În al șaselea rând, revizuirile serviciului se concentrează doar pe volumul de tichete. Revizuirile mature examinează alertele ratate, schimbările de ajustare, starea surselor de jurnalizare, recuperarea dovezilor, accesul furnizorului, cooperarea în incidente și obligațiile contractuale.

Pașii următori: pregătiți-vă furnizorul MDR pentru audit cu Clarysec

Dacă furnizorul MDR este deja activ, nu așteptați ca o autoritate de reglementare, un auditor al clientului sau un incident să descopere că dovezile sunt incomplete. Începeți cu o alertă recentă și construiți urma. Apoi clasificați furnizorul, revizuiți contractul, validați jurnalizarea, testați escaladarea, confirmați clauzele pentru persoanele împuternicite, revizuiți accesul și planificați monitorizarea furnizorului.

Clarysec vă poate ajuta să operaționalizați rapid acest lucru folosind:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint pentru implementare etapizată, inclusiv Step 19 pentru validarea jurnalizării, monitorizării și accesului, și Step 23 pentru controalele de management al furnizorilor și incidentelor.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls pentru maparea controalelor ISO/IEC 27002:2022 5.19, 5.22 și 8.15 la așteptările de audit NIS2, DORA, GDPR, NIST și COBIT.
• Șabloane de politici Clarysec, inclusiv Politica de răspuns la incidente, Politica de securitate privind terții și furnizorii, Politica de jurnalizare și monitorizare, Politica de răspuns la incidente - IMM, Politica de securitate privind terții și furnizorii - IMM, Politica de jurnalizare și monitorizare - IMM și Politica de protecție a datelor și confidențialitate - IMM.

MDR este una dintre cele mai valoroase investiții de securitate pe care o organizație le poate face. În 2026, această valoare trebuie demonstrată prin guvernanță, dovezi și supraveghere responsabilă. Dacă doriți un pachet practic de supraveghere MDR mapat la ISO/IEC 27001:2022, NIS2, DORA și GDPR Article 32, Clarysec vă poate ajuta să îl construiți înainte ca următoarea alertă să devină următoarea constatare de audit.