Să presupunem că o organizație a externalizat integral administrarea infrastructurii IT către un MSP și serviciile de securitate cibernetică către un MSSP: nu are administratori de sistem, nu are un SOC propriu și nici specialiști care să gestioneze direct vulnerabilitățile sau incidentele de securitate. Are însă contracte, SLA-uri, rapoarte periodice și, cel puțin teoretic, acces la toate competențele tehnice de care are nevoie. Este o situație foarte des întîlnită.

Vine momentul autoevaluării maturității conform Ordinului DNSC nr. 1/2026. Cine completează matricea CyFun? Organizația, care nu execută activitățile tehnice, sau furnizorii, care dețin infrastructura, instrumentele și dovezile?

Și, mai ales, al cui nivel de maturitate îl măsurăm?

Întrebarea nu este deloc teoretică. Într-un asemenea model, aproape toate controalele din funcțiile Protecție și Detecție pot depinde operațional de furnizori. Dacă evaluăm doar ce face organizația cu resurse proprii, riscăm să penalizăm externalizarea. Dacă preluăm scorurile furnizorilor, riscăm să atribuim organizației o maturitate pe care nu o putem demonstra.

Cred că răspunsul trebuie căutat înainte de a ajunge la controalele tehnice. Mai exact, în funcția Guvernare.

Începem cu responsabilitățile, nu cu tehnologia

Controlul GV.RR-01.1 stabilește răspunderea conducerii de vîrf pentru riscul de securitate cibernetică. Controlul GV.RR-02.1 merge mai departe și cere ca rolurile, responsabilitățile și atribuțiile de autoritate pentru angajați, furnizori, clienți și parteneri să fie documentate, revizuite, autorizate, actualizate, comunicate și coordonate intern și extern.

Observați că cerința îi include explicit pe furnizori. Nu presupune că toate activitățile trebuie executate intern, dar nici nu permite ca responsabilitățile să dispară odată cu semnarea contractului.

Să luăm ca exemplu un proces obișnuit: managementul vulnerabilităților.

MSSP identifică vulnerabilitățile prin scanări și monitorizare. MSP administrează sistemele și aplică actualizările. Cine decide însă în cît timp trebuie remediată o vulnerabilitate critică? Cine aprobă amînarea unei actualizări atunci cînd aceasta poate afecta funcționarea unei aplicații importante? Cine acceptă riscul dacă vulnerabilitatea nu poate fi remediată?

Faptul că organizația are două contracte nu răspunde la aceste întrebări. Nici existența unei matrice RACI anexate contractului nu este suficientă, dacă responsabilitățile nu funcționează în practică.

Putem avea un MSSP care identifică vulnerabilitatea la timp și un MSP care respectă toate obligațiile sale contractuale, dar vulnerabilitatea să rămînă nerezolvată pentru că nimeni nu a stabilit cine decide, cine escaladează și cine verifică remedierea. Fiecare furnizor și-a făcut treaba. Organizația a rămas cu riscul.

Aici începe, de fapt, evaluarea maturității.

Un control, mai mulți executanți

Pentru a evalua o organizație cu servicii IT complet externalizate, aș separa controalele în funcție de modul în care sînt exercitate responsabilitățile.

Unele controale țin de guvernanță și presupun decizii ale organizației: aprobarea politicilor, stabilirea apetitului pentru risc, acceptarea riscurilor reziduale sau supravegherea furnizorilor. Activitățile de analiză și documentare pot fi realizate cu sprijin extern, dar deciziile rămîn la organizație.

Alte controale au o componentă predominant tehnică și pot fi executate integral de furnizori. Configurarea sistemelor, aplicarea actualizărilor, monitorizarea evenimentelor sau realizarea backup-urilor sînt exemple evidente.

Există apoi controale care presupun o colaborare efectivă între părțile implicate. Răspunsul la incidente este probabil cel mai bun exemplu: MSSP investighează, MSP intervine asupra infrastructurii, iar organizația decide asupra măsurilor cu impact asupra activității și gestionează comunicarea și notificările obligatorii.

Această clasificare în responsabilități interne, externalizate și partajate nu apare ca atare în CyFun. Este doar propunerea mea pentru a a organiza evaluarea și a găsi răspunsul la întrebarea: de la cine trebuie să cerem dovezile și cine răspunde dacă acestea lipsesc?

Mai apare o problemă. Un control poate avea un executant principal, fără ca toate obligațiile aferente să fie externalizate. De exemplu, MSP poate administra conturile utilizatorilor, dar aprobarea drepturilor de acces aparține responsabililor de procese din organizație. Dacă evaluăm numai activitatea MSP, verificăm doar o parte a controlului.

De aceea, înainte de punctare, trebuie înțeles întregul proces, nu doar serviciul cumpărat.

Ce punctăm, de fapt?

Anexa nr. 2 la Ordinul DNSC nr. 1/2026 cere două scoruri pentru fiecare control aplicabil: maturitatea documentației și maturitatea implementării. Fiecare este evaluat de la 1 la 5, pe baza unor criterii și praguri definite.

Metodologia nu spune că personalul care execută activitatea trebuie să fie angajatul organizației. Dar nici nu introduce o regulă prin care maturitatea furnizorului poate fi transferată automat beneficiarului.

Să presupunem că organizația din exemplul nostru a contractat un SOC 24/7. MSSP deține o platformă SIEM, colectează evenimente, analizează alerte și transmite notificări. Furnizorul are proceduri, personal specializat și poate prezenta inclusiv certificări de securitate.

Ce scor acordăm controlului privind monitorizarea?

Pentru documentație trebuie să verificăm dacă cerințele controlului sînt acoperite de proceduri și documente aplicabile serviciului. Contractul, regulile de escaladare, responsabilitățile și procedurile MSSP pot contribui la demonstrarea maturității documentației. Dar trebuie să știm și ce a aprobat organizația, ce sisteme intră în serviciu și cum sînt gestionate excepțiile.

La implementare, lucrurile devin mai interesante.

Faptul că MSSP are un SIEM nu dovedește că toate sistemele relevante ale clientului trimit evenimente în platformă. Nici existența unei echipe SOC 24/7 nu demonstrează că alertele sînt analizate și escaladate în termenele contractate.

Avem nevoie de dovezi privind serviciul efectiv prestat: sursele monitorizate, alertele procesate, incidentele investigate, timpii de răspuns, excepțiile și rezultatele testelor.

Să presupunem că documentația îndeplinește criteriile stadiului 4, iar implementarea doar pe cele ale stadiului 3. Pentru implementare există un proces formal și dovezi pentru majoritatea activităților, cu excepții sub pragul admis, dar nu există toate dovezile și metricile necesare stadiului 4.

Am avea, în acest exemplu, scor 4 pentru documentație și 3 pentru implementare, dacă sînt îndeplinite integral criteriile respective din metodologie.

Nu contează că analiștii SOC lucrează în sediul MSSP. Contează ce se întîmplă efectiv cu sistemele organizației și ce putem demonstra.

MSSP este matur. Dar serviciul cumpărat?

Aici cred că apare una dintre cele mai frecvente confuzii în piață.

Un MSSP poate avea un nivel ridicat de maturitate organizațională și operațională. Poate fi certificat ISO/IEC 27001, poate utiliza tehnologii avansate și poate avea procese de detecție și răspuns foarte bine documentate.

Dar organizația noastră nu a cumpărat întreaga capacitate a MSSP. A cumpărat un anumit serviciu, cu un anumit domeniu de aplicare, cu anumite limite contractuale.

Poate că furnizorul are capabilități de monitorizare a mediilor cloud, dar contractul acoperă doar infrastructura locală. Poate că oferă răspuns automat la incidente, dar organizația a contractat numai notificarea alertelor. Sau poate că analiza vulnerabilităților există, dar remedierea nu face parte din serviciu. Aceste diferențe contează atunci cînd acordăm scorurile.

Maturitatea generală a furnizorului este relevantă pentru evaluarea riscului asociat acestuia. Maturitatea controlului implementat pentru organizație este însă altceva.

Și mai există o a treia dimensiune: capacitatea organizației de a supraveghea serviciul, de a înțelege rezultatele și de a lua decizii asupra riscurilor identificate.

Cele trei nu trebuie confundate.

Cine deține dovezile?

Într-un model complet externalizat, cele mai multe dovezi tehnice se află la MSP sau MSSP. Organizația primește de obicei rapoarte lunare, indicatori de performanță și notificări pentru evenimentele importante.

Este suficient? Depinde ce conțin rapoartele și ce control evaluăm.

Un raport care afirmă că serviciul SOC a funcționat în proporție de 99,9% poate demonstra disponibilitatea serviciului, dar nu ne spune cîte dintre sistemele critice au fost monitorizate sau dacă evenimentele relevante au fost detectate.

La fel, un raport MSP care indică aplicarea actualizărilor pe 95% dintre servere nu spune mare lucru dacă nu știm care sînt cele 5% rămase, ce vulnerabilități au și ce riscuri introduc.

Nu este obligatoriu ca evaluatorul să primească acces direct la toate sistemele furnizorului. Pot fi utilizate rapoarte detaliate, extrase tehnice, tichete anonimizate, demonstrații sau evaluări independente. De altfel, ghidul de implementare al controlului GV.SC-07.3 admite, acolo unde este cazul, certificări, evaluări independente și atestări drept dovezi relevante pentru conformitatea furnizorilor critici.

Dar trebuie verificat ce acoperă efectiv aceste dovezi. O certificare a MSSP nu demonstrează automat că toate controalele CyFun aplicabile clientului sînt implementate.

Dacă furnizorul refuză să ofere dovezi suficiente, apare o problemă de evaluare. Nu putem concluziona automat că respectivul control nu funcționează, dar nici nu putem acorda un scor ridicat numai pentru că furnizorul declară că îl implementează.

Iar acest lucru ar trebui avut în vedere încă de la negocierea contractului, nu descoperit în timpul autoevaluării.

Cine îl verifică pe cel care execută?

Să revenim la MSP. Furnizorul administrează infrastructura, aplică actualizările și transmite lunar un raport în care arată că sistemele sînt conforme. Organizația acceptă raportul. Îl arhivează și îl folosește ca dovadă în evaluarea maturității.

Dar cine a verificat datele din raport?

Nu sugerez că orice raport trebuie refăcut de un auditor independent. Ar fi costisitor și, în multe situații, inutil. Însă pentru controalele importante trebuie să existe un nivel de verificare proporțional cu riscul: eșantionare, teste, evaluări independente sau cel puțin o analiză documentată a excepțiilor.

Problema este și mai interesantă atunci cînd MSP și MSSP sînt aceeași companie. Furnizorul administrează sistemele, le monitorizează securitatea și raportează rezultatele ambelor activități. Această organizare nu reprezintă, în sine, o neconformitate. Dar ridică întrebări privind independența verificărilor și riscul de concentrare.

Dacă același furnizor este compromis sau devine indisponibil, cine mai poate administra infrastructura, investiga incidentul și coordona recuperarea?

Prin urmare, supravegherea furnizorilor nu este doar o problemă contractuală. Face parte din gestionarea riscurilor organizației.

Și atunci, cum calculăm maturitatea?

Metodologia CyFun nu se schimbă în funcție de modelul de externalizare.

Pentru fiecare control aplicabil acordăm cele două scoruri, documentație și implementare, și le justificăm în scris. Scorurile sînt agregate la nivel de subcategorii și categorii, iar scorul total al entității este media scorurilor categoriilor.

Pragurile minime totale sînt 2,5 pentru nivelul Bază, 3 pentru Important și 3,5 pentru Esențial, cu cerințele suplimentare privind măsurile-cheie și, la nivelul Esențial, scorul fiecărei categorii. Nu facem o medie între maturitatea organizației și cea a furnizorilor. Nu atribuim automat un scor superior pentru că MSSP este certificat și nici un scor inferior pentru că organizația nu are personal tehnic propriu.

Evaluăm controalele aplicabile organizației, inclusiv procesele executate de furnizori.

Practic, pentru fiecare control ar trebui să putem identifica responsabilul pentru execuție, responsabilul pentru supraveghere, documentația aplicabilă, dovezile de implementare și justificarea scorului.

Dacă aceste informații nu pot fi obținute, problema nu este neapărat externalizarea. Poate fi modul în care aceasta a fost guvernată.

În loc de concluzie

Revin la întrebarea de la început: cine este evaluat atunci cînd IT-ul și securitatea sînt externalizate integral? Entitatea, nu furnizorul. Dar evaluarea entității trebuie să includă și controalele implementate prin serviciile contractate.

Controlul GV.RR-02.1 este un punct de plecare util tocmai pentru că obligă organizația să clarifice responsabilitățile interne și externe. Fără această delimitare, evaluarea controalelor tehnice riscă să devină o colecție de rapoarte primite de la furnizori, fără o imagine clară a modului în care funcționează întregul proces.

O organizație poate avea un nivel ridicat de maturitate fără să dețină intern un SOC sau o echipă de administrare. Trebuie însă să poată demonstra ce a externalizat, cine execută, cine verifică și cine decide atunci cînd apar probleme.

Iar această demonstrație nu se încheie odată cu autoevaluarea. În cadrul unui audit ulterior de conformitate, inclusiv al auditului de evaluare a nivelului de asigurare, atunci cînd acesta este aplicabil, auditorul va trebui să poată verifica fundamentarea scorurilor, responsabilitățile asumate și dovezile privind implementarea controalelor. Dacă informațiile se află exclusiv la MSP sau MSSP, organizația trebuie să se asigure că ele pot fi puse la dispoziție și verificate.

Altfel, putem ajunge la situația în care MSP este conform, MSSP este conform, contractele sînt în regulă, iar autoevaluarea indică un nivel satisfăcător de maturitate. Dar, în momentul auditului, organizația nu poate demonstra că riscurile sale sînt gestionate corespunzător.

Și atunci, ce am evaluat, de fapt? Maturitatea securității cibernetice a organizației sau doar capacitatea furnizorilor de a declara că își îndeplinesc obligațiile?