Aprofundează
GRC + ISO 27001 — pregătire pentru certificare
Guvernanță, risc și conformitate, apoi ISO/IEC 27001:2022 clauză cu clauză și drumul spre certificat — cu NIS2, DORA, CRA și AI Act la starea din 2026. Fiecare lecție are quiz.
Traseul de lectură
- 01
GRC nu e un departament, ci numele integrării dintre guvernanță, risc și conformitate; ținute separat, cele trei se dublează și se contrazic.
What Is GRC (Governance, Risk, and Compliance)? · OCEG (Open Compliance and Ethics Group) · 2002
Acronimul a fost lansat de OCEG în 2002, iar definiția lui e mai puțin birocratică decât pare: ansamblul integrat de capabilități care permit atingerea fiabilă a obiectivelor, gestionarea incertitudinii și acțiunea cu integritate. Cuvântul care duce greutatea e „integrat”. Guvernanța stabilește direcția și cine răspunde, managementul riscului spune ce poate strica direcția, conformitatea spune ce e obligatoriu pe drum. Ținute separat, se calcă pe picioare: aceleași controale sunt inventariate de trei ori, aceeași dovadă e cerută de trei echipe, iar conducerea primește trei tablouri care nu se potrivesc între ele. De aceea GRC nu se cumpără ca departament și nici ca instrument. Se recunoaște după artefacte: un singur registru de riscuri, un singur set de controale cu proprietari cu nume, o singură listă de obligații legale legată de acele controale și un singur raport către conducere. Restul e etichetă pusă peste aceleași trei silozuri.
GRC (guvernanță, risc și conformitate) este ansamblul integrat de capabilități care permit unei organizații să își atingă în mod fiabil obiectivele, să gestioneze incertitudinea și să acționeze cu integritate — pentru a ajunge la Principled Performance.OCEG, «What Is GRC (Governance, Risk, and Compliance)?» — definiția de deschidere; acronimul a fost creat de OCEG în 2002
De ce contează Cine tratează GRC ca pe trei departamente vecine plătește de trei ori pentru aceeași dovadă și tot nu poate răspunde la o singură întrebare a conducerii.
Pe larg →Strânge ↑
Pasajul 1. Integrarea nu înseamnă doar registre comune, ci o schimbare de ordine: întrebările conducării vin primite, iar guvernanța, riscul și conformitatea răspund împreună la ele. În practică silozurile lucrează invers — fiecare își face inventarul, apoi speră că cineva îl asamblează. Exemplu concret: când se lansează un produs nou, echipa de risc evaluează separat, echipa juridică verifică separat, iar consiliul aude ambele povești, nu una. O organizație integrată pornește de la întrebarea „putem lansa asta în siguranță?” și adună riscurile, obligațiile și controalele ca un singur răspuns. Următorul pas: cum arată, în zi cu zi, oamenii care lucrează astfel fără să li se spună „GRC”.
Pasajul 2. În zi cu zi, integrarea nu arată ca un program, ci ca niște obiceiuri mici. Oamenii nu spun „GRC”; ei doar nu mai cer de două ori aceeași dovadă. Contabilul care primește o cerere de audit întreabă dacă răspunsul poate servi și politicii de securitate. Managerul care deschide un incident verifică imediat ce obligații legale se declanșează, nu abia la final. Un exemplu banal: când se schimbă un furnizor de plăți, o singură persoană strânge evaluarea riscului, cerințele legale și testele de control, apoi le trimite împreună. Semnul distinctiv e că nimeni nu descoperă după fapt că altcineva făcuse aceeași lucrare. Dar aceste obiceiuri nu apar singure; ce le face posibile e următoarea întrebare.
Pasajul 3. Ce leagă aceste obiceiuri nu e software-ul, ci proprietatea: fiecare control are un om cu nume care răspunde de el. Fără asta, integrarea rămâne un desen pe hârtie. Când un control are un singur proprietar, același test poate servi mai multor scopuri, pentru că cineva e obligat să-l țină viu. Exemplu concret: controlul „accesul se revizuiește trimestrial” aparține unui șef de echipă anume, iar auditul, securitatea și juridicul cer toate aceluiași om, nu trei. Dacă nimeni nu semnează, fiecare echipă își face copia proprie și silozurile reînvie. Proprietarul numit e lipiciul care ține registru, obligații și controale într-un singur loc. Dar ce se întâmplă când organizația crește și proprietarii se înmulțesc? Acolo integrarea e pusă cu adevărat la încercare.
Când organizația crește, proprietarii se înmulțesc, iar integrarea se rupe de obicei pe limbaj. Fiecare echipă numește același risc altfel, deci trei liste care vorbesc despre același lucru par trei probleme diferite. Soluția nu e un departament, ci un vocabular comun: un risc, o obligație și un control primesc câte un nume fix, pe care toată lumea îl folosește. Exemplu concret: „întârzierea plății furnizorilor” înseamnă exact același lucru pentru cumpărături, pentru juridic și pentru finanțe, deci cele trei intrări din registre se unesc fără discuții. Fără acest dictionar, chiar și proprietarii numiți reconstruiesc silozurile, doar mai mari. Rămâne întrebarea ce face conducerea cu imaginea unică pe care i-o dă acest limbaj comun.
Conducerea primește acum o singură imagine. Dar tabloul unic nu e un raport de citit, e un instrument de decizie: arată unde riscul, obligațiile și obiectivele se lovesc între ele. Exemplu concret: bugetul e limitat, iar tabloul arată că un control slab acoperă și o obligație legală și un risc mare de fraudă. Atunci bani se duc acolo, nu la un proiect care doar arată bine. Fără imaginea integrată, fiecare echipă cere fonduri pentru povestea ei, iar alegerea devine o licitație. Cu ea, alegerea devine o comparație pe aceeași scară. Aici apare ideea de Principled Performance: performanță care nu se cumpără cu compromisuri asupra integrității. Următorul pas: ce se întâmplă când apare un eveniment neașteptat și timpul de decizie se scurtează brusc.
Un eveniment neașteptat e testul real al integrării, pentru că timpul de decizie se scurtează brusc. Într-o organizație integrată, conducerea nu strânge informații în criză; le are deja, pentru că registrul, obligațiile și controalele trăiesc la un loc. Exemplu concret: un furnizor cloud cade joi seara. În loc de trei ședințe paralele, tabloul unic arată imediat ce clienți sunt afectați, ce obligații de notificare se declanșează și ce controale de rezervă există. În organizațiile silozate, aceleași ore se pierd căutând cine știe ce. Criza nu creează haosul, doar îl dezvăluie. Iar modul în care se decide sub presiune arată dacă integrarea e reală sau doar etichetă.
Integrarea nu se termină odată construită; se tocește dacă nu e întreținută. Registre, obligații și controale se schimbă constant, iar un tablou unic neactualizat minte la fel de frumos ca trei tablouri separate. Întreținerea nu înseamnă un proiect anual, ci un ritm mic și regulat: cine revizuiește ce, când, și ce declanșează o actualizare în afara calendarului. Exemplu concret: o lege nouă despre protecția datelor apare în primăvară; lista de obligații se actualizează săptămâna respectivă, controlul potrivit primește proprietar, iar tabloul reflectă schimbarea la următoarea ședință. Fără acest ritm, integrarea devine un instantaneu din trecut, nu o imagine a prezentului. Rămâne întrebarea cine păzește acest ritm când nimeni nu-l cere explicit.
- 02
Cadrul NIST a promovat în 2024 guvernanța la rang de funcție proprie și a așezat-o în centru: ea decide cum se aplică celelalte cinci.
The NIST Cybersecurity Framework (CSF) 2.0 · National Institute of Standards and Technology (NIST) · 2024
Până în 2024, cadrul NIST avea cinci funcții: identifică, protejează, detectează, răspunde, restabilește. Versiunea 2.0, publicată pe 26 februarie 2024, a adăugat a șasea — GOVERN — și a mutat-o în centrul roții. Nu e o rubrică în plus, ci o recunoaștere: strategia de risc, așteptările conducerii, politica, rolurile și autoritățile, riscul din lanțul de aprovizionare și supravegherea nu sunt activități tehnice, dar decid cât de bine se fac cele tehnice. Consecința e neplăcută pentru echipele care încep cu unelte. Dacă nimeni nu a stabilit ce obiective apără organizația, cine decide și cu ce buget, atunci detecția și răspunsul se optimizează în gol. Aceeași idee stă la baza clauzei 5 din ISO/IEC 27001, «leadership»: conducerea nu „susține” sistemul, ci răspunde de el. Un auditor care caută dovezi de guvernanță citește decizii scrise ale conducerii, cu dată și autor, nu ecrane de monitorizare.
GOVERN stă în centrul roții pentru că determină modul în care organizația va implementa celelalte cinci funcții.NIST CSWP 29, «The NIST Cybersecurity Framework (CSF) 2.0» (26 februarie 2024), secțiunea 1 «CSF Core», explicația figurii 2
De ce contează La audit, dovada de guvernanță e o decizie scrisă a conducerii, cu dată și autor, nu un tablou de bord tehnic.
Pe larg →Strânge ↑
Vestea bună e că GOVERN nu cere un departament de securitate. Cadrul din 2024 se adresează oricărei organizații, nu doar celor mari. Guvernanța înseamnă, la bază, decizii luate conștient: ce merită apărat, cine răspunde, cât cheltuim. O brutărie cu cinci angajați poate avea guvernanță dacă proprietarul notează, într-un fișier, ce date ale clienților păstrează, cine are acces la casă și ce face când se strică sistemul de comenzi. Un grup uriaș face același lucru, doar cu mai multe pagini. Diferența nu e mărimea, ci faptul că deciziile există în scris, nu doar în capul cuiva. Asta deschide o întrebare practică: cum arată prima decizie de guvernanță pe care o poate lua o organizație mică, săptămâna asta?
Prima decizie de guvernanță pe care o poate lua o organizație mică e simplă: alege cine răspunde de securitate. Nu înseamnă să angajezi un specialist. Înseamnă un nume scris lângă o responsabilitate. Într-o clinică mică, medicul proprietar notează, semnat și cu dată, că el decide ce se face când sistemul de programări cade. Asta e guvernanță în forma ei cea mai simplă. Cadrul din 2024 duce ideea mai departe: decizia trebuie să se poată arăta altcuiva. Un auditor nu e convins de un ecran plin de alerte. El caută documentul care arată cine a hotărât ce, și când. Monitorizarea arată că ceva se întâmplă. Decizia scrisă arată că cineva a răspuns de ea. Fără acel nume, celelalte funcții ale cadrului rămân activități fără stăpân. Iar odată ce numele există, apare întrebarea următoare: ce anume are voie să decidă persoana aceea, și unde se oprește?
- 03
Riscul se măsoară față de obiective, iar cine nu are un proprietar cu nume pentru fiecare risc are doar un tabel, nu un management al riscului.
Guide for Conducting Risk Assessments (NIST SP 800-30 Rev. 1) · National Institute of Standards and Technology (NIST) · 2012
Definiția din ghidul NIST de evaluare a riscurilor (SP 800-30 Rev. 1, 2012) e utilă tocmai pentru că e plictisitoare: riscul e o măsură a cât de expusă e o entitate la o circumstanță sau la un eveniment, funcție de impactul advers și de probabilitatea de apariție. ISO 31000:2018 spune același lucru altfel — efectul incertitudinii asupra obiectivelor — și adaugă ce lipsește din prima formulare: riscul se raportează la obiective, nu la active. Trei termeni se confundă constant. Apetitul de risc e cât risc caută organizația ca să-și atingă obiectivele; e o decizie a conducerii, nu a echipei de securitate. Toleranța e abaterea acceptată în jurul apetitului, exprimată ca praguri concrete care declanșează o reacție. Proprietarul riscului e persoana cu autoritatea și responsabilitatea de a-l trata, adică cineva care poate aloca buget și poate opri o activitate. În ISO/IEC 27001:2022, clauza 6.1.3 cere aprobarea proprietarilor pentru planul de tratare și acceptarea riscurilor reziduale.
Riscul este o măsură a gradului în care o entitate este amenințată de o circumstanță sau de un eveniment potențial și este de regulă o funcție de: (i) impactul advers care ar apărea dacă circumstanța sau evenimentul se produce; și (ii) probabilitatea de apariție.NIST SP 800-30 Rev. 1, «Guide for Conducting Risk Assessments» (septembrie 2012), secțiunea 2.3 «Key Risk Concepts»
De ce contează Auditorul nu întreabă ce riscuri ai, ci cine le deține și cine a acceptat riscul rezidual; fără nume, clauza 6.1.3 nu e îndeplinită.
Pe larg →Strânge ↑
Pasul pe care cardul nu îl face încă e acesta: fără obiective scrise, riscul nu poate fi măsurat, pentru că nu ai la ce să-l raportezi. NIST dă formula, ISO dă ancora — efectul incertitudinii asupra obiectivelor. Practic, întrebi întâi ce vrea organizația să realizeze, apoi ce ar putea împiedica asta. Un magazin online vrea livrare în 24 de ore; atunci o pană de la curier e un risc, iar o defecțiune la un server de test nu e decât un eveniment fără miză. Aceeași defecțiune devine risc doar dacă lovesc un obiectiv. De aici decurge restul: apetitul, toleranța și proprietarul au sens doar raportate la acel obiectiv. Dar cum alege organizația cât risc e dispusă să suporte pentru obiectivul ei?
Pasajul 2: Răspunsul la întrebarea din urmă e apetitul de risc, și e o decizie a conducerii, nu a echipei de securitate. Consiliul spune, de fapt, cât de mult poate eșuează organizația în drum spre obiectiv. Apoi toleranța traduce apetitul în praguri concrete: dacă livrările întârziesc peste opt ore, cineva e obligat să reacționeze. Fără prag, apetitul rămâne un slogan frumos pe un poster. Iar pragurile fără un nume care să reacționeze rămân doar cifre pe hârtie. Cine ar trebui să semneze acel nume?
- 04
Certificatul spune că, la data auditului, un eșantion de dovezi corespundea cerințelor; nu spune nimic despre ziua următoare.
The Process of Security · Bruce Schneier · 2000
Fraza lui Schneier are un sfert de secol și e încă cea mai bună obiecție la conformitatea tratată ca destinație. Un certificat spune că, în zilele auditului, un eșantion de dovezi a corespuns cerințelor. Sistemul care a produs acele dovezi poate fi abandonat a doua zi, iar certificatul rămâne valabil până la următoarea supraveghere. Certificatul e o fotografie; securitatea e filmul din care a fost decupată. De aici vine testul practic pentru orice program de conformitate: dacă un control funcționează doar când se apropie auditul, controlul nu există — există pregătirea pentru audit. Semnele se recunosc ușor: revizuiri de acces pe tot anul, făcute toate în aceeași săptămână; jurnale colectate retroactiv; instruire finalizată de toată lumea în trei zile. ISO/IEC 27001 e construit exact împotriva acestui tipar, fiindcă cere măsurare (9.1), audit intern (9.2), analiză de management (9.3) și acțiune corectivă (10.2). Adică ritm, nu eveniment.
Securitatea este un proces, nu un produs. Produsele oferă o oarecare protecție, dar singura cale de a face afaceri eficient într-o lume nesigură este să pui la punct procese care recunosc nesiguranța inerentă a produselor.Bruce Schneier, «The Process of Security», revista Information Security, aprilie 2000 — paragraful de deschidere
De ce contează Auditorul de supraveghere caută urmele de ritm, iar dovezile îngrămădite în ultima săptămână spun singure ce s-a întâmplat.
Pe larg →Strânge ↑
Există o diferență de cost între cele două moduri de gândire. Un produs se cumpără o dată, la recepție, și se termină. Un proces se plătește lunar, în timp și atenție, și nu se termină niciodată. De aceea multe firme aleg fotografia: e mai ieftină pe hârtie. Dar prețul real apare la incident, când certificatul nu oprește nimic. Gândește-te la fereastra casei: o încuietoare bună cumpărată o dată nu ajută dacă nu o încui seara. Securitatea funcționează la fel — obiceiul de a încui, nu încuietoarea, e protecția. Întrebarea următoare e naturală: dacă procesul e filmul, cine ține camera pornită între audituri?
Certificatul are o proprietate ciudată: supraviețuiește sistemului care l-a meritat. Poți opri mâine toate verificările lunare, iar hârtia rămâne valabilă până la următoarea vizită. De aceea auditorul de supraveghere nu citește doar ce arată dovezile, ci când au fost create. Un exemplu familiar: copilul care învață doar în noaptea dinaintea testului ia nota, dar nu știe materia. La fel, jurnalele de acces revizuite toate în aceeași săptămână înainte de audit spun o poveste pe care nimeni n-a scris-o explicit. Ritmul uniform, cu înregistrări mici dar dese, e singurul semn că controlul trăiește și între verificări. Rămâne de văzut cine, în firmă, ar trebui să dețină acest ritm ca responsabilitate de zi cu zi.
Pasajele de până acum au lăsat întrebarea: cine deține ritmul? Răspunsul lui Schneier e neconfortabil: nu există un deținător natural. Securitatea e proces, iar procesul nu are un proprietar unic — are participanți. Contabilul nu face securitate, dar respectă o politică de acces. Adminul nu face contabilitate, dar păstrează jurnalele. Ritmul trăiește doar dacă fiecare își vede bucata ca parte din munca lui, nu ca favoare către auditor. De aici testul invers: întreabă cineva din afara echipei de securitate ce face, luna asta, pentru securitate. Dacă răspunsul e "nimic, nu e treaba mea", procesul nu există — există doar o echipă mică care pregătește fotografii. Gândește-te la curățenia dintr-un bloc: scara e curată doar dacă fiecare vecin își face partea, nu dacă vine un curător înainte de vizita administratorului. Rămâne de văzut ce se întâmplă cu ritmul când oamenii pleacă din firmă.
Pasajul 3 a lăsat deschisă plecarea oamenilor. Aici apare adevărata probă a procesului: dacă ritmul trăiește doar în capetele anumitor oameni, el pleacă odată cu ei. Un proces adevărat nu ține de memorie, ci de rutină scrisă și repetabilă. Verificarea accesului se poate face de oricine, în fiecare lună, dacă pașii sunt notați și calendarul există. Când adminul pleacă, noul coleg deschide lista și continuă, fără să întrebe pe nimeni ce se făcea. Dacă doar o persoană știe cum se colectează jurnalele, firma nu are un control — are o persoană. Gândește-te la rețeta bunicii: dacă nu e scrisă, moare cu ea. Procesul scris supraviețuiește schimbărilor, la fel ca filmul care continuă și când se schimbă operatorul camerei. Următoarea întrebare e ce faci când rutina scrisă chiar se rupe.
Pasajul 4 a lăsat întrebarea: ce faci când rutina scrisă chiar se rupe. Aici procesul își arată valoarea reală. Un proces bun nu pretinde că nimic nu merge greșit; prevede ce se întâmplă atunci. Cine observă, cine decide, cine repară, cine notează lecția. Diferența nu e între firmele fără incidente și cele cu incidente — incidente apar peste tot. Diferența e între cele care ascund gaura și cele care o repară și schimbă rutina. Gândește-te la țeava spartă: plumbarul care doar astupă gaura lasă problema să revină; cel care îți spune de ce a crăpat țeava îți schimbă felul de a o întreține. Un incident tratat așa devine combustibil pentru proces, nu dovadă de eșec. Rămâne de văzut cum arată un proces care a învățat, comparat cu unul care doar a supraviețuit.
- 05
Cele trei linii nu sunt etaje ierarhice, ci roluri simultane; regula pe care le ține împreună e că nimeni nu dă asigurare despre propria muncă.
The IIA's Three Lines Model: An Update of the Three Lines of Defense · The Institute of Internal Auditors (IIA) · 2020
Modelul actualizat de Institutul Auditorilor Interni în iulie 2020 nu mai vorbește despre „linii de apărare”, ci despre roluri. Organul de guvernanță dă direcția și cere socoteală. Managementul acoperă prima și a doua linie: prima livrează produsele și serviciile și, implicit, deține riscurile care vin cu ele; a doua aduce expertiză, monitorizare și contestare — conformitate, securitatea informației, calitate. A treia linie e auditul intern, care oferă asigurare independentă și obiectivă asupra guvernanței și a managementului riscului, raportând atât conducerii, cât și organului de guvernanță. Aici stau două confuzii scumpe. Responsabilul cu securitatea informației e linia a doua: sfătuiește, monitorizează, contestă, dar nu poate da asigurare despre propria muncă. Iar auditul intern nu proiectează controale și nu ține registrul de riscuri, altfel își pierde independența. Aceeași regulă se aplică la certificare: cine a implementat sistemul nu poate audita ce a implementat.
Funcția de audit intern oferă asigurare și consiliere independente și obiective privind adecvarea și eficacitatea guvernanței și a managementului riscului. Realizează acest lucru prin aplicarea competentă a unor procese sistematice și disciplinate, a expertizei și a discernământului.The IIA, «The IIA's Three Lines Model: An Update of the Three Lines of Defense» (iulie 2020), Principiul 4 «Third line roles»
De ce contează Independența nu e o formalitate: o opinie dată despre propriul proiect nu are valoare, iar organismul de certificare respinge aranjamentul.
Pe larg →Strânge ↑
Cardul spune că nimeni nu dă asigurare despre propria muncă. Hai să ducem ideea mai departe: rolurile simultane funcționează doar dacă fiecare știe când să se oprească. Cine sfătuiește nu poate apoi judeca sfatul dat. Cine construiește un control nu poate spune dacă controlul e bun. Într-o familie, persoana care a gătit cina nu e cea care decide dacă cina a fost suficient de bună pentru invitați. De aceea auditul intern nu proiectează nimic pe care apoi să-l evalueze. Independența nu e un titlu, ci o limită pe care și-o impune singură. Dar ce se întâmplă când rolurile se suprapun în practică, de pildă când managementul cere auditului intern să țină registrul de riscuri?
Când auditul intern ține registrul de riscuri, problema nu apare imediat. Registrul arată bine, e actualizat, totul merge. Rănile apar peste un an, când același audit trebuie să evalueze dacă riscurile firmei sunt corect identificate. Oricum ar evalua, își judecă propria muncă, iar opinia devine neutilizabilă pentru organul de guvernanță. E ca și cum contabilul care ține registrele ar semna și raportul că registrele sunt corecte. Soluția nu e ca auditul să refuze orice ajutor, ci ca rolul să fie scris negru pe alb: cine deține activitatea, cine o verifică. Asta ridică întrebarea următoare: cine decide de fapt aceste limite, și cine le supraveghează?
- 06
Clauza 9.1 nu cere cifre, ci un plan de măsurare: ce, prin ce metodă, când și cine — apoi cine analizează rezultatele.
Electrical Units of Measurement · William Thomson (Lord Kelvin) · 1883
Propoziția lui Kelvin, dintr-o conferință despre unitățile electrice ținută în 1883, e de obicei citată prost, ca „ce nu măsori nu poți conduce”. Originalul e mai onest: fără numere, cunoașterea rămâne sărăcăcioasă, dar nu inexistentă. Diferența contează, fiindcă un program care măsoară doar ce e ușor de numărat ajunge să raporteze activitate în loc de efect. Clauza 9.1 din ISO/IEC 27001:2022 pune patru întrebări și cere răspuns documentat la fiecare: ce se monitorizează și se măsoară, prin ce metode, când se măsoară și cine măsoară, apoi când se analizează rezultatele și cine le analizează. Un indicator de performanță spune cât de bine merge un control, de pildă ponderea sistemelor cu corecții aplicate în termen. Un indicator de risc e prospectiv: crește înainte ca riscul să se materializeze. Cine confundă cele două raportează trecutul și îl numește avertizare timpurie.
Spun adesea că, atunci când poți măsura lucrul despre care vorbești și îl poți exprima în numere, știi ceva despre el; dar când nu îl poți măsura, când nu îl poți exprima în numere, cunoașterea ta este de un fel sărăcăcios și nesatisfăcător.«Electrical Units of Measurement», conferință la Institution of Civil Engineers, 3 mai 1883; Popular Lectures and Addresses, vol. 1 (1889), p. 73
De ce contează Clauza 9.1 pică des la audit nu pentru că lipsesc cifrele, ci pentru că lipsesc metoda, momentul și numele celui care măsoară.
Pe larg →Strânge ↑
Planul de măsurare devine real abia când fiecare răspuns din clauza 9.1 are un nume atașat. Nu „se măsoară periodic”, ci „Ana extrage datele în prima zi de luni din lună”. Fără un nume, planul e o intenție; cu un nume, e o obligație verificabilă. Un exemplu obișnuit: în bucătărie, rețeta care spune doar „gătește până e gata” eșuează; cea care spune cine verifică, cu ce și când, funcționează. Următorul pas e să vedem ce se întâmplă când cineva măsoară, dar nimeni nu analizează.
Măsurarea fără analiză e un jurnal, nu un sistem de avertizare. Clauza 9.1 cere a doua jumătate a planului: cine citește rezultatele și când. Fără ea, indicatorii se strâng ca biletele de tramvai păstrate și niciodată verificate. Un exemplu obișnuit: cântarul din baie îți dă un număr în fiecare dimineață, dar dacă nimeni nu decide ce înseamnă creșterea de o lună, numărul nu schimbă nimic. La fel, un raport de patch-uri aplicate în termen devine util doar când cineva stabilește pragul și ce se face la depășirea lui. Analiza transformă măsurarea în decizie. Rămâne de văzut ce fel de măsurători merită analizate: cele care descriu trecutul sau cele care anunță viitorul.
- 07
Informația documentată nu există pentru hârtie, ci pentru că memoria proprie e cel mai indulgent auditor pe care îl are cineva.
Cargo Cult Science · Richard P. Feynman · 1974
Fraza lui Feynman din 1974 descrie, fără să vrea, motivul pentru care sistemele de management cer informații documentate. Nu pentru că hârtia ar avea valoare în sine, ci pentru că memoria proprie e cel mai indulgent auditor pe care îl are cineva. Un proces despre care toți spun că „merge așa” nu poate fi contrazis de nimic; un proces scris poate fi comparat cu ce s-a întâmplat de fapt. De aici vin cele două jumătăți ale disciplinei: scrii ce faci și faci ce scrii. Prima singură produce un raft de proceduri pe care nu le urmează nimeni, iar fiecare abatere devine neconformitate. A doua singură produce practici bune, imposibil de demonstrat și de transmis mai departe. Dovada obiectivă e un artefact cu dată, autor și conținut verificabil de altcineva: un jurnal, o aprobare, un rezultat de test, o listă de prezență. Ce nu poate fi arătat unui străin nu s-a întâmplat, din punctul de vedere al auditului.
Primul principiu este că nu trebuie să te păcălești pe tine însuți — iar tu ești persoana cea mai ușor de păcălit.Richard P. Feynman, «Cargo Cult Science», discursul de absolvire la Caltech, 1974, publicat în Engineering and Science, iunie 1974
De ce contează La audit, diferența dintre o observație și o neconformitate e adesea doar existența unui artefact cu dată și autor.
Pe larg →Strânge ↑
Memoria nu minte din răutate; ea refăcerește trecutul de fiecare dată. După o săptămână, decizia luată ieri pare deja mai corectă decât era. Artefactul scris oprește această rescriere lentă. Nu e doar dovadă pentru auditor, e un punct fix împotriva propriului tău creier. Gândește-te la o întâlnire în care toți pleacă convinși de lucruri ușor diferite. Nota trimisă după aceea devine singura versiune reală. Feynman avertiza că te păcălești cel mai ușor pe tine; articolul cu dată e apărarea ta. Dar ce se întâmplă când înregistrezi ceva ce nu ai făcut de fapt?
Pasajul 1 s-a oprit la întrebare; aici e răspunsul: înregistrarea falsă nu e doar o minciună pe hârtie, e o contaminare a întregului lanț. Fiecare artefact cu dată devine punct de plecare pentru deciziile următoare. Dacă jurnalul de test spune ceva ce nu s-a întâmplat, colegul de luna viitoare construiește pe un fundament inventat. Feynman a văzut asta la laboratoare: rezultate ajustate ușor, cu bune intenții, care au dus întreaga comunitate pe un drum greșit. Exemplul de zi cu zi: completezi astăzi lista de verificare a mașinii din memorie, pentru că „oricum am verificat-o ieri”. Mâine, altcineva pleacă la drum având încredere într-o verificare care nu a existat. Documentul sincer e greu de scris; documentul fals e ușor de scris și costă pe toți ceilalți. Dar ce te împiedică, în practică, să scrii sincer, când nimeni nu verifică în acel moment?
- 08
Un SMSI nu e o listă de controale, ci mecanismul care decide ce controale sunt necesare, le pune în funcțiune și verifică dacă mai sunt potrivite.
ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements · ISO/IEC · 2022
Un SMSI — sistem de management al securității informației — nu e o listă de controale, ci mecanismul care decide ce controale sunt necesare, le pune în funcțiune și verifică dacă mai sunt potrivite. Standardul o spune direct în introducere: sistemul păstrează confidențialitatea, integritatea și disponibilitatea informației aplicând un proces de management al riscului. Controalele din Anexa A, 93 la număr, grupate în ediția din 2022 în patru teme — organizaționale, oameni, fizice, tehnologice — sunt consecința evaluării riscului, nu punctul de plecare. Cerințele auditabile sunt clauzele 4–10: context, leadership, planificare, suport, operare, evaluarea performanței, îmbunătățire. Structura e comună tuturor standardelor de sistem de management scrise după 2012, ceea ce are o urmare practică: ISO 9001, ISO 22301 sau ISO/IEC 42001 pentru inteligența artificială folosesc aceleași clauze-cadru. O organizație care rulează deja unul dintre ele adaugă a doua schemă fără să reconstruiască politica, auditul intern sau analiza de management.
Sistemul de management al securității informației păstrează confidențialitatea, integritatea și disponibilitatea informației prin aplicarea unui proces de management al riscului și oferă încredere părților interesate că riscurile sunt gestionate adecvat.ISO/IEC 27001:2022, Introducere, 0.1 «General»
De ce contează Cine începe cu Anexa A construiește o listă de sarcini; cine începe cu clauzele 4–10 construiește sistemul pe care îl va audita organismul de certificare.
Pe larg →Strânge ↑
Pasul următor e decizia asupra domeniului de aplicare. Înainte de orice risc sau control, standardul cere să spui exact ce acoperă sistemul: ce servicii, ce sedii, ce date. Alegerea nu e formală. Un domeniu prea larg promite ceva ce nu poți susține; unul prea îngust lasă afară exact riscurile care contează. Exemplu concret: o firmă cu un singur magazin online poate declara doar platforma de vânzări, cu plățile și baza de clienți, nu și contabilitatea internă. Domeniul devine apoi granița la care auditorul verifică totul. O întrebare naturală urmează: cine, în organizație, răspunde pentru că acestă graniță există și e respectată?
Pasajul 1 s-a încheiat cu o întrebare: cine răspunde pentru graniță? Clauza 5 dă răspunsul: conducerea de sus. Nu departamentul IT, ci cei care decid bugete și priorități trebuie să demonstreze implicare și să stabilească o politică de securitate. Practic, asta schimbă locul discuției. Dacă un magazin online decide că datele clienților contează, decizia nu se ia în echipa de dezvoltare, ci la nivelul care alege între creștere și protecție. Auditorul vorbește cu conducerea, nu doar cu specialiștii. Securitatea devine astfel o decizie de afaceri, cu un responsabil numit. Dar cine conduce ceva trebuie să știe spre ce ținte merge — și aici intră planificarea din clauza 6.
- 09
Domeniul de aplicare e singura propoziție pe care o citește un client și prima pagină pe care o citește un auditor; trebuie să reziste ambelor lecturi.
ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements · ISO/IEC · 2022
Clauza 4 cere trei lucruri înainte de orice control. Întâi, problemele interne și externe relevante pentru scopul organizației și pentru rezultatele așteptate de la sistem. Apoi, părțile interesate și cerințele lor — clienți, autorități, angajați, furnizori — pentru că o cerință contractuală neidentificată devine neconformitate la primul audit. Abia apoi vine domeniul de aplicare, la 4.3: limitele și aplicabilitatea sistemului, ținând cont de problemele de la 4.1, de cerințele de la 4.2 și de interfețele cu activități realizate de alte organizații. Greșeala clasică e la 4.3, în ambele direcții. Un domeniu prea îngust, o singură echipă sau un singur produs, trece ușor auditul, dar nu convinge niciun client care întreabă ce anume e certificat. Un domeniu prea larg, declarat înainte ca procesele să existe, transformă certificarea într-un proiect care nu se mai termină. Amendamentul 1:2024, publicat în februarie 2024, a adăugat la 4.1 și 4.2 obligația de a considera schimbările climatice ca posibilă problemă relevantă.
Organizația trebuie să determine limitele și aplicabilitatea sistemului de management al securității informației pentru a-i stabili domeniul de aplicare.ISO/IEC 27001:2022, clauza 4.3 «Determining the scope of the information security management system»
De ce contează Un domeniu de aplicare croit doar ca să treacă auditul produce un certificat pe care echipa de vânzări nu îl poate folosi.
Pe larg →Strânge ↑
Domeniul de aplicare nu e un document administrativ, ci o decizie de business scrisă în limbaj de audit. El spune exact ce procese, ce locații și ce date sunt acoperite de certificat. Gândește-l ca pe eticheta unui produs: prea vagă, nimeni nu cumpără; prea optimistă, revin reclamațiile. Un exemplu simplu: o firmă de software își include serviciul de suport clienți în domeniu, pentru că tocmai acolo curg cele mai multe date sensibile. Dacă suportul rămâne afară, clientul care verifică certificatul vede o gaură. Întrebarea următoare e practică: cum alegi granița fără să o trasezi nici prea fricos, nici prea curajos?
Înainte să trasezi granița, standardul îți cere două lecturi de teren. Prima privește problemele interne și externe care pot influența securitatea: legislație, tehnologie, forța pieței. A doua privește părțile interesate și ce cer fiecare: clientul care cere criptare, autoritatea care cere raportări, furnizorul care are acces la sistemele tale. Domeniul de aplicare nu se alege din mers, ci ca răspuns la aceste cerințe. Exemplu concret: un furnizor de găzduire cu acces la baza ta de date aduce cu el o obligație pe care nu o poți ignora doar pentru că nu e în contractul cu clientul final. Saltul următor e firesc: cum arată granița când și interfețele cu alții contează?
- 10
Clauza 5 nu cere un departament de securitate, ci dovezi că oamenii care decid bugetul conduc efectiv sistemul: politică, obiective, resurse, roluri.
ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements · ISO/IEC · 2022
Clauza 5 are trei alineate și toate încep cu «conducerea de vârf», nu cu «organizația». Diferența nu e stilistică: la 5.1 auditorul cere probe că oamenii care hotărăsc bugetul și direcția au făcut ceva verificabil — au asigurat că politica și obiectivele există și se potrivesc cu direcția strategică, au integrat cerințele în procesele curente ale organizației, au pus la dispoziție resurse, au promovat îmbunătățirea continuă. La 5.2 politica trebuie să fie potrivită scopului organizației, să conțină obiective sau cadrul pentru stabilirea lor și două angajamente: satisfacerea cerințelor aplicabile și îmbunătățirea continuă. Ea există ca informație documentată, se comunică intern și se pune la dispoziția părților interesate, după caz. La 5.3 rolurile se atribuie și se comunică, iar două responsabilități sunt numite explicit: conformitatea sistemului cu cerințele standardului și raportarea performanței lui către conducerea de vârf. De aceea interviurile de la etapa 2 nu se țin doar cu echipa tehnică.
Conducerea de vârf trebuie să demonstreze leadership și angajament în privința sistemului de management al securității informației prin: asigurarea faptului că politica de securitate a informației și obiectivele de securitate a informației sunt stabilite și sunt compatibile cu direcția strategică a organizației.ISO/IEC 27001:2022, clauza 5.1 «Leadership and commitment», paragraful introductiv și litera a)
De ce contează O neconformitate de clauza 5 nu se repară cu o unealtă: cere o decizie a conducerii, deci se închide cel mai lent dintre toate.
Pe larg →Strânge ↑
Pasajul 1: Conducerea de vârf înseamnă, la 27001, oamenii cu putere reală, nu titluri. Auditorul urmărește lanțul de la decizie la efect. Dacă directorul financiar aprobă bugetul, el trebuie să poată explica de ce securitatea primește cât primește. Un exemplu obișnuit: la o firmă de logistică, managerul general semnează politica, dar nu poate spune ce obiective conține. Semnătura nu e dovadă de conducere. Întrebarea care se pune apoi: cum arată o decizie verificabilă, nu doar una declarată?
O decizie verificabilă lasă urme în procesele care existau deja. Standardul nu cere o structură nouă, ci că cerințele de securitate intră în ce face organizația oricum. La o lanț de farmacii, asta înseamnă că regulile despre acces la rețetele electronice apar în procedura de angajare a farmacistului, nu într-un document separat pe care nimeni nu-l citește. Resursele se văd la fel: nu în promisiuni, ci în faptul că echipa are timp și oameni pentru ce i s-a cerut. Iar conducerea primescște periodic un răspuns la întrebarea simplă: sistemul funcționează sau nu? Dacă toate astea există, urmează întrebarea ce anume trebuie să conțină politica pe care conducerea o aprobă.
- 11
Evaluarea riscului nu produce o listă de temeri, ci o comparație cu criterii scrise dinainte, care poate fi refăcută de altcineva cu același rezultat.
ISO/IEC 27005:2022 — Information security, cybersecurity and privacy protection — Guidance on managing information security risks · ISO/IEC · 2022
Clauza 6.1.2 din ISO/IEC 27001:2022 cere un proces, nu un tabel. Litera a) cere criterii scrise: criteriile de acceptare a riscului și criteriile pentru efectuarea evaluărilor. Litera b) e cea care desparte metoda serioasă de improvizație — evaluările repetate trebuie să producă rezultate consecvente, valide și comparabile. Apoi vin identificarea riscurilor pentru pierderea confidențialității, integrității și disponibilității, împreună cu numirea proprietarilor de risc; analiza, adică estimarea consecințelor și a probabilității realiste și determinarea nivelurilor; și evaluarea, adică prima comparație cu criteriile de la litera a) și prioritizarea pentru tratare. Ghidul detaliat stă în ISO/IEC 27005:2022, ediția a patra, care pune față în față două căi de identificare: abordarea pe evenimente, care pornește de la scenarii și de la obiectivele afectate, și abordarea clasică pe active, care pornește de la inventar, amenințări și vulnerabilități. Prima e mai rapidă și mai apropiată de business, a doua e mai completă și mai lentă.
evaluarea riscului: procesul de comparare a rezultatelor analizei riscului cu criteriile de risc, pentru a determina dacă riscul și/sau semnificația lui sunt acceptabile sau tolerabileISO/IEC 27005:2022, 3.2.6 «risk evaluation» — definiție preluată din ISO Guide 73:2009, 3.7.1, modificată («significance» a înlocuit «magnitude»)
De ce contează Dacă doi analiști ai aceleiași organizații ies cu clasamente diferite pe aceleași riscuri, litera b) a clauzei 6.1.2 este deja picată.
Pe larg →Strânge ↑
Consecvența nu e doar un test de competență, ci ceea ce face evaluarea verificabilă. Dacă rezultatul depinde de cine scrie tabelul, nimeni nu poate verifica nimic. Cu criterii și metodă fixate dinainte, același proces poate fi reluat peste un an și diferențele înseamnă ceva: s-a schimbat situația, nu doar analistul. Gândește-te la un magazin online care evaluează riscul de indisponibilitate a plăților. Dacă metoda e aceeași, o creștere a nivelului de risc față de anul trecut e un semnal real, nu o schimbare de dispoziție. Dar cum se construiește o metodă care să dea aceleași rezultate în mâinile unor oameni diferiti?
Răspunsul la întrebarea din urmă stă în alegerea punctului de plecare. ISO/IEC 27005:2022 pune față în față două căi de identificare a riscurilor. Abordarea pe evenimente pornește de la scenarii și de la obiectivele afectate. Abordarea pe active pornește de la un inventar, apoi leagă amenințări și vulnerabilități de fiecare element. Prima e mai rapidă și mai apropiată de modul în care conducerea gândește. A doua e mai lentă, dar acoperă colțuri pe care scenariul le poate sări. Alege una, scrie-o în metodă, și doi analiști vor merge pe același drum. Un restaurant cu comenzi online poate porni de la evenimentul „sistemul de comenzi cade în weekendul de vârf”. Sau poate porni de la active: serverul, aplicația, datele clienților, fiecare cu propriile amenințări. Aceeași alegere, scrisă negru pe alb, e ceea ce face rezultatul repetabil. Dar odată identificate riscurile, cine decide ce e acceptabil și cine poartă răspunderea?
- 12
Controalele vin din tratarea riscului, iar Anexa A e doar verificarea că nu ai uitat ceva; Declarația de aplicabilitate consemnează ambele decizii.
ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements · ISO/IEC · 2022
Ordinea din 6.1.3 este citită greșit de aproape toți începătorii. Nu se pleacă de la Anexa A. Se aleg întâi opțiunile de tratare, ținând cont de rezultatele evaluării; apoi se determină toate controalele necesare pentru a pune în practică opțiunile alese — standardul spune limpede că ele pot fi proiectate de organizație sau luate din orice sursă; abia apoi se compară lista obținută cu Anexa A, ca verificare încrucișată că nu a fost omis nimic necesar. Rezultatul se consemnează în Declarația de aplicabilitate, singurul document care leagă riscurile de controale. Ea spune patru lucruri despre fiecare control: că este necesar, de ce a fost inclus, dacă este implementat sau nu, și de ce a fost exclus, când e cazul. Un control necesar dar neimplementat are voie să apară acolo; ce nu are voie e tăcerea. La final, planul de tratare și acceptarea riscului rezidual se aprobă de proprietarii riscurilor.
să producă o Declarație de aplicabilitate care conține: controalele necesare (vezi 6.1.3 b) și c)); justificarea includerii lor; dacă acele controale necesare sunt implementate sau nu; și justificarea excluderii oricăruia dintre controalele din Anexa A.ISO/IEC 27001:2022, clauza 6.1.3 litera d) — conținutul obligatoriu al Declarației de aplicabilitate
De ce contează Declarația de aplicabilitate e primul document cerut la etapa 1 și singurul care arată dacă sistemul chiar a pornit de la riscuri.
Pe larg →Strânge ↑
Pasajul precedent a arătat ordinea corectă: riscuri, opțiuni, controale, apoi comparație cu Anexa A. Următorul pas e să înțelegem ce se întâmplă când comparația găsește o diferență. Dacă un control din Anexa A nu apare în lista ta, nu e o eroare automată. Poate fi exclus, dar numai cu o justificare care arată de ce riscurile tale nu îl cer. De exemplu, o firmă fără birou fizic poate explica de ce un control despre securitatea zonei de birouri nu are ce proteja. Ce nu e voie e să omiți controlul în tăcere, fără motiv scris. Justificarea nu e o formalitate pentru auditor; e gândirea ta pusă pe hârtie. Iar când justificarea lipsește, auditorul nu mai poate vedea de unde a pornit sistemul. Dar ce se întâmplă cu controlul necesar pe care l-ai identificat, dar nu l-ai implementat încă?
Controlul necesar dar neimplementat este permis, cu o condiție: să fie consemnat ca atare în Declarația de aplicabilitate. Documentul devine astfel și o hartă a muncii rămase. Un control marcat ca necesar dar neimplementat arată o decizie conștientă, nu o neglijare. De pildă, o firmă mică știe că are nevoie de o politică de parole puternice, dar o scrie abia luna viitoare; în declarație, statutul ei este onest. Auditorul vede diferența dintre un plan în derulare și o casă de cărți. Ce aruncă sistemul dezechilibrat e tăcerea: un control absent din listă fără motiv, sau unul declarat implementat deși nu e. Declarația trebuie să spună adevărul despre fiecare rând, chiar când adevărul e incomod. Rămâne întrebarea cine semnează, în final, aceste decizii și riscul care rămâne după ele.
- 13
Obiectivele trebuie măsurate și comunicate, schimbările trebuie planificate, iar competența trebuie dovedită: clauzele 6.2, 6.3 și 7 transformă intenția în probe.
ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements · ISO/IEC · 2022
Clauza 6.2 cere obiective care se pot verifica: consecvente cu politica, măsurabile dacă este posibil, ținând cont de cerințele aplicabile și de rezultatele evaluării și tratării riscului, monitorizate, comunicate, actualizate și disponibile ca informație documentată. În plus, planificarea lor răspunde la cinci întrebări: ce se face, cu ce resurse, cine răspunde, până când și cum se evaluează rezultatele. «Creșterea nivelului de securitate» nu trece de acest filtru. Clauza 6.3 e nouă în ediția din 2022 și are o singură propoziție, dar e auditabilă: o schimbare a sistemului — sediu nou, furnizor nou de servicii în cloud, reorganizare — făcută la repezeală devine constatare. Clauza 7 asigură restul: resurse (7.1), competență determinată, asigurată și dovedită, cu evaluarea eficacității acțiunilor (7.2), conștientizarea privind politica, contribuția proprie și consecințele neconformării (7.3), comunicare planificată (7.4) și controlul informațiilor documentate (7.5).
Atunci când organizația stabilește că sunt necesare schimbări ale sistemului de management al securității informației, schimbările trebuie efectuate într-o manieră planificată.ISO/IEC 27001:2022, clauza 6.3 «Planning of changes» — clauză nouă în ediția din 2022
De ce contează Cele mai multe neconformități minore de la primul audit stau în clauza 7: dovezi de competență și de conștientizare care nu au fost păstrate.
Pe larg →Strânge ↑
Cele trei clauze formează de fapt un singur obicei: nu face nimic important fără să poți arăta mai târziu cum ai decis, cine a fost pregătit și ce a ieșit. Măsurarea obiectivelor nu e birocrație, ci memoria organizației. Dacă obiectivul e „mai puține incidente de acces”, trebuie spus cine numără, cu ce frecvență și unde rămâne rezultatul. Un exemplu simplu: la mutarea biroului, cine semnează că personalul a fost instruit pentru noul control al accesului? Fără acel semn, schimbarea pare făcută la repezeală. Auditul nu întreabă dacă ai grijă, ci ce poți arăta. Iar proba cea mai des lipsă nu e politica, ci evidența pregătirii oamenilor. Următorul pas: cum arată o probă bună de competență în practică.
- 14
Clauzele 6.1.2 și 6.1.3 cer metoda, iar 8.2 și 8.3 cer execuția ei: aceleași cuvinte, alt verb și alte dovezi.
ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements · ISO/IEC · 2022
Clauza 8 e locul unde sistemul chiar funcționează. La 8.1 organizația planifică, implementează și controlează procesele necesare pentru a îndeplini cerințele și pentru a pune în practică acțiunile stabilite la clauza 6, păstrează informații documentate care arată că procesele s-au desfășurat conform planului, controlează schimbările planificate și analizează consecințele celor neintenționate. Tot aici stă cerința despre externalizare: procesele, produsele sau serviciile furnizate din exterior și relevante pentru sistem trebuie determinate și ținute sub control. Nu trebuie recertificate, ci controlate. Confuzia clasică de examen este între 6.1.2 și 8.2. Prima cere să existe un proces de evaluare a riscului, definit și aplicat; a doua cere ca acel proces să fie rulat efectiv, la intervale planificate și la schimbări semnificative, iar rezultatele să fie păstrate. Aceeași pereche există și pentru tratare: 6.1.3 definește procesul, iar 8.3 cere implementarea planului și păstrarea rezultatelor.
Organizația trebuie să efectueze evaluări ale riscului de securitate a informației la intervale planificate sau atunci când sunt propuse ori apar schimbări semnificative, ținând cont de criteriile stabilite la 6.1.2 a).ISO/IEC 27001:2022, clauza 8.2 «Information security risk assessment», prima propoziție
De ce contează Un dosar impecabil de clauza 6 fără dovezi de clauza 8 descrie un sistem proiectat, nu unul care funcționează.
Pe larg →Strânge ↑
Perechea 6-8 schimbă felul în care citești orice cerință din standard. Nu întrebi doar "ce trebuie să existe", ci "cine l-a rulat, când și ce a rămas în urmă". Un auditor nu se oprește la procedura scrisă; urmărește urma lăsată de execuție. Gândește-te la rețeta de copt: a o avea scrisă pe hârtie nu e același lucru cu un cuptor care miroase a coaptă și cu un carnețel în care notezi temperaturile. Diferența dintre cele două clauze e, de fapt, diferența dintre intenție și faptă. Iar urma aceea are o structură pe care merită să o descompunem: ce anume trebuie păstrat ca dovadă, și ce o face convingătoare?
Pasajul 2 privește ce anume rămâne în urmă după execuție. La 8.2, dovada nu e doar raportul final, ci și faptul că evaluarea a folosit criteriile fixate la 6.1.2: ce consideri risc acceptabil, pe ce scară măsori. Dacă criteriile s-au schimbat între două rulări, raportul trebuie să arate asta. Exemplu concret: la recrutare, nu ajunge lista finală de candidați; contează grila de evaluare aplicată și cine a semnat-o. La 8.3, urma e planul de tratare transformat în decizii: riscuri acceptate, modificate sau transferate, fiecare cu dovada acțiunii. Iar 8.1 adaugă o cerință ușor trecută cu vederea: furnizorii externi. Un serviciu cloud sau un contabil extern țin în mâini procese din sistemul tău; trebuie determinați și controlați, nu doar menționați într-un contract. Rămâne însă o întrebare: ce se întâmplă când execuția dezvăluie că planul însuși era greșit?
- 15
Clauza 9 cere trei lucruri diferite: să măsori, să te auditezi cu ochi independent și să pui rezultatele pe masa conducerii.
ISO 19011:2026 — Guidelines for auditing management systems · ISO · 2026
La 9.1 organizația decide ce monitorizează și măsoară, prin ce metode, când și de către cine, iar metodele alese trebuie să dea rezultate comparabile și reproductibile ca să fie considerate valide. La 9.2 se cere un program de audit intern — frecvență, metode, responsabilități, cerințe de planificare și raportare — construit ținând cont de importanța proceselor și de rezultatele auditurilor anterioare; auditorii trebuie aleși astfel încât să asigure obiectivitatea și imparțialitatea procesului. La 9.3 conducerea de vârf analizează sistemul pe o listă fixă de intrări: stadiul acțiunilor anterioare, schimbările de context și de cerințe ale părților interesate, performanța sistemului, rezultatele auditurilor, îndeplinirea obiectivelor, rezultatele evaluării riscului și oportunitățile de îmbunătățire. Ghidul de metodă este ISO 19011, a cărui ediție a patra a apărut în mai 2026 și înlocuiește ediția din 2018; fiind standard de recomandări, se aplică imediat, fără perioadă de tranziție.
Independența este baza imparțialității auditului și a obiectivității concluziilor de audit. Auditorii ar trebui să fie independenți de activitatea auditată ori de câte ori este posibil și ar trebui, în toate cazurile, să acționeze într-o manieră lipsită de părtinire și de conflict de interese.ISO 19011:2026, 4.6 «Independence» — ediția a patra, publicată în mai 2026, care înlocuiește ISO 19011:2018
De ce contează Cine implementează un proces nu îl poate audita: independența este condiția care face din auditul intern o verificare, nu o confirmare.
Pe larg →Strânge ↑
Clauza 9 nu cere trei obligații paralele, ci un lanț în care fiecare verigă se hrănește din precedenta. Datele măsurate la 9.1 devin materia primă pe care auditorul intern le verifică la 9.2. Concluziile auditului intră apoi, la 9.3, pe lista fixă de intrări ale analizei conducerii, alături de performanță și de riscuri. Dacă o verigă slăbește, întregul lanț produce doar hârtie. Gândește-te la un restaurant: rețetele sunt măsurătorile, controlul din bucătărie e auditul, iar ședința săptămânală a proprietarului e analiza conducerii. Dacă bucătarul care gătește își controlează singur faruri, controlul devine confirmare, nu verificare. Întrebarea care urmează: unde se rupe de fapt acest lanț, în organizația ta?
- 16
Corecția repară incidentul, acțiunea corectivă repară motivul pentru care a fost posibil; standardul le cere pe amândouă, iar auditorul le distinge.
Out of the Crisis · W. Edwards Deming · 1986
În ediția din 2022 ordinea s-a schimbat: 10.1 este îmbunătățirea continuă, iar 10.2 neconformitatea și acțiunea corectivă. Cerința are două jumătăți. Întâi reacționezi la neconformitate: o ții sub control, o corectezi și te ocupi de consecințe. Apoi evaluezi dacă e nevoie de acțiune pentru a elimina cauzele, ca să nu reapară și să nu apară în altă parte — analizezi neconformitatea, îi determini cauzele și verifici dacă există sau ar putea exista neconformități similare. La final analizezi eficacitatea acțiunii corective și, dacă e cazul, schimbi sistemul. Se păstrează natura neconformităților, acțiunile întreprinse și rezultatele lor. Un laptop pierdut se înlocuiește: asta e corecția. Motivul pentru care criptarea discului nu era impusă pe toate laptopurile se elimină: asta e acțiunea corectivă. Pasul sărit cel mai des este ultimul, analiza eficacității — fără el, tichetul e închis, dar neconformitatea nu.
Calitatea nu vine din inspecție, ci din îmbunătățirea procesului de producție.Out of the Crisis (MIT Press, 1986), cap. 2, p. 29 — comentariul la Punctul 3 al celor 14 puncte, despre renunțarea la dependența de inspecție
De ce contează Aceeași constatare care revine an de an înseamnă că s-au făcut numai corecții, iar asta e cel mai frecvent motiv pentru care o neconformitate se agravează.
Pe larg →Strânge ↑
Deming a văzut în fabrici același gest pe care îl vedem azi în birouri: se repară rapid, apoi toată lumea respiră ușurată. Corecția dă senzația că s-a terminat ceva. Dar dacă procesul rămâne neschimbat, aceeași problemă se întoarce, doar cu altă dată. Gândește-te la un coleg care își uită mereu badge-ul la intrare. Ii deschizi poarta de fiecare dată: corecție. Instalați o citire automată a badge-ului în fluxul de acces: acțiune corectivă. Diferența nu e în gravitate, ci în întrebare: am reparat doar incidentul, sau și motivul pentru care era posibil? Auditorii nu cer să nu ai neconformități. Cer să poți arăta ambele jumătăți, fiecare cu dovezi. Iar cea mai grea dovadă rămâne cea din urmă: că acțiunea corectivă chiar a funcționat.
- 17
Anexa A din 2022 are 93 de controale în patru teme și este o listă de verificare încrucișată, nu un plan de proiect pe care trebuie să îl bifezi integral.
ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements · ISO/IEC · 2022
Ediția din 2022 a restructurat anexa: din 114 controale grupate în 14 clauze au rămas 93, grupate în patru teme — organizaționale (37), oameni (8), fizice (14) și tehnologice (34). Unsprezece sunt complet noi: informații despre amenințări (5.7), securitatea informației la utilizarea serviciilor în cloud (5.23), pregătirea tehnologiei pentru continuitatea activității (5.30), monitorizarea securității fizice (7.4), managementul configurațiilor (8.9), ștergerea informațiilor (8.10), mascarea datelor (8.11), prevenirea scurgerilor de date (8.12), activități de monitorizare (8.16), filtrarea traficului web (8.23) și codarea securizată (8.28). Ghidul de implementare stă în ISO/IEC 27002:2022, care adaugă fiecărui control cinci atribute pentru filtrare: tipul controlului, proprietățile securității informației, conceptele de securitate cibernetică, capabilitățile operaționale și domeniile de securitate. Atributele sunt un instrument de sortare, nu cerințe suplimentare. Iar 27002 este un ghid: nimeni nu se certifică după el.
Controalele de securitate a informației enumerate în Anexa A nu sunt exhaustive și pot fi incluse controale suplimentare de securitate a informației, dacă este nevoie.ISO/IEC 27001:2022, clauza 6.1.3 c), NOTA 3
De ce contează Proiectele care încep prin a implementa toate cele 93 de controale cheltuiesc mult pe riscuri pe care nu le au și pică oricum la Declarația de aplicabilitate.
Pe larg →Strânge ↑
Ordinea corectă e inversul instinctului: întâi riscurile, apoi controalele. Anexa A funcționează ca un dicționar de opțiuni, nu ca o listă de cumpărături. Alegi din ea doar ce răspunde la un risc real al organizației tale. Restul intră în Declarația de aplicabilitate cu o justificare de excludere — și asta e perfect legitim. Exemplu: o firmă fără birou propriu nu are ce gestiona la tema fizică dincolo de laptopurile angajaților. Standardul spune explicit că lista nu e exhaustivă, deci poți adăuga controale proprii. Pe scurt: Anexa A răspunde la întrebarea "ce există", nu "ce îți trebuie". Următorul pas e să vedem cum decizi, control cu control, ce intră și ce rămâne afară.
Cum decizi, control cu control? Ediția din 2022 a restructurat lista: 93 de controale în patru teme, de la organizare până la tehnologie. Unsprezece sunt noi, printre ele securitatea cloud, ștergerea datelor și codarea securizată. Semnalul e clar: lista urmărește cum se lucrează azi, nu e un set fix și etern. Dar ea spune doar ce există, nu cum se aplică. Detaliile practice stau în ISO/IEC 27002, care adaugă fiecărui control atribute de filtrare — tip de control, capabilități operaționale, domenii de securitate. Sunt un instrument de sortare, nu cerințe în plus. Iar 27002 e doar ghid: nimeni nu se certifică după el. Exemplu concret: dacă alegi controlul pentru cloud, atributele te trimit rapid spre ghidul de implementare, nu prin toată lista. Următorul pas: ce faci cu riscurile pentru care niciun control din listă nu e suficient.
- 18
O analiză a decalajelor utilă compară cerința cu dovada existentă, nu cu intenția: ce cere standardul, ce ai, cine închide diferența și până când.
The Art of War · Sun Tzu, traducere Lionel Giles · 1910
Standardul cere explicit informații documentate în paisprezece locuri: domeniul de aplicare (4.3), politica (5.2), procesul de evaluare a riscului (6.1.2), procesul de tratare a riscului și Declarația de aplicabilitate (6.1.3), obiectivele (6.2), dovezile de competență (7.2), dovezile că procesele s-au desfășurat conform planului (8.1), rezultatele evaluărilor de risc (8.2), rezultatele tratării (8.3), rezultatele monitorizării și măsurării (9.1), programul și rezultatele auditului intern (9.2), rezultatele analizelor de management (9.3) și, la 10.2, natura neconformităților, acțiunile întreprinse și rezultatele lor. Peste ele se adaugă documentele cerute de controalele reținute în Declarație: politici tematice, inventarul informațiilor și al activelor asociate, regulile de utilizare acceptabilă și celelalte. O analiză a decalajelor bună are o linie pentru fiecare cerință și trei coloane: ce cere standardul, ce dovadă există astăzi și unde, apoi decizia — conform, parțial sau absent, cu un proprietar și un termen. Procentele fără proprietari nu închid nimic.
Dacă îți cunoști dușmanul și te cunoști pe tine, nu trebuie să te temi de rezultatul a o sută de bătălii. Dacă te cunoști pe tine, dar nu îl cunoști pe dușman, pentru fiecare victorie câștigată vei suferi și o înfrângere. Dacă nu cunoști nici dușmanul, nici pe tine însuți, vei pierde în fiecare bătălie.The Art of War, traducerea Lionel Giles (1910), cap. III «Attack by Stratagem», §18
De ce contează Etapa 1 se pică cel mai des nu din lipsă de controale, ci din lipsa dovezilor documentate pe care standardul le cere pe nume.
Pe larg →Strânge ↑
O analiză a decalajelor se strică în mod tacit atunci când dovada există doar pe hârtie. O politică semnată nu înseamnă nimic dacă nimeni nu o aplică. Verifică practica reală, nu doar fișierul din folder. Întreabă oamenii cum lucrează de fapt și compară răspunsul cu documentul. Dacă cele două nu se potrivesc, decalajul e mai mare decât scria în tabel. Exemplu simplu: regula spune că accesul se revizuiește trimestrial, dar ultimul extras datează de doi ani. Atunci cerința e parțială, nu conformă, indiferent cât de frumos e redactată politica. Următorul pas: cum transformi aceste constatări în acțiuni pe care cineva chiar le duce la capăt.
Un tabel de decalaje devine util abia când fiecare linie are un proprietar cu putere reală de decizie. Nu persoana care știe cel mai mult despre subiect, ci cea care poate aloca timp și bani. Un risc tratat de cineva fără buget rămâne pe hârtie. Termenul trebuie să fie o dată verificabilă, nu urgență, nu curând, nu trimestrul acesta. Iar starea parțială e mai valoroasă decât conformul optimist: spune exact ce lipsește. Exemplu concret: în loc de accesul se revizuiește, scrie că Ana din operațional va livra extrasele de acces ale tuturor sistemelor până pe o dată anume, cu un rezervor de ore alocat de manager. Dacă data trece fără livrare, decalajul nu a dispărut, doar s-a mutat. Atunci întrebarea devine alta: cine verifică că termenul a fost respectat și ce se întâmplă când nu a fost.
- 19
Certificarea nu e un eveniment, ci un ciclu de trei ani: două etape la început, supraveghere în fiecare an, recertificare la capăt.
Remarks on Signing the Intermediate-Range Nuclear Forces Treaty · Ronald Reagan · 1987
Auditul de certificare vine în două etape. Etapa 1 se uită la documentație și la gradul de pregătire: domeniul de aplicare, politica, evaluarea și tratarea riscului, declarația de aplicabilitate, dovada că auditul intern și analiza de management chiar au avut loc. Rezultatul ei nu e o notă, ci planul etapei 2 și lista lucrurilor care ar bloca-o. Etapa 2 verifică implementarea: se cer înregistrări din perioada scursă, se intervievează oameni din procese, se compară ce scrie cu ce se face. După certificat urmează supravegherea anuală, pe un eșantion de procese și controale, și recertificarea completă la trei ani. Organismul care emite certificatul e el însuși acreditat după ISO/IEC 17021-1, în România de organismul național de acreditare RENAR; un certificat fără acreditare în spate e o hârtie, nu o recunoaștere. Din același motiv de independență, cine a implementat sistemul nu îl poate și audita.
Am ascultat înțelepciunea unei vechi maxime rusești. Și sunt sigur că vă este familiară, domnule secretar general, deși pronunția mea s-ar putea să vă dea bătăi de cap. Maxima este: Dovorey no provorey — ai încredere, dar verifică.Ronald Reagan, cuvântare la semnarea Tratatului privind forțele nucleare cu rază intermediară, Casa Albă, 8 decembrie 1987 — arhiva Bibliotecii Prezidențiale Reagan
De ce contează Ordinea etapelor spune unde se pierde timpul: cine intră în etapa 2 fără înregistrări din perioada scursă amână certificatul, nu îl grăbește.
Pe larg →Strânge ↑
Reagan a împrumutat de la ruși o maxima despre încredere și verificare. Ideea merge mai departe: verificarea nu e un gest unic, ci un ritm. Certificarea unui sistem de management funcționează la fel. Nu te uiți o dată la ceva și gata, ci stabilești un ciclu cu termene cunoscute din start. Gândește-te la vizita medicală pentru permisul de conducere: nu dovedești o dată pentru totdeauna că vezi bine, ci revii la intervale fixate. Diferența e că aici ciclul are structură: etape pregătitoare, apoi verificări anuale, apoi reluarea completă. Ritmul există tocmai pentru că încrederea se uzează, iar sistemele se schimbă. Întrebarea firească este ce se întâmplă de fapt în fiecare dintre aceste momente ale ciclului.
Ciclul începe cu o divizare pe care mulți o ratează: certificarea nu se cere dintr-o dată, ci în două etape. Prima nu caută defecte în practică, ci citește hârtiile și pregătirea. Verifică dacă domeniul e definit, dacă politica și evaluarea riscurilor există, dacă auditul intern și analiza managementului chiar s-au ținut. Rezultatul nu e o notă, ci un plan: ce se verifică în etapa a doua și ce ar putea s-o blocheze. E ca vizita la arhitect înainte de renovare: nu demolăm nimic, dar aflatăm unde sunt pereții portanți. Cine sare peste etapa 1 intră în etapa 2 orb. Iar etapa 2 cere altceva: înregistrări din perioada scursă și oameni care povestesc cum lucrează. Ce urmează după ce certificatul ajunge pe perete?
- 20
O constatare de audit nu e o părere: e o abatere de la o cerință, sprijinită pe ceva verificabil, iar gravitatea ei decide dacă certificatul mai poate fi emis.
ISO 19011:2018 — Guidelines for auditing management systems · ISO · 2018
Constatările vin pe patru trepte. Oportunitatea de îmbunătățire nu e o abatere, e o sugestie. Observația semnalează ceva care încă respectă cerința, dar merge într-o direcție proastă. Neconformitatea minoră e o scăpare izolată dintr-o cerință. Neconformitatea majoră e altceva: absența completă a unei cerințe, o defecțiune sistemică sau un eșec care pune la îndoială capacitatea sistemului de a-și atinge rezultatele. Diferența nu e de ton, ci de consecință — o majoră deschisă blochează decizia de certificare. Răspunsul are patru părți, în ordinea asta: corecția, adică repararea cazului găsit; analiza cauzei-rădăcină; acțiunea corectivă, care schimbă procesul astfel încât situația să nu se repete; și un termen asumat. Cine trimite doar corecția primește constatarea înapoi. Fiecare constatare se sprijină pe dovadă obiectivă — o înregistrare, o declarație de fapt sau altă informație relevantă și verificabilă — nu pe impresia auditorului.
Dovadă de audit: înregistrări, declarații de fapt sau alte informații care sunt relevante pentru criteriile de audit și verificabile.ISO 19011:2018, clauza 3.8 — definiția dovezii de audit (platforma de consultare ISO e randată în JavaScript și a răspuns 403 la verificare)
De ce contează Confuzia dintre minor și major costă săptămâni: o majoră nu se închide cu o scuză, ci cu o schimbare de proces demonstrată.
Pe larg →Strânge ↑
Pasul următor e felul în care e scrisă constatarea. O constatare bună are trei piese: cerința încălcată, ceea ce s-a constatat și dovada care leagă cele două. Dacă lipsește una, firma nu știe ce să repare. Spune auditorului: cerința cere ca fiecare echipă să aibă instrucțiunea actualizată. La postul de lucru numărul doi, instrucțiunea e din anul trecut, și asta se vede din fișierul verificat azi. Firma știe exact ce să corecteze. O formulare vagă, de tipul procedura nu e respectată corespunzător, nu e o constatare, e o impresie îmbrăcată în limbaj tehnic. Ceea ce ridică întrebarea: cine verifică că răspunsul firmei acoperă chiar cerința din constatare?
- 21
Din 1 noiembrie 2025 nu mai există certificate pe ediția 2013: orice audit se face pe 2022, cu Anexa A de 93 de controale și cu clima în context.
IAF MD 26:2023 — Transition Requirements for ISO/IEC 27001:2022 · International Accreditation Forum · 2023
Tranziția s-a încheiat. Documentul obligatoriu al forului internațional de acreditare, IAF MD 26:2023, a fixat o perioadă de trei ani de la publicarea ediției 2022 și a spus fără nuanțe că certificările pe ediția 2013 expiră sau se retrag la capătul ei — 31 octombrie 2025. În 2026 întrebarea nu mai e cum treci, ci ce ai de arătat pe ediția curentă. Ce s-a schimbat concret: clauza 6.3 cere planificarea schimbărilor aduse sistemului; capitolul 10 și-a inversat ordinea, îmbunătățirea continuă venind înaintea neconformității și acțiunii corective; Anexa A a trecut de la 114 la 93 de controale, restructurate în patru teme, cu unsprezece controale noi, între care informațiile despre amenințări, securitatea în cloud, gestionarea configurațiilor, mascarea datelor și codificarea sigură. Amendamentul 1:2024 a adăugat la clauzele 4.1 și 4.2 obligația de a lua în considerare schimbările climatice ca aspect relevant al contextului.
Toate certificările bazate pe ISO/IEC 27001:2013 vor expira sau vor fi retrase la sfârșitul perioadei de tranziție.IAF MD 26:2023, Issue 2 (emis 15 februarie 2023), §4.2 «CAB Actions» — acțiunile organismului de certificare
De ce contează Un plan de conformitate care încă vorbește despre 114 controale e scris pentru un standard care nu se mai auditează nicăieri.
Pe larg →Strânge ↑
Expirarea certificatelor pe 2013 nu e doar o dată de calendar; e o schimbare de rol pentru organizație. Înainte, tranziția era un proiect cu termen. Acum, ediția 2022 e pur și simplu standardul la care trăiești zi de zi. Diferența se vede în practică: nu mai pregătești un dosar de migrare, ci întreții un sistem care deja vorbește limba nouă. Gândește-te la un magazin care a trecut de la casă de marcat veche la una digitală. La început, tranziția era evenimentul. După, nimeni nu mai vorbesc despre trecere; contează că bonul iese corect în fiecare zi. La fel aici: întrebarea utilă în 2026 e ce dovezi live poți arăta unui auditor, nu ce ai făcut cândva pentru trecere. Și asta duce la o întrebare firească: cine verifică, de fapt, că organizația e pe ediția corectă?
Pasajul 1 s-a întrebat cine verifică ediția. Răspunsul e lanțul de acreditare: organismele de certificare nu răspund doar clienților, ci unor entități de acreditare, iar acestea urmează regulile forului internațional. Documentul de tranziție le-a dat termenul limită și le-a cerut să planifice auditurile în consecință. Adică presiunea nu vine de la auditorul din fața ușii, ci de la structura care îl autorizează pe el. Un exemplu obișnuit: la un control tehnic auto, mașina nu e verificată de mecanicul oricui, ci de o stație autorizată care respectă proceduri fixate de stat. Dacă stația nu se conformează, își pierde autorizația. La fel, un organism de certificare care ar emite încă pe ediția veche și-ar pune în joc propria acreditare. Ceea ce ridică următoarea întrebare: ce anume din standardul nou e verificat mai atent acum?
- 22
NIS2 mută securitatea din subsolul tehnic în sala de consiliu: măsurile devin obligații legale, iar conducerea răspunde personal pentru ele.
Directiva (UE) 2022/2555 privind măsuri pentru un nivel comun ridicat de securitate cibernetică în Uniune · Parlamentul European și Consiliul Uniunii Europene · 2022
Directiva (UE) 2022/2555, pe scurt NIS2, e transpusă în România prin Ordonanța de urgență 155/2024, publicată în Monitorul Oficial nr. 1332 din 31 decembrie 2024; autoritatea competentă este Directoratul Național de Securitate Cibernetică. Entitățile acoperite se împart în esențiale și importante, iar diferența stă în regimul de supraveghere și în plafonul amenzilor, nu în setul de măsuri. Articolul 21 cere măsuri adecvate și proporționale, pe o abordare care ia în calcul toate pericolele, și enumeră zece categorii minime: analiza riscului, tratarea incidentelor, continuitatea, securitatea lanțului de aprovizionare, achiziția și dezvoltarea sigură, evaluarea eficacității, igiena cibernetică și instruirea, criptografia, securitatea resurselor umane și controlul accesului, autentificarea cu mai mulți factori. Articolul 23 fixează ritmul: avertizare timpurie în 24 de ore, notificare în 72, raport final într-o lună. Articolul 20 spune că organul de conducere aprobă măsurile și poate fi tras la răspundere.
Statele membre se asigură că entitățile esențiale și importante iau măsuri tehnice, operaționale și organizatorice adecvate și proporționale pentru a gestiona riscurile la adresa securității rețelelor și a sistemelor informatice pe care aceste entități le utilizează pentru operațiunile lor sau pentru furnizarea serviciilor lor și pentru a preveni sau a reduce la minimum impactul incidentelor asupra beneficiarilor serviciilor lor și asupra altor servicii.Directiva (UE) 2022/2555 (NIS2), art. 21 alin. (1), primul paragraf — măsuri de gestionare a riscurilor de securitate cibernetică
De ce contează Cele zece categorii din articolul 21 se suprapun aproape una la una peste controalele Anexei A, deci un sistem certificat devine schelet de conformitate, nu un proiect paralel.
Pe larg →Strânge ↑
Cardul spune că NIS2 mută răspunderea în sala de consiliu. Pasul următor: legea nu impune un pachet fix de măsuri, ci un rezultat. Articolul 21 cere măsuri adecvate și proporționale riscurilor fiecărei entități. Deci o firmă mică cu date sensibile poate avea obligații mai grele decât una mare cu risc scăzut. Proporționalitatea se judecă după ce s-ar întâmpla dacă sistemul ar cădea, nu după numărul de angajați. Exemplu: un laborator medical cu douăzeci de persone care ține rezultate de analize trebuie să protejeze acele date ca pe un activ de business, pentru că pacienții depind de ele. Conducerea trebuie deci mai întâi să înțeleagă propriile riscuri, înainte să aleagă orice instrument. Cum se face concret această înțelegere a riscurilor?
- 23
DORA nu cere un sistem de management al securității, ci reziliență demonstrată: că sistemul rezistă, că știi cui i-ai dat cheile și că ai testat asta ca un atacator.
Regulamentul (UE) 2022/2554 privind reziliența operațională digitală a sectorului financiar · Parlamentul European și Consiliul Uniunii Europene · 2022
Regulamentul (UE) 2022/2554 se aplică direct entităților financiare din 17 ianuarie 2025 și stă pe cinci piloni: gestionarea riscului legat de tehnologia informației și comunicațiilor, tratarea și raportarea incidentelor, testarea rezilienței operaționale digitale, riscul furnizorilor terți de servicii tehnologice și schimbul de informații despre amenințări. Două cerințe nu au echivalent într-un sistem de management clasic. Prima este registrul de informații: fiecare acord contractual pentru servicii tehnologice, cu funcția pe care o susține, într-un format pe care supraveghetorul îl poate cere integral. A doua este testarea avansată bazată pe amenințări, obligatorie cel puțin o dată la trei ani pentru entitățile identificate de autoritatea competentă — o simulare pe sistemele reale, nu o scanare de vulnerabilități. Peste ele, furnizorii desemnați critici intră sub supravegherea directă a autorităților europene de supraveghere. Un sistem certificat acoperă bine primul pilon și mare parte din al doilea; restul cere lucruri noi.
Entitățile financiare dispun de un cadru intern de guvernanță și control care asigură o gestionare eficace și prudentă a riscului legat de TIC, în conformitate cu articolul 6 alineatul (4), pentru a atinge un nivel ridicat de reziliență operațională digitală.Regulamentul (UE) 2022/2554 (DORA), art. 5 alin. (1) — guvernanță și organizare
De ce contează Cine crede că un certificat acoperă DORA descoperă la prima inspecție că registrul de informații și testarea bazată pe amenințări nu erau în domeniul lui de aplicare.
Pe larg →Strânge ↑
DORA mută răspunderea sus, în consiliu. Nu IT-ul semnează că sistemul e rezistent, ci conducerea entității răspunde personal pentru asta. Reziliența e tratată ca o stare care trebuie dovedită încontinuu, nu ca un document aprobat o dată pe an. Practic, un membru al conducerii trebuie să poată spune, fără să deschidă un raport, cine are acces la sistemele critice și când a fost testat ultimul scenariu de atac. E ca la un bloc: nu te uiți după hârtia de la instalarea liftului, ci după procesul-verbal al reviziei curente. Aici apare întrebarea practică: ce înseamnă, concret, ca un consiliu să demonstreze reziliență, nu doar să o declare?
- 24
Din 11 septembrie 2026, orice produs cu elemente digitale vândut în Uniune are obligații de raportare a vulnerabilităților exploatate activ, cu ceasul pornit la 24 de ore.
Regulamentul (UE) 2024/2847 privind cerințe orizontale de securitate cibernetică pentru produsele cu elemente digitale · Parlamentul European și Consiliul Uniunii Europene · 2024
Regulamentul (UE) 2024/2847, pe scurt actul privind reziliența cibernetică, mută răspunderea pe fabricant: produsul trebuie proiectat, dezvoltat și fabricat după cerințele esențiale din partea I a anexei I, iar riscul se evaluează și se documentează pe toată durata perioadei de suport. Practic înseamnă livrare fără vulnerabilități cunoscute exploatabile, configurare sigură implicită, actualizări de securitate și o listă a componentelor software pentru dependențele de nivel superior. Calendarul e etajat. Obligațiile de raportare din articolul 14 se aplică din 11 septembrie 2026: o vulnerabilitate exploatată activ se anunță printr-o avertizare timpurie în 24 de ore, printr-o notificare în 72 de ore și cu un raport final în 14 zile. Restul regulamentului se aplică din 11 decembrie 2027. Pentru cine are deja un sistem certificat, controalele de dezvoltare sigură din Anexa A, 8.25-8.28, de la ciclul de viață securizat până la codificarea sigură, sunt exact locul de unde se pornește.
La introducerea pe piață a unui produs cu elemente digitale, fabricanții se asigură că acesta a fost proiectat, dezvoltat și fabricat în conformitate cu cerințele esențiale de securitate cibernetică prevăzute în partea I din anexa I.Regulamentul (UE) 2024/2847 (actul privind reziliența cibernetică), art. 13 alin. (1) — obligațiile fabricantului
De ce contează Termenul de 24 de ore nu se negociază în timpul incidentului: ori există un proces de tratare a vulnerabilităților care îl poate respecta, ori nu există.
Pe larg →Strânge ↑
Cardul spune când se pornește ceasul. Pasul următor e ce se întâmplă în cele 24 de ore, înainte de a ști ceva sigur. Notificarea timpurie nu cere o analiză completă, ci doar semnalul că o vulnerabilitate e exploatată activ și că produsul tău e afectat. Asta schimbă ordinea muncii: întâi anunți, apoi investighezi. Un proces clasic de securitate așteaptă diagnosticul complet înainte de a comunica; aici comunicarea vine prima. Gândește-te la un frigider conectat sau la o cameră video de acasă: dacă producătorul află luni că cineva o exploatează, ceasul a pornit deja. Deci întrebarea practică nu e „avem procedură?", ci „putem trimite o avertizare corectă într-o noapte?". Iar asta depinde de cine, în firmă, are puterea de a decide fără a aștepta șeful de dimineață.
Pasajul 1 s-a oprit la cine poate decide într-o noapte. Pasajul 2 privește ce se întâmplă după: cele 72 de ore și raportul final. Avertizarea timpurie spune doar „se întâmplă ceva". Notificarea de la 72 de ore trebuie să aducă primele fapte: ce afectează, cum se exploatează, cine e atins. Adică firma are nevoie de un canal gata făcut către autoritatea de securitate, nu de una găsită sub presiune. Gândește-te la un lanț de pizza: dacă nu știi dinainte cui telefonezi, comanda pierde oricum timpul cel mai scump. Iar raportul final, la 14 zile, închide povestea cu ce s-a cauzat și ce s-a reparat. Asta înseamnă că investigația, comunicarea și remedierea trebuie să ruleze paralel, nu la rând. Următoarea întrebare firească: cine, de fapt, primește aceste notificări și ce face cu ele?
Pasajul 2 s-a întrebat cine primește notificările. Răspunsul e gândit ca un filtru, nu ca o coadă: fabricantul trimite către un punct de contact desemnat, iar informația ajunge la rețeaua europeană de răspuns la incidente și la autoritățile de supraveghere a pieței. Scopul nu e doar să știe cine a fost lovit, ci să vadă imaginea de ansamblu. Dacă mai mulți producători raportează aceeași vulnerabilitate dintr-o componentă comună, problema se dezvăluie ca sistemică. Gândește-te la un bloc în care mai mulți vecini sesizează aceeași scurgere: separat, fiecare pare un accident; împreună, arată o defecțiune a țevii principale. Pentru fabricant asta înseamnă că raportarea nu e un act de conformitate izolat, ci o piesă dintr-un sistem de avertizare timpurie la nivel de Uniune. Următoarea întrebare: ce se întâmplă dacă vulnerabilitatea nu e a ta, ci a unui furnizor din lista componentelor?
- 25
Un sistem de management al inteligenței artificiale nu se construiește lângă cel de securitate, ci în el: aceleași clauze, alt registru de riscuri.
Regulamentul (UE) 2024/1689 de stabilire a unor norme armonizate privind inteligența artificială · Parlamentul European și Consiliul Uniunii Europene · 2024
Regulamentul (UE) 2024/1689 se aplică în trepte. Practicile interzise și dispozițiile generale se aplică din 2 februarie 2025, obligațiile pentru modelele de uz general din 2 august 2025, iar aplicarea generală a regulamentului din 2 august 2026. Pentru sistemele cu risc ridicat din anexa III, pachetul „omnibus digital” a amânat obligațiile la 2 decembrie 2027 — starea din septembrie 2026. Articolul 9 cere un sistem de management al riscurilor instituit, pus în aplicare, documentat și menținut pe tot ciclul de viață al sistemului cu risc ridicat: un proces iterativ, nu un dosar. Aici se vede avantajul structurii armonizate a standardelor de management. ISO/IEC 42001:2023, standardul pentru sisteme de management al inteligenței artificiale, folosește aceleași clauze 4-10 ca ISO/IEC 27001, deci contextul, rolurile, auditul intern și analiza de management se conduc o singură dată. Ce se adaugă e specific: inventarul sistemelor, evaluarea impactului asupra persoanelor, datele de antrenare, supravegherea umană.
Se instituie, se pune în aplicare, se documentează și se menține un sistem de management al riscurilor în legătură cu sistemele de IA cu grad ridicat de risc.Regulamentul (UE) 2024/1689 (regulamentul privind inteligența artificială), art. 9 alin. (1) — sistemul de management al riscurilor
De ce contează Cine tratează conformitatea privind inteligența artificială ca pe un proiect separat plătește de două ori pentru exact aceleași clauze de management.
Pe larg →Strânge ↑
Pasajele anterioare au arătat că cele două sisteme împart aceleași clauze de management. Dar partajarea clauzelor nu înseamnă un singur document. Articolul 9 cere un registru propriu de riscuri pentru inteligența artificială, distinct de cel de securitate. Un risc de securitate spune: cineva îți fură datele clienților. Un risc de inteligență artificială spune: sistemul tău de creditare respinge sistematic cererile dintr-un cartier anume. Ambele trăiesc în aceeași analiză anuală, la aceeași masă, dar cu vocabular diferit. Practic, întâlnești echipa o dată și discuți două registre. Cine le amestecă pierde specificul fiecăruia; cine le separă complet dublează ședințele. Pasul următor: cine ar trebui să dețină fiecare registru în organizație.
- 26
În 2026 conformitatea se mută de la dosarul anual la dovada continuă, iar certificarea devine platforma pe care se sprijină mai multe cadre deodată.
Recomandarea (UE) 2024/1101 privind o foaie de parcurs coordonată de punere în aplicare a tranziției la criptografia post-cuantică · Comisia Europeană · 2024
Trei linii se văd deja. Prima: dovada se colectează singură. Un control descris ca text și verificat o dată pe an e înlocuit de un control exprimat ca regulă executabilă, care produce înregistrarea că a funcționat; auditorul citește un istoric, nu o captură de ecran. A doua: lanțul de aprovizionare. Controalele 5.19-5.23 din Anexa A și articolul 21 alineatul (2) litera (d) din NIS2 cer același lucru — să știi ce riscă furnizorii tăi și să scrii asta în contract. Peisajul de amenințări publicat în 2025 de agenția europeană pentru securitate cibernetică a analizat 4 875 de incidente între iulie 2024 și iunie 2025, cu phishingul drept vector dominant de intrare, în 60% din cazuri. A treia: criptografia post-cuantică. Foaia de parcurs coordonată din iunie 2025 cere începerea tranziției până la sfârșitul lui 2026 și migrarea infrastructurilor critice cel târziu până la sfârșitul lui 2030, pe algoritmii standardizați în august 2024 de institutul american de standarde și tehnologie.
Statele membre ar trebui să aibă în vedere migrarea infrastructurilor și serviciilor digitale actuale ale administrațiilor publice și ale altor infrastructuri critice la criptografia post-cuantică cât mai curând posibil, ceea ce presupune o schimbare fundamentală a algoritmilor, protocoalelor și sistemelor criptografice.Recomandarea (UE) 2024/1101 a Comisiei din 11 aprilie 2024, considerentul (5) — migrarea la criptografia post-cuantică
De ce contează O dovadă produsă o singură dată și citită de mai multe cadre e singura variantă în care numărul de audituri crește fără ca efortul să crească la fel.
Pe larg →Strânge ↑
Dovada continuă schimbă ordinea muncii. Înainte, pregăteai dosarul când venea auditul. Acum, controlul e scris ca regulă, iar regula rulează zilnic și lasă urme. Diferența nu e tehnologică, ci de moment: întrebarea nu mai e „ce făceai în decembrie”, ci „ce s-a întâmplat marți, la ora trei”. Un exemplar: parola unui cont de administrare expiră automat după 90 de zile. Regula o blochează singură și înregistrează blocarea. Auditorul vede în istoric că nicio parolă nu a trăit mai mult. Același istoric servește apoi la NIS2, la ISO sau la cerințele unui client, fără refacere. Următorul pas: ce faci când două cadre cer același control formulat diferit.
Pasul următor e maparea. Fiecare cadru are propriul limbaj, dar cerințele se suprapun. Spre exemplu, gestionarea riscurilor furnizorilor apare și în Anexa A, la controalele despre relațiile cu furnizorii, și în NIS2, la articolul despre securitatea lanțului de aprovizionare. Conținutul e aproape identic: să știi ce pot afecta furnizorii tăi și să pui asta în contract. Dacă scrii controlul o singură dată, ca regulă executabilă, apoi îl etichetezi cu referințele din fiecare cadru, o singură colectare hrănește mai multe răspunsuri. Un exemplar: chestionarul anual al unui client mare cere politici de furnizori; le scoți din același istoric care servește deja auditorului, nu le refaci. Aici apare limita: unele cerințe, precum migrarea la criptografia post-cuantică, nu se reduc la un control comun. Următorul pas: ce face un control când cerința e o tranziție, nu o stare.
- 27
Frumusețea nu e decor, ci forță morală ambivalentă: poate ridica sau poate corupe, iar lupta dintre cele două se dă în inima fiecărui om.
Idiotul · Fiodor Dostoievski · 1869
Dostoievski pune afirmația în gura unui personaj considerat naiv, tocmai ca să nu sune ca o lozincă. Romanul întreg e testul acestei teze: frumusețea din roman nu e doar armonie, ci și seducție, vanitate, putere de a orbi. Mecanismul pe care îl arată autorul: ce ne fermecă ne și dezarmează, pentru că admirația reduce vigilența morală. Un chip admirat poate ascunde cruzime; o operă admirată poate justifica orice. De aceea frumusețea e „groaznică”: cere o judecată pe care admirația singură nu o poate da, și exact acolo, între fascinație și discernământ, se decide ce face ea cu noi.
Frumusețea va salva lumea. Frumusețea e un lucru misterios și groaznic; aici Dumnezeu și diavolul se luptă între ei, iar câmpul de bătălie e inima oamenilor.Idiotul, partea a II-a, cap. 5
De ce contează Într-o perioadă în care publicul întreabă dacă publicațiile spun același lucru și pe cine să creadă, Dostoievski arată că farmecul unei formulări nu e o dovadă — și că discernământul e muncă, nu impresie.
Pe larg →Strânge ↑
Cardul spune că admirația reduce vigilența morală. Pasul următor: admirația nu doar că reduce vigilența, ci ne oferă și o scuză gata făcută. Când ceva e frumos, simțim că am făcut deja judecata, deci nu mai verificăm nimic. Dostoievski arată asta prin personaje care iartă cruzime doar pentru că e purtată de un chip sau de un talent care le fermecă. Gândește-te la un coleg care spune lucruri urâte, dar cu un umor atât de bun încât toată lumea râde și trece mai departe. Râsul devine permisiunea. De aici întrebarea practică: cum îți dai seama că admiri ceva sau cineva, nu că ești doar orbit de farmec?
- 28
Omul e scindat între dorința de a trăi intens aici, în trup, și aspirația spre ceva mai înalt — și nu poate alege definitiv niciuna.
Faust. Prima parte a tragediei · Johann Wolfgang von Goethe · 1808
Goethe formulează aici conflictul care va purta întreaga tragedie: Faust nu e un păcătos simplu, ci o conștiință divizată care suferă din cauza divizării ei. Mecanismul e tensiunea nerezolvată — sufletul care agață de lume îl ține ancorat în experiență, iar cel care zboară îl face neliniștit cu orice câștig pământesc. De aceea pactul cu diavolul pare rezolvarea: o promisiune că va gusta totul, fără să aleagă. Goethe arată că omul care vrea totul nu e viclean, ci deznădăjduit de propria lui dublă natură.
Ah, în pieptul meu locuiesc două suflete, care voiesc să se despartă unul de altul: unul ține, în pofta-i trupească, să se agațe de lume cu ghearele-i; celălalt se ridică cu tărie din ceață spre câmpiile înalte ale strămoșilor.Faust I, versurile 1112–1117 (scena „Noaptea”, monologul lui Faust)
De ce contează Dezbaterile despre conștiința artificială și sfatul cerut preoților reiau întrebarea lui Faust: poate exista ceva care dorește și se ridică în același timp?
Pe larg →Strânge ↑
Pasajul de pe card arată ruptura. Pasul următor e altul: Goethe nu tratează divizarea ca un defect de reparat, ci ca motorul însuși al vieții lui Faust. Dacă unul dintre cele două suflete ar câștiga definitiv, omul s-ar opri din mișcare. Cel agățat de lume ar deveni leneș în plăcere; cel înălțat ar deveni rece, doar contemplare. Tensiunea e cea care îl ține viu și căutând. Gândește-te la cineva care își iubește familia și totuși visează noaptea la o viață complet diferită. Nu e trădare, ci aceeași dublă mișcare. Divizarea doare, dar ea produce și setea care îl duce pe Faust spre pact. Întrebarea care se deschide: ce se întâmplă când cineva încearcă să răspundă acestei tensiuni printr-o singură tranzacție?