Oportunitati de voluntariat

La AGM 2014 au existat intrebari legate de oportunitatile de voluntariat care pot ajuta board-ul ISACA Romania sa rezolve mai repede si/sau mai bine anumite probleme curente.

In acest moment, exista cateva taskuri specifice pe care poate fi util un ajutor din partea membrilor:

  • stabilirea procesului de desfasurare a alegerilor si a regulamentului alegerilor
  • inregistrarea modificarilor statutului asociatiei la toate entitatile legale relevante (Registrul Asociatiilor si Fundatiilor, etc)
  • identificarea oportunitatilor de parteneriat la evenimente interesante pentru membri
  • identificarea beneficiilor optime ce pot fi acordate membrilor (a fost mentionata organizarea de evenimente care sa permita acumularea de CPE-uri)

Va rog sa scrieti pe adresa de email contact@ si sa mentionati subiectul pe care sunteti dispusi sa participati si ajutorul pe care-l puteti acorda.

De asemenea, va reamintim ca suntem deschisi si vom incerca sa sustinem logistic si financiar orice initiativa venita din partea membrilor si care poate aduce beneficii unui numar cat mai mare de membri, deci va asteptam cu propuneri.

Program de asistenta pentru chapter pentru efectuarea de traduceri – 2014-2015

♣ Conținut accesibil exclusiv membrilor ISACA, în funcție de nivelul de acces. Autentificaţi-vă pentru a avea acces, cu aceleași credențiale de la isaca.org.


To view the contents of this post, you must be an ISACA member, authenticated and have the required access level.

COBIT5 – A Business Framework

COBIT5 – A Business Framework for the Governance and Management of Enterprise IT

S-au lansat primele documente din noua versiune a cadrului de referinţă COBIT. În acest moment sunt disponibile doar pentru membri.  Noile documente clarifică şi mai mult raţiunea pentru care o organizaţie apelează la un cadru de referinţă sau la bune practici: nevoia de a rezolva o problemă economică!

Începând cu această versiune Guvernarea IT implică Evaluare, Monitorizare şi Conducere; în timp ce Managementul IT se va ocupa de Planificare; Creare; Funcţionare şi Monitorizare.

 

COBIT 5
Cadrul de referinţă pentru managementul şi guvernarea IT (“A Business Framework for the Governance and Management of Enterprise IT”). Volumul documentează cele 5 principii ale noii versiuni COBIT (Meeting Stakeholder Needs; Covering the Enterprise End-to-end; Applying a Single Integrated Framework; Enabling a Holistic Approach; Separating Governance From Management) şi defineşte 7 factori pe care se sprijină această nouă versiune a cadrului de referinţă (Principles, Policies, Frameworks; Processes; Organizational Structures; Culture, Ethics, Behaviour; Information; Services, Infrastructure, Applications; People, Skills, Competences)
COBIT 5 : Enabling Processes
Este ghidul care detaliază procesele în modelul de referinţă prezentat în COBIT 5: obiectivele prezentate conform modelului “cascadă”; explicarea procesului; modelul de referinţă al procesului.
COBIT 5 Implementation
Abordarea bazată pe bune practici pentru implementarea guvernării IT pe baza îmbunătăţirii continue ca etapă a ciclului de viaţă.
   COBIT 5 Toolkit
Resurse de la care se poate porni o implementare practică.
   COBIT 5 Framework Overview
Principalele scheme/figuri întâlnite în COBIT 5 (un rezumat sau pocket guide).

Spre deosebire de COBIT 4.1 nu mai există “control objectives” sau “control practices” ci “governance practices” sau “management practices”.

COBIT 5: A Business Framework for the Governance and Management of Enterprise IT

Riscul auditării

Conform definiţiei, auditul sistemelor informaţionale are drept obiective protecţia activelor, integritatea datelor eficacitatea şi eficienţa sistemului.

De exemplu, atât auditorii interni cât şi cei externi caută să identifice care sunt pierderile materiale sau erorile din cadrul raportărilor financiare ca urmare a neregulilor descoperite în cadrul sistemului auditat. Orice afirmaţie făcută de auditor trebuie însă susţinută de probe sau dovezi. Datorită naturii testelor la care se face apel, există riscul ca CISA să eşueze în încercarea de a identifica erorile reale sau potenţiale din cadrul sistemului. Acesta este riscul auditării.

AICPA, organizaţia ce grupează auditorii externi din SUA, a elaborat în 1988 un model de calcul al riscului auditării[1]:

RA = RI * RC * RD, unde

RA= riscul auditării/de audit;

RI= riscul inenrent;

RC=riscul controlului;

RD=riscul detectării.

Acest model rămîne valabil şi în cazul auditului sistemelor informaţionale[2]. În manual de pregătire pentru examenul CISA se menţionează că auditorul de sisteme informaţionale trebuie să estimeze riscul de audit pentru a aloca în mod corespunzător resursele în timpul misiunii.

Riscul inerent reprezintă disponibilitatea unei zone supusă auditării de a conţine erori pornind de la ipoteza că nu există controale interne. Erorile pot fi materiale, individuale sau orice altă combinaţie posibilă.

De exemplu, riscul inerent asociat securităţii sistemului de operare de pe un server de baze de date este mare atît timp cît modificarea sau divulgarea datelor ca urmare a speculării eventualelor bug-uri/configurări greşite pot să aibă ca efect pierderea avatajului deţinut de organizaţie pe piaţă. Dacă în schimb discutăm de o staţie de lucru, acest risc poate fi considerat redus atît timp cît respectiva staţie nu rulează aplicaţii considerate critice pentru organizaţie.

Atât timp cât erorile potenţiale din cadrul unei singure componente a sistemului informaţional se pot propaga în întreaga organizaţie şi asupra tuturor utilizatorilor, în majoritatea sistemelor informaţionale acest risc este considerat ridicat.

În evaluarea riscului inerent, auditorul trebuie să aibă în vedere atât controalele considerate dominante[3] în zona supusă auditării cât şi pe cele de detaliu/fond[4]. Excepţie de la această abordare face situaţia în care evaluarea auditorului vizează în exclusivitate controalele dominante din cadrul sistemului. În ceea ce priveşte controalele dominate ce acţionează în zona supusă evaluării, auditorul trebuie să aibă în vedere :

  • integritatea, experienţa şi cunoştinţele conducătorilor compartimentului de specialitate;
  • schimbările intervenite la nivelul conducerii compartimentului;
  • presiunile la care sunt supuşi managerii acestui compartiment (termenele “strânse” ale proiectelor în derulare etc.);
  • domeniul de activitate al organizaţiei şi natura sistemului informaţional (planuri privind trecerea la comerţul electronic, soluţii ERP sau lipsa acestora etc);
  • factori care afectează domeniul tehnologiilor informaţionale la scară mondială (apariţia unor tehnologii noi, lipsa specialiştilor care să deţină noile cunoştinţe);
  • gradul de influenţă al terţilor asupra controalelor (outsourcing, accesarea directă a sistemului de către clienţi/terţi);
  • disponibilitatea informaţiilor din auditările precedente.

La nivelul controalelor detaliate/de fond, auditorul trebuie să ţină cont de :

  • complexitatea sistemului;
  • nivelul intervenţiilor manuale în sistem;
  • disponibilitatea la pierderi sau furt a componentelor controlate de către sistem (evidenţa stocurilor, salarizarea);
  • apariţia perioadelor de vârf în timpul auditării (închiderile de lună).

Riscul controlului reprezintă riscul ca o eroare care poate să apară în zona supusă auditării să nu fie prevenită sau detectată şi corectată de către sistemul de control intern într-o perioadă rezonabilă de timp.

De exemplu, riscul pe care îl implică revizia manuală a jurnalelor sau a tabelelor de audit realizate de un server Oracle va fi considerat mare datorită volumului mare de informaţii înmagazinate în aceste jurnale şi a uşurinţei cu care se greşeşte în aceste situaţii. Pe de altă parte riscul controlului asociat procedurilor formalizate de validare a datelor este considerat redus datorită continuităţii acestui control şi a testelor efectuate anterior dării în exploatare a aplicaţiei.

Auditorul va atribui cel mai mare nivel riscului controlului cu excepţia situaţiilor în care:

  • au fost identificate controale interne relevante;
  • aceste controale au fost evaluate ca fiind în funcţiune;
  • controalele au fost testate şi s-a dovedit că funcţionează în mod corespunzător.

 Riscul detecţiei reprezintă riscul ca un test independent/de fond efectuat de către auditor să nu detecteze o eroare care există în zona supusă auditării.

De exemplu, riscul detecţiei asociat identificării punctelor slabe ale securităţii unei aplicaţii va fi mare atât timp cât logurile/jurnalele pentru întreaga perioadă supusă auditării nu vor fi disponibile în totalitate în momentul efectuării verificării. Pe de altă parte, riscul detecţiei asociat identificării existenţei unui plan de refacere în caz de dezastre, va fi considerat redus atât timp cât existenţa acestui document este uşor de verificat.

Pentru a determina numărul testelor independente/de fond care trebuie efectuate, auditorul trebuie să ţină cont de:

  • nivelul la care a fost evaluat riscul inerent;
  • concluziile la care a ajuns în urma efectuării testelor de conformitate.

Aici mai intervine şi riscul eşantionării/noneşantionării. Riscul auditului este invers proporţional cu ceea ce statistica definişte ca fiind gradul de încredere. Un risc de acceptare incorectă de 5% este echivalent cu a spune că a fost asociat un grad de încredere de 95%. Altfel spus, ca auditor pot afirma că sunt 95% sigur că eşantionul analizat reprezintă populaţia sau că există o şansă de 5% ca eşantionul să nu reprezinte populaţia.

În concluzie, putem spune că, dacă riscul inerent şi riscul controlului au fost evaluate la un nivel mare, atunci auditorul trebuie să obţină cât mai multe probe prin efectuarea testelor independente/de fond!


[1] Accounting Principles and Auditing Standards

[2] IS Audit Guidelines – www.isaca.org/ Standards & Guidelines

[3] Controalele dominate sunt controalele generale, proiectate cu scopul de a administra şi a monitoriza sistemul informaţional şi care afectează toate activităţile acestuia

[4 ]Controalele detaliate sunt controalele efectuate asupra achiziţiei/dezvoltării, implementării şi întreţinerii sistemului informaţional. În componenţa lor intră controalele aplicaţiilor şi controalele generale care nu sunt considerate dominante.

Cum ajută COBIT la atingerea conformităţii: exemplu Regulamentul 18 BNR

Art.2 al Regulamentul 18/2009 consolidat defineşte noţiuni comune practicii guvernării IT:

d) control intern – proces continuu, destinat să furnizeze o asigurare rezonabilă pentru îndeplinirea obiectivelor de performanţă – eficacitatea şi eficienţa activităţilor desfăşurate -, de informare – credibilitatea, integritatea şi furnizarea la timp a informaţiilor financiare şi ale celor necesare conducerii –  şi de conformitate – conformarea cu legile  şi  reglementările aplicabile, precum şi cu politicile şi procedurile interne – şi care, pentru a fi eficace, necesită implementarea următoarelor 3 funcţii: funcţia de administrare a  riscurilor, funcţia de conformitate şi funcţia de audit intern. Controlul intern include, de  asemenea, organizarea contabilităţii, tratamentul informaţiilor, evaluarea riscurilor  şi  sistemele de măsurare a acestora;”

“o)  risc aferent tehnologiei informaţiei (IT) – subcategorie a riscului operaţional care se referă la riscul actual sau viitor de afectare negativă a profiturilor  şi capitalului,  determinat de inadecvarea strategiei  şi politicii IT, a tehnologiei informaţiei  şi a  procesării informaţiei, cu referire la capacitatea de gestionare, integritatea,
controlabilitatea  şi continuitatea acesteia, sau de utilizarea necorespunzătoare a tehnologiei informaţiei; ”

Art. 28.   este cel care face referire la sistemele informaţionale, controlul intern şi riscuri

 (5) În contextul alin. (2), instituţiile de credit trebuie să respecte cerinţele organizaţionale şi de control intern legate de procesarea electronică a informaţiilor şi să asigure existenţa unei piste de audit adecvate

 (6) Sistemele informaţionale ale instituţiilor de credit, inclusiv cele care păstrează şi utilizează date în format electronic, trebuie să fie sigure, monitorizate independent şi susţinute de planuri alternative corespunzătoare, care să le permită continuarea activităţii în cazul apariţiei unor situaţii neprevăzute. Replicarea sistemelor informatice critice trebuie asigurată fie prin existenţa unor sisteme de rezervă situate într-o altă locaţie a instituţiei de credit – centru de back-up -, fie prin intermediul unui furnizor extern de servicii.

(7) Funcţionarea planurilor alternative prevăzute la alin. (6) trebuie testată periodic prin simularea operaţiunilor pe sistemele de rezervă.

(8) Instituţiile de credit trebuie să controleze eficient riscurile implicate de utilizarea sistemelor informatice. În acest scop, se vor efectua atât controale generale la nivelul întregului sistem informatic, cât şi controale la nivelul fiecărei aplicaţii informatice din componenţa acestuia.

(9) Controalele generale trebuie efectuate asupra infrastructurii hardware şi de comunicaţii a sistemelor informatice – sisteme mainframe, sisteme client/server, routere, echipamente de reţea, staţii de lucru ale utilizatorilor finali, precum şi asupra sistemelor de operare care asigură funcţionarea acestora. Controalele au drept scop verificarea funcţionării continue şi corespunzătoare a acestora.

(10) Controalele generale includ şi verificarea existenţei şi aplicării unei strategii de informatizare, a procedurilor interne de salvare şi restaurare a datelor, a politicilor de efectuare a achiziţiilor, a procedurilor de dezvoltare a aplicaţiilor informatice, a procedurilor de administrare şi întreţinere, precum şi a politicilor de securitate vizând accesul fizic şi logic la resursele sistemului informatic. 

(11) Controalele efectuate la nivelul aplicaţiilor informatice reprezintă proceduri de validare şi control incluse în codul aplicaţiilor informatice utilizate, precum şi proceduri manuale de verificare a modului de procesare a tranzacţiilor şi a efectuării operaţiunilor.

Ce suport oferă COBIT?

În primul rând este dezvoltat conform COSO (Committee of Sponsoring Organizations). În al doilea rând oferă ghiduri pentru management şi responsabilii de procese economice. În al treilea rând oferă un set generic de procese IT aliniate proceselor economice. În al patrulea rând oferă cerinţele pe care managementul trebuie să le aibă în vedere pentru controlarea proceselor IT – obiectivele controlului. Responsabilii de la nivel operaţional ştiu astfel ce set de controale este necesar unui anumit proces din organizaţie.

COBIT ofera exemple de intrări şi ieşiri pentru fiecare proces în parte. Este flexibil şi nu este prescriptiv. Oferă în plus o descriere a responsabilităţilor celor care sunt sau pot fi implicati într-un proces. Responsabilitatea pentru controalele implementate la nivelul aplicaţiilor este o responsabilitate comună atît domeniului economic cât şi IT-ului. Managementul proceselor economice răspunde de definirea corespunzătoare a cerinţelor funcţionale şi de control, de utilizarea serviciilor automatizate în mod potrivit . Managementul IT este responsabil pentru automatizarea şi implementarea cerinţelor funcţionale şi de control, de stabilirea elementelor de gestiune pentru a menţine integritatea, aplicabilitatea şi eficienţa controalelor implementate la nivelul aplicaţiilor.

Pragul de semnificaţie în auditul sistemelor informaţionale

Atunci cînd planifică o misiune, auditorul trebuie să aibă în vedere trei perspective: conformitatea, operaţionalul şi strategicul. Un concept oarecum ambiguu pentru auditorii de sisteme informaţionale este “materialitatea/pragul de semnificaţie”.

Conform LISTEI TERMENILOR CHEIE ISA 2008, materiality înseamnă (prag de) semnificaţie. În cazul auditului financiar (ne place ori nu, pragul de semnificaţie trebuie înţeles pornind de aici), se spune:

 Informaţiile sînt semnificative dacă omisiunea sau declararea lor eronată ar putea influenţa deciziile economice ale utilizatorilor, luate pe baza situaţiilor financiare. Pragul de semnificaţie depinde de mărimea elementului sau a erorii, judecate în împrejurările specifice ale omisiunii sau declarării eronate. Astfel, pragul de semnificaţie oferă mai degrabă o limită, decît să reprezinte o caracteristică calitativă primară pe care informaţia trebuie să o aibă pentru a fi utilă. – ISA 320 Audit Materiality

În cazul auditului sistemelor informaţonale, situaţia este puţin mai complicată. Aceasta deoarece auditul financiar exprimă pragul de semnificaţie în termeni monetari. Standardul de audit financiar menţionat anterior spune:

Pragul de semnificaţie trebuie luat în considerare de auditor atunci cînd:

a) se determină natura, durata şi întinderea procedurilor de audit

b) se evaluează efectele informaţiilor eronate

Materiality Concepts for Auditing Information Systems Document G6 spune:

În evaluarea pragului de semnificaţie, auditorul de SI trebuie să ia în considerare:

– nivelul agregat al erorilor acceptabile de către management, auditorul, agenţiile cu atribuţii de reglementare şi celelalte părţi interesate

– potenţialul ca efectul cumulat al unor erori nesemnificative sau puncte slabe să devină semnificativ

Ghidul din care am tradus şi adaptat lămureşte şi ce înseamnă “control semnificativ” – un control sau un grup de controale în lipsa căruia procedurile de control nu oferă asigurări rezonabile că obiectivul controlului va fi atins.

Ghidul prezintă şi aspectele ce trebuie avute în vedere de către un CISA atunci când evaluează pragul de semnificaţie:

  • Cât sunt de critice sunt procesele economice realizate cu ajutorul sistemului informaţional
  • Cât este de critică baza de date folosită
  • Numărul şi tipul aplicaţiilor dezvoltate
  • Numărul utilizatorilor sistemului informaţional
  • Numărul managerilor sau directorilor ce lucrează cu sistemul informaţional, clasificaţi în funcţie de privilegiile avute
  • Cât de critice sunt comunicaţiile/reţeaua
  • Costul sistemului sau al operării acestuia (hardware, software, staff, servicii third-party etc)
  • Costul potenţial al erorilor (pe cât posibil exprimat în termeni de pierdere a vânzărilor, garanţii, costuri de dezvoltare neacoperite, costuri de rectificare etc.)
  • Costul pierderii informaţiilor vitale
  • Eficienţa măsurilor de securitate
  • Numărul tranzacţiilor/interogărilor pe o perioadă de timp
  • Natura, dimensiunea, data rapoartelor şi fişierelor întreţinute
  • Natura şi cantitatea materialelor manipulate
  • SLA şi costul penalităţilor
  • Penalităţile nerespectării cerinţelor legale, statutare sau contractuale

Despre ISACA

Cu mai mult de 95,000 membri în mai mult de 160 de ţări, ISACA ® – Information Systems Audit and Control Association (www.isaca.org) este un important furnizor mondial de cunoştinţe, certificări, comunitate profesională, suport pentru formare profesională în domeniul securităţii, guvernării şi serviciilor de asigurare IT şi tratare a riscurilor asociate sistemelor informaţionale.

Viziune:

Lider recunoscut la nivel mondial în domeniul guvernării, controlului şi asigurării IT.

Misiune:

Sprijinirea obiectivelor companiilor prin dezvoltarea, furnizarea şi promovarea cercetării, a standardelor, competenţelor şi practicilor eficiente de guvernare, control şi asigurare a sistemelor informaţionale şi tehnologiilor.

Fondată în 1969, ISACA sponsorizează conferinţe internaţionale, publică ISACA ® Journal şi dezvoltă standardele internaţionale pentru controlul şi auditul sistemelor informaţionale. De asemenea administrează renumitele certificări internaţionale Certified Information Systems Auditor™ (CISA®), Certified Information Security Manager® (CISM®), Certified in the Governance of Enterprise IT® (CGEIT®) şi Certified in Risk and Information Systems Control™ (CRISC™).

Certificările ISACA sunt acceptate şi recunoscute la nivel mondial. Ele combină realizarea trecerii unui examen cu recunoaşterea experienţei profesionale şi educaţionale, oferind credibilitate pentru a progresa în carieră. Certificările dovedesc că un angajat deţine ceea ce este necesar pentru a adăuga valoare organizaţiei. În fapt, multe organizaţii şi agenţii guvernamentale din întreaga lume recunosc sau solicită ca primă cerinţă de angajare certificări ISACA.

Studii independente evidenţiază în mod constant certificările ISACA printre cele mai utile si de impact certificări pe care un profesionist IT le poate deţine. ISACA oferă Business Model for Information Security (BMIS) şi IT Assurance Framework (ITAF). De asemenea dezvoltă şi actualizează în mod continuu cadrele de referinţă COBIT®, Val IT™ şi Risk IT, cadre ce îi ajută pe profesioniştii din domeniul IT şi pe liderii organizaţiilor să îşi îndeplinească responsabilităţile cu privire la guvernarea IT şi să aducă valoare organizaţiei.

Calitatea de membru ISACA oferă beneficii importante:

  • ISACA eLibrary — o colecţie completă a cărţilor publicate de ISACA /ITGI şi peste 350 de titluri suplimentare;
  • Reduceri de tarif pentru membri ce aplică pentru certificările CISA, CISM, CGEIT şi CRISC;
  • Reduceri de tarif la conferinţele şi sesiunile de instruire ISACA;
  • Webcasts şi e-Symposia;
  • Evenimente educaţionale şi prezentări ale Chapterului local;
  • Acces gratuit la ISACA Journal — revista bilunară a Asociaţiei;
  • @ISACA — acces la newsletter-ul bilunar al Asociaţiei;
  • COBIT Online — acces gratuit la funcţionalităţile de bază;
  • COBIT Quickstart — descărcare gratuită;
  • Download Center— acces gratuit doar pentru membri la materialele ISACA/ITGI;
  • Knowledge Center— acces exclusiv în comunitatea profesioniştilor domeniului;
  • Standarde — acces la standardele, procedurile şi ghidurile de audit ISACA;
  • Programe de audit şi chestionare pentru control intern;
  • Oportunităţi de cercetare.

ISACA ROMÂNIA a fost recunoscută încă din anul 2001, numărând în prezent peste 260 de membri, dintre care peste 130 certificați CISA, CISM, CGEIT sau CRISC.

ISACA ROMÂNIA doreşte să contribuie la creșterea gradului de conștientizare cu privire la necesitatea controlului și guvernării tehnologiilor informaționale în cadrul organizațiilor, prin promovarea educaţiei în rândul membrilor și non-membrilor. Scopul filialei din România a asociației este de a îmbunătăţi şi dezvolta abilităţile referitoare la audit, securitate și controlul sistemelor informaționale.