Ordinul DNSC nr. 1/2026 a adus pe masa entităților esențiale și importante un set de peste 200 de controale, organizate după modelul CyFun 2025 (NIST CSF 2.0). Prima reacție, pe care o văd foarte des, este să se deschidă matricea de controale (fișierul Excel de pe situl DNSC) și să se înceapă să se bifeze, căci tocmai sîntem în perioada în care trebuie realizată autoevaluarea Este o reacție pe care o pot înțelege: se dorește conformitate. Și asta conduce aproape sigur la o conformitate de hîrtie: politici multe, dovezi puține și o organizație care nu știe ce să restaureze prima dată atunci cînd lucrurile chiar se opresc.
Abordarea pe care tot o propun și o susțin public nu este nouă și nici nu îmi aparține. Ea vine din….cărți și bunele practici: securitatea cibernetică începe cu activitatea organizației. Analiza impactului asupra activității (BIA) este fundamentul deciziilor, iar furnizorii nu sînt un capitol separat, ci o parte a sistemului pe care îl protejăm.
În „Cum facem practic ce spune CyFun?” am arătat că cele șase funcții lucrează în paralel, cu Guvernanța ca inel care le orientează pe celelalte. În „Putem folosi COBIT pentru CyFun?” am arătat, pe exemplul GV.OC-03.1 și MEA03, cum un obiectiv COBIT dă structură unui control CyFun. Acum vin cu întrebarea: de unde știm ce este prioritar și cum ducem această prioritate pînă la furnizori?.
BIA: patru întrebări care schimbă prioritățile
O analiză de impact bună răspunde la patru întrebări simple:
- Ce trebuie să funcționeze în continuare?
- Ce impact au întreruperile și compromiterea datelor?
- Cât timp putem tolera impactul?
- De ce avem nevoie pentru recuperare?
Repet ce tot am mai scris/afirmat: BIA nu este un exercițiu al departamentului IT.
Responsabilii de servicii descriu rezultatele și utilizatorii, echipa din subordine evaluează impactul în timp (inclusiv în perioadele de vîrf), IT/OT și achizițiile identifică dependențele, responsabilii stabilesc serviciul minim și nevoile de recuperare, iar conducerea aprobă prioritățile și lacunele rămase. Rezultatul este o analiză aprobată cu dependențe prioritizate și decizii documentate.
Să luăm un exemplu ipotetic, pe care îl voi folosi încontinuare: procesarea și livrarea comenzilor unei companii de distribuție
| Element BIA | Exemplu |
| Serviciu și responsabil | Procesarea și livrarea comenzilor / Director operațional |
| Impact în timp | La 2 ore: restanțe. La 8 ore: termene de expediere ratate |
| Întrerupere maximă tolerabilă | 8 ore |
| Obiective de recuperare | RTO 4 ore / RPO 15 minute |
| Serviciu minim | Expediere manuală pentru 30% din comenzile prioritare |
| Dependențe critice | ERP, identitate, rețeaua depozitului, API-ul transportatorului, personal |
RTO, RPO și pragul intolerabil nu se adună
Cele trei valori răspund unor întrebări diferite:
- RPO (15 minute) spune cîte date putem pierde.
- RTO (4 ore) spune cît de repede reluăm serviciul.
- Întreruperea maximă tolerabilă (8 ore) spune cînd impactul devine inacceptabil pentru organizație (nu pentru IT!)
Diferența dintre RTO și prag nu este un „tampon” de risipit, ci timpul necesar pentru validarea serviciului și gestionarea restanțelor/întîrzierilor.
Aici apar frecvent două capcane. Prima: un backup programat la 15 minute nu demonstrează, singur, un RPO de 15 minute. Contează execuțiile eșuate, datele corupte și punctele efectiv recuperabile. A doua: repornirea unui server nu înseamnă reluarea procesării comenzilor. Recuperarea se măsoară de la un moment de pornire convenit, cu criterii de acceptare la nivelul întregului serviciu.
În exemplul nostru, BIA cere RTO de 4 ore, dar furnizorul de transport marfă își recuperează API-ul în 24 de ore. Trasabilitatea arată astfel: BIA documentează nevoia și dependența; evaluarea riscurilor (GV.OC-04.4, GV.SC-05.1, GV.SC-07.1) documentează diferența de 20 de ore.
Protecție, detecție, răspuns și recuperare, prin prisma serviciului
Odată ce știm ce contează, celelalte funcții Cyfun capătă ….mușchi….context. Inventarul activelor leagă serviciul (critic) de aplicații, identități, infrastructură și furnizori, iar o singură dependență poate opri totul:
- Protecția acoperă căile critice de compromitere: MFA, privilegii minime, acces administrativ separat, configurare sigură, backup-uri izolate cu teste de restaurare, segmentare IT/OT.
- Detecția are nevoie de contextul activității: jurnale pentru serviciile critice, identitate și accesul furnizorilor, corelate cu impactul, cu escaladare către un responsabil și un înlocuitor.
- Răspunsul corelează tehnologia cu deciziile: cine poate izola ERP-ul, cine activează procesarea manuală, cum comunicăm cînd e-mailul nu funcționează.
- Recuperarea se încheie cu un serviciu sigur, acceptat formal de responsabilul său, cu timpul efectiv și pierderea reală de date comparate cu obiectivele.
Serviciul nostru se poate opri în organizația altcuiva
Externalizarea schimbă operatorul serviciului, nu responsabilitatea. Organizația are în continuare nevoie de dovezi că se poate baza pe furnizor. Iar numărul contractelor nu demonstrează independența: două organizații pot depinde de aceeași platformă cloud (spitalele în 2024?) sau de același subcontractant, iar două contracte de conectivitate pot împărți aceeași rută fizică.
Criticitatea unui furnizor rezultă din dependență, nu din valoarea contractului.
Un serviciu de identitate ieftin poate afecta întreaga organizație. Întrebările utile sînt: ce serviciu critic depinde de el, ce date sau acces privilegiat deține, cât de repede îl putem înlocui, ce subcontractanți folosește și ce performanță de recuperare demonstrează.
Securitatea furnizorului se gestionează pe toată durata relației, iar fiecare etapă produce o dovadă:
- la selecție, constatările de diligență și decizia de risc;
- la acordarea accesului, clauzele semnate și accesul aprobat;
- în operare, revizuiri și teste;
- pentru incidente, exerciții documentate și contacte verificate;
- la ieșire, jurnale de revocare și confirmarea returnării sau ștergerii datelor.
GV.SC-07.1 cere, acolo unde se aplică, revizuirea riscurilor cel puțin anual și la schimbări.
Contractele sînt cele care transformă rezultatele BIA în angajamente verificabile: domeniul serviciului și obiectivul de recuperare, participarea la exerciții, declanșatori și termene pentru incidente, obligațiile subcontractanților, remedierea defectelor, drepturi de revizuire sau audit, returnarea datelor și sprijinul pentru tranziție. Un procent generic de disponibilitate trecut în contract nu demonstrează capacitatea de recuperare.
Afirmațiile comerciale au nevoie de dovezi relevante pentru serviciul contractat: domeniu, actualitate, excluderi, constatări și modul de remediere. O certificare ISO 27001 a unui sistem de management nu demonstrează, singură, un anumit RTO pentru serviciul pe care îl folosim.
Accesul furnizorilor are nevoie de controale proprii (conturi nominale cu MFA, sesiuni de suport limitate și aprobate, activitate monitorizată), iar pentru software contează întregul lanț: componente și SBOM, pipeline CI/CD cu secrete protejate, proveniența și integritatea artefactelor, actualizări testate cu posibilitate de revenire. SBOM sprijină analiza vulnerabilităților, dar nu certifică singură siguranța aplicației.
În loc de concluzie
CyFun nu se implementează pornind de la lista de controale, ci pornind de la întrebarea „ce trebuie să continue să funcționeze în organizația mea?”. BIA transformă eticheta „critic” într-o ordine de priorități justificată. Furnizorii fac parte din sistem, iar contractele transformă nevoile în angajamente verificabile.
Maturitatea se demonstrează prin…. teste, nu doar prin numărul de proceduri.
Dacă ar fi să încep mîine, aș face două lucruri:
- aș stabili aplicabilitatea controalelor Cyfun pentru organizația mea;
- aș face un prim exercițiu BIA.
Restul decurge din ce descoperim acolo…..Cît timp durează povestea asta? Destul de mult…..și nici nu-i gratis.
