Evaluarea interna a riscurilor operationale generate de folosirea sistemelor informatice

Mihnea MIRONESCU
Consultant

Norma ASF 6/2015 impune companiilor de asigurari, reasigurari si intermediere o detaliere a modului in care administreaza riscurile operationale la nivelul entitatii pentru subcategoria riscurilor operationale generate de utilizarea sistemelor informatice. Desi si pana acum unele companii au luat in calul acest gen de riscuri operationale, ASF doreste o tratare mai riguroasa a riscurilor legate de IT.

Companiile isi aleg singure modul de implementare a sistemului de management al riscului legat de IT, insa dupa cum indica si bunele practici, este recomandabil sa se utilizeze un singur sistem (proces) de management al riscului la nivelul entitații (ERM - enterprise risk management) pentru a nu trata separat aceasta sub-categorie de riscuri operaționale, cu consecința unei dificultați in a ingloba riscurile IT identificate in tabloul mai larg al riscurilor operaționale la care este supusa compania pe ansamblu.

Prima forma a instrucțiunii ASF a prezentat mai multe exemple de riscuri si a descris procesul de identificare si evaluare a riscurilor pentru companiile care nu au deja un astfel de proces si pot beneficia de pe urma unui exemplu. Desi aceste exemple au fost eliminate din textul final, ASF are in lucru un ghid de indrumare menit sa ofere companiilor mai mici un exemplu practic de abordare a unui astfel de proces.

Intregul proces de identificare, evaluare, tratare si raportare a riscurilor legate de utilizarea IT este realizat de funcția de management a riscului din companie, bineințeles cu suportul celor din zona de business si din IT.

Ce-i de facut practic?

1. Crearea cadrului procedural necesar. Stabilirea cadrului procedural de gestionare a riscurilor IT necesita (la minimum) o politica de gestionare a riscurilor IT si o procedura de evaluare a riscurilor IT. Acestea pot fi create ca documente separate sau pot fi inglobate in cadrul intern de management al riscului. Documentele trebuie sa descrie:

• Cine este responsabil pentru realizarea identificarii si evaluarii riscurilor IT, pentru gestionarea registrului riscurilor IT, pentru stabilirea si monitorizarea indicatorilor de risc etc.
• Cum se vor realiza practic procesele de identificare si evaluare a riscurilor IT etc.
• Frecvența cu care se vor realiza procesele de mai sus, cu care vor fi masurați indicatorii cheie de risc etc.
• Cum se va face raportarea riscurilor, catre cine se vor escalada situațiile monitorizate prin KRI etc.
  

2. Identificarea scenariilor de riscuri IT la care este expusa entitatea. Identificarea se poate face plecand de la:

• O lista de riscuri IT generice, adaptata mediului in care opereaza entitatea (se poate prelua din standarde cum ar fi ISACA RiskIT, COSO sau altele)
• Procesele interne ale entitații
• Obiectivele strategice si operationale ale entitații
• Lista problemelor IT
• Rezultatele auditurilor IT mai recente
• Istoricul incidentelor / pierderilor inregistrate de entitate.
  

Trebuie sa fim atenți ca la identificarea scenariilor de risc IT sa nu ne limitam doar la vulnerabilitațile si amenințarile legate de securitatea informatica, ci sa luam in calcul si alte surse de risc, cum ar fi:

• Intarzierile in livrarea proiectelor IT
• Probleme de aderare la cadrul legislativ (complianța)
• Probleme in livrarea serviciilor IT
• Problemele generate de o arhitectura IT invechita sau inflexibila
  

Scenariile de risc pot fi reutilizate si rafinate la fiecare sesiune de evaluare a riscurilor IT, devenind din ce in ce mai adaptate specificului companiei. Ele vor suferi modificari pe masura ce mediul in care opereaza entitatea se schimba.

3. Evaluarea riscurilor IT identificate prin estimarea frecvenței de apariție si a impactului asupra afacerii, folosind aceleasi scale de estimare utilizate in activitatea de management a riscului la nivelul entitații.

4. Crearea unui registru al riscurilor operaționale generate de utilizarea sistemelor informatice. Acest registru este recomandabil sa fie separat de registrul de riscuri generale la nivelul entitații datorita tipurilor de informații pe care il conține. Riscurile identificate si evaluate vor fi introduse in registru si clasificate, conform normei ASF, in patru categorii: oameni, procese, sisteme/tehnologii, mediul extern. Gestionarea registrului poate fi facuta de IT Security/Compliance Officer sau tot de funcția interna de management al riscului.

5. Stabilirea unui set de indicatori cheie de risc (KRI). Acestia ofera o avertizare timpurie asupra apariției unui risc important, permițand conducerii sa ia masurile cuvenite, prevenind astfel potențialele pierderi.

Pentru alegerea acestora se porneste de la riscurile cu impact mare asupra afacerii, fiecare indicator trebuind sa fie direct asociat cu un risc identificat. Indicatorii de risc sunt legați de apetitul de risc al entitații si de toleranța la risc asumata de aceasta. De aceea se recomanda alegerea de praguri de avertizare (triggeri) pentru fiecare indicator de risc atunci cand acesta iese din intervalul de toleranța asumat, pentru a permite aplicarea de masuri de limitare a efectelor riscului respectiv.

Ca exemple de indicatori cheie de risc IT pot fi (in proiectul de instrucțiune ASF erau date mai multe exemple de KRI):

• Numarul de niveluri de servicii (SLA) afectate de incidente operaționale
• Numar de zile dintre data terminarii contractului cu compania si data incetarii accesului in sistemele IT
• Procent de proiecte IT incheiate la timp si incadrate in buget
• Numar de incidente generate de punerea in producție a modificarilor de aplicații
  

Toleranța la risc este intervalul in care riscul poate devia fața de nivelul asumat prin apetitul de risc si prin obiectivele de afaceri ale entitații. De exemplu:

• Nivelul de disponibilitate al centrului de date este de 99,8% pe luna; cu toate acestea, cazuri izolate de disponibilitate 99,5% vor fi tolerate.
• Exista o procedura de aprobare a unui nou cont utilizator in aplicațiile de afaceri; dar in anumite situații se va tolera abaterea parțiala de la procedura.
• Standardele interne prevad ca proiectele sa se incadreze in termen si buget; insa vor fi tolerate depasiri de buget cu 10% si de termene cu 20%.
• Modificarile in aplicațiile de afaceri nu trebuie sa genereze incidente; cu toate acestea vor fi tolerate izolat incidente cu impact cel mult mediu.
  

6. Includerea in profilul (apetitul) de risc al entitații de elemente legate de sistemele informatice. Aceste elemente vor necesita adaptari ale sistemului IT pentru a satisface aceste limite impuse de conducere prin apetitul de risc. De exemplu:

• Conducerea a determinat ca sistemul de vanzare a contractelor de asigurari de viața nu poate fi intrerupt pe perioade de peste 2 ore, iar sistemul trebuie sa poata asigura un volum anual de tranzacții in crestere cu 15% fara impact asupra performanței.

Pentru a transpune in practica acest lucru, IT trebuie sa traduca aceste cerințe in cerințe legate de redundanța sistemului IT (servere si infrastructura) pe care ruleaza aplicațiile respective. De asemenea, va trebui calculat impactul cresterii numarului de tranzacții asupra resurselor sistemului respectiv, obținand anumite cerințe legate de capacitate.

In varianta inițiala a instrucțiunii ASF se menționa si formularea profilului de risc IT al entitații in legatura cu utilizarea sistemelor informatice, aspect care a fost eliminat din textul curent.

De unde pornim?

Exista mai multe standarde de Enterprise Risk Management (ERM) precum COSO ERM (un framework de guvernanța corporativa a riscurilor), ISO 31000:2009 (gestionarea riscurilor, independent de industrie) sau ISO/IEC 27005:2011 (gestionarea riscurilor legate de securitatea informatica).

De asemenea, exista framework-uri de IT Management precum ITIL, ISO/IEC 20000, ISO/IEC 27001/2, si COBIT de la ISACA.

Insa cel mai relevant trebuie sa ramana cadrul intern de Risk Management al organizației, care va trebui largit pe partea procedurala si organizaționala cu problematica specifica parții de IT.

Despre autor

Are 15 ani experiența in managementul IT, din care 7 ani in industria de asigurari si pensii private. De asemenea a lucrat pentru companii de renume din domeniul FMCG.

Are o experiența solida in crearea sau optimizarea cadrelor procedurale IT in vederea alinierii cu cerințele legale sau de grup si a rezolvarii punctelor de audit IT deschise, precum si cu cadre interne de control intern, managementul riscului si audit intern dobandite intr‐un mediu complex, multinațional.

In prezent furnizeaza consultanța in servicii IT cu accent pe industria de asigurari, in special in domeniul conformitații pentru audituri externe, reglementari tip Solvency II, norma ASF cu privire la gestionarea riscurilor legate de utilizarea sistemelor informatice.

Poate fi contactat la mihnea.mironescu@gmail.com.