Information Technology General Controls -...

Sistemi di gestione dei dati e dei processi aziendali

Information Technology General Controls

Anno Accademico 2009/2010 Sistemi di gestione dei dati e dei processi aziendali

Slide 2

Indice degli argomenti

• Introduzione agli ITGC

• ITGC e altre componenti del COSO Framework

• Sviluppo e manutenzione degli applicativi

• Gestione operativa delle infrastrutture tecnologiche

• Accesso ai programmi e ai dati

• Conclusioni


• ITGC e altre componenti del COSO

Framework


• Gestione operativa delle infrastrutture

tecnologiche


• Conclusioni


Slide 4

Gli ITGC rispetto al COSO Framework

Secondo il framework sui

controlli interni del COSO, gli

ITGC sono una delle diverse

tipologie di controlli che

risiedono all’interno della

componente “attività di

controllo”


Slide 5

Introduzione

Recenti studi ha evidenziato che l’Information Technology

rappresenta oggi, per la maggior parte delle imprese, uno degli

assets aziendali di maggior valore, sebbene sia spesso oggetto

di limitata attenzione.

Fattori di mercato e sviluppi della normativa hanno recentemente

fatto aumentare la sensibilità verso le tematiche legate alla c.d.

“IT Governance” e in genere ai controlli interni in ambito

Information Technology.


Slide 6

Il COSO Framework e gli ITGC

Secondo il COSO Framework, la maggior parte delle imprese,

incluse quelle di minori dimensioni, utilizzano i computer per

elaborare le informazioni. Conseguentemente, in termini di

controllo interno, sorge il problema di comprendere le attività di

controllo sulle informazioni elaborate dai moderni sistemi

informativi.

Tali attività di controllo si possono suddividere in:

• controlli applicativi

• controlli generali sull’Information Technology (ITGC)

Una corretta combinazione di tali controlli assicura la

completezza, l’accuratezza, la validità e l’integrità delle

informazioni registrate nei sistemi informativi.


Slide 7

Il COSO Framework e gli ITGC

I controlli generali sull’Information Technology (ITGC) sono quei

controlli interni finalizzati ad assicurare il continuo e corretto

funzionamento dei sistemi applicativi aziendali.

Gli ITGC comunemente includono i controlli:

• sullo sviluppo e sula manutenzione dei sistemi applicativi

• sul funzionamento dei centri elaborazione dati

• sull’acquisto e sulla manutenzione del software di sistema

• sulla sicurezza degli accessi logici

Gli ITGC si applicano a tutte le tipologie di sistemi informativi

(mainframe, minicomputer e personal computer).


Slide 8

Domini ITGC

Le attività di controllo sui sistemi informativi possono essere

normalmente suddivise in quattro aree di interesse (c.d.

“domini”), corrispondenti alle tipiche attività di competenza

della funzione preposta alla gestione dei sistemi informativi

I quattro domini sono:

- Sviluppo degli applicativi (“Program Development”)

- Manutenzione degli applicativi (“Program Changes)

- Gestione operativa delle infrastrutture (“Computer

Operations”)

- Accesso ai programmi e ai dati (“Access to Programs

and Data”)



Framework



tecnologiche


• Conclusioni


Slide 10

Importanza delle 5 componenti COSO

Secondo il framework sui

controlli interni del COSO,

tutte le 5 componenti del

controllo interno devono

operare efficacemente per far

sì che il sistema di controllo

interno del cliente sia

efficiente nel raggungere gli

obiettivi dell’organizzazione.


Slide 11

Control Environment

Asserzione COSO: “The control environment sets the tone of an

organization, influencing the control consciousness of its people.

It is the foundation for all other components of internal control,

providing discipline and structure”.

Valutando l’ambiente di controllo da un punto di vista IT, devono

essere analizzate le seguenti sotto componenti:

- IT Governance

- Ruoli e Competenze IT,

- Risorse Umane


Slide 12

Risk Assessment

Asserzione COSO : “Every entity faces a variety of risks from

external and internal sources that must be assessed. A

precondition to risk assessment is establishment of objectives,

linked at different levels and internally consistent. Risk

assessment is the identification and analysis of relevant risks to

achievement of the objectives, forming a basis for determining

how the risks should be managed”.

Nella valutazione del rischi presenti in ambito IT, devono essere

analizzate le seguenti sotto componenti:

- Obiettivi e rischi IT,

- Gestione della variazione dei rischi IT,

- Mitigazione del rischio e gestione del rischio residuo


Slide 13

Information & Communication

Asserzione COSO : “Pertinent information must be identified,

captured and communicated in a form and timeframe that

enables people to carry out their responsibilities. Effective

communication must also occur in a broader sense, flowing

down, across and up the organization”.

Nel valutare la componente “Information and Comunication” da

un punto di vista IT devono essere analizzate le seguenti sotto

componenti:

- Disponibilità e qualità dell’informazione

- Proprietà dei dati

- Comunicazioni IT sui controlli

- Elaborazioni da parte dell’utente finale


Slide 14

Monitoring

Asserzione COSO : “Internal control processes need to be

monitored – a process that assesses the quality of the system’s

performance over time. This is accomplished through ongoing

monitoring activities, separate evaluations or a combination of the

two. Internal control deficiencies should be reported upstream,

with serious matters reported to top management and the board”.

Valutando le attività di monitoraggio da un punto di vista IT

devono essere analizzate le seguenti sotto componenti:

- Monitoraggio continuo

- Monitoraggio puntuale

- Comunicazione delle carenze



Framework



tecnologiche


• Conclusioni


Slide 16

Obiettivo del Dominio

Program Development

Assicurare che i sistemi siano

sviluppati, configurati ed implementati

in modo tale da raggiungere gli

obiettivi del management.


Slide 17


Program Changes

Assicurare che i cambiamenti agli

applicativi e alle tecnologie sui quali questi

operano siano opportunamente richiesti,

abbiano assegnata una priorità, siano

eseguiti, testati ed implementati in accordo

con gli obiettivi del management.


Slide 18

Attività di Program Development e Program

Changes in relazione con il mondo reale

Le attività necessarie per la

costruzione di una casa…

…e la manutenzione della

casa dopo la sua

costruzione…

Program Development


Slide 20

Testing &

Quality

Assurance

Data

Conversion

Program

Implementation

Construction/

Package

Selection

Analysis

& Design

Project

Initiation

Testing &

Quality

Assurance

Construction

Change

Requests

Program

Development

Program

Changes


Slide 21

Testing &

Quality

Assurance

Data

Conversion

Program

Implementation

Construction/

Package

Selection

Analysis

& Design

Project

Initiation

Testing &

Quality

Assurance

Construction

Change

Requests

Program

Development

Program

Changes


Slide 22

Project Initiation

Le attività di iniziazione di un progetto prevedono:

• Opportunità di partecipazione del management

• Efficace pianificazione del progetto

• Allineamento delle risorse

• Gestione del rischio


Slide 23

Testing &

Quality

Assurance

Data

Conversion

Program

Implementation

Construction/

Package

Selection

Analysis

& Design

Project

Initiation

Testing &

Quality

Assurance

Construction

Change

Requests

Program

Development

Program

Changes


Slide 24

Analysis & Design

Le attività di analisi e design prevedono:

• Una comprensione dei bisogni del business

• L’accordo sui requisiti di sistema

• L’opportunità di assicurare adeguata attenzione ad alcune

aree di rischio chiave:

- Le interfacce con altri sistemi

- La sicurezza

- I controlli interni

- La performance

• Un sistema costruito in modo da rispettare i requisiti

specificati


Slide 25

Testing &

Quality

Assurance

Data

Conversion

Program

Implementation

Construction/

Package

Selection

Analysis

& Design

Project

Initiation

Testing &

Quality

Assurance

Construction

Change

Requests

Program

Development

Program

Changes


Slide 26

Construction

Durante la fase di “Construction” il project team:

• Agisce sulla base del progetto/disegno approvato per creare

un sistema funzionante

• Valuta se produrre un software internamente o scegliere ed

eventualmente adattare un pacchetto esistente sul mercato

• Opera in conformità agli standard di programmazione ed ai

requisiti sulle architetture tecniche

La fase di “Construction” è spesso un processo iterativo


Slide 27

2 - Le modifiche complete

vengono trasferite

sull’ambiente di test

3 - Le modifiche testate vengono

trasferite all’ambiente di

produzione

Ambiente di sviluppo Ambiente di test Ambiente di produzione

1 - Il codice sorgente è copiato dai

programmatori per effettuare le

modifiche

Computing Environments


Slide 28

Testing &

Quality

Assurance

Data

Conversion

Program

Implementation

Construction/

Package

Selection

Analysis

& Design

Project

Initiation

Testing &

Quality

Assurance

Construction

Change

Requests

Program

Development

Program

Changes


Slide 29

Le attività di Testing e di controllo qualità forniscono:

• La certezza che il sistema funzioni secondo quanto previsto

nelle specifiche approvate

• L’opportunità agli utenti finali di verificare le nuove funzionalità

in un ambiente protetto prima dell’implementazione

• L’opportunità di assicurare la corretta integrazione del nuovo

sistema con gli altri sistemi

• La possibilità di verificare eventuali carenze di controllo nel

sistema

Testing & Quality Assurance


Slide 30

Testing &

Quality

Assurance

Data

Conversion

Program

Implementation

Construction/

Package

Selection

Analysis

& Design

Project

Initiation

Testing &

Quality

Assurance

Construction

Change

Requests

Program

Development

Program

Changes


Slide 31

Data Conversion

Le attività di “Data conversion” forniscono:

• La certezza sulla completezza e l’accuratezza dei dati nel

nuovo sistema

• La possibilità di eliminare i dati nocivi


Slide 32

Testing &

Quality

Assurance

Data

Conversion

Program

Implementation

Construction/

Package

Selection

Analysis

& Design

Project

Initiation

Testing &

Quality

Assurance

Construction

Change

Requests

Program

Development

Program

Changes


Slide 33

Program Implementation

Il processo prevede:

• Un processo di implementazione formalizzato

• La previsione di piani di ripristino

• Approvazioni da parte degli attori coinvolti

• Messa in produzione da parte di una funzione indipendente

• Protezione del codice sorgente durante il passaggio

dall’ambiente di test all’ambiente di produzione

• Procedure e modelli per le verifiche successive alla messa in

produzione

Program Changes


Slide 35

Testing &

Quality

Assurance

Data

Conversion

Program

Implementation

Construction/

Package

Selection

Analysis

& Design

Project

Initiation

Testing &

Quality

Assurance

Construction

Change

Requests

Program

Development

Program

Changes


Slide 36

Program Development vs. Program Changes

Quando ci trova di fronte a processi di sviluppo piuttosto che di

manutenzione di applicativi?

• La linea di demarcazione è diversa a seconda delle

organizzazioni

• Lo sviluppo implica l’elaborazione di nuove funzionalità e

progetti. Qualsiasi cambiamento significativo dovrebbe essere

gestito con il rigore dedicato agli sviluppi di nuove

applicazioni.


Slide 37

Testing &

Quality

Assurance

Data

Conversion

Program

Implementation

Construction/

Package

Selection

Analysis

& Design

Project

Initiation

Testing &

Quality

Assurance

Construction

Change

Requests

Program

Development

Program

Changes


Slide 38

Richiesta di manutenzione (Change Requests)

Cos’è una change request?

• La documentazione che supporta una modifica di sistema.

• Può provenire dagli utenti degli applicativi o dal personale IT.

• Normalmente prevede un’autorizzazione da parte del

responsabile di area prima dell’inizio dei lavori


Slide 39

Manutenzione di emergenza o correzioni

(Emergency and Minor Changes)

Eccezioni al sistema di controlli standard nell’ambito delle

modifiche:

• Modifiche di emergenza

• Modifiche minori


Slide 40

Testing &

Quality

Assurance

Data

Conversion

Program

Implementation

Construction/

Package

Selection

Analysis

& Design

Project

Initiation

Testing &

Quality

Assurance

Construction

Change

Requests

Program

Development

Program

Changes


Slide 41

Construction

Nella fase di “Construction”:

• I programmatori estraggono il codice ed effettuano le

modifiche specificate nella richiesta.

• Vengono apportate le modifiche al codice sorgente

nell’ambiente di sviluppo

• Le attività di programmazione devono essere in linea con gli

standard di programmazione.

• La documentazione all’interno del codice sorgente registra

quali sono state le modifiche apportate al codice


Slide 42

Testing &

Quality

Assurance

Data

Conversion

Program

Implementation

Construction/

Package

Selection

Analysis

& Design

Project

Initiation

Testing &

Quality

Assurance

Construction

Change

Requests

Program

Development

Program

Changes


Slide 43

Testing and Quality Assurance

• Le modifiche vengono inizialmente testate dai

programmatori nell’ambiente di produzione per assicurare

che la modifica funzioni da un punto di vista tecnico (unit

testing).

• La modifica deve poi essere testata nell’ambiente di test

dall’utente finale responsabile (user acceptance testing or

UAT).

• L’utente finale approva la modifica solo quando questa

risponde agli obiettivi documentati nella richiesta


Slide 44

Testing &

Quality

Assurance

Data

Conversion

Program

Implementation

Construction/

Package

Selection

Analysis

& Design

Project

Initiation

Testing &

Quality

Assurance

Construction

Change

Requests

Program

Development

Program

Changes


Slide 45

Program Implementation

Dopo che le attività di test sono state svolte:

• È necessario un processo per la migrazione delle modifiche in

ambiente di produzioe.

• Il processo è spesso reso più agevole dall’utilizzo di strumenti

di controllo delle modifiche.

• E’ necessario porre attenzione alla segregazione degli

ambienti e delle responsabilità.



Framework



tecnologiche


• Conclusioni


Slide 47


Computer Operations

Assicurare che le operazioni di elaborazione sui

sistemi in produzione siano svolte

completamente e accuratamente in linea con gli

obiettivi del management e che problemi di

elaborazione siano identificati e risolti

completamente ed accuratamente per assicurare

l’integrità dei dati.


Slide 48

Computer Operations e mondo reale

Pensando alla tua

automobile

• Quali sono alcune delle

precauzioni per

assicurare il regolare

funzionamento di

un’automobile nel

tempo?

• Quali le precauzioni in

caso di emergenza?


Slide 49

Le attività di “Computer Operations” in generale

Nell’ambito delle “Computer Operations” due attività assumono

particolare rilevanza:

• Gestione dei backup

• Gestione e risoluzione dei malfunzionamenti e disaster

recovery


Slide 50

Backups

• Gli applicativi, i dati e le applicazioni di sistema sono

copiati su nastro o all’interno di storage

• Può essere integrale o incrementale per ciascuna data

pianificata (giornaliera, settimanale, etc.)

• Può essere svolto secondo rotazioni stabilite

• Il c.d. Data mirroring non può essere considerato un

sostituto del salvataggio dei dati


Slide 51

Ripristino in caso di disastro o Disaster Recovery

Il disaster recovery plan consiste nelle procedure e modalità operative che consentono ad una azienda la ripresa tempestiva dell’operatività del suo sistema informatico in tempi rapidi a seguito di gravi malfunzionamenti o disastri.

E’ importante che tale piano sia:

• correlato ad una attività di valutazione dei rischi

• adeguatamente documentato

• adeguatamente conosciuto in azienda

• periodicamente testato



Framework



tecnologiche


• Conclusioni


Slide 53

Domain Objective

Access to Programs and Data

Consiste nell’assicurare che l’accesso

ai programmi e ai dati sia limitato

solamente alle utenze autorizzate

previa autenticazione dell’utente.


Slide 54

Accessi ai prograami e ai dati

e mondo reale

I livelli di accesso ai

sistemi informativi sono

paragonabili agli strati

della crosta terrestre.

Un “incidente” (ad es.

impatto di un

meteorite) potrebbe

essere possibile, ma

difficilmente avrebbe

effetti in profondità.

Crosta terrestre

Manto superiore

Manto inferiore

Nucleo esterno

Nucleo

interno


Slide 55

Componenti della Sicurezza

DATIAPPLI-

CAZIONI

SISTEMA OPERATIVO

RETE INTERNA

RETE PERIMETRALE

Attività di gestione della sicurezza

Amministrazione Centralizzata della sicurezza

Sicurezza fisica


Slide 56

• Salvaguardare l’integrità dei controlli automatici e

delle procedure automatiche di contabilizzazione

• Salvaguardare l’integrità dei dati contenuti nei report

prodotti dai sistemi

• Supportare un’efficace segregazione dei compiti

• Proteggere i dati e i programmi da minacce interne ed

esterne

Importanza delle attività di gestione degli accessi ai

programmi e ai dati


Slide 57

Gestione degli accessi

E’ importante che adeguati controlli siano operativi per

garantire una corretta gestione degli accessi a livello di:

1. Applicazioni - controllo all’accesso dei programmi utilizzati

(es: SAP)

2. Dati – controllo degli accessi diretti al database

3. Sistema operativo – controlli agli accessi alla

configurazione del sistema

4. Rete - controllo all’accesso della rete aziendale

5. Accessi fisici – controllo all’accesso ai locali aziendali in

particolari quelli dove sono ubicate le infrastrutture IT



Framework



tecnologiche


• Conclusioni


Slide 59

Tematiche di attualità

• Stretta interrelazione fra controlli interni su Information

Technology e corretta implementazione della

Segregazione dei Compiti

- le moderne tecnologie consentono un’ampia flessibilità

nella definizione dei “profili” di accesso, ma al contempo

ne aumentano a dismisura la complessità, rendendone

difficile la verificabilità


Slide 60

Tematiche di attualità

• Correlazione fra sistemi integrati e informatica

distribuita

- I moderni sistemi informativi aziendali di tipo integrato

forniscono soluzioni più efficienti in termini di costi di

gestione, ma risultano spesso molto complessi e ciò in

molti casi ostacola la realizzazione di interventi di

manutenzione

- Tale situazione, combinata con il costo minimo degli

strumenti di informatica distribuita, ha comportato il

proliferare di soluzioni elaborative “lato utente” (es.

Excel, Access), che sfuggono al controllo della funzione

IT, con un maggior rischio di produrre informazioni

errate


Slide 61

Riferimenti bibliografici

Le principali fonti bibliografiche relative agli ITGC sono:

• COSO Internal Control Framework

• International Standard on Auditing 315 *

• PCAOB Audit Standard No. 5 *

• CobiT 4.1 (ITGI) *

• Manuale di Information Systems Auditing (ISACA) *

* testi non oggetto dell’esame

Information Technology General Controls -...

Documents

Transcript of Information Technology General Controls -...