Elenco dei controlli
relativi alla sicurezza IT
Questo elenco, liberamente ricavato dalla
traduzione italiana del framework CobiT
4.1([1]),
viene, alla data, ritenuto completo ed esaustivo e quindi un suo utilizzo
offre buone garanzie di sistematicità in quanto vengono esaminate tutte le
aree dove sono possibili interventi migliorativi. La seguente tabella, ottenuta conservando
esclusivamente le parti relative alla sicurezza ([2])
viene proposta : ·
come aiuto per una rapida, efficiente e sistematica ricerca
delle aree di maggior criticità nelle quali è auspicabile / necessario
intervenire ([3]) ·
per introdurre alcuni criteri che consentano di individuare
la priorità dei singoli interventi ·
per introdurre alcuni criteri utili alla “vendita
interna” degli interventi stessi Suggeriamo di utilizzarla nel seguente modo:
|
Dominio :
Pianificazione e Organizzazione
Processo [importanza relativa per la
sicurezza] |
Attività / controlli |
Possibile intervento migliorativo |
Lavori in corso nell'area |
Business drivers |
Interventi collegati / collegabili |
|||
N |
Entità / costo |
Tempo |
Autonomia |
|||||
PO2 - Definire l’architettura informatica [4] La funzione Sistemi
Informativi dovrebbe definire ed aggiornare regolarmente un modello delle
informazioni aziendali e individuare i sistemi più appropriati per
ottimizzare l’uso di queste informazioni. Questo comporta lo sviluppo
di un dizionario dei dati aziendali che comprenda le regole di sintassi, lo
schema di classificazione dei dati, i livelli di sicurezza. Questo processo
migliora la qualità delle decisioni garantendo l’affidabilità e la
sicurezza delle informazioni fornite e permette la razionalizzazione delle
risorse dei sistemi informativi rispetto alle strategie aziendali. Tale
processo è necessario anche per aumentare l’integrità e la sicurezza
dei dati e per migliorare l’efficacia ed il controllo della
condivisione di informazioni a livelli di applicativi e di entità aziendali. |
PO2.1 - Modello Aziendale di
Architettura Informatica Stabilire un modello
informativo che renda possibile lo sviluppo degli applicativi e lo svolgimento
di attività a supporto del processo decisionale, oltre ad essere in linea con
i piani di IT descritti nel PO1. Tale modello facilita la creazione,
l’utilizzo e la condivisione di informazioni a livello aziendale pur
mantenendone l’integrità e si caratterizza per la sua flessibilità,
efficienza dei costi, tempestività, sicurezza e capacità di recupero in caso
di errore. |
|
|
|
|
|
|
|
PO2.2 - Dizionario dei Dati
Aziendali e Regole di Sintassi Mantenere un dizionario aziendale
dei dati che comprenda le relative regole di sintassi. Tale dizionario
permette la condivisione di dati tra applicativi e sistemi, promuove una
concezione comune dei dati tra l’IT e gli utenti aziendali, e previene
la creazione di dati incompatibili. |
|
|
|
|
|
|
|
|
PO2.3 - Schema di
Classificazione dei Dati Stabilire uno schema di
classificazione applicabile a tutta l’impresa basato su criteri di
criticità e sensibilità dei dati (per es., accessibile a tutti, riservato, di
massima segretezza). Tale schema include una dettagliata indicazione del
proprietario dei dati, una definizione dei livelli di sicurezza e dei
controlli di protezione appropriati, ed infine una breve descrizione della
loro criticità e sensibilità e dei requisiti che determinano l’obbligo
di mantenerli o eliminarli. Tale schema si usa come base per la cifratura,
l’archiviazione e, tra l’altro, il controllo degli accessi. |
|
|
|
|
|
|
|
|
PO2.4 - Gestione
dell’Integrità Definire ed implementare procedure
per assicurare l’integrità e la concordanza di tutti i dati archiviati
in forma elettronica, come database, datawarehouse ed archivi. |
|
|
|
|
|
|
|
|
PO6 - Comunicare gli obiettivi e gli orientamenti della
direzione [1] La Direzione dovrebbe
sviluppare un quadro aziendale di riferimento per il controllo dell’IT
definendo e comunicando le politiche. Dovrebbe essere definito un programma
di comunicazione continua per articolare la missione, gli obiettivi del
servizio, le politiche e le procedure, ecc., approvati e sostenuti dalla
Direzione. La comunicazione sostiene il raggiungimento degli obiettivi della
funzione IT ed assicura consapevolezza e comprensione dei rischi aziendali e
informatici, degli obiettivi e delle linee guida. Tale processo dovrebbe
assicurare la conformità alle leggi e ai regolamenti che riguardano
l’IT. |
PO6.1 - Politiche IT e
Ambiente di Controllo Definire in ambiente di
controllo per l’IT che sia allineato alla filosofia di gestione ed allo
stile operativo dell’impresa. Tali elementi comprendono
aspettative/obblighi relativi alla produzione di valore attraverso gli
investimenti, la disponibilità al rischio, l’integrità, i valori etici,
la competenza del personale, la responsabilità e la capacità di render conto
delle azioni svolte. L’ambiente di controllo si basa su una cultura che
sostiene la produzione di valore mentre si gestiscono rischi significativi,
incoraggia la cooperazione tra le varie divisioni aziendali ed il lavoro di
squadra. Promuove la conformità ed il miglioramento continuo dei processi ed
infine gestisce bene le deviazioni dei processi (compresi i fallimenti) |
|
|
|
|
|
|
|
PO6.2 - Rischio IT
dell’Impresa e Quadro Strutturale del Controllo Interno Sviluppare e mantenere un
quadro strutturale che definisca l’approccio generale
dell’impresa verso i rischi ed il controllo interno per produrre valore
mentre si proteggono le risorse ed i sistemi informativi. Tale quadro
strutturale dovrebbe essere integrato con il quadro strutturale dei processi
dell’IT ed il sistema di gestione della qualità, ed essere conforme in
generale agli obiettivi aziendali. Dovrebbe mirare ad ottenere il massimo
valore minimizzando il rischio informatico per mezzo di misure preventive, la
pronta identificazione di irregolarità, la limitazione delle perdite e il
pronto recupero dei beni aziendali. |
|
|
|
|
|
|
|
|
PO6.3 - Gestione delle
Politiche IT Sviluppare e mantenere un insieme
di politiche a supporto della strategia dell’IT. Tali politiche
dovrebbero comprendere gli intenti, i ruoli e le responsabilità, i processi
di eccezione, l’approccio alla conformità ed il riferimento a
procedure, standard e linee guida. Tali politiche dovrebbero trattare temi
importanti come la qualità, la sicurezza, la riservatezza, i controlli
interni e la proprietà intellettuale. La loro rilevanza dovrebbe essere
confermata ed approvata regolarmente. |
|
|
|
|
|
|
|
|
PO6.4 - Introdurre le
Politiche Introdurre (roll-out) le
politiche dell’IT e farle rispettare da tutto il personale interessato,
in modo da integrarle nell’intera operatività aziendale. I metodi
utilizzati per introdurre tali politiche dovrebbero considerare la necessità
di risorse e consapevolezza e le relative implicazioni. |
|
|
|
|
|
|
|
|
PO6.5 - Comunicazione degli
Obiettivi e gli Indirizzi dell’IT Assicurare che gli obiettivi e
gli indirizzi dell’IT siano comunicati e compresi in tutta l’azienda.
La comunicazione di queste informazioni dovrebbe comprendere una missione
chiaramente articolata, degli obiettivi di servizio, la sicurezza, i
controlli interni, la qualità, il codice etico, le politiche e
procedure,ecc., ed essere inserita in un programma continuo di comunicazione,
supportato a parole e di fatto dall’alta direzione. La direzione
dovrebbe porre particolare attenzione alla trasmissione della consapevolezza
della sicurezza informativa e del fatto che ciascuno ne è responsabile. |
|
|
|
|
|
|
|
|
PO8 - Gestire la Qualità [1] Si dovrebbe sviluppare e
mantenere un sistema di gestione della qualità che consideri e documenti i
processi di sviluppo e acquisto e i relativi standard. Questo risultato è
ottenibile con la pianificazione, realizzazione e manutenzione di un sistema
di gestione della qualità, con la definizione di chiari requisiti, procedure
e politiche per la qualità. I requisiti di qualità dovrebbero essere definiti
e comunicati utilizzando indicatori quantitativi con valori di soglia
raggiungibili. Un processo di miglioramento continuo è conseguito attraverso
sistematici monitoraggi, analisi, interventi per gestire gli scostamenti,
report per comunicare i risultati ai soggetti interessati. La gestione della
qualità è essenziale per assicurare che l’IT è portatore di valore per
l’azienda, è fattore di miglioramento continuo e di trasparenza per gli
stakeholder. |
PO8.1 - Il Sistema di Gestione
della Qualità (SGQ/QMS) Definire e mantenere un
Sistema di Gestione della Qualità con un approccio standard, formale e
continuo in linea con le necessità aziendali. Questo sistema definisce i
requisiti e criteri di qualità. i principali processi dell’IT, la
sequenza e l’interazione degli stessi, e le politiche, i metodi e i
criteri per definire, identificare, correggere e prevenire i casi di non
conformità. Il SGQ dovrebbe definire la struttura organizzativa per la
gestione della qualità, indicando ruoli, compiti e responsabilità. Tutte le
aree principali sviluppano piani di qualità propri in base a criteri e
politiche e ne registrano i dati. Monitorare e valutare l’efficacia e
l’accettazione del SGQ e migliorarlo, ove necessario. |
|
|
|
|
|
|
|
PO8.2 - Standard e Prassi per
la Gestione della Qualità dell’IT Identificare e mantenere gli
standard, le procedure e pratiche per i principali processi IT al fine di
guidare l’organizzazione a rispondere alle finalità del SGQ. Utilizzare
come riferimento le best practice del settore quando si stanno migliorando e
personalizzando le pratiche per la gestione della qualità dell’azienda.
|
|
|
|
|
|
|
|
|
PO8.3 - Standard di Sviluppo
ed Acquisto Adottare e mantenere standard
di sviluppo ed acquisto per tutto il ciclo di vita del prodotto finale e prevedere
approvazioni formali a conclusione delle fasi principali secondo criteri di
approvazione formale. Gli aspetti da considerare comprendono: gli standard
per la codifica dei software, la definizione di una nomenclatura
convenzionale, i formati dei file, gli standard di progettazione dei
dizionari degli schemi e dei dati, gli standard dell’interfaccia
utente, l’interoperatività, l’efficienza della performance del
sistema, la scalabilità, gli standard di sviluppo e verifica, la convalida in
base ai requisiti, i piani di verifica, ed infine, i test di unità,
regressione ed integrazione. |
|
|
|
|
|
|
|
|
PO8.4 - Centralità del Cliente Assicurare che la gestione
della qualità si concentri sui clienti determinandone i requisiti ed
allineandoli agli standard e le pratiche dell’IT. Sono definiti i ruoli
e le responsabilità per la risoluzione dei conflitti tra il
consumatore/utente e la struttura IT. |
|
|
|
|
|
|
|
|
PO8.5 - Miglioramento Continuo
Mantenere e comunicare regolarmente
un piano generale per gestione della qualità che promuova il miglioramento
continuo. |
|
|
|
|
|
|
|
|
PO8.6 - Valutazione,
Monitoraggio e Verifica della Qualità Definire, pianificare ed implementare
attività di valutazione per monitorare che il SGQ venga costantemente
adottato e se ne percepisca il valore aggiunto. Le valutazioni, il
monitoraggio e la registrazione delle informazioni dovrebbero servire al
proprietario del processo per adottare le opportune misure correttive e
preventive. |
|
|
|
|
|
|
|
|
PO9 - Valutare e Gestire i Rischi Informatici [10] Creare e mantenere un sistema
di gestione dei rischi che documenti il livello conosciuto e condiviso dei rischi
informatici aziendali, le strategie per contenerli ed i rischi residui
accettati. Si dovrebbero identificare, analizzare e valutare tutti gli
impatti sugli obiettivi aziendali che potrebbero essere determinati da eventi
imprevisti. Si dovrebbero adottare strategie di contenimento dei rischi per
ridurre il rischio residuo ad un livello minimo concordato. Il risultato
della valutazione dei rischi dovrebbe poter essere compreso dagli stakeholder
ed essere espresso in termini finanziari, per permettere agli stessi
stakeholder di allineare il rischio ad un livello accettabile di tolleranza. |
PO9.1 - Allineamento della
Gestione dei Rischi Aziendali ed Informatici Integrare la governance, il
risk management e il sistema di controllo dell’IT con il sistema di
risk management aziendale, il che implica anche allinearsi con le
disponibilità al rischio dell’azienda ed il suo livello di tolleranza. |
|
|
|
|
|
|
|
PO9.2 - Definizione del
contesto di Rischio Definire il contesto di applicazione
del sistema di valutazione dei rischi al fine di assicurare risultati
appropriati. Ciò implica anche la determinazione di un contesto interno ed
esterno in ciascuna valutazione, le finalità della valutazione ed i criteri
adottati per la valutazione dei rischi. |
|
|
|
|
|
|
|
|
PO9.3 - Identificazione
dell’Evento Identificare tutti gli eventi
(minacce o vulnerabilità) che potenzialmente hanno un impatto sulle finalità
e sull’operatività aziendali, compresi gli aspetti legati al business o
alla normativa, gli aspetti legali, tecnologici, i partner commerciali, il
personale e gli aspetti operativi. Determinare la natura dell’impatto,
positivo e/o negativo, e mantenere questa informazione. |
|
|
|
|
|
|
|
|
PO9.4 - Valutazione dei Rischi Valutare periodicamente la
probabilità e l’impatto di tutti i rischi identificati utilizzando
metodi qualitativi e quantitativi. La probabilità e l’impatto associati
al rischio intrinseco e a quello residuo dovrebbero essere determinati
separatamente, per categoria, in base ad un portafoglio. |
|
|
|
|
|
|
|
|
PO9.5 - Risposta ai Rischi Identificare un proprietario
del rischio e i proprietari dei processi soggetti a quel rischio, sviluppare
e mantenere una pronta capacità di risposta per assicurare che controlli
efficaci e convenienti, e misure di sicurezza, mantengano al minimo
l’esposizione al rischio nel tempo. La risposta al rischio dovrebbe
identificare strategie per evitare, ridurre, condividere o accettare il
rischio. Nello sviluppare la risposta, considerare i costi ed i benefici e
selezionare le risposte che riportino il rischio residuo entro livelli di
tolleranza definiti. |
|
|
|
|
|
|
|
|
PO9.6 - Mantenimento e
Monitoraggio di un Piano d’Azione per la Gestione dei Rischi (Risk
Action Plan) Una volta definite le
priorità, pianificare le attività di controllo dei rischi a tutti i livelli
per implementare le risposte ritenute necessarie, oltre ad identificare
costi, benefici ed i responsabili esecutivi. Fare approvare le azioni
suggerite e fare accettare i rischi residui, assicurando che le azioni
approvate siano di proprietà del/dei proprietari dei processi soggetti a quel
rischio. Monitorare l’esecuzione dei piani e riferire qualsiasi
devianza al senior management. |
|
|
|
|
|
|
|
Dominio :
Acquisizione e realizzazione
Processo [importanza relativa per la sicurezza] |
Attività / controlli |
Possibile intervento migliorativo |
Lavori in corso nell'area |
Business drivers |
Interventi collegati / collegabili |
|||
N |
Entità / costo |
Tempo |
Autonomia |
|||||
AI2 - Acquisire e manutenere il software applicativo [1] Le applicazioni devono essere
rese disponibili come previsto dai requisiti di business. Questo processo
comprende la progettazione delle applicazioni, un’adeguata
considerazione dei controlli applicativi e dei requisiti di sicurezza, lo
sviluppo e configurazione delle soluzioni nel rispetto degli standard. Questo
approccio consente alle organizzazioni di supportare in modo appropriato
l’operatività aziendale attraverso applicazioni informatiche adatte. |
AI2.1 - Progettazione di alto
livello Tradurre i requisiti aziendali
in specifiche di progettazione di alto livello per lo sviluppo del software,
considerando gli indirizzi tecnologici dell’azienda e
l’architettura informativa; ottenere l’approvazione delle
specifiche di progettazione ad alto livello per garantire che queste
soddisfino i requisiti. Durante lo sviluppo o la manutenzione, rieffettuare
la valutazione ogniqualvolta si verifichino delle incongruenze logiche o
tecniche rilevanti. |
|
|
|
|
|
|
|
AI2.2 - Progettazione di
dettaglio Effettuare la progettazione di
dettaglio e definire i requisiti tecnici per il software applicativo.
Definire i criteri di accettazione dei requisiti. Ottenere
l’approvazione dei requisiti per garantire che corrispondano alla
progettazione di alto livello. Durante lo sviluppo o la manutenzione,
rieffettuare la valutazione ogniqualvolta si verifichino delle incongruenze
logiche o tecniche rilevanti. |
|
|
|
|
|
|
|
|
AI2.3 - Controllo e
verificabilità delle applicazioni Tradurre i controlli
funzionali, ove appropriato, in controlli applicativi automatizzati in modo
tale che l’elaborazione sia accurata, completa, tempestiva, autorizzata
e verificabile. |
|
|
|
|
|
|
|
|
AI2.4 - Sicurezza applicativa
e disponibilità delle applicazioni Considerare La sicurezza delle
applicazioni e i requisiti di disponibilità devono rispondere ai rischi
identificati, coerentemente con la classificazione dei dati,
l’architettura della sicurezza delle informazioni ed il profilo di
rischio aziendale. Le problematiche da considerare comprendono la gestione
dei diritti d’accesso e dei privilegi, la protezione delle informazioni
sensibili in tutte le fasi, l’autenticazione e l’integrità delle
transazioni e il ripristino automatico. |
|
|
|
|
|
|
|
|
AI2.5 - Configurazione ed
implementazione del software applicativo acquisito Personalizzare ed implementare
le funzionalità automatizzate acquisite utilizzando procedure di configurazione,
accettazione e test. Le problematiche da considerare comprendono la
validazione delle caratteristiche del prodotto rispetto alle clausole
contrattuali, l’architettura delle informazioni aziendali, le
applicazioni esistenti, l’interoperabilità con gli applicativi e le
basi dati esistenti, l’efficienza e le prestazioni dei sistemi, la
documentazione ed i manuali utente, i piani di integrazione e di test dei
sistemi. |
|
|
|
|
|
|
|
|
AI2.6 - Aggiornamenti significativi
ai sistemi esistenti Seguire un processo di
sviluppo analogo a quello dello sviluppo dei nuovi sistemi nel caso in cui i
cambiamenti rilevanti ai sistemi esistenti comportino una modifica
significativa nel progetto e/o nelle funzionalità del sistema in essere. Le
problematiche da considerare comprendono l’analisi degli impatti, la
giustificazione dell’adeguatezza economica e la gestione dei requisiti. |
|
|
|
|
|
|
|
|
AI2.7 - Sviluppo di software
applicativo Garantire che le funzionalità
automatizzate siano sviluppate coerentemente con le specifiche di
progettazione, secondo gli standard di sviluppo e documentazione e i
requisiti di qualità. Approvare formalmente ogni fase significativa del
processo di sviluppo del software applicativo, dopo aver completato con
successo le revisioni di funzionalità, performance e qualità. Le
problematiche da considerare comprendono l’approvazione che le
specifiche di progetto rispondano ai requisiti aziendali, funzionali e tecnici;
l’approvazione delle richieste di modifica; la conferma che il software
applicativo è compatibile con la produzione e pronto per la migrazione.
Inoltre, garantire che siano identificati e risolti tutti gli aspetti legali
e contrattuali relativi allo sviluppo di software applicativo realizzato da
terze parti. |
|
|
|
|
|
|
|
|
AI2.8 - Garanzia di qualità
del software Sviluppare, assegnare risorse
ed eseguire un piano di verifica della qualità del software per ottenere la qualità
specificata nella definizione dei requisiti e nelle politiche e procedure di
qualità aziendali. Le problematiche da considerare nel piano di verifica
della qualità includono la specifica dei requisiti di qualità e dei processi
di verifica e validazione, includendo l’ispezione, walkthroughs e test. |
|
|
|
|
|
|
|
|
AI2.9 - Gestione dei requisiti
applicativi Garantire che, durante la
progettazione, lo sviluppo e l’implementazione, lo stato dei singoli requisiti
(inclusi tutti i requisiti rifiutati) sia tracciato e che le modifiche ai
requisiti siano approvate attraverso un processo di gestione delle modifiche
predefinito. |
|
|
|
|
|
|
|
|
AI2.10 - Manutenzione del
software applicativo Sviluppare una strategia e
pianificare la manutenzione ed il rilascio delle applicazioni software. Le
problematiche da considerare includono la pianificazione ed il controllo dei
rilasci, la pianificazione delle risorse, la correzione dei bachi e dei difetti,le
migliorie minori, la manutenzione della documentazione, le modifiche in
emergenza, le interdipendenze con altre applicazioni ed infrastrutture, le
strategie di aggiornamento, le condizioni contrattuali, ad esempio, per il
supporto in caso di problemi e per gli aggiornamenti, le revisioni periodiche
rispetto alle necessità aziendali, ai rischi e ai requisiti di sicurezza. |
|
|
|
|
|
|
|
|
AI3 - Acquisire e manutenere l’infrastruttura tecnologica
[2] Le aziende hanno dei processi
per gestire l’acquisizione, l’implementazione e
l’aggiornamento dell’infrastruttura tecnologica. Questo richiede
un approccio basato su dei piani per l’acquisizione, la manutenzione e
la protezione dell’infrastruttura coerente con le strategie
tecnologiche concordate, oltre alla disponibilità di ambienti di sviluppo e
test. Questo approccio garantisce che ci sia un supporto tecnologico continuo
per le applicazioni aziendali. |
AI3.1 - Piano per
l’acquisizione dell’infrastruttura tecnologica Produrre un piano per
l’acquisizione, l’implementazione e la manutenzione
dell’infrastruttura tecnologica che soddisfi i requisiti aziendali
funzionali e tecnici e sia coerente con gli indirizzi tecnologici
dell’organizzazione. |
|
|
|
|
|
|
|
AI3.2 - Protezione e disponibilità
delle risorse di infrastruttura Implementare i controlli
interni, le misure di sicurezza e di verifica durante la configurazione,
l’integrazione e la manutenzione dell’hardware e del software di
infrastruttura, per proteggere le risorse e garantirne la disponibilità e
l’integrità. Le responsabilità per l’uso di componenti critiche
dell’infrastruttura dovrebbero essere chiaramente definite e comprese
da quanti sviluppano e integrano i componenti dell’architettura. Il loro
uso dovrebbe essere monitorato e valutato. |
|
|
|
|
|
|
|
|
AI3.3 - Manutenzione delle
infrastrutture Sviluppare una strategia e un
piano per la manutenzione delle infrastrutture e garantire che le modifiche
siano controllate coerentemente con le procedure aziendali di gestione delle
modifiche. Prevedere verifiche periodiche rispetto ai fabbisogni aziendali,
alle strategie di gestione delle patch e degli aggiornamenti, ai rischi, alla
valutazione delle vulnerabilità e ai requisiti di sicurezza. |
|
|
|
|
|
|
|
|
AI3.4 - Attendibilità
dell’ambiente di test Installare ambienti di
sviluppo e test per supportare efficacemente ed efficientemente i test di
fattibilità e di integrazione di componenti dell’infrastruttura. |
|
|
|
|
|
|
|
|
AI4 - Permettere il funzionamento e l’uso dei sistemi IT
[3] E’ resa disponibile la
conoscenza sui nuovi sistemi. Questo processo richiede la produzione di
documentazione e di manuali per gli utenti e per il personale tecnico, La
fornitura della formazione per assicurare l’utilizzo appropriato e il
funzionamento delle applicazioni e delle infrastrutture. |
AI4.1 - Pianificazione delle
soluzioni operative Sviluppare un piano per
identificare e documentare tutti gli aspetti tecnici, operativi e di utilizzo
dei sistemi in modo che tutti gli interessati, che gestiscono operativamente
o utilizzano o manutengono i sistemi informatici, possano assumere le proprie
responsabilità. |
|
|
|
|
|
|
|
AI4.2 - Trasferimento di
conoscenza al management aziendale Trasferire la conoscenza sui
sistemi al management aziendale per consentir loro di prendere possesso di
sistemi e dati ed inoltre di assumere coscientemente le responsabilità sui
servizi erogati, sulla qualità, sui controlli interni e sui processi di
amministrazione dell’applicazione. |
|
|
|
|
|
|
|
|
AI4.3 - Trasferimento di
conoscenza agli utenti finali Trasferire conoscenze e
competenze per consentire agli utenti finali di usare efficacemente ed
efficientemente il sistema applicativo per supportare i processi aziendali. |
|
|
|
|
|
|
|
|
AI4.4 - Trasferimento di
conoscenza allo staff operativo e di supporto Trasferire conoscenza e
competenze per consentire al personale operativo e di supporto tecnico di
rilasciare, supportare e manutenere il sistema applicativo e
l’infrastruttura associata efficacemente ed efficientemente. |
|
|
|
|
|
|
|
|
AI5 - Approvvigionamento delle risorse IT [1] Le risorse IT, comprendendo
con questa accezione le persone, l’hardware, il software e i servizi
devono essere acquisite. Questo richiede la definizione e
l’applicazione di procedure di approvvigionamento, la selezione dei
venditori, la definizione di accordi contrattuali e l’acquisizione vera
e propria. Operare in questo modo garantisce che l’organizzazione abbia
a disposizione tutte le risorse IT richieste nel momento opportuno e con
costi appropriati. |
AI5.1 - Controllo
dell’approvvigionamento Sviluppare ed agire in
conformità ad un insieme di procedure e standard che siano coerenti con il
processo aziendale di approvvigionamento e con la strategia di acquisizione
per garantire che l’acquisizione di infrastrutture, facilities,
hardware, software e servizi IT soddisfi i requisiti aziendali. |
|
|
|
|
|
|
|
AI5.2 - Gestione del contratto
di fornitura Definire una procedura con cui
istituire, modificare e chiudere i contratti con tutti i fornitori. La
procedura dovrebbe coprire almeno gli aspetti legali, finanziari,
organizzativi, di documentazione, prestazione, sicurezza, proprietà
intellettuale e le responsabilità di chiusura ivi incluse quelle per la
rescissione e quelle relative alle reponsabilità (con inclusione delle
penali). Tutti i contratti e le loro modifiche dovrebbero essere rivisti da
consulenti legali. |
|
|
|
|
|
|
|
|
AI5.3 - Selezione dei
fornitori Selezionare i fornitori
secondo una prassi equa e formale per garantire la scelta attuabile più
appropriata sulla base dei requisiti. I requisiti dovranno essere ottimizzati
in base alle informazioni ricevute dai potenziali fornitori. |
|
|
|
|
|
|
|
|
AI5.4 - Acquisizione di
risorse Garantire che gli interessi
dell’azienda siano salvaguardati in tutti gli accordi contrattuali di
acquisizione. Formalizzare all’interno del contratto i diritti e gli
obblighi di tutte le parti coinvolte nell’acquisizione di software,
risorse per lo sviluppo, infrastrutture e servizi. |
|
|
|
|
|
|
|
|
AI6 - Gestire le modifiche [6] Tutte le modifiche, inclusa la
manutenzione di emergenza e le patch, riguardanti l’infrastruttura e le
applicazioni in ambiente di produzione devono essere gestite formalmente in
modo controllato. Le modifiche (incluse quelle relative a procedure,
processi, parametri di sistema e di servizio) devono essere registrate,
valutate e autorizzate prima dell’implementazione e riviste
confrontandole con i risultati attesi a seguito dell’implementazione.
Questi controlli riducono i rischi di un impatto negativo sulla stabilità o
sull’integrità dell’ambiente di produzione. |
AI6.1 - Standard e procedure
per la gestione delle modifiche Attivare procedure formali di
gestione delle modifiche per trattare in modo standardizzato tutte le
richieste (incluse quelle di manutenzione e le patch) di variazione di:
applicazioni, procedure, processi, parametri di sistema e di servizio e delle
piattaforme sottostanti. |
|
|
|
|
|
|
|
AI6.2 - Valutazione
dell’impatto, definizione delle priorità e autorizzazione Assicurarsi che tutte le
richieste di modifica siano valutate secondo una prassi strutturata e
considerino gli impatti sui sistemi che supportano l’operatività e
sulle loro funzionalità. Questa valutazione dovrebbe includere la
classificazione delle modifiche secondo categorie predefinite e
l’assegnazione di priorità. Prima del passaggio in produzione le modifiche
debbono essere autorizzate dagli appropriati referenti. |
|
|
|
|
|
|
|
|
AI6.3 - Modifiche in stato di
emergenza Stabilire un processo per
definire, proporre, valutare e autorizzare le modifiche in stato di emergenza
che non seguono il processo di gestione delle modifiche predefinito. La
documentazione e il test dovrebbero essere comunque effettuati, ancorché dopo
l’implementazione della modifica in stato di emergenza. |
|
|
|
|
|
|
|
|
AI6.4 - Registrazioni e
informative sullo status della modifica Stabilire un sistema di
registrazioni e di informative per mantenere aggiornati i richiedenti della
modifica e tutte le parti interessate circa lo stato della modifica ad
applicazioni, procedure, processi, parametri di sistema e di servizio e alle
piattaforme sottostanti. |
|
|
|
|
|
|
|
|
AI6.5 - Chiusura delle
modifiche e documentazione Aggiornare, ogni qualvolta sono
implementate delle modifiche al sistema, la documentazione di sistema, utente
e le procedure. Stabilire un processo di revisione per garantire la completa
implementazione di ciascuna delle modifiche. |
|
|
|
|
|
|
|
|
AI7 - Installare e certificare le soluzioni e le modifiche [2] È necessario che i nuovi
sistemi siano resi operativi quando lo sviluppo è completato. Questo richiede
un test appropriato in un ambiente dedicato con dei dati di test
significativi, la definizione del rilascio e delle istruzioni per la
migrazione, la pianificazione dei rilasci e dell’effettivo passaggio in
produzione, la revisione post implementazione. Questo garantisce che i
sistemi applicativi siano allineati con le aspettative e i risultati
concordati. |
AI7.1 - Formazione Formare il personale dei
dipartimenti utente interessati e la funzione IT che gestisce le attività
operative coerentemente con il piano di formazione e implementazione e la
documentazione relativa. Le attività di formazioni devono essere parte di
ogni progetto di sviluppo, di realizzazione o modifica dei sistemi
informativi. |
|
|
|
|
|
|
|
AI7.2 - Pianificazione dei
test Definire un piano dei test e
ottenerne l’approvazione dalle controparti rilevanti. Il piano dei test
è basato sugli standard dell’azienda e definisce ruoli, responsabilità
e criteri per la determinazione del superamento del test. Il piano considera
la preparazione dei test (includendovi la preparazione del sito), i requisiti
di formazione, l’installazione o l’aggiornamento di un ambiente
di test ben individuato, la pianificazione / esecuzione / documentazione /
conservazione dei casi di test, la gestione e la correzione degli errori e le
modalità di approvazione formale. Partendo da una valutazione dei rischi
connessi a guasti del sistema ed errori di implementazione, il piano dovrebbe
includere i requisiti relativi alle prestazioni, alle situazioni di stress,
all’usabilità, ai test pilota e di sicurezza. |
|
|
|
|
|
|
|
|
AI7.3 - Piano di
implementazione Stabilire un piano di
implementazione e ottenerne l’approvazione dalle controparti rilevanti.
Il piano definisce la progettazione delle fasi di rilascio, la costruzione dei
package di rilascio, la messa in esercizio / installazione delle procedure,
la gestione degli incidenti, il controllo sulla distribuzione (inclusi gli
strumenti), l’archiviazione del software, la verifica dei rilasci e la
documentazione delle modifiche. Il piano dovrebbe includere anche le
soluzioni per il ripristino della versione precedente dei sistemi. |
|
|
|
|
|
|
|
|
AI7.4 - Ambiente di test Realizzare un ambiente di test
separato per eseguire il test. Questo ambiente, per consentire un test
adeguato, dovrebbe rispecchiare l’ambiente di produzione futuro (per
esempio misure di sicurezza, controlli interni e carichi di lavoro simili).
Dovrebbero essere attivate delle procedure per garantire che i dati usati
nell’ambiente di test siano rappresentativi dei dati (ripuliti dove
necessario) che saranno presenti nell’ambiente di produzione. Prevedere
misure adeguate per prevenire la divulgazione dei dati di test personali e/o
sensibili. La documentazione dei test effettuati e i relativi risultati
dovrebbero essere conservati. |
|
|
|
|
|
|
|
|
AI7.5 - Conversione del
sistema e dei dati Garantire che i metodi di
sviluppo aziendali consentano lo svolgimento delle attività necessarie per
tutti i progetti di sviluppo, implementazione e modifica, e che tutti gli
elementi necessari quali hardware, software, dati delle transazioni, file
principali, copie ed archivi, interfacce con gli altri sistemi, procedure,
documentazione di sistema, ecc., siano convertiti dal vecchio sistema al
nuovo secondo il piano prestabilito. Dovrebbero essere sviluppate e mantenute
evidenze (relative alla situazione precendente e successiva alla conclusione
delle attività di conversione) che consentano la verifica dei risultati delle
attività di conversione. Dovrebbe essere effettuata una verifica dettagliata
delle prime elaborazioni del nuovo sistema da parte dei responsabili
aziendali del sistema per confermare il successo della conversione. |
|
|
|
|
|
|
|
|
AI7.6 - Test delle modifiche Garantire che le modifiche
siano testate secondo il piano di accettazione definito e siano supportate da
una valutazione dell’impatto e delle risorse che includa la
misurazione, da parte di un gruppo di test indipendente (dai realizzatori),
delle prestazioni in un ambiente di test separato prima che
dell’utilizzo nell’ambiente operativo di produzione. Si può
considerare la possibilità di inserire nel piano un test parallelo o un test
pilota. I controlli di sicurezza dovrebbero essere testati e valutati prima
del rilascio, cosicché l’efficacia delle misure di sicurezza possa
essere certificata. Dovrebbero essere sviluppati e testati anche i piani di
ripristino della versione precedente del sistema prima del passaggio in
produzione delle modifiche. |
|
|
|
|
|
|
|
|
AI7.7 - Test di accettazione
finale Garantire che le procedure
prevedano, come parte del test finale di accettazione o di garanzia di
qualità dei sistemi informativi nuovi o modificati, una valutazione ed
un’approvazione formali dei risultati dei test da parte della direzione
del/i dipartimento/i utente interessato/i e della funzione IT. I test
dovrebbero coprire tutte le componenti del sistema informativo (per esempio:
il software applicativo, l’infrastruttura, le procedure tecniche e
utente) e garantire che i requisiti di sicurezza delle informazioni siano
soddisfatti da tutte le componenti. I dati dei test dovrebbero essere
archiviati come traccia delle attività svolte e per eventuali test futuri. |
|
|
|
|
|
|
|
|
AI7.8 - Passaggio in
produzione Dopo i test, controllare il
passaggio del sistema modificato all’ambiente operativo, garantendo
l’allineamento con il piano di implementazione. Ottenere
l’approvazione da tutte el parti coinvolte ed in particolare dagli
utenti, da system owner e dai responsabili operativi. Se opportuno, attivare
in parallelo, per un certo periodo, il vecchio ed il nuovo sistema
confrontandone comportamenti e risultati. |
|
|
|
|
|
|
|
|
AI7.9 - Verifica
post-implementazione Stabilire delle procedure in linea
con gli standard aziendali di sviluppo e modifica che richiedano una verifica
post-implementazione del sistema informativo in produzione per valutare e
rendicontare se le modifiche soddisfano i requisiti definiti e generano i
benefici previsti nella modalità economicamente più efficiente. |
|
|
|
|
|
|
|
Dominio :
Erogazione e Assistenza
Processo [importanza relativa per la sicurezza] |
Attività / controlli |
Possibile intervento migliorativo |
Lavori in corso nell'area |
Business drivers |
Interventi collegati / collegabili |
|||
N |
Entità / costo |
Tempo |
Autonomia |
|||||
DS1 - Definire e gestire i livelli di servizio [4] Una comunicazione efficace tra
la Direzione IT ed i clienti interni relativamente ai servizi richiesti è
resa possibile attraverso un accordo sui servizi IT e sui livelli di servizio
e una loro definizione ben documentata. Questo processo comprende anche il
monitoraggio e il reporting tempestivo agli stakeholder sul raggiungimento
dei livelli di servizio. Questo processo facilita l’allineamento tra i
servizi IT e i relativi requisiti aziendali. |
DS1.1 - Modello per la
gestione dei livelli di servizio Definire un modello di riferimento
che stabilisca un processo formalizzato di gestione dei livelli di servizio
fra i clienti ed i fornitori del servizio. Questo modello di riferimento
dovrebbe mantenere un allineamento continuo con le priorità e i requisiti
aziendali e dovrebbe facilitare la comprensione comune del servizio fra il
cliente ed i fornitori. Il modello di riferimento dovrebbe comprendere i
processi per la definizione dei requisiti dei servizi e dei servizi stessi,
degli accordi sui livelli di servizio (SLA), degli accordi sui livelli
operativi (OLA) e delle fonti di finanziamento. Questi attributi dovrebbero
essere organizzati in un catalogo dei servizi. Il modello di riferimento
dovrebbe definire la struttura organizzativa per la gestione dei livelli di
servizio identificando i ruoli, le attività e le responsabilità dei clienti e
dei fornitori, sia interni sia esterni. |
|
|
|
|
|
|
|
DS1.2 - Definizione dei
servizi Definire i servizi IT
basandosi sulle caratteristiche e sui requisiti dei servizi aziendali. Assicurarsi
che questi siano organizzati e mantenuti centralmente mediante la
realizzazione di un catalogo del portfolio dei servizi. |
|
|
|
|
|
|
|
|
DS1.3 - Accordi sui livelli di
servizio Definire e concordare gli accordi
sui livelli di servizio (SLA) per tutti i servizi IT critici basandosi sui
requisiti posti dal cliente e sulle potenzialità dell’IT. Gli accordi
dovrebbero comprendere: il mandato dei clienti, i requisiti di supporto ai
servizi, le metriche qualitative e quantitative per misurare i servizi
sottoscritti dagli stakeholder, le condizioni finanziarie e commerciali
qualora applicabili, i ruoli e le responsabilità compresa la supervisione
degli SLA. Elementi da considerare sono la disponibilità, l’affidabilità,
le prestazioni, la capacità di crescita, i livelli di assistenza, il piano di
continuità, la sicurezza e i limiti relativamente a nuove richieste. |
|
|
|
|
|
|
|
|
DS1.4 - Accordi sui livelli
operativi Definire i livelli operativi in
modo tale da spiegare come i servizi saranno tecnicamente erogati per
supportare gli SLA in modo ottimale. Gli OLA dovrebbero descrivere i processi
tecnici in termini comprensibili per il fornitore e ciascuno di essi potrebbe
supportare diversi SLA. |
|
|
|
|
|
|
|
|
DS1.5 - Monitoraggio e
reporting dei livelli di servizio conseguiti Monitorare sistematicamente i
criteri seguiti per la definizione dei livelli di prestazione dei servizi. I report,
riguardanti il raggiungimento dei livelli di servizio, dovrebbero essere
forniti in un formato comprensibile per gli stakeholder. I controlli
statistici dovrebbero essere attivati e analizzati per identificare andamenti
positivi e/o negativi di ciascun servizio o dei servizi nel loro complesso. |
|
|
|
|
|
|
|
|
DS1.6 - Revisione degli
accordi sui livelli di servizio e dei contratti Revisionare regolarmente gli
accordi sui livelli di servizio e i relativi contratti con i fornitori di servizi,
sia interni sia esterni, per assicurarsi che siano efficaci, aggiornati e che
i cambiamenti nei requisiti siano stati presi adeguatamente in
considerazione. |
|
|
|
|
|
|
|
|
DS2 - Gestire i servizi di terze parti [4] La necessità di assicurare che
i servizi forniti da terze parti (fornitori, rivenditori, partner) siano
conformi ai requisiti aziendali comporta l’istituzione di un efficace
processo di gestione delle terze parti. Questo processo è attuato sia attraverso
l’inserimento negli accordi con le terze parti di una chiara
definizione dei ruoli, delle responsabilità e delle aspettative, sia
attraverso la revisione ed il monitoraggio di tali accordi per garantirne
l’efficacia e la conformità. Un’efficace gestione dei servizi di
terze parti minimizza i rischi aziendali associati a mancate o parziali
prestazioni dei fornitori. |
DS2.1 - Identificazione delle
relazioni con tutti i fornitori Individuare tutti i fornitori
di servizi e classificarli in funzione del tipo di fornitura, importanza e
criticità. Mantenere aggiornata la documentazione formale delle
caratteristiche tecniche ed organizzative contenenti: ruoli e responsabilità,
finalità, erogazioni attese e credenziali dei rappresentanti di questi
fornitori. |
|
|
|
|
|
|
|
DS2.2 - Gestione delle
relazioni con i fornitori Formalizzare il processo di
gestione del rapporto intrattenuto con ciascun fornitore. Il responsabile del
rapporto con il fornitore dovrebbe relazionare sui problemi esistenti con i
clienti e con il fornitore e assicurare la qualità della relazione basata
sulla fiducia reciproca e sulla trasparenza ( ad esempio attraverso accordi
sui livelli di servizio) |
|
|
|
|
|
|
|
|
DS2.3 - Gestione del rischio
relativo ai fornitori Individuare e mitigare il
rischio relativo alla capacità dei fornitori di continuare ad erogare il
servizio con: efficacia, sicurezza, efficienza e continuità. Assicurare che i
contratti siano in linea con gli standard di mercato e conformi ai requisiti previsti
da leggi e norme. La gestione dei rischi dovrebbe inoltre considerare: gli
accordi di non divulgazione (NDA- Non Disclosure Agreement), le clausole di
garanzia (ad esempio sui sorgenti), la continuità dei fornitori critici, la
conformità ai requisiti di sicurezza, la disponibilità di fornitori
alternativi, le penali ed i premi, ecc. |
|
|
|
|
|
|
|
|
DS2.4 - Monitoraggio delle
prestazioni dei fornitori Stabilire un processo di monitoraggio
dei servizi erogati per assicurare che i fornitori siano conformi agli
attuali requisiti aziendali e continuino ad essere aderenti ai contratti ed
ai livelli di servizio contrattualizzati e che le prestazioni siano
competitive rispetto a fornitori alternativi ed alle condizioni di mercato. |
|
|
|
|
|
|
|
|
DS3 - Gestire le prestazioni e la capacità produttiva [1] La necessità di gestire le
prestazioni e la capacità produttiva delle risorse IT richiede un processo di
revisione periodica delle prestazioni e della capacità produttiva delle
risorse IT. Questo processo include la previsione delle necessità future
basata sui requisiti relativi al carico di lavoro, alla memorizzazione e alle
emergenza. Questo processo fornisce la garanzia che le risorse informative
supportano i requisiti di business e sono continuamente disponibili. |
DS3.1 - Pianificazione delle
prestazioni e della capacità produttiva Definire un processo di
pianificazione per il riesame delle prestazioni e della capacità produttiva
delle risorse IT, per assicurare che siano disponibili prestazioni e capacità
produttive ad un costo giustificabile, per far fronte ai carichi di lavoro
concordati come determinato dagli accordi sui livelli di servizio. La pianificazione
della capacità produttiva e delle prestazioni dovrebbe utilizzare appropriate
tecniche di modellizzazione per produrre un modello delle performance attuali
e previste, della capacità produttiva e del throughput delle risorse IT. |
|
|
|
|
|
|
|
DS3.2 - Capacità produttiva e
prestazioni attuali Valutare le attuali capacità
produttive e le prestazioni delle risorse IT per determinare se esistono una
sufficiente capacità produttiva e una sufficiente performance a fronte dei
livelli di servizio concordati. |
|
|
|
|
|
|
|
|
DS3.3 - Capacità produttiva e
prestazioni future Effettuare ad intervalli
regolari previsioni sulle prestazioni e sulla capacità produttiva delle risorse
IT, per minimizzare il rischio di non fornitura del servizio a causa di una
insufficiente capacità produttiva o prestazioni ridotte, e per identificare
anche la capacità produttiva in eccesso per un possibile reimpiego.
Identificare i trend dei carichi di lavoro e determinare le relative
previsioni per contribuire alla pianificazione delle prestazioni e della
capacità produttiva. |
|
|
|
|
|
|
|
|
DS3.4 - Disponibilità delle
risorse IT Fornire la capacità produttiva
e le performance richieste, prendendo in considerazione aspetti come il
normale carico, le emergenze, le esigenze di memorizzazione e il ciclo di
vita delle risorse IT. Dovrebbero essere definite delle linee guida per
l’assegnazione delle priorità alle attività, la gestione della
tolleranza ai guasti e le modalità di allocazione delle risorse. La Direzione
dovrebbe assicurare che i piani di emergenza forniscano una adeguata
soluzione per la disponibilità, la capacità produttiva e le prestazioni di
ciascuna risorsa IT. |
|
|
|
|
|
|
|
|
DS3.5 - Monitoraggio e
rapporti Monitorare continuamente le
prestazioni e la capacità produttiva delle risorse IT. I dati raccolti hanno
due finalità: Mantenere e mettere a punto le prestazioni attuali
dell’IT e fornire soluzioni per problematiche come la capacità di
resistenza o ripresa (resilience), le emergenze, i carichi di lavoro attuali
e previsti, i trend delle esigenze di memorizzazione e l’acquisizione
pianificata delle risorse. Rendicontare la disponibilità dei servizi erogati
all’azienda come richiesto dagli SLA. Allegare a tutte le eccezioni
documentate le raccomandazioni sulle azioni correttive. |
|
|
|
|
|
|
|
|
DS4 - Assicurare la continuità del servizio [3] La necessità di assicurare la continuità
dei servizi IT richiede lo sviluppo, la manutenzione ed il test del piano di
continuità IT, l’utilizzo di sistemi di archiviazione dei dati per il
ripristino del sistema collocati a sufficiente distanza dal sito e
l’addestramento periodico al piano di continuità. Un efficace processo
di continuità del servizio minimizza la probabilità e l’impatto di una
grave interruzione del servizio IT per processi e funzioni aziendali chiave. |
DS4.1 - Modello di riferimento
della continuità IT Sviluppare un modello di
riferimento per la continuità IT che supporti la gestione della continuità
aziendale attraverso un processo coerente. L’obiettivo del modello di
riferimento è di aiutare a determinare le richieste di capacità di ripresa
delle infrastrutture e guidare lo sviluppo di un piano di Disaster Recovery e
un piano di emergenza IT. Il modello di riferimento dovrebbe indirizzare la
struttura organizzativa nella gestione della continuità operativa, includendo
ruoli, compiti e responsabilità dei fornitori di servizi interni ed esterni,
del loro management e dei loro clienti e il processo di pianificazione che
crea le regole e le strutture coinvolte nella documentazione, nel test del
Disaster Recovery e del piano di emergenza IT. Il piano dovrebbe anche
indirizzare aspetti come l’identificazione delle risorse critiche, il
controllo ed i rapporti sulla disponibilità delle risorse critiche, i
processi alternativi e i principi di salvataggio e ripristino. |
|
|
|
|
|
|
|
DS4.2 - Piano di continuità IT Sviluppare il piano di
continuità IT basandosi sulla struttura di riferimento e finalizzandolo alla
riduzione dell’impatto o della grave interruzione dei processi e delle
funzioni aziendali chiave. I piani dovrebbero essere basati sulla comprensione
e valutazione del rischio di potenziali impatti sul business e indirizzare i
requisiti sulla capacità di ripresa, sui processi alternativi e sulla
capacità di ripristino di tutti i servizi IT critici. I piani dovrebbero
trattare i seguenti argomenti: linee guida per l’utilizzo, ruoli e
responsabilità, procedure, processi di comunicazione e approccio al test. |
|
|
|
|
|
|
|
|
DS4.3 - Risorse critiche IT Concentrare l’attenzione
sugli elementi più critici del piano di continuità per costruire capacità di ripresa
(resilienza) e stabilire delle priorità per le situazioni di ripristino.
Evitare di disperdere l’impegno nel ripristino di elementi poco
rilevanti e assicurare risposte e ripristini in linea con le priorità
aziendali, assicurare allo stesso tempo che i costi siano mantenuti ad un
livello accettabile e conformi a regolamenti e requisiti contrattuali.
Considerare i fabbisogni di resilienza, di risposta e di ripristino per
differenti livelli, p. e. da 1 a 4 ore, da 4 a 24, più di 24 ore e per
periodi nei quali vengono svolte operazioni aziendali critiche. |
|
|
|
|
|
|
|
|
DS4.4 - Aggiornamento del
piano di continuità IT Incoraggiare la Direzione IT a
definire ed eseguire procedure di controllo dei cambiamenti per assicurare che
il piano di continuità IT sia mantenuto aggiornato e rifletta continuamente i
requisiti aziendali in essere. Comunicare i cambiamenti nelle procedure e
nelle responsabilità in modo chiaro e in maniera tempestiva. |
|
|
|
|
|
|
|
|
DS4.5 - Verifica del piano di
continuità IT Verificare regolarmente il
piano di continuità IT per assicurare che i sistemi IT possano essere
effettivamente ripristinati, i difetti siano riscontrati e il piano rimanga
efficace. Questo richiede un’attenta preparazione, documentazione e
relazione sui risultati dei test e, in base ai risultati,
l’implementazione di un piano di azione. Comprendere nei test di
ripristino le situazioni relative a singole applicazioni, a scenari di test
integrato, a test end-to-end, a test integrati con i fornitori. |
|
|
|
|
|
|
|
|
DS4.6 - Addestramento sul
piano di continuità IT Fornire a tutte la parti
interessate regolari sessioni di addestramento relativamente alle procedure, ai
ruoli e alle responsabilità in caso di incidente o disastro. Verificare e
migliorare l’addestramento in accordo con i risultati dei test di
emergenza. |
|
|
|
|
|
|
|
|
DS4.7 - Distribuzione del
piano di continuità IT Verificare se esiste e se è operante
una strategia di distribuzione del piano per assicurare che il piano sia
distribuito in modo appropriato e sicuro, e che sia disponibile alle parti
interessate debitamente autorizzate quando e dove necessario. Dovrebbe essere
posta attenzione nel rendere i piani accessibili, qualunque sia lo scenario
di disastro. |
|
|
|
|
|
|
|
|
DS4.8 - Recupero e ripristino
dei servizi IT Pianificare le azioni che
devono essere intraprese nel periodo in cui i servizi IT devono essere recuperati
e ripristinati. Questo potrebbe includere l’attivazione di siti
alternativi (backup sites), l’attivazione di processi alternativi, la
comunicazione di procedure di ripristino alla clientela ed al personale
interessato, ecc. Assicurare che l’azienda sia consapevole dei tempi di
ripristino e degli investimenti tecnologici necessari per supportare le
esigenze di recupero e ripristino aziendali. |
|
|
|
|
|
|
|
|
DS4.9 - Conservazione dei
supporti di backup in ubicazione remota Conservare in un’ubicazione
remota tutti i supporti critici di backup, la documentazione e le altre
risorse IT necessarie per il ripristino IT e per l’attuazione del piano
di continuità aziendale. Determinare il contenuto dei supporti di backup
necessari, in collaborazione con i proprietari dei processi aziendali e con
il personale IT. La Direzione del servizio di archiviazione remota dovrebbe
conformarsi alla politica di classificazione dei dati ed alle pratiche
aziendali di archiviazione dei media. La Direzione IT dovrebbe assicurare che
le attrezzature dell’ubicazione remota siano periodicamente analizzate,
almeno annualmente, sia per quanto riguarda il contenuto che le misure di
sicurezza e protezione ambientale. Assicurare la compatibilità
dell’hardware e del software per ripristinare i dati archiviati e
verificare e aggiornare periodicamente i dati archiviati. |
|
|
|
|
|
|
|
|
DS4.10 - Revisione
Post-Ripristino Determinare se la Direzione IT
ha previsto procedure per valutare l’adeguatezza del piano, in
riferimento al ripristino della funzione IT a seguito di un disastro, e
l’aggiornamento del piano coerentemente alle esigenze emerse
nell’attività di ripristino. |
|
|
|
|
|
|
|
|
DS5 - Garantire la sicurezza dei sistemi [8] La necessità di mantenere
l’integrità delle informazioni e la protezione delle risorse IT
richiede un processo di gestione della sicurezza. Questo processo compende la
definizione e l’aggiornamento dei ruoli e delle responsabilità sulla
sicurezza IT, delle politiche, degli standard e delle procedure. La gestione
della sicurezza comprende anche il monitoraggio della sicurezza, lo
svolgimento di test periodici e l’implementazione delle azioni
correttive a fronte di punti di debolezza o incidenti di sicurezza
identificati. Una gestione efficace della sicurezza protegge tutte le risorse
IT al fine di minimizzare gli impatti aziendali derivanti da vulnerabilità e
da incidenti. |
DS5.1 - Gestione della
sicurezza IT Gestire la sicurezza IT al più
alto livello aziendale appropriato, così che la gestione degli interventi di
sicurezza sia in linea con i fabbisogni aziendali |
|
|
|
|
|
|
|
DS5.2 - Piano di sicurezza IT Tradurre le esigenze aziendali
di business, di rischio e di conformità in un piano generale di sicurezza IT,
tenendo in considerazione l’infrastruttura IT e la cultura della
sicurezza. Assicurarsi che il piano sia realizzato attraverso politiche e
procedure di sicurezza insieme ad appropriati investimenti in servizi,
personale, software e hardware. Comunicare le politiche e le procedure di
sicurezza agli stakeholder e agli utenti. |
|
|
|
|
|
|
|
|
DS5.3 - Gestione delle
Identità Assicurare che tutti gli
utenti (interni, esterni o temporanei) e le loro attività sui sistemi IT
(applicazioni aziendali, sistemi operativi, sviluppo e manutenzione) siano
identificati in modo univoco. Abilitare le identità degli utenti attraverso
meccanismi di autenticazione. Assicurare che i diritti di accesso ai sistemi
ed ai dati siano in linea con le necessità aziendali, definite e documentate,
e le esigenze di lavoro siano coerenti all’identità degli utenti.
Assicurarsi che i diritti di accesso siano richiesti dalla Direzione Utente,
approvati dal proprietario del sistema e implementati dalla persona
responsabile della sicurezza. Mantenere gli identificativi utente e i diritti
di accesso in modo centralizzato. Sviluppare tecniche operative e procedure
economicamente giustificate e mantenerle aggiornate per definire
l’identificazione degli utenti, l’implementazione
dell’autenticazione e l’applicazione dei diritti di accesso. |
|
|
|
|
|
|
|
|
DS5.4 - Gestione degli
identificativi degli utenti. Stabilire delle regole per la richiesta,
la definizione, il rilascio, la sospensione, la modifica e la revoca degli
identificativi utente ed i relativi privilegi attraverso un insieme di
procedure per la gestione degli identificativi utente, compresa una procedura
di approvazione e concessione dei privilegi di accesso basata sul
proprietario dei dati o dei sistemi. Queste procedure dovrebbero essere
applicata per tutti gli utenti, inclusi gli amministratori (utenti
privilegiati), utenti interni ed esterni, sia per i casi normali sia di emergenza.
Diritti e obblighi relativi agli accessi alle informazioni e ai sistemi
aziendali dovrebbero essere stabiliti contrattualmente per tutti i tipi di
utente. Eseguire una sistematica revisione di tutti gli identificativi ed i
relativi privilegi. |
|
|
|
|
|
|
|
|
DS5.5 - Verifica, sorveglianza
e monitoraggio della sicurezza Testare e controllare in modo
proattivo l’implementazione della sicurezza IT. La sicurezza IT
dovrebbe essere riaccreditata periodicamente per assicurare il mantenimento
del livello della sicurezza delle informazioni approvato per l’azienda.
Esiste una funzione di registrazione e monitoraggio che consente una rapida
prevenzione e/o rilevazione, e conseguentemente una pronta rendicontazione di
attività non usuali e/o anormali che potrebbe essere necessario trattare. |
|
|
|
|
|
|
|
|
DS5.6 - Definizione degli
incidenti di sicurezza Definire chiaramente e
comunicare le caratteristiche dei potenziali incidenti sulla sicurezza così
che possano essere correttamente classificati e trattati dal processo di
gestione dei problemi e degli incidenti. |
|
|
|
|
|
|
|
|
DS5.7 - Protezione della
tecnologia sulla sicurezza Rendere la tecnologia
collegata alla sicurezza resistente alle manomissioni e non divulgare
inutilmente la documentazione sulla sicurezza. |
|
|
|
|
|
|
|
|
DS5.8 - Gestione delle chiavi
crittografiche Verificare che siano definite e
messe in atto politiche e procedure per organizzare la generazione, modifica,
revoca, distruzione, distribuzione, certificazione, memorizzazione,
immissione, uso e archiviazione delle chiavi crittografiche per assicurare la
protezione delle chiavi da modifiche e da divulgazioni non autorizzate. |
|
|
|
|
|
|
|
|
DS5.9 - Prevenzione,
rilevazione e correzione del sofware malevolo Mettere in atto misure
preventive, di rilevazione e correzione (specialmente l’aggiornamento delle
patch di sicurezza e il controllo dei virus) presso tutta
l’organizzazione per proteggere i sistemi informativi e le tecnologie
da malware (ad esempio virus, worms, spyware, spam). |
|
|
|
|
|
|
|
|
DS5.10 - Sicurezza della Rete Utilizzare le tecniche di
sicurezza e le relative procedure di gestione (e.g. firewalls, dispositivi di
sicurezza, segmentazione della rete e rilevazione delle intrusioni) per
autorizzare l’accesso ed il controllo del flusso di informazioni da e
per la rete. |
|
|
|
|
|
|
|
|
DS5.11 - Scambio di dati
sensibili Effettuare le transazioni con
dati sensibili solo su percorsi di fiducia o ambienti controllati per
assicurare l’autenticità del contenuto, la dimostrazione di chi ha
avviato la transazione e di chi l’ha ricevuta, e il non ripudio da
parte del mittente |
|
|
|
|
|
|
|
|
DS9 - Gestione della configurazione [1] Assicurare l’integrità
delle configurazioni hardware e software richiede che sia implementato ed
aggiornato un repository delle configurazioni completo e accurato. Questo
processo include la raccolta delle informazioni di configurazione iniziali,
la definizione di parametri di base, la verifica e l’audit delle
configurazioni, e all’occorrenza, l’aggiornamento del repository
di configurazione. Una gestione efficace delle configurazioni permette di
ottenere una maggiore disponibilità dei sistemi, minimizza la perdita di
produzione e risolve più rapidamente i problemi. |
DS9.1 - Gestione del
repository di configurazione e dei parametri base Stabilire uno strumento di
supporto e un repository centrale che contenga tutte le informazioni
rilevanti sugli elementi di configurazione. Monitorare e registrare tutti gli
asset ed i cambiamenti agli stessi. Dovrebbe essere gestito uno schema base
di elementi di configurazione per ogni sistema o servizio come punto di
controllo a cui ritornare dopo le modifiche. |
|
|
|
|
|
|
|
DS9.2 - Identificazione ed
aggiornamento degli elementi di configurazione Stabilire procedure per
supportare la gestione e la registrazione in log di tutti i cambiamenti al
repository delle configurazioni. Integrare queste procedure con quelle di
gestione del cambiamento, gestione degli incidenti e dei problemi. |
|
|
|
|
|
|
|
|
DS9.3 - Revisione
dell’integrità delle configurazioni Rivedere in modo regolare gli
elementi di configurazione per confermare e verificare l’integrità dei
dati di configurazione attuali e storici. Rivedere periodicamente rispetto
alla politica di utilizzo del software, l’esistenza di qualsiasi
software personale o senza licenza, o di ogni elemento di software in eccesso
rispetto ai contratti di licenza attuali. Errori e difformità dovrebbero
essere resi noti, documentati e corretti. |
|
|
|
|
|
|
|
|
DS10 - Gestione dei problemi [1] Una efficace gestione dei
problemi richiede l’identificazione e la classificazione dei problemi,
l’analisi delle cause di base e la risoluzione dei problemi. Il
processo di gestione dei problemi include anche l’identificazione di
raccomandazioni per il miglioramento, l’aggiornamento delle
registrazioni dei problemi e la revisione dello stato delle azioni
correttive. Un efficace processo di gestione dei problemi massimizza la
disponibilità dei sistemi, migliora i livelli di servizio, riduce i costi e
migliora la soddisfazione e la convenienza dei clienti. |
DS10.1 - Identificazione e
classificazione dei problemi Implementare i processi di rendicontazione
e classificare i problemi che sono stati identificati come parte della
gestione degli incidenti. I passi inerenti la classificazione dei problemi
sono simili a quelli di classificazione degli incidenti; è necessario
determinare la categoria, l’impatto, l’urgenza e la priorità. I
problemi dovrebbero essere categorizzati in modo appropriato in gruppi o
domini correlati (ad esempio hardware, software, software di supporto).
Questi gruppi possono corrispondere alle responsabilità organizzative di
utenti e clienti, e dovrebbero essere la base per allocare i problemi al
personale di supporto. |
|
|
|
|
|
|
|
DS10.2 - Tracciamento e
risoluzione dei problemi Assicurare che il sistema di gestione
dei problemi fornisca adeguati strumenti di audit trail che permettano di
tracciare, analizzare e determinare le principali cause di tutti i problemi
rendicontati considerando: Tutti gli elementi di configurazione associati
Problemi e incidenti di grandi dimensioni Errori conosciuti e sospettati
Tracciamento del trend dei problemi Identificare ed attivare soluzioni
sostenibili indirizzando le principali cause e le crescenti richieste di
cambiamento attraverso il prestabilito processo di gestione del cambiamento.
Attraverso il processo di risoluzione, il gestore dei problemi dovrebbe
ottenere rapporti regolari dalla gestione delle modifiche sulla risoluzione
di problemi ed errori. Il gestore dei problemi dovrebbe monitorare con
continuità l’impatto dei problemi e degli errori conosciuti sui servizi
agli utenti. Nel caso in cui questo impatto diventi critico, il gestore dei
problemi dovrebbe scalare il problema, eventualmente comunicandolo ad un
comitato appropriato per incrementare la priorità della richiesta di modifica
(RFC) o se appropriata per implementare una modifica urgente. Il corso della
risoluzione dei problemi dovrebbe essere monitorato tenendo in cosiderazione
gli SLA. |
|
|
|
|
|
|
|
|
DS10.3 - Chiusura dei problemi Mettere in opera una procedura
per chiudere la registrazione di un problema o dopo la conferma di
eliminazione con successo degli errori conosciuti o dopo l’accordo con
l’azienda su come gestire il problema in modo alternativo. |
|
|
|
|
|
|
|
|
DS10.4 - Integrazione della
gestione del cambiamento, della configurazione e dei problemi Per assicurare una gestione
efficace di problemi e rendere possibili i miglioramenti, integrare i
processi correlati di gestione del cambiamento, della configurazione e dei
problemi. |
|
|
|
|
|
|
|
|
DS11 - Gestione dei dati [3] Una gestione efficace dei dati
richiede l’identificazione dei requisiti dei dati. Il processo di
gestione dei dati include anche lo stabilire procedure efficaci per gestire
la librerie dei supporti di memorizzazione, il salvataggio e il ripristino
dei dati ed un’appropriata eliminazione dei supporti di memorizzazione.
Un efficace processo di gestione dei dati aiuta ad assicurare la qualità,
tempestività e disponibilità dei dati di business. |
DS11.1 - Requisiti di business
per la gestione dei dati Verificare che tutti i dati
richiesti per le elaborazioni siano ricevuti e processati completamente,
accuratamente e tempestivamente, e tutti gli output siano distribuiti,
coerentemente con i requisiti definiti dalle funzioni di business. Supportare
adeguatamente i requisiti di riavvio e rielaborazione dei dati. |
|
|
|
|
|
|
|
DS11.2 - Predisposizione di
modalità operative per la memorizzazione e la conservazione dei dati Definire e implementare
procedure per una efficiente ed efficace memorizzazione, mantenimento e
conservazione dei dati, al fine di raggiungere gli obiettivi aziendali ed
essere conforme alla policy di sicurezza aziendale e ai requisiti legali |
|
|
|
|
|
|
|
|
DS11.3 - Sistema di gestione
della libreria dei supporti di memorizzazione Definire e implementare
procedure per mantenere un inventario dei supporti di memorizzazione e di
conservazione ed assicurare la loro usabilità ed integrità. |
|
|
|
|
|
|
|
|
DS11.4 - Eliminazione Definire e implementare
procedure per assicurare che i requisiti di business per la protezione dei
dati sensibili e del software siano soddisfatti quando i dati e
l’hardware siano eliminati o trasferiti. |
|
|
|
|
|
|
|
|
DS11.5 - Salvataggio e
Ripristino Definire e implementare
procedure per il salvataggio e ripristino di sistemi, applicazioni, dati e
documentazione in linea con i fabbisogni di business ed i piani di
continuità. |
|
|
|
|
|
|
|
|
DS11.6 - Requisiti di
sicurezza per la gestione dei dati Definire ed implementare
policy e procedure per identificare ed applicare i requisiti di sicurezza in
caso di ricezione, elaborazione, memorizzazione fisica ed output di dati al
fine di raggiungere gli obiettivi aziendali ed essere conforme alla policy di
sicurezza aziendale e ai requisiti legali. |
|
|
|
|
|
|
|
|
DS12 - Gestione dell’ambiente fisico [6] La protezione dei dispositivi
di elaborazione e delle persone richiede infrastrutture fisiche ben
progettate e ben gestite. Il processo di gestione dell’ambiente fisico
include la definizione dei requisiti del sito fisico, la scelta delle
infrastrutture appropriate e la progettazione di processi efficaci per
monitorare i fattori ambientali e la gestione degli accessi fisici. Una
gestione efficace dell’ambiente fisico riduce le interruzioni di
business per i danni ai dispositivi di elaborazione e al personale. |
DS12.1 - Scelta e layout del sito
fisico Definire e scegliere i siti
fisici per i dispositivi IT per supportare la strategia tecnologica connessa
alla strategia di business. La scelta ed la progettazione della disposizione
del sito fisico dovrebbe tenere conto del rischio associato ai disastri
naturali e provocati dall’uomo, considerando leggi e regolamenti
rilevanti come i regolamenti sulla salute fisica e sulla sicurezza dei
lavoratori. |
|
|
|
|
|
|
|
DS12.2 - Misure di sicurezza
fisica Definire e implementare misure
di sicurezza fisica in linea con i requisiti di business per rendere sicuri i
locali e gli asset fisici. Le misure di sicurezza fisica devono essere in
grado di prevenire, identificare e mitigare efficacemente i rischi legati a
furti, alte temperature, fuoco, fumo, terremoti, atti di vandalismo e di
terrorismo, interruzioni di corrente elettrica, prodotti chimici ed
esplosivi. |
|
|
|
|
|
|
|
|
DS12.3 - Accesso fisico Definire e implementare
procedure per concedere, limitare e revocare gli accessi a locali, edifici ed
aree secondo i requisiti di business incluse le emergenze. Gli accessi ai
locali, edifici ed aree dovrebbero essere giustificati, autorizzati,
registrati e monitorati. Questo si applica a tutte le persone che entrano nei
locali di edifici, incluso personale dipendente, personale temporaneo,
clienti, fornitori, visitatori od ogni altra terza parte. |
|
|
|
|
|
|
|
|
DS12.4 - Protezione contro
fattori ambientali Definire e implementare misure
di protezione contro fattori ambientali. Dovrebbero essere installati
dispositivi specializzati per monitorare e controllare l’ambiente. |
|
|
|
|
|
|
|
|
DS12.5 - Gestione delle
infrastrutture fisiche Gestire le infrastrutture,
inclusi i dispositivi per l’energia e le comunicazioni, in linea con
leggi e regolamenti, fabbisogni tecnici e di business, specifiche dei
fornitori, e linee guida per garantire la salute e l’incolumità fisica. |
|
|
|
|
|
|
|
|
DS13 - Gestione delle operazioni [2] Una completa ed accurata
elaborazione dei dati richiede un’efficace gestione
dell’elaborazione dei dati e un’accurata manutenzione
dell’hardware. Questo processo include la definizione di politiche e
procedure operative per un’efficace gestione delle elaborazioni
schedulate, la protezione di output con informazioni sensibili, il
monitoraggio delle prestazioni infrastrutturali e la manutenzione preventiva
dell’hardware. Una gestione efficace delle operazioni aiuta a mantenere
l’integrità dei dati e riduce i ritardi di business ed i costi
operativi dell’IT. |
DS13.1 - Istruzioni e
procedure operative Definire, implementare e
mantenere procedure standard per l’operatività IT ed assicurare che il
personale IT sia a conoscenza di tutte le attività operative rilevanti. Le
procedure operative dovrebbero coprire i cambi di turno (cambio formale di
attività, aggiornamento sullo status, problemi operativi, procedure di
escalation e rapporti sulle responsabilità correnti) per assicurare il
raggiungimento dei livelli di servizio concordati e la continuità operativa. |
|
|
|
|
|
|
|
DS13.2 - Schedulazione dei job Organizzare la schedulazione
dei job, dei processi e delle attività nelle sequenze più efficienti, massimizzando
il throughput e l’utilizzo delle risorse per soddisfare i requisiti
definiti dal business. |
|
|
|
|
|
|
|
|
DS13.3 - Monitoraggio
dell’infrastruttura IT Definire e implementare
procedure per monitorare l’infrastruttura IT e gli eventi correlati.
Assicurare che una sufficiente informazione cronologica sia memorizzata in
log operativi per consentire la ricostruzione, revisione ed esame delle
sequenze temporali delle operazioni e le altre attività di contorno o di
supporto alle operazioni. |
|
|
|
|
|
|
|
|
DS13.4 - Documenti sensibili e
dispositivi di output Definire e applicare
appropriate tutele fisiche, prassi di rendicontazione e gestione
dell’inventario per risorse IT sensibili come ad esempio moduli
speciali, strumenti negoziabili, stampanti speciali o token di sicurezza. |
|
|
|
|
|
|
|
|
DS13.5 - Manutenzione
preventiva dell’hardware Definire ed implementare
procedure per assicurare una manutenzione tempestiva
dell’infrastruttura per ridurre la frequenza e l’impatto di
guasti o degrado delle prestazioni. |
|
|
|
|
|
|
|
Dominio :
Monitoraggio e Valutazione
Processo [importanza relativa per la
sicurezza] |
Attività / controlli |
Possibile intervento migliorativo |
Lavori in corso nell'area |
Business drivers |
Interventi collegati / collegabili |
|||
N |
Entità / costo |
Tempo |
Autonomia |
|||||
ME1 - Monitorare e valutare le prestazioni dell’IT [4] Una gestione efficace delle
prestazioni IT richiede un processo di monitoraggio. Tale processo comprende
la definizione dei più importanti indicatori di prestazione, una informativa
sistematica e tempestiva alla Direzione sulle prestazioni rilevate,
l’individuazione di interventi solleciti in caso di scostamenti. Il
monitoraggio è necessario per assicurarsi che siano adottate le giuste azioni
e che esse siano in linea con le indicazioni e le politiche aziendali
stabilite. |
ME1.1 - Approccio al
monitoraggio Definire un quadro di
riferimento e un approccio generale al monitoraggio, che stabilisca
l’ambito, la metodologia e il processo da seguire per monitorare il
contributo dell’IT ai risultati aziendali, alla erogazione di servizi e
soluzioni. Integrare il quadro di riferimento con il sistema aziendale di
misurazione delle prestazioni. |
|
|
|
|
|
|
|
ME1.2 - Definizione e raccolta
di dati per il monitoraggio Di concerto con le altre
funzioni aziendali, definire un insieme bilanciato di obiettivi e farlo
approvare dalle funzioni aziendali non-IT e dai principali stakeholder.
Definire dei benchmark con cui confrontare gli obiettivi e identificare i
dati disponibili per essere raccolti ed elaborati per misurare il
raggiungimento degli obiettivi stessi. Definire i processi di misurazione in
modo da poter raccogliere tempestivamente e accuratamente i dati per riferire
sui progressi conseguiti rispetto agli obiettivi. |
|
|
|
|
|
|
|
|
ME1.3 - Metodo di monitoraggio Identificare e tradurre
operativamente un metodo di monitoraggio delle prestazioni (es. cruscotto
aziendale o balanced scorecard) per registrare i risultati raggiunti e le
misure effettuate, per fornire una sintetica vista complessiva delle
prestazioni IT; il metodo deve essere in sintonia con il sistema di
monitoraggio aziendale. |
|
|
|
|
|
|
|
|
ME1.4 - Valutazione delle
prestazioni Revisionare periodicamente le
prestazioni rispetto agli obiettivi, effettuare un’analisi delle cause
di ogni scostamento e avviare azioni correttive per rimuovere le cause
stesse. Ogniqualvolta richiesto, effettuare un’analisi delle cause sulla
base degli scostamenti. |
|
|
|
|
|
|
|
|
ME1.5 - Reporting ai vertici
aziendali e al consiglio di amministrazione Fornire analisi ai vertici
aziendali per consentire loro di effettuare una valutazione del contributo
dell’IT al perseguimento degli obiettivi aziendali, in particolare per
quanto riguarda le prestazioni dei servizi/prodotti offerti
dall’azienda, le iniziative di investimento facilitate dall’IT, i
livelli di efficacia delle singole iniziative per l’erogazione del
servizio e delle soluzioni. Inserire nelle analisi il grado di raggiungimento
degli obiettivi pianificati, la quota di utilizzo del budget, gli obiettivi
di prestazione raggiunti e i rischi mitigati. Anticipare la verifica della
Direzione suggerendo le azioni correttive che riducano i principali
scostamenti. Fornire il reporting alla Direzione, sollecitare un feedback
dalla valutazione dei responsabili. |
|
|
|
|
|
|
|
|
ME1.6 - Azioni correttive Identificare e avviare azioni correttive
basate sul monitoraggio, sulle valutazioni e sui report riguardanti le
prestazioni. Questo comprende il follow-up di tutti i monitoraggi, di tutte
le valutazioni e di tutte le analisi, attraverso: la verifica, la
negoziazione e la conferma delle risposte del management l’assegnazione
delle responsabilità per le azioni correttive la tracciatura dei risultati
delle azioni per cui il management si è impegnato |
|
|
|
|
|
|
|
|
ME2 - Monitorare e valutare i controlli interni [4] La realizzazione di un
efficace programma di controllo interno per l’IT richiede un processo
di monitoraggio ben definito. Tale processo riguarda il monitoraggio e
l’informativa sulle eccezioni ai controlli, sui risultati delle
autovalutazioni, sulle verifiche di terze parti. Un importante beneficio
prodotto dal monitoraggio dei controlli interni è costituito dalla garanzia
(assurance) riguardo l’efficienza e l’efficacia delle operazioni
e la conformità a leggi e regolamenti. |
ME2.1 - Valutazione del modello
del sistema di controllo interno Monitorare in modo continuo,
effettuare benchmark e migliorare il sistema di controllo interno IT e il
modello dei controlli per facilitare il raggiungimento degli obiettivi
aziendali. |
|
|
|
|
|
|
|
ME2.2 - Controlli di
supervisione Monitorare e valutare
l’efficacia e l’efficienza della verifica, da parte della
management IT, sui controlli interni. |
|
|
|
|
|
|
|
|
ME2.3 - Eccezioni ai controlli Registrare le informazioni riguardanti
tutte le eccezioni ai controlli e assicurarsi che sia svolta un’analisi
delle cause sottostanti. Le eccezioni debbono essere riportate ai livelli
organizzativi superiori ove necessario e ove opportuno ai diversi
stakeholder. Avviare le necessarie azioni correttive. |
|
|
|
|
|
|
|
|
ME2.4 - Attività di controllo
promosse autonomamente (Self – assessment) Valutare la completezza e
l’efficacia dei controlli interni sui processi, sulle procedure e sui
contratti dell’IT attraverso un programma continuo di autovalutazione. |
|
|
|
|
|
|
|
|
ME2.5 - Garanzie (Assurance)
sui controlli interni Ottenere, quando necessario,
ulteriori garanzie (assurance) sulla completezza e sull’efficacia dei controlli
interni attraverso verifiche svolte da terzi. |
|
|
|
|
|
|
|
|
ME2.6 - Controllo interno
presso terze parti Valutare lo stato del sistema
di controllo interno di ogni terza parte fornitrice di servizi. Assicurarsi che
il fornitore di servizi esterno sia conforme alle leggi e ai regolamenti e
alle obbligazioni contrattuali. |
|
|
|
|
|
|
|
|
ME2.7 - Azioni correttive Identificare, avviare e
monitorare azioni correttive basate sulle analisi e valutazioni dei controlli.
|
|
|
|
|
|
|
|
|
ME3 - Assicurare la conformità a leggi e normative esterne [3] Un’efficace supervisione
del rispetto dei regolamenti richiede la definizione di un processo di valutazione
per assicurare la conformità ai requisiti di legge, di norme e di contratti.
Tale processo include l’identificazione dei requisiti di conformità,
l’ottimizzazione e valutazione dei risultati, l’assicurazione che
i requisiti di conformità sono stati effettivamente soddisfatti, infine,
l’integrazione del reporting relativo alla conformità di competenza
dell’IT nell’ambito del reporting di conformità aziendale. |
ME3.1 - Identificazione dei
requisiti esterni di compliance relativi a leggi, normative e contratti. Identificare, in modo
sistematico, leggi nazionali ed internazionali, normative ed altri requisiti
- di natura esogena rispetto all’azienda – che l’azienda
deve rispettare, al fine di farli integrare nelle politiche, negli standard,
nelle procedure e nelle metodologie specifici dell’IT. |
|
|
|
|
|
|
|
ME3.2 - Ottimizzazione della
gestione dei requisiti normativi Rivedere e adeguare le
politiche, gli standard, le procedure ed i metodi IT per assicurare che i
requisiti di legge, normativi e contrattuali siano efficientemente
soddisfatti e conosciuti. . |
|
|
|
|
|
|
|
|
ME3.3 - Valutazione del
rispetto dei requisiti esterni Confermare che le politiche, gli
standard, le procedure e i metodi IT rispettano i requisiti normativi e di
legge. |
|
|
|
|
|
|
|
|
ME3.4 - Garanzia di conformità Ottenere e riferire sulla
garanzia di conformità con e rispetto di tutte le politiche interne che
derivano dall’applicazione di direttive interne o di leggi e normative
esterne o di contratti; confermare che i proprietari dei processi interessati
abbiano adottato le opportune azioni correttive per superare eventuali lacune
di conformità. |
|
|
|
|
|
|
|
|
ME3.5 - Reporting integrato Integrare, con analoghe
informative provenienti da altre funzioni aziendali, il reporting
dell’IT riguardante la conformità a requisiti di legge, normativi e
contrattuali. |
|
|
|
|
|
|
|
|
ME4 - Istituzione dell’IT Governance [4] Istituire un’efficace
struttura per la governance che includa la definizione delle strutture
organizzative, dei processi, della leadership, dei ruoli e delle
responsabilità al fine di garantire che gli investimenti dell’impresa
in tecnologie informatiche siano allineati ed erogati in accordo con le
strategie e con gli obiettivi aziendali. |
ME4.1 - Istituzione di un
quadro di riferimento per l’IT Governance Definire, realizzare un quadro
di riferimento per la governance dell’IT e mantenerlo allineato con il
contesto stabilito per la governante ed il controllo dell’intera
azienda. Il quadro di riferimento dovrebbe essere basato su un adeguato
modello di controllo e dei processi IT e indicare responsabilità non ambigue
e procedure che consentano di prevenire errori nell’ambito di attività
di controllo e di supervisione. Confermare che il quadro di riferimento per
la governance dell’IT è funzionale a garantire la conformità con la
legislazione e le normative, l’allineamento alle strategie aziendali ed
il perseguimento degli obiettivi aziendali. Definire un sistema di reporting
che relazioni sullo stato e sulle problematiche dell’IT Governance. |
|
|
|
|
|
|
|
ME4.2 - Allineamento
strategico Facilitare la comprensione da parte
del Consiglio di Amministrazione e dell’Alta Direzione delle
problematiche strategiche dell’IT, come il ruolo dell’IT, le
caratteristiche e le potenzialità delle tecnologie informatiche in azienda.
Assicurarsi che il potenziale contributo dell’IT alla strategia
aziendale sia compreso sia dall’azienda sia dalla funzione sistemi
informativi. Collaborare con il Consiglio di Amministrazione al fine di
definire ed implementare organismi di controllo, come il Comitato Strategico
per l’IT, con l’obiettivo di fornire un orientamento strategico
al management che si deve relazionare con l’IT, in modo da assicurare
che strategia ed obiettivi siano diffusi all’interno delle unità
operative sia di business sia delle singole funzioni IT, e che tra utenti
aziendali e specialisti della funzione sistemi informativi si sviluppi un
rapporto di fiducia reciproca. Facilitare l’allineamento dell’IT
all’azienda per quanto riguarda strategia e processi operativi,
incoraggiando la condivisione di responsabilità fra process owner e
l’IT al fine di pervenire a decisioni strategiche e produrre valore a
fronte di investimenti in tecnologie informatiche. |
|
|
|
|
|
|
|
|
ME4.3 - Apporto di valore Gestire i programmi di
investimento dove l’IT è fattore abilitante e di altre risorse e
servizi IT in modo che possano apportare il maggiore valore possibile nel
perseguimento della strategia e degli obiettivi dell’impresa.
Assicurarsi che i risultati degli investimenti IT attesi dall’azienda e
che tutti gli sforzi necessari per ottenerli vengano compresi, che siano
prodotti e approvati dagli stakeholder degli studi di fattibilità
significativi e coerenti, che le risorse e gli investimenti siano controllati
durante tutto il loro ciclo di vita economico e che ci sia una gestione
finalizzata alla realizzazione dei benefici, come il contributo a nuovi
servizi, guadagni in efficienza e una maggiore capacità di risposta alla
domanda del cliente. Assicurare una gestione puntuale a livello di
portafoglio, di programmi e di progetti, incoraggiando l’assunzione di
risponsabilità da parte delle strutture e dei processi di business sugli
investimenti favoriti dall’IT e che la funzione sistemi informativi
garantisca un efficiente ed efficace supporto. |
|
|
|
|
|
|
|
|
ME4.4 - Gestione delle risorse Supervisionare gli
investimenti, l’utilizzo e l’allocazione delle risorse IT
attraverso una attività di verifica sistematica delle iniziative e delle operations
IT assicurandosi che la funzione sistemi informativi disponga di una quantità
sufficiente di risorse competenti e allineate con gli attuali e futuri
obiettivi strategici ed esigenze irrinunciabili dell’azienda. |
|
|
|
|
|
|
|
|
ME4.5 - Gestione del rischio Collaborare con il Consiglio
di Amministrazione al fine di definire la propensione al rischio IT
dell’impresa; ottenere una ragionevole garanzia che le modalità di
gestione del rischio informatico siano appropriate e che il rischio
informatico attuale non superi il livello stabilito dal Consiglio.
Incorporare le responsabilità di gestione del rischio
nell’organizzazione, assicurando che l’azienda e l’IT
valutino e comunichino in maniera sistematica i rischi correlati all’IT
ed il loro impatto sui processi di business. La posizione assunta
dall’azienda nei confronti del rischio IT dovrebbe essere trasparente e
nota a tutti gli stakeholder. |
|
|
|
|
|
|
|
|
ME4.6 - Valutazione delle
prestazioni Confermare che gli obiettivi
IT sui quali si è raggiunto un accordo sono stati raggiunti o superati, o che
i miglioramenti nel perseguimento degli obiettivi IT è coerente con le
aspettative. Ove gli obiettivi non siano stati raggiunti o le aspettative
siano state insoddisfatte, verificare gli interventi risolutivi adottati
dalla Direzione. verso Fornire al Consiglio informazioni dettagliate sugli
aspetti più importanti legati al portafoglio delle iniziative che riguardano
l’IT, ai programmi e alle prestazioni dei processi IT, attraverso dei
report che mettano in condizione la Direzione di verificare i progressi
dell’azienda verso gli obiettivi definiti. |
|
|
|
|
|
|
|
|
ME4.7 - Certificazione
indipendente Ottenere una certificazione indipendente
(interna o esterna) relativamente alla conformità dell’IT con la
legislazione ele normative vigenti; con le politiche, gli standard e le
procedure dell’azienda, con le pratiche generalmente accettate, con
l’attesa efficienza ed efficacia delle performance IT. |
|
|
|
|
|
|
|
[1] Liberamente scaricabile dal sito: www.aiea.it.
[2] Il Framework CobiT valuta anche gli aspetti relativi a :efficienza,
efficacia
ed affidabilità
dell’IT.
[3] Chi volesse approfondire la conoscenza e l’utilizzo
del framework CobiT, ricordiamo che, tra altri elementi, esso propone
interessanti metodi di autovalutazione per la verificare quanto i vari processi
siano erogati in modo adeguato alle vostre esigenze, mettendo in risalto le
aree di miglioramento. Il framework medesimo propone inoltre un ulteriore
livello di dettaglio delle attività / controlli con le : Pratiche di Controllo.