MANUAL DE AUDIT AL

TEHNOLOGIILOR INFORMAŢIONALE

Chişinău

2010

1
 Prefaţă
Societatea determină o creştere dinamică a dependenţei tuturor domeniilor
vieţii economico-sociale de tehnologiile informaţionale. Valorificarea posibilităţilor
oferite de TI presupune acceptarea unor riscuri specifice, cum ar fi: securitatea
informaţională, dependenţa prea mare de gradul de calificare a persoanelor
responsabile, veridicitatea datelor, costurile mari de întreţinere, nedorinţa unor
angajaţi de a accepta schimbările etc. Luând în considerare consumul de resurse
umane şi financiare la dezvoltarea unui sistem informaţional automatizat, este
necesar să se desfăşoare anumite activităţi care să ducă la atingerea obiectivului
propus la timp, cu nivelul de calitate stabilit şi în limita bugetului alocat. Una din
aceste activităţi, deosebit de importantă pentru realizatori, dar mai ales pentru
utilizatori, este auditul tehnologiilor informaţionale.
Auditul sistemelor şi tehnologiilor informaţionale are scopul de a oferi
certitudine rezonabilă managementului de vârf precum că riscurile generate de
utilizarea TI în cadrul organizaţiei sunt adecvat conştientizate şi gestionate
corespunzător.
Anume din aceste considerente Curtea de Conturi, ca instituţia supremă de
audit din RM, începând cu anul 2009 a început realizarea auditului Sistemele IT şi
Tehnologiile Informaţionale în paralel cu auditul regularităţii şi cel al performanţei.
În acest scop, prin Hotărârea Curţii de Conturi nr. 54 din 22.12.2009, au fost
aprobate standardele de audit al TI.
Auditul TI poate avea şi obiectivul de a determina nivelul de corespundere
anumitor reglementări şi standarde în domeniu, precum: standardele de audit TI a
ISACA şi Cadrul CoBIT; Rapoartele IIA; Standarde elaborate de organizaţii de
specialitate, cum ar fi ISACF sau IFAC, COSO; Pentru ramuri separate ale TI sunt
elaborate standarde internaţionale ISO.
În acest scop, Curtea de Conturi, prin intermediul auditului Tehnologiilor
Informaţionale, v-a analiza sistemele TI, mediul lor de funcţionare, procesele de
business aferente, v-a colecta probe de audit şi v-a evalua eficienţa şi suficienţa
mijloacelor de control ale riscurilor TI. De asemenea, în cazul în care v-a constata
situaţii ce implică riscuri inacceptabile pentru organizaţie sau neconformări la cadrul
de reglementare, v-a oferi recomandări pentru remedierea situaţiei.
Prezentul manual cuprinde un ansamblu de proceduri şi orientări stabilite de către
Curtea de Conturi în baza standardelor şi practicilor internaţionale.
Obiectivul manualului este de a contribui la atingerea unei calităţi înalte a
activităţilor de audit al sistemelor IT şi tehnologiilor informaţionale şi de a
consolida competenţele profesionale ale auditorilor în acest domeniu.

2
 Cuprins
Prefaţă ...................................................................................................................... 2
Cuprins .................................................................................................................... 3
Glosar şi abrevieri ................................................................................................ 8
CAAT (Computer Assisted Auditing Techniques) – tehnici de audit asistate de
calculator............................................................................................................ 8
Capitolul I. Procesul auditului IT .................................................................... 12
1. Introducere în auditul IT ............................................................................. 12
1.1. Definiţia auditului IT ............................................................................ 12
1.2. Obiectivele Auditului TI ....................................................................... 14
1.3. Misiunea Curţii de Conturi .................................................................. 15
2. Etapele auditului TI ..................................................................................... 16
2.1. Planificarea pentru auditul IT ............................................................. 17
2.1.1. Privire generală ..................................................................................... 17
2.1.2. Planul strategic ...................................................................................... 17
2.1.3. Planul anual ........................................................................................... 18
2.1.4. Micro-planul /Programul de audit ......................................................... 18
2.2. Planificarea tehnică ............................................................................. 18
2.3. Planificarea logistică ........................................................................... 19
2.4. Cerinţe de resurse ................................................................................ 19
2.4.1. Resurse de personal ............................................................................... 19
2.4.2. Fonduri ................................................................................................... 20
2.4.3. Resurse tehnice ....................................................................................... 20
3. Studiul preliminar şi colectarea informaţiei despre entitate ...................... 21
3.1. Cunoaşterea entităţii ............................................................................ 21
3.1.1. Mediul organizaţional ....................................................................... 21
3.1.2. Structura organizatorică ................................................................... 22
3.1.3. Aprecierea importanţei Sistemului ................................................... 22
3.1.4. Natura echipamentului şi a aplicaţiilor utilizate .............................. 23
4. Evaluarea riscurilor pentru a defini scopul şi obiectivele auditului ......... 23
4.1. Paşi în analiza riscurilor...................................................................... 24
4.2. Riscul inerent ........................................................................................ 24
4.3. Riscul de control................................................................................... 24
4.4. Identificarea domeniilor de control ale managementului riscului ...... 26
4.5. Domeniul de aplicare şi scopul auditului intern .................................. 26
4.6. Riscul de nedetectare ........................................................................... 27
4.7. Obiectivele şi domeniul de aplicabilitate a auditului .......................... 27
5. Şedinţa de deschidere ................................................................................... 28
6. Colectarea şi evaluarea probelor ................................................................. 28
6.1. Tipuri de probe de audit ....................................................................... 29
6.1.1. Probele fizice ..................................................................................... 29
6.1.2. Interviul ............................................................................................. 30
6.1.3. Chestionarele .................................................................................... 30
3
 6.1.4. Diagramele de flux ............................................................................ 31
6.1.5. Procedurile analitice......................................................................... 32
6.2. Instrumente de colectare a probelor .................................................... 32
6.2.1. Software generalizat de audit ........................................................... 32
6.2.2. Software-ul de audit specific unei ramuri ......................................... 32
6.2.3. Software-ul specializat de audit ........................................................ 33
6.2.4. Instrumente de auditare concomitentă.............................................. 33
6.3. Teste de audit........................................................................................ 34
6.4. Eşantionarea ........................................................................................ 34
6.5. Evaluarea probelor .............................................................................. 35
7. Şedinţa de închidere ..................................................................................... 37
8. Documentarea procesului de audit şi raportarea ....................................... 37
8.1. Importanţa documentării...................................................................... 37
8.2. Forma, conţinutul şi domeniul de aplicare a documentaţiei de audit . 37
8.3. Feedback-ul (comentariile) managementului entităţii auditate .......... 38
8.4. Raportarea............................................................................................ 38
8.5. Structura raportului Auditului TI ......................................................... 39
8.6. Limitările întâlnite pe parcursul efectuării auditului .......................... 40
Capitolul II. Metodologia de Audit ................................................................. 41
9. Controalele TI .............................................................................................. 41
9.1. Controale generale & ale aplicaţiilor.................................................. 41
9.1.1. Controale IT generale ....................................................................... 42
9.1.2. Controalele aplicaţiei........................................................................ 42
9.2. Relaţia dintre controalele generale şi controalele aplicaţiei .............. 43
9.2.1. Controale IT tip “ceapa” .................................................................. 43
10. Evaluarea controalelor generale............................................................... 46
10.1. Controalele organizaţionale şi de management (politicile şi standardele
IT) 46
10.1.1. Riscurile asociate cu controalele inadecvate ................................... 47
10.1.2. Organizaţia şi structura IT ............................................................... 48
10.1.2.1. Controlul şi implicarea managementului superior........................ 48
10.1.3. Strategia IT........................................................................................ 49
10.1.4. Personalul şi instruirea ..................................................................... 50
10.1.4.1. Structurile organizaţionale /organigrame/ .................................... 50
10.1.4.2. Fişele de post ................................................................................. 50
10.1.4.3. Planificarea personalului .............................................................. 51
10.1.4.4. Instruirea şi pregătirea personalului ............................................. 51
10.1.4.5. Politicile de recrutare/eliberare din funcţie şi coduri de conduită 51
10.1.4.6. Evaluarea personalului, inclusiv promovarea şi retrogradarea ... 52
10.1.4.7. Contracte speciale.......................................................................... 52
10.1.4.8. Rotaţia personalului....................................................................... 52
10.1.4.9. Concediile obligatorii .................................................................... 53
10.1.5. Politicile de documentare şi păstrare ............................................... 53
10.1.5.1. Politica de documentare a sistemelor ............................................ 53
10.1.5.2. Politicile de păstrare a documentelor ........................................... 53
4
10.1.6. Politica de externalizare a serviciilor............................................... 54
10.1.7. Implicarea auditului intern ............................................................... 54
10.1.8. Politica de securitate IT .................................................................... 55
10.1.9. Conformitatea legală şi de reglementare ......................................... 56
10.1.10. Segregarea sarcinilor .................................................................... 57
10.2. Operaţiuni TI ........................................................................................ 59
10.2.1. Rolurile şi responsabilităţile operaţiunilor IT .................................. 59
10.2.2. Riscurile asociate cu operaţiunile computerizate slab controlate ... 60
10.2.3. Controlul operaţiunilor IT ................................................................ 60
10.2.3.1. Acorduri privind nivelul serviciilor ............................................... 60
10.2.3.2. Controlul, revizuirea şi supravegherea din partea managementului
61
10.2.3.3. Instruirea şi experienţa .................................................................. 61
10.2.3.4. Întreţinerea calculatoarelor........................................................... 62
10.2.3.5. Documentarea operaţiunilor ......................................................... 62
10.2.3.6. Managementul problemelor ........................................................... 63
10.2.3.7. Managementul şi controlul reţelei ................................................. 63
10.3. Controale fizice şi de mediu ................................................................. 63
10.3.1. Introducere ........................................................................................ 63
10.3.2. Riscuri asociate cu controale fizice sau de mediu insuficiente/absente
64
10.3.2.1. Fizice .............................................................................................. 64
10.3.2.2. De mediu ........................................................................................ 64
10.3.3. Abordarea clientului faţă de riscurile fizice şi de mediu .................. 65
10.3.4. Controale fizice şi de mediu specifice ............................................... 65
10.3.4.1. Controlul fizic al zonelor sigure .................................................... 65
10.3.4.2. Controale administrative: .............................................................. 65
10.3.4.3. Controale de mediu ........................................................................ 68
10.4. Controale de acces logic ...................................................................... 70
10.4.1. Introducere ........................................................................................ 70
10.4.1.1. Riscul asociat cu controale de acces logic inadecvate.................. 71
10.4.1.2. Atacatorii ....................................................................................... 72
10.4.1.3. Consecinţele unei breşe în securitatea accesului logic ................. 72
10.4.2. Resurse, fişiere şi instalaţii care necesită protecţie ......................... 73
10.4.2.1. Fişiere de date................................................................................ 73
10.4.2.2. Aplicaţii .......................................................................................... 73
10.4.2.3. Fişiere cu parole ............................................................................ 73
10.4.2.4. Programe informatice şi instrumente de sistem (system tools) ..... 73
10.4.2.5. Fişiere jurnal.................................................................................. 74
10.4.2.6. Fişierele gata pentru imprimare şi cele temporare ....................... 74
10.4.3. Cadrul de securitate a accesului ....................................................... 74
10.4.4. Sistemul de operare şi controalele de acces la aplicaţii .................. 75
10.4.5. Controalele de acces logic la nivel de instalare ............................... 75
10.4.5.1. Gestiunea conturilor ...................................................................... 75
10.4.5.2. Proceduri de conectare la sistem................................................... 76
5
 10.4.5.3. Identificarea şi autentificarea utilizatorului .................................. 77
10.4.5.4. Autentificarea ................................................................................. 77
10.4.5.5. Protecţia resurselor ....................................................................... 80
10.4.5.6. Securizarea fişierelor şi programelor............................................ 80
10.4.5.7. Alte controale de acces logic ......................................................... 81
10.4.6. Evidenţa jurnalelor ........................................................................... 82
10.5. Planul de Continuitate în Afaceri şi Planul de Recuperare în caz de
Dezastru............................................................................................................ 83
10.5.1. Obiectivele de audit........................................................................... 83
10.5.2. Zonele de risc .................................................................................... 83
10.5.3. Proceduri de audit............................................................................. 83
10.6. Controalele sistemelor orientate pe utilizator ..................................... 85
10.6.1. Ce înseamnă sisteme orientate pe utilizator (End-User Computing)?
85
10.6.2. Riscurile asociate cu sistemele orientate pe utilizator ..................... 85
10.6.2.1. Elaborarea sistemelor .................................................................... 85
10.6.2.2. Dublarea efortului.......................................................................... 86
10.6.2.3. Neconcordanţa datelor .................................................................. 87
10.6.2.4. Utilizarea sporită a resurselor şi costurilor .................................. 87
10.6.2.5. Ştergerea informaţiei centrale ....................................................... 87
10.6.2.6. Conformitatea cu legislaţia............................................................ 87
10.6.2.7. Pierderile de date ........................................................................... 88
10.6.2.8. Securitatea accesului logic şi fizic ................................................. 88
10.6.3. Viruşi de calculator ........................................................................... 89
10.6.4. Controalele sistemelor orientate pe utilizator .................................. 89
10.6.4.1. Controalele proceselor de elaborare a sistemelor ........................ 89
10.6.4.2. Dublarea efortului.......................................................................... 90
10.6.4.3. Neconcordanţa datelor .................................................................. 90
10.6.4.4. Legislaţia ........................................................................................ 90
10.6.4.5. Pierderile de date ........................................................................... 90
10.6.4.6. Acces logic şi fizic .......................................................................... 91
10.6.4.7. Asistenţă/suport pentru utilizatorii finali ....................................... 91
10.7. Controlul schimbărilor......................................................................... 92
10.7.1. Obiectivele de audit........................................................................... 92
10.7.2. Necesităţile de schimbări în sisteme ................................................. 92
10.7.3. Domeniile de risc .............................................................................. 93
10.7.4. Proceduri de audit............................................................................. 93
11. Controalele aplicaţiei ................................................................................. 94
11.1. Tipuri de aplicaţie ................................................................................ 94
11.1.1. Sisteme de introducere a datelor pe loturi (batch processing)......... 94
11.1.2. Sisteme ce operează în timp real (on-line processing) ..................... 94
11.2. Utilizatorii, administratorii şi proprietarii aplicaţiei .......................... 94
11.2.1. Proprietarul aplicaţiei ...................................................................... 94
11.2.2. Administratorul de aplicaţie ............................................................. 95
11.2.3. Utilizatorii ordinari ai sistemului ..................................................... 95
6
 11.3. Definirea controalelor intrării, procesării & ieşirii datelor ............... 95
11.4. Controalele introducerii datelor (Input controls)................................ 96
11.4.1. Autorizarea introducerii datelor ....................................................... 97
11.4.2. Plenitudinea introducerii datelor...................................................... 98
11.4.3. Validarea datelor introduse .............................................................. 99
11.4.4. Verificările duble ............................................................................ 102
11.4.5. Concordanţa (Matching)................................................................. 103
11.4.6. Gestiunea intrărilor refuzate .......................................................... 103
11.5. Controale procesării datelor (processing controls) .......................... 103
11.5.1. Controalele run to run .................................................................... 104
11.5.2. Controalele de reconciliere a fişierelor .......................................... 105
11.5.3. Controalele de validate a tranzacţiilor ........................................... 105
11.5.4. Procedurile de gestionare a discrepanţelor ................................... 105
11.6. Controalele ieşirii datelor .................................................................. 105
11.6.1. Prezicerea rezultatului .................................................................... 106
11.6.2. Plenitudinea datelor-rezultat .......................................................... 106
11.6.3. Protecţia fişierelor - rezultat ale aplicaţiei .................................... 106
11.6.4. Raţionalitatea datelor-rezultat ........................................................ 107
11.6.5. Producerea datelor-rezultat în timp util ......................................... 107
11.6.6. Distribuirea datelor – rezultat (output) .......................................... 107
11.6.7. Utilizarea generatoarelor de rapoarte de către utilizatorii sistemului
107
11.6.8. Sistemele ce operează în timp real.................................................. 109
11.6.8.1. Pierderea mecanismelor de control convenţional ....................... 109
11.6.8.2. Controale preventive în sistemele ce operează în timp real ........ 110
11.6.8.3. Controalele detective a sistemelor ce operează în timp real....... 110
11.6.9. Sistemele de baze de date ................................................................ 111
11.6.9.1. Problemele de control specifice bazelor de date ......................... 111
11.6.9.2. Căile de compensare a punctelor slabe în control ...................... 112
11.6.10. Sisteme distribuite ........................................................................ 113
11.6.10.1. Controlul schimbului de date ...................................................... 113
11.6.10.2. Controalele privind accesul la funcţiile sistemului .................... 113
11.6.10.3. Controlul consistenţei datelor ..................................................... 114
11.7. Controalele pentru fişierele master şi datele invariabile .................. 114
11.7.1. Importanţa fişierelor master şi a datelor invariabile ..................... 115
11.7.2. Controalele fişierului master .......................................................... 115
Anexa nr.1 Exemplu de program de audit. ...................................................... 117
Anexa nr.2 Chestionar de determinare a criticismului SI. ............................. 124
Bibliografia........................................................................................................... 130

7
 Glosar şi abrevieri
TI – Tehnologii Informaţionale.

Cadrul COBIT (Control OBjectives for Information and related Tehnology ) -

un set de bune practice (cardu de referinţă) pentru managementul TI, bazate pe
domenii şi procese, prezentate într-o manieră logică şi uşor de gestionat.

ITGI (IT Governance Institute) - a fost înfiinţată în 1998, ca recunoaştere a

creşterii criticismului TI pentru succesul întreprinderii. ITGI desfăşoară activităţi de
cercetare privind practicile globale şi percepţiile de guvernare TI pentru comunitatea
de afaceri. ITGI are scopul de a ajuta liderii întreprinderii să înţeleagă cum o de
guvernanţă eficientă poate face TI de succes în sprijinirea misiunii şi obiectivelor
întreprinderii.

ISACF (Information Systems Audit and Control Foundation) – Fundaţia de

Audit şi Control a Sistemelor Informaţionale.

IFAC (International Federation of Accountants) – Federaţia Internaţională a

Contabililor.

COSO (Committee of Sponsoring Organizations of the Treadway Commission)

- este o organizaţie voluntară din sectorul privat, cu sediul în Statele Unite, dedicată
pentru a furniza orientări conducerii executive şi instituţiilor de guvernare asupra
aspectelor critice ale guvernării organizaţionale, eticii în afaceri, de control intern,
gestionarea domeniilor de risc corporativ, fraudă, şi raportare financiară. COSO a
stabilit un model comun de control intern în conformitate cu care companiile şi
organizaţiile pot evalua sistemele lor de control.

VPB (valoare pentru bani) a sistemelor IT – criteriul de performanţă a sistemelor

TI.

SI de tip ERP (enterprise resource planning system) – o aplicaţie integrată bazată

pe TI, folosită pentru a gestiona resursele interne şi externe, inclusiv activele
corporative, resurse financiare, materiale şi resurse umane.

CAAT (Computer Assisted Auditing Techniques) – tehnici de audit

asistate de calculator.

ISA – instituţie supremă de audit.

FIREWALL (paravan de protecţie ) – set de programe înrudite, instalate pe un

server de acces într-o reţea care protejează resursele reţelelor particulare de alte
reţele. Paravanele de protecţie pot fi o aplicaţie/ proxy, filtratoare de pachete.
Exemple de paravane de protecţie sunt Cisco PIX, Check Point Firewall, Juniper

8
NetScreen şi Cyberquard. (Deşi conţin anumite funcţii ale paravanelor de protecţie,
rutere nu se includ în această definiţie.).

Regulă Firewall – Informaţii adăugate în configurarea paravanului de protecţie

pentru a defini politica de securitate a organizaţiei prin enunţuri condiţionale, care
dictează paravanului de protecţie cum să reacţioneze într-o anumită situaţie.

ACL - software de audit pentru analiza, monitorizarea şi raportarea datelor.

IDEA - software de audit pentru analiza, monitorizarea şi raportarea datelor.

CAPS – software specific pentru auditul instituţiilor financiare şi cuprinde module

cum ar fi auditul restanţelor la împrumuturi, auditul dobânzilor, etc.

ITF (Integrated Test Facility) - Instrument de testare complexă. EX: Creează o

entitate fictivă într-o bază de date pentru procesarea tranzacţiilor test simultan cu
datele reale, procesate în timp real. Acesta poate fi folosit pentru încorporarea
tranzacţiilor test într-un mediu de producţie normal al sistemului.

SCARF (System Control Audit Review File) - Fişier de examinare a controlului

sistemelor în cadrul auditului. Este una din cele mai complexe tehnici de efectuare a
auditului on-line. Implică (include) modulele de audit încorporate într-un SI pentru
a oferi posibilitate monitorizării tranzacţiilor din cadrul sistemului.

EAM (Embeded Audit Modules) – module de audit încorporate amplasate în

puncte prestabilite a SI pentru a aduna informaţii despre tranzacţii sau evenimente
care auditorii le consideră materiale.

CPU (Central Processing Unit) - unitatea principală de procesare.

SLA (Service Level Agreement ) - acorduri privind nivelul serviciilor acceptabile

cu restul organizaţiei, adică departamentele de utilizatori.

ISACA (Information Systems Audit and Control Association) – Asociaţia de

Control şi Audit al Sistemelor Informaţionale.

RAM (Random Access Memory) – Memorie cu acces aleatoriu. O formă (un tip)
de memorie a computatorului.

UPS (Uninterruptible power supply) - sursă de alimentare neîntreruptibilă.

codul PIN - număr personal de identificare.

UNIX- sistemă de operare pentru computatoare.

9
Crack - un program destinat spargerii protecţiei unu soft sau sistem de operare.

ID – date de identificare.

BCP (Business Continuity Plan) – Plan de Continuitate în Afaceri.

DRP (Disaster Recovery Plan ) - Plan de Recuperare în caz de Dezastru.

Back-UP – copie de rezervă a sistemelor informaţionale sau a informaţiei.

CASE (Computer-aided software engineering ) - este aplicarea ştiinţifică a unui

set de instrumente şi metode la un sistem informaţional, care are menirea de a-l
transforma în produs de o înaltă calitate, lipsit de defecte şi uşoare de întreţinut.

Prompterul sistemului de operare – mediu de comandă, în care utilizatorul poate

scrie comenzi directe sistemului.

Outsourcing – procedură de externalizare a serviciilor.

Snapshot – imagine captată a informaţiei ce se vizualizează la ecran.

Feedback – comentarii, reacţie de răspuns.

Dummy data – date de test sau false, introduse în mediul de producţie a sistemului
pentru a verifica dacă acesta lucrează în modul stabilit.

reţea de tip LAN (Local Area Network) – reţea locala de calcul.

reţea de tip WAN (Wide Area Network) – reţea de calcul de mare extindere
geografică, de exemplu între 2 oraşe, pe o ţară, un continent sau chiar pe întreaga
lume.

Centru de asistenţă (help desk) – unitate structurală sau persoană care asigură
interacţiunea dintre utilizatori şi specialiştii TI, direcţionând solicitările reieşind din
specificul acestora. În cazul problemelor mai simple pot asigura consultanţă directă
sau pot soluţiona problemele personal.

Hardware – ansamblul componentelor şi dispozitivelor care formează un sistem

electronic de calcul.

Software – sistem de programe (aplicaţii) pentru computere şi procedurile de

aplicare a lor, furnizate odată cu computerul sau alcătuite de utilizator.

Boot – sector a dispozitivului de stocare pe care se conţine informaţia necesară

lansării sistemului de operare (de obicei este protejată).
10
RFC (Request for changes) – cerere de schimbare.

Batch processing – metodă de introducere a datelor pe loturi.

On-line processing - sistem ce operează în timp real; Metodă de introducere a

datelor în timp real, direct în sistem.

SQL (Structured Query Language) - limbaj structurat de interogare, utilizat în

mod special pentru lucrul cu bazele de date.

EUC (End User Computing) – Din perspectiva unui audit, sistemele orientate pe
utilizatori (de exemplu, foi de calcul tabelar) sunt definite ca un instrument conceput
în scopul extragerii informaţiei şi manipulare de date înainte de transfer şi / sau
generare de rezultate către o fişă electronică a sistemului de evidenţă financiară. În
plus, drept EUC pot fi privite fişierele în programele software independente, cum ar
fi Excel şi MS Access, care sunt create şi menţinute la nivel local de către utilizatorii
finali, şi nu beneficiază în mod oficial de sprijin de către personalul TI.

11
 Capitolul I. Procesul auditului IT
1. Introducere în auditul IT
Tehnologiile informaţionale sînt parte indispensabilă a vieţii contemporane.
Posibilităţile şi avantajele pe care le oferă sînt principalele premise care fac ca ele
să-şi găsească o aplicare largă în cadrul sectorului guvernamental. În limita
resurselor disponibile, autorităţile publice implementează diferite soluţii ale
tehnologiilor informaţionale pentru a-şi eficientiza procesele de lucru.
În acest context, Curtea de Conturi, ca instituţie supremă de audit a ţării este
obligată să-şi creeze şi să-şi menţină capacităţile corespunzătoare în domeniul
auditului sistemelor informaţionale. Auditul sistemelor informaţionale reprezintă o
provocare la care aceasta trebuie să facă faţă.
1.1. Definiţia auditului IT
Auditul IT poate fi descris în general ca un proces de obţinere şi evaluare a
probelor pentru a determina dacă un sistem IT protejează activele organizaţiei,
utilizează eficient resursele, menţine securitatea şi integritatea datelor şi realizează
obiectivele business-ului în mod eficace.
Unele din varietatea de tipuri de audite IT includ următoarele:
Analiza controalelor O analiză detaliată a controalelor manuale şi celor
automatizate într-un sistem IT, cu obiectivul de a
estima gradul de încredere asupra tranzacţiilor
procesate şi rapoartelor generate de sistem
Auditul sistemelor Auditul rapoartelor financiare procesate /generate de
financiare un sistem IT, în vederea exprimării unei opinii de
audit
Auditul performanţei Examinarea unui sistem IT pentru a estima dacă
sau VPB a sistemelor obiectivele preconizate pentru implementarea
IT sistemului au fost realizate în mod eficace, cu atenţia
cuvenită asupra economicităţii şi eficacităţii

12
Auditul sistemelor în Auditul sistemelor IT în proces de elaborare pentru a
proces de elaborare estima dacă:
• planificarea, design-ul şi elaborarea sistemelor
este făcută într-un mod structurat într-un mediu
controlat, şi în conformitate cu metodologia
specificată;
• controalele adecvate şi eficace sunt luate în
considerare la fiecare etapă a procesului de
elaborare a sistemului; şi
• sistemul prevede o pistă adecvată de audit
Auditul judiciar În cazuri de suspectări de fraudă, acte ilegale sau
încălcări ale politicilor şi procedurilor companiei, o
anchetă pentru a colecta probe de audit, prin
utilizarea instrumentelor / dispozitivelor
corespunzătoare pentru restabilirea datelor într-un
mod fundamentat din punct de vedere juridic din
dispozitive de calculator (inclusiv computatoare de
buzunar, telefoane mobile, etc.) utilizate de către
suspect; şi
analizarea datelor colectate pentru a determina
proporţia actelor ilegale şi culpabilitatea persoanelor
implicate
Audit al securităţii Auditele controalelor de securitate în sistemele TI
informaţionale pentru a estima gradul în care sunt menţinute
confidenţialitatea, integritatea şi disponibilitatea
datelor şi sistemelor, proporţional cu profilul riscului
sistemului IT şi organizaţiei
Tehnici de audit Utilizarea instrumentelor automatizate şi software de
asistate de calculator audit pentru:
(CAAT)
• Descărcarea datelor din sistemele TI ale
entităţii auditate;
• Analiza şi verificarea datelor entităţii auditate
pentru realizarea obiectivelor de audit
tradiţionale.

13
 1.2. Obiectivele Auditului TI
În baza evaluării riscurilor şi a controalelor aplicaţiei /sistemului selectat
pentru audit sunt stabilite obiectivele de audit. La formularea obiectivelor de audit
trebuie să se ia în considerare obiectivele managementului pentru acel sistem. În
mod normal, dacă sistemul satisface obiectivele managementului şi serveşte
intereselor afacerii în cel mai bun mod posibil devine obiectivul general al auditului.

După cum este descris în definiţia auditului TI, obiectivul general al auditului
IT cuprinde o evaluare a procesului pentru a asigura protecţia bunurilor, securităţii
datelor, eficacitatea sistemului şi eficienţa şi conformarea la reguli şi regulamente.

Deşi este esenţial de a stabili clar obiectivele auditului pentru iniţierea unui
audit detaliat, este necesar de a înţelege că pe parcursul auditului aceste obiective ar
putea suferi modificări sau formulări ulterioare.
Obiectivele auditului TI includ evaluarea şi aprecierea, proceselor care:
 (a) Asigură securitatea activelor. Se disting următoarele cinci tipuri de active:
• Date
Tipuri de date în sensul cel mai larg, de exemplu: interne şi externe; structurate şi
nestructurate; grafice; sunete; imagini; documentaţie de system; ş.a.
• Aplicaţiile
Aplicaţiile reprezintă un sumar de proceduri atît manual, cît şi programate.
• Tehnologii
Tehnologiile se referă la: echipament, sisteme de operare, sisteme de management a
bazelor de date, reţele de calcul, multimedia, etc.
• Resurse
Resursele care găzduesc şi suportă SI, consumabile, etc.
• Personalul
Competenţele personalului de conştientizare şi productivitate necesare pentru a
planifica, organiza, achiziţiona, furniza, a menţine şi monitoriza SI şi serviciile.
 (b) Asigură că următoarele 7 atribute a datelor ori informaţiei sînt menţinute:
• Eficacitate – asigură că informaţia este relevantă şi pertenentă pentru procesul de
afaceri şi poate fi livrată în timp, correct şi într-o manieră uşor de utilizat.
Deasemenea asigură că SI corespunde obiectivelor generale ale top
managementuliu şi utilizatorilot finali.
• Eficienţă – asigură, că informaţia este furnizată prin utilizarea optimă a resurselor
(cu o productivitate şi economicitate maximă). Asigură că SI utilizează resursele
optimal pentru a atinge obiectivele necesare.
• Confidenţialitatea - asigură că informaţia sensibilă este protejată de acces
neautorizat şi de divulgare.
14
 • Integritatea – asigură acurateţea şi completitudinea informaţiei astfel încît validarea
acesteea să fie efectuată în conformitate cu principiile şi aşteptările bussinesului.
• Disponibilitatea – asigură că informaţia este disponibilă la momentul solicitării de
bussines-procese şi deasemenea se referă la protejarea resurselor.
• Conformitatea – asigură corespunederea cu cadrul legal şi normativ, precum şi cu
condiţiile contractual al căror subiect este bussines procesul.
• Fiabilitatea informaţiei – asigură că managementului îi este furnizată informaţie
adecvată şi fiabilă pentru luare de decizii.
Astfel Auditul TI examinează dacă procesele TI şi resursele TI sînt combinate
pentru a atinge obiectile propuse ale organizaţiei fără a compromite eficacitatea, eficienţa
şi economicitatea activităţii acesteia, concomitant respectînd şi nomele existente. Acest
lucru poate fi descries schematic în modul următor:
Figura nr.1

Resurse TI Procese TI

Obiectivele
Organizaţiei

1.3. Misiunea Curţii de Conturi

Conform art.31 al Legii Curţii de Conturi nr.261-XVI din 05.12.2008, Curtea de
Conturi efectuează controlul asupra administrării şi întrebuinţării resurselor
financiare publice şi a patrimoniului public prin auditul regularităţii, auditul
performanţei şi alte tipuri de audit.

15
2. Etapele auditului TI
Figura nr.2: Procesul de audit
Începu

Identificarea SI/
aplicaţiile supuse

Obiectivele şi scopul Identificarea obiectivelor şi scopului auditului

documentului de
audit
Repatizarea
resurselor (auditului)

Şedinţa de deschidere

Sistemele de Etapa preliminară de audit (înţelegerea

documente SI/controale/riscuri)

Nu
Sînt controalele
fiabile?
Da
Testarea controalelor

Da Nu
Testare independentă Ne putem baza pe Testare independentă
controale în
restrînsă continuare? exstinsă

Evaluarea probelor

Şedinţa de închidere

Elaborarea raportului şi prezentarea

către management

Stop

16
Procesul auditului IT cuprinde în mod obişnuit următorii paşi:

• Planificarea
• Definirea obiectivelor
• Evaluarea controalelor
• Colectarea şi evaluarea probelor
• Raportarea şi urmărirea (monitorizarea executării implementării
recomandărilor)
2.1. Planificarea pentru auditul IT

2.1.1. Privire generală

Planificarea adecvată este un prim pas necesar în realizarea unui audit eficace al
sistemului IT. Planificarea adecvată ajută auditorul la:
• direcţionarea şi controlul lucrului său;
• identificarea domeniilor critice;
• alocarea resurselor limitate de audit către domenii mai importante;
• stabilirea perioadei de timp şi sarcinilor pentru activitatea de examinare;
• obţinerea unor probe suficiente, veridice şi relevante de audit şi
• subsecvent va ajuta entitatea auditată la luarea unor decizii .

2.1.2. Planul strategic

Acesta reprezintă o planificare pe termen lung, unde sarcinile şi obiectivele
pentru auditul sistemelor IT al entităţilor auditate sunt determinate de Curtea de
Conturi pentru o perioadă de la trei la cinci ani. Acest plan ar trebui să cuprindă
toate organizaţiile auditate şi să abordeze probleme ca:
• scopurile şi obiectivele auditului pe termen lung;
• priorităţile auditului şi criteriile pentru prioritizare;
• cum de re-orientat tehnicile şi metodele de audit pentru a satisface
cerinţele schimbătoare;
• cerinţele de personal şi infrastructură şi
• necesităţile de instruire.

17
2.1.3. Planul anual
Acesta transformă planul pe termen lung într-un program de lucru pentru anul următor.
Planificarea aici defineşte scopurile şi obiectivele fiecărui audit major ce urmează a fi
întreprins pe parcursul anului, cu resursele disponibile în cadrul Curţii de Conturi.

2.1.4. Micro-planul /Programul de audit

Acesta este un plan de activitate pentru fiecare audit aparte şi explică detaliile sarcinilor ce
urmează a fi realizate pentru fiecare audit, împreună cu planificarea timpului. Acest plan 1
ar trebui să conţină o analiză detaliată a organizaţiei auditate pentru a determina gradul de
asistenţă, dacă este, cerută de la auditorii - specialişti/consultanţi TI şi divizarea lucrului
între auditorul generalist şi auditorul TI. Aceasta cuprinde următoarele aspecte:
• Planificarea tehnică
• Planificarea logistică
• Evaluarea riscurilor
Notă: Planul anual şi micro planul nu pot fi statice sau fixe, ele necesită a fi revizuite
periodic, pentru ajustări în consonanţă cu schimbările de mediu ale entităţii.

2.2. Planificarea tehnică

Acesta este cel mai important aspect al planificării auditului – fie acesta audit de
performanţă sau audit financiar, şi implică o înţelegere aprofundată a organizaţiilor
auditate, mediul de afaceri în care activează, mecanismul de control intern al acestora şi
riscurile implicate prin utilizarea sistemelor IT.
Ca parte a acestui proces, CCRM efectuează o analiză generală a sistemelor IT ale
entităţii auditate pentru a obţine o privire de ansamblu asupra:
• entităţii auditate, naturii afacerii acesteia şi mediului de afaceri inclusiv strategia
lor IT şi politicile, structurile de management şi control (atât pentru auditele
financiare cât şi pentru auditele performanţei);
• mediului de reglementare în care funcţionează entitatea auditată
• detaliilor unităţilor operaţionale – numărul şi locaţia
• mărimii, tipului, naturii şi complexităţii sistemelor IT utilizate de entitatea auditată
(pentru auditul financiar);
• sistemelor IT majore, în ceea ce priveşte valoarea sistemelor în sine şi contribuţia
acestora la realizarea obiectivelor corporative ale entităţii auditate (pentru auditul
performanţei);
• naturii riscurilor la care sunt expuse sistemele şi gradul de vulnerabilitate a
sistemelor IT la astfel de riscuri;
• unităţi /funcţii organizaţionale critice

1
Anexa nr.1 Exemplu de program de audit

18
 • tipurilor principale şi volumelor tranzacţiilor procesate de sisteme
• mărimii şi domeniului de aplicabilitate a auditului intern;
Detaliile de mai sus pot fi colectate de ISA prin:
• efectuarea unui tur al spaţiilor principale ale organizaţiei
• citirea materialului de ordin general inclusiv publicaţiile organizaţiei, rapoartele
anuale şi rapoartele independente de audit /analitice
• examinarea planurilor strategice pe termen lung
• intervievarea personalului cheie pentru a înţelege problemele legate de afacere
• examinarea rapoartelor precedente de audit
Colectarea acestei informaţii va face posibil ca CCRM să aibă o idee clară despre tipul
sistemelor ce urmează a fi auditate, indice domeniile prioritare pentru audit şi ofere un
punct de pornire pentru audit.

2.3. Planificarea logistică

Planificarea logistică include:
• alocarea responsabilităţilor echipei care va efectua auditul IT;
• planificarea metodologiei de audit, de ex. auditul bazat pe sisteme sau verificări
directe de fond în cazul auditului financiar;
• deciderea domeniului de aplicabilitate şi gradul de acoperire a auditului
• alcătuirea bugetului (costurile de efectiv, cât şi de resurse), şi obţinerea aprobărilor
necesare pentru alocarea resurselor
• elaborarea orarului pentru diferite sarcini;
• explorarea căilor de obţinere a probelor de audit şi
• formularea cerinţelor de raportare.

2.4. Cerinţe de resurse

Auditorul IT trebuie să planifice resursele necesare pentru a finaliza sarcinile
atribuite. Resursele există în câteva forme şi toate trebuie luate în considerare.

2.4.1. Resurse de personal

Auditorul IT necesită de competenţe şi servicii ale colegilor sau altor specialişti. La
determinarea necesităţilor, auditorul IT trebuie să ţină cont de:
• nivelul de experienţă şi competenţele necesare pentru realizarea fiecărei
sarcini;
• necesarul de personal;

19
 • disponibilitatea personalului. Pentru efectuarea auditului TI este necesar de a
“rezerva” personalul din timp pentru a se asigura disponibilitatea lui; şi
• bugetele de timp. Unele ISA ar putea avea sisteme complexe de înregistrare a
timpului şi de bugetare, utilizate pentru a controla resursele de personal alocate
pentru fiecare activitate.
Auditorul trebuie de asemenea să ia în considerare ce resurse de personal ale
clientului sunt necesare şi disponibilitatea acestora.

2.4.2. Fonduri
Auditorul IT ar putea avea nevoie să facă bugetul pentru cheltuieli, în special dacă
examinarea IT include şi elementul deplasări.

2.4.3. Resurse tehnice

Auditorul IT ar putea avea nevoie de resurse tehnice pentru efectuarea examinării.
Exemplele de resurse tehnice includ:
• hardware: auditorul IT ar putea avea nevoie să utilizeze un calculator portabil
pentru realizarea CAAT;
• software: auditorul IT ar putea avea nevoie de software pentru interogări
pentru audit; şi
• manuale tehnice sau ghiduri privind sistemele clientului, de ex. un ghid de
audit privind sistemul de operare al clientului.

20
3. Studiul preliminar şi colectarea informaţiei despre entitate
Deşi planificarea este concentrată preponderent pentru etapa iniţială a auditului, ea
trebuieşte efectuată şi pe parcursul întregului audit. Acest lucru se datorează faptului că
rezultatele evaluărilor preliminare oferă baza pentru a determina durata şi tipul testărilor
ulterioare. În cazul în care auditorii obţin dovezi că procedurile specifice de control sunt
ineficiente, ei pot considera că este necesar să reevalueze concluziile lor anterioare şi a
altor decizii de planificare bazate pe acele concluzii.

3.1. Cunoaşterea entităţii

Auditor TI, urmează să acumuleze cunoştinţe şi informaţie primară în următoarele aspecte
ale entităţii care urmează să fie auditată:
• funcţiile organizaţiei şi mediul de operare,
• organigrama,
• criticismul sistemului,
• natura echipamentului şi aplicaţiilor utilizate,
• amploarea şi sfera de aplicare a auditului intern,
• natura şi amploarea riscurilor care afectează sistemele.
Sursele de informaţie ar trebui să includă:

• documentele de lucru din anii precedenţi: auditorul ar trebui să confirme că informaţia

rămâne actuală şi precisă;
• observaţii: vizitarea infrastructurii computerizate ale clientului;
• intervievarea personalului IT;
• revizuirea rapoartelor auditului intern; şi
• documentele cheie ale clientului (strategia IT, business planul, profilurile de cheltuieli).

De gradul de cunoaştere al organizaţiei şi a proceselor ei, necesare pentru auditor, vor

determina modul de organizare şi nivelul de detaliere în care se va petrece auditul şi va fi
determinat de natura organizaţiei şi nivelul de detaliu la care se află procesul de audit.
Cunoaşterea a organizaţiei urmează să includă activitatea acesteia, aspectele financiare şi
riscurile inerente cu care se confruntă organizaţia. Acesta ar trebui să includă, de asemenea,
măsura în care organizaţia se bazează pe outsourcing pentru a îndeplini obiectivele sale.
Auditorul trebuie să utilizeze aceste informaţii în identificarea problemelor potenţiale,
formularea obiectivelor şi domeniul de aplicare al activităţii. În activitatea sa auditorul
trebuie să ia în consideraţie acţiunile managementului, efectuarea cărora prezintă
îngrijorări.

3.1.1. Mediul organizaţional

Ca parte a procesului de planificare auditorii urmează să obţină înţelegere a mediului de
ansamblu al entităţii. Aceasta trebuie să includă o înţelegere generală a variatelor business
procese şi funcţiilor aferente auditului, tipurile de SI ce suportă activitatea, precum şi a
mediului operaţional. Înţelegerea organizaţiei ne ajută să decidem: ce să audităm, cu ce
frecvenţă, cînd, cum şi în ce măsură.

21
Unele aspecte esenţiale despre organizaţie, necesare de a fi înţelese sunt:
• Funcţiile de bază (ce face şi cum face), obiectivele strategice şi sarcinile,
• Principalele tipuri de tranzacţii şi volumele lor implicate pentru efectuarea business
proceselor.
• Subdiviziunile şi funcţiile cheie necesare pentru realizarea activităţii.
• Numărul şi dislocarea teritorială a unităţilor operaţionale.
• Aplicaţiile informaţionale utilizate pentru gestiunea activităţilor de bază.
• Proiectele şi programe existente sau în proces de implementare aferente SI şi
echipamentului.
• Tipurile de risc cu care se confruntă organizaţia.
• Cadrul normativ în care entitatea îşi desfăşoară activitatea.

3.1.2. Structura organizatorică

Structura organizatorică şi controalele de management sun un domeniu important de
evaluare a auditului pentru a identifica zonele şi obiectivele de audit. Controalele
organizaţionale şi de management sunt acele controale care oferă protecţie pentru mediul
organizaţional la fel precum şi pentru managementul resurselor umane şi gestiunea
activelor. Controalele organizaţionale includ următoare:
• Politicele de resurse umane de bază şi practicile manageriale,
• Segregarea obligaţiunilor între mediul de prelucrare a informaţiei şi alte medii
organizaţionale,
• Segregare responsabilităţilor în interiorul mediului de prelucrare a datelor,
• Metodele de evaluare a eficienţei şi eficacităţii operaţiunilor.
Auditorii trebuie să obţină o înţelegere a structurii organizaţionale (ierarhia) a entităţii
precum şi a subdiviziunii TI. Cunoaşterea ierarhiei organizaţionale şi delimitarea
responsabilităţilor în cadrul acestora, oferă informaţie valoroasă controalele de
supraveghere (cine şi de ce răspunde).

3.1.3. Aprecierea importanţei Sistemului 2

SI pot fi clasificate ca sisteme de importanţă critică şi sisteme de suport. Sistemele de
importanţă critică sunt acele sisteme, ale căror eşuare va avea un impact major asupra
organizaţiei. Sistemele de suport sunt acelea care sprijină managementul în luarea de
decizii şi absenţa cărora nu poate duce la un impact la fel de grav ca în cazul sistemelor de
importanţă critică. Spre exemplu: eşecul SI de control a traficului aerian sau feroviar poate
avea consecinţe foarte grave, ceea ce nu este echivalent cu eşecul unui SI de management
a documentelor. În acest caz abordarea de audit este diferită pentru fiecare sistem în parte.

2
Anexa nr.2 Chestionar de determinare a criticismului SI.

22
Prin urmare, la planificarea auditului, auditor trebuie să ia în consideraţie natura
aplicaţiilor, funcţiile acesteia şi impactul lor asupra entităţii şi societăţii.

3.1.4. Natura echipamentului şi a aplicaţiilor utilizate

Înţelegerea specificaţiilor şi parametrilor echipamentului organizaţiei în general şi în
particular pentru SI, este de o importanţă majoră pentru auditor, deoarece aceasta oferă o
înţelegere a nivelului de risc implicat. Deşi progresul tehnic merge spre echipamente de
standarde unice, diferenţele mai există şi vulnerabilităţile specifice trebuie luate în
consideraţie. Auditorul trebuie să evalueze achiziţia de echipament şi procesul de suport
ca parte a studiului preliminar.
Auditorul să determine tipurile aplicaţiilor utilizate în cadrul entităţii. Aplicaţiile pot fi
elaborate şi dezvoltate nemijlocit de organizaţie sau achiziţionate din exterior, principiile
de luare a deciziilor în acest sens urmează a fi analizate. Auditorul urmează să colecteze
detalii despre sistemele de operare, SI şi bazele de date utilizate în organizaţie. La etapa
studiului preliminar, auditorul trebuie să colecteze informaţie despre arhitectura reţelei de
calcul, tehnologiile de comunicaţii, paravane de protecţie, ş.a.

4. Evaluarea riscurilor pentru a defini scopul şi obiectivele auditului

La prioritizarea sistemelor IT ale entităţii auditate, echipa de audit trebuie să desfăşoare o
analiză preliminară a sistemelor pentru a identifica riscurile la care sunt expuse sistemele,
natura şi gradul a astfel de riscuri, vulnerabilitatea sistemelor la aceste riscuri şi măsurile
pe care le-a implementat managementul pentru a elimina /minimaliza astfel de riscuri.
Managementul riscului este responsabilitatea managementului de vârf. Acesta presupune
procesul de identificare a riscului, evaluarea riscului, şi întreprinderea unor măsuri pentru
reducerea riscului la un nivel acceptabil, analizând atât probabilitatea cât şi impactul
producerii riscului. Cele trei obiective de securitate ale oricărei organizaţii sunt
Confidenţialitatea, Integritatea şi Disponibilitatea. În audit evaluăm dacă vreunul din
aceste obiective este încălcat, şi dacă da, în ce măsură. Evaluarea riscului este o analiză
sistematică a faptului că:
• eşuarea activităţii entităţii poate să rezulte din insuficienţă de securitate, luând în
considerare consecinţele potenţiale de pierdere a confidenţialităţii, integrităţii sau
disponibilităţii informaţiei şi altor active;
• probabilitatea unor astfel de eşecuri trebuie analizată prin prisma comparaţiei
pericolelor şi vulnerabilităţilor cu controalele implementate la moment.
Este deci, necesar să înţelegem că există o justificare între costuri şi riscuri, care sunt
acceptată de către management. De exemplu, managementul ar putea să decidă în mod
conştient că păstrarea informaţiei în afară instituţiei nu este necesară pentru diminuarea
riscurilor, dacă acestea sunt acceptabile pentru companie. Cu alte cuvinte este important
de a studia perspectiva managementului şi politica formulată înainte ca auditul să ajungă
la o concluzie cu privire la riscurile acceptabile sau neacceptabile.
Din acest motiv, orice evaluare a siguranţei sistemului IT va trebui să fie bazată pe studiul
politicilor şi procesele managementului riscului adoptate de organizaţie. Este necesar un
audit detaliat şi testarea de fond, unde evaluarea riscului este înaltă şi managementul
riscului slab.

23
La etapa de planificare este necesar să se studieze procesul de management al riscului
pentru a înţelege ameninţările aşa cum sunt percepute de către management, impactul
acestora asupra sistemelor şi să se evalueze în mod independent dacă aceste ameninţări au
fost contracarate sau preîntâmpinate cu eficacitate şi în mod econom.
O analiză independentă a riscului de către auditor ajută nu doar la identificarea domeniilor
ce trebuie examinate, dar şi la determinarea obiectivelor auditului şi sprijinirea deciziilor
de audit bazate pe risc.

4.1. Paşi în analiza riscurilor

Paşii care pot fi urmaţi pentru o abordare bazată pe risc la elaborarea unui plan de audit
sunt:
• Inventarierea sistemelor informaţionale utilizate de către organizaţie şi divizarea pe
categorii a acestora.
• Determinarea sistemelor care au impact critic asupra funcţiilor sau valorilor, astfel
ca mijloace financiare, materiale, clienţi, luarea deciziilor, şi cât de aproape de
timpul real operează acestea.
• Estimarea riscurilor care afectează aceste sisteme şi nivelul impactului asupra
afacerii.
• În baza estimărilor de mai sus se va decide prioritatea, resursele, orarul şi frecvenţa
auditului.
Riscurile care afectează un sistem şi care trebuie luate în considerare la etapa estimării pot
fi diferenţiate ca riscuri inerente, riscuri de control şi riscuri de nedetectare. Aceşti factori
au impact direct asupra gradului de risc al auditului care poate fi definit ca riscul că raportul
informaţional /financiar ar putea să conţină erori materiale care ar putea trece nedepistate
pe parcursul auditului.

4.2. Riscul inerent

Riscul inerent este susceptibilitatea resurselor informaţionale sau resurselor controlate de
sistemul informaţional la furturi materiale, distrugere, divulgare, modificare neautorizată,
sau alte defecţiuni, cu condiţia că nu există controale interne asociate. De exemplu, riscul
inerent asociat cu aplicarea securităţii este de obicei înalt, deoarece modificările efectuate,
sau chiar şi dezvăluirea datelor sau programelor prin intermediul punctelor slabe ale
securităţii sistemului de aplicaţii poate rezulta în informaţie de gestionare falsă sau
dezavantaje competitive. Contrariu, riscul inerent asociat cu securitatea pentru un
calculator separat, când o analiză adecvată demonstrează că acesta nu este folosit pentru
scopuri critice ale afacerii, este, de obicei, redus.

4.3. Riscul de control

Riscul de control este riscul ca o eroare care poate să apară într-un domeniu al auditului, şi
care ar putea fi materială, separată sau în combinaţie cu alte erori, nu va fi prevenită sau
depistată şi corectată la timp de sistemul de control intern. De exemplu, riscul de control
asociat cu examinările manuale ale jurnalelor de pe calculator poate fi înalt deoarece
24
activităţile ce necesită investigaţie sunt deseori trecute cu uşurinţă cu vederea din cauza
volumului de informaţie înregistrată în jurnal. Riscul de control asociat cu procedurile de
validare a datelor computerizate este de obicei redus deoarece procesele sunt aplicate
consecvent.

Estimarea preliminară a caracterului adecvat sau altfel al controalelor ar putea fi făcut în

baza discuţiilor cu managementul, un studiu preliminar al aplicaţiei, chestionarelor şi
documentaţiei disponibile. Nivelul de conştientizare al controlului în organizaţia auditată
şi existenţa sau inexistenţa standardelor de control sunt indicatori cheie pentru evaluarea
controlului preliminar ce urmează a fi efectuat de către auditori. Evaluarea la această etapă
ajută, de asemenea, la ajustarea obiectivelor de audit, care trebuie să fie explicate înainte
de începerea testărilor de fond.

Politicile, procedurile, practicile şi structurile organizaţionale puse în aplicare pentru a

reduce riscurile sunt numite controale interne. Proporţia controalelor interne prezente va
determina gradul de risc ale aplicaţiei auditate şi de asemenea cuantumul de auditare ce
urmează a fi întreprins. Cu alte cuvinte, acolo unde controalele interne sunt dorite,
proporţia auditului creşte odată cu creşterea testărilor de fond şi invers.

Controalele IT sunt grupate ca: controale generale, controale ale aplicaţiilor şi controale
specifice. La etapa de planificare ar fi suficient ca auditorul să-şi formeze o opinie generală
privind natura şi caracterul adecvat a controalelor desfăşurate într-un sistem IT şi, de
asemenea, în domeniile unde controalele sunt slabe şi vulnerabile. Aceasta formează baza
pentru cuprinderea, domeniile şi profunzimea testărilor necesare. De asemenea este
esenţial ca paşii să fie înregistraţi în mod detaliat pentru a servi drept indicatoare.

Activităţile de control intern şi procesele de suport sunt fie manuale sau acţionate de resurse
informaţionale automatizate computerizate. Elementele controalelor care trebuie luate în
considerare la evaluarea puterii controlului sunt clasificate ca Preventive, Detective (de
depistare) şi Corective cu următoarele caracteristici.

Preventive • Depistează problemele înainte ca acestea să apară

• Monitorizează atât operaţiunile cât şi resursele
• Încearcă să prezică problemele potenţiale, înainte ca
acestea să apară şi să facă ajustări
• Prevină apariţia unei erori, omisiuni sau vreunui act
maliţios
Detective • Utilizează controale care depistează şi raportează apariţia
unei erori, omisiuni sau vreunui act maliţios

25
 Corective • Minimizează impactul unei ameninţări
• Rezolvă problemele descoperite de controalele detective
• Identifică cauza problemei
• Corectează erorile care apar din cauza vreunei probleme
• Modifică sistemele de procesare pentru a minimaliza
apariţia problemei pe viitor

În mod obişnuit, auditorul trebuie să facă o evaluare preliminară a controalelor şi să

elaboreze planul de audit în baza acestei evaluări. Pe parcursul examinării, auditorul va lua
în considerare caracterul adecvat al acestei evaluări la determinarea gradului de încredere
în aceste controale pe parcursul testărilor. De exemplu, la utilizarea programelor de
calculator pentru a testa fişierele de date, auditorul trebuie să evalueze controalele asupra
bibliotecilor de programe ce conţin programe utilizate în scopuri de audit pentru a
determina gradul de protecţie al programelor faţă de modificările neautorizate. Similar,
dacă accesul nu este controlat sau reglementat prin parole, acest lucru indică controale
slabe ale securităţii cu un risc înalt al sistemului de a fi atacat sau spart.

4.4. Identificarea domeniilor de control ale managementului riscului

În baza estimărilor riscurilor inerente şi de control, inclusiv evaluării preliminare a
controalelor bazate pe calculator, auditorul trebuie să identifice tehnicile generale de
control care par cel mai probabil a fi eficace şi care, din acest motiv, trebuie testate pentru
a determina dacă de fapt funcţionează eficace. Bazându-se pe aceste estimări preliminare
pentru a planifica testele de audit, auditorul poate evita folosirea resurselor pentru testarea
controalelor care, în mod clar, nu sunt eficace.

4.5. Domeniul de aplicare şi scopul auditului intern

Auditorii TI interni şi auditul TI extern au roluri complimentare de activitate. Cînd există
o suprapunere a domeniilor de aplicare, abordarea auditului extern trebuie revăzută.
Auditul TI extern trebuie să evalueze capacitatea, scopul şi eficienţa funcţiei de audit intern
TI pentru a decide ce verificări urmează să fie efectuate pentru a evita duplicarea.
Punctele slabe ale auditului TI intern ne indică nivelul sporit de risc în controlul intern şi
duce în mod obligatoriu la extinderea ariei de audit extern. Domeniile de risc de bază cu
care auditorul extern se poate confrunta pe parcursul evaluării auditului TI intern:
• auditul intern nu raportează conducerii de vîrf,
• managementul nu cere conformarea cu recomandările auditului intern,
• auditorul intern nu are toate împuternicirile necesare pentru efectuarea unei game
complete de evaluări,sau pot exista restricţii semnificative privind domeniul de
aplicare a activităţii sale,
• insuficienţa de resurse (financiare, de personal, competenţe necesare),
26
 • neimplicarea auditului intern în proiectele TI în curs de dezvoltare.

4.6. Riscul de nedetectare

Riscul de nedetectare este riscul ca procedurile de fond ale auditorului IT să nu depisteze
o eroare care ar putea fi materială, separată sau în combinaţie cu alte erori. De exemplu,
depistarea riscurilor asociate cu identificarea penetrării securităţii într-un sistem de
informaţional este, de obicei, înalt deoarece jurnalele (logurile) pentru întreaga perioadă de
audit nu sunt disponibile la etapa de efectuare a auditului. Riscul de nedetectare asociat cu
identificarea lipsei planurilor de recuperare în caz de dezastru este de obicei redus deoarece
existenţa acestuia se poate verifica cu uşurinţă.

La determinarea nivelului testărilor de fond necesare, auditorul IT trebuie să ia în

considerare:

• Estimarea riscului inerent

• Concluzia la care s-a ajuns privind riscul de control în urma testărilor de

conformitate

Cu cât mai înaltă este estimarea riscului inerent şi de control cu atât mai multe probe de
audit urmează să obţină auditorul IT din efectuarea procedurilor de fond în cadrul auditului.

4.7. Obiectivele şi domeniul de aplicabilitate a auditului

În baza evaluării riscurilor şi a controalelor aplicaţiei /sistemului selectat pentru audit sunt
stabilite obiectivele de audit. La formularea obiectivelor de audit trebuie să se ia în
considerare obiectivele managementului pentru acel sistem. În mod normal, dacă sistemul
corespunde obiectivelor managementului şi serveşte intereselor afacerii, devine obiectivul
general al auditului.
Deşi este esenţial de a stabili clar obiectivele auditului pentru iniţierea unui audit detaliat,
este necesar de a înţelege că pe parcursul auditului aceste obiective ar putea suferi
modificări sau formulări ulterioare.
După cum este descris în definiţia auditului IT, obiectivul general al auditului IT cuprinde
o evaluare a procesului pentru a asigura protecţia bunurilor, securităţii datelor, eficacitatea
sistemului şi eficienţa şi conformarea la reguli şi regulamente. Obiectivele auditului IT
merg mână în mână cu orice obiective de audit al performanţei, financiar sau de
regularitate, pe care auditorul le-ar putea întreprinde.
Următoarea listă ilustrează unele din obiectivele obişnuite de audit pentru un audit IT.
• Evaluarea controalelor efectuate asupra sistemelor IT pentru a obţine asigurare cu
privire la corespunderea şi eficacitatea acestora;
• Evaluarea proceselor principale utilizate în operaţiunile unui domeniu dat (de
exemplu, procesele principale într-un sistem de facturare vor fi calcularea valorii facturii,
generarea facturii, colectarea taxelor, evidenţa plăţilor întârziate/ ne-plăţilor, etc.) sau un
sistem (de ex., sistem de salarizare, sistem de contabilitate financiară, etc.);
• Evaluarea performanţei unui sistem;

27
• Examinarea securităţii sistemelor IT;
• Examinarea procesului de elaborare a sistemului şi a procedurilor urmate la diferite
etape ale acestuia.
Obiectivele de audit şi domeniul de aplicabilitate ar putea cuprinde mai mult decât doar un
singur aspect al domeniilor menţionate mai sus. De exemplu, examinarea securităţii
sistemului ar putea cuprinde doar unul din următoarele aspecte sau o combinaţie a
acestora:
• Securitatea paravanului de protecţie (Firewall-ului )
• Securitatea accesului fizic
• Parolele
• Securitatea setărilor
• Politicile conturilor de utilizatori
• Drepturile utilizatorului, etc.
Domeniul de aplicabilitate defineşte limitele auditului. Determinarea domeniului de
aplicabilitate al auditului reprezintă o parte a planificării auditului. Aceasta abordează
astfel de aspecte ca perioada şi numărul de locaţii ce vor fi cuprinse şi volumul de testări
de fond în dependenţă de nivelurile de risc şi punctele slabe ale controlului. Nu mai este
nevoie de spus că domeniul de aplicabilitate al auditului va suferi schimbări în procesul de
desfăşurare al auditului.

5. Şedinţa de deschidere
Este necesară o şedinţă formală de începere a auditului, organizată cu managementul
superior responsabil pentru domeniului ce urmează a fi auditat, pentru a finaliza domeniul
de aplicare, înţelege îngrijorările speciale, dacă sunt, planifica datele şi explica
metodologia pentru audit. Această şedinţă ajută la ajustarea obiectivelor în baza
percepţiilor manageriale despre sistemul IT. Astfel de şedinţe implică managementul
superior, permit persoanelor să se întâlnească, să clarifice problemele şi îngrijorările de
bază ale companiei, şi ajută ca auditul să fie desfăşurat fără probleme în afară de prevenirea
entităţii despre datele, informaţia şi documentele care vor fi solicitate de echipa de audit.
Pe parcursul conferinţei de deschidere, reprezentanţii entităţii auditate pot fi informaţi
despre obiectivele generale ale auditului, planul de audit preliminar propus, domeniile
posibile de interes în baza constatărilor de audit anterioare sau constatărilor de audit în
domenii de afaceri similare. Aceştia sunt provocaţi să-şi împărtăşească îngrijorările cu
privire la sistemul IT, care sunt luate în considerare de auditori.

6. Colectarea şi evaluarea probelor

Conform standardelor de Audit TI ale CCRM (p.13 cap.III):

28
„Pentru a susţine deciziile şi concluziile auditorilor, privind organizarea, programul,
activităţile şi funcţiile din cadrul auditului trebuie obţinute probe competente pertinente şi
relevante”
Standardele stabilesc că:
a) Selectarea şi eşantionarea datelor trebuie efectuate cu atenţie,
b) Auditorii trebuie să aibă o înţelegere clară a tehnicilor şi procedurilor precum:
inspectarea, observaţiile, investigaţiile şi confirmaţiile pentru colectarea probelor de
audit,
c) Probele trebuie să fie competente, relevante, rezonabile şi concrete.

6.1. Tipuri de probe de audit

La planificarea lucrului ce ţine de auditul IT, auditorul ar trebui să ţină cont de tipul
probelor de audit ce vor fi colectate, utilizarea acestora ca probe de audit pentru a răspunde
la obiectivele de audit şi nivelele variate de încredere. Printre lucrurile ce trebuie luate în
calcul se numără independenţa şi calificarea furnizorului de probe de audit. De exemplu,
probele de audit coroborate, obţinute de la o parte terţă independentă pot uneori fi mai de
încredere decât probele de audit de la organizaţia auditată. Probele fizice de audit sunt în
general mai de încredere decât descrierile unui individ.

Tipurile probelor de audit, pe care auditorul trebuie să le ia în considerare pentru a le utiliza,

includ:

• Procesul observat şi existenţa elementelor fizice,

• Probele documentare de audit (inclusiv înregistrările electronice),
• Analiza (inclusiv analiza făcută posibilă de IT prin utilizarea CAAT).

6.1.1. Probele fizice

Probele fizice sunt obţinute prin observaţii. Este de dorit ca probele fizice să fie
coroborate/confirmate, în special dacă acestea sunt cruciale pentru careva din constatările
auditului. Una din cele mai dezirabile coroborări ale probelor fizice este acceptarea a astfel
de probe de către entitate.

Verificarea fizică este inspecţia sau numărarea de către auditor a valorilor materiale.
Auditorul poate inspecta fizic prezenţa calculatoarelor, terminalelor, imprimantelor, etc.
Camera de servere (data centrul) va trebui vizitat pentru verificarea vizuală a prezenţei
detectoarelor de apă şi de fum, stingătoarelor de incendiu, etc. De asemenea, amplasarea
dispozitivelor trebuie marcată clar şi să fie vizibilă. Controalele accesului fizic sunt
destinate pentru a proteja organizaţia de accesul neautorizat.

În IT, unde se acordă o importanţă considerabilă mediului fizic al sistemelor, auditul de

asemenea trebuie să asigure faptul că mediul corespunde unor norme acceptabile.
Aspectele verificate pot varia de la amplasarea stingătoarelor de incendiu la controalele
accesului fizic la un inventar al suporturilor într-un spaţiu de depozitare din afara firmei.
În astfel de cazuri observarea şi coroborarea probelor observate este importantă.
29
 6.1.2. Interviul
Auditorii pot utiliza interviurile pentru a obţine atât informaţie calitativă cât şi cantitativă
pe parcursul activităţii de colectare a probelor. Utilizarea interviurilor de către auditori
include următoarele:

• Analiştii de sistem şi programatorii pot fi intervievaţi pentru a obţine o înţelegere

mai bună a funcţiilor şi controalelor înglobate în sistem.

• Angajaţii/personalul responsabil de introducerea datelor poate fi intervievat pentru

a determina cum corectează aceştia datele introduse pe care sistemul de aplicaţii le
identifică ca fiind imprecise sau incomplete.

• Utilizatorii unui sistem de aplicaţii pot fi intervievaţi pentru a determina percepţiile

acestora privind cum a afectat sistemul calitatea condiţiilor de muncă.

• Personalul operativ poate fi intervievat pentru a determina dacă vreun sistem de

aplicaţii pare să consume volume anormale de resurse atunci când sunt executate.

Desfăşurarea cu succes a interviurilor necesită o pregătire atentă. Este necesar de a se:

• Asigura că informaţia solicitată nu este disponibilă de-a gata în altă parte. De

asemenea ar putea fi găsite surse alternative pentru informaţia solicitată.

• Identifica acel personal din cadrul unei organizaţii care poate furniza cea mai bună
informaţie pentru un subiect al interviului. Structurile organizaţionale deseori
reprezintă o primă sursă de informare privind respondenţii adecvaţi pentru
intervievare.

• Identifica clar obiectivele interviului şi elabora o listă cu informaţia care se

urmăreşte a fi obţinută pe parcursul interviului. Informaţia generală va trebui
solicitată la începutul şi finalul interviurilor. Informaţia specifică se va solicita spre
jumătatea interviurilor. Informaţia solicitată la începutul interviurilor nu va avea
nici un caracter controversat, dar nici sensibil.

• Respondenţii pot fi contactaţi pentru a programa timpul şi locul interviurilor cu ei.

• Cât de repede posibil după finalizarea interviurilor, auditorii trebuie să întocmească

un raport. Pe parcursul elaborării rapoartelor cu privire la interviuri, auditorii ar
trebui să aibă două obiective majore. Primul, să încerce să separe faptele de opinii.
Al doilea, auditorii trebuie să încerce să asimileze informaţia pe care ei o obţin pe
parcursul unui interviu şi să determine ce înseamnă aceasta pentru obiectivele lor
generale de audit.

6.1.3. Chestionarele
Chestionarele au fost folosite în mod tradiţional pentru evaluarea controalelor din cadrul
sistemelor. Auditorii pot de asemenea folosi chestionare pentru a evidenţia părţile slabe ale

30
unui sistem pe parcursul colectării probelor. De exemplu, auditorii pot utiliza chestionare
pentru a estima opinia generală a utilizatorilor despre un sistem informaţional ca indicator
al eficacităţii sistemului. Similar, chestionarele pot fi folosite pentru a identifica domeniile
cu un sistem informaţional unde există potenţiale ineficienţe. Întrebările trebuie să fie
formulate clar, termenii trebuie definiţi şi instrucţiunile pentru completarea chestionarelor
trebuie să fie clare. Unele recomandări generale cu privire la chestionare, de care trebuie
de ţinut cont sunt de a:

• Asigura că întrebările sunt specifice,

• Utiliza limbaj corespunzător cu înţelegerea persoanei preconizate a fi intervievate.

De exemplu, întrebările adresate administratorului de sistem sau administratorului
bazei de date trebuie să fie specifice şi ar putea include cuvinte care sună ca jargoane
IT, însă care să exprime exact observaţia, utilizarea acestora poate fi inevitabilă.

• Următoarele trebuie să fie evitate, decât în cazul în care sunt necesare:

 întrebările ambigue

 întrebările care sugerează răspunsuri prestabilite

 întrebările prezumtive

 întrebările ipotetice

 întrebările jenante

6.1.4. Diagramele de flux

Diagramele de flux cu privire la control arată că controalele există într-un sistem şi unde
aceste controale există în sistem. Acestea au trei scopuri majore ale auditului:

• Comprehensiune – elaborarea unei diagrame de flux a controlului subliniază acele

domenii unde auditorilor le lipseşte înţelegerea fie a sistemului în sine sau fie a
controalelor în sistem;

• Evaluare – auditorii experimentaţi pot utiliza diagrame de flux ale controlului pentru
a recunoaşte modelele care manifestă fie puncte forte ale controlului fie puncte slabe
ale controlului într-un sistem;

• Comunicarea – auditorii pot utiliza diagrame de flux ale controlului pentru a

comunica altora percepţia despre un sistem şi controalele asociate ale acestuia.

Elaborarea unei diagrame de flux a controlului cuprinde patru paşi:

• Selectarea tehnicii primare pentru diagramă care permite ca anumite caracteristici

ale unui sistem să fie subliniate şi înţelese mai bine;

31
 • Selectarea nivelului adecvat de detaliu la care auditorii să lucreze în aşa fel ca să nu
fie supraîncărcaţi cu conţinutul, dar cu toate acestea să nu piardă punctele forte sau
punctele slabe importante ale controlului;

• Elaborarea diagramei primare astfel ca caracteristicile sistemului să poată fi înţelese

cu uşurinţă;

• Elaborarea diagramei controlului în baza diagramei primare astfel ca punctele forte

sau punctele slabe ale controlului să fie evidente.

6.1.5. Procedurile analitice

Procedurile analitice folosesc comparaţii şi relaţii pentru a determina dacă datele şi
soldurile conturilor par rezonabile. Drept exemplu putem analiza indicatorii economici din
anul precedent cu cei din acest an. Procedurile analitice urmează a fi efectuate la începutul
auditului, pentru a ne ajuta în luarea deciziilor privind domeniile care necesită o atenţie
sporită şi care nu. CAAT pot ajuta la pregătirea cifrelor pentru o evaluare analitică. În
special, CAAT pot genera analize, care altfel nu vor fi disponibile.

6.2. Instrumente de colectare a probelor

Cu necesitatea sporită pentru certificarea sistemelor, este de asemenea o creştere în ceea ce
priveşte disponibilitatea instrumentelor pe care le pot utiliza auditorii IT. Diferite feluri de
instrumente sunt discutate în paragrafele ce urmează.

6.2.1. Software generalizat de audit

Acesta este un software de-a gata ce oferă procedeul de a obţine acces la şi a manipula
datele ţinute pe medii de stocare pe calculator computer. ACL şi IDEA sunt utilizate de
obicei ca exemple de software generalizat de audit. Software-ul generalizat de audit a fost
elaborat în mod specific pentru a corespunde unei mari varietăţi de diferite platforme
hardware şi software. Acestea oferă un număr de funcţii cum ar fi acces la fişier, re-
organizarea fişierului, selectarea şi extragerea datelor, diferite funcţii de analiză a datelor
şi funcţii de raportare. Acestea sunt utilizate pentru a (a) examina existenţa, precizia,
deplinătatea, consecvenţa şi caracterul oportun al datelor (b) calitatea proceselor cuprinse
într-un sistem de aplicaţii (c) evaluarea analitică pentru a monitoriza indicatorii de audit
cheie, cum ar fi analiza tendinţelor.

Software-ul generalizat de audit este discutat mai detaliat în modulul privind CAAT.

Există nişte limite privind utilizarea Software-ului generalizat de audit cum ar fi capacitatea
limitată pentru verificarea logicii de procesare şi o abilitate limitată de a determina
predispunerea la erori.

6.2.2. Software-ul de audit specific unei ramuri

Software-ul de audit specific unei ramuri este destinat să ofere comenzi de nivel înalt care
invocă funcţii de audit obişnuite, necesare în cadrul unei anumite ramuri. Pentru a fi mai
specifice, acestea oferă o logică caracteristică ramurii date. De exemplu, analiza financiară
32
sau rapoartele ajustate la industria bancară. Un alt exemplu este CAPS care este specific
pentru auditul instituţiilor financiare şi cuprinde module cum ar fi auditul restanţelor la
împrumuturi, auditul dobânzilor, etc.

6.2.3. Software-ul specializat de audit

Acesta este un software elaborat pentru a îndeplini un set specific de sarcini de audit.
Majoritatea sistemelor bine elaborate includ un modul de audit, care cuprind în mod
esenţial rutine ce emit alerte şi informaţie pentru a asigura o dependenţă continuă de
controale. Caracterul adecvat al modulului de audit, datele generate de modul, cât şi
urmărirea de către management a rezultatelor auditului intern sunt în sine supuse cercetării
atente a auditului extern. dacă modulul de audit nu este operaţional sau a fost dezactivat
sau nu este revizuit periodic aceasta reprezintă un risc eminent pentru posibilitatea de
penetrare a sistemului.

6.2.4. Instrumente de auditare concomitentă

După cum stau lucrurile în procesul manual de audit, auditarea concomitentă nu se
efectuează de auditorii de stat externi. Însă cu computerizarea crescândă este obligatoriu
să fie o dependenţă sporită de tehnicile de auditare concomitentă, pentru a colecta probele
de audit în acelaşi timp cât un sistem de aplicaţii efectuează procesarea datelor acestuia.
Acestea ar putea fi sub formă de module speciale de audit încorporate în sistemul de
aplicaţii pentru a colecta procese şi imprima probe de audit. Majoritatea software de sistem
vin cu module de audit incorporate, care ajută la supravegherea eficace din partea
managementului.

Există diferite tipuri de tehnici de auditare concomitentă, majoritatea cărora se împart în

trei categorii - (a) acelea care pot fi utilizate pentru a evalua sistemele de aplicaţii care
testează datele în timp ce acestea efectuează procesarea, (b) acelea care pot fi utilizate
pentru a selecta tranzacţiile pentru examinare în cadrul auditului în timp ce sistemele de
aplicaţii efectuează procesarea, şi (c) acelea care pot fi utilizate pentru a trasa sau a mapa
stările schimbătoare ale aplicaţiei în timp ce acestea efectuează procesarea. Câteva din
aceste tehnici sunt:

• Instrument de testare complexă (Integrated Test Facility (ITF)),

• Fişier de examinare a controlului sistemelor în cadrul auditului şi module de audit

încorporate (SCARF/EAM),

• Snapshot-uri (tehnici extinse de audit),

• Capcane de audit,

• Simulare continuă şi intermitentă.

33
 6.3. Teste de audit
Auditorii utilizează de obicei două tipuri de teste – teste de ‘conformitate’ şi teste ‘de
fond’.

Testele de conformitate sunt legate de testarea tranzacţiilor pentru conformitatea cu

regulile şi regulamentele entităţii şi oferă auditorilor probe despre prezenţa/absenţa
controalelor interne. Testele de conformitate pot fi utilizate pentru a testa existenţa şi
eficacitatea unui proces definit, care ar putea include o pistă a probelor documentare sau
automatizate.

Câteva exemple de teste de conformitate după cum sunt relaţionate cu mediul IT includ:

• Determinarea faptului dacă parolele sunt periodic schimbate;

• Determinarea faptului dacă jurnalele sistemului sunt revizuite;

• Determinarea faptului dacă schimbările în program sunt autorizate;

• Determinarea faptului dacă controalele funcţionează după cum a fost prevăzut;

• Determinarea faptului a fost testat vreun plan de reabilitare în caz de dezastru.

Testele de fond oferă auditorilor probe privind validitatea şi proprietatea tranzacţiilor şi

bilanţurilor. Auditorii utilizează teste de fond pentru a identifica erorile monetare care
afectează direct bilanţurile rapoartelor financiare.

Câteva exemple de teste de fond după cum sunt relaţionate cu mediul IT includ:

• Efectuarea analizei privind disponibilitatea sistemului;

• Efectuarea analizei privind mediul de stocare al sistemului;

• Efectuarea analizei privind întreruperea sistemului;

• Compararea inventarului din calculator conform cărţii vis-a-vis de contul actual;

• Reconcilierea soldurilor conturilor.

Testele de conformitate determină măsura în care vor fi desfăşurate testele de fond.

Controalele puternice relevate în testele de conformitate pot limita testele de fond şi
viceversa.

6.4. Eşantionarea
Eficienţa auditului se bazează pe obţinerea minimului de probe de audit, suficiente pentru
a forma opinia de audit. Utilizarea eşantionării de audit, în misiunile de audit, oferă
auditorilor beneficii nenumărate. Acestea includ:

• oferirea unui cadru din care se obţin suficiente probe de audit,

34
 • clarificării abordării de audit pentru a determina modul în care vor fi realizate
obiectivele de audit,

• minimalizarea riscului de supra-auditare (corelarea efortului cu rezultul),

• facilitarea unei examinări mai rapide a documentelor de lucru,

• sporirea nivelului acceptării concluziilor de audit de către entitate, prin evidenţierea

naturii imparţiale a lor.

Eşantionarea pentru audit este testarea elementelor selectate din cadrul unui masiv pentru
a obţine şi evalua probele despre unele caracteristici ale acestui masiv, în scopul de a forma
o concluzie cu privire la tot masivul.

Este important ca elementele selectate să fie reprezentative, în scopul de a putea forma o

concluzie privind întregul masiv. De exemplu, proiectarea rezultatelor testelor aplicate
doar asupra acelor elemente care au o caracteristică specifică, cum ar fi doar elementele cu
valoare înaltă, asupra întregului masiv va da rezultate denaturate.

Sunt două metode primare de eşantionare utilizate de auditorii IT. Acestea sunt
Eşantionarea Atributivă şi Eşantionarea Variabilă. Eşantionarea atributivă este în
general utilizată în situaţiile de testare de conformitate şi vizează prezenţa sau absenţa
atributelor şi oferă concluzii exprimate în rate de incidenţă. Eşantionarea variabilă este în
general aplicată în situaţiile de testare de fond şi se axează pe caracteristicile masivelor de
date, care variază şi oferă concluzii legate de devierile de la normă.

Eşantionarea poate fi utilizată în diferite situaţii de auditare. Există diferite căi în care poate
fi selectată o eşantionare statistică. Cel mai frecvent utilizate metode sunt selectarea
aleatorie unde fiecare element din masivul de date are şansă egală de a fi selectat.
Eşantionarea aleatorie simplă asigură faptul că fiece număr din masiv are o şansă egală de
a fi selectat. Este utilă pentru testarea controalelor interne. De exemplu, auditorul poate
decide dacă sunt erori peste o anumită limită atunci sistemele de control sunt ineficiente.
Eşantionul poate selecta folosind numere aleatorii prin intermediul calculatoarelor.
Software de audit, cum este IDEA poate fi folosit pentru selectarea eşantionului. Odată ce
eşantionul este selectat, testele de audit identificate se vor aplica asupra eşantionului.

6.5. Evaluarea probelor

Auditorul utilizează informaţiile colectate pentru a realiza o evaluare obiectivă a
performanţei reale pe baza criteriilor de audit. Atunci când performanţa nu îndeplineşte
aceste criterii, sunt necesare investigaţii suplimentare pentru a obţine asigurarea că orice
constatări sau concluzii de audit rezultate sunt semnificative, corecte şi bine fondate.

Procesul de evaluare implică cântărirea şi combinarea element cu element a probelor

colectate pentru a formula o decizie generală. La formularea deciziei generale, auditorul
trebuie să determine dacă consideră că există controale şi dacă acestea operează cu

35
siguranţă pentru a asigura că sistemul protejează bunurile şi integritatea datelor, realizează
eficace obiectivele organizaţionale şi consumă resursele în mod eficient.

Un auditor cu competenţele şi cunoştinţele sale profesionale determină care ar trebui să fie

statutul unei condiţii existente în conformitate cu normele acceptate. Acesta examinează
condiţia aşa cum există în mediul real şi dacă există o diferenţă semnificativă, o notează ca
pe o constatare. Constatările trebuie să aibă următoarele caracteristici:

• Să fie bazate pe fapte şi descoperite de auditor;

• Să se bazeze pe standarde sau recomandări în comparaţie cu care condiţiile sunt

evaluate;

• Efectul, impactul şi semnificaţia divergenţelor trebuie raportată.

La elaborarea constatărilor, auditorul are nevoie de a compara condiţia cu o valoare de

referinţă. Suplimentar, pentru ca constatările să aibă un impact, auditor trebuie să cuantifice
semnificaţia divergenţelor în termeni de valoare.

Constatările auditului au fost deseori considerate ca conţinând elemente ale criteriilor,

condiţiilor şi efectului cât şi a cauzei atunci când sunt identificate problemele. Însă,
elementele necesare pentru o constatare depind totalmente de obiectivele auditului.
Aceasta înseamnă că elementele ‘cauză’ şi ‘efect’ pot fi opţionale pentru un audit de
conformitate dar sunt obligatorii pentru un audit operaţional. Astfel, o constatare sau un
set de constatări este complet în măsura în care obiectivele auditului sunt îndeplinite şi
raportul relaţionează clar acele obiective cu elementele constatării. O constatare de
deficienţă trebuie să aibă cinci elemente sau atribute după cum sunt prezentate mai jos.

• Criterii (ce ar trebui să fie);

• Condiţie (ce este);

• Cauză (de ce a apărut condiţia);

• Efect (care este consecinţa);

• Recomandare (ce trebuie de făcut).

36
7. Şedinţa de închidere
După ce cercetarea de audit a fost finalizată, constatările de audit şi sugestiile pentru acţiuni
de corectare pentru managementul superior pot fi comunicate într-o şedinţă formală.
Aceasta va asigura o înţelegere mai bună şi spori susţinerea recomandărilor de audit.
Aceasta de asemenea oferă organizaţiei auditate o oportunitate de a-şi exprima punctele de
vedere privind problemele puse în discuţie. Scrierea raportului după o astfel de şedinţă,
unde se ajunge la o înţelegere cu privire la toate problemele de audit poate spori puternic
eficacitatea auditului. Conferinţa finală de asemenea ajută la finalizarea recomandărilor
practice şi fezabile.

8. Documentarea procesului de audit şi raportarea

Auditorii urmează să documenteze în mod adecvat probele de audit în documentele de
lucru, inclusiv nivelul de planificare, lucrările efectuate şi concluziile auditului.
Documentele de lucru ar trebui să conţină informaţii suficiente pentru a permite unui
auditor experimentat care nu a fost implicat în auditul respectiv să accepte constatările
auditorului şi concluziile.

8.1. Importanţa documentării

Documentarea de audit a SI reprezintă înregistrarea activităţilor de audit efectuate şi a
probelor de audit ce justifică constatările şi concluziile de audit. Documentaţia de audit
poate fi utilizată pentru:

• Demonstrarea nivelului de corespundere cu standardele de audit;

• Asistenţa la planificare, revizuirea auditelor şi evaluarea performanţei acestora;

• Facilitarea utilizării materialelor de către persoane terţe (inclusiv la evaluarea

calităţii);

• Suport în cazurile depistării de fraude, pentru procesul de judecată.

8.2. Forma, conţinutul şi domeniul de aplicare a documentaţiei de audit

Auditorul trebuie să pregătească documentaţia de audit, în aşa mod care să permită altui
auditor cu experienţă să înţeleagă:

• natura, durata, domeniul de aplicare şi rezultatele procedurilor de audit efectuate,

• probele de audit obţinute,

• concluziile obţinute asupra aspectelor semnificative,

• procedurile de audit necesare pentru identificarea riscurilor de denaturări

semnificative.

Documentaţia trebuie să includă date despre:

37
 • planificarea, domeniul de aplicare şi obiectivele auditului,

• programul de audit,

• probele colectate care au adus la anumite concluzii,

• toate documentele de lucru, inclusiv fişier generale referitoare la entitate şi SI,

• punctele discutate în interviuri care atestă în mod clar subiectul discuţiei, persoana
intervievată, poziţia şi funcţia, ora şi locul,

• înregistrări asupra observaţiilor directe. Înregistrările trebuie să includă date despre

locul, timpul, motivul, efectuării observaţiilor şi persoanele implicate

• rapoartele şi datele obţinute de către auditor direct din SI sau primite de la personalul
entităţii. Auditorul trebuie să se asigure că rapoartele respective indică sursa, data,
timpul şi scopul obţinerii lor.

• la diferite etape, auditorul poate adăuga comentarii şi precizări cu privire la

preocupările sale şi necesităţile de informaţii suplimentare.

• în cazul în care activitatea de audit este revizuită de către un coleg sau un superior,
comentariile care reiese din revizuirea respectivă, de asemenea, ar trebui să fie
înregistrate în documentaţia de audit.

Proiectul şi rapoartele finale ale auditului ar trebui să facă parte din documentaţia de audit.

Identificarea persoanelor care au pregătit sau revizuit documentaţia:

• cine şi când a efectuat procedurile de audit,

• cine şi când a revizuit documentaţia de audit.

8.3. Feedback-ul (comentariile) managementului entităţii auditate

În cazul auditului TI este extrem de important, de a obţine comentarii la constatările de
audit. Chiar dacă e dificil de a obţine comentarii formalizate, este necesar de a petrece o
şedinţă cu managementul superior a entităţii pentru a le releva despre principalele
constatări de audit. Dacă aceste eforturi nu au succes, acest fapt trebuie documentat şi
anexat la dosar.

8.4. Raportarea
Formatul rapoartelor de audit TI este similar cu formatul rapoartelor altor tipuri de audit.

Cu toate acestea, de cîte ori este utilizat cadrul CoBIT nu numai pentru îndrumare, dar şi
ca cadru de referinţă, raportarea trebuie să fie bazată pe structura cadrului respectiv. În
acelaşi timp, urmează a ţine cont de posibilul cititor. Cu toate aceste, conţinutul raportului
trebuie să fie orientat spre posibilului cititor.

38
Efectuarea auditului TI, trebuie să se bazeze pe examinarea unui SI. Un astfel de sistem
poate rula într-o singură unitate structurală a entităţii, sau într-un număr mare de unităţi, în
care să fie utilizate diferite funcţionalităţi ale acestuia. De exemplu un SI financiar din
cadrul Trezoreriei, poate fi utilizat în mai multe unităţi teritoriale şi chiar alte instituţii. Pe
de altă parte un sistem de facturare poate fi utilizat doar într-o ramură de activitate a unei
entităţi. În cazul utilizării SI în mai multe unităţi ale instituţiei, examinările de audit trebuie
repartizată în aş mod încât concluziile să devină reprezentative.

8.5. Structura raportului Auditului TI

Raportul trebuie să fie complet, exact, obiectiv, convingător şi atât de clar şi concis pe cât
permite subiectul. Raportul trebuie să includă toate constatările de audit semnificative.
Atunci când o constatare necesită explicaţii, auditorul trebuie să descrie constatarea, cauza
şi riscul acesteia. !!!! Când este cazul, auditorul trebuie să ofere explicaţii într-o
referinţă separată şi să facă trimitere la aceasta în raport. Această abordare poate fi
adecvată pentru problemele de înaltă confidenţialitate. Auditul IT nu este eficace dacă
sunt realizate procedurile de audit şi emise rapoartele, dar nu se efectuează nici o urmărire
pentru a stabili dacă organizaţia auditată a întreprins măsuri corective corespunzătoare.
Auditorul trebuie să aibă un program de urmărire pentru a determina dacă măsurile
corective stabilite în comun acord au fost implementate. Nivelul de examinare al urmăririi
din partea auditorului va depinde de câţiva factori. În unele cazuri, auditorul poate doar să
trebuiască să se informeze despre situaţia actuală. În alte cazuri, auditorul ar putea să
efectueze anumiţi paşi de audit pentru a determina dacă măsurile corective stabilite şi
acceptate de către organizaţia auditată au fost implementate.

Un audit IT tipic ar avea următoarea structură:

• Introducere

• Obiectivele auditului, domeniul de aplicabilitate şi metodologia

• Constatările auditului

• Concluziile auditului

• Recomandările

De menţionat, că realizările managementului entităţii identificate pe parcursul

auditului, care se referă la domeniul de aplicare al auditului, pot fi incluse în
raportul de audit, împreună cu deficienţele depistate. Astfel de informaţii oferă o
prezentare mai obiectivă a situaţiei. În plus, includerea unor astfel de realizări
poate duce la îmbunătăţirea performanţelor de către alte organizaţii
guvernamentale care citesc raportul.

39
 8.6. Limitările întâlnite pe parcursul efectuării auditului
În raportul de audit urmează a fi menţionat despre limitările care au fost întâmpinate de
audit. De exemplu, în cazul în care datele nu au fost utilizate din mediul de producţie. În
mod similar, dacă auditul nu a putut utiliza date de test (dummy data) pentru a evalua
controalele de intrare complet.

Accesul „Read Only” (doar de citire) nu este o limitare.

Raportul nu trebuie să conţină date, care ar putea ajuta persoanelor terţe să

pătrundă în sistem sau să aducă careva daune acestuia. Astfel de informaţie
precum numele şi structura tabelelor, locaţia şi calea către componentele SI, pot
fi tratate doar ca probe de audit, dar în raport trebuie menţionate foarte atent.
Acest lucru este valabil mai ales în cazul SI de tip ERP de reţea sau bazate pe
tehnologii WEB.

40
 Capitolul II. Metodologia de Audit
9. Controalele TI
Capacităţile sistemelor informaţionale au avansat rapid în ultimele decenii.
În multe organizaţii, majoritatea proceselor au fost computerizate şi toate
informaţiile sunt disponibile doar în mediul digital. În această situaţie, auditorii
urmează să adapteze metodologia lor la circumstanţele schimbate. Chiar dacă
obiectivele generale de control nu se modifică intr-un mediu informatizat, punerea
lor în aplicare se schimbă. În consecinţă abordarea auditorilor de a evalua controalele
interne va suferi schimbări.
Controalele TI dintr-un sistem informaţional sunt toate metodele manuale şi
programate, politicile şi procedurile care asigură protecţia activelor entităţii,
acurateţea şi fiabilitatea înregistrărilor, şi orientarea operaţională la
standardele managementului.
Prezenţa controalelor într-un sistem informaţional este semnificativă din punctul de
vedere a auditului, deoarece aceste sisteme pot permite dublarea intrărilor sau
prelucrărilor, sau invizibilitatea unor procese, iar în cazul unor organizaţii a căror
sisteme informaţionale sunt operate de furnizori terţi de servicii, care utilizează
propriile standarde şi controale, fac aceste sisteme vulnerabile la acces neautorizat
şi de la distanţă.
La efectuarea auditul TI este preferabil de utilizat ambele tipuri de teste – de
conformitate şi de fond. Testul de conformitate, determină dacă controalele sunt
aplicate în modul descris în documentaţia entităţii. Cu alte cuvinte, un test de
conformitate determină dacă controalele sunt aplicate în conformitate cu politicile şi
procedurile organizaţiei. Auditul de fond "fundamentează" corespunderea
controalelor existente pentru protejarea organizaţiei de la activităţi frauduloase şi
cuprinde rezultatele raportate asupra procesării tranzacţiilor şi activităţilor.
9.1. Controale generale & ale aplicaţiilor
În cadrul mediului IT pot fi identificate două nivele de control:
• Controale IT generale; şi

• Controale ale aplicaţiei.

La cel mai jos nivel, există controale generale, care sunt axate pe mediul general în
care sistemele IT sunt elaborate, exploatate, gestionate şi întreţinute. Controalele IT
generale creează un cadru al controlului general pentru activităţile IT şi oferă unele
asigurări precum că obiectivele generale ale controlului sunt îndeplinite. În esenţă
acestea acţionează ca o fundaţie, pe care pot fi elaborate controale ale aplicaţiilor
specifice.

Celălalt nivel de control constă din controale ale aplicaţiei. Acestea sunt proceduri
specifice de control asupra aplicaţiilor care pot să garanteze că toate tranzacţiile sunt
41
autorizate şi înregistrate, procesate complet, corecte şi efectuate în timp. Controalele
aplicaţiei ar putea consta din proceduri manuale efectuate de utilizatori (controale
ale utilizatorilor) şi proceduri automatizate sau controale efectuate de software de
calculator.

9.1.1. Controale IT generale

Controalele IT generale vizează infrastructura IT a clientului, inclusiv orice politici,
proceduri şi practici de lucru legate de IT. Acestea nu sunt specifice pentru fluxurile
de tranzacţii individuale sau pachete de contabilitate speciale sau aplicaţii financiare.
În majoritatea cazurilor elementele controalelor generale ale unei revizuiri IT se vor
concentra asupra departamentul IT al clientului sau o funcţie similară.
Componentele controalelor generale includ:

• controalele organizaţiei şi de management (politicile şi standardele IT);

• controalele operaţionale;

• controalele fizice şi de mediu;

• segregarea sarcinilor;

• controalele de acces logic;

• dezvoltarea sistemului şi controlul schimbărilor;

• utilizatorii de TI (inclusiv programatori, analişti de sistem, şi personal pentru

operare la calculator);

• Planul de continuitate în afaceri şi Planul de recuperare în caz de dezastru;

• computerizarea utilizatorilor finali.

9.1.2. Controalele aplicaţiei

Controalele aplicaţiei sunt specifice unei aplicaţii şi au un impact direct asupra
procesării tranzacţiilor individuale. Aceste controale sunt utilizate pentru a oferi
asigurare (în principal managementului) că toate tranzacţiile sunt valide, autorizate
şi înregistrate.

Deoarece controalele aplicaţiei sunt strâns legate de tranzacţiile individuale este mai
uşor de a vedea de ce testarea controalelor va oferi auditorului o asigurare în ceea ce
priveşte exactitatea unui anumit sold de cont. De exemplu, testarea controalelor într-
o aplicaţie de salarizare va oferi asigurarea cu privire la cifra salarizării în conturile
unui client şi invers, testarea controalelor IT generale ale clientului (de ex.,
schimbarea procedurilor de control) nu va oferi un grad similar de asigurare pentru
acelaşi sold de cont.
După cum sunt legate de fluxurile de tranzacţii, controalele aplicaţiilor includ de
obicei:
42
 • introducerea tranzacţiilor (controale de intrare);

• controalele de procesare;

• controale de ieşire (raportare);

• „master-files”.

Multe controale ale aplicaţiilor sunt pur şi simplu versiuni computerizate ale
controalelor manuale, de ex., autorizarea computerizată de către un supraveghetor
folosind mai degrabă un cod de acces decât punând o semnătură pe o foaie de hârtie.
9.2. Relaţia dintre controalele generale şi controalele aplicaţiei
O modalitate de a privi relaţia dintre controalele generale şi ale aplicaţiilor este de a
distribui controalele generale pentru protejarea aplicaţiilor şi bazelor de date ale
tranzacţiilor. Controalele generale oferă aplicaţiilor resursele de care au nevoie
pentru a opera şi de a asigura faptul că modificările neautorizate nu pot fi făcute la
nici una din aplicaţii (adică, sunt protejate de reprogramare) sau baze de date de bază
(colecţia mare de date privind tranzacţiile).
În acelaşi timp, controalele aplicaţiilor funcţionează în baza tranzacţiilor individuale
şi asigură că acestea sunt corect introduse, procesate şi produse.

9.2.1. Controale IT tip “ceapa”

În acest model vom începe din mijlocul cepei cu rapoartele financiare şi vom
continua spre ieşire lucrul nostru prin straturi succesive de control. Aceste straturi,
fiind puse împreună ar trebui să reducă riscul ca rapoartele financiare să conţină erori
materiale atunci când noi, ca auditori financiari, începem să le audităm.
Notă: acest capitol este preconizat pentru a oferi auditorilor o interpretare vizual a
straturilor de control utilizând un sistem financiar-contabil. Controalele vor fi
acoperite detaliat în capitolele ce urmează.

• Rapoartele financiare: eventualul obiectiv: sunt toate tranzacţiile totalizate şi

printate? Problemele posibile sau riscurile de care auditorul trebuie să ţină cont
includ:
− sunt conturile complete, adică includ acestea plata noastră?
− au fost plăţile corect arătate ca plăţi?
− a fost planul de conturi sau alte acte normative modificate?
• Produs: În timpul aşteptării pentru imprimare a unui document financiar, ne putem
oare asigura că datele nu au fost modificate sau plăţile redirecţionate într-un alt cont
bancar?
• Procesarea: A fost plata procesată corect utilizându-se corect ratele salariale sau
taxele indirecte?
• Introducerea: Posibilitatea apariţiei erorilor la momentul introducerii tranzacţiei,
de exemplu erori transpoziţionale. Tranzacţia poate fi frauduloasă sau neautorizată.
Operatorul poate introduce date greşite plasând tranzacţia într-o perioadă contabilă
greşită.

43
Toate aceste controale s-au referit până la moment la aplicaţie. Am presupus că
persoana care introduce tranzacţia este un angajat competent, sârguincios şi onest.
Acest lucru ar putea fi şi altfel. După cum progresăm către stratul exterior al cepei,
identificăm mai multe controale IT generale care se axează pe prevenirea accesului
neautorizat al unei persoane la sistem, ceea ce devine din ce în ce mai important
odată cu creşterea reţelelor de arie largă şi conexiunii la Internet. Auditorul trebuie
să aibă asigurarea precum că clientul a folosit versiunea corectă a pachetului contabil
şi nu versiunea netestată care ar putea conţine erori de programare.

• Sistemul de operare: acestea pot controla cine din personal şi ce aplicaţii pot
accesa. De exemplu, aplicaţiile financiare sunt de obicei rulate pe un sistem
computerizat central al clientului împreună cu multe alte programe, aşa ca sisteme
de control pentru personal, procesarea textelor, producere, etc. Sistemul de operare
trebuie să aibă controale pentru a se asigura că numai cei cu acces legitim la
sistemele financiare să poată utiliza acele aplicaţii. Acest lucru se face prin
securitatea accesului logic.

• Accesul la reţea: marea majoritate a sistemelor financiare sunt conectate fie la o

reţea de tip LAN sau WAN. Aceste conexiuni urmează să fie controlate pentru a
asigura că utilizatorii neautorizaţi nu pot accesa sistemele.

• Securitatea sistemului şi auditul intern: Aceste controale în mod normal sunt

efectuate de un ofiţer pentru securitatea sistemelor şi de un departament de audit
intern. Acţiunile acestora ar trebui să ajute la identificarea riscurilor şi adoptarea
măsurilor de a reduce riscurilor la un nivel acceptabil.

• Selectarea, verificarea şi instruirea personalului: Procedurile de selectare şi alte

proceduri legate de personal ar trebui să reducă riscurile de erori, etc. asigurând că
personalul este onest, de încredere şi că ştie ce face.

• Fizic şi de mediu: calculatoarele sunt atât sensibile la mediul lor cât şi atractive
pentru infractori (în ceea ce priveşte valoarea lor inerentă a diferitor componente şi
resurselor financiare pe care le controlează). Calculatoarele trebuie să fie protejate
fizic de aceste riscuri.

• În topul acestor controale se situează politicile şi standardele managementului.

Acestea trebuie să fie politicile şi standardele cu privire la toate inelele interioare
ale controlului de tip ceapă.

44
Controlul de tip ceapă

Physical & Environmental

Controls

System Security & Internal

Audit

Staff Selection, Vetting &

Training

Network Access
Controls

Operating System
Controls

Application
Controls

Privire detaliată asupra stratului de control al aplicaţiei

Applicati
Input Process Output
Transa Accou
ti t
Aud Sta

45
10. Evaluarea controalelor generale
În acest capitol vor fi analizate controalele de nivel înalt adoptate de management pentru a
asigura că sistemele computerizate funcţionează corect şi că acestea satisfac obiectivele
afacerii. Scopul nostru, ca auditori externi, este de a determina dacă controalele pe care le-a
pus clientul în aplicare sunt suficiente pentru a asigura controlul adecvat al activităţilor TI.

10.1. Controalele organizaţionale şi de management (politicile şi standardele IT)

În realizarea evaluării noastre, noi acoperim următoarelor domenii:

• riscurile asociate cu controale inadecvate ale conducerii;
• structurile organizaţionale IT;
• strategia IT şi implicarea conducerii de vârf;
• politicile pentru personal şi instruire;
• politicile de documentare şi păstrare a documentelor;
• politicile de externalizare a serviciilor (outsourcing);
• implicarea auditului intern;
• politicile de securitate IT;
• conformarea legală şi de reglementare; şi
• segregarea sarcinilor.

În principiu, problemele organizaţionale şi de conducere, relevante unei funcţiuni IT nu sunt

diferite de acelea din cadrul funcţiei financiare a unui client. Principiile de bază sunt aceleaşi.

Experienţa a demonstrat că politicile, procedurile şi standardele de nivel înalt sunt foarte

importante in crearea unui cadru solid de controale interne. Clienţii care nu au o unitate TI
robustă de nivel înalt şi controale de management este puţin probabil să aibă controale
adecvate detaliate de un nivel mai inferior.

Politicile de nivel înalt sunt importante deoarece acestea stabilesc un cadru în baza căruia
clientul îşi poate dezvolta controalele detaliate la nivel inferior.

Există o regulă generală precum controalele merg din vârful unei organizaţii în jos (după
toate, controalele sunt responsabilitatea conducerii de vârf).

Fluxul de controale poate fi ilustrat în formă de diagrame.

Management
(Approve Policies)

IT Standards

Detailed Procedures
(e.g.: desk instructions)

46
Conducerea stabileşte şi aprobă politicile. Politicile sunt de obicei declaraţii de intenţie de
nivel înalt. Politicile se utilizează pentru a stabili standarde. Procedurile detaliate (şi
controalele) reiese din standarde.
Auditor ar pierde credibilitate dacă ar fi făcut critici doar teoretice fără a acorda vreo
atenţie la circumstanţele clientului. De exemplu, recomandând clientului să
angajeze mai mult personal pentru a creşte segregarea sarcinilor din cadrul
departamentului IT.
Notă: la examinarea politicilor şi standardelor IT a unui client, auditorul trebuie să ţină cont
de probabilitatea că fiecare client poate fi diferit şi poate avea diferite cerinţe organizaţionale
şi manageriale. Auditorul poate evalua dacă structura organizaţională a clientului şi locul IT
în structură este corespunzător.

10.1.1. Riscurile asociate cu controalele inadecvate

• managementul are responsabilitatea finală pentru salvgardarea activelor
organizaţiilor. Acesta este responsabil faţă de parteneri; contribuabili şi fiecare
cetăţean. Managementul stabileşte politici pentru asigurarea gestionării adecvate a
activelor;

• implicarea inadecvată a managementului ar putea duce la o funcţie TI fără direcţie

(direction-less IT function), care, la rândul său, nu serveşte necesităţilor afacerii.
Acest lucru ar putea da naştere la probleme cu sistemele financiare utilizate, acestea
fiind în imposibilitatea de a respecta noile cerinţe de raportare (care poate apărea
datorită unei schimbări în standardele naţionale de contabilitate sau a unei schimbări
în actele legislative);

• structurile slabe de raportare pot conduce la luarea unor decizii neadecvate. Acest
lucru poate afecta capacitatea clientului de a-şi livra serviciile sale şi poate afecta
viitorul acestuia;

• planificare IT inadecvată sau deloc care conduce la constrângeri în ceea ce priveşte

creşterea afacerilor din cauza lipsei de resurse IT; de ex., managerul IT raportează
directorului executiv că sistemul nu este în măsură să facă faţă creşterii vânzărilor.
Supraîncărcarea unui sistem informatic poate duce la degradare sau indisponibilitate
prin piedici în comunicare sau prin căderi ale unui sistem;

• personal ineficient care nu-şi înţeleg funcţiile lor (fie din cauza politicilor inadecvate
de recrutare sau fie din cauza lipsei de instruire a personalului sau supraveghere).
Acest lucru sporeşte riscul ca personalul să comită greşeli şi erori;

• personal nemulţămit capabil să saboteze sistemul, de exemplu când personalul află

că urmează a fi disciplinaţi sau disponibilizaţi; şi

• funcţia ineficientă de audit intern care nu poate examina în mod satisfăcător

sistemele computerizate şi controalele asociate;

• pierderea pistei de audit din cauza politicilor inadecvate de păstrare a documentelor

(include atât păstrarea documentelor pe suport de hârtie cât şi magnetic, suporturi
optice); şi

47
 • spargeri a securităţii care duc la pierderea datelor, fraudă şi erori.

10.1.2. Organizaţia şi structura IT

Acest capitol continuă cu o analiză a modului în care IT se încadrează în structura de
management a clientului.

În cadrul unui departament IT obişnuit, directorul executiv (sau consiliul de administraţie,

managementul executiv, consiliul de conducere), ar trebui să ocupe partea de sus a
diagramei, subliniind importanţa IT pentru organizaţie.

În continuare, trecem mai departe să vedem modul în care departamentul IT al unui client
se încadrează în structura organizaţională globală, inclusiv legăturile cu alte părţi ale
afacerii.

Directorul IT ar trebui să fie membru al Comitetului de supraveghere IT. Calitatea de

membru îi va permite să discute strategia IT, precum şi orice probleme legate de IT cu
utilizatorii sistemului.

Un client mare poate avea un Comitet pentru securitate care raportează directorului
executiv. Funcţionarul pentru securitatea IT va raporta Comisiei pentru securitate.

10.1.2.1. Controlul şi implicarea managementului superior

Aspecte de luat în considerare atunci când se face examinarea controalelor organizaţiei şi
managementului în cadrul departamentului IT al unui client.

Responsabilitatea generală: Aceasta include o analiză a modului în care IT-ul se

încadrează în structura organizaţională generală. Auditorul ar trebui să determine dacă
există un membru al consiliului sau manager superior (cineva cu influenţă din
managementul superior), cu responsabilitate pentru IT. În cazul în care nu există o astfel
de persoană, avem un risc sporit că IT nu va primi recunoştinţa, atenţia sau resursele de
care are nevoie pentru a-şi îndeplini obiectivele de afacere. Auditorul extern va fi
îngrijorat în cazul în care sistemelor financiare nu li se acordă resursele necesare pentru
a produce conturi complete şi exacte.

Structura IT formalizată: Ar trebui să existe o structură organizaţională formalizată,

cu toţi membrii personalului cunoscându-şi rolurile şi responsabilităţile, preferabil să
aibă fişe de post convenite şi notate.

Comitetul de supraveghere IT: în mod ideal, ar trebui să existe un Comitet de

supraveghere, care să includă reprezentanţi ai utilizatorilor din toate domeniile afacerii,
precum şi personal IT. Comitetul de supraveghere va fi responsabil de direcţia generală
a IT. Natura Comitetului de supraveghere IT va varia în funcţie de circumstanţele
clientului. De exemplu, un departament mare de stat ar fi de aşteptat să aibă un Comitet
de supraveghere oficial, în timp ce, în cadrul unui client mic, Comitetul de supraveghere
IT poate fi mic şi informal. Comitetul de supraveghere IT va fi responsabil de problemele
ce nu ţin de sistemele de contabilitate şi financiare, de exemplu, sistemul de
telecomunicaţii (linii telefonice, videoconferinţe), de sistemele de automatizare pentru
birouri, etc.

48
Pentru a fi eficace, Comitetul de supraveghere IT ar trebui să-şi selecteze membrii săi din
managementul superior şi mediu. Calitatea de membru ar trebui să fie atrasă din toate
departamentele de utilizatori din cadrul unei organizaţii. Locul managementului superior
este deosebit de important, deoarece prezenţa lor oferă deciziile luate de către comitet o
pondere mai mare.

10.1.3. Strategia IT
Odată ce Comitetul de supraveghere stabileşte direcţia ulterioară a IT, deciziile ar putea fi
formalizate şi documentate într-un plan. Direcţia ulterioară a Comitetul de supraveghere IT
este în mod normal stabilit într-un document cunoscut sub denumirea de strategia IT.

!!!! Strategia IT este de fapt punctul de plecare pentru orice investiţii în IT deoarece
aici se identifică schimbările ulterioare care trebuie să fie bugetate.

Deciziile şi modificările planificate specificate în cadrul strategiei IT ar contribui apoi la

planurile anuale ale departamentului IT.

Deşi este probabil ca strategia IT să aibă un efect minim asupra auditului din anul curent,
aceasta poate avea un efect semnificativ asupra auditelor din anii ce urmează. O examinare
a strategiei IT a unui client ar putea pune în gardă auditorul IT referitor la problemele care
pot apărea în anii viitori. De exemplu, strategia IT poate menţiona că organizaţia va înlocui
sistemul său financiar într-o perioadă de doi ani. Acest lucru poate avea impact asupra
activităţii auditorului.

Din punctul de vedere al clientului, riscul principal asociat cu o strategie IT slabă sau absentă
este dezvoltarea unor sisteme care nu satisfac necesităţilor afacerii.

La examinarea strategiei IT ar trebui să stabilim următoarele:

• strategia IT ar trebui să urmeze strategia de business: În trecut, departamentele IT

deţineau controlul asupra deciziilor legate de cheltuielile IT. Aceasta a rezultat în
instalarea sistemelor IT din cauza că personalul tehnic vroia sisteme noi, dar nu
deoarece afacerea necesita sisteme noi;

• devine din ce în ce mai obişnuit ca IT să fie privit ca cheltuieli de business care trebuie
să se justifice. În consecinţă, toate cheltuielile majore legate de IT sunt examinate
îndeaproape şi se fac investiţii doar atunci când este un caz necesar pentru afacere;

• strategia IT ar trebui să fie orientată spre viitor. De obicei, acestea vizează o perioadă
de 3 ani înainte. Este dificil de a prezice cu precizie o perioadă mai mare din
cauza ritmului schimbărilor tehnologice;

• ritmul de schimbare înseamnă de asemenea că strategia IT ar trebui revizuită anual

pentru a verifica dacă presupoziţiile şi deciziile rămân valabile;

• conştientizarea: personalul trebuie ţinut la curent cu privire la problemele

principale din strategia IT;

• strategia ar trebui să includă analiza sistemelor de finanţare; şi

49
 • strategia ar trebui aprobată de managementul superior.

Dimensiunea, detaliile şi conţinutul strategiei IT a unei organizaţii vor varia în funcţie de

diverşi factori, inclusiv: mărimea clientului si departamentului IT, precum şi importanţa sau
situaţia critică a sistemelor IT.

De exemplu, un departament guvernamental mare sau ministerele sunt susceptibile de a

avea strategii IT detaliate care se înşiră pe câteva sute de pagini şi în mai multe volume. La
celălalt capăt al scării, o strategie IT a unui client mic s-ar putea să cuprinde un document de
una sau două pagini.

La revizuirea strategiei IT a clientului auditorul trebuie să ia în considerare ceea ce este

adecvat pentru organizaţie.

10.1.4. Personalul şi instruirea

În ceea ce priveşte frecvenţa apariţiei, cele mai întâlnite cauze ale pierderilor de date, datelor
neautorizate şi modificărilor de program şi căderilor de sistem sunt:
• erori sau omisiuni cauzate de oameni;
• dezastre naturale (inundaţii, incendii, furtuni, cutremure, loviri de fulger, sau o simplă
întrerupere de curent);
• fraudă; şi
• defecţiuni de hardware/software.

Erorile şi omisiunile reprezintă cea mai mare sursă de probleme. Prin urmare, este
important ca clientul să aibă controale şi proceduri pentru a reduce riscul de a comite greşeli.
Acest lucru poate fi realizat prin adoptarea unor politici şi proceduri de personal adecvate,
de exemplu:
• o structură organizaţională clară sprijinită de linii de raportare/ diagrame;
• fişe de post;
• planificarea personalului;
• instruiri şi pregătirea personalului;
• politici de angajare/eliberare din funcţie (inclusiv, coduri de conduită);
• evaluările de personal (promovare/retrogradare);
• contracte speciale;
• rotaţia personalului; şi
• concediile personalului.

10.1.4.1. Structurile organizaţionale /organigrame/

Ar trebui să existe structuri organizaţionale care prezintă liniile de raportare şi de
management. Acest lucru ar trebui să asigure că toţi membrii personalului ştiu cum să se
încadrează în structura organizaţională a afacerii şi a departamentului IT. Diagramele, de
asemenea, oferă o indicaţie personalului, pe cine ar trebui să informeze atunci când se
confruntă cu probleme.

10.1.4.2. Fişele de post

Toţi personalul IT trebuie să primească fişe sau descrieri de post. Acestea urmează să descrie
ce sarcini are de efectuat personalul IT, ca parte a funcţiei. Acestea pot fi folosite pentru
evaluarea personalului şi pentru a ajuta auditorului să determine dacă există o segregare
adecvată a sarcinilor.
50
 10.1.4.3. Planificarea personalului
Planificarea personalului este importantă pentru a asigura că există suficient personal IT
calificat în mod corespunzător pentru a rula sistemele actuale, precum şi corespunde
cerinţelor viitoare de personal. Exemple privind nevoia de planificare a resurselor de
personal includ:

• acolo unde clientul a decis să actualizeze (upgrade) sistemele computerizate,

personalul care este considerat specializat în sistemul vechi ar putea simţi că valoarea
lor pentru organizaţie s-a diminuat sau chiar că zilele lor de angajare în continuare
sunt numărate. În consecinţă, aceştia se pot simţi demoralizaţi şi ar putea să nu mai
acorde asistenţă pentru sistemele vechi în mod adecvat;

• atunci când se instalează sisteme noi, competenţele tehnice necesare pentru rularea
sistemelor noi ar putea să nu fie disponibile. Managementul ar putea avea nevoie să
identifice competenţele necesare din timp şi să trimită personalul la cursuri de
instruire, recruteze personal nou sau să angajeze consultanţi pentru o perioadă.

10.1.4.4. Instruirea şi pregătirea personalului

Instruirea şi pregătirea personalului sunt strâns legate de planificarea resurselor de
personal. Managementul IT ar trebui să ştie ce capacităţi ale personalului sunt necesare atât
pentru prezent cât şi pentru viitorul previzibil. Personalului ar trebui oferite instruiri pentru
a satisface aceste cerinţe. Necesitatea de instruire este în continuă pentru că atât hardware-
ul cât şi software-ul se dezvoltă continuu. Instruirea în domeniul IT este deseori costisitoare
şi ar trebui să fie controlată prin planuri de instruire şi bugete.

Pentru a reduce dependenţa de câţiva angajaţi cheie, clientul poate folosi o formă de
instruire încrucişată, adică instruirea membrilor personalului pentru a efectua activităţile
colegilor lor, în caz de absenţă. Acest lucru prevede, de asemenea, o formă de planificare de
succesiune. Clientul ar trebui să fie conştient de faptul că instruirea personalului pentru a
suplini un alt membru al personalului creşte riscul că acest personal să posede o cunoaştere
mai detaliată a întregului sistem, inclusiv existenţa unor controale compensatoare.

10.1.4.5. Politicile de recrutare/eliberare din funcţie şi coduri de conduită

Politicile ar trebui să se aplice la angajarea personalului permanent, personalului temporar,
contractanţilor şi consultanţilor. Ar trebui să fie adoptate politici de angajare a personalului
pentru a asigura faptul că se selectează personalul corespunzător. Ar trebui să existe, de
asemenea, politici şi proceduri care vizează celălalt capăt al ciclului de angajare, adică
eliberarea din funcţie (fie voluntară, fie obligatorie). Politicile sunt susceptibile de a fi
puternic influenţate de cerinţele legale, adică de legislaţia cu privire la angajare din fiecare
ţară.

La angajarea unor noi membri de personal IT, clientul, ar fi de aşteptat, să ţină cont de:

• verificările de fond: inclusiv solicitarea scrisorilor de referinţă (în unele ţări ar putea
fi posibil de a verifica dacă persoana nu a avut antecedente penale);

• acordurile de confidenţialitate: acestea menţionează că angajatul nu va dezvălui

informaţiile confidenţiale unor părţi terţe neautorizate; şi

51
 • codurile de conduită, inclusiv relaţiile contractuale cu rudele, acceptarea de cadouri,
conflicte de interese, etc.

Angajaţii noi ar trebui să fie familiarizaţi cu rolurile şi responsabilităţile lor în ceea ce

priveşte problemele de securitate.

Politicile cu privire la eliberarea din funcţie ar trebui să definească măsurile care trebuie
întreprinse atunci când serviciile unui angajat nu mai sunt necesare. Este important ca aceste
politici şi proceduri să fie aplicate deoarece pagubele care pot fi cauzate de un angajat
nemulţămit asupra unui sistem computerizat pot fi considerabile. Politicile cu privire la
eliberarea din funcţie ar trebui să abordeze:
• eliberarea din funcţie din motive voluntare ale angajatului (demisia, pensionarea);
• eliberarea din funcţie din motive voluntare ale angajatului: adică concediat;
• eliberarea imediată din funcţie, de ex., din cauza unor încălcări serioase;
• măsuri de securitate: care ar putea include:
o returnarea cheilor de acces, cardurilor şi ecusoanelor de identitate;
o ştergerea sau dezactivarea privilegiilor de acces logic, adică parola acestora.
• alte proceduri:
o notificarea altor angajaţi. Alţi angajaţi ar trebui să fie la curent cu rezilierea
contractului şi aceştia vor fi conştienţi de orice activităţi neautorizate pe care
aceşti angajaţi ar putea încerca să le efectueze;
o aranjarea rutinelor de plată finale pentru a se asigura că acea persoană este
exclusă din statul de plată;
o realizarea interviurilor înainte de plecare ar putea fi utile pentru a determina
sentimentele angajatului faţă de organizaţie;
o întoarcerea bunurilor proprietate a companiei, inclusiv laptop-urilor personale,
pagerelor, cartelelor inteligente (smartcard-uri) etc.; şi
o escortarea în afara incintei (dacă este necesar).

10.1.4.6. Evaluarea personalului, inclusiv promovarea şi retrogradarea

Politicile şi procedurile de evaluare a personalului ar trebui să fie văzute ca juste şi echitabile
şi înţelese de toţi angajaţii. Politicile ar trebui să se bazeze pe criterii obiective şi se va acorda
atenţie tuturor factorilor relevanţi, care ar putea include: nivelul de studii, instruire,
experienţă, nivelul de responsabilitate, realizări şi conduită a angajatului.

10.1.4.7. Contracte speciale

Pentru departamentele IT este din ce în ce mai obişnuit să apeleze la specialişti, contractanţi
şi consultanţi pentru lucrările unice/ocazionale. Ar trebui să existe politici care să ceară
aderarea celor cu contracte speciale la politicile şi procedurile stabilite.

10.1.4.8. Rotaţia personalului

Rotaţia personalului poate oferi un grad de control suplimentar deoarece aceeaşi persoană
nu îndeplineşte aceleaşi îndatoriri tot timpul. Rotaţia personalului permite altor membri ai
personalului să efectueze o activitate care în mod obişnuit este efectuată de altă persoană şi
poate duce la detectarea şi identificarea posibilelor nereguli. Rotaţia personalului de
asemenea acţionează ca un control preventiv. Persoanele sunt mai puţin înclinate să adopte
practici de lucru neaprobate sau să comită fraude dacă ştiu că altcineva le preia postul.

52
 10.1.4.9. Concediile obligatorii
Personalul ar trebui să fie obligat să îşi ia concedii regulate, cel puţin o dată pe an. Acest lucru
ar trebui să reducă riscul ca acţiunile neautorizate sau ilegale să rămână nedepistate.
Concediile obligatorii ar putea fi o condiţie de asigurare, în unele întreprinderi, de exemplu,
industria bancară. Au existat cazuri în care personalul nu a mers în concediu pentru mai
mulţi ani şi au fost efectuate fraude care implică procesul numit teeming and lading (prin
care deficienţele de numerar (furt de numerar) sunt ascunse pentru o perioadă de timp, fiind
acoperite de la un alt creditor, apoi de la altul). Fraudele lor au fost descoperite numai atunci
când s-au îmbolnăvit, şi activitatea lor a fost preluată de către un alt angajat.

10.1.5. Politicile de documentare şi păstrare

La examinarea sistemelor de control intern ale unui client, auditorul IT poate obţine o mare
parte din informaţiile pe care le cere din documentaţia clientului. Auditorul ar putea avea
nevoie de asemenea să examineze documentaţia clientului pentru a testa tranzacţiile
individuale şi soldurile de cont.

10.1.5.1. Politica de documentare a sistemelor

Riscurile asociate cu politicile de documentare inadecvate includ:
• practici de lucru neautorizate, adoptate de personalul IT;
• creşterea numărului de erori făcute de personalul IT;
• sisteme care sunt dificil de întreţinut, astfel sporind riscul de indisponibilitate al
sistemului. De exemplu, dacă reţeaua unui client nu este documentată în mod adecvat
şi apare o problemă cu cablurile, cei însărcinaţi cu efectuarea reparaţiilor ar putea
avea dificultăţi în a localiza unde a apărut defecţiunea. Ei nu ar putea să determine
sub care scândură se află cablurile.

Politica privind documentarea ar trebui să stabilească că toată documentaţia cu privire la

sistem trebuie actualizată la zi şi că doar cele mai recente versiuni ar trebui să fie utilizate.
Politica ar putea, de asemenea, stabili faptul că copiile de rezervă ale documentaţiei să fie
depozitate într-un loc sigur din afara sediului companiei.

În cazul în care un client se conformează cu un standard internaţional, ar trebui să existe

politici privind producerea, aprobarea şi emiterea documentelor, precum şi privind
controlul modificărilor la documentele existente.

10.1.5.2. Politicile de păstrare a documentelor

Auditorul ar putea avea nevoie să examineze probele pentru a ajunge la o opinie cu privire
la situaţiile financiare. Din punct de vedere istoric, aceste probe au fost obţinute din
document pe suport de hârtie (facturi, ordine de cumpărare, note de primire a mărfurilor,
etc.). Deoarece mai mulţi clienţi îşi instalează sisteme computerizate, auditorul va găsi mai
multe probe sub formă de înregistrări electronice.

În final, dacă clientul nu păstrează probe suficiente, adecvate, atunci auditorul va avea
dificultăţi în a fi capabil să ofere opinie de audit.

Auditorul ar trebui să ia în considerare două tipuri de documentaţie în conformitate cu

abordarea de audit:

53
 Abordări de audit bazate pe controale: auditorul ar avea nevoie de probe ale
controalelor în funcţiune pe parcursul perioadei contabile. Aceste probe ar putea consta
din reconcilieri, semnături, jurnale de audit examinate, etc.

Testările de fond: asigurarea ar putea cere ca auditorul să examineze probele legate de

tranzacţiile individuale. Auditorul ar putea necesita să poată urmări tranzacţiile de la
început şi până la rezumarea acestora în conturi. Acolo unde detaliile tranzacţiei sunt
înregistrate în sistemele computerizate acestea ar trebui păstrate pentru inspecţia de
audit. Acolo unde spaţiul de stocare este limitat, de ex., capacitate limitată pe hard
discuri, clientul ar putea arhiva datele sau rezuma datele cu privire la tranzacţii în
bilanţuri/rapoarte. Dacă clientul arhivează datele, auditorul ar putea să aibă nevoie să
ceară ca acestea să fie extrase înainte de a face o vizită. Dacă clientul rezumă tranzacţiile
în bilanţuri, auditorul va avea nevoie să identifice sau solicite o pistă alternativă de audit,
de ex., cerând clientului să producă o copie pe suport de hârtie a tranzacţiilor care să
adune bilanţurile rezumate.

Ar mai putea fi alte cerinţe, ne-asociate cu auditul, care solicită clientului să păstreze
documentaţia referitor la tranzacţii, de exemplu:
• regulamente cu privire la import;
• regulamente cu privire la impozitare; şi
• cerinţe ale companiei cu privire la legislaţie.

Politicile clientului de păstrare a documentaţiei ar trebui să ţină cont de toate aceste cerinţe.

10.1.6. Politica de externalizare a serviciilor

Există o tendinţă tot mai mare ca serviciile IT să fie livrate de către prestatorii terţi de
servicii. Acest lucru a apărut pentru că domeniul IT nu este văzut ca fiind o activitate de bază
a afacerii. Managementul poate să ia atitudine că afacerea lor implică furnizarea de produse
şi servicii, şi nu furnizarea de servicii IT. Externalizarea permite managementului să-şi
concentreze eforturile asupra activităţilor principale ale afacerii.

Nevoia de externalizare poate fi, de asemenea, generată de necesitatea de a reduce costurile

de funcţionare. În cazul în care un client externalizează sau intenţionează să externalizeze
activităţile sale de IT, auditorul trebuie să se preocupe de examinarea politicilor şi
procedurilor care asigură securitatea datelor financiare ale clientului. Auditorul poate avea
nevoie de a obţine o copie a contractului pentru a stabili dacă au fost specificate anumite
controale adecvate.

În cazul în care clientul intenţionează să externalizeze funcţia sa IT, auditorul trebuie să se

asigure că nevoile auditului sunt luate în considerare şi incluse în contracte. Clauzele
contractuale sunt adesea dificil de a fi schimbate odată ce acestea au fost semnate. Chiar dacă
partea terţă este dispusă să modifice contractul este probabil să perceapă o taxă mare pentru
a face acest lucru. Taxa ar putea fi trecută de către client pe seama auditorului.

10.1.7. Implicarea auditului intern

După cum s-a menţionat anterior în acest modul, managementul are responsabilitatea finală
pentru a se asigura că un sistem adecvat de controale interne este în vigoare. Managementul
implementează politici şi proceduri şi primeşte asigurarea că controalele sunt funcţionale şi
în mod corespunzător reduc riscurile identificate, bazându-se pe activitatea de examinare
efectuată de către auditorii interni.
54
Auditorul extern poate analiza funcţia de audit intern a clientului, ca parte a structurii de
control global (deoarece auditorii interni previn, depistează şi corectează deficienţele de
control şi erorile).

Auditorul extern IT urmează să efectueze o evaluare generală a funcţiei de audit intern a

clientului. Această evaluare va permite auditorului să decidă dacă putem folosi sau ne putem
baza pe activitatea de audit intern. Auditorul IT extern trebuie să determine dacă:

• se poate obţine asigurare din activităţile de audit intern;

• personalul implicat în auditul intern poate fi utilizat pentru a oferi asistenţă directă
în cadrul auditului, dacă este necesar sub supravegherea auditorului extern. De
exemplu, auditorul extern ar putea cere auditorilor interni să-i acorde asistenţă la
verificarea existenţei activelor fixe.

Înainte de a ne încrede pe activităţile de examinare a controalelor IT efectuate de către

auditorii interni ai clientului, noi ar trebui să efectuăm evaluarea noastră proprie asupra
muncii lor. Această evaluare poate fi în mare măsură informată din experienţa anterioară şi
din examinarea directă a activităţii de audit intern.
Întrebările de bază pe care auditorul extern le poate solicita la revizuirea activităţii de audit
intern includ:
• raportează auditul intern managementului superior?
• poate auditul intern să raporteze consiliului de administraţie sau comitetului de audit?
• se cere ca managementul să acţioneze la recomandările auditului intern?
• au aceştia împuternicirea să efectueze o gamă largă de evaluări sau există restricţii
semnificative cu privire la domeniul de aplicabilitate a activităţii sale?
• există suficiente resurse disponibile, în ceea ce priveşte finanţele şi personalul? şi
• este calitatea auditului intern acceptabilă în ceea ce priveşte planificarea,
supravegherea, revizuirea şi documentarea?

Personalul cu competenţe şi experienţă în auditul IT nu va fi întotdeauna angajat de către

departamentele de audit intern. Unele departamente de audit intern pot avea personal de
audit IT în cadrul companiei şi altele pot contracta auditori IT pentru activităţi de examinare
specifice. Unele departamente de audit intern nu pot efectua orice fel de examinări ale
controalelor IT.

Auditorul extern ar trebui să ia în considerare dacă departamentul de audit IT dispune de

personalul necesar pentru a efectua examinări competente cu privire la sistemele
informatice ale clientului.

În cazul în care auditorul extern intenţionează să se bazeze pe activitatea auditorilor interni

acesta ar trebui să examineze activitatea în comparaţie cu standardele proprii de audit.

10.1.8. Politica de securitate IT

Este important ca clientul să stabilească o politică de securitate IT, care prevede în mod clar
poziţia organizaţiei. Controale detaliate la un nivel mai inferior ar trebui să se bazeze pe
politica de securitate IT. De exemplu, controalele detaliate asupra parolelor ar trebui să se
bazeze pe secţiunea privind accesul logic din cadrul politicii de securitate IT.

Politicile de securitate IT sunt, în mod normal, exprimate sub formă de naraţiune concisă,
55
adică în câteva pagini de text. Politica necesită aprobarea managementului superior în cazul
în care se doreşte ca aceasta să aibă vreo influenţă, şi, prin urmare, ar trebui să fie aprobată
la nivel de consiliu de administraţie sau echivalentul acestuia şi ar trebui susţinut de
managementul superior. În cele din urmă, ar trebui să fie disponibilă tuturor angajaţilor,
responsabili de securitatea informaţională. Acolo unde clientul dispune de personal care are
acces la un sistem computerizat, aceasta va include astfel de personal.

Politica ar trebui să conţină următoarele:

• o definiţie a securităţii informaţionale, obiectivele sale generale şi domeniul de
aplicare;
• o declaraţie cu privire la intenţia managementului, care sprijină obiectivele şi
principiile securităţii informaţionale;
• o extindere a politicilor de securitate specifice, principiilor, standardelor şi cerinţelor
de conformitate, inclusiv:
o conformitatea cu cerinţele legale şi contractuale;
o educaţie şi instruire în domeniul securităţii;
o politica de prevenire şi detectare a viruşilor;
o politica de planificare a continuităţii afacerii.
• o definiţie a responsabilităţilor generale şi specifice pentru toate aspectele securităţii
informaţionale; şi
• o explicaţie a procesului de raportare a incidentelor de securitate suspectate .

Clientul ar trebui să implementeze metode de monitorizare a conformităţii cu politica şi de

asigurare că politica rămâne actualizată la zi.

Politica de securitate IT ar trebui să fie sprijinită de standarde şi proceduri de securitate IT

mai detaliate. De exemplu:

• stabileşte că toate sistemele computerizate ar trebui să fie protejate prin controale

ale parolelor;

• menţionează că parolele ar trebui să conţină 6 caractere, să fie greu de ghicit şi să

constea dintr-un amestec de caractere alfa-numerice; şi

• oferă utilizatorilor îndrumări privind modul de schimbare a parolelor lor în diferite

sisteme pe care sunt autorizaţi să le folosească, de ex., parolă la conectare (bios),
parola mainframe (calculatoare de mare capacitate), etc.

Unii clienţi creează forumuri pentru securitate informaţională pentru a analiza şi coordona
politicile de securitate IT.

Responsabilitatea pentru securitatea IT este, în mod normal, atribuită unei funcţii de

administrare a securităţii. La clienţii mai mici, această funcţie poate fi un post part-time
deţinut de un membru al personalului, cunoscut sub numele de specialist pentru securitatea
IT. Clienţii mai mari ar fi de aşteptat să aibă personal dedicat pentru securitatea IT.

10.1.9. Conformitatea legală şi de reglementare

Cerinţele legale şi de reglementare vor varia de la o ţară la alta.
Cerinţele legale şi de reglementare ar putea include:

56
 • legislaţie privind protecţia şi confidenţialitatea datelor pentru a proteja datele cu
caracter personal la indivizi, de ex., informaţia salarială a acestora;

• legislaţie privind utilizarea calculatorului în scopuri ilegale pentru a face încercări de

spargere a calculatoarelor şi accesare neautorizată prin intermediul calculatorului a
antecedentelor penale;

• reglementări bancare şi financiare, care prevăd ca băncile să fie supuse unor

examinări regulate, dacă acestea doresc să continue să funcţioneze; şi

• legile privind dreptul de autor pentru a preveni furtul de software de calculator.

Clientul ar trebui să fie la curent cu cerinţele locale şi să întreprindă măsuri adecvate pentru
a asigura conformitatea.
Neconformitatea ar putea rezulta în acţiuni, variind de la os scrisoare de avertizare la
urmărire penală sau chiar închiderea afacerii.

10.1.10. Segregarea sarcinilor

Separarea sarcinilor este o modalitate dovedită de a asigura că tranzacţiile sunt autorizate,
înregistrate în mod corespunzător şi că activele sunt protejate. Separarea sarcinilor se
produce atunci când o persoană efectuează un control asupra activităţilor altei persoane. De
asemenea, aceasta este utilizată pentru a împiedica o persoană să desfăşoare o activitate de
la început până la sfârşit, fără implicarea unei alte persoane. Separarea sarcinilor reduce
riscul de fraudă, deoarece pentru a ocoli controlul ar fi necesare înţelegeri secrete.

Sarcinile segregate pot de asemenea oferi o formă de verificare a erorilor şi control al calităţii
şi includ atât:

• separarea responsabilităţilor pentru controalele activelor de responsabilitatea ţinerii

înregistrărilor care contează pentru ei; şi

• separarea funcţiilor din cadrul mediului IT.

Separarea sarcinilor se aplică atât pentru mediul controalelor generale cât şi pentru aplicaţii
sau programe specifice.

În cadrul mediului controalelor IT generale, diferite funcţii şi roluri din cadrul

departamentului IT ar trebui segregate.

De exemplu, un dezvoltator de software nu ar avea nevoie de acces la mediul real de calcul

pentru a putea să-şi efectueze munca. Programatorii nu trebuie să aibă autoritatea de a
transfera un software nou între mediile de elaborare, testare şi mediile de producţie.
Segregarea sarcinilor între programatori şi personalul operativ ar reduce riscul ca cei cu
cunoştinţe de programare să poată face modificări neautorizate în programe.

În multe cazuri, departamentul IT va fi împărţit în două categorii mari de activitate:

• programare (sisteme şi aplicaţii); şi
• operaţiuni computerizate.

57
Personalul nu ar trebui să aibă sarcini care să se încadreze în ambele tipuri de activitate.
Programatorii nu ar trebui să dispună de acces la fişiere şi programe cu date reale.

Într-o lume ideală, majoritatea funcţiilor din cadrul departamentului IT ar fi efectuate de

personal diferit, de ex.:
• proiectarea şi programarea sistemelor;
• asistenţă pentru sisteme;
• operaţiuni IT de rutină;
• introducerea datelor;
• securitatea sistemului;
• administrarea bazei de date; şi
• managementul schimbărilor.

Cu presiunea de a reduce costurile funcţiilor IT, numărul personalului este adesea redus.
Aceasta limitează domeniul de aplicare pentru sarcinile segregate. Dacă acesta este cazul,
atunci auditorul trebuie să adopte o abordare pragmatică pentru identificarea punctelor
slabe şi oferirea recomandărilor. În cazul în care domeniul de aplicare pentru sarcinile
segregate este limitat, auditorul ar trebui să caute existenţa unor controale compensatoare,
cum ar fi securitatea bună a calculatoarelor şi reconcilierea între utilizatorii finali.

Auditorul ar trebui să determine dacă personalul IT, de asemenea, are responsabilităţi în

cadrul departamentelor pentru utilizatori. IT ar trebui să fie separat de funcţiile de utilizator,
cum ar fi finanţe, gestiunea stocurilor, evaluarea granturilor, etc., Personalul cu atribuţii în
ambele domenii – de IT şi de utilizator – ar dispune de o cunoaştere mai bună a sistemelor,
inclusiv despre existenţa unor controale manuale şi compensatoare, şi ar putea face modificări
neautorizate şi greu de depistat.

58
 10.2. Operaţiuni TI

10.2.1. Rolurile şi responsabilităţile operaţiunilor IT

Rolurile şi sarcinile operaţiunilor IT includ următoarele:

1. planificarea capacităţilor: adică asigurarea faptului că sistemele computerizate

vor continua să ofere un nivel satisfăcător de performanţă pe termen mai lung.
Acest lucru va implica personalul operativ IT să facă estimări ale cerinţelor
viitoare ce ţin de unitatea principală de procesare (CPU), capacitatea de stocare
pe disc şi capacitatea de încărcare pe reţea.

2. monitorizarea performanţelor: monitorizarea zi cu zi a performanţelor

sistemului în ceea ce priveşte măsurile, cum ar fi timpul de răspuns.

3. încărcarea iniţială a programului: încărcarea sistemelor sau instalarea unor

programe software noi.

4. managementul media: include controlul discurilor şi dischetelor, CD ROM-urilor

(cartelelor perforate, în cazul în care clientul are un sistem foarte vechi).

5. planificarea realizării sarcinilor: o sarcină este, în mod obişnuit, un proces sau

secvenţă a unui lot de procese, care sunt rulate peste noapte or pe fundal şi care
actualizează fişierele, etc. În mod obişnuit, sarcinile sunt rulate periodic, fie zilnic,
săptămânal, lunar, trimestrial sau anual.

6. copiile de siguranţă (back-up) şi restabilirea în caz de dezastru: copii ale

datelor şi software vor fi făcute de personalul operativ IT cu regularitate.
Aspectele legate de back-up şi continuitatea afacerii sunt acoperite detaliat într-
un capitol următor.

7. centrul de asistenţă (help desk) şi managementul problemelor: centrele de

asistenţă sunt legătura zilnică dintre utilizatori cu problemele ce ţin de IT şi
departamentul IT. Acestea sunt acele pentru care utilizatorii te sună/cheamă când
au o problemă cu imprimanta sau îşi uită parola. Problemele ar putea fi întâlnite
şi cu programele individuale (aplicaţii şi sisteme), hardware sau telecomunicaţii.

8. întreţinerea: atât a hardware cât şi software.

9. monitorizarea şi administrarea reţelei: majoritatea calculatoarelor folosite în

mediul de afaceri, inclusiv Guvern, sunt în reţea. Funcţiei operaţiunilor IT îi revine
responsabilitatea pentru a asigura că legăturile de comunicare sunt menţinute şi
că oferă utilizatorilor nivelul necesar de acces la reţea.

“Operaţiunile computerizate” se referă la aspectele logistice şi de infrastructură ale

hardware şi software. Operaţiunile computerizate corespunzătoare scutesc utilizatorii de
necesitatea de a analiza aceste aspecte prin asigurarea faptului că sistemele de aplicaţii sunt
disponibile la ore programate, acestea funcţionează după cum este prevăzut şi rezultatele
procesării acestora, cum ar fi copiile la imprimantă, sunt produse la timp. Într-un
departament IT bine condus, ne aşteptăm să găsim operaţiuni computerizate care să fie
transparente pentru utilizatori, care îi sprijină pe deplin în îndeplinirea rolurilor lor.

59
 10.2.2. Riscurile asociate cu operaţiunile computerizate slab controlate
Riscurile includ:

• aplicaţii neexecutate corect (rularea unor aplicaţii greşite sau versiuni incorecte
sau parametri de o configurare greşită introduse de personalul operativ, de ex., ora
şi data sistemului fiind incorecte, ceea ce ar putea duce la procente ale dobânzii
eronate, calcule salariale eronate, etc.);

• pierderea sau coruperea aplicaţiilor financiare sau fişierelor de date principale: ar

putea rezulta din utilizarea necorespunzătoare sau neautorizată a utilităţilor
sistemului. Personalul operativ IT ar putea să nu cunoască cum să facă faţă
problemelor de procesare sau rapoartelor/mesajelor de eroare. Aceştia ar putea
cauza mai multe daune decât să le soluţioneze;

• întârzieri şi întreruperi în procesare. Acordarea de priorităţi greşite unor sarcini;

• lipsa de backup şi planificarea în împrejurări neprevăzute cresc riscul de a nu

putea continua procesarea în urma unui dezastru;

• lipsa de capacitate a sistemului. Sistemul ar putea să nu poată procesa

tranzacţiile în timp util din cauza supra-încărcării sau lipsei spaţiului de stocare
care împiedică afişarea vreunei tranzacţii noi; şi

• perioade mari de timp de neoperare a sistemului pentru remedierea defectelor:

atunci când sistemele nu sunt disponibile, se poate crea un jurnal al comenzilor în
aşteptare (backlog) al tranzacţiilor neafişate;

• problemele utilizatorilor rămân nerezolvate din cauza unei funcţionări slabe a

help-desk-ului. Utilizatorii ar putea încerca să-şi soluţioneze problemele.

10.2.3. Controlul operaţiunilor IT

10.2.3.1. Acorduri privind nivelul serviciilor
Este din ce în ce mai obişnuit pentru departamentele IT să elaboreze şi să aprobe acorduri
privind nivelul serviciilor (service level agreement – SLA) cu restul organizaţiei, adică
departamentele de utilizatori. Acest lucru permite utilizatorilor să specifice şi să fie de acord,
de preferinţă în scris, cu nivele de servicii, în ceea ce priveşte cantitatea şi calitatea necesară.
Acordurile privind nivelul serviciilor sunt de fapt contracte de prestare a serviciilor interne.

Fără un acord privind nivelul serviciilor, următorul proverb devine relevant: "Dacă ţinteşti
către nicăieri, de obicei acolo ajungi.", Structura şi nivelul de servicii specificat într-un
SLA va depinde de practicile de lucru şi cerinţele fiecărei organizaţii. Un SLA tipic ar putea
să conţină următoarele:

• dispoziţii generale (inclusiv domeniul de aplicare al acordului, semnatarii acestuia,

data următoarei revizuiri);
• descrierea succintă a serviciilor (aplicaţii ale funcţiilor şi tipuri majore de
tranzacţii);

60
 • ore de serviciu (program normal de lucru şi ocazii speciale precum week-end-
urile);
• disponibilitatea serviciului (procentajul disponibilităţii, numărul maxim de erori
al serviciului şi timpul maxim de neoperare per defecţiune);
• nivelele de sprijin pentru utilizatori (detalii help desk);
• performanţa (timp de răspuns, durata ciclului de prelucrare (turnaround time);
• situaţii neprevăzute (detalii succinte ale planurilor);
• securitate (inclusiv conformarea cu politica de securitate IT a organizaţiei); şi
• restricţii (numărul maxim de tranzacţii, utilizatori);

Auditorul ar trebui să examineze orice SLA pentru a determina că aceste sprijină procesarea
corectă şi consecventă a datelor financiare.

10.2.3.2. Controlul, revizuirea şi supravegherea din partea managementului

Personalul operativ TI ar trebui să fie supravegheat de management. Din punctul de vedere
al separării sarcinilor, acestora nu ar trebui de distribuit sarcini de a introduce tranzacţii
sau orice formă de programare a aplicaţiilor.

Sistemele IT ale clientului ar putea avea incluse utilităţi software care ar putea fi utilizate, să
presupunem, pentru a face modificări neautorizate la fişierele de date. Personalul operativ
cu acces la astfel de software ar trebui supravegheat pentru a se asigura că aceştia utilizează
utilităţile în scopuri autorizate.

Conducerea nu va putea asigura o monitorizare continuă a personalului operativ TI şi ar

putea să aibă o oarecare încredere în instrumentele de logare şi monitorizare automatizate
incluse în sisteme. Evenimentele înregistrate în jurnale vor depinde de parametrii setaţi la
instalarea sistemelor. Ca şi cu majoritatea sistemelor de logare, o mare cantitate de date pot
fi produse într-o perioadă scurtă. Recomandând ca clientul să revizuiască jurnalele de
activitate (loguri) cu regularitate este puţin probabil să se aplice în practică. Pentru a ajuta
conducerea în detectarea activităţilor neautorizate, clientul ar trebui să elaboreze proceduri
(de ex., un program) pentru a raporta excepţiile sau anomaliile.

Supravegherea eficace asupra personalului operativ IT este deseori dificilă de realizat, din
cauza nivelului înalt de cunoştinţe tehnice. Aceştia ar putea face sistemului ceva ce
conducerea nu ar putea depista sau chiar recunoaşte importanţa, dacă se depistează o
schimbare. Din acest motiv, într-o oarecare măsură conducerea trebuie să acorde un grad
înalt de încredere personalului operativ TI, iar încrederea să se bazeze pe selectarea
adecvată a personalului şi proceduri de validare (conform controalelor organizaţionale şi de
management discutate în capitolul precedent, {capitolul 10.1}).

10.2.3.3. Instruirea şi experienţa

Personalul operativ IT ar trebui să dispună de competenţe, experienţă şi instruire necesare
pentru a-şi realiza activităţile lor la standarde competente. Auditorul IT ar trebui să
determine dacă necesităţile de instruire ale personalului operativ IT au fost evaluate.
Necesităţile de instruire ar putea include instruire ne-tehnică, de ex., instruirea
managementului pentru supravegherea operaţiunilor IT.

Ca un ajutor pentru continuitatea asigurării cu personal, unele organizaţii ar putea instrui

personalul să aibă mai mult de un rol sau să introducă o formă de rotaţie a angajaţilor.

61
Strâns legată de instruire este dezvoltarea carierei personalului. Dacă operaţiunile IT se
consideră că se află într-un punct mort cu puţin progres, moralul acestora ar putea fi la un
nivel redus şi este mai puţin probabil ca să-şi desfăşoare activitatea la un standard înalt
(aceştia chiar ar putea fi tentaţi să ocolească regulile şi să efectueze activităţi neautorizate).

10.2.3.4. Întreţinerea calculatoarelor

Ca şi cu majoritatea echipamentului, calculatoarele ar putea necesita o întreţinere regulată
pentru a reduce riscul de defecte neaşteptate de hardware. Deşi întreţinerea profilactică
devine din ce în ce mai puţin obişnuită, în special pentru mini şi micro-calculatoare, s-ar
putea să fie încă necesar pentru echipamentul de mediu, cum ar fi aparatele de aer
condiţionat şi instalaţiile de stingere a focului. Funcţia operaţiunilor IT ar trebui să aibă fie o
capacitate internă pentru întreţinere, fie să contracteze în afară serviciile de întreţinere de
la un furnizor terţ.

Auditorul IT ar putea dori să examineze contractele de întreţinere şi graficul de executare a

lucrărilor pentru a determina dacă se efectuează o întreţinere adecvată. Ulterior, testele
cheie în ceea ce priveşte modul adecvat al aranjamentelor clientului pentru serviciile de
întreţinere reprezintă perioada de ne-operare (down-time) a sistemului sau numărul
incidentelor de Help desk care apar din cauza defecţiunilor de echipament.

10.2.3.5. Documentarea operaţiunilor

Clientul urmează să aibă nişte proceduri de operare clare şi documentate pentru toate
sistemele computerizate pentru a asigura operarea corectă, sigură a acestora. Procedurile
documentate ar trebui să fie disponibile pentru executarea detaliată a fiecărei activităţi şi ar
trebui să includă următoarele:
• mânuirea corectă a fişierelor de date;
• cerinţele de planificare în timp (pentru a asigura cea mai bună utilizare a resurselor
IT);
• instrucţiuni pentru gestionarea erorilor sau altor condiţii excepţionale care pot
apărea când sunt operate activităţile;
• contacte de sprijin în cazul dificultăţilor operaţionale neaşteptate sau tehnice
dificultăţi;
• rezultate (output) speciale pentru gestionarea instrucţiunilor; şi
• re-conectarea (restart) sistemului şi proceduri de recuperare.

Clientul ar trebui, de asemenea, să dispună de proceduri documentate pentru activităţile de

menaj şi întreţinere, cum ar fi procedurile de pornire (start-up) ale calculatorului,
procedurile zilnice de salvare (back-up) a datelor, gestionare a sălii de calculatoare şi de
securitate.

Documentaţia poate fi utilizată de personalul operativ TI atunci când nu sunt siguri cum să
desfăşoare o procedură. Acestea sunt utile şi pentru instruire personalului nou.

Auditorul ar trebui să ţină cont că nivelul şi detaliul documentaţiei va varia de la un client la

altul şi va depinde de factori precum mărimea organizaţiei, tipul hardware-lui şi software-
ului utilizat şi tipul aplicaţiilor. Auditorul se va aştepta să vadă cantităţi mari de
documentaţie de calitate înaltă într-o operaţiune amplă, critică de IT, pe când un client mic

62
care-şi rulează software-le de automatizare a oficiului vor avea probabil documentaţie mai
puţin detaliată şi extensivă.

10.2.3.6. Managementul problemelor

Secţia de operare IT ar trebui să dispună de proceduri documentate pentru depistarea şi
înregistrarea condiţiilor anormale. Un jurnal manual sau computerizat poate fi utilizat
pentru a înregistra aceste condiţii.

Jurnalul trebuie să includă:

• data depistării erorii sau defecţiunii: când a fost depistată defecţiunea prima dată;
• descrierea rezoluţiei scrisorii: rezolvate, pendinte, sunt în investigaţie, nici o
acţiune ulterioară, de ne-rezolvat;
• codul erorii: de ex., A3=defecţiune a imprimantei, B2= defecţiune a unităţii de
afişare vizuală (VDU), C2= defecţiune la sistemul de aplicaţii;
• descrierea erorii: o scurtă naraţiune care să descrie defecţiunea;
• sursa erorii;
• iniţialele celor responsabili de întreţinerea jurnalului, închiderea jurnalului; şi
• secţia responsabilă pentru soluţionarea problemei.

Abilitatea de a adăuga o înregistrare în jurnal nu ar trebui să fie limitată, însă capacitatea de

a actualiza jurnalul ar trebui restricţionată şi efectuată doar de personalul autorizat.
Managementul ar trebui să dispună de mecanisme ca să asigure că mecanismul de
soluţionare a problemei este întreţinut în mod adecvat şi că erorile restante sunt abordate şi
rezolvate adecvat.

10.2.3.7. Managementul şi controlul reţelei

Acolo unde clientul foloseşte reţele de calculator sunt necesare o serie de controale.
Administratorii de reţea ar trebui să asigure că există controale adecvate pentru a securiza
datele în reţele, şi că reţelele sunt protejate adecvat de acces neautorizat. Controalele ar
putea include:
• separarea sarcinilor dintre operatori şi administratorii de reţea;
• stabilirea responsabilităţii pentru procedurile şi managementul echipamentului
de la distanţă;
• monitorizarea disponibilităţii şi performanţei reţelelor. Trebuie să existe
rapoarte şi utilităţi pentru a măsura timpul de răspuns al sistemului (response
time) şi perioada de ne-operare (down time); şi
• stabilirea şi monitorizarea controalelor de securitate specifice reţelelor de
calculatoare.

10.3. Controale fizice şi de mediu

10.3.1. Introducere
Obiectivul controalelor fizice şi de mediu este de a preveni accesul şi intervenţia
neautorizată la serviciile IT. În acest scop, echipamentele informatice şi informaţiile pe care
acestea le conţin şi le controlează trebuie protejate de utilizatori neautorizaţi. Ele trebuie
protejate şi de deteriorarea produsă de mediul înconjurător, cauzată de foc, apă (fie sub
formă concretă, fie ca umiditate în exces), cutremure, incendii de pădure, alunecări de teren,
supratensiuni de curent electric sau întreruperi ale acestuia.

63
Conform Asociaţiei de Control şi Audit al Sistemelor Informatice (ISACA), a doua cauză
generatoare de erori o reprezintă dezastrele naturale (prima fiind eroarea de utilizator, a treia
fiind frauda, iar a patra - defecţiunea hardware).

Există două moduri de a restricţiona accesul la sistemele informatice, accesul fizic şi accesul
logic. Acest capitol examinează accesul fizic şi măsurile de protecţie pentru a proteja fizic un
sistem informatic. Accesul logic este analizat în capitolul 10.4.

10.3.2. Riscuri asociate cu controale fizice sau de mediu insuficiente/absente

10.3.2.1. Fizice
• daune accidentale sau intenţionate produse de către personal:
o angajaţi IT;
o personal de curăţenie, agenţi de pază;
o alţi angajaţi.
• furtul de calculatoare sau componente individuale ale acestora (furtul de
calculatoare este în creştere şi este probabil să continue. Luaţi în considerare
faptul că, bucată cu bucată, cipurile de calculator valorează mai mult decât aurul
şi sunt foarte atractive pentru hoţi);
• pana de curent sau supratensiunea, care poate cauza deteriorarea componentelor
şi pierderea sau deteriorarea datelor;
• evitarea controalelor de acces logic: de ex., accesul fizic la un server de fişiere
poate fi exploatat pentru a ocoli controalele logice, cum ar fi parolele; şi
• copierea sau vizualizarea de informaţii sensibile sau confidenţiale, de ex.,
politicile de stabilire a preţurilor, rezultatele înaintea publicării, politicile
guvernamentale.

10.3.2.2. De mediu
• daune produse de incendiu / apă (sau daune produse de alte dezastre naturale);
• energie electrică: întreruperi, ceea ce duce la pierderea datelor din memoria
volatilă (RAM);
o Pene: duc la căderi de sistem, erori de prelucrare;
• deteriorarea echipamentului din cauza temperaturii sau umidităţii extreme (sau
doar cu câteva grade în afara valorilor normale);
• explozia cauzată de bombe. Terorismul pare a fi în creştere în întreaga lume.
Centrele informatice par a fi uşor de atacat, iar distrugerea lor ar putea avea
repercusiuni semnificative asupra guvernului;
• electricitatea statică: poate deteriora componentele electrice sensibile fixate în
calculator (ROM, RAM şi procesorul). Acestea pot fi uşor deteriorate de şocuri de
electricitate statică;
• altele: de ex. trăsnet.

De asemenea, unele dintre aceste riscuri sunt tratate mai profund în capitolul despre
planificarea continuităţii afacerii. {în Capitolul 10.5}.

Preocuparea principală a auditorului financiar al sistemelor informatice este aceea că un

incident asociat cu controale fizice sau de mediu îndoielnice va creşte riscul:
• deteriorării calculatoarelor şi datelor financiare ale clientului, limitând
capacitatea acestuia de a înregistra tranzacţiile financiare şi a produce un set de
rapoarte financiare care pot fi supuse auditului;
64
 • erorilor din rapoarte, cauzate de fraudă sau greşeli ale clienţilor.

10.3.3. Abordarea clientului faţă de riscurile fizice şi de mediu

Este responsabilitatea conducerii să se asigure că există controale interne adecvate
pentru a proteja activele şi resursele instituţiei. Pentru a face acest lucru, conducerea trebuie
să efectueze o evaluare a riscurilor. Aceasta ar implica identificarea ameninţărilor la adresa
sistemelor, vulnerabilitatea componentelor sistemului şi impactul probabil al unui posibil
incident. Conducerea identifică apoi măsuri de combatere pentru a reduce nivelul de
expunere la un nivel acceptabil. Conducerea trebuie să compare riscurile identificate cu
costurile de punere în aplicare a controalelor.

Punerea în aplicare a unor controale poate fi costisitoare şi ar fi justificată doar într-un mediu
cu grad ridicat de risc. Alte controale pot fi considerate a fi de bază, de ex. încuietorile uşilor,
şi vor fi găsite la majoritatea clienţilor. Politica de securitate IT a clientului ar trebuie să ia în
considerare a riscurilor fizice şi de mediu.

Măsurile de combatere, sau controalele pe care clientul le introduce, vor varia de la un client
la altul. De exemplu, un departament guvernamental mare, având propriul său centru de
date, va avea de obicei un grad mai mare de control asupra echipamentelor sale de IT, decât
o organizaţie mică care utilizează sisteme informatice de birou, cum ar fi procesare de text
şi foi de calcul.

10.3.4. Controale fizice şi de mediu specifice

10.3.4.1. Controlul fizic al zonelor sigure
Controalele fizice de acces sunt în mod special menite să asigure că doar cei care au fost
autorizaţi de către conducere au acces fizic la sistemele informatice. Securitatea accesului
fizic trebuie să se bazeze pe conceptul de perimetre desemnate, care înconjoară
echipamentele IT. De exemplu, clientul ar putea desemna un perimetru IT în jurul clădirii,
în jurul sălii cu calculatoare, în jurul camerei imprimantei, etc. Perimetrele trebuie să fie clar
definite, iar personalul trebuie să fie conştient de localizarea limitelor.

Accesul la locul şi zonele sigure ale clientului trebuie controlat prin straturi de controale,
începând de la gardul perimetrului şi acţionând prin intrarea în clădire, până la sala cu
calculatoare şi terminale. Controalele fizice pot fi explicite, cum ar fi un sistem de blocare a
uşii; sau implicite, de exemplu, fişa postului unui angajat implică necesitatea de a intra în
zona de operaţiuni IT.

10.3.4.2. Controale administrative:

• personalul care poartă insigne cu numele sau identificarea;

• anularea drepturilor de acces ale personalului concediat: de ex. agenţii de

securitate sunt informaţi atunci când personalul pleacă, sau cheile sunt returnate
atunci când angajaţii sunt concediaţi. Trebuie să existe proceduri pentru
identificarea persoanelor care pleacă şi interzicerea accesului fizic a lor în clădire;

• vizitatori: înscrierea în jurnal a vizitatorilor, inclusiv cine sunt, pentru cine

lucrează, pe cine vizitează, ora sosirii, ora ieşirii. Vizitatorii pot fi solicitaţi să
prezinte o anumită formă de identificare, înainte de a li se permite intrarea, de ex.
65
 un permis de conducere sau buletin de identitate. Vizitatorii pot fi însoţiţi
permanent;

• procedurile în afara programului de lucru: adică ce trebuie de făcut atunci când

angajaţii părăsesc birourile, de ex. atunci când personalul pleacă seara acasă, sau
pentru masa de prânz. Măsurile ar putea include blocarea tastaturilor, punerea
calculatoarelor portative în sertare încuiate şi blocarea unităţilor de dischete.

• Încuierea uşilor - încuietorile fizice de la uşi necesită unul din două lucruri pentru
a avea acces. Ceea ce cineva are, sau ceea ce cineva ştie. Indiferent de metoda
utilizată, "cheia" pentru fiecare tip de încuietoare trebuie bine controlată, de
exemplu, cui trebuie să i se dea o cheie sau cui trebuie să i se spună combinaţia de
taste. Încuietorile frecvent întâlnite includ:
o chei mecanice: cheia de la uşă trebuie marcată "a nu se reproduce", iar cheile
nu trebuie să indice numărul biroului la care permit accesul;
o încuietori cu combinaţie sau cu cifru: acestea sunt în general tastaturi cu
butoane numerotate. Personalului autorizat i se dă combinaţia pentru a avea
acces. Combinaţiile variază între 3-6 numere şi trebuie schimbate în mod
regulat, sau atunci când un membru al personalului IT pleacă sau se mută în
altă parte a organizaţiei;
o încuietori electronice: Acestea utilizează în general carduri de plastic cu o
bandă magnetică pe partea din spate. Banda magnetică este folosită pentru a
reţine un cod special, care este citit de un cititor de carduri. În cazul în care
codul este corect, mecanismul de închidere se pune în funcţiune şi permite
intrarea.
Încuietorile electronice oferă avantaje faţă de încuietorile manuale, deoarece acestea:
 pot fi setate pentru a identifica persoanele şi a înregistra mişcările lor;
 restricţionează accesul la anumite zone ale organizaţiei în funcţie de
necesitatea utilizatorului (sau ora din zi);
 pot fi dificil de reprodus, mai ales dacă sunt de tip Smart Card cu un
microcip încorporat;
 pot fi uşor de controlat de la o consolă centrală, de ex. în cazul în care
un angajat pleacă, e nevoie de doar câteva secunde pentru a anula
dreptul de acces al acelui utilizator; şi
 pot fi conectate la sistemele de alarmă silenţioasă, care activează într-
o cameră de control atunci când se încearcă accesul persoanelor
neautorizate.
o încuietori biometrice: aceste încuietori sunt programate să recunoască
caracteristicile biometrice ale utilizatorilor autorizaţi. Caracteristicile
biometrice care pot fi utilizate includ amprenta palmei, modelul vocii,
amprentele digitale, scanarea retinei sau o semnătură. Sistemele biometrice
tind să fie mai scumpe si sunt de obicei utilizate numai în unităţile informatice
foarte sensibile.

Alte controale fizice includ:

• camere video: camerele video pot fi situate în puncte strategice pentru a

monitoriza şi înregistra intrarea şi ieşirea. În cazul în care camerele video sunt
monitorizate 24 de ore pe zi, ele pot acţiona ca un control preventiv. De
asemenea, ele pot reprezenta un control detectiv, prin aceea că oferă un jurnal
vizual;

66
 • agenţi de securitate: agenţii de securitate pot fi dispuşi la intrările în sediul
clientului. Ei pot fi folosiţi pentru a verifica identitatea tuturor celor care intră în
sediu. De asemenea, pot fi utilizaţi pentru a efectua patrule în afara orelor de
lucru;

• garduri în jurul perimetrului: înconjoară instalaţiile informatice;

• alarme împotriva hoţilor: acestea pot fi utile pentru a monitoriza punctele de

intrare inactive, cum ar fi ieşirile de incendiu, sau atunci când instalaţiile sunt
nesupravegheate;

• controlul angajaţilor în afara programului: pentru cei mai mulţi clienţi aceasta
include personalul de întreţinere, agenţii de securitate şi sub-contractanţii. Nu
este neobişnuit să găsim că clienţii au un control puternic asupra mişcărilor
personalului, dar un control slab asupra furnizorilor de servicii în afara
programului de lucru. De exemplu, un agent de securitate poate avea acces la cele
mai multe părţi ale sediului clientului şi, de asemenea, poate să vină şi să iasă în
afara programului de lucru, fără a fi supus procedurilor normale de securitate. Au
fost multe cazuri în care personalul de serviciu nu erau doar personal de serviciu,
ci aveau o altă ordine de zi (de ex. de a culege informaţii pentru presă, spionaj,
furt);

• uşi securizate: uşile securizate pot fi găsite la intrările în zone sensibile, cum ar
fi sala cu calculatoare. Ele constau din două uşi, dintre care numai una poate fi
deschisă în orice moment. Ele sunt utile în a împiedica persoanele neautorizate să
urmeze o persoană autorizată în incintă, adică ajută la prevenirea “luării în
spinare”. Alte controale similare cu uşile securizate sunt uşile rotative şi tuburile
pentru o persoană;

• încuietori informatice: unele mărci de calculatoare au încuietori incluse, care

blochează tastatura sau mecanismul de pornire/oprire al computerului pentru a
preveni accesul neautorizat. Problema cu acest control este că utilizatorii pierd în
mod frecvent cheile sau le lasă în încuietori tot timpul;

În cazul în care a fost identificat un risc ridicat de furt de calculatoare sau vandalism, există
mai multe controale pe care clientul le poate lua în considerare;

• dulapuri de securitate: odată cu creşterea furtului de cipuri, furnizorii de

produse de securitate produc dulapuri de securitate din metal. Acestea constau
din carcase de metal, care pot fi ataşate la o suprafaţă solidă. Computerul este apoi
blocat în carcasa de metal. Acest lucru face mai dificilă deschiderea computerului
şi scoaterea cipurilor;

• apă inteligentă: aceasta constă din apă cu o semnătură chimică unică. Atunci
când sediul clientului este forţat, se activează un sistem de detectare a intruşilor
care pulverizează apă "inteligentă" prin duzele de la nivelul plafonului. Toate
persoanele (hoţi, etc.) şi echipamentele care vin în contact cu apa pot fi apoi
urmărite până la locul infracţiunii;

67
 • "ecrane de ceaţă": aceste dispozitive se activează atunci când este detectat un
intrus şi pulverizează aburi în cameră, care creează o ceaţă deasă. Acest lucru
reduce vizibilitatea, în măsura în care este foarte dificil pentru un infractor să vadă
ceea ce face.

10.3.4.3. Controale de mediu

Prevenirea, detectarea şi înlăturarea incendiilor:

Aceste sisteme sunt proiectate pentru a preveni izbucnirea unui incendiu în primul rând, şi
în cazul când un incendiu se produce, asigură stingerea acestuia într-un mod eficient.

Controalele de prevenire a incendiilor pot include:

• construirea de echipamente IT rezistente la foc, prin utilizarea materialelor de
construcţii rezistente la foc;
• o politică anti-fumat în clădire sau în sala cu calculatoare;
• un birou cu calculatoare curat, în care nu se permite acumularea prafului şi
hârtiei;
• controalele de detectare a incendiilor pot include detectoare de fum şi de căldură.

Controalele de înlăturare a incendiului pot include:

• extinctoare portative de incendiu: trebuie acordată atenţie pentru a se asigura că

stingătorul este la îndemână. De exemplu, unele stingătoare sunt improprii pentru
incendiile electrice. Stingătoarele portabile cu dioxid de carbon sau halon sunt
adecvate pentru utilizare la incendii electrice. Stingătoare cu apă trebuie să fie
disponibile în sau lângă stocurile de consumabile de calculator, de ex. hârtie de
imprimantă şi papetărie;

• sisteme automate de stingere: Aceste sisteme se activează în mod automat atunci

când este detectat un incendiu. Ele produc în mod normal o alarmă sonoră atunci
când se activează şi încep o numărătoare inversă înainte ca stingătorul de
incendiu să intre în funcţiune. Sistemul ar trebui să împartă sediul în segmente
sau zone. Acest lucru permite sistemului să se activeze numai în acele zone în care
a izbucnit un incendiu. Sistemele de stingere a incendiilor folosesc adesea fie apă,
fie halon. Halonul este mai bun, deoarece nu deteriorează echipamentul ca apa, şi
este mai puţin periculos pentru sănătate decât stingătoarele cu dioxid de carbon.

Sistemul de înlăturare a incendiului trebuie întreţinut cu regularitate, pentru a se asigura că

este în stare de funcţionare corectă. De asemenea, sediul clientului trebuie inspectat de către
departamentul de pompieri sau de autorităţile competente.

Personalul trebuie să fie instruit pentru utilizarea corectă a echipamentului de stingere a

incendiului.

Protecţia împotriva daunelor produse de apă

Echipamentele informatice (şi în special energia electrică ce alimentează echipamente) nu

trebuie să aibă contact cu apa. Prin urmare, echipamentele informatice trebuie să fie în
primul rând situate într-un loc în care este puţin probabil ca echipamentul să intre în contact
cu apa, iar pe de altă parte, în cazul în care apa reuşeşte să intre în camere cu calculatoare,
prezenţa sa să fie detectată.
68
Apa poate intra într-o cameră cu calculatoare prin mai multe surse, inclusiv:
• inundaţii;
• acoperişuri cu scurgeri;
• ţevi sparte;
• chiuvete suprapline, grupuri sanitare;
• radiatoare cu scurgeri; şi
• condensare.

Din moment ce curgerea apei se face sub influenţa gravitaţiei, riscul de deteriorare din cauza
apei poate fi redus prin amplasarea echipamentelor informatice la o înălţime mai mare,
adică nu în subsol. Este normal ca instalaţiile informatice să fie situate la etajele trei-şase
ale clădirilor.

Detectoarele de apă trebuie amplasate sub pardoseli supraînălţate. Ele trebuie conectate
la alarme vizuale şi auditive.

Chiar şi în cazul în care instalaţiile informatice sunt situate deasupra nivelului solului, poate
încă exista un risc de deteriorare din cauza apei provenite din conducte sparte sau scurgere
de pe acoperişuri. Acoperişurile plate au reputaţia de a avea scurgeri.

Protecţia şi controlul alimentării cu energie

Preocupările principale ale auditorului se referă la impactul posibil al energiei electrice

asupra disponibilităţii sistemelor şi integrităţii datelor procesate.

Sistemele clientului trebuie să aibă introduse controale, pentru a reduce la minimum efectul
unei întreruperi de energie electrică sau abateri în furnizare (vârfuri sau căderi de tensiune).
Acest lucru este realizat în mod normal prin instalarea de:

• protecţii la supratensiuni electrice: tensiunea şi frecvenţa de reţea pot varia.

Echipamentele informatice pot fi sensibile la aceste variaţii şi trebuie protejate de
vârfuri şi căderi de tensiune şi variaţii de frecvenţă. Regulatoarele de tensiune
monitorizează energia electrică de intrare şi o reglează în conformitate cu
cerinţele de sistem. Protecţiile la supratensiune electrică sunt de obicei integrate
în dispozitive de alimentare neîntreruptibile;

• surse de alimentare neîntreruptibile (UPS) : acest echipament permite

continuitatea funcţionării calculatorului până la revenirea alimentării cu energie
electrică, generatorul de rezervă poate fi activat sau sistemul poate fi oprit într-o
manieră controlată.

Cerinţele UPS pot varia în funcţie de nevoile locale, de ex. frecvenţa şi durata întreruperilor
de energie electrică.

Controalele de putere suplimentare pot include:

• generatoare de rezervă: generatoarele de rezervă sunt utilizate în mod normal

atunci când întreruperea energiei electrice durează mai mult de câteva ore. Sunt
disponibile două tipuri de generator, diesel şi turbine cu gaz;

69
 • cablare alternativă de energie electrică: în unele cazuri clienţii pot simţi nevoia
de a-şi conecta instalaţiile informatice la două staţii de energie electrică, în
speranţa că o întrerupere la o sursă de alimentare nu o va afecta pe cealaltă.

Încălzirea, ventilaţia şi aerul condiţionat:

Multe dintre calculatoarele mai mari, mainframe-uri şi minicalculatoare, au nevoie de un

mediu controlat, în care să funcţioneze eficient. Acestea pot necesita controlul temperaturii,
umidităţii, sau a ambelor. Mainframe-urile pot genera o cantitate semnificativă de căldură,
iar fără o ventilaţie corespunzătoare există riscul defectării echipamentelor.

Acestea pot fi controlate prin exploatarea echipamentelor de aer condiţionat.

În cazul în care aerul condiţionat este important pentru funcţionarea în continuare a

echipamentelor informatice, auditorul trebuie să revizuiască procedurile şi contractele de
întreţinere ale clientului.

Întreţinerea şi gospodărirea

Clientul poate avea controale care să asigure că sistemele de calculatoare şi zonele în care
acestea se află sunt curate şi fără resturi (deşeuri de hârtie, praf, fum, etc.).

De asemenea, pot exista politici de interzicere a consumului de produse alimentare şi băuturi

în imediata apropiere a echipamentelor informatice. O ceaşcă de cafea răsturnată poate avea
un impact semnificativ asupra unui computer.

10.4. Controale de acces logic

10.4.1. Introducere
Zilele, când informaţiile erau scrise pe hârtie şi depozitate în dulapuri cu dosare,au rămas în
mare măsură în trecutul îndepărtat şi neclar. Astăzi, majoritatea sistemelor financiare
întâlnite de către auditori vor fi informatizate.

Clienţii se bazează pe sistemele lor informatice pentru a iniţia, înregistra şi raporta

tranzacţiile financiare. Următorul aspect luat în considerare este modul de protejare a
datelor şi a resurselor instituţiei.

Sistemele informatice sunt de aşa natură încât să nu poată fi uşor controlate prin controale
cu acces fizic, cum ar fi dulapuri închise. Acest lucru este adevărat îndeosebi atunci când
calculatoarele unui client sunt conectate la reţele locale sau extinse.

Spre exemplu

Un sistem financiar este conectat la o reţea extinsă utilizând linii de comunicare telefonică,
cum ar fi modemurile dial-up. Încuietorile de la uşi, alarmele, agenţii de pază, etc., nu vor fi
capabile să oprească pe cineva să acceseze sistemul informatic prin reţea. Este necesară o
altă metodă de protecţie a sistemelor şi a datelor pe care acestea le procesează. Aici intră în
joc controalele de acces logic.

Controalele de acces logice sunt definite ca fiind:

70
“un sistem de măsuri şi proceduri, atât în cadrul unei organizaţii cât şi în programele
informatice, care vizează protejarea resurselor informatice (date, programe şi terminale)
împotriva tentativelor de acces neautorizat.”

Există trei elemente de bază pentru securitatea accesului logic:

a.) Identificarea utilizatorului

Acest lucru implică în mod normal un utilizator care se identifică la calculator cu un nume
de utilizator sau ID de înregistrare, etc.

b.) Autentificarea utilizatorului

Calculatorul necesită confirmarea faptului că utilizatorul este cine spune că este. Acest lucru
este realizat prin ceva ce utilizatorul are sau ştie. Parolele sunt o formă obişnuită de
autentificare. Alte forme de autentificare includ codurile PIN (utilizate pentru autentificare
după introducerea cardului bancar într-un bancomat), o semnătură sau elementele
biometrice integrate, cum ar fi amprenta mâinii.

c.) Protecţia resurselor

Resursele sunt fişierele informatice, directoarele, dispozitivele periferice. Protecţia

resurselor se bazează pe nevoile fiecărui utilizator. De exemplu, când un utilizator se
conectează (identificat şi autentificat), calculatorul ştie cine este şi restricţionează accesul la
anumite fişiere, aplicaţii sau alte resurse, în funcţie de cerinţele de la locul de muncă.

Auditorul trebuie să aibă în vedere faptul că unele sisteme de operare şi opţiunile de control
al accesului logic asociate, parametri de fişiere, etc. au natură foarte tehnică. În cazul în care
sistemele clientului sunt complexe din punct de vedere tehnic şi auditorul nu are cunoştinţe
privind sistemele specifice ale clientului, auditorul IT poate avea nevoie de suport şi
asistenţă suplimentară de la un auditor IT cu competenţele şi experienţa necesară.

Este puţin probabil ca un auditor IT extern să aibă o cunoaştere aprofundată despre mai mult
de câteva sisteme (de ex. cele mai întâlnite sisteme de operare, cum ar fi Unix, Novell şi
Windows NT).

Atunci când este însărcinat cu o revizuire în profunzime a controalelor de acces logic de pe

un sistem complex, auditorul IT poate avea nevoie de asistenţă suplimentară din partea unui
specialist în acel mediu de operare.

10.4.1.1. Riscul asociat cu controale de acces logic inadecvate

Principalele efecte care ar putea apărea în lipsa controalelor de acces logic sunt:
• divulgarea neautorizată;
• modificarea neautorizată, şi
• încălcarea integrităţii sistemului.

Posibilul impact al unei încălcări într-un control de acces logic este mai mare în cazul în care
calculatoarele sunt folosite pentru a iniţia, precum şi a înregistra tranzacţiile. În sistemele
manuale, personalul din finanţe era atent în folosirea cecurilor şi altor documente financiare.
În cazul în care un client are un sistem computerizat, se aplică aceleaşi principii iar clientul
trebuie să aibă controale pentru a împiedica persoanele neautorizate să obţină acces la
71
înregistrările şi documentele electronice financiare (de ex. un fişier de plată electronică,
înainte de transmiterea acestuia la bancă).

În cazul în care sistemele clientului sunt conectate la o reţea extinsă, cum ar fi Internetul,
atunci riscurile sunt chiar mai mari. Caracterul înregistrărilor electronice este de aşa natură
încât nu poate fi evident faptul că cineva a făcut o modificare neautorizată.

Acest lucru ar trebui să aducă în atenţie importanţa controalelor de acces logic pentru a
asigura integritatea, disponibilitatea şi confidenţialitatea sistemelor financiare ale clientului.

10.4.1.2. Atacatorii
Sistemele informatice pot fi atacate din mai multe direcţii. Atacatorul care ne vine primul în
minte este hacker-ul informatic.

Hackerii sunt în general persoane extrem de pregătite în domeniul informatic, care încearcă
să obţină acces la un sistem, din simplu motiv, pentru a dovedi că pot. Ei privesc această
acţiune ca pe o provocare personală. Cu toate că intenţia lor principală este doar accesul, pot
provoca din greşeală daune sistemelor sau datelor.

Angajaţi: aceştia pot fi personal din departamentul IT sau utilizatorii normali de sistem.
Auditorul trebuie să ia notă de controalele asupra personalului temporar şi personalului
angajat pe jumătate de normă.

Foştii angajaţi: foştii angajaţi, în special cei cu resentimente, pot încerca să acceseze
sistemul pentru a manifesta o anumită formă de răzbunare.

Părţi externe: pot include concurenţi, puteri străine (spionaj), crima organizată.

Furnizori şi consultanţi: Sunt adesea persoane care au introdus un sistem sau cei care îl
întreţin.

10.4.1.3. Consecinţele unei breşe în securitatea accesului logic

Opinie de audit cu menţiuni: În calitate de auditori externi, aceasta este preocuparea cea
mai evidentă. Rapoartele ar putea fi neauditabile din cauza pierderii pistei de audit financiar,
sau rapoartele pot conţine erori materiale datorită pierderii integrităţii datelor.

Pierderi financiare: Pierderile pot fi pierderi directe ca urmare a fraudei, sau pierderi
indirecte, care rezultă din costul de modificare a sistemului şi de corectare a datelor.

Obligaţiile legale: Clientul poate avea anumite obligaţii legale privind stocarea şi divulgarea
datelor, de ex. în cazul în care există o legislaţie care solicită clientului să păstreze
confidenţialitatea cu privire la orice date cu caracter personal. Într-un mediu bancar, o
pierdere de integritate ar putea duce la încălcarea reglementărilor bancare şi la măsuri
disciplinare.

Pierderea cotei de piaţă şi / sau credibilităţii: Acest lucru este important în special în
sectorul serviciilor financiare, de ex. bănci şi societăţi de investiţii şi titluri de valoare. O
breşă de securitate poate duce la o pierdere de credibilitate şi, eventual, la o pierdere în
afaceri.

72
Întreruperi ale activităţilor întreprinderii: de exemplu, în cazul în care un hacker a avut
acces la un sistem informatic şi a schimbat toate dimensiunile produsului într-un sistem
industrial de fabricaţie.

10.4.2. Resurse, fişiere şi instalaţii care necesită protecţie

10.4.2.1. Fişiere de date

Acestea pot consta în fişiere de tranzacţii sau baze de date. Orice fişiere care conţin fişiere
master sau informaţii de date permanente trebuie de asemenea protejate, de ex. fişiere care
conţin ratele de salarizare, codurile de cont bancar, parametri de sistem, etc. În cazul în care
nu sunt protejate, cineva ar putea aduce modificări neautorizate sau chiar şterge datele.

10.4.2.2. Aplicaţii
Accesul nerestricţionat creşte riscul ca aplicaţiile financiare să fie supuse unor modificări
neautorizate care duc la fraudă, pierderi şi denaturări de date. Accesul neautorizat la codul
sursă al unei aplicaţii ar putea fi folosit pentru a face modificări în logica de programare, de
ex. rotunjirea plăţilor către cea mai apropiată unitate (bănuţi, cenţi, etc.) şi introducerea
fracţiunii rotunjite în contul de rambursare a cheltuielilor programatorului.

În cazul în care un sistem efectuează calcule complexe, ar putea fi imposibilă verificarea în

mod independent a calculelor aplicaţiei şi modificările neautorizate pot rămâne nedetectate
pentru o perioadă considerabilă de timp.

10.4.2.3. Fişiere cu parole

Dacă aceste fişiere nu sunt protejate în mod adecvat şi oricine le poate vizualiza, ar fi greu
de oprit o persoană neautorizată să obţină datele de identificare şi parola unui utilizator
privilegiat al sistemului. Orice utilizator neautorizat care a obţinut permisiunea de acces a
unui utilizator privilegiat al sistemului ar putea produce pagube considerabile.

Chiar şi în cazul în care datele de identificare şi parola unui utilizator normal sunt obţinute,
principiul prin care utilizatorii sunt traşi la răspundere pentru acţiunile lor este ocolit.
Utilizatorul neautorizat ar putea folosi identificarea "furată" pentru a aduce modificări care
nu pot fi urmărite până la agresor.

10.4.2.4. Programe informatice şi instrumente de sistem (system tools)

Acestea constau din programe informatice, cum ar fi editoare, compilatoare, depanatoare de
programe. Accesul la acestea trebuie limitat, deoarece aceste instrumente ar putea fi utilizate
pentru a face modificări în fişierele de date şi programele informatice aplicative.

73
 10.4.2.5. Fişiere jurnal
Fişierele jurnal sunt utilizate pentru a înregistra acţiunile utilizatorilor şi, prin urmare, oferă
administratorilor de sistem şi conducerii clientului o formă de responsabilitate. Un jurnal de
sistem poate înregistra cine s-a autentificat în sistem şi ce aplicaţii, fişiere de date sau
instrumente a folosit în acest timp. Un jurnal de aplicaţie poate fi folosit pentru a înregistra
modificări aduse datelor financiare (cine ce date a schimbat, de la ce la ce, şi când). Dacă
fişierele jurnal sunt insuficient protejate, un hacker, o persoană necinstită, etc. le-ar putea
şterge sau edita pentru a-şi ascunde acţiunile.

10.4.2.6. Fişierele gata pentru imprimare şi cele temporare

Fişierele gata pentru imprimare şi cele temporare pot fi utilizate pentru a stoca informaţii
înainte de a se acţiona asupra lor. De exemplu, atunci când un utilizator iniţiază tipărirea
unui cec, este creat un fişier temporar care conţine detalii despre cec. Acest fişier este utilizat
pentru tipărirea cecului atunci când imprimanta este pregătită. Fără protecţie adecvată,
cineva ar putea edita fişierul şi modifica detaliile plăţii, înainte ca ele să fie transmise
imprimantei.

10.4.3. Cadrul de securitate a accesului

Este responsabilitatea conducerii clientului să se asigure că există controale adecvate pentru
a aborda orice riscuri identificate ale sistemelor. Conducerea trebuie să stabilească ce
controale de acces logic trebuie să fie introduse, în primul rând prin stabilirea unei politici
corporative de securitate a accesului.

În elaborarea unei politici, conducerea trebuie să stabilească cerinţele întreprinderii pentru

controlul accesului şi să stabilească cerinţele de acces pentru fiecare sistem.

Politicile de securitate ale companiei sunt în mod normal documente relativ scurte. Ele pot
să conţină:
• definiţii: de ex. ce se înţelege prin securitate şi în mod special termenii de
confidenţialitate, integritate şi disponibilitate;
• declaraţii de securitate de ex.
o fiecare sistem şi fişierele conexe trebuie să aibă un proprietar şi trebuie să fie
clasificate în funcţie de importanţa confidenţialităţii, integrităţii şi
disponibilităţii;
o accesul la informaţiile conţinute în sisteme va fi acordat numai pe baza
necesităţii de a le cunoaşte. Necesitatea de cunoaştere va depinde de funcţia
(rolurile, responsabilităţile şi îndatoririle) fiecărui utilizator de sistem şi
funcţia sistemului informatic; şi
o nivelul de protecţie va fi proporţional cu nivelul de risc şi valoarea activului;
• responsabilităţi: trebui să fie definite responsabilităţile tuturor utilizatorilor.
Acest lucru se face în mod normal prin gruparea utilizatorilor în "utilizatori
normali", proprietarul sistemului, managementul de securitate şi auditul
sistemelor informatice / IT.

Detaliile controalelor de acces logic se vor baza pe declaraţiile la nivel înalt din cadrul
politicii corporative de securitate IT.

74
 10.4.4. Sistemul de operare şi controalele de acces la aplicaţii
Controalele de acces logic pot exista de obicei, în sistemele financiare, pe două niveluri,
nivelul de instalare şi nivelul aplicaţiei. Prin urmare, controalele de acces pot fi incluse în:
• sistemul de operare (sau instrumente încorporate) şi/ sau
• fiecare aplicaţie.

Controalele de acces logic la fiecare nivel sunt în mod normal controlate de către diferiţi
administratori. Cineva din unitatea IT va fi responsabil pentru persoanele care se pot conecta
în reţea şi, odată ce acestea sunt conectate, pentru aplicaţiile şi fişierele de date la care pot
avea acces. Această persoană controlează accesul la nivel de instalare.

Un administrator separat de aplicaţie va fi responsabil pentru administrarea drepturilor

utilizatorilor în fiecare aplicaţie.

Administratorul de sistem din unitatea IT va înţelege mai bine sistemul de operare şi

resursele sale şi va şti ce aplicaţii şi instrumente importante de sistem trebuie să fie
protejate. Acest lucru va permite protecţia resurselor sistemului faţă de intruşi, precum şi
faţă de personalul IT neautorizat.

Administratorul aplicaţiei va cunoaşte mai bine aplicaţiile şi persoanele care le utilizează.

Această înţelegere a aplicaţiei va permite administratorului de aplicaţie să modifice
privilegiile de acces în funcţie de nevoile fiecărui utilizator. De exemplu, cineva cu cunoştinţe
în domeniul financiar va şti ce activităţi sunt necesare fiecărui membru al personalului
pentru a-şi îndeplini sarcinile în mod eficient. Acest lucru ar asigura faptul că utilizatorii au
acces doar la funcţii din cadrul aplicaţiei de care au nevoie pentru locul lor de muncă, de ex.
administratorul aplicaţiei va şti că un operator de achiziţii nu va avea nevoie de acces la
sistemul de vânzări, astfel că accesul la acest sistem nu va fi permis.

Această abordare se adaugă controlului, prin faptul că îndatoririle de securitate a accesului

sunt separate între administratorul de sistem şi administratorul de aplicaţie.

10.4.5. Controalele de acces logic la nivel de instalare

Controalele de acces logic sunt adesea incluse de către producător în programul informativ
al sistemului de operare (Unix, Novell, NT). Soliditatea controalelor de acces variază de la un
produs la altul. Există câteva organizaţii care desfăşoară testări independente ale
caracteristicilor de securitate în cadrul sistemelor de operare.

În cazul în care sistemele de operare nu au securitate de acces logic încorporată, clientului i

se poate instala un pachet separat. De exemplu este normal ca utilizatorilor de calculatoare
mainframe IBM să li se instaleze pachete de control al accesului precum RACF sau ACF2. De
asemenea, există pachete de securitate potrivite disponibile pentru microcalculatoare.

10.4.5.1. Gestiunea conturilor

Organizaţia trebuie să aibă o politică sistematică pentru gestionarea conturilor sistemului
informatic, inclusiv stabilirea, activarea, modificarea, revizuirea, dezactivarea şi ştergerea
conturilor. Acest lucru va cuprinde în mare următoarele activităţi:
• Identificarea tipurilor de conturi (individuale / de grup / de sistem), precum şi
stabilirea condiţiilor de membru al grupului.
• Specificarea drepturilor / privilegiilor de acces pe baza nevoii de cunoaştere;
75
 • Proceduri de identificare a cererilor pentru stabilirea de conturi, şi aprobarea de
astfel de conturi;
• Monitorizarea conturilor de vizitatori / anonime, precum şi dezactivarea
conturilor inutile;
• Notificarea managerilor de cont privind schimbarea statutului utilizatorilor
sistemului informatic (transfer / încetare, etc.)

10.4.5.2. Proceduri de conectare la sistem

Procedurile de conectare la terminal sunt folosite pentru a obţine acces la date şi aplicaţii în
sistemele informatice. Atunci când utilizatorul cere acces la sistem, se activează procesul de
conectare (de ex. prin simpla pornire, făcând clic pe o pictogramă, tastând o comandă de
conectare). Acest lucru iniţiază un mesaj de conectare. Procedurile de conectare conduc
utilizatorii prin paşii pe care trebuie să-i facă pentru a se identifica şi a-şi autentifica
identitatea către calculator. Acest lucru implică de obicei introducerea de către utilizatori a
ID-ului de conectare, urmat de o parolă.

Procedurile de conectare ar trebui să cuprindă următoarele controale:

• numele organizaţiei trebuie afişat doar după ce utilizatorul s-a conectat cu succes.
Aceasta limitează indiciile pe care sistemul le poate da unui utilizator neautorizat.
De exemplu, în cazul în care o organizaţie naţională de cercetare spaţială a afişat
un mesaj de conectare cu numele organizaţiei, un utilizator neautorizat ar avea un
indiciu atunci când încearcă să ghicească parolele. Acesta ar încerca parole
precum nebuloasă, quasar, solar, etc.;

• conectarea nu trebuie să ureze "bun venit" nimănui. Există un caz celebru prin
care un hacker a avut acces la un sistem informatic care avea un ecran de bun
venit. Hacker-ul a scăpat de urmărirea penală, deoarece ecranul de bun venit
a fost considerat a fi o invitaţie la încercarea de a accesa sistemul;

• mesajul de conectare nu trebuie să informeze utilizatorul despre succesul sau

eşecul său, până când întregul proces de autentificare s-a încheiat. Acest lucru
asigură faptul că un utilizator neautorizat nu este informat cu privire la cazul în
care ceva nu a mers bine;

• deconectare automată după un anumit număr de încercări de autentificare (3

încercări); şi

• orice instrumente de ajutor pe ecran trebuie dezactivate în timpul procesului de

conectare, pentru a asigura faptul că utilizatorii neautorizaţi nu primesc indicaţii
cu privire la accesarea sistemului.

După ce utilizatorii s-au conectat cu succes, sistemul poate fi capabil să afişeze ora şi data
ultimei conectări a utilizatorului, precum şi detalii cu privire la orice încercări nereuşite de
conectare. Acest lucru ar trebui să aducă la cunoştinţa utilizatorului orice tentative de acces.
De exemplu, dacă un utilizator se conectează la sistem dimineaţa şi apare un mesaj care
arată ultima autentificare la 04.30 a.m., el va şti că ceva nu este în regulă.

76
 10.4.5.3. Identificarea şi autentificarea utilizatorului
Identificarea utilizatorului este realizată în mod normal de către utilizatori, prin
introducerea unui identificator de conectare. Clientul trebuie să aibă o politică pentru
compunerea codurilor de identificare la conectare, de exemplu primele trei litere din numele
de familie ale utilizatorilor, iniţiala prenumelui şi un număr din două cifre.

De exemplu: Dl. James Smith are ID-ul de conectare SMIJ27.

Oricare ar fi politica pe care clientul decide să o adopte, aceasta trebuie să asigure că ID-urile
de conectare ale fiecărui utilizator sunt unice. Unicitatea este importantă, deoarece permite
identificarea fiecărei persoane. Aceasta, la rândul său, susţine responsabilitatea, în special în
cazul în care ID-urile autentificate de conectare ale utilizatorilor sunt înregistrate faţă de
activităţile pe care aceştia le exercită asupra sistemului.

Calculatorul trebuie să menţină o listă de ID-uri de conectare pentru toţi utilizatorii

autorizaţi.

Alte sisteme pot utiliza un simbol ca formă de identificare, de ex. un card cu o bandă
magnetică pe partea din spate.

10.4.5.4. Autentificarea
După ce un utilizator s-a identificat în sistemul informatic, calculatorul trebuie să confirme
faptul că această persoană este cine se pretinde a fi. Acest lucru este cunoscut sub numele de
autentificare.

Autentificarea se realizează de către utilizator prin a şti ceva, a poseda ceva sau dintr-o
comparaţie a caracteristicilor fizice. Factorii de autentificare pot fi în general clasificaţi în
trei categorii:
• Ceva caracteristic utilizatorului (de ex. amprenta digitală, structura retinei,
structura vocii, recunoaşterea semnăturii, etc.)
• Ceva ce utilizatorul posedă (de ex. buletin de identitate, simbol de securitate,
simbol software sau telefon mobil)
• Ceva ce utilizatorul ştie (de ex. parola, sintagma de control sau codul PIN)

10.4.5.4.1. Parole

Pentru a fi eficiente, controalele pe bază de parolă trebuie să ia în considerare:

• structura parolei: Politica clientului privind parolele ar trebui să interzică

introducerea unor parole care se bazează pe:
o nume de familie, adrese, iniţiale (inclusiv animale de companie);
o numere de înmatriculare ale autovehiculelor;
o numere de telefon;
o combinaţii uşor de ghicit, de ex. qwerty;
o caractere exclusiv alfanumerice sau numerice (cu cât sunt mai multe opţiuni,
cu atât o parolă este mai greu de ghicit);
o cuvinte din dicţionar (cuvintele wdin programele TV sunt obişnuite);
o ceea ce utilizatorii pot vedea de la fereastră. (Se întâlneşte frecvent ca
utilizatorii să utilizeze o parolă bazată pe ceva ce pot vedea de la biroul lor, de
ex. Compaq 486, sau numele staţiei PECO de peste drum).
77
 • lungimea minimă: cu cât sunt mai multe caractere, cu atât este mai greu de ghicit.
Cu toate acestea, cu cât mai lungă este o parolă, cu atât mai probabil este ca
utilizatorii să o uite. Un minim de 6 caractere este normal pentru sisteme
financiare;

• îmbătrânirea parolei: adică aceasta trebuie să expire după un anumit număr de

zile. (30 -60 zile este normal). În plus, unele sisteme nu permit utilizatorilor să-şi
schimbe parolele imediat după ce au făcut o schimbare. Ei trebuie să aştepte o
perioadă, de ex. 7 zile, înainte de a putea schimba parola din nou;

• istoricul parolei: unele sisteme de parole ţin o evidenţă a ultimelor câteva parole
şi împiedică utilizatorul să reutilizeze una veche. Acest lucru îi împiedică pe
utilizatori să reactiveze câteva dintre parolele lor favorite;

• secretul parolei: adică stipularea faptului că parolele nu trebuie niciodată să fie

scrise sau împărtăşite altor persoane. În plus, parolele nu trebuie să apară pe
ecran atunci când utilizatorii le introduc. Ecranul trebuie să afişeze o serie de stele
sau asteriscuri, de ex. ******;

• alocarea iniţială: trebuie să existe proceduri de alocare iniţială pentru adăugarea

de noi utilizatori în sistem. Parolele iniţiale sunt de obicei alocate de către
administratorul de sistem. În cazul în care sistemul permite utilizatorilor să-şi
schimbe parolele, aceştia ar trebui să o facă în cel mai scurt timp. Sistemul poate
fi capabil să forţeze utilizatorii să-şi schimbe parolele, de exemplu atunci când
administratorul de sistem adaugă un nou utilizator, viaţa parolei poate fi setată
astfel încât ea a expirat deja. Atunci când noul utilizator se conectează pentru
prima dată, sistemul îl anunţă că parola a expirat şi trebuie schimbată înainte ca
alte conectări să fie permise;

• criptarea parolei: parolele trebuie protejate pentru a preveni divulgarea

neautorizată. Criptarea este o metodă comună de protejare a datelor în fişierul de
parole. Dacă puteţi vedea o parolă necriptată, veţi fi în măsură să spuneţi care este
parola reală. Apoi o puteţi copia şi folosi la o dată ulterioară;

Unele sisteme aplică un algoritm pentru parola utilizatorului şi stochează rezultatul într-un
fişier de parole. Când acest utilizator se conectează, parola pe care o introduce este criptată
folosind aceleaşi algoritm şi comparată cu parola criptată din fişierul de parole. În cazul în
care acestea se potrivesc, accesul este permis.

Alte sisteme stochează parolele criptate într-un fişier ascuns, care nu poate fi văzut de către
utilizatori. Acest lucru împiedică hackerii să obţină copii ale fişierelor de parole criptate şi
rularea de programe de tip "crack" pe acestea. Crack este un program Unix care criptează
cuvintele şi le compară cu parolele criptate. În cazul în care se obţin concordanţe, se va şti
care este parola:

• parole ale personalului care a plecat: atunci când angajaţii părăsesc

organizaţia, ID-urile şi parolele lor trebuie blocate. Aceasta reduce riscul ca un fost
angajat, care poate fi un nemulţumit, să aibă acces la calculatoare. Acest lucru
poate solicita clientului să instituie proceduri prin care administratorul IT este
informat cu privire la concedierea personalului. Este normal în mod rezonabil ca

78
 acesta să fie ultimul care ştie că un membru al personalului a fost sancţionat, dar
cazurile când “nimeni nu ne-a spus să-i eliminăm autentificarea!" ar trebui să fie
evitate;

• parole implicite şi pentru furnizori: atunci când sunt instalate noi sisteme, în
mod normal acestea au conturi de utilizator stabilite pentru inginerii care le
instalează, furnizori şi consultanţi. Aceste conturi au în mod normal niveluri
ridicate de acces şi privilegiu. Ele trebuie să fie strict controlate, şi dezactivate
dacă este necesar. De exemplu, pachete de contabilitate pot avea un cont de
utilizator standard, pentru a permite testarea sistemului. Acest cont poate avea
ID-ul "test", precum şi o parolă asociată "test";

• orientarea utilizatorului, proceduri şi conştientizare: utilizatorii trebuie să

cunoască care sunt politicile privind parolele. De exemplu, urmează să
conştientizeze că parolele nu trebuie spuse sau scrise. Procedurile scrise pot fi
benefice pentru utilizatori, deoarece acestea vor reduce probabilitatea ca
utilizatorii să comită greşeli atunci când îşi schimbă parolele, etc.

10.4.5.4.2. Autentificare multifactor

Din punct de vedere istoric, majoritatea sistemelor de control al accesului autentifică

utilizatorul prin solicitarea introducerii unei parole. Cu toate acestea, odată cu creşterea
conectivităţii la Internet şi riscurile sale inerente, o autentificare sigură implică utilizarea de
metode multiple de autentificare pentru a asigura o autentificare mai fiabilă a identităţii. De
exemplu, Guvernul SUA defineşte patru nivele de autentificare, de la nivelul 1 la 4, nivelul 1
oferind cea mai redusă asigurare, iar nivelul 4 cea mai ridicată:

Nivelul 1 - Acesta oferă asigurarea că acelaşi solicitant accesează datele protejate ale
tranzacţiei. Nu necesită "demonstrarea identităţii", nici nu sunt necesare metode
criptografice. Deoarece parole necriptate sau secrete nu sunt transmise printr-o reţea de
nivelul 1, sunt permise protocoalele simple de parole chemare-răspuns.

Nivelul 2 - Acesta oferă autentificare de la distanţă într-o reţea printr-un singur factor cu
solicitarea verificării identităţii. Autentificarea cu succes impune ca solicitantul să
demonstreze, printr-un protocol de autentificare sigur, că el controlează simbolul de
autentificare.

Nivelul 3 - Acesta oferă autentificare de la distanţă într-o reţea, prin mai mulţi factori, cu un
minim de doi factori de autentificare, precum şi proba implicită de posesie a unei chei sau
unei parole de un singur uz, printr-un protocol criptografic. Autentificarea cu succes
presupune ca solicitantul să demonstreze printr-un protocol securizat de autentificare că el
controlează simbolul, şi trebuie mai întâi să deblocheze simbolul printr-o parolă sau date
biometrice, sau trebuie să utilizeze şi o parolă în protocolul de autentificare securizat, pentru
a stabili o autentificare cu doi factori.

Nivelul 4 - Acesta oferă cea mai înaltă asigurare practică de autentificare de la distanţă în
reţea şi este similar cu nivelul 3, cu excepţia faptului că doar simbolurile criptografice "grele"
sunt permise.

79
 10.4.5.5. Protecţia resurselor
A avea acces la un calculator şi a fi capabil de conectare nu implică faptul că un utilizator
poate avea acces nelimitat la toate aplicaţiile şi fişierele de date. Un nivel suplimentar de
control este necesar pentru a restricţiona utilizatorii numai la acele aplicaţii, fişiere de date
sau resurse de sistem (de ex. imprimante pentru facturi, imprimante pentru cecuri, unităţi
cu bandă pentru copiere), pentru care le-a fost acordate acces specific.

Controalele de meniu pot fi utilizate pentru a restricţiona accesul anumitor utilizatori.

Restricţiile de meniu pot fi folosite pentru a asigura că numai acei utilizatori care trebuie să
aibă acces la o anumită aplicaţie sau fişier de date au un astfel de acces. Controalele de meniu
pot fi prezente în cadrul sistemului de operare, programelor-instrumente (program tools)
sau aplicaţiilor.

De exemplu, atunci când un operator de vânzări se conectează, îi va fi prezentat un meniu de

aplicaţii privind sistemul. Opţiunile ar putea fi după cum urmează:
• Sistemul de vânzări;
• Sistemul de achiziţii;
• Sistemul de stocuri;
• Sistemul de personal.

Administratorul de sistem poate seta sistemul astfel încât operatorul de vânzări are acces
doar la sistemul de vânzări, celelalte opţiuni de meniu, cum ar fi procesarea comenzilor de
achiziţii, de gestionare a stocurilor şi de personal ar fi "colorate în gri" şi, prin urmare,
indisponibile.

10.4.5.6. Securizarea fişierelor şi programelor

Accesul la funcţiile şi datele sistemului trebuie acordat numai utilizatorilor autorizaţi care
au nevoie de acces pentru a-şi îndeplini sarcinile. Natura acestui acces şi acestei utilizări
trebuie să fie în mod special autorizată de către conducere, luând în considerare
preocupările de integritate şi confidenţialitate. Clientul se poate baza pe proprietarii de
aplicaţii, care au acces aprobat la aplicaţii, înainte de acordarea accesului. Proprietarul
aplicaţiei este în mod normal utilizatorul mai vechi al unei aplicaţii, căruia i se acordă
responsabilitatea de a asigura faptul că aplicaţia continuă să îndeplinească obiectivele
instituţiei. De exemplu, proprietarul unei aplicaţii de contabilitate financiară este în mod
normal contabilul şef, proprietarul unui sistem de personal este în mod normal de managerul
de resurse umane. Aprobarea acestora trebuie cerută înainte ca orice noi utilizatori să poată
obţine acces la meniul din aplicaţiile lor.

Controalele pot include:

• autorizarea de a utiliza funcţii specifice (de ex. utilite (tools), elemente de meniu
şi programele lor de bază, etc.);

• capacitatea de a "conţine” utilizatori în grupul lor de funcţii autorizate, precum şi

de limitare a funcţiilor prin utilizator, timp şi resurse. Utilizatorii pot fi limitaţi la
anumite meniuri definite. Atunci când cineva se conectează la sistem, este plasat
automat într-un mediu controlat şi îi sunt prezentate opţiunile din meniu. Orice
tentativă de a accesa alte părţi ale sistemului (de ex. prompterul liniilor de
comenzi ale sistemului de operare, de exemplu, prin apăsarea tastei de ieşire), va
cauza deconectarea utilizatorului de la sistem;
80
 • refuzul prompterului sistemului de operare, de ex. pe un sistem DOS promptul C:
\, şi pe un sistem UNIX promptul $ sau #. Restricţionarea accesului ar trebui să
reducă riscul ca utilizatorul să încarce sau să ruleze aplicaţiile sau utilitele
neautorizate din sistem.

Permisiunile fişierelor: capacitatea de a restricţiona accesul la date, inclusiv diferenţierea

între întrebare şi actualizare sau modificare de date. Fiecărei resurse din sistem i se pot
atribui privilegii de acces. Atunci când un utilizator încearcă să acceseze o resursă, i se
compară permisiunea cu permisiunile fişierului. În cazul în care utilizatorul are acces la
nivelul de privilegiu, poate utiliza fişierul sau resursa.

Atributele normale privind fişierul/resursa sunt:

• citire;
• scriere;
• creare;
• actualizare;
• ştergere;
• executare; şi
• copiere.

În momentul revizuirii controalelor de permisiune la un fişier, auditorul trebuie să verifice

faptul că următoarele controale suplimentare sunt în funcţiune:
• asigurarea că permisiunile de acces sunt în concordanţă cu cerinţele autorizate şi
că accesul la o zonă sau la o funcţie nu eludează restricţiile autorizate în alta. De
ex., permisiunea de citire a unui director poate să nu ia în seamă permisiuni
specifice alocate fişierelor din acel director, şi
• restricţii speciale privind abilitatea de a adăuga, şterge sau modifica elementele
de meniu, programe sau instrumente.

Această capacitate este de obicei limitată la administratorul de sistem.

Permisiunile de acces trebuie să fie revizuite şi actualizate.

10.4.5.7. Alte controale de acces logic

Limitarea numărului de sesiuni simultane: Aceasta înseamnă că, atunci când un utilizator
este conectat la sistem, el nu poate merge la un alt terminal şi să se conecteze din nou.
Aceasta reduce riscul ca un utilizator neautorizat să obţină acces la sistem. În cazul în care
utilizatorul legitim este autentificat, impostorul nu poate avea acces. În cazul în care
impostorul este conectat şi utilizatorul legitim încearcă să obţină acces dar este împiedicat,
utilizatorul este informat cu privire la această problemă şi pot fi apoi luate măsuri corective.

Limite privind orele de muncă: unele sisteme de operare (de ex. Novell şi Windows NT),
pot restricţiona accesul utilizatorului la perioade de timp predefinite. De ex., în cazul în care
conducerea a crezut că nici un membru al departamentului financiar nu va avea nevoie de
acces la sistem în timpul nopţii (de ex. de la 9 seara la 6 dimineaţa), sistemul ar putea fi
configurat astfel încât aceştia să nu se poată conecta pe timpul acestor ore specificate.

Tentative restricţionate de înregistrare: Acest lucru implică setarea de limite privind

numărul de încercări nereuşite de introducere a parolei pe care un utilizator le are, înainte
ca posibilitatea de a se conecta să fie blocată. Stabilirea unei limite superioare cu privire la
81
numărul de încercări nereuşite reduce riscul ca cineva să ghicească parola. După ce se atinge
limita, un sistem poate bloca ID-ul unui utilizator pentru o perioadă stabilită, de ex. 30 de
minute, sau menţine ID-ul blocat până când este activat de administratorul de sistem.

Decuplarea automată a terminalului: terminalele nesupravegheate pot fi exploatate

pentru a obţine acces neautorizat la un sistem informatic. Unele sisteme pot fi configurate
pentru a deconecta utilizatorii după o perioadă stabilită, în cazul în care nu este detectată
nici o activitate a acestora. Alternativ, se poate activa un ecran economizor, care impune
utilizatorului să reintroducă parola de conectare pentru a elibera ecranul (de ex. Windows
95 şi Windows NT).

Acces specific la terminal: poate fi dezirabil să se restricţioneze accesul la anumite aplicaţii

de la anumite terminale. De exemplu, clientul ar putea dori să configureze un sistem astfel
încât accesul la o aplicaţie de salarizare să poată fi obţinut doar de la un terminal din
departamentul resurse umane.

10.4.6. Evidenţa jurnalelor

Controalele menţionate până în prezent au fost de natură preventivă, adică sunt concepute
pentru a se asigura că persoanele neautorizate sunt împiedicate să obţină acces la sistemele
informatice. Următoarea linie de controale implică detectarea tentativelor şi activităţilor de
acces neautorizat. Acest fapt este atins în mod normal prin înregistrarea evenimentelor într-
un jurnal. Există două tipuri de jurnale folosite de obicei în sistemele informatice, jurnalul de
securitate şi jurnalul de tranzacţii. Jurnalul de securitate poate fi folosit pentru a înregistra o
mare varietate de informaţii cu privire la activităţile utilizatorilor.

Exemple de evenimente de securitate frecvent înregistrate:

• eşecuri de acces: atunci când utilizatorii au încercat fără succes să se conecteze
sau a fost făcută o încercare de a accesa un fişier sau director protejat; şi
• utilizarea utilitelor (instrumentelor) şi aplicaţiilor de sistem. Detaliile înregistrate
ar putea include aplicaţia care a fost accesată, de către cine şi când.

Auditorul trebuie să fie conştient de faptul că înregistrarea fiecărui eveniment de securitate

ar putea prelua o cantitate semnificativă de resurse ale sistemului şi poate duce la
degradarea sistemului. În plus, este puţin probabil ca clientul să petreacă timp pentru a
revizui imense fişiere de jurnal. Clientul trebuie să găsească un echilibru între activităţile
semnificative care sunt înregistrate şi importanţa sau sensibilitatea sistemelor.

Jurnalele trebuie protejate pentru a asigura că acestea nu pot fi supra-scrise sau şterse de
către cineva care încearcă să-şi acopere urmele.

În cazul în care o cantitate mare de date este înscrisă într-un fişier jurnal, clientul poate folosi
instrumente de selecţie a raportării, care scanează fişierele jurnal şi evidenţiază acele
evenimente care necesită o atenţie suplimentară.

Al doilea tip de jurnal, jurnalul de tranzacţii este utilizat pentru a înregistra derularea
tranzacţiilor, pe măsură ce acestea sunt prelucrate de către sistem.

82
10.5. Planul de Continuitate în Afaceri şi Planul de Recuperare în caz de Dezastru

10.5.1. Obiectivele de audit

Scopul elaborării şi implementării Planului de Continuitate în Afaceri (Business Continuity
Plan - BCP) şi Planului de Recuperare în caz de Dezastru (Disaster Recovery Plan - DRP) şi
controalelor aferente este de a asigura că organizaţia îşi va putea realiza misiunile şi nu-şi
va pierde capacităţile de procesare, recepţionare şi protecţie a datelor chiar şi în cazul de
stopare bruscă sau provocată de un dezastru (calamitate, factor necontrolat) care va aduce
la pierderea temporară sau totală a funcţionalităţii infrastructurii TI.

10.5.2. Zonele de risc

Absenţa unul BCP şi a unui DRP bine definite şi testate ar putea reprezenta următoarele
ameninţări majore la adresa existenţei înseşi a organizaţiei:
• Capacitatea organizaţiei de a-şi îndeplini misiunea după reluarea (repornirea)
funcţionalităţii;
• De a prelua şi proteja informaţia deţinută;
• De a menţine intacte toate activele organizaţiei după dezastru;
• De a începe operaţiunile în proporţii depline cît mai curînd posibil, de a
minimaliza pierderile de resurse financiare, umane şi active.

10.5.3. Proceduri de audit

O organizaţie cu sistemele computerizate ar trebui să aibă evaluate ameninţări la adresa
sistemului, vulnerabilitatea şi impactul pierderii de funcţionalitate care pot afecta
posibilitatea de atingere a obiectivelor organizaţionale. Trebuie puse în aplicaţie măsuri
adecvate, care ar reduce riscurile la un nivel acceptabil pentru conducerea organizaţiei.
Extinderea BCP şi DRP şi măsurile necesare realizării lor vor varia considerabil de la caz la
caz. Organizaţiile cu muţi angajaţi în domeniul TI, cu reţele de comunicaţii, echipamente şi
sisteme informaţionale complexe, necesită BCP şi DRP comprehensive, actualizate, testate şi
care includ „active în aşteptare” (ce pot fi lansate în orice moment cu funcţionalitate deplină)
în locaţii alternative. Organizaţiile cu infrastructuri TI simple, ce nu efectuează operaţiuni
critice, ar pute utiliza planuri mai simple.
BCP şi DRP trebuie să fie documentate adecvat, testate periodic şi actualizate regulat. Pentru
a determina dacă planurile vor funcţiona aşa cum este prevăzut, ar trebui să fie testate
periodic prin exerciţii de simulare a cazurilor de dezastru.
Importanţa de o documentaţie corespunzătoare este majoră în caz de dependenţă
semnificativă de careva persoane-cheie. Pierderea de persoane-cheie, poate afecta
capacitatea unei organizaţii de a relua operaţiunile într-un interval de timp rezonabil.
Copiile de rezervă (Back-UP) a SI, aplicaţiilor şi a tuturor datelor importante trebuie
efectuate în md regulat. Copiile de rezervă trebuie să aibă un caracter ciclic bine determinat,
utilizând o combinaţie a periodicităţii de efectuare. Copiile Back-Up trebuie păstrate
împreună cu DRP şi documentaţia de sistem, într-un loc bine protejat în afara sediului.
La analizarea BCP şi DRP auditorul TI trebuie să:
• evalueze BCP şi DRP pentru a determina cât sunt ele de adecvate, prin prisma
standardelor organizaţionale şi prevederile guvernamentale şi legislative,
• verifice dacă BCP şi DRP sunt efective pentru a asigura că capacităţile de procesare
a datelor vor putea fi reluate prompt după o întrerupere neplanificată, prin
revizuirea rezultatelor testărilor efectuate (dacă există astfel de teste) de către
organizaţie,

83
• evalueze dispozitivele de stocare din afara oficiului (unde se păstrează copiile de
rezervă), prin inspectarea localului şi echipamentului, dacă acestea sunt adecvate,
revizuind conţinutul, securitatea şi corespunderea controalelor fizice şi de mediu.
Poate fi constatat că chiar dacă copiile de rezervă sun efectuate regulat, ele nu au
fost testate prin recuperarea datelor sau nu a fost efectuată validarea lor,
• evalueze abilitatea organizaţiei de a reacţiona eficient în situaţii de urgenţă, prin
revizuirea procedurilor aferente, instruirea personalului şi rezultatele testării
acestora.

84
10.6. Controalele sistemelor orientate pe utilizator

10.6.1. Ce înseamnă sisteme orientate pe utilizator (End-User Computing)?

Termenul de Sisteme orientate pe Utilizator este un termen vag (imprecis). În esenţă, acesta
se referă la situaţiile în care utilizatorii dispun de instrumente de calculare inteligente pe
masa sa de lucru (şi anume, calculatoare cu capacităţi proprii de procesare CPU), împreună
cu aplicaţii care le permit să-şi elaboreze sisteme proprii de procesare şi raportare.

Sistemele orientate pe utilizator le permit utilizatorilor să deţină un control mai riguros

asupra procesării şi prezentării datelor proprii. În schimb, acestea reduc controlul exercitat
de unităţile TI centrale.

Există patru tipuri de Sisteme orientate pe Utilizator . Acesta sunt:

• Calculatoare personale 3;
• Generatoare de rapoarte şi software de extragere (extraction software) (de ex. SQL);
• Sisteme informaţionale pentru nivel executiv (executive information systems) (în
special de managementul superior); şi
• Instrumente de control, automatizare şi monitorizare a sistemului - (system
generation tools), de ex. instrumente CASE (Computer-aided software engineering 4)
şi limbajele de generaţia a patra.

10.6.2. Riscurile asociate cu sistemele orientate pe utilizator

De la început, dezvoltările (progresele) în mediul sistemelor orientate pe utilizator erau
necontrolate (nedirijate). Utilizatorii nu adoptă aceleaşi standarde sau practici de succes pe
care le aplică colegii săi din unităţile TI.

Acest mediu necontrolat poate determina, şi chiar, a dus la o irosire de timp, efort şi finanţe
pentru client. De asemenea, nedirijarea sistemelor orientate pe Utilizator a determinat unele
îngrijorări din partea auditorilor, în special în cazurile în care utilizatorii finali procesau
tranzacţii financiare.

Majoritatea problemelor şi riscurilor legate de Sistemele orientate pe utilizator au fost

determinate de absenţa istorică a controlului. Utilizatorii percep calculatoarele sale ca
teritoriu propriu asupra cărora ei deţin controlul şi pe care fac ce doresc. Acest fapt a dus la
apariţia unor riscuri specifice.

10.6.2.1. Elaborarea sistemelor

De regulă, departamentele TI dispun de oameni cu experienţă şi instruiţi în elaborarea
sistemelor informatice. Aceştia sunt instruiţi şi dispun de experienţă privind:

3 Utilizarea calculatoarele personale este cauza dezvoltării sistemelor orientate pe utilizator. În 1995 s-au
estimat a fi 120 mln. calculatoare compatibile PC IBM în toată lumea. Nu este departe timpul în care se va
considera normal ca toţi utilizatorii să posede un calculator personal pe masa sa de lucru. Calculatoarele
personale sunt utilizate în mare parte pentru automatizarea activităţii de birou (procesoare Word şi Excel),
interogarea bazei de date, activitatea prin email şi în grup. Acestea de asemenea sunt folosite pentru a accesa
sistemele informaţionale centrale, de ex. sistemul financiar.

4
este aplicarea ştiinţifică a unui set de instrumente şi metode la un sistem software care are menirea de a
transforma în produse de o înaltă calitate, lipsite de defecte şi uşoare de întreţinut.

85
 • standardele aplicate în elaborarea sistemelor;
• documentaţia necesară;
• ce instrumente trebuie incluse în noul sistem; şi
• testarea necesară pentru a asigura că sistemul exercită sarcinile şi acţiunile pentru
care este destinat.

Sistemele orientate pe Utilizator le-au permis utilizatorilor finali să-şi elaboreze aplicaţiile
proprii fără a recurge la asistenţa unităţilor TI centrale. Utilizatorii finali elaborându-şi
sistemele proprii o fac fără a avea competenţele şi instruirea relevantă.

Atunci când sistemele sunt elaborate fără a se baza pe standarde, de către persoane fără
experienţă sau instruire, desigur, apar probleme. De regulă, acestea presupun următoarele:

• sisteme nesigure care nu procesează datele după cum se intenţionează, de ex. cadrul
logic de bază al aplicaţiilor nu a fost bine-gândit sau codificat corect;

• sisteme care nu includ instrumente pentru asigurarea integrităţii, intrării, procesării

sau ieşirii datelor principale. De exemplu, sistemele de contabilitate financiară care
acceptă intrări duble (înregistrări repetate), rezultând în divergenţe în balanţele de
verificare;

• sisteme care nu sunt testate şi sunt imprevizibile. De exemplu, dacă sistemul nu este
testat pentru a se asigura că acesta poate opera cu intrările de date incorecte, acesta
(sistemul) poate să se oprească accidental să-şi îşi încetinească lucrul atunci când un
utilizator introduce asemenea date;

• sisteme nedocumentate. Acest fapt determină dificultăţi în menţinerea sistemului pe

un termen lung. Auditorii TI, deseori, se confruntă cu afirmaţii din partea clienţilor,
de genul, că aplicaţia a fost elaborată de către un angajat cinci ani in urmă şi după ce
această persoană a plecat nimeni nu a putut găsi nici o documentaţie / instrucţiuni
pentru a putea înţelege exact cum funcţionează aplicaţia;

• sistemele care au fost subiectul unor schimbări necontrolate. Utilizatorii finali au un

obicei de a pătrunde (investiga în profunzime) oriunde pentru a găsi o problemă în
aplicaţiile lor. Ei tind să nu respecte aceleaşi proceduri de control al schimbărilor
precum cele utilizate în unităţile TI. Acest fapt determină schimbări ce nu sunt bine-
gândite şi bine programate. Aceste schimbări pot exercita un impact prejudicios
asupra sistemului. De exemplu, un utilizator poate schimba o formulă într-un tabel,
şi fără a realiza acest fapt, acţiunea sa poate rezulta în efecte neplanificate în altă
parte;

• incompatibilitatea şi fragmentarea informaţiei: sistemele procurate de utilizatorii

finali pot fi incompatibile cu sistemele corporative. Acest fapt creează dificultăţi în
realizarea schimbului de date on-line. Datele în sistemele utilizatorilor finali ar putea
să nu fie actualizate şi să nu includă ultimele modificări în datele din sistemul central.

10.6.2.2. Dublarea efortului

Atunci când utilizatorii finali îşi asumă responsabilitatea pentru aplicaţiile proprii, aceştia
tind să nu se consulte cu restul organizaţiei şi rareori, îşi coordonează eforturile. Acest fapt
duce la dublarea eforturilor deoarece două părţi diferite ale organizaţiei încearcă să
elaboreze o aplicaţie orientată pe utilizator pentru a soluţiona aceeaşi problemă. Probleme
86
suplimentare apar şi atunci când dublarea este identificată şi nimeni nu doreşte să renunţe
la proiect. Alternativ, ambele pot fi dezvoltare, dublând efortul necesar pentru întreţinere şi
dezvoltare. Având în vedere că sistemele au fost elaborate de diferiţi utilizatori, este posibil
ca acestea să producă rezultate diferite pentru aceeaşi problemă.

10.6.2.3. Neconcordanţa datelor

De asemenea, datele unui departament pot veni în contradicţie cu datele altui departament.
În cazul ierarhiilor tradiţionale de management şi raportare, informaţia actualizată trebuie
distribuită iniţial la o ramură de management ierarhic superioară, înainte de a fi distribuită
la una ierarhic inferioară.

Neconcordanţele de date pot cauza probleme auditorului, dacă diferite părţi ale unei
organizaţii utilizează diferite date invariabile sau fişiere master în calculările sale, de ex.
ratele de plată pentru personalul subcontractat, sau unitatea de preţ pentru facturile de
comercializare.

10.6.2.4. Utilizarea sporită a resurselor şi costurilor

Experienţa a demonstrat că sistemele orientate pe utilizator au determinat sporirea
costurilor pentru majoritatea serviciilor TI ale organizaţiilor. Costurile înalte sunt
determinate nu doar de acordarea unui calculator personal pentru fiecare utilizator.
Costurile au crescut datorită cerinţelor înalte de instruire, cerinţelor înalte pentru serviciul
de suport/asistenţă în utilizarea calculatorului. De asemenea, există costuri ascunse precum
faptul că utilizatorii alocă mai mult timp încercând să soluţioneze propriile probleme de TI
şi cele ale colegilor săi.

Sistemele orientate pe utilizator au tendinţa de a fi mai puţin eficiente în utilizarea

resurselor, de ex. resurse de procesare, resursele de reţea şi imprimare. De exemplu,
generatoarele de rapoarte necesită o putere semnificativă de procesare, fapt ce ar putea
încetini restul activităţii sistemului. În unele organizaţii, utilizatorilor nu li se permite să
opereze cu rapoartele sale în timpul programului de lucru normal. Astfel, rapoartele trebuie
operate în timpul nopţii.

10.6.2.5. Ştergerea informaţiei centrale

Utilizatorii finali pot descărca datele dintr-un sistem central pentru examinare sau procesare
cu ajutorul aplicaţiilor proprii elaborate de utilizatorul final. Probleme ar putea apărea
atunci când fluxul de date este bidirecţional, ceea ce înseamnă, că după ce utilizatorul a
procesat datele, acestea sunt încărcate înapoi în sistemul central, înlocuind fişierele
originale. Acest fapt sporeşte riscul ca informaţia necesară pentru audit să fie înlocuită cu
informaţie incorectă. Adiţional, calea de verificare în audit poate fi eclipsată sau pierdută
atunci când utilizatorii înlocuiesc fişierele de date originale.

10.6.2.6. Conformitatea cu legislaţia

Dacă nu sunt determinaţi de departamentul TI central, probabilitatea ca utilizatorii finali să
cunoască legislaţia privind utilizarea calculatoarelor, păstrarea informaţiei personale,
confidenţialitatea(caracterul privat) sau dreptul de autor este mică.

87
Atunci când utilizatorii dispun de calculatoare personale la locul de muncă, există tentaţia de
a copia şi utiliza aplicaţii ilegale. Atitudinea că “nimeni nu va şti dacă utilizez această
aplicaţie” este comună printre utilizatorii.

Puţin probabil ca o organizaţie, sau chiar şi angajaţi individuali să scape de urmărire penală
recurgând la scuza că “Eu nu am ştiut ce stipulează legea, nimeni nu mi-a spus.”

10.6.2.7. Pierderile de date

Unităţile TI, de regulă, recunosc importanţa şi fac copii de rezervă a datelor cu regularitate
asigurând ca în caz de apariţie a unei probleme sau dezastru, sistemul să poată fi restabilit,
împreună cu datele. Din păcate, acest aspect nu este adevărat şi pentru mediul sistemelor
orientate pe utilizator 5.

O altă problemă legată de pierderile de date este creşterea cazurilor de furt de calculatoare.
Calculatoarele, şi în special calculatoarele personale de performanţă, sunt echipamente
valoroase. Valoarea lor înaltă le-a transformat în ţinta hoţilor de calculatoare. La furtul
calculatorului, în mod evident, se pierde şi toată informaţia de pe el.

Creşterea gradului de mobilitate(portabilitate) a sistemelor orientate pe utilizatori finali în

formă de laptop sau notebook a creat un nou risc. Portabilitatea lor inerentă sporeşte riscul
de pierdere sau furt a întregului calculator de ex., când calculatoarele sunt lăsate în
transportul public sau furate din camerele de hotel, cărucioarele pentru bagaj sau
aeroporturi.

10.6.2.8. Securitatea accesului logic şi fizic

Majoritatea calculatoarelor personale utilizează sisteme de operare Windows XP, Windows
Vista, Windows 7, Linux sau Mac. Aceste sisteme de operare sunt proiectate pentru
utilizatori unici şi în consecinţă, au puţine controale de acces logic pentru a restricţiona
accesul utilizatorilor neautorizaţi.

Este relativ uşor de a ocoli orice instrumente de securitate utilizate de aceste sisteme de
operare. Oricare persoană cu cunoştinţe suficiente despre sistemele de operare ar fi apt să
acceseze orice fişier de date sau aplicaţie dorită.

Accesul fizic la calculatoarele-staţii de lucru este, de regulă, mai puţin controlat. Data centrul
şi staţiile de lucru de tip „terminal” sunt, de regulă, localizate într-un mediu controlat cu
acces restricţionat de uşi încuiate, blocări prin combinaţii de taste şi camere video cu circuit
închis. Acelaşi lucru este rareori real, în cazul, computerelor utilizatorilor finali. De regulă,
acestea sunt localizate pe masă într-un mediu de oficiu normal.

Dispunând de acces fizic la computator, acesta poate fi exploatat pentru a ocoli instrumentele
de acces logic simple, de ex. parolele elementare ale utilizatorului de tip Windows. Datele pot
fi păstrate de asemenea şi pe Flash-Drive care poate fi uşor copiat. De asemenea, datele pot
fi redactate sau şterse de utilizatori neautorizaţi.

5
DEFINITIE????????????????????????????????????

88
 10.6.3. Viruşi de calculator
În realitate, viruşii de calculator sunt programe mici care sunt proiectate pentru a se replica
şi răspândi de la un calculator la altul anexându-se fie la un program, fişier sau sectorul de
încărcare (boot) a unui disc.

Viruşii de calculator se activează şi se copiază atunci când fişierul la care sunt ataşaţi este
operat sau atunci când calculatorul foloseşte un disc infectat. Odată activaţi, viruşii pot
rămâne activi în memoria calculatorului aşteptând să mai infecteze ceva.

10.6.4. Controalele sistemelor orientate pe utilizator

În cazurile în care organizaţiile utilizează pe larg Sisteme orientate pe utilizator, este foarte
probabil ca auditorul să constate că mediul de control general este slab. Acest fapt poate fi
determinat de insuficienţa de personal pentru distribuirea responsabilităţilor, lipsa de
instruire pentru utilizatorii de calculatoare, resurse neadecvate sau lipsa de angajament al
administraţiei în stabilirea standardelor şi instrumentelor corespunzătoare.

Lipsa inerentă de controale generale ar putea determina creşterea riscului de eroare şi

fraudă. În organizaţiile care utilizează sisteme orientate pe utilizator şi auditorului i se
solicită evaluarea posibilităţii de încredere în controalele existente. Astfel, urmează să fie
cercetate, mai curând, existenţa controalelor de management şi controalelor administrative,
decât controalele tehnice detaliate din componenţa calculatoarelor şi aplicaţiilor.

Una din principalele probleme cu care se confruntă clienţii la operarea cu controalele

sistemelor orientate pe utilizator este asigurarea ca tot personalul relevant să cunoască
politicile, standardele şi practicile de lucru necesare de adoptat. Această problemă poate fi
depăşită cu ajutorul unui program de instruire/educaţie comprehensiv pentru utilizatorii
sistemului. Informaţia poate fi distribuită printr-o combinaţie de buletine informative,
panouri informative şi instruire oficială.

10.6.4.1. Controalele proceselor de elaborare a sistemelor

Acestea ar putea include stabilirea politicilor şi standardelor de elaborare a sistemelor
pentru aplicaţiile elaborate de utilizator. Nivelul de oficializare ar putea depinde de criticismul
acestuia pentru afacere. De exemplu, atunci când aplicaţia este importantă, este necesară
oficializarea şi controlul riguros al elaborării acesteia. Pe de altă parte, în cazul în care
aplicaţia nu este importantă şi utilizată la nivel local doar de câţiva angajaţi, procesul de
elaborare ar putea să nu fie supus unui control riguros.

Standardele de elaborare ar trebui să asigure ca procesul de elaborare iniţial, şi schimbările

ulterioare la aplicaţiile importante să fie aprobate, documentate şi testate în mod
corespunzător.

Problemele asociate cu sistemele incompatibile pot fi reduse dacă clientul dispune de politici
şi proceduri pentru achiziţionarea echipamentului şi aplicaţiilor software. Politicile ar putea
include, de asemenea, proceduri pentru realizarea procurărilor de bunuri şi înregistrare a
locaţiei bunurilor într-un jurnal.

89
 10.6.4.2. Dublarea efortului
Utilizatorii vor dispune obligatoriu de un mecanism prin care aceştia ar avea posibilitatea de
a comunica eforturile sale celorlalţi angajaţi din organizaţie. Acest fapt poate fi realizat prin
organizarea unor şedinţe/întruniri regulate între nivelul mediu şi inferior de management.
Dezvoltările locale în sistemele TI ar putea fi una din subiectele de discuţie din agenda
şedinţei.

10.6.4.3. Neconcordanţa datelor

În cazul în care informaţia actualizată este importantă, clientul va dispune obligatoriu de un
sistem pentru a asigura ca toţi utilizatorii de date să dispună de o copie actualizată a acestora.
De regulă, această problemă este soluţionată prin stocarea datelor într-o bază de date
centrală. Aplicaţiile elaborate de utilizatorii finali ar putea utiliza, mai curând, informaţia din
baza de date decât să se bazeze pe informaţia neactualizată din fişierele de date locale.

De asemenea, clientul ar putea dispune de controale procedurale pentru a asigura utilizarea

a celei mai noi informaţii. De exemplu, s-ar putea crea o listă de control (check list) pentru a
determina utilizatorii să utilizeze informaţia cea mai recentă.

În situaţiile în care utilizatorii au acces la informaţia dintr-o bază de date centrală, este
necesar de a stabili permise de acces astfel încât doar persoanele autorizate să poată
actualiza datele centrale.

10.6.4.4. Legislaţia
Clientul va stabili obligatoriu politici pentru a asigura ca utilizatorii finali o să cunoască şi
acţioneze în conformitate cu legislaţia în vigoare. Programul de sensibilizare ar putea
acoperi următoarele:
• furtul de aplicaţii soft: ceea ce înseamnă, copierea neautorizată a unei software sau a
datelor organizaţiei pentru utilizare în scopuri de profit sau cu caracter personal;
• respectarea legislaţiei cu privire la securitatea la locul de lucru;
• utilizarea aplicaţiilor soft piratate şi ilegale; şi
• colectarea, utilizarea şi stocarea informaţiei cu caracter personal.

10.6.4.5. Pierderile de date

Atunci când aplicaţiile sau datele importante sunt păstrate/stocate pe calculatoarele
utilizatorilor finali, clientul va stabili obligatoriu controale pentru a asigura ca organizaţia să
nu fie prejudiciată de un dezastru care ar afecta calculatoarele în cauză.

Procedurile de control ar putea include următoarele:

• cerinţă ca utilizatorii să efectueze regulat copii de rezervă (back-up) a aplicaţiilor,

datelor şi documentaţiei sale şi să le stocheze/păstreze în locuri securizate (la cerere,
în exterior). Frecvenţa efectuării copiilor de rezervă va depinde de gradul de
importanţă a datelor, oportunitatea (timpul adecvat de utilizare) a datelor şi numărul
de tranzacţii procesate într-o perioadă dată; şi

• stocarea datelor pe un server de fişiere în loc de a o păstra pe discul local sau pe flash-
drive. Serverele vor fi, de regulă, administrate de către unitatea TI şi vor fi stabilite
obligatoriu proceduri de efectuare regulată a copiilor de rezervă pentru date.
90
 10.6.4.6. Acces logic şi fizic
Utilizatorii vor fi obligatoriu încurajaţi să adopte cel puţin măsurile de precauţie de bază
pentru asigurarea securităţii accesului logic pe calculatorul individual, de exemplu, stabilirea
unei parole pe BIOS.

Dacă este posibil, datele se vor stoca pe un server de reţea. În general, sistemele de operare
de reţea vor asigura gradul necesar de protecţie împotriva accesului neautorizat prin
intermediul reţelei.

În cazul în care utilizatorul foloseşte calculator portabil, este necesar de a stabili politici care
ar stipula păstrarea lor în mediu securizat în timpul nopţii, de ex. într-un sertar sau dulap
încuiat cu lacăt.

În cazul în care clientul consideră că riscul este mare, este necesar de a lua în considerare
opţiunea de instalare a aplicaţiilor soft de securizare pe calculatoarele utilizatorilor finali.
Acestea vor avea obligatoriu controale de acces logic mai robuste şi ar putea cripta datele
vulnerabile de importanţă înaltă.

10.6.4.7. Asistenţă/suport pentru utilizatorii finali

Sistemele orientate pe utilizator sunt în creştere şi probabil vor deveni mai semnificative în
viitor. Clientul trebuie să posede un cadru de servicii pentru a asigura suport utilizatorilor.

Asistenţa pentru utilizatorii finali este furnizată, de regulă, prin intermediul unei funcţii de
suport tehnic (help-desk). Serviciul de suport tehnic activează în calitate de interfaţă între
specialiştii din unitatea TI şi utilizatorii finali. Cererea de suport a utilizatorului va fi atribuită
specialistului TI cu competenţe şi cunoştinţe corespunzătoare în problema dată.

91
10.7. Controlul schimbărilor

10.7.1. Obiectivele de audit

Chiar şi atunci când procesul de dezvoltare a sistemului a fost finalizat, iar noul sistem este
acceptat, este probabil că acesta va trebui să fie schimbat, menţinut sau modificat în timpul
ciclului său de viaţă. Acest proces de schimbare poate avea un impact asupra controalelor
existente şi pot afecta funcţionalităţile care stau la baza sistemului. Dacă auditorul se bazează
în colectarea probelor (la orice nivel) pe sistem, este necesar de a efectua o analiză a
controalelor de schimbare. Controlul schimbărilor este necesar pentru a obţine o asigurare
că sistemele continuă să facă ceea ce ar trebui să facă şi controalele continuă să funcţioneze
aşa cum au fost prevăzute.

Se analizează schimbări referitoare cât la hardware atât şi la software. Hardware include

computere, periferice, comunicaţii şi infrastructura. Software-ul include atât software de
sistem (sistem de operare şi oricare alte instrumente) cât şi aplicaţii individuale.

Amploarea schimbărilor poate varia considerabil, de la ajustarea orei dintr-un sistem intern,
până la instalarea unei noi versiuni a aplicaţiei sau sistemului de operare. Efectul unei
schimbări asupra funcţionării sistemului poate fi de proporţii diferite cu mărimea sau nivelul
modificării efectuate.

10.7.2. Necesităţile de schimbări în sisteme

După implementarea sistemului, automat începe perioada de mentenanţă. Sistemele rareori
rămân neschimbate pentru mult timp. Începând cu prima zi de exploatare de producţie sunt
utilizatori nemulţumiţi, care vor solicita schimbări (RFC- request for changes) şi unele din
ele, cu timpul, vor fi efectuate.

Schimbările (modificările) pot fi necesare din mai multe motive:

• Pentru a spori funcţionalitatea sistemului: utilizatorii zilnici pot să nu fie
mulţumiţi cu modul în care funcţionează acesta. Aceste nemulţumiri ar putea fi din
cauza nesatisfacerii de interfaţa aplicaţiei, timpul de răspuns a sistemului, etc.
Totodată, pe parcursul exploatării, utilizatorii pot identifica anumite greşeli şi omiteri
în sistem care pot sluji ca motiv de producere a rezultate eronate.
• Pentru a face operarea sistemului mai uşoară şi mai eficientă: această categorie
include persoanele ce operează dispozitivele de stocare şi de înscriere pe bandă
magnetică; managementul serviciului de suport a utilizatorilor („Help desk”);
administratorii de baze de date; administratorii de reţea.
• Planificarea capacităţilor: sistemul poate necesita resurse suplimentare sau
creşterea capacităţilor a careva componente (ex: CPU mai productiv, spaţii de stocare
suplimentare, majorarea capacităţii canalelor de comunicare).
• Corectarea erorilor şi înlăturarea neajunsurilor: registrele incidentelor acumulate
de serviciul „Help desk” sunt sursa principală de informaţie: fiecare incident
înregistrat de serviciul „Help desk” contribuie la identificarea problemelor de bază.
Dacă problemele identificate sunt semnificative, serviciul „Help desk” trebuie să vină
cu o solicitare de efectuare a schimbărilor.
• Pentru îmbunătăţirea securităţii: personale TI responsabile de securitate:
identificarea punctelor slabe şi vulnerabilităţilor sistemului de securitate trebuie să
ducă la solicitări de schimbări pentru îmbunătăţirea securităţii.

92
 • Actualizarea de rutină: dezvoltatorii sistemului pot actualiza sau îmbunătăţi
aplicaţiile de sistem. Astfel de cazuri pot necesita schimbări în caz dacă furnizorul
insistă asupra necesităţii trecerii la versiuni noi.
• Modificări în cerinţe: schimbări ale legislaţiei, în cerinţele sau direcţiile de activitate,
pot rezulta în necesităţi de schimbări semnificative ale sistemelor.

10.7.3. Domeniile de risc

Controlul schimbărilor este conceput pentru a asigura că toate modificările operate asupra
sistemelor sunt autorizate, testate, documentate, dirijate şi sistemele funcţionează după cum
a fost preconizat şi că există o pistă de audit adecvată a modificărilor.
Riscurile asociate cu controale neadecvate ale schimbărilor pot fi identificate astfel:
• Schimbări neautorizate: schimbări accidentale sau deliberate dar neautorizate
efectuate sistemului. De exemplu, dacă nu există controale adecvate, programatorii
ar putea face modificări sau ajustări neautorizate direct în mediul de producţie.
• Probleme de implementare: de exemplu, o schimbare neplanificată care afectează
activitatea organizaţiei, cum ar fi schimbarea ratelor, coeficienţilor sau taxelor.
• Procesare sau raportare eronată: sisteme care nu funcţionează cum s-a preconizat.
Astfel de cazuri pod duce la plăţi greşite, rapoarte eronate, tranzacţii şi operaţii cu
conturi incorecte.
• Nemulţumirea utilizatorilor: utilizatorii nu sunt mulţumiţi de sistem: poate duce la
erori la introducerea datelor, probleme morale şi organizatorice cu angajaţii,
scăderea productivităţii, boicotarea lucrului.
• Dificultăţi în întreţinere: sisteme de calitate joasă, ale căror mentenanţă este
anevoioasă sau costisitoare (ex: din cauza documentării proaste). În astfel de cazuri
controalele neadecvate pot duce la situaţia în care au fost efectuate numeroase
modificări, dar nimeni nu ştie exact care versiune a sistemului sau a modulelor
acestuia sunt utilizate în mediul de producţie. Nimeni nu va cunoaşte care erori au
fost înlăturate sau care parametri au fost modificaţi în diversele versiuni.
• Utilizarea de hardware şi software neautorizat: sistemele (hardware şi software)
utilizate nu sunt neautorizate. Aceasta poate duce la incompatibilităţi între diferite
părţi ale sistemelor sau încălcarea drepturilor de autor şi a legislaţiei.
• Probleme cu schimbările de urgenţă: modificări necontrolate efectuate în cazuri
de urgenţă direct în mediul de producţie, pot duce la pierderi de date sau deteriorare
de fişiere.

10.7.4. Proceduri de audit

În efectuarea auditului, trebuie să ne asigurăm că procedurile organizaţiei privind controlul
schimbării includ:
• Proceduri de autorizarea a conducerii;
• Testarea completă şi detaliată a aplicaţiei modificate înainte de exploatarea ei în
mediul de producţie;
• Aplicaţia modificată poate fi transferată sau „transportată” în mediul de producţie
numai în urma autorizării de către conducere;
• Analizele, estimările managementului a efectului oricăror modificări;
• Întreţinerea înregistrărilor adecvate;
• Efectuarea procesului de revenire la versiunea precedentă (înainte de modificare), în
cazurile când este necesitate;
• Stabilirea procedurilor de efectuarea a schimbărilor de urgenţă.

93
Trebuie să existe proceduri de înregistrare a tuturor cererilor de schimbare (RFC), de
preferinţă într-un format standard şi / sau cu şabloane de prezentare. Cererile de modificare
ar trebui să fie autentificate şi să primească un număr unic de referinţă cronologică. Pentru
fiecare RFC-uri ar trebui să fie alocat un indice de prioritate pentru a indica urgenţa cu care
schimbarea ar trebui să fie luată în considerare sau operată. Sarcina atribuirii priorităţilor,
în mod normal, este prerogativa, unei comisii de gestionare a controlului schimbărilor din
cadrul comitetului coordonator al TI (dacă există astfel de structuri). Analizele şi deciziile
comisiei şi comitetului se fac cunoscute prin intermediul unei persoane, responsabile de
managementul schimbărilor.
Priorităţile modificărilor sunt determinate, reieşind din evaluarea costurilor şi
beneficiilor.

11. Controalele aplicaţiei

Controalele informatice se extind mai departe de mediul general TI. Este necesar de a verifica
şi controalele din cadrul aplicaţiilor individuale.

În trecut, când un auditor se confrunta cu un sistem manual, acesta verifica existenţa

controalelor manuale care asigura că tranzacţiile individuale au fost iniţiate, autorizate,
procesate cu acurateţe şi înregistrate manual în registrele contabile. Acelaşi lucru se
întâmplă şi atunci când clientul utilizează aplicaţii informatice, şi anume, auditorul va
examina obligatoriu, controalele în cadrul unei aplicaţii care asigură că tranzacţiile sunt
iniţiate, autorizate, procesate şi înregistrate corespunzător.

11.1. Tipuri de aplicaţie

De regulă, aplicaţiile sunt separate în categorii conform căii de introducere şi accesare a
datelor pentru utilizatori. Principalele categorii sunt:

11.1.1. Sisteme de introducere a datelor pe loturi (batch processing)

O metodă de operare în care tranzacţiile pentru o perioadă de timp sunt acumulate (pentru
o zi, săptămână, lună, etc.), după care sunt procesate printr-o singură lansare a procesului
respectiv. În cazul introducerii datelor pe loturi, utilizatorii nu interacţionează cu sistemul
atunci când datele sunt procesate (lucru care e posibil la procesarea on-line)

11.1.2. Sisteme ce operează în timp real (on-line processing)

Sistemele ce operează în timp real reprezintă una din cele mai recente dezvoltări în domeniul
aplicaţiilor informatice financiare. Utilizatorii pot introduce tranzacţia la staţia sa de lucru şi
vedea efectul imediat în bilanţurile contabile, ceea ce înseamnă că conturile sunt actualizate
ori de câte ori utilizatorul introduce o nouă tranzacţie. Sistemele în timp real permit
utilizatorilor să corecteze erorile imediat şi să sporească oportunitatea (timpul util)
informaţiei pentru management. Totodată, acestea nu includ controale tradiţionale precum
totalurile în loturi.

11.2. Utilizatorii, administratorii şi proprietarii aplicaţiei

De regulă, sunt trei tipuri de utilizatori ce ţin de aplicaţiile financiare.

11.2.1. Proprietarul aplicaţiei

În primul rând, există un proprietar al aplicaţiei. Proprietarii aplicaţiei sunt, de regulă,
utilizatorii de nivel superior. Aceştia sunt funcţionarii din nivelul superior de management
94
care utilizează sistemul în mod regulat. De exemplu, proprietarul aplicaţiei financiar-
contabile este, de regulă, contabilul-şef.

Proprietarul aplicaţiei, în realitate, are o responsabilitate generală asupra contribuţiei

strategice exercitată de sistem întru realizarea obiectivelor afacerii. De exemplu, managerul
pe finanţe responsabil de sistemul financiar-contabil are ca sarcină asigurarea faptului ca
tranzacţiile organizaţiei să fie înregistrate cu acurateţe şi complet, şi ca sistemul să producă
rezultatele(output) cerute, de ex. rapoarte de gestiune pe vânzări, cheltuieli în raport cu
bugetul, etc.

Auditorul va lua în consideraţie că conceptul unui proprietar de aplicaţie nu este întotdeauna

clar clientului. Prin urmare, atunci când auditorul doreşte să identifice cine este proprietarul,
ar fi necesar de a pune întrebări de genul “cine din Administraţie (managementul superior)
deţine responsabilitatea generală pentru a asigura că sistemul financiar-contabil operează
conform cerinţelor?”

Proprietarul aplicaţiei, de asemenea, are responsabilitatea de a asigura ca sistemul să fie

utilizat de persoanele corespunzătoare şi că acesta operează conform cerinţelor.
Proprietarul aplicaţiei este, de regulă, un funcţionar foarte ocupat şi deci, probabil nu are
suficient timp să urmărească şi să administreze sistemul zi cu zi.

Prin urmare, deseori, auditorul va identifica faptul că responsabilitatea de a administra

sistemul zi cu zi este delegată unui administrator de aplicaţie sau sistem.

11.2.2. Administratorul de aplicaţie

Acest funcţionar este subordonat unui proprietar de sistem. Sarcinile caracteristice ale unui
administrator de sistem includ următoarele:
• gestionarea listei de utilizatori autorizaţi ai aplicaţiei;
• adăugarea sau anularea utilizatorilor din profilurile de securitate ale aplicaţiei;
• a asigura că au fost efectuate copii de rezervă a datelor în conformitate cu politicile
de efectuare a copiilor de rezervă;
• soluţionarea cererilor din partea utilizatorilor aplicaţiei;
• identificarea, monitorizarea şi raportarea problemelor semnificative proprietarului
aplicaţiei şi unităţii TI;
• păstrarea şi distribuirea documentaţiei referitoare la aplicaţie; şi
• coordonare/cooperare: coordonarea cu unitatea TI asupra performanţei sistemului,
de ex. capacitatea de stocare, timpul de răspuns (response time). De asemenea,
administratorul ar coopera cu administratorii altor aplicaţii şi furnizorii de aplicaţii.

11.2.3. Utilizatorii ordinari ai sistemului

Aceştia sunt utilizatorii cotidieni ai aplicaţiei. Acestora li se acordă acces la unele părţi ale
sistemului de care necesită pentru aşi exercita sarcinile de lucru. Instruirea acestora privind
utilizarea sistemului se limitează la funcţiile necesare exercitării sarcinilor sale de lucru.

În esenţă, utilizatorii ordinari trebuie să se asigure că ştiu cum să utilizeze părţile sistemului
pentru care sunt autorizaţi. Aceştia cunosc foarte puţin despre responsabilităţile de
administrare a sistemului.

11.3. Definirea controalelor intrării, procesării & ieşirii datelor

95
Acest capitol descrie controalele aplicate, fie manual de utilizatorii aplicaţiei, fie automatizat
de sistemul informatic tranzacţiilor în cadrul unui sistem iformaţional.

Obiectivul de bază al unui sistem de control al oricărui sistem contabil este de a asigura
plenitudinea, acurateţea şi credibilitatea înregistrărilor contabile. Este necesar de reţinut
faptul că obiectivele controlului vor fi identice pentru toate sistemele contabile, de la
operaţiunile manuale simple la sistemele complexe de baze de date în timp real (complex
real-time database systems). Totodată, metodele de realizare a gradului de control vizat va
varia conform circumstanţelor individuale.

Indiferent dacă sistemul financiar este manual sau în baza unui sistem informatic, validitatea
înregistrărilor/intrărilor este asigurată cel mai bine prin metoda autorizaţiei.

Auditorul va acorda credibilitate mai mare autorizării ieşirii(output) dintr-un sistem decât
autorizării intrării(input), deoarece aceasta înseamnă mai curând autorizarea a ceea ce de
fapt a fost procesat decât autorizarea a ceea ce urmează a fi procesat.

Actele financiare sunt produsul unui sistem contabil şi obiectivele principale de control sunt
realizate dacă există proceduri de realizare a controlului plenitudinii şi acurateţei:

• intrării datelor în sistem: acest fapt presupune examinarea procedurilor şi

controalelor care asigură autorizarea, plenitudinea, nedublarea, acurateţea şi
oportunitatea(timpul util) intrării datelor;

• procesării datelor introduse: ceea ce înseamnă, controalele care asigură utilizarea

aplicaţiei şi fişierelor de date corecte, procesarea tuturor datelor, înregistrările
sunt conforme cu codurile conturilor contabile corecte şi actualizarea fişierelor
adecvate; şi

• ieşirii din sistem: şi anume, controalele care asigură producerea corespunzătoare

a tuturor ieşirilor, plenitudinea şi expedierea acestora la destinaţia corectă în timp
util.
Este responsabilitatea clientului de a asigura ca controalele aplicaţiei să fie
adecvate. În calitate de auditor TI, este responsabilitatea noastră să evidenţiem
clientului unde există puncte slabe.

Un aspect important este faptul că există costuri asociate cu implementarea controalelor.

Costurile pot fi definite în termeni de genul timpul acordat de personal, capacitatea şi
eficienţa procesării. Administraţia clientului va trebui să ia în considerare aceste costuri în
contextul riscului determinat de circumstanţele specifice ale sistemului şi clientului.

La examinarea controalelor intrării, procesării şi ieşirii datelor, auditorul va determina

obligatoriu dacă clientul a desfăşurat vreo evaluare a riscului pentru a determina dacă
controalele existente sunt adecvate şi cost-efective.

11.4. Controalele introducerii datelor (Input controls)

Controalele intrării (introducerii) datelor în sistem presupun examinarea procedurilor şi
controalelor care asigură autorizarea, plenitudinea, nedublarea, acurateţea şi oportunitatea
intrării datelor.
Controalele introducerii vor asigura ca:

96
 • toate tranzacţiile sunt introduse cu acurateţe;
• toate tranzacţiile sunt introduse;
• toate tranzacţiile sunt valide;
• toate tranzacţiile au fost autorizate;
• toate tranzacţiile au fost introduse în perioada contabilă corespunzătoare; şi
• toate tranzacţiile au fost înregistrate conform clasificaţiei.

Auditorul va lua în considerare faptul că controalele intrării se referă nu numai la simpla

intrare a datelor în sistemul informatic şi extragerea rapoartelor de partea cealaltă.
Auditorul va examina şi alte aspecte ale securităţii aplicaţiei, precum modul în care sistemul
restricţionează/limitează accesul doar utilizatorilor autorizaţi. De asemenea, auditorul va
examina obligatoriu controalele manuale sau administrative precum distribuirea
responsabilităţilor în cadrul departamentului finanţe al clientului, delegarea
responsabilităţilor, custodia: activelor, documentaţiei de intrare, registrele contabile pe
suport de hârtie şi rechizitele financiare.

În cazul în care clientul utilizează controale computerizate a intrării datelor, auditorul va

avea posibilitatea de a obţine asigurări la operarea acestora. Dacă auditorul decide să adopte
o abordare în auditare în baza controalelor, auditorul va testa obligatoriu controalele. În
acest caz auditorul va desfăşura o evaluare a: procesului de elaborare a sistemului;
programului de testare a sistemului şi rezultatelor acestuia; procedurile de control a
schimbărilor; şi controalele în operare.

11.4.1. Autorizarea introducerii datelor

Clientul va dispune de proceduri şi controale existente pentru a asigura ca toate tranzacţiile
să fie autorizate înainte de a fi introduse în sistemul informatic. Din punct de vedere a
auditorului extern, controalele autorizării reduc riscul tranzacţiilor frauduloase, sau
tranzacţiilor neregulate. Clientul, de asemenea, obţine un control mai bun asupra resurselor.

În mod tradiţional, sistemele manuale au utilizat o formă manuală de autorizare a tranzacţiei.

Chiar şi în cazul în care sistemele financiare sunt computerizate, mulţi clienţi utilizează
controalele manuale de autorizare precum semnătura sau iniţialele numelui funcţionarului
de nivelul corespunzător responsabilităţii delegate. Unele organizaţii pot utiliza o ştampilă
de autorizare în loc de semnătură.

Aplicaţiile financiare computerizate ar putea permite personalului clientului să introducă şi

să autorizeze tranzacţiile direct în sistem. Acest fapt poate fi realizat prin instituirea
controalelor accesului prin parole pentru echipamentul de intrare a datelor şi permisiuni
pentru intrarea datelor, de ex. monitorizarea/supravegherea intrării datelor.

Autorizarea tranzacţiilor de valoare redusă, de rutină uneori poate lua forma unei autorizări
invariabile, de ex. funcţionarul pe vânzări poate avea autorizare invariabilă (permanentă)
pentru introducerea tranzacţiilor ce ţin de cheltuielile de regie precum cheltuielile de
electricitate şi telefon până la o limită prestabilită.

De exemplu, un funcţionar financiar este responsabil de intrarea tranzacţiilor în sistemul

contabil. Permisiunile de acces pot fi stabilite astfel încât funcţionarul să poate introduce
detaliile tranzacţiei. Totodată, acesta nu poate autoriza tranzacţia deoarece nu dispune de
permisiune de acces de a completa/finaliza supravegherea autorizării datelor. Tranzacţia
este expediată electronic deţinătorului de buget care o aprobă pe monitor (aceştia pot
autoriza tranzacţiile deoarece ei dispun de permisiunile necesare).
97
Aplicaţiile financiare ar putea verifica dacă o tranzacţie a fost aprobată de către o persoană
cu nivel adecvat de autoritate prin verificarea numelui lor de identificare(ID) conform listei
prestabilite de aprobare a tranzacţiilor.

Examinarea gestiunii este un alt control pe care clientul l-ar putea utiliza la verificarea
faptului dacă tranzacţia a fost autorizată. Sistemul ar putea afişa lista tuturor tranzacţiilor
(pe suport de hârtie(imprimat) sau pe monitor). Managerul sau supraveghetorul ar putea
verifica lista şi selecta un eşantion de tranzacţii pentru verificarea corectitudinii autorizării
acestora.

Pentru a acorda credibilitate controalelor automatizate, auditorul necesită identificarea

faptului dacă au fost setate nivele adecvate de autoritate şi aceste nivele au fost operate pe
parcursul întregii perioade. Acestea vor include următoarele:
• verificarea matricelor de acces;
• obţinerea copiei imprimate a permisiunilor pentru utilizatori;
• examinarea registrelor de schimbări a permisiunilor;
• intervievarea utilizatorilor; şi
• testarea controalelor pe parcursul anului.

11.4.2. Plenitudinea introducerii datelor

Ca parte a auditării actelor financiare, auditorul va examina în mod obligatoriu dacă
înregistrările contabile sunt complete şi nu există omiteri de materiale. Pentru aceasta
auditorul va solicita verificarea controalelor pentru a se asigura că tranzacţiile introduse
sunt complete, şi anume că tranzacţiile nu lipsesc.

Plenitudinea tranzacţiilor introduse poate fi asigurată de o varietate de controale. Acestea

presupun:

• proceduri manuale, de ex. menţinerea unui jurnal al tranzacţiilor trimise de

utilizatori pentru introducere în sistem. Funcţionarii responsabili de intrarea
datelor din cadrul departamentului financiar ar putea să se aştepte la un flux sau
tip regulat de tranzacţii din departamentele utilizatorilor. În cazul în care se
aşteaptă o intrare a unui lot de documente însă nu s-a recepţionat nimic sau
numărul lotului lipseşte, va fi întreprinsă o acţiune ulterioară pentru a identifica
tranzacţia lipsă;

• utilizarea formularelor de intrare numerotate în prealabil. Acestea pot fi

numerotate secvenţial. Atunci când un număr este lipsă personalul de la finanţe
ar putea cerceta orice divergenţă. Alternativ, tranzacţiile introduse pot fi
expediate pe formulare în loturi numerotate secvenţial (sequentially numbered
batch forms) din departamentele utilizatorilor;

• utilizarea totalurilor loturilor (batch totals): într-un sistem tradiţional de intrare

în loturi, toate datele sunt prezentate sistemului în loturi şi loturile necomplete
sunt depistate, după care se produc rapoarte de excepţie; şi

• crearea unei acţiuni de rutină sau presupuneri de intrări de date. De ex. dacă
personalul responsabil de intrarea datelor presupune recepţionarea
documentelor de intrare de la toate 10 departamente vinerea şi ei au recepţionat
doar 9 seturi, ei ar urmări/cerceta setul de documente de intrare ce lipseşte.
98
Un lot este o colecţie de documente de intrare care sunt tratate ca un grup. Existenţa loturilor
este utilă la stabilirea controalelor pentru a asigura plenitudinea intrării datelor în sistem.
Totalul tranzacţiilor individuale va corespunde totalului calculat manual înregistrat pentru
intrare pe documentul titlu al lotului.

Sistemul pe loturi solicită ca tranzacţiile să fie introduse pe loturi. Dacă un lot este necomplet,
de exemplu dacă se anulează o tranzacţie, sistemul ar refuza lotul de date pentru intrare
deoarece totalul lotului calculat de calculator nu va corespunde cu totalul calculat de
persoana care a pregătit lotul şi a completat titlul lotului.

Totalul lotului (Batch totals) va fi obligatoriu înregistrat la cel mai primar punct posibil în
ciclul de procesare şi totalurile din rapoartele de actualizare vor fi acordate conform acestei
înregistrări iniţiale, ceea ce înseamnă că primul total de lot serveşte drept referinţă pentru
verificarea inversă a tranzacţiilor în ciclul său de procesare în sistem.

Este necesar de a exercita un control de către utilizatori pentru a asigura ca toate loturile să
fie procesare, precum şi pentru a asigura acceptarea valorii corecte pentru fiecare lot. Prin
urmare, este esenţial de a menţine un jurnal complet al tuturor loturilor expediate pentru
procesare. Acesta, de regulă, este un act de înregistrări completat de operatori şi verificat şi
semnat de supraveghetor.

La pregătirea loturilor şi expedierea lor pentru introducerea datelor, acestea sunt însoţite de
un document–titlu de lot (batch header document). De regulă, titlul lotului va conţine
informaţia următoare:
• numărul lotului şi data;
• totalul controlului de lot;
• totalurile documentului.

Chiar şi atunci când nu se utilizează sisteme pe loturi, clientul ar avea posibilitatea de a se

baza totalurile jurnalelor simple. Având în vedere că totalurile jurnalelor nu verifică ca
tranzacţia să conţină date corecte, acestea pot asigura o oarecare certitudine că tranzacţiile
nu lipsesc.

Aplicaţiile de asemenea pot dispune de controale integrate pentru a asigura ca toata

informaţie de bază a tranzacţiei este introdusă înainte ca tranzacţia să fie plasată în conturi.
De exemplu, dacă un utilizator al finanţelor nu introduce date într-un câmp de bază precum
suma, tranzacţia va fi refuzată de sistem.

11.4.3. Validarea datelor introduse

Aplicaţiile financiare pot avea controale integrate care verifică automat ca introducerea
datelor să fie efectuată cu acurateţe şi validă. Validarea poate fi, de asemenea, obţinută prin
proceduri manuale precum verificarea dublă a documentelor de intrare sau verificarea de
către supraveghetor.

Acurateţea datelor introduse în sistem poate fi controlată prin impunerea unui număr de
verificări electronice a validităţii asupra datelor prezentate sistemului.

Verificări automate a validităţii vor fi obligatoriu în număr suficient, pentru a asigura ca toate
datele acceptate în sistem vor fi acceptate de toate procesele subsecvente, inclusiv de alte
sisteme care prevăd un transfer electronic de date. Acceptarea este importantă în special
99
atunci când se utilizează sisteme de alimentare /sisteme operative (feeder system). De
exemplu, documentul de ieşire (rezultatul) unui sistem de salarizare individual ar putea
furniza date de intrare pentru un sistem financiar general.

Validarea verificărilor poate reduce riscul de prăbuşire a aplicaţiei din cauza erorilor logice
apărute la încercarea procesării datelor introduse cu valori ce nu se încadrează în limitele
pre-definite.

De exemplu, persoanele instruite ar fi auzit de problema anului 2000 şi riscul de prăbuşire

a sistemelor atunci când anul sa schimbat de la 99 la 00. Unele aplicaţii se puteau prăbuşi
deoarece 00 este din punct de vedere numeric înaintea 99 chiar dacă acesta se referă la
următorul an. Pentru soluţionarea acestei probleme s-ar putea aplica o verificare a validităţii
datelor.

Există multe tipuri de controale programate pentru aplicaţii cu care se poate confrunta un
auditor TI. De exemplu, controlul formatului, controlul validităţii, controlul şirului/seriei,
controlul limitelor, caractere de control, controlul compatibilităţii, etc.

Controlul formatului

Controlul formatului este exercitat pentru a asigura ca datele introduse sunt conforme unui
format pre-definit. De exemplu, un anumit câmp acceptă o combinaţie specifică de caractere
alfanumerice. Controlul formatului este aplicat deseori în câmpurile de tipul următor:

Sumă: unde se acceptă doar caracterele numerice, de ex. preţul bunurilor sau serviciilor, sau
numărul de ore lucrate de către angajaţi.

Dată: unde data obligatoriu va fi în ordinea ZZ/LL/AA opus ordinii LL/ZZ/AA. Formatul
datei poate fi important deoarece acesta poate fi utilizat pentru a determina valoarea
datoriilor din conturi la sfârşit de an. De exemplu, 11/12/96 înseamnă 11 decembrie 1996
sau 12 noiembrie 1996. Răspunsul ar putea depinde de ţara în care a fost elaborat aplicaţia
soft.

Codurile de conturi: codul de conturi poate fi valoare numerică, de ex. 668531. Dacă un
funcţionar responsabil de introducerea datelor în departamentul de finanţe a introdus
668S31 sistemul ar defini codul contului ca ne-valid.

Controlul seriei/şirului/tipului şi limitei

Controlul seriei/şirului/tipului şi limitei este utilizat în câmpurile pre-definite de a accepta

doar date care se încadrează într-o serie specificată. Sistemul poate fi setat să accepte o
valoare mai mare şi o valoare mai mică. Dacă este setată doar limita superioară atunci
controlul este o verificare a limitei.

Controalele limitei sunt frecvent utilizate pentru prevenirea erorilor mari. De exemplu, s-ar
putea seta o limită la numărul orelor de lucru pe săptămână pentru un angajat. Dacă limita
este setată la 80 ore şi un utilizator a introdus incorect 800, sistemul ar refuza tranzacţia şi
afişa un mesaj de eroare.

Similar, se poate seta o limită pentru valoarea ordinelor de remunerare şi alte tranzacţii ce
pot fi procesate de fiecare angajat.

100
De exemplu, aplicaţiile financiare pot fi configurate să permită personalului gestiunii
financiare să înregistreze/opereze cu cheltuieli de până la £10,000, pe când personalul
superior ar putea opera cu cheltuieli între £10,000 şi £100,000.

Chiar dacă controalele limitei examinează corectitudinea datelor, acestea pot fi utilizate
pentru a asigura certitudinea că cifrele sunt rezonabile. Limitele vor fi setate astfel încât
toate datele corecte să fie acceptate şi cele eronate să fie refuzate. Clientul decide ce limite
să aplice ţinând cont de tipurile de cheltuieli.

Controalele limitei pot fi atribuite şi utilizatorilor individuali. De exemplu, un simplu

funcţionar responsabil de procurări poate introduce şi procesa ordinele de procurare până
la o sumă anumită, (fie £100,000). Totodată, ordinele de procurare care depăşesc suma dată
trebuie introduse de cineva care deţine o autorizaţie de operare cu limită mai ridicată, de ex.
managerul departamentului de finanţe sau supraveghetorul.

Caracterele de control (check digits)

Caracterele de control sunt utilizate pentru verificarea transpoziţiei, transcripţiei şi erorilor

aleatoare. Controlul implică calcularea, aplicând o formulă predefinită, a unui caracter de
control în baza numărului ce urmează a fi introdus. Caracterul de control este adăugat la
sfârşitul numărului introdus.

De exemplu, dacă numărul 12345 trebuie introdus şi caracterul de control se bazează pe

modulul lui 11 (MOD 11 Check Digit) şi 7, 5, 1, caracterul de control ar fi calculat după cum
urmează:

1*7=7
2 * 5 = 10
3*1=3
4 * 7 = 28
5 * 5 = 15
Total = 63

63 împărţit la modulul lui 11 = 5 cu 8 rest.

Prin urmare, caracterul de control este 8 şi numărul introdus de către utilizatori ar fi 123458.

Unele sisteme folosesc puterea lui 2 ca serie de control, prin urmare în loc de 7, 5, 1 din
exemplul anterior, ar fi folosită seria 2, 4, 8, 16, 32.

Majoritatea sistemelor de caractere de control folosesc modulul lui 11.

Controlul validităţii datelor

Controlul validităţii datelor presupune că calculatorul verifică automat datele introduse de

către un utilizator în baza unui set de valori numerice. Dacă intrările nu corespund unei cifre
sau valori pre-definite, intrarea este refuzată.

De exemplu, dacă un utilizator din departamentul finanţelor a dorit să introducă o

tranzacţie în baza unui cod de cont specific, aplicaţia ar verifica codul de cont introdus de

101
utilizator în baza unui tabel de conturi pre-definit. Dacă codul de cont nu se încadrează în
tabelul de conturi, tranzacţia este refuzată.

Verificarea validităţii codurilor de conturi reduce riscul localizării eronate sau amplasarea
în final a tranzacţiilor în contul de aşteptare (ceea ce înseamnă că nu sunt incluse în balanţa
de verificare sau conturi).

Auditorul va lua în considerare faptul că în unele aplicaţii, când sistemul nu este apt să
valideze datele, în loc, acesta poate adăuga date noi în tabel. De exemplu, dacă un sistem nu
a recunoscut un cod de cont pentru o tranzacţie, sistemul ar anunţa utilizatorul despre acest
fapt afişându-i un mesaj “cod de cont neidentificat” şi apoi să întrebe utilizatorul dacă
doreşte să adauge codul de cont în tabelul de coduri de cont. Acest fapt poate cauza probleme
atunci când aceste coduri de cont noi nu sunt preluate de către sistemele de raportare. În
acest exemplu noile coduri de cont ar putea fi omise din documentele de lucru care pregătesc
balanţa de verificare şi conturile rezumate.

Verificarea validităţii datelor invariabile (date permanente) precum lista de furnizori

aprobaţi reduce riscul de fraudă (în cazul în care permisiunile pentru actualizarea datelor
invariabile sunt restricţionate).

Verificarea/controlul compatibilităţii

Controlul compatibilităţii este utilizat atunci când există o interrelaţie ce poate fi identificată
între două seturi sau domenii de date. Relaţia dintre două domenii trebuie identificată şi
înregistrată (de regulă, într-un tabel). La introducerea seturilor de date, acestea sunt
comparate aplicând relaţia din tabel. De exemplu, dacă un utilizator introduce într-un
sistem de state, ziua de naştere, urmată de vârsta angajatului, aplicând valorile 1 aprilie 1968
urmată de vârsta 78, aplicaţia va respinge datele (vârsta corectă trebuie să fie aproximativ
28).

11.4.4. Verificările duble

Creşterea numărului de tranzacţii ce necesită a fi procesate joacă un rol important în
informatizarea sistemelor contabile. Din păcate, volumul sporit de tranzacţii a determinat,
în rezultat, faptul că personalul de la finanţe în mare parte uită tranzacţiile pe care le-au
procesat puţin înainte. Această problemă este adăugată la faptul că un document de intrare
informatizat poate fi similar cu altul.

Acest fapt creşte riscul dublării unor tranzacţii şi nedepistării acesteia.

Pentru a aborda acest risc, unele aplicaţii ar putea depista tranzacţiile duble, de ex.
comparând tranzacţiile noi cu cele atribuite aceluiaşi cont anterior. Alte sisteme marchează
tranzacţiile cu un steguleţ după ce s-a lucrat cu ele. De exemplu, facturile în contul
furnizorului ar fi bifate odată ce se efectuează plata.

Alte sisteme pot să accepte doar un număr de tranzacţii pe un cont, unitate sau individual.
De exemplu, un sistem de înregistrare a timpului care ar permite doar o foaie de pontaj
introdusă per angajat.

102
 11.4.5. Concordanţa (Matching)
Acest control verifică şi compară o înregistrare a tranzacţiei cu datele incluse în altă
tranzacţie relevantă. Atunci când datele diferă, se produce un raport de excepţie. De
exemplu, datele introduse la recepţia bunurilor şi automat comparate cu facturile
furnizorului şi datele comenzii de procurare din sistem. Când se identifică o discordanţă,
sistemul produce un raport de excepţie. Clientul va exercita unii paşi pentru identificarea
cauzei discrepanţei.

11.4.6. Gestiunea intrărilor refuzate

Este foarte important ca atunci când datele sunt verificate şi validate automat la
introducerea lor, să existe proceduri de gestionare a tranzacţiilor care nu satisfac cerinţele
de intrare, ceea ce înseamnă că auditorul va identifica obligatoriu ce se întâmplă cu
tranzacţiile refuzate.

Există metode alternative de gestionare a tranzacţiilor introduse ce sunt refuzate de testările

de validitate.

Refuzul sistemului – atunci când tranzacţiile sunt refuzate direct, clientul va stabili
obligatoriu proceduri de setare a controlului asupra acestor refuzuri şi asigura ca toate
datele refuzate să fie ulterior corectate, reintroduse şi acceptate de sistem . Regulile
sistemului vor identifica dacă este necesar de a refuza tranzacţii individuale sau loturile
integral.

Menţinere în aşteptare – În acest caz, este foarte important ca utilizatorii să conştientizeze

faptul că menţinerea în aşteptare înseamnă că acestea vor fi obligatoriu gestionate repede.
Este esenţial faptul că toate articolele plasate într-un cont de aşteptare să fie corectate şi
ulterior procesate cu succes. Adoptând această abordare, noi evităm posibilitatea de pierdere
a articolelor refuzate, însă amânăm acţiunea de corectare a erorii de intrare.

Atunci când articolele sunt plasate într-un cont de aşteptare, auditorul va examina
obligatoriu procedurile de identificare, corectare şi deblocare a acestor tranzacţii.

11.5. Controale procesării datelor (processing controls)

Controalele procesării datelor sînt controalele care asigură utilizarea aplicaţiei şi fişierelor
de date corecte, procesarea tuturor datelor şi actualizarea fişierelor adecvate.

Controalele procesării vor asigura obligatoriu ca:

• Datele să fie procesate adecvat;
• Toate datele să fie procesate;
• Datele să fie procesate doar o dată; şi
• Procesările să fie aplicate doar pe datele validate.

Procedurile şi controalele procesării sunt mai eficiente dacă sunt automatizate.

Controalele procesării pot fi setate să opereze la două nivele de bază:

• La nivel de tranzacţie: controalele sunt aplicate tranzacţiilor individuale la
momentul procesării acestora; şi
• La nivel total: controalele totale sunt aplicate pe grupuri sau registre şi, de regulă,
sunt utilizate pentru a asigura plenitudinea procesării.

103
 11.5.1. Controalele run to run
Atunci când este posibil de a identifica un total derivat dintr-un fişier ce urmează a fi
procesat, dar care obligatoriu va rămâne intact pe parcursul şi după procesarea datelor,
concordarea acestui total ‘iniţial’ la fişierul cu datele procesate, totalul final’, este un mijloc
foarte eficient de control al plenitudinii procesării informaţiei.

Atunci când un număr de procesări sunt exercitate cu succes, ar putea fi posibil de extins
acest principiu pentru a concorda totalul derivat din datele înainte de prima procesare cu
totalul fişierului după exercitarea procesării finale. Acest fapt este posibil doar atunci când
poate fi identificată unitatea de control care va supravieţui pe parcursul tuturor procesărilor,
însă chiar şi atunci când aceasta nu este posibil, se poate realiza un control run prin utilizarea
totalului (rezultantei) pivot sau totalului (rezultantei) punctului de control.

Totalul pivot sau punctului de control presupune exercitarea controlului cu referinţă la un

total până la un punct de procesare când este posibil de a relaţiona două totale şi exercita
controlul de la acel punct mai de parte prin mijloacele celui de-al doilea total. Un exemplu de
utilizare a totalului pivot este sistemul de înregistrare a timpului de lucru/salarizare care
stabileşte totalul de control din orele lucrate până la punctul unde acesta poate fi egalat cu o
valoare de plată brută şi apoi o adoptă pe aceasta ca total de control din acel punct mai
departe.

Atunci când controalele run to run se schimbă de la un proces la altul, acest fapt poate servi
drept indicaţie de pierdere sau adăugare a datelor în timpul procesării. La identificarea
totalurilor (rezultantelor) run to run neegalate, acestea vor fi raportate obligatoriu
departamentului TI pentru a fi cercetate.

Totalurile (rezultantele) de control pot fi de asemenea utilizate la depistarea erorilor de

procesare în datele nenumerice, de exemplu, dacă un nume al unui furnizor sau plătitor al
checului a fost alterat pe parcursul procesării. Acest fapt poate fi realizat prin utilizarea
totalului hash(rezultantei H). Totalurile hash sunt calculate prin aplicarea unui algoritm
unor câmpuri de date nenumerice şi producerea unui total numeric. De exemplu, un total
hash (rezultantă H) poate fi aplicată unui cod de impozitare sau asigurare naţională a unui
angajat.

Tehnologia hash reprezintă aplicarea unor algoritmi matematici, pentru identificarea unică
a unui şir de simboluri (date sau fişiere) prin calcularea unei valori (sume de control) de
lungime fixă (diferă pentru fiecare metodă). Această procedură permite depistarea oricăror
modificări în şirul de simboluri iniţial prin contrapunerea sumelor de control obţinute.
Există numeroase metode (algoritmi) de calcularea a valorii hash, care pot fi utilizate separat
sau pot fi contrapuse. Cele mai răspândiţi algoritmi sunt: MD2, MD4, MD5, SHA-1, SHA-256,
SHA-384, SHA-512 (aici în regim online pot fi calculate valorile hash pentru date sau fişiere).
Metodele moderne oferă posibilitatea de criptare (encryption) a datelor prin utilizarea unei
„chei” care face parte din algoritm. Astfel unele date importante pot fi păstrate numai în
formă criptată, iar la necesitate utilizării lor se va folosi aceiaşi cheie pentru transformarea
datelor în forma iniţială (vezi figura de mai jos). Sistemele informaţionale moderne au
incorporate instrumente de calculare a sumelor de control hash şi de criptare a datelor,
pentru excluderea posibilităţii de accesare a datelor ocolind instrumentele de securitate a
sistemului (un exemplu de astfel de sistem este ASYCUDA World).

104
 11.5.2. Controalele de reconciliere a fişierelor
În cadrul unei aplicaţii, controale de procesare ar trebui să asigure că sunt utilizate numai
date şi fişierele de program valide şi că procesarea este completă şi efectuată cu acurateţe,
iar datele procesate au fost înregistrate în fişierele corespunzătoare. Asigurarea că
prelucrarea a fost corectă şi completă poate fi obţinută prin efectuarea unei reconcilieri a
totalurilor derivate din operaţiunile de intrare la schimbările în fişierele de date utilizate de
procesul respectiv. Auditorul trebuie să se asigure că sunt efectuate controale pentru a
detecta prelucrările incomplete sau inexacte a datelor de intrare.

11.5.3. Controalele de validate a tranzacţiilor

Procesele din cadrul unei aplicaţii ar putea efectua validarea suplimentară a tranzacţiilor
prin verificarea duplicării şi coerenţei datelor prin suprapunerea cu informaţii deţinute de
alte părţi ale sistemului. Procesul trebuie să verifice integritatea datelor pe care le menţine,
de exemplu, prin utilizarea sumelor de control derivate din date. Scopul acestor controale
este de a detecta modificări din exterior a datelor cauzate de defecţiuni de sistem sau
utilizarea de instrumente de redactarea a sistemului, cum ar fi redactorii de fişiere.

11.5.4. Procedurile de gestionare a discrepanţelor

Auditorul va determin obligatoriu cum aplicaţia şi utilizatorii gestionează discrepanţele,
inclusiv dacă tranzacţiile sunt refuzate în timpul procesării şi de care proceduri dispune
clientul pentru rectificarea erorilor şi reintroducerea datelor.

Sistemele computerizate ar trebui să menţină un jurnal al tranzacţiilor procesate. Jurnalul

de tranzacţii trebuie să conţină informaţii suficiente pentru a identifica sursa fiecărei
tranzacţii. În mediile de procesare a datelor în loturi, erorile detectate în timpul prelucrării
trebuie să fie aduse la cunoştinţa utilizatorilor. Loturile respinse trebuie să fie înregistrate şi
retrimise iniţiatorului tranzacţiei. Sisteme on-line ar trebui să includă controale pentru a
monitoriza şi raporta tranzacţiile neprelucrate sau neclare (cum ar fi facturi plătite parţial).
Ar trebui să existe proceduri care să permită identificarea şi revizuirea tuturor tranzacţiilor
neclare, care au trecut de o perioadă de aşteptare stabilită.

11.6. Controalele ieşirii datelor

Controalele ieşirii (raportării) datelor reprezintă controalele care asigură producerea
corespunzătoare a tuturor ieşirilor (rapoartelor), plenitudinea şi expedierea acestora
conform destinaţiei şi în timp util.
105
Controalele datelor –rezultat (de ieşire) vor asigura obligatoriu ca:
• Să se producă un rezultat atunci când se aşteaptă un rezultat;
• Rezultatul este complet;
• Rezultatul este exact(acurate) şi procesat;
• Rezultatul este rezonabil în termeni de cantitate şi format;
• Rezultatul este produs în timp util; şi
• Rezultatul este distribuit la destinaţia corectă într-un mod securizat.

11.6.1. Prezicerea rezultatului

Cei care depun date pentru procesare sau sunt responsabili de bugetele-resurse ar trebui să
aibă o viziune clară asupra rezultatului aşteptat şi cu o oarecare probabilitate momentul de
recepţionare a acestuia. S-ar putea crea o anticipare prin experienţă şi instruire a
utilizatorilor. De exemplu, după o vreme, utilizatorii vor putea prezice recepţionarea
raportului de buget la sfârşit de săptămână sau lună, deci dacă ei nu vor recepţiona
rapoartele anticipate, vor încerca să identifice motivul.

O abordare mai oficială pentru a asigura că utilizatorii au recepţionat datele-rezultat după

ce au depus datele pentru procesare, este de a menţine un jurnal sau program privind datele
expediate şi datele-rezultat recepţionate. Jurnalul poate fi manual sau automatizat.

11.6.2. Plenitudinea datelor-rezultat

Plenitudinea datelor-rezultat produse în sistem poate fi stabilită prin acumularea totalului
derivat din informaţia inclusă în raport. Acest total va fi imprimat la finalul procesării.
Totalul-rezultat va fi apoi comparat cu totalul anticipat în baza bilanţului unui control
independent sau conţinutului jurnalului de control al fişierelor de date.

Cu unele rapoarte este imposibil de a concorda totalul de articole incluse sau reconcilia la
datele introduse sau totalul evidenţiat anterior.

Plenitudinea datelor-rezultat computerizate poate fi asigurată de controale automate

precum programarea aplicaţiei pentru a adăuga numere secvenţiale rapoartelor –rezultat, şi
anume, numerotarea paginilor. Acest fapt va permite utilizatorilor să identifice rapid
paginile lipsă. În mod similar, sistemul ar trebui să tipărească “sfârşitul raportului” pe pagina
finală. Alternativ, tipărirea ‘x’ din ‘y’ poate asigura utilizatorului certitudinea că rezultatul
este complet.

Atunci când utilizatorul face o cerere de raport, dar nu se extrage nici un jurnal sau date,
aplicaţia va fi programată să tipărească cuvintele “RAPORT NUL”.

11.6.3. Protecţia fişierelor - rezultat ale aplicaţiei

Multe aplicaţii financiare nu produc imediat date-rezultat, atunci când utilizatorul apasă
tasta ENTER. În loc de aceasta, ei procesează un fişier sau grup de tranzacţii şi stochează
rezultatul într-un fişier temporar în aşteptare pentru tipărire la o imprimantă (şi anume,
transfer de rezultat).

Atunci când datele-rezultat sunt plasate într-o locaţie temporară, auditorul se va asigura
obligatoriu că există controale de acces logic corespunzătoare în vederea anulării oricărei
acţiuni neautorizate de modificare a datelor.

106
 11.6.4. Raţionalitatea datelor-rezultat
Datele-rezultat produse de un sistem informatic vor fi obligatoriu rezonabile şi vor satisface
aşteptările utilizatorului.

Responsabilitatea iniţială pentru verificarea raţionalităţii datelor-rezultat produse de

calculator poate ţine de competenţa utilizatorului sau a subdiviziunii TI. Atunci când
utilizatorii dispun de un control al intrării, procesării şi ieşirii datelor, aceştia vor fi
responsabili de verificarea raţionalităţii datelor-rezultat. Atunci când datele sunt expediate
unei unităţi centrale TI pentru introducere şi procesare, personalul TI va fi responsabil
pentru verificările iniţiale ale raţionalităţii (de ex. dacă sistemul produce un raport de 50
pagini când se preconizează producerea unui raport de 5 pagini).

În cele din urmă, sistemele sunt proiectate pentru a prelucra datele utilizatorilor şi aceştia
poartă responsabilitatea finală de a asigura că datele-rezultat sunt rezonabile. În fine, este
informaţia lor, resursele lor şi ei sunt cei care trebuia să ia decizii în baza informaţiei
recepţionate.

11.6.5. Producerea datelor-rezultat în timp util

Controalele în cadrul unităţii TI vor asigura obligatoriu ca datele utilizatorilor să fie
procesate şi toate datele-rezultat să fie produse şi disponibile în timp util.

Viteza şi periodicitatea datelor-rezultat vor fi influenţate de necesităţile de afacere. Unele

părţi ale afacerii clientului pot depinde de rapoartele oportune şi informaţia actualizată, de
ex. utilizatorii care operează cu pieţele de capital, pe când altele ar putea aştepta câteva zile.

11.6.6. Distribuirea datelor – rezultat (output)

Sistemul de distribuire, operat de către client ar trebuie să asigure ca datele-rezultat sunt
livrate către persoanele potrivite, la locul potrivit şi în timp util.

Cerinţele de securizare a sistemelor de distribuţie vor depinde de vulnerabilitatea sau

valoarea datelor-rezultat. De exemplu, datele-rezultat dintr-un aparat de emitere a
checurilor ar fi subiectul unei protecţii mai mari decât rapoartele de buget de la finele unei
perioade.

11.6.7. Utilizarea generatoarelor de rapoarte de către utilizatorii sistemului

Aplicaţiile financiare moderne deseori au integrate module de generare a rapoartelor care
permit utilizatorilor să-şi definească rapoarte cu condiţii/opţiuni specifice.

Utilizatorii pot folosi generatoarele de rapoarte pentru a specifica ce date solicită de la baza
de date. Multe din modulele de generare a rapoartelor dispun de o interfaţă favorabilă
pentru utilizator şi un limbaj de interpelări la baza de date, precum SQL (Structured Query
Language - Limbaj Structurat de Interogare). Odată ce rapoartele utilizatorilor au fost
procesate, acestea pot fi descărcate în seturi de foi de lucru gata (off the shelf spreadsheet
packages) precum Excel sau Lotus.

Există un număr de probleme de control care apar atunci când utilizatorii produc rapoarte
proprii conform logicii proprii şi cadrului temporal. Atunci când clientul utilizează un raport
definit de utilizator în scopuri de raportare financiară, auditorul va examina utilizarea
107
facilităţilor respective şi identifica riscurile specifice acestor circumstanţe şi care necesită a
fi luate în considerare adiţional la punctele menţionate anterior în acest capitol.

La etapa de proiectare a sistemului, clientul ar putea să a nu decidă oficial care rapoarte de

bază trebuie pre-definite. În cazul acesta, s-ar putea ca utilizatorii să acorde puţină atenţie la
modul în care rapoartele produse de către sistem asigură acurateţea sau corectitudinea
datelor.

Există o mai mare probabilitate ca rapoartele definite de către utilizator să conţină erori, în
special în contextul în care acestea nu sunt subiectul aceloraşi testări riguroase precum
rapoartele specificate în prealabil la etapele iniţiale ale dezvoltării sistemului.

Sursele potenţiale de erori presupun:

• Logica conform căreia au fost selectate articolele în raport poate fi incorectă;
• Informaţia ar putea să nu fie completă sau actualizată la momentul extragerii de
ex. ar putea exista tranzacţii ce urmează a fi procesate;
• Nu toată informaţia relevantă ar putea fi accesată de program din cauza prăbuşirii
sistemului; şi
• Penetrarea securităţii (de ex. datele confidenţiale sau personale pot fi extrase şi
dezvăluite).

La etapa de proiectare a sistemului, este necesar de a defini un şir de rapoarte pentru a

demonstra utilizatorului, acurateţea informaţiei sistemului. În special aceste rapoarte vor
asigura obligatoriu că:
• Toate datele introduse şi autorizate au fost procesate adecvat;
• Doar datele introduse şi autorizate au procesare;
• Tranzacţiile din alte sisteme au fost procesate corespunzător şi prompt;
• Tranzacţiile au fost procesate aplicând versiunile corecte ale fişierelor;
• Tranzacţiile generate de către sistem pentru introducerea datelor în alte sisteme
sunt corecte şi oportune; şi
• Informaţia sistemului continuă a fi corectă şi nu a fost alterată în nici un fel.

Logica extragerii, ca în cazul utilizării SQL, folosită pentru producerea unui raport va fi
tipărită pe prima foaie a raportului. Acest fapt determină crearea unei piste de audit şi
permite atât utilizatorilor cât şi auditorilor să întreprindă verificări şi examinări ulterioare,
la necesitate.

Ulterior, ar fi bine de a restricţiona criteriile de selecţie disponibile pentru utilizatori pentru

unele funcţii directe (la subiect). Acest fapt ar reduce riscul erorilor logice frecvent întâlnite.

Accesul utilizatorilor ar putea fi restricţionat la criteriile de selecţie standard şi formate de

rapoarte care necesită doar unele modificări minore. Aceste criterii standard de raportare
ar satisface o mare parte din rapoartele ad-hoc, pe care utilizatorii le vor solicita.

Multe din sistemele contabile populare includ instrumente de generare a rapoartelor

suficient de sofisticate. Accesul şi controlul asupra utilizării oricăror rapoarte generate va fi
examinat cu deosebită atenţie, în special având în vedere că unele sisteme de generare a
rapoartelor au posibilitatea de a rescrie fişierul cu date.

Unele indicaţii vor fi obligatoriu tipărite pe rapoarte pentru a elucida gradul de

actualizare a informaţiei. Aceste indicaţii vor fi efectuate în dependenţă de aplicaţie şi

108
vor include cel puţin ora şi data când a fost extrasă informaţia şi, de preferinţă, ultima
dată când a fost actualizat fişierul de date de fiecare sistem de intrare/sistem operativ
cu care lucrează.

Atunci când fişierul în baza căruia utilizatorul creează raportul, este static de ex. de la
sfârşitul lunii precedente, acesta va fi în mod raţional credibil şi la subiect. Atunci când
fişierul în baza căruia utilizatorul generează raportul, este dinamic, de ex. datele de la
mijlocul lunii, atunci indicaţii privind statutul datelor ar putea fi crucială.

În final, vor fi incluse obligatoriu indicaţii privind faptul că programul a accesat toate
înregistrările relevante din fişier. Din nou, acest fapt va fi examinat pentru fiecare aplicaţie
individual. De exemplu, atunci când un raport derivă dintr-un fişier “static”, totalul
înregistrărilor citite pot fi tipărite şi acceptate pentru rapoartele de control sugerate
anterior. În mod alternativ, într-un fişier “dinamic”, ar putea include unele mesaje ce
confirmă faptul că totalul de înregistrări citite corespund unui jurnal de control pentru
fişierul date. Acest jurnal de control va fi la rândul său reconciliat, în mod regulat, la totalurile
externe.

Un aspect foarte important în toate cele expuse anterior este recunoaşterea de către
utilizator a necesităţii unor asemenea controale şi definirii clare a circumstanţelor în care
este necesară exercitarea unor asemenea controale şi cine ar fi executorul potenţial/exact.

11.6.8. Sistemele ce operează în timp real

Sistemele e operează în timp real devin tot mai frecvente deoarece administraţia solicită
disponibilitatea imediată a informaţiei actualizate. Performanţa înaltă a sistemelor
informatice au asigurat elaboratorilor de soft platforme de echipament care au o capacitate
de procesare suficientă pentru a exercita procesarea în timp real.

11.6.8.1. Pierderea mecanismelor de control convenţional

Atunci când sistemul suportă procesarea în timp real, pentru client ar fi imposibil să
implementeze multe proceduri de control de sistem în bază de loturi pe care să se bazeze
administraţia şi auditorii.

Consecinţele de control al procesării în timp real pot fi rezumate după cum urmează:

• Intrarea directă la terminal poate rezulta în eşuarea utilizatorilor de a pregăti sau

reţine documentele sursă cu o ulterioară pierdere a jurnalului tradiţional de
înregistrare a tuturor acţiunilor, menţinut pe suport de hârtie;

• Procesarea tranzacţiilor în timp real elimină necesitatea introducerii/intrării pe

loturi şi astfel, nu se poate asigura plenitudinea introducerii datelor prin
reconcilierea totalurilor datelor introduse şi datelor-rezultat pe loturi;

• Redactarea/editarea interactivă şi on-line elimină necesitatea raportării erorilor

de intrare(introducere a datelor). Prin urmare, nu întotdeauna este posibil de a
obţine probe pentru stabilirea faptului dacă acţiunile de validare au operat
adecvat;

• Totalurile de control nu sunt generate de nici o funcţie din sistem şi deci, controlul
asupra procesării run-to-run nu poate fi stabilit prin aceste mijloace;
109
 • Informaţia este introdusă şi accesată în sistem la cerere şi deseori, lipseşte o
raportare a fişierelor de date complete pregătire pentru procesare. De exemplu,
introducerea modificărilor privind salarizarea angajaţilor înainte de calculările în
salarizare de la sfârşitul lunii, personalul din resurse umane ar putea să nu ştie
când au fost efectuate toate modificările; şi

• Nu există o procedură formală de actualizare a informaţiei fişierelor master şi

schimbările nu sunt raportate în mod regulat.

11.6.8.2. Controale preventive în sistemele ce operează în timp real

În multe cazuri, sunt mai multe controale preventive pe care proiectanţii aplicaţiei ar putea
să le integreze în sistemele ce operează în timp real proiectate să reducă la minim
posibilitatea de apariţie a erorilor. Cele mai frecvente tehnici de control sunt:

• Controalele de acces logic precum protecţia cu parolă a aplicaţiei şi a funcţiilor

principale pot fi aplicate pentru prevenirea accesului neautorizat la module, sub-
module sau monitorizarea introducerii datelor;

• Controalele datelor introduse în timp real permite aplicaţiei să valideze datele

introduse la momentul introducerii datelor, împreună cu corectarea imediată a
oricărei informaţii introduse incorect şi refuzate de sistem;

• Fişierele jurnale (log files) pot fi utilizate pentru înregistra acţiunile din sistem.
Atunci când fişierele jurnale înregistrează incidente de securitate, precum
încercări de accesare eşuate, acestea acţionează ca protecţie împotriva tentaţiei
de experimentare. Dacă utilizatorii ştiu că sistemul înregistrează încercările lor
eşuate de accesare, aceştia vor fi mai puţin tentaţi să încerce;

• Verificarea integrităţii: acest control poate fi utilizat pentru a identifica

discrepanţele la momentul cel mai timpuriu posibil. De exemplu, un control de
verificare a integrităţii ar putea fi apt să depisteze dacă a fost efectuată o editare
neautorizată a fişierelor de date din baza de date aplicând instrumente de
modificare sau editare a datelor. Acest fapt va reduce riscul ca modificările să fie
efectuate prin back-door routes (metode de acces care ocolesc procedura de
autentificare).

11.6.8.3. Controalele detective a sistemelor ce operează în timp real

Datorită inabilităţii tehnicilor de control convenţional de a exercita un control eficace a
informaţiei procesate de aplicaţiile în timp real, alternativele disponibile vor fi luate
obligatoriu în considerare şi vor fi adoptate cele mai adecvate. Printre alternative se numără
următoarele:

• Verificarea una câte una – acceptarea fiecărei tranzacţii în sistem este confirmată
individual de către iniţiator. Această alternativă este aplicabilă atunci când este
disponibil un jurnal complet al tuturor tranzacţiilor introduse la un moment
ulterior intrării datelor. Această tehnică de control este cea mai potrivită pentru
aplicaţiile care au un volum de tranzacţii pentru procesare relativ scăzut;

110
 • Operarea pe loturi retrospectivă – loturile de informaţie identificate sunt
constituite retrospectiv din tranzacţiile introduse în sistem şi conforme cu
informaţia acceptată într-un mod similar abordării adoptate pentru sistemele de
procesare în loturi. Pentru a permite operarea acestei metode de control, sistemul
va avea obligatoriu capacitatea de a colecta informaţia şi de a o trata totodată ca
lot în scopuri de raportare;

• Raportarea excepţiilor – rapoarte produse de sistem, privind toate tranzacţiile ce

nu sunt conforme cu criteriile predeterminate. Criteriile potenţiale pentru
raportare sunt următoarele: tranzacţiile mari, articolele fără parametrii timpului,
discrepanţele în informaţie, eşecurile în reconciliere. Acest control include o
asumare inerentă precum că nu este necesar de a exercita vreo acţiuni asupra
altor tranzacţii;

• Raportarea contului de aşteptare – toate tranzacţiile care nu pot fi procesate de

către sistem in mod normal sunt plasate în conturi de aşteptare. Orice balanţă a
contului de aşteptare trebuie raportată şi analizată ca una ce necesită o acţiune
urgentă pentru soluţionarea problemei de procesare; şi

• Conturile de control extern – informaţia procesată de sistem este plasată

independent într-un cont de control nemijlocit în afara sistemului informatic şi
reconcilierea între acest cont şi totalul sistemului informatic se bazează pe
asigurarea plenitudinii şi acurateţei procesării.

Deseori, câteva tehnici enumerate anterior sunt antrenate concomitent pentru a realiza un
control al sistemului. Controalele pot fi utilizate pentru a exercita controlul asupra diferitor
părţi ale sistemului şi acestea vor fi obligatoriu proiectate să se suporte unul pe altul. În
general, este necesar de a adopta structura de control optimă pentru aplicaţie.

11.6.9. Sistemele de baze de date

Multe din dificultăţile în control identificate în sistemele ce operează în timp real, sunt
aplicabile şi în cazul sistemelor de baze de date. Sistemele de baze de date, de asemenea,
prezintă dificultăţi adiţionale, în sensul că auditorul va fi nevoit să se bazeze în mare parte
pe controalele generale într-un mediu informatic general.

Aceasta se datorează faptului că, puţin probabil, ca controalele aplicaţiei, izolate, să fie
capabile să asigure plenitudinea şi acurateţea procesării exercitate de sistemele de baze de
date. Controalele aplicaţiei sunt eficace/eficiente în controlul asupra datelor introduse prin
intermediul instrumentelor de monitorizare a datelor de intrare ale aplicaţiei, totodată,
acestea, de regulă, nu sunt apte să prevină defectările în baza de date subordonată. Auditorul
va examina obligatoriu controalele generale pentru a evalua controalele care reduc riscul ca
utilizatorii să editeze direct baza de date.

11.6.9.1. Problemele de control specifice bazelor de date

De regulă, atunci când sistemele utilizează baze de date pentru stocarea detaliilor tranzacţiei,
clientul va numi o persoană responsabilă pentru administrarea bazei de date. Această
persoană este administratorul bazei de date.

În vederea exercitării rolului său în mod eficient, administratorului bazei de date i se acordă
o mare putere de decizie şi i se acordă acces la toată informaţia din baza de date.
111
Administratorul va avea privilegii de acces de nivel înalt şi va fi capabil să exercite mult mai
multe funcţii decât un utilizator de sistem ordinar.

Relaţiile dintre elementele de date în cadrul unei baze de date pot fi foarte complexe şi prin
urmare, este dificil de a stabili o integritate continuă a bazei de date şi concordanţa relaţiilor
între date. Există programe-utilite de verificare disponibile pentru majoritatea bazelor de
date, care pot fi operate periodic pentru a asigura integritatea, totodată, ar putea fi dificil de
a identifica cauza şi sursa erorilor survenite.

Plenitudinea raportării într-o bază de date depinde mai curând de acurateţea referinţelor
(pointer) între elementele de date, decât de abilitatea aplicaţiei de a citi cu succes fişierul pe
diagonală. Din acest motiv, este necesar de a trata toate rapoartele din sistemele de baze de
date ca rapoarte de excepţie a căror plenitudine necesită mai curând a fi dovedită, decât a fi
acceptată fără dubii.

Dacă o bază de date este actualizată în timp real, atunci starea datelor incluse în copiile de
rezervă a bazei de date sunt variabile, în dependenţă de poziţia datelor în secvenţa copiilor
de rezervă. Dacă un client necesită să recupereze o bază de date dintr-o sursă a copiilor de
rezervă (back-up), auditorul va examina obligatoriu procedurile adoptate pentru asigurarea
ca tranzacţiile depuse în timpul procesului efectuării copiilor de rezervă(back-up) să fie
incluse.

11.6.9.2. Căile de compensare a punctelor slabe în control

Având în vedere că este foarte dificil de a dovedi că funcţiile bazei de date într-adevăr
operează adecvat pe parcursul procesării datelor, este obligatoriu de a acorda atenţie
deosebită la specificarea şi elaborarea funcţiilor bazei de date şi este necesar de a efectua
testări comprehensive înainte de implementarea sistemului.

Atunci când nu au fost introduse schimbări de la începutul implementării, auditorul poate

acorda credibilitate procedurilor de testare şi rezultatelor testării. Unde este practic, se
recomandă reprocesarea periodică a datelor testării pentru a asigura că se produc rezultate
identice.

Verificarea integrităţii bazelor de date va fi obligatoriu derulată cu regularitate şi toate

erorile investigate integral şi corectate de către administratorul baze de date. Este necesar
de a stabili cauza erorilor şi modifica funcţiile, la necesitate. Dacă au fost modificate caeva
funcţii este necesar de a desfăşura un nivel adecvat de retestare.

Procesul de testate a bazei de date va include obligatoriu, testarea procedurii de

efectuare a copiilor de rezervă şi a procedurilor de recuperare. Auditorul va examina
obligatoriu orice documentaţie, deţinută de client ce ţine de procedurile de recuperare
şi efectuare a copiilor de rezervă. Documentaţia va acoperi obligatoriu diferite seturi de
acţiuni care pot fi întreprinse la implementarea procedurilor de recuperare atât pe
termen scurt cât şi pe termen lung. Planurile de testare şi de efectuare a copiilor de
rezervă trebuie să fie cunoscute în profunzime de către personalul relevant.

Sarcinile şi responsabilităţile tuturor angajaţilor clientului implicat în administrarea şi

controlul bazei de date vor fi obligatoriu specificate clar şi documentate. Documentarea bazei
de date obligatoriu va include descrieri ale funcţiilor tuturor aplicaţiilor care solicită acces la
baza de date.

112
Auditorul va determina obligatoriu dacă descrierea bazei de date (un set separat de
tabele care conţin descrierea detaliată a structurii bazei de date şi tabelelor acesteia)
este actualizată. Dicţionarul datelor este o descriere a bazei de date, care include denumiri şi
stricturi a tuturor tipurilor de date, precum şi orice restricţii şi care aplicaţii utilizează datele.

Capacitatea bazei de date de a se „opune” erorilor poate fi realizată prin:

• Controalele punctelor de verificare (reper), depozitărilor în segmente

protejate de memorie (dump), de reîncărcare (restart): atunci când se
efectuează periodic depozitări „dump” în calitate de puncte de reper şi se
înregistrează tranzacţiile între două puncte de. La reîncărcare, sistemul ia ultima
depozitare „dump” şi reaplică tranzacţiile efectuate după crearea acesteia; şi

• Rularea înapoi şi rularea înainte: acest fapt se referă la abilitatea de

anulare(undo) a tranzacţiilor sau reaplicare a lor (forward), astfel, permiţând
administratorului bazei de date să determine starea bazei de date la anumit
moment de timp.

11.6.10. Sisteme distribuite

Utilizarea sistemelor distribuite este în creştere. Capacitatea sporită şi costurile mai scăzute
a sistemelor de comunicare a permis sistemelor izolate anterior să se conecteze reciproc.
Furnizorii de programe soft au elaborat noi aplicaţii care exploatează avantajul capacităţii
de procesare la ambele capete de reţea, şi anume tehnologia client server.

Există unele aspecte de control specifice controlului asupra sistemelor distribuite. Acestea
sunt adiţionale celor descrise anterior în acest capitol şi sunt rezultatul tehnologiei aplicate
şi distribuirea fizică şi logică a datelor în cadrul sistemelor distribuite.

11.6.10.1. Controlul schimbului de date

La transmiterea datelor între echipamente interconectate care fac uz de instrumentele
(metode, abilităţi) de comunicare, este esenţial de a asigura ca datele să nu fie
corupte(modificate) în timpul transmiterii şi ca fişierele care recepţionează datele să fie
actualizate.

Majoritatea instrumentelor de comunicare asigură mecanisme automatizate de verificare a

integrităţii aplicând un şir variat de tehnici de verificare paralele şi redundante care pot
determina o asigurare certă că datele transmise nu au fost alterate/eronate.

Pentru a asigura ca fişierele de date pe echipamentul-receptor sunt actualizate integral,

rapoartele de transmitere a datelor şi rapoartele de recepţie a datelor vor fi produse
independent, câte unul la fiecare locaţie, în scop de comparare, la necesitate. La transmiterea
unui volum mare de date, este necesar de a identifica mijloace alternative de asigurare a
plenitudinii actualizării fişierului-receptor.

11.6.10.2. Controalele privind accesul la funcţiile sistemului

Atunci când puterea de procesare a fost distribuită unui număr de locaţii separate, nu mai
putem acorda mare credibilitate restricţiilor de acces fizic la un sistem informaţional
complex.

113
Ca precauţie iniţială, este necesar de a întreprinde paşi pentru fiecare locaţie de distribuţie
care are acces la resursele (instrumentele, echipamentul) de procesare, pentru a restricţiona
accesul doar persoanelor autorizate.

Clientul va cerceta necesităţile de procesare pentru fiecare locaţie. Sistemul va fi obligatoriu

configurat să restricţioneze accesul la informaţie şi resursele solicitate de facto. Acest fapt va
implica pregătirea unei matrice complexe pentru concordarea cerinţelor cu facilităţile.
Matricea va fi menţinută central şi actualizată regulat pentru a înregistra utilizatorii
autorizaţi ai tuturor resurselor disponibile în sistem.

Înregistrarea activităţii în sistem (ex. registrele de activitate) va furniza detalii

suficiente privind actualizările (modificările) efectuate. Acest fapt va permite stabilirea
sursei responsabile de modificarea informaţiei în caz de eroare sau prăbuşire în
vederea actualizării cu succes a bazei de date centrale. Este necesară o monitorizare
riguroasă a sistemului pentru a permite administratorilor de sistem să identifice şi să
rectifice orice dificultate în timp util.

11.6.10.3. Controlul consistenţei datelor

Dacă copiile fişierelor de date sunt menţinute în diferite puncte ale sistemului, clientul va
asigura menţinerea consistenţei datelor. Acest fapt va fi realizat după cum urmează:
• Toate actualizările sunt reflectate în toate fişierele. În acest caz se obţine o
concordanţă totală a tuturor datelor la orice moment de timp. Sistemul de control
care coordonează activitatea va fi obligatoriu capabil să asigure că toate
actualizările au fost reflectate adecvat pentru fiecare fişier relevant şi, de
asemenea, capabil de a depista şi corecta erorile atunci când actualizarea unuia
sau a mai multor copii de fişiere nu au fost realizate cu succes;
• Toate actualizările sunt reflectate doar într-un fişier central. Se menţine o
versiune definitivă centrală a fişierului de date şi toate programele de actualizare
vor accesa doar acest fişier. Copii locale ale fişierului sunt furnizate doar în
scopuri de informare şi sunt rescrise de o copie a fişierului central la intervale
regulate. Fişierele locale vor fi neactuale la orice moment de timp, de la cea mai
recentă actualizare efectuată prin copiere de pe fişierul central.

11.7. Controalele pentru fişierele master şi datele invariabile

Fişierele master sunt fişiere de date care conţin date financiare sau de referinţă semi-
permanente ce pot fi utilizate de câteva aplicaţii la procesare. Datele stocate în fişierele master
sunt denumite date invariabile.

Aplicaţiile vor interpela datele de referinţă din fişierele master pentru procesarea
tranzacţiilor sale.

De exemplu, un fişier master poate conţine date invariabile cu privire la preţul bunurilor
pentru vânzare. La efectuarea unei vânzări, aplicaţia cere utilizatorului să introducă datele
variabile ale tranzacţiei precum cantitatea bunurilor comercializate. Ulterior, aplicaţia
interpelează datele invariabile pentru preţ din fişierul master şi combină unitatea de preţ cu
cantitatea pentru a obţine valoarea totală a vânzării.

114
Datele invariabile pot includ următoarele:
• rate de plată pentru fiecare categorie;
• detalii privind furnizorul (numărul de referinţă, adresa, numărul de telefon,
termenii de creditare);
• detalii privind clientul (numele, adresa, numărul de telefon, limita de creditare);
• numărul de cont bancar al angajatului (pentru transferurile salariale
automatizate);
• rata inflaţiei şi indicele (pentru evidenţa contabilă a costurilor curente);
• datele de administrare a sistemului, precum fişierele cu parole sau permisiunile
de control al accesului; şi
• codurile conturilor.

11.7.1. Importanţa fişierelor master şi a datelor invariabile

Prin natura sa, datele invariabile sunt utilizate la procesarea multor tranzacţii. De exemplu,
date invariabile TVA pot fi utilizate pentru a determina responsabilităţile de impozitare
pentru sute sau mii de tranzacţii ale unei organizaţii.

Prin urmare, este foarte important ca datele invariabile să fie corecte. Auditorul va fi
obligatoriu interesat de datele invariabile deoarece o eroare în datele invariabile, combinat
cu caracterul sistematic al sistemelor informatice va rezulta în mari erori în conturile
clientului.

Clientul trebuie să conştientizeze importanţa datelor invariabile şi trebuie să aibă,

obligatoriu, controale implementate pentru a se asigura că:
• modificările la datele invariabile să fie autorizate;
• utilizatorii vor fi responsabili pentru orice schimbare efectuată;
• datele invariabile să fie actualizate şi exacte; şi
• integritatea fişierelor master să fie menţinută.

Având în vedere că erorile în datele invariabile produc un efect extins, este normal ca
controalele asupra lor să fie mai stricte decât controalele asupra tranzacţiilor individuale.

11.7.2. Controalele fişierului master

Tipul de control pe care clientul l-ar putea utiliza pentru protejarea datelor permanente au
fost deja descrise în acest modul, şi anume controalele accesului fizic şi logic (identificarea /
autentificarea, protecţia resurselor şi înregistrarea).

Aceste controale vor asigura obligatoriu ca doar utilizatorii autorizaţi să poată accesa, crea,
modifica sau şterge datele permanente.

Controalele pot fi implementate atât la nivel de aplicaţie cât şi la nivel de instalaţie.

Controalele instalaţiei vor asigura obligatoriu ca alţi utilizatori de calculatoare, de ex.
personalul altor operaţiuni TI şi utilizatori ai altor aplicaţii să nu obţină acces la date.
Controalele la nivel de aplicaţie vor asigura obligatoriu să li se acorde acces doar
utilizatorilor aplicaţiei care necesită acces la datele permanente.

Un alt control aplicat de client ar putea fi pentru segregarea responsabilităţilor, şi anume cei
responsabili pentru introducerea datelor tranzacţionale să nu poată face modificări la datele
tranzacţionale. În exemplele de fraudă, au survenit pierderi de date deoarece utilizatorii

115
aveau posibilitatea de a modifica datele permanente şi ulterior iniţiau tranzacţia bazată pe
datele permanente.

Tranzacţiile individuale vor fi obligatoriu autorizate şi acelaşi principiu se va aplica şi

schimbărilor la datele fişierului master. Prin urmare, clientul va avea obligatoriu proceduri
şi controale pentru efectuarea modificărilor la datele din fişierele master. Acestea vor
include completarea formularelor de modificare a datelor sau stabilirea ca un utilizatori să
introducă modificarea şi alt utilizator (supraveghetor) să depună modificarea folosind
permisiune automatizată.

Jurnalele tranzacţiilor sunt utile deoarece acestea ajută la identificarea utilizatorilor

individuali care efectuează modificări neautorizate. În mod ideal, jurnalul tranzacţiilor va
înregistra înregistrările sau câmpurile modificate, în momentul modificării acestora, care
este modificarea şi cine a efectuat modificarea.

Având în vedere că datele permanente sunt foarte importante, clientul va asigura ca acestora
să li se facă copii de rezervă în mod regulat, în special după modificarea lor.

Managementul clientului va asigura efectuarea verificărilor independente a datelor din

fişierele master. Clientul va tipări periodic copii ale fişierelor master şi verifica un eşantion
de date pentru a asigura că acestea sunt actualizate şi corecte.

Atunci când utilizatorii solicită modificarea fişierului master, de regulă se tipăresc rapoarte
cu modificările fişierelor master. Documentele tipărite vor fi expediate înapoi la solicitant
pentru verificare.

116
 Anexa nr.1 Exemplu de program de audit.
Aprobat:
Directorul Departamentului de audit
Valentina MADAN
01 octombrie 2010

Programul de audit

pentru petrecerea auditului TI cu tema: auditul tehnologiilor informaţionale la S.V. al R.M.

1. Prezentare generală

Auditul se efectuează în baza Programului activităţii de audit a Curţii de Conturi expus în redacţie
nouă prin HCC nr. 29 din 07.05.2010 şi art. 28 şi 31 din Legea privind Curtea de Conturi nr. 261-XVI din
05.12.2008 şi în conformitate cu materialele instructive în domeniul auditului de revizuire a controalelor
sistemelor informaţionale, documentele şi procedeele de audit standardizate în manualele regularităţii şi
performanţei.
Scopul auditului este realizarea Programului activităţii de audit a Curţii de Conturi pe anul 2010,
exercitarea calitativă a atribuţiilor de audit TI ale Curţii de Conturi, întocmirea unui raport calitativ de audit.
Auditului este supus Sistemul Informaţional Integrat Vamal al Serviciului Vamal atît la
aparatul central, cît şi la birourile vamale.
2. Informaţie generală despre entitate şi sistemul informaţional
Serviciul Vamal al Republicii Moldova este organul administraţiei publice, subordonat
Ministerului Finanţelor, care asigură securitatea economică a statului, implementează politica
vamală şi conduce nemijlocit activitatea vamală în Republica Moldova.
Serviciul Vamal este un organ de drept, cu statut de persoană juridică, dispune de ştampilă
cu Stema de Stat a Republicii Moldova, activează conform principiului de instituţie bugetară,
finanţată de la buget, dispune de mijloace (fonduri) speciale, precum şi de resurse obţinute de la
activitatea unităţilor din subordine aflate la autogestiune.
Structura aparatului central al Serviciului Vamal este aprobată prin Hotărîrea Guvernului nr.
4 din 02.01.20076. Astfel, SV este constituit din aparatul central (2 departamente şi 16 secţii) şi 8
birouri vamale.
În conformitate cu planul de acţiuni strategice, adoptat anual în cadrul Serviciului Vamal se
efectuează o modernizare esenţială a sistemului informaţional, se întreprind măsurile necesare
pentru aducerea lui în conformitate cu volumul sporit al informaţiei, adaptarea la normele admise
în practica internaţională.
Sistemul Informaţional Integrat Vamal se bazează pe ASYCUDA World (ASYCUDA:
Automated SYstem for CUstoms DAta) - produsul de program elaborat de către Conferinţa
Naţiunilor Unite pentru Comerţ şi Dezvoltare în scopul susţinerii reformelor în organele vamale,
precum şi acordarea suportului la facilitarea comerţului şi controlului vamal. Reieşind din
informaţia prezentată de V. Bagrin (inspector principal al Secţiei Sisteme Informaţionale Vamale),
în activitatea Serviciului Vamal sînt utilizate 28 sisteme informaţionale şi 7 SOFTuri licenţiate.
În scopul administrării, menţinerii şi asigurării funcţionării S.I. al Serviciului Vamal şi
subdiviziunilor lui a fost creată Întreprinderea de Stat “Vamtehinform” 7. Pentru atingerea
scopurilor, întreprinderea desfăşoară următoarele genuri de activitate:
- participă la elaborarea şi promovarea politicii unice a Serviciului Vamal în domeniul
informatizării, creării şi implementării noilor tehnologii informaţionale, sistemelor şi
reţelelor informaţionale, necesare activităţii organelor vamale;
- implementarea concepţiei elaborate de Serviciul Vamal privind informatizarea şi
automatizarea activităţii organelor vamale ale Republicii Moldova;

6
Hotărîrea Guvernului nr.4 din 02.01.2007 ”Privind aprobarea structurii, efectivului-limită şi a Regulamentului Serviciului Vamal”.
7
Hotărîrea Guvernului Republicii Moldova nr. 346 din 28.03.2007.
117
 - implementarea, exploatarea şi menţinerea continuă a sistemelor de informatizare şi
automatizare a activităţii organelor vamale la comanda Serviciului Vamal;
- realizarea strategiei Serviciului Vamal cu privire la îmbunătăţirea în continuu a pregătirii
profesionale a colaboratorilor vamali în domeniul tehnologiilor informaţionale;
- elaborarea proiectelor de documente ce vizează asigurarea informaţională şi tehnologică
de proiectare, implementare şi exploatare a sistemelor informaţionale automatizate,
necesare activităţii Serviciului Vamal;
- asigurarea funcţionării echipamentelor informaţionale şi de comunicaţii ale organelor
vamale în modul stabilit de Serviciul Vamal;
- analiza şi argumentarea propunerilor privind cadrul legislativ, instituţional, metodologic al
procesului de informatizare şi automatizare a Serviciului Vamal;
- menţinerea şi dezvoltarea Web site-ului şi a serverului poştal ale Serviciului Vamal în
modul stabilit de acesta;
- implementarea proiectelor şi sarcinilor tehnice pentru echipamentele şi utilajele necesare
organelor vamale întru asigurarea compatibilităţii acestora cu sistemele informaţionale şi
echipamentele existente în modul stabilit de Serviciul Vamal;
- elaborarea la comandă a aplicaţiilor software pentru instituţiile publice, agenţi economici
şi/sau persoane fizice cu acordul Serviciului Vamal;
- prestarea serviciilor de menţinere şi dezvoltare a aplicaţiilor elaborate;
- alte genuri de activitate în bază de contract ce nu contravin legislaţiei Republcii Moldova
cu acordul Serviciului Vamal.
Concepţia Sistemului Informaţional Integrat Vamal 8 (în continuare SIIV) formulează cerinţele
de bază pentru implementarea noilor tehnologii informaţionale în activitatea vamală.
Informatizarea organelor vamale este o direcţie strategică şi prioritară a activităţii Serviciului
Vamal şi reprezintă procesul de introducere a tehnologiilor informaţionale moderne în activitatea
vamală.
Concepţia Sistemului Informaţional Asycuda Word este elaborată în conformitate cu planul
de acţiuni strategice, adoptat anual în cadrul Serviciului Vamal şi cu Conceptul General al
sistemului informaţional ASYCUDA World (Legea nr.301-XV din 11 iulie 2003 privind
ratificarea Acordului de credit pentru dezvoltare (Proiectul “Facilitarea Comerţului şi
Transportului în Europa de Sud-Est”) dintre Republica Moldova şi Asociaţia Internaţională pentru
Dezvoltare). Concepţia SIIV stabileşte scopurile, sarcinile, funcţiile, precum şi totalitatea
sintezelor privind dezvoltarea Sistemului Informaţional Integrat Vamal şi implementarea noilor
tehnologii informaţionale în activitatea vamală. Ea prezintă baza metodică pentru crearea unui
sistem informaţional complex, în scopul asigurării activităţii organelor vamale.
Obiectivele de bază ale SIIV:
• asigurarea introducerii tehnologiilor moderne în activitatea organelor vamale pentru
perfecţionarea procedurilor de perfectare vamală şi creşterea eficacităţii controlului
vamal;
• asigurarea utilizării eficiente la nivel optim a tuturor resurselor existente în sistem
(hardware, software, dispozitive de comunicaţii, personal tehnic de specialitate etc.);
• asigurarea creşterii calităţii operaţiunilor de control şi urmărire de toate tipurile
(înainte, în timpul sau după vămuire), prin furnizarea inspectorului vamal a datelor
consolidate necesare, prezentîndu-i, astfel, în mod optim şi concludent, informaţiile
cele mai utile;
• asigurarea disponibilităţii elementelor de evaluare a operaţiunilor de vămuire şi
control efectuate de colaboratorii vamali, cu scopul de a evidenţia eficient şi operativ
punctele slabe în fluxul de procesare a diferitelor documente vamale;

8
Concepţia Sistemului Informaţional Integrat Vamal, aprobată prin Hotarîrea Guvernului nr. 561 din 18.05.2007.
118
 • perfecţionarea organizării schimbului de informaţii cu structurile externe, inclusiv de
peste hotare, dezvoltarea colaborării cu aceste structuri în domeniul tehnologiilor
informaţionale;
• asigurarea unui sistem unic de securitate a informaţiei organelor vamale ale
Republicii Moldova.
Pericolele de bază SIIV

Pericolele de bază privind protecţia şi securitatea informaţiei în cadrul SIIV se consideră:

1. Acţiunile neintenţionate ale colaboratorilor vamali, care conduc la accesul nesancţionat la

informaţie, modificarea nesancţionată şi nerespectarea confidenţialităţii acesteia;
2. Acţiunile intenţionate nesancţionate ale colaboratorilor vamali, care conduc la înlocuirea,
ştergerea şi modificarea informaţiei;
3. Accesul nesancţionat al utilizatorilor externi la resursele informaţionale ale organelor vamale;
4. Răspândirea viruşilor şi a altor maliţioase şi efectul lor negativ asupra resurselor informaţionale
ale organelor vamale;
5. Scurgerea informaţiei care conţine secret comercial prin diferite canale tehnice.
6. Suprasolicitarea echipamentelor şi comunicaţiilor.
7. Continuitatea menţinerii echipamentului şi SIIV în condiţiile fluctuaţiei cadrelor şi modernizării
tehnologiilor.
3. Persoanele cheie din entitate:

Directorul General al SV, dl T. Baliţchi;

Directorul departamentului Venituri şi tehnologii informaţionale al SV, dl C. Trofăilă;

Şef-adjunct al Direcţiei Fluxuri Informaţionale şi Statistică Vamală al SV, dl S. Beiu;

Şef al Direcţiei Audit Intern, dl M. Răducan.

4. Baza legislativ-normativă a entităţii

Actele legislative şi normative ce reglementează activitatea de asigurare socială a SV sunt:

Codul vamal al Republicii Moldova nr.1149-XIV din 20 iulie 2000;

Codul fiscal al Republicii Moldova nr.1163-XIII din 24 aprilie 1997;
Legea nr.1380-XIII din 20 noiembrie 1997 cu privire la tariful vamal;
Legea nr.1417-XIII din 17 decembrie 1997 pentru punerea în aplicare a Titlului III al Codului
fiscal;
Legea nr.1054-XIV din 16 iunie 2000 pentru punerea în aplicare a Titlului IV din Codul fiscal;
Legea nr.982-XIV din 11 mai 2000 privind accesul la informaţie;
Legea nr.467-XV din 21 noiembrie 2003 cu privire la informatizare şi la resursele informaţionale
de stat;
Legea nr.264-XV din 15 iulie 2004 cu privire la documentul electronic şi semnătura digitală;
Legea nr.301-XV din 11 iulie 2003 privind ratificarea Acordului de credit pentru dezvoltare
(Proiectul “Facilitarea Comerţului şi Transportului în Europa de Sud-Est”) dintre Republica
Moldova şi Asociaţia Internaţională pentru Dezvoltare;
Hotărîrea Guvernului nr.1140 din 2 noiembrie 2005 “Pentru aprobarea Regulamentului de aplicare
a destinaţiilor vamale prevăzute de Codul vamal al Republicii Moldova”.
5. Obiectivele de audit

Obiectivele auditului sunt:

- Testarea componentelor SIIV pentru a obţine asigurare rezonabilă vizavi de calitatea,
complexitatea şi eficacitatea controalelor sistemului şi corespunderea lor cu criteriile stabilite.
- Evaluarea nivelului de securizare a SIIV.
- Evaluarea eficienţei gestionării TI şi ale Sistemelor Informaţionale din cadrul SV.
119
 - Managementul personalului TI, asigurarea securităţii şi continuităţii întreţinerii TI.
Realizarea obiectivelor stabilite va oferi un răspuns la următoarea întrebare:
Sînt controalele TI din cadrul Serviciului Vamal şi cele a aplicaţiei „Asycuda
Word” suficiente pentru a asigura exactitatea, integritatea şi acurateţea
datelor, precum şi securitatea, fiabilitatea şi disponibilitatea SIIV?
După etapa studiului preliminar misiunea de audit a decis să testeze controalele generale TI din cadrul
SV şi cele ale aplicaţiei „Asycuda Word”.
Criteriile de apreciere a controalelor şi securităţii SIIV sunt standardele internaţionale TI stabilite de
ISACA, bunele practici internaţionale în domeniu (COBIT), legislaţia în vigoare, precum şi criteriile şi
cerinţele stabilite în concepţie şi documentaţia de proiect a sistemului.
ISACA este o subdiviziune a IFAC, care se ocupă cu modelarea standardelor de audit ale sistemelor
informaţionale, certificarea auditorilor sistemelor informaţionale (CISA).
Standardele de audit prezintă doua mari categorii de mecanisme de control în ceea ce priveşte sistemele
bazate pe tehnologii informaţionale si anume: controalele generale si controalele de aplicaţie.
• Controalele generale se refera la toate aspectele funcţiilor tehnologiilor informaţionale, inclusiv
administrarea sistemelor informaţionale, achiziţia şi întreţinerea programelor informatice,
securitatea fizica şi securitatea accesului la echipamente, produse-program şi date asociate acestora,
planificarea creării de copii de siguranţă în cazul producerii de evenimente neprevăzute şi
conceperea de mecanisme de control integrate în TI.
• Controalele de aplicaţie se exercită asupra prelucrării operaţiunilor individuale, cum ar fi controlul
prelucrării unor operaţiuni specifice programului (de ex. calculul şi încasarea plăţilor vamale).
Aceste controale trebuie evaluate pentru fiecare aspect al auditului afectat de o aplicaţie
informatică, în care se planifică sa se reducă riscul de control estimat.
Controalele generale sunt proiectate pentru a proteja toate controalele de aplicaţie, cu scopul de a se
asigura eficienta acestora din urma.
Controalele generale se evaluează atent încă din etapa iniţială a auditului, din cauza impactului acestora
asupra controalelor de aplicaţie. In categoria controalelor generale sunt incluse: administrarea funcţiei de
tehnologii informaţionale, separarea sarcinilor legate de tehnologiile informaţionale, proiectarea sistemelor,
securitatea fizica şi securitatea accesului electronic, gestionarea copiilor de rezervă şi a evenimentelor
neprevăzute, controalele proprii ale echipamentelor fizice.
În categoria controalelor de aplicaţie întră controalele intrărilor de date, controalele prelucrărilor de
date, controalele ieşirilor de date.
Gestionarea resurselor TI, a resurselor umane disponibile şi a mijloacelor financiare utilizate, trebuie
să corespundă obiectivelor şi direcţiilor strategice de dezvoltare. Sistemele Informaţionale trebuie să
corespundă cerinţelor de gestionare eficientă şi asigură continuitatea şi securitatea activităţilor de bază ale
entităţii.

6. Metodologia auditului
La executarea auditului se vor petrece următoarele activităţi şi se vor utiliza următoarele metode de
colectare a probelor precum şi va fi aplicată metodologia:
Activităţi de audit:

- Intervievarea persoanelor responsabile din cadrul entităţii;

- Identificarea persoanelor cheie responsabile de elaborarea, implementarea şi administrarea
componentelor SIIV, intervievarea lor;
- Examinarea performanţelor personalului TI şi a fluctuaţiei cadrelor;
- Studierea documentaţiei de contract privind elaborarea şi implementarea SIIV, deservirea
tehnică şi menţinerea lui, procesele verbale de executare a lucrărilor şi darea în exploatare a
sistemului, modificările operate;
- Studierea politicilor entităţii în domeniul dezvoltării mediului informaţional şi a performanţelor
personalului cheie;
- Studierea contractelor privind prestarea serviciilor de telecomunicaţii, internet ş.a.;
- Examinarea configuraţiei sistemului, infrastructurii aferente, dezvoltarea şi implementarea;
- Analiza funcţiilor specifice SIIV, instruirea utilizarea şi menţinerea;
- Analiza modului de gestionare a TI, existenţa şi eficienţa măsurilor de asigurare a continuităţii în
activitate şi dezvoltare;

120
 - Analiza: datelor de intrare (procesul de introducere/import/acumulare a datelor); procesării datelor
în cadrul Sistemelor Informaţionale; datelor de ieşire (raportarea, schimbul de date, integrarea în
alte structuri şi asigurarea accesului). Identificarea operaţiunilor manuale şi automatizate.
Procedurile de autorizare şi asigurarea accesului restricţionat;
- Descrierea procedeelor şi posibilităţilor de restabilire a prejudiciilor aduse sistemului în caz de
calamitate. Efectuarea, testarea, validarea şi păstrarea în siguranţă a copiilor de rezervă. Asigurarea
continuităţii activităţii instituţiei;
- Testarea funcţionalităţii aplicaţiei la 4 posturi vamale.
- Întrunirea de generalizare a echipei de audit, analiza informaţiei obţinute în teritorii şi pe parcursul
auditului la SIIV. Sistematizarea documentaţiei şi probelor obţinute pe parcursul procesului de
audit.
Compararea şi analiza celor observate şi constatate de auditori. Revizuirea constatărilor şi formularea
concluziilor. Structurarea proiectului raportului cu expedierea entităţii auditate pentru obiecţii şi propuneri.
Metode de colectare a probelor:
- Documentarea interviurilor;
- Completarea chestionarelor;
- Observările directe (documentarea constatărilor, imagini foto, imprimarea interfeţelor, imprimarea
registrelor electronice);
- Testele de control (CoBIT) cu imprimarea ecranelor (screen-urilor);
- Efectuarea de copii ale documentelor necesare;
- Analiza documentelor (completarea tabelelor de date, diagrame).
7. Testarea controalelor
Pe parcursul auditului se vor testa următoarele controale generale sub aspectul riscurilor legate de:
• Administrarea sistemului. Riscuri implicate de utilizarea practicilor inadecvate de administrare a
sistemului: gestiune conturi utilizatori, proceduri de back-up, configurare sistem, instruire
administratori (identificat ca risc de grad înalt).
• Acces utilizatori. Riscurile implicate de compromiterea securităţii informaţionale pe staţiile
utilizator sau de către utilizatorii sistemului informaţional (virusare, acces nesancţionat,
compromiterea parolelor, utilizarea inadecvată a resurselor disponibile ş.a.) (identificat ca risc de
grad înalt).
• Proceduri operaţionale. Riscuri implicate de lipsa documentării detaliate şi adecvate a utilizării
tuturor resurselor critice (identificat ca risc de grad mediu).
• Dependenţe externe. Riscuri implicate de dependenţa de anumiţi furnizori în vederea menţinerii
sistemului, operarea de modificări de program (deţinerea codului sursă), produselor program, alte
servicii (identificat ca risc de grad înalt).
• Personalul critic. Existenţa unei singure persoane în vederea efectuării procedurilor critice
(administrare sisteme şi reţele) poate să compromită activitatea normală curentă (identificat ca risc
de grad înalt).
• Parole vulnerabile. Riscuri implicate de utilizarea parolelor vulnerabile, în special pentru conturile
de administrare a sistemului şi pentru conturile utilizatorilor critici (identificat ca risc de grad
mediu).
• Accesul la date. Riscuri implicate de gestionarea inadecvată a drepturilor de acces la resursele
informaţionale, modul în care se pot accesa resursele şi informaţia din sistem (identificat ca risc de
grad mediu).
• Securitatea fizică. Riscuri implicate de controlul inadecvat al accesului fizic la resursele
informaţionale atât intern cât şi extern (identificat ca risc de grad mediu).
• Dezastre de scară mare. Riscurile legate de dezastrele naturale ca incendii, inundaţii, căderi de
durată a curentului electric ş.a. pot avea impacturi considerabile asupra activităţii operaţionale
(identificat ca risc de grad necunoscut).
• Construcţii. Riscul legat de afectarea sediului companiei şi distrugerea serverului cu baza de date
în caz de lipsa unui server de rezervă cu BD a SIA amplasat la distanţă în altă localitate (identificat
ca risc de grad necunoscut).
8. Termenii de realizare a auditului

Bugetul şi punctele de reper pentru audit

121
 Membrul echipei Titlul Începutul Finalul Orele preconizate ale
utilizării personalului

Etapa de planificare

Vadim Şargarovschi Lider de echipă 06.09.2010 01.10.2010 80 ore

George Antoci Auditor 50 ore

Fricăţel Roman Auditor 120 ore

Adrian Varatic Auditor 120 ore

Etapa de executare

Vadim Şargarovschi Lider de echipă 04.10.2010 03.12.2010 260 ore

George Antoci Auditor 200 ore

Fricăţel Roman Auditor 294 ore

Adrian Varatic Auditor 286 ore

Etapa de raportare

Vadim Şargarovschi Lider de echipă 06.12.2010 20.12.2010 80 ore

George Antoci Auditor 60 ore

Fricăţel Roman Auditor 80 ore

Adrian Varatic Auditor 80 ore

Punctele de reper pentru audit:

Punctele de reper în timp Data ţintă iniţială Data revizuită Data de facto

Începutul auditului 06.09.2010

Şedinţa de deschidere 06.09.2010

Vizite în teren 01.11.2010, 05-10.11.2010

Finalizarea activităţilor de audit 01.12.2010

Proiectul constatărilor şi concluziilor de audit 15-17.12.2010

Şedinţa de închidere 20.12.2010

Prezentarea proiectului raportului de audit 20.12.2010

pentru revizuire

Obţinerea comentariilor din partea SV 24.12.2010

Includerea comentariilor entităţii auditate în 27.12.2010

raport

122
Prezentarea raportului pentru revizuirea finală 28.12.2010
în şedinţa CC

9. Componenţa echipei de audit:

Şeful echipei: Vadim Şargarovschi

Membrii echipei de audit: George Antoci

Fricăţel Roman

Adrian Varatic

10. Responsabilii de revizuirea proiectului de raport privind auditul TI pilot:

Directorul de Departament: Valentina Madan

Membrul Curţii de Conturi : Paknehad Ecaterina

Raportul de audit TI pilot se va prezenta spre examinare în şedinţa Plenului Curţii de Conturi pînă la data
de „____” _______________2010.

123
 Anexa nr.2 Chestionar de determinare a criticismului SI.

În cadrul entităţii pot fi utilizate multiple sisteme informaţionale şi aplicaţii. Curtea de Conturi poate să nu
fie interesată în auditarea tuturor acestora. Mai mult ca atît, careva aplicaţii pot fi aplicaţii de importanţă
strategică, neajunsurile cărora pot avea consecinţe cu efecte de rezonanţă. În astfel de cazuri Curtea de
Conturi, pentru efectuarea auditului, poate selecta metode şi instrumente stricte de evaluare (ex: CoBIT).
Curtea de Conturi poate să nu fie interesată în audite exhaustive a unor SI de management, ce nu sînt
utilizate de entitate pentru luare de decizii sau efectuare de operaţiuni financiare. Instrumentul prezentat
poate reprezenta o evaluare subiectivă a timpului, resurselor şi metodelor alocate, dar totuşi reprezintă
o metodă sigură de evaluare a riscurilor.

Numele oficilului (subdiviziunii):

Informaţie preliminară

A. Numele entităţii

B. Tipul entităţii Oficiul central

Oficiu regional

Oficiu teritorial

Oficiu al subdiviziunii

Altele

C. Denumirea sistemului

D. Descrierea sistemului

124
 Se referă oare sistemul la careva din următoarele

Operaţiuni critice pentru afaceri (30)

Numele oficiului:

Informaţie preliminară

Funcţii de suport (25)

E-Governare (30)

2 Investiţii în sistem

< 100.000 MDL (5)

100.000-500.000 MDL (10)

500.000-1.000.000 MDL (15)

1.000.000-5.000.000 MDL (25)

> 5.000.000 MDL (30)

3 Situaţia privind nivelul computerizării entităţii.

Majoritatea business proceselor (30)

Majoritatea proceselor financiare şi contabile (25)

Nu sînt automatizate (0)

4 Numărul computerelor din cadrul sistemului

> 100 (30)

> 50,< 100 (25)

> 20,< 50 (15)

> 10,< 20 (10)

< 10 (5)

5 Este sistemul de reţea?

da

nu

Dacă sistemul e de reţea, este conectat la:

Reţeaua locală LAN şi/ori la intranet? (20)

WAN şi MAN şi/ori la extranet? (25)

125
 Web bazată /domen public? (30)

6 Sistema funcţionază doar:

O singură locaţie (10)

Mai mult de o locaţie, dar mai puţin de 5 (20)

Mai mult de 5 locaţii (30)

7 Entitatea este dependent de sistem în măsura în care

Informaţia de ieşire este utilizată pentru operaţii critice activităţii sau (30)
formare de venituri

Informaţia de ieşire este verificată manual înainte de efectuarea (10)

plăţilor sau creşterii conturilor.

Informaţia de ieşire este utilizată pentru pregătirea Sistemului (15)

Informaţional

Informaţia de ieşire este utilizată pentru plăţi sau cumulare de venituri. (0)

8 Chiar dacă sistema nu efectuează funcţii financiare, ea procesează date de interes public.
Natura datelor este aşa încît, date eronate şi greşite pot aduce la:

Stoparea sau eşecul activităţii entităţii (30)

Pierderea credibilităţii entităţii (15)

Pierderi financiare (25)

Nici una din aceste (0)

9 Pot oare persoane fizice avea acces la astfel de date prin internet sau prin oricare alte căi?

Persoane fizice pot vedea datele în mod dinamic (15)

Persoane fizice nu pot nu pot vedea datele (0)

Persoane fizice pot efectua tranzacţii on-line (30)

10 Permite oare sistemul utilizarea linkurilor directe părţilor terţe. (ex: schimb electronic de date)

Da (20)

Nu (0)

11 Are oare instituţia personal TI dedicat

Nu (0)

< 10 (10)

126
 > 10, < 30 (20)

> 30, < 70 (25)

> 70 (30)

12 Cîte persoane aproximativ pot fi considerate ca utilizatori finali ai sistemului?

<5 (0)

> 5, < 25 (10)

> 25, < 70 (20)

> 70, < 150 (25)

> 150 (30)

13 Sistemul se utilizează de:

> 10 ani (5)

< 10 ani, > 5 ani (10)

< 5 ani, > 2 ani (20)

< 2 ani (20)

14 Sistema e bazată pe

Batch Processing (10)

On Line Transaction Processing (25)

15 Sînt oare proceduri formale de management a schimbărilor?

Da (0)

Nu (20)

Cît de frecvent sînt efectuate schimbări în aplicaţie

Mai mult de 5 ori în an (30)

Mai puţin de 5 ori în an, dar mai mult de 2 ori pe an (20)

Mai puţin de 2 ori pe an (10)

Nici măcar odată în an (5)

16 Are oare entitatea o politică de securitate documentată şi aprobată?

Da (5)

Nu (20)

127
 Are, dar nu este suficient documentată (15)

17 Foloseşte oare entitatea software destinat asigurării securităţii?

Da (5)

Nu (20)

18 Are oare entitatea o persoană abilitată, responsabilă de securitatea

sistemului?

Da (5)

Nu (10)

Numele persoanei/persoanelor menţionate:

Informaţie preliminară despre persoana menţionată (funcţia, gradul, data angajării, studii,
diplome, certificate, cursuri, etc.)

19 Are oare entitatea un Plan de recuperare în caz de

dezastru/calamităţi documentat şi aprobat?

Da (0)

Nu (20)

20 Capacitatea (volumul) datelor din sistem constituie aproximativ:

> 10 GB (25)

> 2 GB, < 2 GB (15)

< 2 GB, > 1 GB (10)

< 1 GB (5)

Total Score

Reieşind din acestui instrument de evaluare a riscului, conform punctelor acumulate, entitatea
reprezintă un nivel de risc:

128
Puncte acumulate Clasificarea gradului de risc

< 150 Scăzut

< 150, > 300 Mediu

> 300 Înalt

129
 Bibliografia

• Information Systems Audit and Control Association Standards and Guidelines (ISCA)

• INTOSAI IT Audit Courseware, 2001

• National Audit Office (UK), Financial Audit Manual – Module T9 – Audit in an IT environment

• CoBIT.

• IFAC Auditing standards,

• Ron Weber, Information Systems Controls and Audit, Prentice Hall,

• Martin A Krist, Standard for Auditing Computer Applications, Auerbach Publications.

• Federal Information Systems Controls Audit Manual, GAO

• ISO/IEC 27001:2005 - Information technology -- Security techniques -- Information security

management systems -- Requirements.,

• Capability Maturity Model (SW) framework of Carnegie Mellon University.

Application

130