Piccola Guida alla Business Continuity
-
Upload
tai-solutions -
Category
Documents
-
view
240 -
download
5
description
Transcript of Piccola Guida alla Business Continuity
Piccola guida alla Business Continuity
Le piccole guide di TAI Solutions
3
Piccola guida alla
Business Continuity
Contenuti
Gestione e valutazione dei rischi..5
BIA—Business Impact Analysis....8
Business continuity plan............11
Disaster Recovery ………………...14
Prefazione Per business continuity (gestione della continuità operativa o continui-
tà aziendale) si intende la capacità dell'organizzazione di continuare ad
esercitare il proprio business a fronte di eventi avversi che possono colpir-
la.
La pianificazione della continuità operativa e di servizio si chiama business
continuity plan (BCP) (in italiano "piano di continuità del business") e vie-
ne comunemente considerata come un processo globale che identifica i
pericoli potenziali che minacciano l'organizzazione, e fornisce una struttu-
ra che consente di aumentare la resilienza e la capacità di risposta in ma-
niera da salvaguardare gli interessi degli stakeholders, le attività produtti-
ve, l'immagine, riducendo i rischi e le conseguenze sul piano gestionale,
amministrativo, legale.
Il Disaster Recovery Plan, che è mirato ai servizi informatici, è un sottoin-
sieme del business continuity plan.
4
Il progetto del piano di business continuity
Per la realizzazione del piano di gestione della continuità operativa è necessario
procedere attraverso un progetto articolato in 4 fasi principali:
1. gestione e valutazione dei rischi;
2. business impact analysis - BIA;
3. definizione della strategia di mitigazione dei rischi;
4. sviluppo del piano di business continuity e disaster recovery.
Focus
La predisposizione di sistemi di
Continuità Operativa è normata a
livello legislativo per determinate
attività in ambito bancario, fiscale
e delle infrastrutture informatiche
critiche.
I Sistemi di Gestione della Conti-
nuità Operativa sono regolati
anche da standard internazionali
volontari, per i quali può essere
conseguita una certificazione.
In particolare, BS 25999 - Busi-
ness continuity management è la
prima norma al mondo per la
continuità operativa, sviluppata
dall’Ente di normazione inglese
BSI (ved. Pag. 12).
Gestione e valutazione dei rischi
La gestione del rischio (risk management) è il processo mediante il quale si misura o si stima il rischio e suc-
cessivamente si sviluppano delle strategie per governarlo.
Di regola, le strategie impiegate includono il trasferimento del rischio a terze parti, l'evitare il rischio, il ridurre
l'effetto negativo ed infine l'accettare in parte o totalmente le conseguenze di un particolare rischio.
Priorità
In una gestione del rischio ideale sono trattati per prima cosa i rischi correlati ad una grande perdita e una
grande probabilità di accadere, invece i rischi con bassa probabilità di occorrenza e basse perdite sono trattati
con ritardo. In pratica il processo può essere estremamente complesso, infatti rischi con alta probabilità di oc-
correnza, ma con bassa perdita, e rischi con alta perdita, ma bassa probabilità di occorrenza, possono essere
mal governati.
La gestione del rischio molto spesso si confronta con la difficoltà di allocare propriamente le risorse; questo
concetto si dice costo di opportunità. Tempo e risorse spese per la gestione del rischio potrebbero essere spese
per attività più redditizie. Inoltre la gestione del rischio ideale spende un ammontare di risorse il minimo indi-
spensabile nel processo di riduzione degli effetti negativi dei rischi.
5
6
I passi del processo di gestione del rischio Cinque sono i passi del processo di gestione del rischio:
• Stabilire il contesto
• Identificare i rischi
• Analizzare i rischi
• Valutare i rischi
• Controllare i rischi
Spesso il passo "Controllare i rischi" viene diviso in una fase di preparazione ed approvazione del Piano di azio-
ne dei rischio (Risk Action Plan) ed in una fase di esecuzione, controllo e modifica del piano.
In parallelo col processo centrale, sono richieste doti di comunicazione e di consultazione. Monitorare e revisio-
nare è parte intrinseca del processo in modo da assicurare che venga eseguito tempestivamente; l'identificazio-
ne, l'analisi, la valutazione ed il controllo sono sempre aggiornati.
La gestione del rischio è quindi un processo ricorsivo, soggetto ad aggiornamenti, e non si esaurisce nell'identi-
ficazione iniziale del rischio.
Stabilire il contesto
Stabilire il contesto include pianificare il residuo del processo, l'identità e lo scopo sono fondamentali, le basi
sulle quali il rischio sarà valutato e definire lo scheletro per il processo, l'agenda per l'identificazione e l'analisi.
Identificare i rischi Dopo aver stabilito il contesto, il passo successivo nel processo di controllo è quello di identificare i rischi poten-
ziali. I rischi sono connessi a eventi che quando si verificano causano problemi. Pertanto l'identificazione del
rischio può iniziare dalla causa dei problemi o dal problema stesso.
Analisi della causa: la sorgente di rischio può essere interna od esterna al sistema oggetto della gestione del
rischio. Esempi di sorgente di rischio sono: i partecipanti a un progetto, i dipendenti di un'azienda oppure il
tempo atmosferico nei cieli di un aeroporto.
Analisi del problema: i rischi sono collegati all'identificazione dei pericoli (o minacce). Ad esempio: il pericolo di
perdere soldi, il pericolo di violazione di informazioni riservate od il pericolo di errori umani, incidenti od infortu-
ni. Le minacce possono essere correlate a vari soggetti, le più importanti sono connesse con gli azionisti, i clien-
ti e le autorità governative.
Quando sono note le origini o i problemi, l'evento che un'origine può attivare o l'evento che può condurre ad un
problema possono essere oggetto di approfondimento. Per esempio, i soci che partecipano a un progetto che si
ritirano durante lo svolgimento dello stesso possono mettere in pericolo il finanziamento del progetto; informa-
zioni riservate possono essere sottratte dai dipendenti autorizzati anche se la rete informatica è protetta da in-
trusioni esterne; un fulmine può colpire un aereo durante il decollo e ferire tutti i passeggeri a bordo.
7
Quando sono note le origini o i problemi, l'evento che un'origine può attivare o l'evento che può condurre ad un
problema possono essere oggetto di approfondimento. Per esempio, i soci che partecipano a un progetto che si
ritirano durante lo svolgimento dello stesso possono mettere in pericolo il finanziamento del progetto; informa-
zioni riservate possono essere sottratte dai dipendenti autorizzati anche se la rete informatica è protetta da in-
trusioni esterne; un fulmine può colpire un aereo durante il decollo e ferire tutti i passeggeri a bordo.
Il metodo per identificare i rischi può dipendere dalla cultura, dalla pratica d'industria e dall'accondiscendenza. I
metodi d'identificazione sono formati da template o dallo sviluppo di template per l'identificazione della sorgen-
te, problema o evento. I più comuni metodi di identificazione del rischio sono:
Basato su obiettivi: le organizzazioni ed i team di progetto hanno degli obiettivi. Ogni evento che può mettere
in pericolo l'acquisizione parziale di un obiettivo è identificato come rischio.
Basato sullo scenario: nell'analisi dello scenario differenti scenari sono creati. Ogni evento che attiva uno scena-
rio alternativo indesiderato è identificato come un rischio.
8
BIA – Business Impact Analysis
La BIA o Impatto sul business (business impact analysis) individua quali processi devono essere funzionanti per
garantire il business e quali possono essere sospesi per un certo periodo di tempo. Questo porta alla definizione
di una strategia di mitigazioni e di recupero.
Al fine di effettuare la BIA, è necessario prendere in esame tutti i processi, le funzioni e le risorse e valutarne
l’impatto sull’azienda dal punto di vista operativo, finanziario e legale.
La BIA inizia con l’identificazione di tutti i processi, le funzioni e le risorse (compresi quelli esterni, qualora siano
critici per lo svolgimento delle attività aziendali) e con l’attribuzione della relativa criticità, anche in considerazio-
ne delle interdipendenze esistenti.
I risultati della BIA vengono incrociati con gli scenari di disastro e i rischi correlati, che emergono dal documen-
to di Valutazione dei Rischi.
Al termine di questa valutazione, è poi possibile decidere, per ciascun processo, quali rischi dovranno essere
mitigati, quali trasferiti e quali, eventualmente, accettati (strategia di mitigazione dei rischi).
La criticità dei processi serve per determinare il Recovery Time Objective ed il Recovery Point Objective e poter
conseguentemente stabilire, nel piano di business continuity e disaster recovery, le azioni da intraprendere nel
caso si verifichino eventi avversi.
RTO Il Recovery Time Objective (RTO) è il tempo necessario per il pieno recupero dell'operatività di un sistema o di
un processo organizzativo in un sistema di analisi Business Critical System (ad esempio implementazioni di poli-
tiche di Disaster Recovery nei Sistemi Informativi).
È in pratica la massima durata, prevista o tollerata, del downtime occorso.
Aspetto di primaria importanza riveste il fatto che il valore di RTO sia definito, conosciuto e verificato, tenendo
presente che se un downtime lungo danneggia la possibilità di fruire del servizio più di uno breve, il danno
maggiore deriva dall'inconsapevolezza di quanto possa essere il tempo previsto per il ripristino dei servizi dan-
neggiati.
La tabella riporta un esempio della scala dei valori per la valutazione dell’RTO.
VALORE CRITICITA’ della Funzione Tempo massimo di ripristino
1 Minore (funzioni auspicabili) > 3 giorni
2 Necessaria (funzioni importanti) 1 – 3 giorni
3 Vitale (funzioni essenziali) 13 -24 ore
4 Fondamentale (funzioni indispensabili per la sopravvivenza) 0 – 12 ore
9
RPO Il Recovery Point Objective (RPO) è uno dei parametri usati nell'ambito delle politiche di disaster recovery
per descrivere la tolleranza ai guasti di un sistema informatico. Esso rappresenta il massimo tempo che in-
tercorre tra la produzione di un dato e la sua messa in sicurezza (ad esempio attraverso backup) e, conse-
guentemente, fornisce la misura della massima quantità di dati che il sistema può perdere a causa di gua-
sto improvviso.
Al diminuire dell'RPO richiesto si rendono necessarie politiche di sicurezza sempre più stringenti e dispen-
diose, che possono andare dal salvataggio dei dati su supporti ridondanti tolleranti ai guasti fino alla loro
pressoché immediata replicazione su un sistema informatico secondario d'emergenza (soluzione in grado di
garantire, in linea teorica, valori di RPO prossimi allo zero).
10
Esempio di tabella di valutazione per la BIA
Parametro Descrizione Dipendenza altri processi Definire la dipendenza del processo in esame
da altri processi / risorse Competenze del personale Definire le competenze del personale addet-
to al processo Periodicità del processo Definire la periodicità del processo
(continuo, periodico, ecc..) Risorse necessarie per il recovery Definire le risorse umane e tecnologiche ne-
cessarie per il recovery Tempo necessario per il recovery Definire i tempi necessari per il recovery
SLA Verificare se sono stati definiti SLA (interni o contrattualizzati) per il processo in esame
Tecnologia utilizzata (sw, hw, server, network…) Definire la tecnologia utilizzata dal processo in esame
Soluzioni e procedure esistenti per il DR Riportare, se esistenti, le soluzioni e proce-dure per il recovery
Possibilità di svolgere il processo da remoto Verificare la possibilità di svolgere il processo in remoto da altre sedi
Possibilità di spostare il processo su altre aree Verificare la possibilità di spostare il proces-so, in via momentanea fino alla ripresa delle normali attività, su altre aree aziendali
Documentazione critica Verificare l’esistenza di documentazione criti-ca (in elettronico ed in cartaceo) legata al processo in esame
Obblighi normativi Verificare eventuali obblighi normativi (scadenze, procedure, ecc…) legate al pro-cesso in esame
Funzioni / Risorse fondamentali Definire le funzioni aziendali e le risorse u-mane fondamentali per la continuità del pro-cesso in esame
Criticità del processo Definire la criticità del processo in esame attraverso il suo Recovery Time Objective (RTO)
Business continuity plan
Il Business Continuity Plan (BCP) o Piano di continuità aziendale è il documento principale che contie-
ne le attività, le azioni ed i piani relativi alla continuità operativa (business continuity) di un'azienda.
Finalità
Si tratta di un piano logistico finalizzato a documentare il modo in cui un'organizzazione può far tornare opera-
tive le sue funzioni critiche entro un predeterminato periodo di tempo dopo un disastro o un grave danno. In
altri termini il BCP costituisce lo strumento attraverso cui una organizzazione si prepara per futuri incidenti che
possono minacciare le sue funzioni vitali e la sua sopravvivenza a lungo termine. Gli incidenti da prevedere
sono svariati, tra essi gli incendi, i terremoti o anche malattie epidemiche.
Il BCP può essere parte del processo organizzativo attraverso cui si cerca di ridurre il rischio operativo e può
essere integrato nelle attività di miglioramento della sicurezza informatica e della gestione del rischio. Nelle
grandi organizzazioni i processi di gestione della continuità operativa comprendono anche il cosiddetto disaster
recovery (che normalmente è riferito soprattutto al ripristino delle funzionalità dei sistemi informatici) e la ge-
stione delle crisi (che riguarda invece ogni tipo di crisi).
Redigere un BCP consente di:
Reagire per assicurare il ripristino della situazione ottimale, in caso di processi critici
Guidare le scelte in caso di crisi
Stabilire le procedure alternative per garantire l'operatività.
Minimizzare il tempo di interruzione dei processi aziendali critici.
Garantire l'efficacia delle procedure di ripristino.
Efficacia
L'efficacia di un BCP si basa sull'accettazione del fatto che esista sempre un elemento di rischio e sul modo di
reagire allo stesso, valutandolo, stimandone gli effetti e stabilendo se e come assumerselo. Tutte queste ope-
razioni permettono di garantire la continuità operativa, analizzando e definendo processi essenziali e di sup-
porto, per stabilire un piano di continuità.
Nel mondo degli affari lo scenario è molto competitivo e ciò influenza continuamente il business, con fattori
endogeni (riassetto organizzativo) ed esogeni (reazioni a cambiamenti del mercato). Pertanto, il BCP è valido
solo fino a quando i suoi elementi non cambiano. Detto ciò, si comprende che un piano di continuità nasce
dell'esigenza di affidabilità dei sistemi, sia come risposta a problemi IT, sia come disponibilità dei sistemi a
supporto dei processi di business.
Un piano di continuità aziendale dev'essere continuamente testato ed aggiornato per ottenere la massima ade-
renza alle esigenze del business. Una soluzione di BC non aggiornata è completamente inutile, in quanto basta
una piccola variazione di un qualsiasi componente base del processo per far crollare tutto il piano.
11
La garanzia di successo di un BCP dipende da alcuni fattori connessi tra loro, tra i quali:
• Tempo
• Aggiornamento continuo delle soluzioni
• Valutazione continua del rapporto tra costo/complessità della soluzione e tra valore/priorità del business e
normativa del processo protetto.
• Costi complessivi
• Ampiezza dell'impatto tra le funzioni coinvolte.
Il maggior elemento di criticità, invece, è costituito dal seguire di pari passo l'evoluzione della tecnologia, del
mercati e della clientela, tutti fattori in la cui velocità di cambiamento è impressionante. L'unica maniera per ri-
durre la complessità portandola ad una dimensione gestibile ed efficace, mantenendo costi controllati, è la gra-
dualità nella soluzione sia come numero di processi considerati, sia come profondità e dettaglio dell'analisi. L'au-
mento tout-court del numero di risorse dedicate (sia interne, che esterne) e del budget economico ha un anda-
mento inferiore rispetto al volume di soluzioni prodotte, in quanto la fruibilità delle soluzioni (condizione neces-
saria per essere effettivamente tale) rischierebbe di scontrarsi con una struttura non pronta a recepirle e ad at-
tuarle in caso di necessità.
Standard di riferimento
Nel dicembre 2006 è stata pubblicata dal British Standards Institute una nuova norma standard, la BS 25999.
Prima della sua pubblicazione si faceva riferimento prevalentemente allo standard per la sicurezza informatica
BS 7799 che trattava la continuità operativa solo in modo sommario in funzione esclusivamente della gestione
della sicurezza informatica. Lo standard BS 25999 si applica a tutte le organizzazioni indipendentemente dal ti-
po, dimensione e settore di appartenenza, private o pubbliche.
Contenuti del piano
Il piano include:
• la descrizione del response team, le responsabilità e l’organizzazione;
• definizione dello staff di supporto e di coordinamento;
• individuazione della sede ed equipaggiamento del Centro di emergenza (crisi)
Il BCP può essere anche costituito da più piani dipartimentali integrati tra loro; occorre quindi stabilire meccani-
smi di manutenzione e integrazione dei vari piani, allocando i vari task e le responsabilità, identificando contatti,
fornitori, risorse, canali di comunicazione interna ed esterna.
Il piano contiene le procedure di continuità, in particolare i processi mission critical e le funzioni vitali dell’orga-
nizzazione, quali sono le risorse disponibili e come devono essere utilizzate per assicurare la continuità.
Si indicheranno:
• l'uso e la locazione e protezione di informazioni critiche;
• gli strumenti di telecomunicazione;
• i requisiti del personale necessari per garantire il livello prefissato di servizio.
12
Struttura di un piano tipo
Il BCP ha una struttura del tipo:
Introduzione
• Obiettivi
• Responsabilità
• Esercitazione e manutenzione
Attivazione del piano
• Dichiarazione di disastro o di incidente
• Valutazione del danno
• Procedure di azione e continuità
• Organizzazione del team e responsabilità
• Centro di Emergenza o Crisi
Comunicazioni
• Soggetti da informare
• Contatti
• Messaggi
Fornitori
• Lista dei fornitori di recovery
• Dettagli dei contratti
Il documento deve essere costantemente aggiornato con la gestione dei processi secondo la logica del Ciclo di
Deming.
13
Disaster Recovery
Per Disaster Recovery (brevemente DR) si intende l'insieme di misure tecnologiche e organizzative/logistiche
atte a ripristinare sistemi, dati e infrastrutture necessarie all'erogazione di servizi di business per imprese, asso-
ciazioni o enti, a fronte di gravi emergenze che ne intacchino la regolare attività.
L'impatto di tali emergenze è tale che si stima che la maggior parte delle grandi imprese spendano fra il 2% ed
il 4% del proprio budget IT nella pianificazione della gestione dei disaster recovery, allo scopo di evitare perdite
maggiori nel caso che l'attività non possa continuare a seguito della perdita di dati ed infrastrutture IT. Delle
imprese che hanno subito disastri con pesanti perdite di dati, circa il 43% non ha più ripreso l'attività, il 51% ha
chiuso entro due anni e solo il 6% è riuscita a sopravvivere nel lungo termine. I disastri informatici con ingenti
perdite di dati nella maggioranza dei casi provocano quindi il fallimento dell'impresa o dell'organizzazione, ragion
per cui investire in opportune strategie di recupero diventa una scelta quasi obbligata.
Disaster Recovery Plan
Il Disaster Recovery Plan (DRP) (in italiano, Piano di disaster recovery) è il documento che esplicita tali misu-
re. Esso fa parte del più ampio Business Continuity Plan (BCP).
Affinché una organizzazione possa rispondere in maniera efficiente ad una situazione di emergenza, devono es-
sere analizzati:
• I possibili livelli di disastro
• La criticità dei sistemi/applicazioni.
Per una corretta applicazione del piano, i sistemi devono essere classificati secondo le seguenti definizioni:
Critici
Le relative funzioni non possono essere eseguite senza essere sostituite da strumenti (mezzi) di caratteristiche
identiche. Le applicazioni critiche non possono essere sostituite con metodi manuali. La tolleranza in caso di in-
terruzione è molto bassa, di conseguenza il costo di una interruzione è molto alto.
Vitali
Le relative funzioni possono essere svolte manualmente, ma solo per un breve periodo di tempo. Vi è una mag-
giore tolleranza all'interruzione rispetto a quella prevista per i sistemi critici, conseguentemente il costo di una
interruzione è inferiore, anche perché queste funzioni possono essere riattivate entro un breve intervallo di tem-
po (generalmente entro cinque giorni).
Delicati
Queste funzioni possono essere svolte manualmente, a costi tollerabili, per un lungo periodo di tempo. Benché
queste funzioni possano essere eseguite manualmente, il loro svolgimento risulta comunque difficoltoso e richie-
de l'impiego di un numero di persone superiore a quello normalmente previsto in condizioni normali.
Non-critici
Le relative funzioni possono rimanere interrotte per un lungo periodo di tempo, con un modesto, o nullo, costo
per l'azienda, e si richiede un limitato (o nullo) sforzo di ripartenza quando il sistema viene ripristinato.
14
Le procedure applicative, il software di sistema ed i file che sono stati classificati e documentati come critici,
devono essere ripristinati prioritariamente. Applicazioni, software e file classificati come critici hanno una tolle-
ranza molto bassa alle interruzioni. La criticità di applicazioni, software di sistema e dati, deve essere valutata
in funzione del periodo dell'anno in cui il disastro può accadere.
Un piano d'emergenza deve prevedere il ripristino di tutte le funzioni aziendali e non solo il servizio ICT centra-
le. Per la definizione del DRP devono essere valutate le strategie di ripristino più opportune su: siti alternativi,
metodi di back up, sostituzione degli equipaggiamenti e ruoli e responsabilità dei team. La prolungata indispo-
nibilità del servizio elaborativo derivante in particolare situazione di disastro, e quindi dei servizi primari, rende
necessario l'utilizzo di una strategia di ripristino in sito alternativo.
Tecniche di Disaster Recovery Allo stato attuale, la tecnologia offre la possibilità di realizzare varie soluzioni di continuità e Disaster Recovery,
fino alla garanzia di fatto di un’erogazione continua dei servizi IT, necessaria per i sistemi (es. finanziari o di
monitoraggio) definiti mission critical.
In pratica i sistemi e i dati considerati importanti vengono ridondati in un "sito secondario" o "sito di Disaster
Recovery" per far sì che, in caso di disastro (terremoto, inondazione, attacco terroristico, ecc.) tale da rendere
inutilizzabili i sistemi informativi del sito primario, sia possibile attivare le attività sul sito secondario nel più
breve tempo e con la minima perdita di dati possibile.
Chiaramente quanto più stringenti saranno i livelli di continuità tanto più alti saranno i costi di implementazio-
ne della soluzione.
In particolare, i livelli di servizio sono usualmente definiti dai due parametri Recovery Time Objective (RTO) e
Recovery Point Objective (RPO).
Replica sincrona La replica sincrona garantisce la specularità dei dati presenti sui due siti poiché considera ultimata una transa-
zione solo se i dati sono stati scritti sia sulla postazione locale che su quella remota. In caso di evento disa-
stroso sulla sede principale, le operazioni sul sito di Disaster Recovery possono essere riavviate molto rapida-
mente (basso RTO e RPO praticamente nullo).
La replica sincrona è limitata dalla incapacità dell'applicazione di gestire l'impatto del ritardo di propagazione
(vincolo fisico quindi, e non tecnologico) sulle prestazioni. In funzione della sensibilità dell'applicazione e della
tecnologia di comunicazione tra i due siti, l'efficacia della copia sincrona inizia a diminuire a una distanza varia-
bile tra i 35 km e i 100 km.
Replica asincrona Per far fronte al limite di distanza tra i due siti imposto da tecniche sincrone, si ricorre spesso alla tecnica di
copia asincrona. In questo caso il sito che si occuperà della replica può trovarsi anche a distanze notevoli. In
questo modo è possibile affrontare anche disastri con ripercussioni su larga scala (come ad esempio forti scos-
se sismiche) che altrimenti potrebbero coinvolgere entrambi i siti (se questi si trovano nelle vicinanze).
Un ulteriore vantaggio della copia asincrona è la possibilità di essere implementata via software non dovendo
necessariamente ricorrere a sofisticate e costose tecnologie di storage.
15
Fonti e autori delle voci
Gestione della continuità operativa Fonte: http://it.wikipedia.org/w/index.php?oldid=56711146 Autori:: Ar-
riano60, Avesan, Condor33, Eumolpo, Giampfrank, Pastore Italy, Squattaturi,
Stefanuzz1986, Theirrulez, Veneziano, 11 Modifiche anonime
Business continuity plan Fonte: http://it.wikipedia.org/w/index.php?oldid=56303885 Autori:: Ary29, Bultro,
Condor33, Cotton, Eumolpo, Giampfrank, Giorces, Jaqen, Phantomas, 4 Modifiche
anonime
Disaster recovery Fonte: http://it.wikipedia.org/w/index.php?oldid=56556466 Autori:: Alleborgo, Arriano60,
Ary29, Avesan, Condor33, Giampfrank, Guam, Hellis, Ignlig, Joana, Marius,
Pracchia-78, Protarkus, Qbert88, Sassospicco, Satyr, Veneziano, 35 Modifiche anonime
Gestione del rischio Fonte: http://it.wikipedia.org/w/index.php?oldid=58352188 Autori:: Alphamu57, Berto77,
Bultro, Condor33, DMor, ErixonBlues1980, Ettore Scarlino, Giovannimacchia,
Ilenia stel, Losògià, MattLanf, Mauro742, Pracchia-78, Senpai, Sentruper, Shivanarayana, Tiesse, TintoMeches,
Veneziano, Wetto, Yosri, 14 Modifiche anonime
Fonti, licenze e autori delle immagini file:Risk and Control Impact Assessment.JPG Fonte: http://it.wikipedia.org/w/index.php?
title=File:Risk_and_Control_Impact_Assessment.JPG Licenza: Creative Commons Zero Autori::
User:QuiteUnusual
Le piccole guide di TAI Solutions –3
2013 - www.taisolutions.it