Într-o discuție sinceră despre ”riscuri IT” ar trebui să recunoaștem următoarea situație:

dacă nu ar exista cerințe de conformitate, o mare parte din ”riscurile IT” nu vor fi luate în calcul de responsabilii cu ”guvernarea”.

Acest lucru se întîmplă din cauza percepției: riscurile IT nu sînt percepute ca riscuri operaționale. Dacă lucrurile ar sta diferit față de cele scrise mai sus, atunci în cele mai multe organizații s-ar cunoaște:

• procesele, activitățile proceselor din fiecare unitate funcțională și dependențele acestora;
• activele (resurse umane și tehnologii) asociate proceselor;
• terții, procesele și activele asociate terților;
• „coșmarurile„ – riscurile percepute;
• soluții=controale interne=politici, tehnicisme…etc.

În fapt ne place să ne jucăm cu aritmetica, să o ”rezolvăm din condei”, să ducem riscul de la ”7” la ”5” , de pe ”roșu” pe ”orange/verde”, printr-o opțiune de ”tratare” numită ”politică/procedură”…deși sîntem conștienți că securitatea unui cont utilizator/laptop/etc nu se poate asigura doar cu o politică….

Nu se poate face ”guvernare” fără a cunoaște ”riscurile” și nu se poate face ”management riscuri” fără a avea ”controale”.

Pentru a avea garanții că există controale funcționabile trebuie ca la final ”cineva” să le testeze. Și acela este auditorul:

• testează modul în care este proiectat controlul (este conceput să atingă obiectivul dorit/cerut?);
• testează modul în care funcționează în realitate (eficacitatea).

Să presupunem că există o ”cerință de conformitate” cu privire la ”managementul vulnerabilităților tehnice” care impune că

• ”trebuie obținute informații despre vulnerabilitățile tehnice ale sistemelor informaționale în uz, trebuie evaluată expunerea organizației la astfel de vulnerabilități și trebuie luate măsurile adecvate”/”accesul la site-uri web externe ar trebui gestionat pentru a reduce expunerea la conținutul rău intenționat.” – (ISO27001)
• ”OSE dezvoltă un proces de identificare, clasificare, remediere şi eliminare a vulnerabilităţilor, în special însoftware şi firmware.” – ”Art. 21, Ordinul 1323”
• ”Vulnerabilitățile în active sunt identificate, validate și înregistrate” – (NIST CSF2.0).

Cum se explică ”structurii de guvernare” o astfel de cerință? Care sînt ”controalele” care trebuie să existe și pe care auditorul le va verifica și testa? Doar ”politica/procedura”?.