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