Vreme trece, vreme vine,/ Toate-s vechi si noua toate;/ Ce e rau si ce e bine/ Tu te-ntreaba si socoate;….

  (Această postare este un preambul la prezentarea ce o voi ţine la evenimentul organizat de PRMIA la Bucureşti în 11 noiembrie.) Constrîngeri? Au existat în trecut, există în prezent şi vor exista cu certitudine şi în viitor……Doar că în multe modele sînt omise. Despre auditul sistemelor informaţionale am spus că implică altceva decît completarea unor check listuri: înţelegerea riscurilor la care se supune organizaţia şi oferirea unor recomandări reale, deci cu valoare. Cam la fel şi cu managementul riscurilor: nu înseamnă preluarea unui model şi completarea unor template-uri….. Impactul şi frecvenţa sînt două variabile statistice aflate în legătură directă cu informaţiile din trecut. Probabilităţile se vor modifica în urma aplicării unor controale, doar în cazul în care acele controale sînt de tip preventiv. În cazul controalelor detective şi corective, probilitatea nu se modifică! În cazul riscurilor securităţii, impactul va fi evaluat asupra activului în sine…

Cît de mult putem accepta din ceea ce cunoaştem? Dar din ceea ce nu cunoaştem?

Majoritatea metodologiilor de evaluare a riscurilor prezintă două dimensiuni ale subiectului: probabilitatea şi severitatea/impactul: În alte lucrări, imaginea de mai sus arată altfel: Aţi observat că sînt inversate axele? Am scris, de mai multe ori, că teoria riscurilor are la bază probabilităţi iar probabilităţile se bazează pe teoria numerelor mari. Altfel spus, atunci cînd dorim o modificare asupra viitorului, schimbarea trebuie realizată în prezent, pe baza unor informaţii cît mai corecte şi complete despre trecut. Am scris/spus, la fel de des, că în lipsa unor astfel de informaţii, managementul riscurilor este irelevant. Este făcut de dragul de a fi făcut sau pentru că e o cerinţă de conformitate. Recunosc că e puţin forţată afirmaţia anterioară. Ceva, ceva tot se obţine. Ce lipseşte din primul meu grafic şi din cel de la ITGI? Cea de a treia dimensiune care apare în ultima…

Un sprijin pentru Regulamentul 18 BNR: IT Control Objectives for Basel II

COBIT nu se utilizează singular. Este un framework. Este la fel ca la mașini: șasiul nu se vede! Dar este esențial pentru ceea ce se pune peste el. Pe situl ISACA este disponibil (free doar pentru membri) un material excelent: IT Control Objectives for Basel II: The Importance of Governance and Risk Management for Compliance   Lucrarea explică/detaliază rolul IT în cadrul riscului operațional. Reamintesc că în COBIT 4.1 despre managementul riscurilor se face referire in PO9 Estimarea si managementul riscurilor IT. De aici ar trebui să se ajungă pentru detalii…

Cît de importante sînt planificarea și analiza în auditul sistemelor informaționale?

  Standardul S5 Planning “The IS auditor should develop and document a risk-based audit approach.”   La comentarii se menţionează:   “For an external IS audit, a plan should normally be prepared for each audit or non-audit assignment. The plan should document the objectives of the audit.”   Cuvîntul cheie: RISC. Motiv pentru care trecem repede pe la Enterprise Risk…

Riscuri şi proiecte

  M-am confruntat de curînd cu acest subiect: evaluarea (se cerea de fapt un audit) riscurilor într-un proiect de dezvoltare software. Pentru că sînt un adept al teorii sistemelor afirm de multe ori că se omite contextul. Sau banalul de acum, “suma părţilor este mai mare decît întregul”. Consider orice proiect ca fiind tot o…