Apetitul la risc TIC conform DORA: ghid pentru aprobarea de către organul de conducere în 2026

Este ora 08:15 într-o zi de marți, iar directorul securității informației al unei companii de tehnologie pentru plăți de dimensiune medie stă în fața sălii de ședință a organului de conducere cu trei documente deschise pe tabletă.
Primul este registrul riscurilor TIC. Are 137 de rânduri, ratinguri marcate cromatic și mai multe riscuri ridicate legate de concentrarea în cloud, managementul accesului privilegiat (PAM), recuperarea după ransomware, expunerea datelor clienților și răspunsul la incidente asociate furnizorilor. Al doilea este instrumentul de urmărire a pregătirii pentru DORA. Acesta arată că organizația are politici, proceduri pentru incidente, registre privind terții și planuri de testare a rezilienței. Al treilea este pachetul pentru organul de conducere destinat unei întâlniri cu autoritatea de reglementare.
Președintele are o singură întrebare, iar aceasta nu este una tehnică:
„Ce nivel de risc TIC am convenit, de fapt, să acceptăm?”
În sală se face liniște, deoarece compania are evaluări ale riscurilor, dar nu are un apetit la risc TIC aprobat de organul de conducere. Are ratinguri de impact, dar nu are praguri de toleranță măsurabile. Are ședințe de escaladare, dar nu are un declanșator formal care să stabilească momentul în care un risc cibernetic devine o decizie a organului de conducere. Are riscuri reziduale acceptate, însă unele sunt justificate ca „decizii de afaceri” fără o legătură clară cu criteriile de risc, proporționalitatea din GDPR Article 32, așteptările DORA privind toleranța sau responsabilitatea managementului în cadrul NIS2.
Această lacună devine tot mai vizibilă în 2026. DORA se aplică de la 17 ianuarie 2025 și impune entităților financiare să mențină un cadru de guvernanță și control pentru riscul TIC, inclusiv responsabilitatea organului de conducere pentru cadrul de management al riscurilor TIC, strategia de reziliență operațională digitală și toleranța la risc TIC. NIS2 impune organelor de conducere să aprobe măsurile de management al riscurilor de securitate cibernetică și să supravegheze implementarea acestora. GDPR Article 32 impune măsuri tehnice și organizatorice de securitate adecvate, bazate pe risc. ISO/IEC 27001:2022 oferă mecanismele sistemului de management: context, părți interesate, criterii de risc, planuri de tratare a riscurilor, informații documentate și analiză efectuată de management.
Puntea lipsă este o declarație privind apetitul la risc TIC și toleranța la risc TIC pe care organul de conducere o poate înțelege, aproba, contesta și utiliza.
Acest ghid explică modul de construire a acestei punți utilizând Zenith Blueprint: foaia de parcurs în 30 de pași pentru auditori, Politica de management al riscurilor de la Clarysec, Politica de management al riscurilor pentru IMM-uri de la Clarysec și Zenith Controls: ghidul pentru conformitate transversală.
De ce registrele de riscuri nu reprezintă apetit la risc
Multe organizații confundă un registru de riscuri cu guvernanța riscurilor. Un registru de riscuri arată ce riscuri există, cum sunt evaluate, cine le deține și ce tratare este planificată. El nu răspunde automat întrebărilor la nivelul organului de conducere pe care DORA, NIS2, GDPR și ISO/IEC 27001:2022 se așteaptă ca liderii să le abordeze.
O declarație matură privind apetitul la risc TIC răspunde la întrebări precum:
- Ce riscuri TIC sunt inacceptabile indiferent de cost?
- Ce indisponibilitate operațională poate tolera organizația pentru o funcție critică sau importantă?
- Ce nivel de pierdere a datelor sau de compromitere a integrității datelor se află în afara apetitului la risc?
- Ce risc de concentrare la terți necesită atenția organului de conducere?
- Cine poate accepta riscul TIC rezidual și la ce nivel?
- Când trebuie escaladat un risc către conducerea superioară sau către organul de conducere?
- Cum sunt integrate cerințele legale, de reglementare și contractuale în criteriile de risc?
În cadrul DORA, aceasta nu este o simplă rafinare opțională a guvernanței. Article 5 impune organului de conducere să definească, să aprobe, să supravegheze și să își asume responsabilitatea pentru cadrul de management al riscurilor TIC, inclusiv pentru strategia de reziliență operațională digitală și toleranța la risc TIC. Article 6 impune un cadru documentat de management al riscurilor TIC, revizuire anuală pentru entitățile care nu sunt microîntreprinderi, audit intern, remedierea constatărilor critice de audit și o strategie de reziliență operațională digitală cu obiective TIC, toleranță la risc, toleranță la impact, arhitectură, testare și strategie de comunicare a incidentelor.
NIS2 adaugă un model paralel de responsabilitate. Article 20 impune organelor de conducere ale entităților esențiale și importante să aprobe măsurile de management al riscurilor de securitate cibernetică, să supravegheze implementarea și să beneficieze de instruire. Article 21 impune măsuri tehnice, operaționale și organizatorice adecvate și proporționale, bazate pe o abordare care acoperă toate amenințările, inclusiv analiza riscului, gestionarea incidentelor, continuitatea activității, securitatea lanțului de aprovizionare, dezvoltarea securizată, eficacitatea controalelor, instruirea, criptografia, securitatea resurselor umane, controlul accesului, politica de management al activelor și autentificarea multifactor acolo unde este adecvat.
Pentru entitățile financiare, DORA este tratată ca act juridic al Uniunii specific sectorului atunci când se aplică obligații NIS2 suprapuse. În practică, DORA înlocuiește, în general, cerințele NIS2 suprapuse privind managementul riscurilor și raportarea incidentelor pentru entitățile financiare aflate în domeniul său de aplicare, în timp ce NIS2 rămâne importantă pentru coordonare și pentru furnizorii care nu intră sub obligațiile directe DORA ale entităților financiare. Pentru furnizorii SaaS, cloud, servicii administrate și servicii administrate de securitate, NIS2 se poate aplica direct atunci când sunt îndeplinite condițiile de încadrare în domeniul de aplicare.
De aceea, apetitul la risc TIC aprobat de organul de conducere nu mai este un artefact de risc financiar. Este un control de guvernanță a securității cibernetice.
Utilizați ISO/IEC 27001:2022 ca sistem operațional
DORA și NIS2 le spun liderilor ce trebuie guvernat. ISO/IEC 27001:2022 oferă organizațiilor un sistem operațional practic pentru modul în care trebuie realizată această guvernanță.
Clauzele 4.1–4.4 din ISO/IEC 27001:2022 impun organizației să definească contextul, părțile interesate, cerințele, domeniul de aplicare al SMSI și procesele SMSI. Acest lucru este important deoarece DORA, NIS2, GDPR, contractele, așteptările autorităților de supraveghere, clienții, furnizorii cloud și relațiile de externalizare devin toate cerințe care influențează criteriile de risc.
Clauzele 5.1–5.3 impun angajamentul conducerii, alinierea politicilor, resurse, responsabilități și raportarea performanței SMSI către conducerea de vârf. Clauzele 6.1.1–6.1.3 impun planificare bazată pe risc, un proces documentat de evaluare a riscurilor, criterii de acceptare a riscului, criterii consecvente de evaluare, proprietari de risc, compararea cu criteriile de risc, planificarea tratării riscurilor, o Declarație de aplicabilitate și aprobarea riscului rezidual.
Aceasta este baza toleranței la risc TIC conform DORA.
În faza de management al riscurilor, pasul 10 din Zenith Blueprint indică organizațiilor să definească criterii de risc înainte de evaluarea riscurilor:
„Criteriile de risc sunt regulile și reperele pe care organizația le utilizează pentru a evalua semnificația fiecărui risc. Stabilirea acestor criterii de la început asigură utilizarea aceluiași limbaj al riscului de către toți.”
Același pas avertizează că impactul de reglementare trebuie integrat în definițiile riscului:
„Orice risc care ar putea conduce la neconformitate cu legislația aplicabilă (GDPR etc.) nu este acceptabil și trebuie atenuat.”
Zenith Blueprint oferă și orientări practice pentru scalarea impactului:
„La definirea impactului, este recomandat să corelați nivelurile cu scara specifică a organizației. De exemplu, «impact financiar major = pierdere > 100.000 USD» (ajustați în funcție de context). Luați în considerare și impactul de reglementare: de exemplu, o încălcare a securității datelor cu caracter personal ar putea fi automat «Majoră» sau «Severă» din cauza amenzilor GDPR și a cerințelor de notificare, chiar dacă pierderea financiară directă este neclară. În mod similar, dacă intrați în domeniul de aplicare NIS2 (servicii esențiale), un incident care cauzează perturbarea serviciului ar putea fi cel puțin «Major» din cauza implicațiilor juridice. Includeți astfel de considerații în definiții.”
Această orientare previne o deficiență frecventă: evaluarea unui risc cibernetic ca moderat deoarece pierderea financiară imediată pare redusă, ignorând impactul juridic, impactul asupra rezilienței operaționale, asupra persoanei vizate sau asupra clienților.
Un model pregătit pentru organul de conducere trebuie să separe patru niveluri:
| Nivel | Întrebarea organului de conducere | Rezultat practic |
|---|---|---|
| Apetit la risc | Ce tipuri și niveluri de risc TIC sunt acceptabile în urmărirea obiectivelor organizației? | Declarație privind apetitul la risc TIC aprobată de organul de conducere |
| Toleranță la risc | Ce praguri măsurabile definesc variația acceptabilă? | Praguri cuantificate pentru indisponibilitate, pierderea datelor, dependența de furnizori, vechimea vulnerabilităților, severitatea incidentelor și recuperare |
| Declanșatoare de escaladare | Când trebuie informată conducerea sau organul de conducere ori când trebuie să decidă? | Matrice de declanșare legată de KRI, incidente, risc rezidual și neconformitate |
| Reguli de acceptare a riscului | Cine poate accepta riscul rezidual și în ce condiții? | Delegarea autorității, dovezi de aprobare și documentare în registrul riscurilor |
Această structură face apetitul la risc verificabil în audit, deoarece fiecare declarație poate fi corelată cu criterii de risc, controale, dovezi și decizii.
O declarație privind apetitul la risc TIC conform DORA, pregătită pentru organul de conducere
O declarație solidă privind apetitul la risc TIC este suficient de scurtă pentru a fi aprobată de organul de conducere, suficient de specifică pentru a fi aplicată de management și suficient de măsurabilă pentru a fi testată de auditori. Trebuie să evite jargonul, dar nu poate fi vagă.
O declarație practică la nivel înalt ar putea fi formulată astfel:
„Organizația noastră are un apetit scăzut pentru riscurile TIC care ar putea genera prejudicii semnificative pentru clienți, perturbarea funcțiilor critice sau importante, divulgarea sau modificarea neautorizată a datelor reglementate, neîndeplinirea obligațiilor legale sau pierderea rezilienței serviciilor TIC critice furnizate de terți.”
Această declarație trebuie apoi susținută prin praguri de toleranță măsurabile și declanșatoare de escaladare.
| Domeniu de risc | Declarație privind apetitul | Prag de toleranță | Metrică sau KRI | Declanșator de escaladare |
|---|---|---|---|---|
| Disponibilitatea serviciilor critice | Avem un apetit foarte scăzut pentru perturbarea funcțiilor critice sau importante. | Indisponibilitate neplanificată maximă de 2 ore pentru procesarea plăților și 4 ore pentru serviciile portalului clienților. | Rapoarte de disponibilitate, durata incidentelor, rezultatele testelor BCDR, performanța RTO și RPO. | Orice indisponibilitate estimată să depășească 50% din toleranță se escaladează către conducerea superioară; depășirea se escaladează către organul de conducere. |
| Confidențialitatea datelor cu caracter personal | Nu avem apetit pentru divulgarea neautorizată a datelor cu caracter personal reglementate, a secretelor de autentificare sau a credențialelor de plată. | Zero divulgări neautorizate confirmate care implică date cu caracter personal de producție, secrete sau credențiale de plată. | Numărul încălcărilor confirmate ale securității datelor cu caracter personal și al încălcărilor notificabile. | Orice încălcare suspectată a securității datelor cu caracter personal declanșează răspunsul la incidente și evaluarea privind protecția datelor; încălcarea confirmată se escaladează imediat către departamentul juridic, DPO și conducerea superioară. |
| Integritatea datelor | Avem un apetit foarte scăzut pentru modificarea neautorizată a datelor de tranzacții, identitate sau raportare. | Nicio anomalie de integritate nerezolvată care afectează rapoarte reglementate, solduri, înregistrări despre clienți sau piste de audit. | Rapoarte privind excepțiile de integritate, eșecuri de reconciliere, alerte ale pistei de audit. | Orice problemă de integritate care afectează înregistrări critice se escaladează către directorul securității informației, DPO și proprietarul riscului în termen de 24 de ore. |
| Concentrarea terților TIC | Acceptăm un risc de concentrare limitat numai atunci când controalele de ieșire, reziliență și monitorizare sunt eficace. | Nicio dependență de furnizor unic pentru o funcție critică fără plan de ieșire sau de contingență testat. | Registrul terților TIC, rezultatele testelor de ieșire, rezultatele revizuirilor furnizorilor. | Un furnizor TIC critic nou sau modificat fără plan de ieșire necesită aprobarea comitetului de risc. |
| Expunerea la vulnerabilități | Acceptăm un risc rezidual de vulnerabilitate limitat atunci când tratarea este urmărită și există controale compensatorii. | Vulnerabilitățile critice expuse la internet sunt remediate sau atenuate în termenul SLA de urgență definit. | Vechimea vulnerabilităților, rata de încălcare a SLA, rapoarte de expunere. | Încălcarea SLA pentru o expunere critică se escaladează către conducerea superioară și proprietarul riscului. |
| Recuperarea după ransomware | Avem un apetit foarte scăzut pentru incapacitatea prelungită de a restaura servicii critice din backup-uri curate. | Restaurarea serviciilor critice din backup-uri curate în termen de 4 ore pentru sistemele prioritare definite. | Rata de succes a backup-urilor, rezultatele testelor de restaurare, rezultatele exercițiilor de recuperare. | Eșecul unui test de restaurare sau detectarea ransomware pe sisteme de producție declanșează escaladarea către managementul crizei. |
| Neconformitate cu reglementările | Nu avem apetit pentru neconformitate deliberată cu DORA, obligațiile NIS2 aplicabile, GDPR sau obligațiile contractuale de securitate. | Zero riscuri reziduale acceptate care încalcă în mod cunoscut cerințe legale sau de reglementare obligatorii. | Registrul excepțiilor de conformitate, constatări de audit, maparea obligațiilor legale. | Orice acceptare propusă a neconformității cu reglementările este respinsă sau escaladată pentru analiză juridică și decizie a organului de conducere. |
Acest tabel schimbă discuția. Organul de conducere nu mai aprobă un slogan. Aprobă limite operaționale pentru disponibilitate, confidențialitate, integritate, furnizori, vulnerabilități, recuperare și conformitate.
Politica de management al riscurilor de la Clarysec susține acest model de guvernanță. Politica pentru întreprinderi prevede:
„Aprobă cadrul de management al riscurilor și definește apetitul la risc acceptabil și pragurile de toleranță.”
Clauza 6.2.1 explicitează cerința de măsurare:
„Riscurile trebuie evaluate din perspectiva probabilității și impactului utilizând o matrice standard de risc cu scale de scorare clar definite.”
Clauza 6.3.4 stabilește regula de acceptare pe care auditorii o vor aștepta:
„Riscurile acceptate fără tratament trebuie justificate în scris, corelate cu apetitul la risc al organizației și aprobate la nivelul corespunzător.”
Pentru IMM-uri, Politica de management al riscurilor pentru IMM-uri păstrează același principiu de guvernanță într-un format mai ușor:
„Asigură implicarea managementului în aprobarea toleranței la risc și a planurilor majore de tratament al riscurilor.”
Aceasta impune și escaladarea riscurilor ridicate:
„Riscurile ridicate trebuie escaladate către directorul general pentru decizie.”
Aceasta este proporționalitatea în practică. DORA Article 4 impune aplicarea cerințelor într-o manieră proporțională cu dimensiunea, profilul de risc și natura, amploarea și complexitatea serviciilor. ISO/IEC 27001:2022 permite același principiu prin domeniu de aplicare, context, criterii de risc și decizii de tratare. Standardul de guvernanță nu este ca fiecare organizație să aibă aceeași structură de comitete. Standardul de guvernanță este ca apetitul la risc, toleranța, escaladarea și acceptarea să fie definite, aprobate, susținute prin dovezi și utilizate.
GDPR Article 32 schimbă discuția despre risc
GDPR Article 32 este tratat adesea ca o clauză tehnică de securitate. Din perspectivă de guvernanță, este și o clauză privind apetitul la risc.
Article 32 impune operatorilor și persoanelor împuternicite să implementeze măsuri tehnice și organizatorice adecvate pentru a asigura un nivel de securitate corespunzător riscului. Această abordare bazată pe risc ia în considerare stadiul actual al tehnologiei, costurile implementării, natura, domeniul de aplicare, contextul și scopurile prelucrării, precum și riscurile pentru drepturile și libertățile persoanelor fizice.
Aceasta afectează apetitul la risc TIC în trei moduri.
În primul rând, impactul asupra datelor cu caracter personal nu poate fi redus la pierdere financiară. Expunerea unei baze de date mici poate avea costuri directe limitate, dar consecințe grave asupra confidențialității, identității, fraudei, discriminării sau drepturilor. Dacă sunt implicate categorii speciale de date cu caracter personal, cum ar fi datele privind sănătatea, datele biometrice sau genetice, apetitul trebuie să fie semnificativ mai scăzut.
În al doilea rând, rolurile de prelucrare trebuie corelate cu deținerea riscului. GDPR distinge între operatori de date și persoane împuternicite. DORA distinge între entități financiare și furnizori terți de servicii TIC. NIS2 distinge între entități esențiale și importante. ISO/IEC 27001:2022 impune proprietari de risc. O declarație matură privind apetitul trebuie să identifice cine deține deciziile de risc care implică date cu caracter personal, prelucrare externalizată, servicii critice și dependențe transfrontaliere.
În al treilea rând, proporționalitatea din Article 32 trebuie să fie vizibilă în selectarea controalelor. Criptarea, pseudonimizarea, controlul accesului, backup-ul, jurnalizarea, monitorizarea, răspunsul la incidente și reziliența nu sunt sarcini tehnice izolate. Ele sunt măsuri de tratare selectate deoarece un risc a depășit apetitul sau toleranța.
Politica de management al riscurilor de la Clarysec face explicită această legătură:
„Article 32: Impune o abordare bazată pe risc pentru măsurile de securitate, îndeplinită prin evaluări de risc bazate pe impact și selectarea controalelor.”
Aceasta este legătura operațională pe care o caută auditorii: cerința Article 32, evaluarea riscurilor, ratingul de risc, planul de tratare, selectarea controalelor, riscul rezidual și aprobarea.
Cum susține Zenith Controls dovezile pentru conformitate transversală
O declarație privind apetitul aprobată de organul de conducere devine puternică atunci când este mapată la controale. Zenith Controls funcționează ca ghid de conformitate transversală al Clarysec, ajutând echipele să reutilizeze dovezi în ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF și asigurare de tip COBIT.
Trei zone de control ISO/IEC 27002:2022 sunt deosebit de importante:
| Control ISO/IEC 27002:2022 | Rol în conformitatea transversală | De ce contează pentru apetitul la risc TIC |
|---|---|---|
| 5.1 Politici pentru securitatea informației | Politicile trebuie definite, aprobate, comunicate, confirmate și revizuite. | Declarația privind apetitul trebuie formalizată prin politică, comunicată, aplicată și revizuită. |
| 5.4 Responsabilități ale managementului | Managementul trebuie să solicite personalului să aplice securitatea informației în conformitate cu politicile, procedurile și rolurile stabilite. | Responsabilitățile organului de conducere și ale managementului trebuie atribuite, susținute prin dovezi și revizuite. |
| 5.31 Cerințe legale, statutare, de reglementare și contractuale | Cerințele legale, statutare, de reglementare și contractuale relevante trebuie identificate, documentate și menținute la zi. | Obligațiile DORA, NIS2, GDPR și contractuale trebuie să influențeze criteriile de risc și limitele de acceptare. |
Aceasta nu este o activitate de mapare pe hârtie. Schimbă modul în care sunt luate deciziile.
Dacă un proprietar de business solicită acceptarea amânării implementării MFA pentru administratori, Zenith Controls îl ajută pe directorul securității informației să arate de ce aceasta nu este doar o problemă de control al accesului. Ea atinge guvernanța politicilor, responsabilitatea managementului, cerințele legale și de reglementare, securitatea prelucrării conform GDPR, managementul riscurilor TIC conform DORA, măsurile de securitate cibernetică NIS2, impactul incidentelor și dovezile de audit.
Dacă o echipă de produs dorește să lanseze într-o nouă piață a UE utilizând un serviciu cloud nou, controlul 5.31 din ISO/IEC 27002:2022 introduce revizuirea cerințelor legale și de reglementare în domeniul de aplicare al SMSI. Clauza 4.2 din ISO/IEC 27001:2022 impune identificarea cerințelor părților interesate, inclusiv obligațiile legale, de reglementare și contractuale. Clauza 8.1 impune planificare și control operațional, inclusiv controlul proceselor, produselor sau serviciilor furnizate extern relevante pentru SMSI.
Obiectivul este un singur limbaj al riscului, nu dialecte separate de conformitate.
Fluxul de aprobare: cine decide ce
Un director al securității informației poate propune apetitul la risc TIC, dar organul de conducere trebuie să îl dețină. Această deținere necesită un flux de lucru.
| Decizie | Proprietar recomandat | Dovezi |
|---|---|---|
| Aprobarea declarației privind apetitul la risc TIC | Organul de conducere | Procese-verbale semnate, hotărâre a organului de conducere, politică aprobată |
| Aprobarea criteriilor de risc și a scalelor de scorare | Comitetul de risc sau conducerea de vârf | Metodologie de risc, matrice, aprobare a politicii |
| Acceptarea riscului TIC rezidual ridicat | Organul de conducere sau forum executiv delegat | Înregistrare privind acceptarea riscului, justificare, dată de expirare, controale compensatorii |
| Acceptarea riscului TIC rezidual mediu | Proprietar de risc cu aprobare de management | Înregistrare în registrul riscurilor, flux de aprobare |
| Aprobarea toleranței DORA pentru funcția critică | Organul de conducere cu contribuția proprietarului de business | Analiza impactului asupra activității (BIA), strategie de reziliență, praguri de toleranță |
| Aprobarea măsurilor de protecție pentru prelucrarea cu risc ridicat conform GDPR | Conducerea operatorului de date cu contribuția DPO | DPIA, plan de tratare a riscurilor, dovezi privind controalele Article 32 |
Aceasta se aliniază și cu NIST CSF 2.0. Funcția GOVERN, în special GV.RM, așteaptă obiective convenite de management al riscurilor, declarații privind apetitul și toleranța la risc, activități de risc integrate în managementul riscurilor la nivel de organizație, opțiuni definite de răspuns la risc, linii de comunicare și metode standardizate pentru calcularea, documentarea, categorizarea și prioritizarea riscurilor de securitate cibernetică. GV.RR așteaptă responsabilitatea conducerii, roluri, autorități și resurse aliniate la strategia de risc. GV.PO așteaptă politici stabilite, comunicate, aplicate, revizuite și actualizate.
Profesioniștii în asigurare de tip COBIT 19 și ISACA vor întreba dacă apetitul la risc este integrat în guvernanța corporativă a informațiilor și tehnologiei, nu doar atașat ca anexă la o politică cibernetică.
Construiți un pachet privind apetitul la risc TIC într-o singură sesiune de lucru
Un atelier practic privind apetitul la risc TIC poate muta organizația de la registre dispersate la un pachet verificabil pentru organul de conducere.
Pasul 1: colectați intrările corecte
Pregătiți registrul actual al riscurilor TIC, analiza impactului asupra activității, obiectivele de recuperare, lista funcțiilor critice sau importante, inventarul activelor TIC, inventarul serviciilor TIC, registrul dependențelor de furnizori și cloud, criteriile de clasificare a incidentelor, inventarul prelucrărilor GDPR, DPIA acolo unde este relevant, registrul obligațiilor legale, politicile, Declarația de aplicabilitate și declarația existentă privind apetitul la risc la nivel de organizație.
Aceasta se aliniază cu clauzele 4, 6 și 8 din ISO/IEC 27001:2022 și cu metodele de profil NIST CSF care pornesc de la prioritățile organizației, prioritățile de risc, cerințe, măsuri de protecție și roluri.
Pasul 2: definiți scale de impact care includ reglementarea
Utilizând pasul 10 din Zenith Blueprint, definiți probabilitatea și impactul în limbaj de afaceri. Includeți pierderea financiară, perturbarea operațională, impactul asupra clienților, prejudiciile reputaționale, impactul legal și de reglementare, prejudiciul pentru persoana vizată și impactul asupra funcțiilor critice.
De exemplu, impactul „Major” poate include o indisponibilitate prelungită a unui serviciu critic, o încălcare confirmată a securității datelor cu caracter personal care necesită notificare, neîndeplinirea unei obligații DORA de raportare a incidentelor sau un eșec al furnizorului care afectează o funcție critică sau importantă.
Pasul 3: formulați apetitul pe domenii
Nu creați un apetit cibernetic generic. Definiți domenii precum disponibilitatea serviciilor critice, confidențialitatea datelor cu caracter personal, integritatea datelor, accesul privilegiat, dependența de terți TIC, concentrarea în cloud, expunerea la vulnerabilități, pregătirea pentru raportarea incidentelor, backup-ul și recuperarea, precum și riscul de schimbare în dezvoltarea securizată.
Pentru fiecare domeniu, redactați o declarație privind apetitul, unul sau mai multe praguri de toleranță și declanșatoare de escaladare.
Pasul 4: conectați tratarea la Declarația de aplicabilitate
Pasul 13 din Zenith Blueprint indică organizațiilor să aleagă opțiunile de tratare a riscurilor: atenuare, evitare, transfer sau acceptare. De asemenea, subliniază aprobarea de către management:
„Deciziile de tratament al riscurilor și SoA trebuie revizuite și aprobate de conducerea de vârf.”
Pentru DORA și NIS2, aceasta constituie dovada că organul de conducere sau conducerea delegată a revizuit riscurile-cheie, tratamentele și expunerea reziduală acceptată. Pentru GDPR, susține responsabilitatea prin demonstrarea motivului pentru care măsurile selectate au fost adecvate riscului.
Pasul 5: înregistrați acceptarea cu termen de expirare și condiții
Fiecare risc rezidual mediu sau ridicat acceptat trebuie să includă:
- ID-ul riscului și proprietarul
- Justificarea de afaceri
- Referința la declarația privind apetitul
- Pragul de toleranță afectat
- Analiza legală și de reglementare
- Controale compensatorii
- Data de expirare sau de revizuire
- Aprobatorul
- Locația dovezilor
- Declanșatorul pentru redeschiderea deciziei
Politica de management al riscurilor pentru IMM-uri prevede:
„Orice decizie de a accepta sau de a amâna tratamentul unui risc ridicat sau mediu trebuie documentată în Registrul de riscuri. Această documentare trebuie să includă:”
În medii de întreprindere, aceasta devine un flux de aprobare și un pachet pentru comitetul de risc. În organizațiile mai mici, poate fi o filă structurată a registrului riscurilor cu aprobarea managementului. Scopul nu este birocrația. Scopul este capacitatea de justificare și susținere.
Toleranța la incidente: punctul în care apetitul întâlnește ceasul
Apetitul la risc devine real în timpul incidentelor.
DORA Article 17 impune entităților financiare să stabilească un proces de gestionare a incidentelor legate de TIC pentru detectarea, gestionarea și notificarea incidentelor, înregistrarea tuturor incidentelor și a amenințărilor cibernetice semnificative, identificarea cauzelor principale, utilizarea indicatorilor de avertizare timpurie, clasificarea incidentelor după prioritate, severitate și criticitatea serviciului, atribuirea rolurilor, comunicarea către părți interesate, escaladarea cel puțin a incidentelor majore legate de TIC către conducerea superioară și organul de conducere și restaurarea la timp a operațiunilor securizate.
DORA Article 18 clasifică incidentele utilizând factori precum clienții afectați, durata, indisponibilitatea, răspândirea geografică, pierderile de date care afectează disponibilitatea, autenticitatea, integritatea sau confidențialitatea, criticitatea serviciilor afectate și impactul economic. Article 19 impune raportarea incidentelor majore legate de TIC către autoritatea competentă, cu informarea clienților atunci când interesele lor financiare sunt afectate.
NIS2 Article 23 prevede raportare etapizată pentru incidente semnificative, inclusiv avertizare timpurie fără întârzieri nejustificate și, după caz, în termen de 24 de ore, notificarea incidentului fără întârzieri nejustificate și, după caz, în termen de 72 de ore, actualizări intermediare la cerere și un raport final cel târziu la o lună după notificarea incidentului. Incidentele semnificative includ incidentele care cauzează perturbări operaționale severe, pierderi financiare sau daune materiale ori imateriale altora.
Declarația privind apetitul trebuie să definească pragurile de escaladare înainte ca incidentul să se producă.
| Condiție de incident | Implicație pentru apetit | Acțiune necesară |
|---|---|---|
| Indisponibilitatea unei funcții critice depășește 50% din toleranță | Se apropie de limita exterioară a apetitului | Activați managementul crizei și notificați conducerea superioară |
| Încălcare confirmată a securității datelor cu caracter personal în producție | În afara apetitului de confidențialitate | Începeți evaluarea încălcării securității datelor conform GDPR și notificați DPO și departamentul juridic |
| Problemă de integritate în datele de raportare reglementate | În afara apetitului de integritate | Escaladați către proprietarul riscului, conformitate și management |
| Clasificare probabilă ca incident major legat de TIC în cadrul DORA | Eveniment de reziliență relevant pentru organul de conducere | Escaladați către organul de conducere și pregătiți raportarea către autoritatea de reglementare |
| Criteriile NIS2 pentru incident semnificativ sunt probabil îndeplinite pentru o entitate aflată în domeniul de aplicare | Prag de raportare reglementară atins | Începeți fluxul de notificare etapizată |
Controalele din Annex A privind planificarea incidentelor, evaluarea evenimentelor de securitate a informațiilor, răspunsul la incidente, învățarea din incidente, colectarea dovezilor, menținerea securității informațiilor în timpul perturbărilor și pregătirea TIC pentru continuitatea activității susțin toate aceste praguri. Rezultatele NIST CSF din IDENTIFY, PROTECT, DETECT, RESPOND și RECOVER susțin același model operațional, inclusiv backup-uri, monitorizare, declararea incidentelor, escaladare, analiza cauzei principale, comunicare cu părțile interesate și verificarea recuperării.
Toleranța față de furnizori și cloud pe care organele de conducere o omit adesea
DORA transformă riscul asociat terților TIC într-o obligație centrală de conformitate. Article 28 impune entităților financiare să gestioneze riscul asociat terților TIC ca parte a cadrului de management al riscurilor TIC, rămânând pe deplin responsabile pentru conformitate. Acesta impune strategie privind riscul asociat terților TIC, registre ale acordurilor contractuale pentru servicii TIC, distincția serviciilor care susțin funcții critice sau importante, raportare anuală, notificarea aranjamentelor planificate, evaluări precontractuale, due diligence, drepturi de audit și inspecție, drepturi de reziliere și strategii de ieșire documentate.
Article 29 adaugă analiza riscului de concentrare, inclusiv lipsa substituibilității, dependențele multiple de aceiași furnizori sau de furnizori conectați, riscurile de subcontractare, subcontractorii din țări terțe, conformitatea cu protecția datelor, caracterul executoriu și lanțurile complexe de subcontractare. Article 30 impune drepturi și obligații contractuale scrise, descrieri ale serviciilor, locații, măsuri de protecție de securitate, accesul la date și returnarea acestora, niveluri de servicii, asistență pentru incidente, cooperarea cu autoritățile, drepturi de reziliere, planuri de contingență testate, monitorizare și aranjamente de ieșire.
O declarație privind toleranța față de furnizori aprobată de organul de conducere ar putea fi formulată astfel:
„Avem un apetit scăzut pentru dependența funcțiilor critice sau importante de un furnizor terț de servicii TIC atunci când nu dispunem de drepturi contractuale de audit, aranjamente de ieșire testate, obligații de notificare a incidentelor, ținte privind nivelul serviciilor, drepturi de returnare a datelor sau vizibilitate asupra subcontractării semnificative.”
Această propoziție oferă achizițiilor o regulă practică. Dacă un contract nu îndeplinește pragul, riscul nu poate fi acceptat discret de echipa de proiect.
Cum vor testa auditorii apetitul la risc TIC
O declarație solidă privind apetitul este proiectată având auditul în vedere.
| Perspectiva auditorului | Ce vor întreba | Dovezi așteptate |
|---|---|---|
| Auditor ISO/IEC 27001:2022 | Sunt criteriile de risc, criteriile de acceptare și deciziile de tratare documentate, consecvente și aprobate? | Metodologie de risc, registru de riscuri, plan de tratare, Declarație de aplicabilitate, înregistrări de aprobare, procese-verbale ale analizei efectuate de management |
| Auditor sau supraveghetor axat pe DORA | A aprobat organul de conducere toleranța la risc TIC și supraveghează managementul riscurilor TIC? | Procese-verbale ale organului de conducere, strategie de reziliență operațională digitală, cadru de risc TIC, KRI, dovezi privind escaladarea incidentelor, înregistrări de remediere a auditului |
| Evaluator NIS2 | A aprobat și supravegheat organul de conducere măsurile de securitate cibernetică și a primit instruire suficientă? | Aprobări ale organului de conducere, înregistrări privind instruirea, maparea controalelor Article 21, dovezi privind incidentele și continuitatea |
| Auditor GDPR sau autoritate de reglementare în domeniul protecției datelor | Sunt măsurile de securitate adecvate riscului pentru persoane și poate fi demonstrată conformitatea? | DPIA, raționamentul controalelor Article 32, înregistrări privind evaluarea încălcării securității datelor, dovezi privind criptarea și accesul, controale pentru persoanele împuternicite |
| Evaluator NIST CSF | Sunt apetitul și toleranța la risc integrate în guvernanță, profiluri și planuri de acțiune prioritizate? | Profiluri curente și țintă, dovezi GV.RM, opțiuni de răspuns la risc, POA&M, metrici de performanță |
| Auditor COBIT 19 sau ISACA | Funcționează eficace obiectivele de guvernanță, drepturile decizionale, responsabilitatea și optimizarea riscurilor? | Mandate de guvernanță, RACI, raportări către organul de conducere, tablouri de bord KPI și KRI, revizuiri ale eficacității controalelor |
Pasul 28 din Zenith Blueprint, în faza Audit, revizuire și îmbunătățire, consolidează nivelul de analiză efectuată de management. Acesta indică organizațiilor să colecteze intrări precum schimbări ale aspectelor externe și interne, performanța SMSI, rezultatele auditului, monitorizare și măsurare, incidente, neconformități, oportunități de îmbunătățire și necesar de resurse. De asemenea, precizează că analiza efectuată de management trebuie să conducă la decizii și acțiuni, nu doar la prezentări.
Cel puțin anual și ori de câte ori apar modificări semnificative, managementul trebuie să revizuiască dacă pragurile de toleranță rămân aliniate cu modelul de afaceri, dacă incidentele au depășit apetitul, dacă riscurile acceptate rămân în limitele aprobate, dacă noile cerințe DORA, NIS2, GDPR sau contractuale au schimbat baza de referință, dacă furnizorii rămân în toleranțele de concentrare și dacă KRI determină escaladare la timp.
Dacă răspunsul este nu, declarația privind apetitul trebuie schimbată sau controalele trebuie schimbate.
Tipare comune de eșec în activitățile de pregătire pentru 2026
În proiectele DORA, NIS2, GDPR și ISO/IEC 27001:2022 apar repetat aceleași puncte slabe:
- Apetit fără praguri, în care organul de conducere aprobă o declarație, dar nimeni nu poate spune când aceasta a fost încălcată.
- Praguri fără autoritate, în care nivelurile de severitate există, dar proprietarii de risc pot accepta excepții fără aprobare superioară.
- Risc juridic în afara modelului de scorare, în care GDPR, DORA, NIS2 și contractele sunt listate separat, dar nu sunt integrate în criteriile de impact.
- Toleranța față de furnizori lipsește din pachetul pentru organul de conducere, deși dependențele TIC critice sunt cunoscute de achiziții sau IT.
- Analiză efectuată de management ca exercițiu formal, în care sunt prezentate slide-uri, dar deciziile, acțiunile, necesarul de resurse și acceptările de risc nu sunt documentate.
- Fragmentarea dovezilor de audit, în care politicile, registrele, KRI, rapoartele de incident, revizuirile furnizorilor și procesele-verbale ale organului de conducere există în locuri diferite fără referințe încrucișate.
Abordarea Clarysec este concepută pentru a elimina aceste lacune. Zenith Blueprint oferă parcursul de implementare pe faze. Politica de management al riscurilor și Politica de management al riscurilor pentru IMM-uri oferă clauze de guvernanță adaptate mediilor de întreprindere și IMM. Zenith Controls mapează coloana vertebrală a controalelor pe politica de securitate a informației, responsabilitatea managementului și cerințele legale sau de reglementare, făcând dovezile reutilizabile în ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF și asigurare de tip COBIT.
Transformați intenția organului de conducere în guvernanță verificabilă a riscurilor TIC
Dacă organizația are un registru de riscuri, dar nu poate demonstra un apetit la risc TIC aprobat de organul de conducere, praguri de toleranță măsurabile, declanșatoare de escaladare și reguli formale de acceptare, lacuna nu este cosmetică. Ea afectează guvernanța DORA, responsabilitatea managementului în cadrul NIS2, capacitatea de susținere a GDPR Article 32 și pregătirea pentru audit ISO/IEC 27001:2022.
Un pas practic următor este derularea unui atelier focalizat privind apetitul la risc TIC utilizând setul de instrumente Clarysec:
- Utilizați pasul 10 din Zenith Blueprint pentru a defini criterii de risc și scale de impact.
- Utilizați pasul 13 din Zenith Blueprint pentru a corela opțiunile de tratare, riscul rezidual și aprobarea Declarației de aplicabilitate.
- Utilizați pasul 14 din Zenith Blueprint pentru a crea referințe încrucișate cu obligațiile GDPR, NIS2 și DORA.
- Utilizați pasul 28 din Zenith Blueprint pentru a include apetitul, KRI, riscurile acceptate și deciziile privind resursele în analiza efectuată de management.
- Aplicați Politica de management al riscurilor sau Politica de management al riscurilor pentru IMM-uri pentru a formaliza regulile de aprobare și acceptare.
- Utilizați Zenith Controls pentru a mapa controalele de guvernanță la dovezi de audit și la așteptările de conformitate transversală.
Clarysec vă poate ajuta să convertiți artefacte de risc dispersate într-un model de apetit la risc TIC aprobat de organul de conducere și pregătit pentru autoritățile de reglementare, pe care echipele îl pot utiliza atunci când următoarea indisponibilitate cloud, defecțiune a unui furnizor, divulgare a unei vulnerabilități sau incident privind datele cu caracter personal testează toleranța reală a organizației.
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council