Universidade Federal do Rio de Janeiro

Escola Politécnica

MBA em Governança, Projetos e Serviços de Tecnologia da

Informação (MGPS)

Gestão de Riscos: Uma Análise Comparativa de Normas,

Boas Práticas e Modelos de Maturidade

Autor:

_________________________________________________

Pedro Paulo Dayrell Rossi

Orientador:

_________________________________________________

Edilberto Strauss, Ph.D.

Examinador:

_________________________________________________

Flavio Luis de Mello, D.Sc.

Examinador:

_________________________________________________

Manoel Villas Bôas Junior, MSc.

MGPS

Janeiro de 2017

ii

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO

Escola Politécnica – Departamento de Eletrônica e de Computação

Centro de Tecnologia, bloco H, sala H-212B, Cidade Universitária

Rio de Janeiro – RJ CEP 21949-900

Este exemplar é de propriedade da Universidade Federal do Rio de Janeiro, que

poderá incluí-lo em base de dados, armazenar em computador, microfilmar ou adotar

qualquer forma de arquivamento.

É permitida a menção, reprodução parcial ou integral e a transmissão entre

bibliotecas deste trabalho, sem modificação de seu texto, em qualquer meio que esteja

ou venha a ser fixado, para pesquisa acadêmica, comentários e citações, desde que sem

finalidade comercial e que seja feita a referência bibliográfica completa.

Os conceitos expressos neste trabalho são de responsabilidade do(s) autor(es).

iii

AGRADECIMENTO

Agradeço aos meus pais, Paulo e Silvana, que tiveram a generosidade de me

apoiar em mais uma das minhas jornadas, tanto do ponto de vista moral quanto pelo

também importante ponto de vista financeiro. Sou eternamente grato também a minha

melhor amiga, esposa e companheira, Vera Ruffato, que não só me incentivou a fazer

esta pós-graduação, mas também tirou o carro da garagem todas as segundas e quartas

do ano com a única finalidade de me buscar na estação de metrô. Agradeço aos meus

antigos gestores e colegas da Oi por ter sempre respeitado meu horário de saída em dias

de aula. Por fim, agradeço aos professores e colegas do curso pelo conhecimento e pelas

experiências que foram compartilhadas ao longo destes meses.

iv

RESUMO

Normas técnicas e modelos de referência vêm nas últimas décadas procurando

sintetizar e colocar no papel as melhores práticas de gestão de riscos, seja abordando

esse conhecimento de forma independente ou de forma associada a outra prática, por

exemplo a gestão de projetos. Explorar essa multiplicidade de documentos e abordagens

permite identificar pontos divergentes e convergentes, esclarecendo as variáveis das

escolhas feitas pelas organizações acerca do tema.

Através da revisão bibliográfica das guias de referência e materiais relacionados,

considerando a adoção da ISO 31.000 como referência genérica, o presente trabalho

busca identificar as relações existentes entre os processos de gestão de riscos teorizados

por seis modelos de grande notoriedade no mercado (ISO 27.005, Risk IT, PRAM,

PMBOK, CMMI e MPS.BR). Esta análise resultou, entre outras coisas, na confirmação

de uma estrutura genérica persistente entre as diversas fontes e na discussão de

vantagens e desvantagens aparentes de cada um dos modelos estudados.

Palavras-Chave: Riscos, Gestão de Riscos, ISO 31.000, ISO 27.005, IT Risk, PRAM,

PMBOK, CMMI, MPS-BR.

v

ABSTRACT

Technical standards and reference models have come in the last decades trying

to synthesize and put on paper the best practices of risk management, either

approaching this knowledge independently or in a way associated with another practice,

for example project management. Exploring this multiplicity of documents and

approaches allows us to identify divergent and convergent points, clarifying the

variables of the choices made by organizations about the theme.

Through the bibliographic review of reference guides and related materials,

considering the adoption of ISO 31,000 as a generic reference, the present work seeks to

identify the existing relationships among risk management processes theorized by six

notorious models in the market (ISO 27.005, Risk IT, PRAM, PMBOK, CMMI and

MPS.BR). This analysis resulted, among other things, in the confirmation of a generic

structure persisting over different sources and in the discussion of apparent advantages

and disadvantages of each of the models studied.

Key-words: Risk, Risk Management, ISO 31.000, ISO 27.005, IT Risk, PRAM,

PMBOK, CMMI, MPS-BR.

vi

SIGLAS

ABNT – Associação Brasileira de Normas Técnicas

APM – Association for Project Management

CAPES – Coordenação de Aperfeiçoamento de Pessoal de Ensino Superior

COBIT – Control Objectives for Information and related Technology

CMMI – Capability Maturity Model – Integration

ERM – Enterprise Risk Management

GTZ – Deutsche Gesellschaft für Technische Zusammenarbeit

ISACA – Information Systems Audit and Control Association

ISO – International Organization for Standardization

ITIL – Information Technology Infrastructure Library

MPS.BR – Melhoria do Processo de Software Brasileiro

NBR – Norma Brasileira

PMBOK – Project Management Body of Knowledge

PMI – Project Management Institute

PRAM – Project Risk Analysis and Management

SEI – Software Engineering Institute

TI – Tecnologia da Informação

UFRJ – Universidade Federal do Rio de Janeiro

vii

Sumário

1 Introdução 1

1.1 - Tema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 - Delimitação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 - Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 - Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.5 - Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.6 - Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Embasamento Teórico 5

2.1 - Definição de Risco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 - Definição de Gestão de Riscos . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 - ISO 31000:2009. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4 - ISO/IEC 27005:2011 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5 - RISK IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.6 - PRAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.7 - PMBOK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.8 - CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.9 - MPS.BR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3 Discussões 38

3.1 - Considerações Gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.2 - Planejamento da Gestão de Riscos. . . . . . . . . . . . . . . . . . . . . . . 39

viii

3.3 - Identificação de Riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.4 - Análise de Riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.5 - Avaliação de Riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.6 - Tratamento de Riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.7 - Monitoramento e Controle de Riscos. . . . . . . . . . . . . . . . . . . . . 46

3.8 - Comunicação de Riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4 Conclusões 49

Bibliografia 51

ix

Lista de Figuras

2.1 – ISO 31000 Gestão de Riscos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 – Componentes da estrutura de gestão de riscos . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 – Processo de gestão de risco. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 – Equação de risco. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5 – Processo de gestão de risco de segurança da informação. . . . . . . . . . . . . . . . 13

2.6 – A atividade de tratamento do risco. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.7 – Frameworks internacionais de gestão de riscos. . . . . . . . . . . . . . . . . . . . . . . 17

2.8 – Categorias de riscos de TI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.9 – Framework do Risk IT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.10 – Fases do PRAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.11 – Processo do PRAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.12 – Grupos de processo PMBOK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.13 – Fases do PMBOK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.14 – Componentes do CMMI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.15 – Metas e Objetivos Específicos de Riscos no CMMI. . . . . . . . . . . . . . . . . . . 30

2.16 – Níveis de Maturidade MPS.BR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

x

Lista de Tabelas

1.1 – Modelos de referência de gestão de riscos revisados . . . . . . . . . . . . . . . . . . . 3

2.1 – Processos do PMBOK Guide 2013. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.2 – Objetivos Específicos da Gestão de Riscos no CMMI . . . . . . . . . . . . . . . . . 29

3.1 – Análise Comparativa – Planejamento da Gestão de Riscos . . . . . . . . . . . . . . 39

3.2 – Análise Comparativa – Identificação de Riscos . . . . . . . . . . . . . . . . . . . . . . . 42

3.3 – Análise Comparativa – Análise de Riscos. . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.4 – Análise Comparativa – Avaliação de Riscos . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.5 – Análise Comparativa – Tratamento de Riscos . . . . . . . . . . . . . . . . . . . . . . . . 46

3.6 – Análise Comparativa – Monitoramento e Controle de Riscos . . . . . . . . . . . . 47

3.7 – Análise Comparativa – Comunicação de Riscos . . . . . . . . . . . . . . . . . . . . . . 48

1

Capítulo 1

Introdução

1.1 – Tema

Considerando a classificação CAPES, o presente trabalho de conclusão de curso

enquadra-se na área Multidisciplinar, subárea de avaliação Interdisciplinar na

especialização Engenharia/Tecnologia/Gestão.

Possui como tema principal a Gestão de Riscos, tanto no sentido amplo desta

área de conhecimento quanto em suas diversas implementações no contexto da

tecnologia da informação. O tema Gestão de Riscos relaciona-se com a Governança de

TI, sendo considerado inclusive uma de suas principais dimensões.

1.2 – Delimitação

Esta pesquisa considera por universo amostral um número limitado de normas,

frameworks, boas práticas e modelos de maturidade, considerando a disponibilidade de

acesso aos documentos de referência. Desta forma, faz parte do escopo da pesquisa o

processo de Gestão de Riscos conforme prescrito nas normas ISO 31.000 e ISO 27.005,

no framework Risk IT (ICASA), nas guias PRAM e PMBOK, e nos modelos de

maturidade CMMI-SW e NPS.BR-SW.

Apesar da pesquisa tangenciar os temas de Gestão de Projetos e Governança,

tais assuntos não serão foco da discussão. Da mesma forma que, exceto as supracitadas,

não fazem parte do escopo a grande biblioteca de normas, padrões, frameworks, guias

de referência, boas práticas e modelos de maturidade que abordam a Gestão de Riscos.

2

1.3 – Justificativa

Durante as últimas duas décadas tem crescido o interesse em melhorar a

capacidade humana de lidar com a incerteza, e especialmente, prevenir seu impacto

negativo a nível da organização. Isto levou ao desenvolvimento de ferramentas,

técnicas, processos e metodologias tipicamente classificadas sob o rótulo de "gestão de

risco". Pesquisas em ferramentas de busca sobre gestão de risco, particularmente gestão

de risco empresarial, resultam em mais de 20 milhões de referências [1].

Considerando o crescimento da importância de projetos como método de

planejamento e execução de trabalho nas organizações [2] era um movimento natural

que as boas práticas de gestão de projetos eventualmente incluíssem também a gestão de

riscos em suas prerrogativas. Assim de fato ocorreu, sendo atualmente recomendado

que os gerentes de projeto reconheçam as ameaças e oportunidades em tempo e

respondam com rapidez suficiente para capturá-las, explorando os benefícios e

diminuindo ou atenuando as ameaças associadas [3].

Paralelamente, a tecnologia da informação tem assumido papel central em

muitos negócios [2] e, ao mesmo tempo que elimina riscos antigos, introduz riscos

completamente novos nas organizações. Desta forma, foram desenvolvidas práticas de

gestão especializadas nos riscos de TI, sendo algumas que abordam toda a TI de forma

holística e outras que se especializam ainda mais. O desenvolvimento de software é uma

das áreas que receberam atenção da gestão de riscos, justamente por ser uma atividade

complexa, envolvendo um grande número de fatores imprevisíveis e de difícil controle,

como inovações tecnológicas e mudanças nos requisitos do cliente. Outro campo que

adotou práticas da gestão de riscos é a segurança da informação.

A evolução da gestão de riscos trouxe com ela um grande número de livros,

artigos e conferências dedicadas ao assunto. Levou também ao desenvolvimento de uma

série de normas e frameworks que prescrevem e aconselham as organizações sobre a

melhor forma de gerir seus riscos. Considerando a importância do assunto, faz-se

necessário que as organizações adotem a metodologia de gestão de riscos mais

adequada para seu negócio e para seus objetivos organizacionais. No entanto, estas

informações encontram-se difusas e, como explicitado, distribuídas em diversas áreas

de conhecimento. Desta forma, qualquer esforço que atue no sentido de compilar,

explorar e analisar diferentes abordagens sobre o assunto, tal como o presente trabalho,

pode fornecer informações valiosas para tomada de decisão.

3

1.4 – Objetivos

O objetivo central deste trabalho é apresentar e comparar alguns dos principais

padrões para Gestão de Riscos de TI e Projetos disponíveis na literatura, identificando

os pontos de semelhança e divergência entre eles. Como objetivo específico, espera-se

identificar em cada um dos modelos estudados as fases correspondentes ao modelo de

processo genérico da norma ISO 31000 de gestão de riscos.

1.5 – Metodologia

O trabalho utiliza-se da revisão bibliográfica para estudar as normas, padrões,

frameworks e modelos de referência selecionados. Foram escolhidas duas referências

relacionadas à Gestão de Riscos em TI (ISO 27.005 e Risk IT), duas relacionadas com à

Gestão de Riscos em Projetos (PRAM e PMBOK) e dois modelos de maturidade

também relacionados à TI (CMMI e NPS.BR). O processo genérico de Gestão de

Riscos descrito na norma ISO 31.000 foi adotado como referencial comparativo e será

usado como parâmetro na avaliação dos demais.

Tabela 1.1. Modelos de referência de gestão de riscos revisados

Modelo/Padrão Autor Ano Foco

Norma ISO 31000 de Gestão de Riscos International Organization for

Standardization

2009 Geral

1. Norma ISO 27005 de Segurança da

Informação

International Organization for

Standardization

2011 TI

2. Risk IT ISACA 2009 TI

3. Project Risk Analysis & Management

(PRAM) Guide, 2nd edition

Association for Project

Management (APM)

2004 Projetos

4. Project Management Body of Knowledge

(PMBoK®): Capítulo 11, 5ed.

Project Management Institute

(PMI)

2013 Projetos

5. CMMI-SW SEI (Software Engineering

Institute) da Universidade

Carnegie Mellon

2010 TI

6. MR-MPS-SW:2016 do MPS.BR Softex 2016 TI

4

A parte principal deste documento consiste de uma série de tabelas que

organizam o conteúdo dos diferentes padrões de forma a facilitar a comparação entre os

mesmos. As tabelas foram divididas de acordo com as diferentes fases do processo de

Gestão de Riscos, conforme prescrito no modelo de referência. Através da análise

comparativa serão extraídas informações necessárias para discussão e posterior

atingimento dos objetivos desta pesquisa.

1.6 – Descrição

No capítulo 2 serão apresentadas definições importantes acerca do tema da

gestão de riscos, bem como serão detalhadas as normas, padrões e frameworks que

fazem parte do escopo deste estudo com o objetivo de balizar a posterior análise

comparativa entre as mesmas.

O capítulo 3 apresenta os resultados desta análise em questão. Para melhor

organização, este capítulo está dividido em subitens de acordo com a fase do processo

ou aspecto da gestão de riscos que está sendo comparado.

Finalmente no capítulo 4 as conclusões são apresentadas, complementadas pelas

considerações sobre possíveis desdobramentos do presente trabalho e as necessidades

identificadas de futuros trabalhos na área.

5

Capítulo 2

Embasamento Teórico

2.1 – Definição de Risco

A literatura disponível sobre riscos é bastante variada e percorre várias áreas do

conhecimento, resultando igualmente em diversas definições para risco. Nem mesmo o

estudo etimológico da palavra parece chegar a um consenso. Alguns autores acreditam

que se origina do latim risicare (ou resicare) e significa ousar [4]. Neste sentido, nota-

se que risco é uma opção ativa e não um destino. Conforme Bernstein [5], correr riscos

faz parte da história antiga.

Outros estudos sugerem que ela tenha sua origem no latim resecum, “o que

corta”, sendo utilizada para descrever situações relacionadas às viagens marinhas, como

“perigo oculto no mar” [6]. Esta última corrente parece corroborar a tese de Lieber &

Lieber [7] de que a palavra risco tem raízes nas transações comerciais marítimas, sendo

adaptada ao longo do tempo até chegar a atual denotação, geralmente negativa, sendo

sinônimo de perigo. Nascimento [8] diferencia perigo de risco, definindo o primeiro

como uma circunstância que pode causar dano, perda ou prejuízo e o segundo como a

probabilidade ou frequência esperada de dano, perda ou prejuízo diante da consumação

do perigo. A GTZ [9], na mesma linha, define que risco é a probabilidade de perdas e

danos em decorrência da interação de um perigo com uma situação de vulnerabilidade.

Destaca-se que, até então, risco assume um caráter de ameaça em todas as definições

apresentadas.

No entanto, a literatura moderna aceita também uma possibilidade de resultado

positivo dentro da definição de risco. Segundo D’Andrea (APUD Oliveira 2006) o risco

pode ser visto como uma oportunidade, quando centrada no investimento e tendo por

base iniciativas estratégicas [10]. Na visão deste autor, quanto maior o risco, maior é o

potencial de retorno, e, de forma não excludente, o potencial de perda. Dagnino e Carpi

Jr (2007) consideram risco como a probabilidade de que um evento – esperado ou não –

se concretize, sem fazer considerações sobre a natureza de seus efeitos [11].

6

Essa visão de risco como condição ou circunstância futura que poderá

proporcionar um impacto positivo ou negativo é praticamente unânime em todos os

modelos de referência e frameworks para Gestão de Riscos. Essa realidade pode ser

observada, por exemplo, na Gestão de Projetos. Apesar da Associação Brasileira de

Gestão de Projetos (ABGP) ter definido que “riscos são acontecimentos com impacto

negativo (prejuízos ou danos) ao sucesso geral do projeto” [12], a principal referência

em Gestão de Projetos, o Project Management Institute (PMI), desde 2004 já define

risco como “evento ou condição incerta que, se ocorrer, tem um efeito positivo ou

negativo sobre ao menos um dos objetivos do projeto, como tempo, custo, escopo ou

qualidade” [13].

A norma ISO 31.000, apoiada pela Guia 73:2009, define risco como “efeito da

incerteza nos objetivos” [14]. Se não houvesse complementação, a definição manteria

em aberto a natureza deste efeito, assumindo aspecto de neutralidade. No entanto, há no

Guia 73:2009 uma nota definindo efeito como qualquer desvio em relação ao esperado,

seja positivo ou negativo. No restante deste trabalho vamos assumir, assim como

classificou Raz e Hillson, a existência de três formas de definir risco [2]: 1. Definição

exclusivamente negativa, comparando risco à ameaça; 2. Definição ampla, que engloba

os conceitos de ameaça (negativo) e oportunidade (positivo); e 3. Definição neutra, que

não especifica a natureza das consequências.

2.2 – Definição de Gestão de Riscos

Gestão de Riscos é o nome dado para o conjunto de atividades coordenadas para

direcionar e controlar o ambiente da organização em relação aos riscos, incluindo

análise, avaliação, tratamento, aceitação e comunicação dos mesmos [15]. A gestão de

riscos é implementada com o objetivo de aumentar a eficiência operacional, reduzindo

assim, perdas e prejuízos decorrentes de fraudes, falhas, sinistros e acidentes,

conduzindo a uma melhoria dos processos organizacionais [16].

Gerenciamento e gestão possuem exatamente o mesmo significado, mas parece

haver uma preferência na literatura de projetos pelo nome gerenciamento, talvez por

compartilhar o mesmo radical da palavra gerente, papel exaltado neste âmbito. O PMI

define gerenciamento de risco como um processo sistemático que objetiva identificar,

analisar e responder aos riscos de um projeto. Atividade que procura ao mesmo tempo

7

reduzir ou eliminar a probabilidade e/ou impacto de um evento adverso ao projeto e

aumentar a probabilidade e/ou impacto de um evento positivo [13]. Segundo a APM,

trata-se de processo no qual decisões são tomadas para aceitar riscos conhecidos e

avaliados e/ou para implementar ações que reduzam as consequências (impactos) ou a

probabilidade de ocorrência destes riscos [17]. Com base em conceitos como os

expostos acima, Fabra conclui que gerenciamento de riscos é justamente um conjunto

de processos proativos que buscam aumentar a probabilidade de sucesso dos projetos,

através da identificação e análise de riscos bem como a execução de ações para eliminar

ou minimizar os problemas antes que estes venham a ocorrer [4].

Fazendo uma análise mais focada na Tecnologia da Informação (TI) pode ser

observado que a maior parte das instituições entende que a análise de riscos é um

caminho para cumprir com requisitos impostos em leis e marcos regulatórios

relacionados de alguma forma com a segurança da informação, como é o caso do

Acordo da Basiléia II e a Lei Sarbanes-Oxley (Janice). A ISACA define gestão de riscos

no contexto de TI como “processo de identificar as vulnerabilidades e ameaças aos

recursos de informação utilizados por uma organização para atingir os objetivos de

negócios e decidir quais as contramedidas, se houver, para reduzir o risco para um nível

aceitável, com base no valor do recurso de informação para a organização” [18].

Grande parte das definições já mencionam em si próprias a existência de fases

ou atividades que fazem parte do escopo da gestão de riscos. Por isto é importante a

existência de metodologias que organizem estas etapas com o objetivo de se alcançar

um efetivo controle dos riscos na organização. A adoção de “frameworks” de processo é

resultado desta demanda e tem sido uma das abordagens mais frequentes adotadas pelas

organizações [19], não só no cenário de risco. A palavra “framework”, cuja tradução

mais apropriada neste caso seria “estrutura lógica”, vem sendo usada há muitos anos no

mundo dos negócios, mas ainda assim carece de uma definição única, sendo comum a

confusão de significado e finalidade entre framework, norma, padrão, processo, guia de

boas práticas, modelo de referência, entre outros nomes.

A norma AS/NZS 4360, oriunda da Austrália e Nova Zelândia, não é o primeiro

esforço normativo para o processo de gestão de riscos, mas inegavelmente é uma das

principais referências na área. Por esse motivo, serve de base para o desenvolvimento da

norma internacional ISO 31000, cuja finalidade é ser um conjunto único de diretrizes e

um modelo genérico de gestão de riscos, que possa ser utilizado por organizações de

qualquer tamanho ou natureza [20].

8

A necessidade do tratamento específico de determinados assuntos, seja por conta

da complexidade dos mesmos ou pela busca por eficiência através da especialização,

estimulou o desenvolvimento de novos frameworks de processos para a gestão de riscos.

A gestão de riscos é uma disciplina em constante evolução. Padrões, frameworks e

diretrizes são modificados periodicamente à luz de novas pesquisas ou práticas

inovadoras, tornando difícil para os gerentes de risco se manterem atualizados [1].

2.3 – ISO 31000:2009

A International Organization for Standardization, amplamente conhecida como

ISO, é um organismo que estabelece padrões internacionais que "forma uma ponte entre

os setores público e privado". Embora muitos de seus institutos membros façam parte da

estrutura governamental de seus países, outros membros têm suas raízes no setor

privado. A ISO promulga padrões industriais e comerciais de propriedade industrial em

todo o mundo. A organização define-se como uma organização não governamental,

constituída por uma rede de institutos nacionais de normalização de 163 países, com um

secretariado central em Genebra, Suíça, que coordena o sistema.

Os Princípios e Diretrizes de Gestão de Riscos da ISO 31000 têm seu núcleo no

AS / NZS 4360 com contribuições da França, Suíça e Brasil [1]. Publicada em 2009, foi

desenvolvida por um grupo de trabalho multidisciplinar com integrantes de 35 países e

representantes de diferentes setores, tais como finanças, saúde, defesa, tecnologia,

seguros, projetos, etc. [21]. A terminologia foi atualizada no documento ISO 73: 2009

de Gestão de Risco. Estas duas normas devem ser consideradas em conjunto para fins

de implementação.

Como definiu Veloso, esta norma tem como objetivo ser uma norma genérica,

que possa ser utilizada por organizações de qualquer natureza tamanho, em todas as

suas áreas de negócio e níveis organizacionais, incluindo funções, atividades e projetos

específicos, através de uma abordagem que fornece os princípios e diretrizes para gerir

todas as formas de risco de maneira sistemática, transparente e confiável [21].

Desta forma, a ISO 31000 não trata apenas de um processo. O padrão é

estruturado em princípios (onze características de gestão de risco), um quadro de cinco

partes (mandato, concepção, implementação, monitoramento e melhoria) e um modelo

processo (comunicação e consulta, contexto, avaliação de risco, tratamento e

monitoramento). Vide abaixo Figura 2.1.

9

Figura 2.1 – ISO 31000 Gestão de Riscos. Fonte: RISK AND INSURANCE MANAGEMENT SOCIETY, INC. (RIMS) [1].

Os princípios, apesar de elementos fundamentais para estabelecer uma cultura de

gestão de riscos nas organizações, não fazem parte do escopo deste trabalho e, portanto,

não serão discutidos neste tópico. Já a estrutura (tradução ABNT para o framework da

norma original em inglês) precisa ser aqui abordada, pois através dela transmite-se a

orientação de que o processo de implantação e manutenção da gestão de riscos deve ser

iterativo, buscando a melhoria contínua. Na Figura 2.2, é possível identificar que o

framework segue o ciclo PDCA (PLAN - DO - CHECK - ACT) de Shewhart.

Figura 2.2 – Componentes da estrutura de gestão de riscos. Fonte: ABNT, ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS [14].

10

Voltando a Figura 2.1, fica nítido que este framework é distinto do processo e

gestão de riscos propriamente dito. À grosso modo, pode ser dito que esta estrutura

suporta e orienta o ciclo de vida do processo de gestão de riscos na organização, dando

as fundações e arranjos necessários para o sucesso deste. O processo é descrito

posteriormente na seção cinco do manual e é dividido em fases, conforme Figura 2.3.

Figura 2.3 – Processo de gestão de risco.

Fonte: ABNT, ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS [14].

Comunicação e consulta (5.2)

A comunicação e consulta com as partes interessadas externas e internas devem

ter lugar durante todas as fases do processo de gestão de riscos.

Estabelecimento do contexto (5.3)

Ao estabelecer o contexto, a organização articula os seus objectivos, define os

parâmetros externos e internos a ter em conta na gestão do risco e define o âmbito e os

critérios de risco para o processo restante. Alguns parâmetros serão similares aos

estabelecidos na fase de concepção da estrutura, mas aqui será necessário fazer um

maior detalhamento dos mesmos a fim de torna-los operacionais.

11

Avaliação de riscos (5.4)

A avaliação de riscos é a fase que engloba de identificação de riscos, análise de

riscos e avaliação de riscos. No documento da norma fica pouco claro o motivo que

levou a ISO a escolher esta forma de organizar as fases. Ao contrário das subfases, que

são descritas no detalhe, o item 5.4 carece de caracterização. A confusão taxonômica

agrava-se ao considerar o resultado da tradução da ABNT. No original em inglês, foram

adotadas palavras distintas para diferenciar a fase 5.4 – risk assessment – de sua subfase

5.4.4 – risk evaluation. No português, ambas são descritas como “avaliação” de riscos.

Identificação de riscos (5.4.2)

A organização deve identificar fontes de risco, áreas de impactos, eventos suas

causas e suas consequências potenciais. A finalidade desta etapa é gerar uma lista

abrangente de riscos com base nesses eventos que possam criar, melhorar, prevenir,

degradar, acelerar ou atrasar a realização dos objetivos. A identificação deve incluir

riscos, independentemente de sua fonte estar ou não sob o controle da organização,

mesmo que a fonte ou causa de risco não seja evidente.

Análise de riscos (5.4.3)

A análise de risco envolve o desenvolvimento de um entendimento completo

acerca do risco. A análise de riscos fornece uma contribuição para a avaliação de riscos

e para as decisões sobre se os riscos precisam ser tratados e sobre as estratégias e

métodos de tratamento de risco mais apropriados. Análise de risco também pode

fornecer um insumo para tomada de decisões onde escolhas devem ser feitas e as

opções envolvem diferentes tipos e níveis de risco.

Avaliação de riscos (5.4.4)

A avaliação do risco envolve a comparação do nível de risco encontrado durante

o processo de análise (5.4.3) com os critérios de risco estabelecidos quando o contexto

foi considerado (5.2). Com base nessa comparação, a necessidade de tratamento pode

ser considerada. O objetivo da avaliação de risco é auxiliar na tomada de decisão, com

base nos resultados da análise de risco, sobre quais riscos precisam de tratamento e

quais são as prioridades para a implementação do tratamento.

12

Tratamento de riscos (5.5)

O tratamento de risco envolve a seleção de uma ou mais opções para modificar

os riscos e implementar essas opções. Uma vez implementados, os tratamentos

fornecem ou modificam os controles. Envolve a seleção de opções de tratamento de

risco mais adequadas comparando os custos e esforços de implementação contra os

benefícios obtidos. Envolve também a preparação e implementação de planos de

tratamento de riscos, que devem estar devidamente documentados na organização.

Monitoramento e análise crítica (5.3)

Tanto o monitoramento como a revisão devem ser uma parte planejada do

processo de gestão de riscos e precisam garantir verificação ou vigilância regulares.

Podem ser feitos de forma periódica ou ad hoc. As responsabilidades de monitoramento

e revisão devem ser claramente definidas na organização. Os resultados devem ser

registados e reportados externamente e internamente, conforme apropriado, e devem

também ser utilizados como insumo para a revisão do framework de gestão de riscos.

2.4 – ISO/IEC 27005:2011

A norma ISO/IEC 27005, lançada em 2008, fornece diretrizes e descreve um

processo genérico para a Gestão de Riscos de Segurança da Informação de uma

organização. Segundo Veloso, a norma surge a partir da revisão dos padrões ISO/IEC

TR 13335-3:1998 e ISO/IEC TR 13335-4:2000 [21]. É parte integrante da família

ISO/IEC 27000 para a gestão da segurança da informação, sendo intencional a

exclusividade de uma norma somente para tratar do processo de gestão de riscos,

distinta das normas ISO/IEC 27001 e 27002. A segunda edição da ISO/IEC 27005 foi

publicada em 2011, refletindo a norma geral de gestão de riscos corporativos ISO

31000:2009 "Gestão de riscos - Princípios e diretrizes" no contexto específico dos riscos

envolvendo informação.

Segundo avalia Silva, o processo descrito pela norma, assim como na ISO

31000, é harmonicamente sincronizado com o ciclo PDCA [22]. O processo foi

construído de forma a permitir seu uso de forma independente, como por exemplo, para

avaliação de risco em projeto. A norma pode ser aplicada a todos os tipos de

organização, independentemente da natureza ou dimensão.

13

A norma entende que a Gestão de Riscos de Segurança da Informação é parte

integrante da Gestão de Riscos Corporativos. Justamente pelo esforço de especialização,

a definição de risco da 27005 distancia da usada na 31000. A norma de Segurança da

Informação define risco como a possibilidade de uma determinada ameaça explorar

vulnerabilidades de um ou mais ativos, prejudicando a organização. Esta definição está

na mesma linha do que Sêmola chamou de “equação do risco” [23].

Figura 2.4 – Equação de risco. Fonte: Sêmola [23].

Figura 2.5 – Processo de gestão de risco de segurança da informação. Fonte: ABNT, ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS [24].

14

A ISO/IEC 27005 tem como ponto central a definição do processo de gestão de

riscos de segurança da informação, representado na Figura 2.5. De forma geral, todas as

atividades são descritas em função de suas entradas, identificando as informações

necessárias para a execução da atividade, ação, que descreve a atividade, diretrizes, que

fornece as diretrizes para a implementação, saídas, que identificando as informações

resultantes da atividade. O processo é composto por seis atividades, sendo que, por

conta das iterações, as atividades de análise/avaliação de riscos e/ou tratamento do risco

podem ser realizadas mais de uma vez

Definição do contexto (7)

Definição do contexto para a prática da gestão de riscos de segurança da

informação, ou seja, nesta fase devem ser definidos os critérios básicos para a gestão de

riscos, seu escopo, suas delimitações e o estabelecimento de uma estrutura adequada

para suportar sua operação.

Processo de avaliação de riscos de segurança da informação (8)

Novamente a fase de avaliação de riscos engloba as subfases de identificação de

riscos, análise de riscos e avaliação de riscos. No entanto, ao contrário da ISO 31000, na

27005 há uma definição exclusiva para o agrupamento. De forma resumida, o processo

de avaliação de riscos quantifica ou descreve os riscos de forma qualitativa e capacita os

gestores a priorizar os riscos de acordo com a sua gravidade ou outros critérios.

Identificação de riscos (8.2)

Determinar eventos que possam causar uma perda potencial, deixando claro

onde estão localizados, seus motivos e como sucederiam. É necessária a identificação

em cada processo de negócio: os Ativos, os Eventos, as Vulnerabilidades, as Ameaças e

suas Consequências, bem como os Controles já existentes na empresa.

Análise de riscos (8.3)

A análise de risco, também chamada de estimativa, visa mensurar a

consequência ou impacto dos cenários de incidente e estimar a sua probabilidade. As

atividades que realiza são a estimativa do risco (com uso de métodos qualitativos e/ou

quantitativos), avaliação das consequências e avaliação da probabilidade.

15

Avaliação de riscos (8.4)

Nesta fase as organizações comparem os riscos estimados com os critérios de

avaliação de riscos definidos durante a definição do contexto. Com a avaliação de riscos

a etapa de análise/avaliação de riscos termina e chega-se ao primeiro ponto de decisão

do processo de gestão de riscos. Caso os resultados não tenham sido satisfatórios deve-

se retornar a fase de definição do contexto, caso a avaliação tenha sido satisfatória o

processo segue para o tratamento do risco.

Tratamento do risco de segurança da informação (9)

A partir da lista dos riscos ordenados por prioridades resultante da avaliação de

riscos, são implementados controles para reduzir, reter, evitar ou transferir os riscos

identificados, de acordo com o plano de tratamento definido pela organização. Esta fase

e seus possíveis desdobramentos estão representados no diagrama da Figura 2.6.

Figura 2.6 – A atividade de tratamento do risco. Fonte: ABNT, ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS [24].

16

As opções de tratamento do risco não são excludentes. É possível a combinação

de opções de forma a maximizar o resultado para a organização. As respostas descritas

pela norma ISO/IEC 27005 são quatro:

• Modificação do risco: realizar ações para reduzir a probabilidade e/ou impacto

• Retenção do risco: aceitar o ônus da perda

• Evitar o risco: eliminar atividade deforma que evite a ocorrência do risco

• Compartilhamento do risco: compartilhar com outrem o ônus da perda ou o

benefício do ganho associado ao risco.

As saídas desta fase serão o plano de tratamento do risco e os riscos residuais,

que precisarão ser determinados através da repetição da análise/avaliação de riscos,

considerando os efeitos previstos do tratamento proposto. Caso o risco residual ainda

não seja aprovado pela organização, uma nova iteração do tratamento do risco pode ser

executada antes de se prosseguir à aceitação do risco

Aceitação do risco de segurança de informação (10)

Nesta fase, gestores responsáveis devem fazer uma análise crítica e aprovar, se

for o caso, os planos de tratamento do risco e os riscos residuais. As condições

associadas a essa aprovação devem ser registradas.

Comunicação e consulta do risco de segurança de informação (11)

Assim como na ISO 31000, novamente o processo prevê que a comunicação e

consulta com as partes interessadas externas e internas devem ter lugar durante todas as

fases da gestão de riscos. O objetivo central desta fase é buscar um consenso entre as

partes interessadas e os tomadores de decisão sobre como os riscos devem ser

gerenciados. A coordenação entre estes atores pode ou não ser feita mediante uma

comissão específica para discussão de riscos.

Monitoramento e análise crítica de risco (12)

Os riscos, ativos, impactos, ameaças, vulnerabilidades e probabilidades devem

monitorados e analisados de forma crítica, com o objetivo de identificação tempestiva

de eventuais mudanças na organização que afetem o contexto. Essa fase assegura que o

resultado da avaliação e do tratamento dos riscos permaneçam relevantes e atualizados.

17

2.5 – Risk IT

O framework Risk IT complementa o COBIT 4.1 da ISACA. Embora o COBIT

estabeleça boas práticas para os “meios” de gerenciamento de risco, fornecendo um

conjunto de controles para mitigar o risco de TI, o Risk IT define boas práticas para os

“fins”, fornecendo um framework para as empresas possam identificar, governar e

gerenciar riscos de TI. O Risk IT é baseado nos princípios de padrões de gerenciamento

de riscos corporativos, como o COSO ERM e o AS/NZS 4360, buscando direcioná-los

para o contexto TI. Segundo a própria ISACA, o framework surgiu com o propósito de

preencher uma lacuna dos modelos predecessores, que na visão da instituição não

conseguiam abordar TI em profundidade e, ao mesmo tempo, cobrir todo escopo

esperado de um processo de gestão de riscos.

Figura 2.7 – Frameworks internacionais de gestão de riscos. Fonte: ISACA [25].

O Risk IT tem como fundação uma série de princípios orientadores para uma

gestão eficaz do risco de TI. Estes baseiam-se em princípios de ERM amplamente

aceitos, que foram aplicados ao domínio da TI. Apesar do processo de gestão de riscos

proposto pelo framework ter sido estruturado para colocar em prática estes princípios,

estes não são relevantes para as análises objetivadas no escopo deste trabalho.

18

Na concepção do Risk IT, risco de TI faz parte do risco do negócio,

especificamente aquele associado ao uso, propriedade, operação, envolvimento,

influência e adoção de TI dentro de uma empresa. Ele consiste em eventos relacionados

a TI e condições que podem potencialmente impactar o negócio. Podem ocorrer com

frequência e magnitude incertas e criar desafios no cumprimento das metas e objetivos

estratégicos. Neste modelo, o risco de TI pode ser categorizado de diferentes maneiras:

1. Risco de captação de benefício/valor de TI - associado a oportunidades

(perdidas) de uso de tecnologia para melhorar a eficiência ou a

efetividade de processos de negócios ou como facilitador de novas

iniciativas de negócios

2. Risco de programa de TI e de entrega de projetos - Associado à

contribuição da TI para soluções de negócios novas ou improvisadas,

normalmente sob a forma de projetos e programas. Isso se relaciona com

a gestão da carteira de investimentos.

3. Risco de operações e prestação de serviços de TI - Associado a todos os

aspectos do desempenho de sistemas e serviços de TI, que podem trazer

destruição ou redução de valor para a empresa.

Figura 2.8 – Categorias de riscos de TI. Fonte: ISACA [25].

A definição apresentada na Figura 2.8 é um exemplo da abordagem ampla do

conceito de risco, discutida previamente na seção 2.1. As consequências do risco podem

ser positivas ou negativas e, desta forma, o processo sugerido deve ser capaz de

preservar a empresa contra as perdas ao mesmo tempo que absorve ganhos potenciais.

19

O modelo de processo de gestão de risco agrupa atividades-chave em vários

processos. Esses processos por sua vez são agrupados em três domínios. No guia de

referência do framework são fornecidas orientações substanciais sobre as principais

atividades dentro de cada processo, as responsabilidades para o processo, os fluxos de

informação entre os processos e a gestão do desempenho do processo.

Figura 2.9 – Framework do Risk IT.

Fonte: ISACA [25].

Domínio Governança do Risco

A finalidade dos processos deste domínio é certificar que as práticas de gestão

de riscos estejam incorporadas na organização, permitindo assegurar um retorno

aceitável ajustado em função do. Este domínio contém três processos: estabelecer uma

visão comum de risco, integrar com a gestão de riscos corporativa e tomar decisões de

negócio com consciência dos riscos.

20

Estabelecer uma Visão Comum de Risco (RG1)

Objetiva assegurar que as atividades de gerenciamento de riscos se alinhem com

a capacidade objetiva da empresa para perda relacionada à TI e a tolerância subjetiva da

liderança para com a mesma. Suas atividades são:

• RG1.1 Realizar avaliação de riscos de TI da empresa.

• RG1.2 Propor limiares de tolerância ao risco de TI.

• RG1.3 Aprovar tolerância ao risco de TI.

• RG1.4 Alinhar a política de risco de TI.

• RG1.5 Promover a cultura consciente de risco de TI.

• RG1.6 Incentivar uma comunicação eficaz do risco de TI.

Integrar com a Gestão de Riscos Corporativa (RG2)

Tem por finalidade integrar a estratégia e operações de risco de TI com as

decisões estratégicas de risco de negócios que foram tomadas no nível da empresa. Pode

ser decomposto nas seguintes atividades:

• RG2.1 Estabelecer e manter a responsabilidade pela gestão de riscos de TI.

• RG2.2 Coordenar estratégia de risco de TI e estratégia de risco de negócios.

• RG2.3 Adaptar as práticas de risco de TI às práticas de risco empresarial.

• RG2.4 Fornecer recursos adequados para a gestão de riscos de TI.

• RG2.5 Fornecer garantia de independência para gestão de riscos de TI.

Tomar Decisões de Negócio com Consciência dos Riscos (RG3)

Este processo tem por objetivo assegurar de que as decisões empresariais

considerem o leque completo de oportunidades e consequências da confiança na TI para

o sucesso. É composto pelas atividades abaixo.

• RG3.1 Conquistar o apoio (buy-in) da gerência para a abordagem de análise

de risco de TI.

• RG3.2 Aprovar análise de risco de TI.

• RG3.3 Incorporar considerações de risco de TI na tomada de decisões

estratégicas de negócios.

• RG3.4 Aceitar riscos de TI.

• RG3.5 Priorizar atividades de resposta a riscos de TI.

21

Domínio Avaliação do Risco

Este domínio busca assegurar que os riscos e oportunidades relacionados à TI

sejam identificados, analisados e apresentados em termos de negócio. Este domínio está

dividido em três processos: coletar dados, analisar riscos e manter o perfil de risco.

Coletar Dados (RE1)

Através deste processo identifica-se os dados relevantes para permitir uma

identificação, análise e comunicação eficazes de riscos relacionados com TI.

• RE1.1 Estabelecer e manter um modelo para a coleta de dados.

• RE1.2 Coletar dados no ambiente operacional.

• RE1.3 Coletar dados sobre eventos de risco.

• RE1.4 Identificar fatores de risco.

Analisar Riscos (RE2)

Desenvolver informações úteis para apoiar as decisões de risco que levam em

conta a relevância dos fatores de risco para o negócio. Inclui:

• RE2.1 Definir o escopo da análise de risco de TI.

• RE2.2 Estimar o risco de TI.

• RE2.3 Identificar opções de resposta ao risco.

• RE2.4 Efetuar uma revisão por pares da análise de risco de TI.

Manter o Perfil de Risco (RE3)

Consiste em manter um inventário atualizado e completo dos riscos e atributos

conhecidos (por exemplo, frequência esperada, impacto potencial, disposição), recursos,

capacidades e controles de TI, conforme entendido no contexto de produtos, serviços e

processos de negócios. Contém as seguintes atividades:

• RE3.1 Mapear recursos de TI para processos de negócios.

• RE3.2 Determinar a criticidade dos recursos de TI para o negócio.

• RE3.3 Compreender a capacidade dos recursos de TI.

• RE3.4 Atualizar componentes de cenário de risco de TI.

• RE3.5 Manter o registro de riscos de TI e o mapa de riscos de TI.

• RE3.6 Desenvolver indicadores de risco de TI.

22

Domínio Resposta ao Risco

Como o próprio nome indica, busca assegurar que os problemas, oportunidades

e eventos de risco relacionados à TI sejam abordados de forma econômica e de acordo

com as prioridades do negócio. Este domínio está dividido em três processos: articular

riscos, gerenciar riscos e reagir a eventos.

Articular Riscos (RR1)

Este processo tem por objetivo assegurar que as informações sobre o estado real

das exposições e oportunidades relacionadas à TI sejam disponibilizadas no tempo e às

pessoas certas para uma resposta adequada.

• RR1.1 Comunicar os resultados da análise de risco de TI.

• RR1.2 Relatório de atividades de gestão de risco de TI e conformidade.

• RR1.3 Interpretar resultados da avaliação independente de TI.

• RR1.4 Identificar oportunidades relacionadas a TI.

Gerenciar Riscos (RR2)

Tem por finalidade assegurar que as medidas para aproveitar as oportunidades

estratégicas e reduzir o risco para um nível aceitável sejam geridas como um portfólio.

• RR2.1 Inventariar controles.

• RR2.2 Monitorar alinhamento operacional com limites de tolerância a risco.

• RR2.3 Responder à descoberta de exposição a risco e oportunidade.

• RR2.4 Implementar controles.

• RR2.5 Relatar o progresso do plano de ação de risco de TI.

Reagir a Eventos (RR3)

O último processo do framework objetiva assegurar que as medidas para

aproveitar oportunidades imediatas ou limitar a magnitude da perda de eventos

relacionados à TI sejam ativadas em tempo hábil e sejam eficazes.

• RR3.1 Manter os planos de resposta a incidentes.

• RR3.2 Monitorar riscos de TI.

• RR3.3 Iniciar resposta aos incidentes.

• RR3.4 Comunicar as lições aprendidas dos eventos de risco.

23

2.6 – PRAM

Em meados da década de 1990, a APM (Associação para Gerenciamento de

Projetos) do Reino Unido começou a desenvolver o Guia de Análise e Gestão de Riscos

de Projetos (PRAM em inglês). Consiste da compilação das experiências de um grande

número de organizações do Reino Unido que utilizaram processos formais de gestão de

riscos com êxito durante vários anos [26].

O processo PRAM usou nove fases desde o início de seu desenvolvimento, ao

invés dos quatro do processo SCERT [27], ou das várias estruturas de três a seis fases

utilizadas por outros membros do grupo de interesse especial responsável pela

iniciativa, devido à necessidade de buscar uma "base comum”. Havia uma clara

necessidade de que todos os envolvidos pudessem mapear seu processo para o processo

PRAM genérico, para garantir a propriedade coletiva [26].

As nove fases do PRAM seriam eventualmente organizadas na publicação em

seis fases e quatro subfases (vide Figura 2.10). Outra inovação no modelo foi separar o

processo de gestão de riscos de técnicas ou métodos detalhados que podem ser

utilizados em diferentes fases do processo [28]. O Guia PRAM ainda considera que um

risco pode ter resultados negativos ou positivos e, desta forma, também tratou de

englobar no processo genérico a capacidade da organização promover a gestão de

oportunidades.

Figura 2.10 – Fases do PRAM. Fonte: Chapman &Ward [29].

O processo PRAM foi um contributo muito importante para a gestão do risco do

projeto por causa de sua análise das necessidades de gestão e sua definição do processo,

incluindo os aspectos-chave cobertos por autores anteriores. Seguem algumas

implicações das atividades envolvidas no PRAM.

24

• Definir Projeto: consolidar uma compreensão inequívoca de todas as

características pertinentes do projeto

• Foco Processo de Gestão de Riscos (PRAM): definir o escopo e planejar

várias subfases e operações do PRAM

• Identificação: identificar todos os possíveis riscos e possíveis opções de

resposta (prevenção ou mitigação)

• Avaliação: implicações das suposições tomadas, propriedade do risco,

importância de capturar o risco, implicações das respostas.

• Planejamento: plano baseado em detalhes, avaliações de risco priorizadas,

planos de contingência proativos e reativos recomendados

• Gerenciamento: iniciação do replanejamento, se necessário, e relatório de

exceção.

Figura 2.11 – Processo do PRAM.

Fonte: Cooper [26].

Na Figura 2.11 as fases e subfases estão organizadas em uma espécie de

fluxograma, onde as relações entre as diferentes atividades estão demonstradas através

de setas. PRAM é um método cíclico que pode ser iniciado em praticamente qualquer

estágio do ciclo de vida do projeto e pode ser mantido enquanto compensar a relação

custo-benefício. Com a evolução do projeto, a eficácia obtida pelo uso do PRAM pode

tender a diminuir. Portanto, o tempo ideal para empregá-lo é nas fases iniciais do

projeto quando o controle de gerenciamento é máximo [30].

25

2.7 – PMBOK

O Project Management Body of Knowledge (PMBOK) é uma coletânea de

processos e áreas de conhecimento aceita como melhores práticas para a gestão

profissional de projetos [31].

Como um padrão reconhecido internacionalmente (ANSI/PMI 99-001-2008 e

IEE 1490-2011), provê aos gestores de projetos com as práticas fundamentais

necessárias para alcançar resultados organizacionais e excelência na prática do

gerenciamento de projetos [31].

Além disso, a guia PMBOK do Project Management Institute (PMI) explora

vários problemas da gestão de projetos, relacionando esse campo do conhecimento com

gestão de riscos em TI [13]. Em sua quinta edição, o PMBOK reconhece cinco grupos

de processo e dez áreas de conhecimento aplicáveis a projetos, programas e operações

[32]. Os cinco grupos de processos podem ser observados na Figura 2.12.

Figura 2.12 – Grupos de processo PMBOK. Fonte: PMI [13].

Na quarta edição do PMBOK existiam 42 processos. Na quinta edição, com a

introdução da área de conhecimento “Partes Interessadas”, o guia chegou ao número de

47 processos. O guia divide o conhecimento necessário para gerenciar projetos está

dividido em nove áreas: Gerência de Integração, Gerência de Escopo, Gerência de

Tempo, Gerência de Custo, Gerência de Qualidade, Gerência de Recursos Humanos,

Gerência de Comunicação, Gerência de Riscos e Gerência de Aquisições. A Tabela 2.1

mostra a relação entre grupos de processos, áreas de conhecimento e processos.

26

Tabela 2.1. Processos do PMBOK Guide 2013

Para o presente trabalho é importante focar no tema do Gerenciamento de

Riscos, representado por uma das áreas de conhecimento. Como torna evidente a Tabela

2.1, esta área possui cinco processos alocados no grupo de Planejamento e um sexto

processo alocado no grupo de Monitoramento e Controle.

Antes de adentrar os processos específicos da área de Gerenciamento de Riscos,

vale analisar o que o PMBOK entende por risco. O Guia PMBOK define risco como

“evento ou condição incerta que, se ocorrer, terá um efeito positivo ou negativo sobre

pelo menos um objetivo do projeto, como tempo, custo, escopo ou qualidade” [13].

O gerenciamento dos riscos do projeto inclui os processos de planejamento,

identificação, análise, planejamento de respostas, monitoramento e controle de riscos de

um projeto. Seu objetivo é maximizar a exposição aos eventos positivos e minimizar a

exposição aos eventos negativos. Para cada um destes processos, o PMBOK apresenta

uma estrutura com entradas, saídas, técnicas e ferramentas. A Figura 2.13 apresenta

todos estes elementos citados, mas ao invés de exibir os seis processos do

gerenciamento de risco, divide a área de conhecimento em quatro macroprocessos.

27

Figura 2.13 – Fases do PMBOK. Fonte: Chapman & Ward [29].

• Planejar o gerenciamento dos riscos (11.1): definir como serão conduzidas

as atividades de gerenciamento de riscos para o projeto.

• Identificar os riscos (11.2): determinar quais riscos podem afetar o projeto

e documentar suas características.

• Realizar a análise qualitativa dos riscos (11.3): processo de avaliação e

priorização dos riscos que serão objeto de análise ou ação adicional.

• Realizar a análise quantitativa dos riscos (11.4): realizar a análise

numérica do efeito dos riscos identificados nos objetivos gerais do projeto.

• Planejar as respostas aos riscos (11.5): desenvolver opções e ações para

aumentar oportunidades e reduzir ameaças em relação a objetivos do projeto.

• Controlar os riscos (11.6): consiste em monitorar e controlar os riscos

durante todo o ciclo de vida do projeto.

28

2.8 – CMMI

O modelo CMM – Capability Maturity Model foi criado em 1991 pelo SEI

(Software Engineering Institute) da Universidade Carnegie Mellon (CMU), em

Pittsburgh, EUA, por um grupo de profissionais de software. Patrocinado pelo

Departamento de Defesa dos Estados Unidos, surgiu da necessidade do governo

americano de criar um método para avaliar a capacidade de seus fornecedores de

software [33]. Desde então, foram desenvolvidos vários modelos para as mais diversas

disciplinas, estando entre os mais notáveis os desenvolvidos para engenharia de

sistemas, engenharia e aquisição de software, desenvolvimento e gestão da força de

trabalho, e desenvolvimento integrado de produtos e processos [34].

Apesar de terem se mostrado úteis, esses modelos específicos possuíam

diferenças significativas entre si, incluindo arquitetura, conteúdo e abordagem,

limitando a capacidade das organizações de focar esforços [34]. Com o objetivo de criar

uma terminologia comum e ao mesmo tempo eliminar inconsistências e redundâncias,

em 2000 foi lançado o CMMI (Capability Maturity Model Integration) [4]. A missão do

projeto de integração foi combinar três fontes de referêcia – (1) Modelo de Maturidade

de Capacidade para Software (SW-CMM) v2.0 projeto C, (2) Padrão Interino da

Aliança Eletrônica de Indústrias (EIA/IS) 731, e (3) Modelo de Maturidade de

Capacidade de Desenvolvimento de Produto Integrado (IPD-CMM) v0.98 - em um

único framework de melhoria [SEI 2002].

O CMMI-SW (Capability Maturity Model Integration for Software) foi criado

para integrar os diversos modelos CMM, que atendem às várias atividades relacionadas

ao desenvolvimento de software [35]. O modelo proposto CMMI-SW contém duas

representações: (i) por estágios, e (ii) contínua. A representação por estágios agrupa as

áreas de processo por nível de maturidade (inicial, gerenciado, definido, gerenciado

quantitativamente e em otimização), indicando quais os processos devem ser

implementados para que a organização atinga cada nível de maturidade.

Cada nível é constituído por um conjunto de áreas de processos, compostas por

objetivos específicos e objetivos genéricos. Cada objetivo específico pode ser composto

por um conjunto de práticas específicas. Um objetivo específico (SG) descreve as

características que devem ser buscadas para satisfazer o objetivo geral de uma área de

processo. Uma prática específica (SP), por sua vez, corresponde a descrição de uma

atividade que é importante para alcançar o objetivo específico a ela associado [4].

29

Figura 2.14 – Componentes do CMMI. Fonte: CMMI Product Team [34].

Embora a identificação e o monitoramento de riscos sejam atividades cobertas

pelas áreas de processo de “Planejamento de Projetos” e “Monitoração e Controle de

Projetos”, ambas no nível 2 de maturidade, Gerenciamento de Riscos aparece como

uma área de processo apartada no nível 3 [35]. O objetivo da área de processo é

identificar possíveis problemas antes que eles ocorram, para que as atividades de

tratamento de risco possam ser planejadas e invocadas conforme necessário ao longo da

vida do projeto para mitigar os impactos adversos na consecução dos objetivos. Na

Tabela 2.2 e na Figura 2.16 estão listados os objetivos específicos e suas práticas.

Tabela 2.2. Objetivos Específicos da Gestão de Riscos no CMMI

SG 1 Preparar-se para a Gerência de Riscos SP 1.1 Determinar Fontes e Categorias de Riscos

SP 1.2 Definir Parâmetros de Riscos

SP 1.3 Estabelecer uma Estratégia para a Gerência de Risco

SG 2 Identificar e Analisar Risco SP 2.1 Identificar Riscos

SP 2.2 Avaliar, Categorizar, e Priorizar Riscos

SG 3 Mitigar Riscos SP 3.1 Desenvolver Planos de Mitigação de Riscos

SP 3.2 Implementar Planos de Mitigação de Riscos

A área de processo Gerenciamento de Risco faz referência a um objetivo

genérico, denominado Institucionalizar um Processo Definido (GG 3). Este objetivo em

questão não será objeto de estudo, pois trata-se de um ponto comum já abordado pelas

organizações em outras áreas de processo do modelo de maturidade.

30

Figura 2.15 – Metas e Objetivos Específicos de Riscos no CMMI. Fonte: Williams [36].

Meta Específica SG1 – Preparar-se para a Gerência de Riscos

A preparação é conduzida estabelecendo e mantendo uma estratégia para

identificar, analisar e mitigar os riscos. Isso geralmente é documentado em um plano de

gerenciamento de riscos. A estratégia de gestão de riscos aborda as ações específicas e a

abordagem de gestão utilizadas para aplicar e controlar o programa de gestão de riscos.

Determinar Fontes e Categorias de Riscos (SP 1.1)

A identificação das fontes de risco fornece uma base para examinar

sistematicamente as situações em mudança ao longo do tempo para descobrir

circunstâncias que afetam o atingimento dos objetivos do projeto. Estabelecer categorias

de riscos prevê um mecanismo para a coleta e organização de riscos, bem como para

garantir o escrutínio adequado e atenção da gestão para os riscos que podem ter

consequências mais graves. Sub práticas:

1. Determinar fontes de risco.

2. Determinar categorias de risco.

Definir Parâmetros de Riscos (SP 1.2)

Definir os parâmetros utilizados para analisar e categorizar os riscos, bem como

os parâmetros utilizados para controlar o esforço de gestão de risco. Sub práticas:

31

1. Definir critérios consistentes para avaliar e quantificar a probabilidade de

risco e níveis de severidade.

2. Definir limiares para cada categoria de risco.

3. Definir limites na medida em que os limiares são aplicados contra ou dentro

de uma determinada categoria.

Estabelecer uma Estratégia para a Gerência de Riscos (SP 1.3)

Como o próprio nome diz, esta prática visa estabelecer e manter a estratégia a

ser utilizada para a gestão de riscos. Não possui sub práticas definidas.

Meta Específica SG2 – Identificar e Analisar Risco

Os riscos são identificados e analisados para determinar a sua importância

relativa. A análise de riscos implica a identificação de riscos das fontes identificadas e,

em seguida, a avaliação de cada risco levantado a fim de determinar sua probabilidade e

consequências. A categorização do risco, em função das categorias de risco

estabelecidas e dos critérios para a estratégia de gestão de risco, fornece as informações

necessárias para o tratamento de riscos.

Identificar Riscos (SP 2.1)

Consiste da identificação de potenciais problemas, perigos, ameaças e

vulnerabilidades que possam afetar negativamente os esforços ou planos de trabalho. Os

riscos são documentados em uma declaração concisa que inclui o contexto, as condições

e as consequências da ocorrência de risco. Sub práticas:

1. Identificar os riscos associados ao custo, cronograma e desempenho em

todas as fases apropriadas do ciclo de vida do projeto.

2. Revisar os elementos ambientais que podem afetar o projeto.

3. Rever todos os elementos da estrutura de divisão do trabalho como parte da

identificação de riscos para ajudar a garantir que todos os aspectos do

esforço de trabalho tenham sido considerados.

4. Reveja os elementos do plano do projeto como parte da identificação de

riscos para assegurar que todos os aspectos do projeto foram considerados.

5. Documentar o contexto, condições e potenciais consequências do risco.

6. Identificar as partes interessadas relevantes associados a cada risco.

32

Avaliar, Categorizar e Priorizar Riscos (SP 2.2)

Avaliar e categorizar cada risco identificado utilizando as categorias e

parâmetros de risco definidos e determinar a sua prioridade relativa. Sub práticas:

1. Avaliar os riscos identificados utilizando os parâmetros de risco definidos.

2. Categorizar e agrupar os riscos de acordo com as categorias definidas.

3. Priorizar riscos para mitigação.

Meta Específica SG3 – Mitigar Riscos

Os riscos são tratados e mitigados, quando apropriado, para reduzir os impactos

adversos na consecução dos objetivos. As etapas no manejo de riscos incluem o

desenvolvimento de opções de tratamento de riscos, o monitoramento de riscos e a

realização de atividades de gestão de riscos quando os limites definidos são excedidos.

Desenvolver Planos de Mitigação de Riscos (SP 3.1)

Desenvolver um plano de mitigação de riscos para os riscos mais importantes

para o projeto, conforme definido pela estratégia de gerenciamento de riscos. O modelo

sugere como opções de respostas: evitar o risco, controlar o risco, transferir o risco,

monitorar o risco e aceitar o risco. Sub práticas:

1. Determinar os níveis e limiares que definem quando um risco se torna

inaceitável e desencadeia a execução de um plano de mitigação de riscos ou

um plano de contingência.

2. Identificar a pessoa ou grupo responsável por endereçar cada risco.

3. Determinar a relação custo-benefício da implementação do plano de

mitigação de risco para cada risco.

4. Desenvolver um plano global de mitigação para o projeto para orquestrar a

implementação dos planos individuais de mitigação e contingência.

5. Desenvolver planos de contingência para riscos críticos selecionados no caso

de seus impactos serem realizados.

Implementar Planos de Mitigação de Risco (SP 3.2)

Monitorar o status de cada risco periodicamente e implementar o plano de

mitigação de riscos conforme apropriado. Sub práticas:

33

1. Monitorar status dos riscos.

2. Prover método para rastrear as atividades de tratamento de riscos abertas até

o seu fechamento.

3. Invocar opções de tratamento de riscos selecionadas quando os riscos

monitorados excederem os limites definidos.

4. Estabelecer um cronograma ou período de desempenho para cada atividade

de tratamento de risco incluindo data de início e data de conclusão previstas.

5. Fornecer comprometimento contínuo de recursos para cada plano para

permitir a execução bem-sucedida das atividades de tratamento de risco.

6. Coletar medidas de desempenho nas atividades de tratamento de risco

Na representação contínua do CMMI, existem seis Níveis de Capacidade para

qualquer uma das áreas de processo. Williams descreve como seria cada nível de

capacidade para o processo de Gestão de Riscos [36].

Nível de Capacidade 0-Incompleto. A gestão de riscos não é executada ou é

parcialmente executada. Um ou mais dos objetivos específicos não são satisfeitos.

Capacidade Nível 1-Executado. As práticas de gestão de risco da organização

satisfazem todos os objetivos específicos da área de processo de riscos.

Capacidade Nível 2-Gerenciada. Neste nível, a gestão de riscos não só é

executada, mas também planejada e executada de acordo com a política, emprega

pessoas qualificadas com recursos adequados, é monitorado, controlado e revisado;

Capacidade Nível 3-Definido. Nesse nível, a gestão de riscos é "gerenciada"

(nível de capacidade 2), mas também segue um processo que é adaptado a partir de um

guia padrão da organização, orientado por diretrizes específicas de forma a contribuir

com a melhoria dos ativos do processo organizacional.

Nível de Capacidade 4 - Gerenciado Quantitativamente. Neste nível, a gestão de

riscos um processo definido (nível de capacidade 3) que é controlado usando técnicas

estatísticas e outras técnicas quantitativas. A qualidade e o desempenho do processo são

entendidos em termos estatísticos e são gerenciados ao longo da vida do processo.

Capacidade Nível 5-Otimização. Neste nível, a gestão de riscos é um processo

gerenciado quantitativamente (nível de capacidade 4) que é alterado e adaptado para

atender aos objetivos de negócios atuais e projetados relevantes. Um processo de

otimização se concentra em melhorar continuamente o desempenho do processo por

meio de melhorias tecnológicas incrementais e inovadoras.

34

2.9 – MPS.BR

O MPS.BR ou Melhoria de Processos do Software Brasileiro é ao mesmo tempo

uma iniciativa para a melhoria da qualidade (Programa MPS.BR) e um modelo de

qualidade de processo (Modelo MPS). Voltado para a realidade do mercado brasileiro

de pequenas e médias empresas de desenvolvimento de software, ele é baseado nas

normas ISO/IEC 12207 e ISO/IEC 15504 e compatível com o CMMI [37].

O MR-MPS-SW usa como ponto de partida os conceitos de maturidade e

capacidade de processo para avaliar e promover a melhoria da qualidade e da

produtividade de software. A capacidade do processo é caracterizada como a habilidade

do processo de alcançar os objetivos de negócio (no presente e no futuro). Neste

modelo, para que uma organização evolua nos níveis de maturidade, um maior nível de

capacidade para desempenhar o processo deve ser atingido. Este desempenho, por sua

vez, é medido pelo atendimento aos atributos do processo (AP) requerido para todos os

processos no nível correspondente ao nível de maturidade.

Sobre a gestão de riscos, identifica-se que o planejamento (incluindo a

identificação e priorização) e a monitoração dos riscos são iniciados no nível G de

maturidade com os resultados GPR6 e GPR15 do processo Gerência de Projetos (GPR),

mas o processo de Gestão de Riscos propriamente dito somente surge no nível de

maturidade C. Sendo os níveis cumulativos, este é composto pelos níveis de maturidade

anteriores (G ao D), acrescidos, além da Gerência de Riscos dos processos

Desenvolvimento para Reutilização e Gerência de Decisões. Neste nível de maturidade,

os processos devem satisfazer os cinco atributos de processo listados abaixo.

• AP 1.1 O processo é executado – medida do quanto o propósito do

processo é alcançado por sua execução.

• AP 2.1 A execução do processo é gerenciada – medida do quanto a

execução do processo é gerenciada.

• AP 2.2 Os produtos de trabalho do processo são gerenciados – medida do

quanto os produtos de trabalho do processo são gerenciados.

• AP 3.1. O processo é definido – medida do quanto o processo padrão da

organização é mantido de forma a apoiar sua adaptação para um processo

definido.

• AP 3.2 O processo está implementado – medida do quanto o processo

padrão está implementado na organização.

35

Figura 2.16 – Níveis de Maturidade MPS.BR. Fonte: Adaptado de Williams [36].

De acordo com MR-MPS-SW, a Gerência de Riscos deve ser aplicada tanto a

riscos de projeto quanto a riscos organizacionais. Sobre a definição de risco, adota o

conceito do IEEE, onde risco é tido como a probabilidade de um evento, perigo, ameaça

ou situação ocorrer associado a consequências indesejáveis, com potenciais impactos.

O propósito do processo, como enunciado pelo modelo, concentra-se em

cumprir as etapas de identificação, análise, tratamento e monitoramento de riscos,

reduzindo-os de forma continua no âmbito organizacional e de projeto. Para ser

considerado implantado, além dos atributos de processo, precisa satisfazer os resultados

esperados. O MR-MPS-SW enumera nove resultados esperados para este processo.

GRI1 - O escopo da gerência de riscos é determinado

A gerência de riscos poder ser aplicada dentro do âmbito dos projetos ou

também para atividades organizacionais. Para atingir esse resultado deve-se definir

claramente a abrangência de aplicação do processo de gerência de riscos na organização

em relação à sua estrutura organizacional e de processos.

GRI2 - As origens e as categorias de riscos são determinadas e os parâmetros

usados para analisar riscos, categorizá-los e controlar o esforço da gerência de

riscos são definidos

36

A organização deve definir uma classificação e critérios para determinação da

probabilidade e da severidade dos riscos. Estas estimativas da probabilidade e impacto

dos riscos podem ser realizadas quantitativa ou qualitativamente.

GRI3 - As estratégias apropriadas para a gerência de riscos são definidas e

implementadas

Uma estratégia de gerência de riscos deve ser definida, definindo e relacionando

aspectos como: escopo; métodos e ferramentas para identificação, análise, mitigação,

monitoração e comunicação; técnicas de mitigação; medidas para monitorar os riscos;

periodicidade de monitoração e avaliação dos riscos. Normalmente a estratégia pode

estar representada no plano de gerência de riscos a ser seguido.

GRI4 - Os riscos do projeto são identificados e documentados, incluindo seu

contexto, condições e possíveis consequências para o projeto e as partes

interessadas

Considerando as fontes e categorias de risco determinadas, deve-se identificar os

riscos potenciais para a organização ou para o projeto, assim como contexto, condições

e consequências associadas. A atividade de identificação de riscos pode fazer uso de

várias abordagens, como reuniões, análises de cenário, árvores de decisão, etc. Estas

informações devem ser devidamente documentadas.

GRI5 - Os riscos são priorizados, estimados e classificados de acordo com as

categorias e os parâmetros definidos

Os riscos identificados devem ser organizados em categorias e ter sua prioridade

determinada. A priorização pode ser feita a partir da determinação da probabilidade e o

impacto dos riscos, seja através de métodos qualitativos ou por meio de métodos

quantitativos. A lista de riscos geral, com seus respectivos parâmetros, quanto a relação

priorizada devem ser documentadas. Os interessados devem ser comunicados

GRI6 - Planos para a mitigação de riscos são desenvolvidos

Deve-se estabelecer planos de mitigação para os riscos prioritários. Os planos de

mitigação serão executados antes que o risco ocorra, diminuindo assim sua

probabilidade e/ou impacto. Evitar um risco ou aceitá-lo também são respostas

possíveis, contanto que estejam previstas no plano.

37

GRI7 - Os riscos são analisados e a prioridade de aplicação dos recursos para o

monitoramento desses riscos é determinada

Atinge-se este resultado ao garantir que os riscos que serão tratados pela

gerência de riscos passem previamente por seleção e análise que determine a prioridade

para aplicação dos recursos (materiais e humanos).

GRI8 - Os riscos são avaliados e monitorados para determinar mudanças em sua

situação e no progresso das atividades para seu tratamento

Os riscos devem ser monitorados e reavaliados periodicamente. Os planos de

mitigação e contingência também devem ser eventualmente revistos, pois podem

necessitar de ajustes em função de alterações nos riscos.

GRI9 - Ações apropriadas são executadas para corrigir ou evitar o impacto do

risco, baseadas na sua prioridade, probabilidade, consequência ou outros

parâmetros definidos

Deve-se realizar a monitoração periódica dos riscos, verificando a necessidade

da execução de ações de mitigação e/ou contingência. As ações que forem julgadas

necessárias devem ser executadas até sua devida conclusão.

38

Capítulo 3

Discussões

3.1 – Considerações Gerais

O foco da análise comparativa foi verificar até que ponto os processos e etapas

descritos pelas várias normas são semelhantes entre si. Um alto grau de similaridade e

consistência entre os padrões indicaria a existência de um consenso tácito sobre a forma

como a gestão de risco deve ser conduzida.

Uma revisão das etapas do processo descritas pelos padrões selecionados

identificou a existência de cinco etapas que vão em direção a este consenso:

planejamento, identificação de riscos, análise de riscos, tratamento de riscos (ou

mitigação) e controle (ou monitoramento). As etapas de avaliação (no sentido de

evaluation) e comunicação, previstas no processo genérico da norma ISO 31000, estão

ausentes de um ou mais modelos de processo.

A terminologia difere entre as normas, embora a estrutura do processo em cada

caso seja semelhante. Por exemplo, em alguns padrões, a "análise" é chamada de

"avaliação" e em alguns casos a análise é dividida em "estimativa" (de probabilidade e

impacto dos eventos de risco) e "avaliação" (determinando a magnitude global do

evento de risco, de onde deriva sua prioridade). Estas diferenças serão discutidas ao

longo dos próximos subitens. Como ponto de partida para tal, será adotado o modelo de

processo descrito na ISO 31000, conforme determinado na metodologia.

A comparação das fases dos processos das seis normas é apresentada nos

próximos tópicos em sete tabelas separadas (Tabelas 3.1 a 3.7), uma para cada uma das

fases e subfases do processo de gestão de riscos genérico. Cada tabela é composta pela

ISO 31000 (modelo de referência) seguida de seis linhas, reservadas para os demais

padrões selecionados. As entradas na tabela podem, dependendo do modelo, incluir

números, códigos ou rótulos originais dos modelos, ajudando a fazer o paralelo com o

documento onde estão originalmente descritos.

39

3.2 – Planejamento da Gestão de Riscos

Na Tabela 3.1 compara-se a forma como os diferentes padrões abordam a etapa

de planejamento, que é a etapa que exibe a maior variabilidade em termos de escopo e

nível de detalhe. Alguns padrões incluem nesta etapa questões de toda a organização,

tais como o estabelecimento da política de gerenciamento de riscos, a definição de

papéis e responsabilidades em vários níveis e o estabelecimento do processo a ser

seguido. Outros, devido a própria finalidade do modelo, são mais especializados.

Tabela 3.1. Análise Comparativa – Planejamento da Gestão de Riscos

Planejamento da Gestão de Riscos

ISO 31.000 5.3. Estabelecimento do contexto

5.3.1. Estabelecer o contexto interno

5.3.2. Estabelecer o contexto externo

5.3.3. Estabelecer o contexto do processo de gestão de risco

5.3.4. Desenvolver de critérios de risco

5.3.5. Definir a estrutura para análise de risco

1. ISO 27.005 7. Definição do contexto

7.2. Critérios básicos

7.2.1. Abordagem da gestão de riscos

7.2.2. Critérios para avaliação de riscos

7.2.3. Critérios de impacto

7.2.4. Critérios para aceitação do risco

7.3. Escopo e limites

7.4. Organização para gestão de riscos de segurança da informação

2. IT Risk Domínio RG

RG1.2 Propor limiares de tolerância ao risco de TI.

RG2.1 Estabelecer e manter a responsabilidade pela gestão de riscos

de TI

RG2.3 Adaptar as práticas de risco de TI às práticas de risco

empresarial.

RG2.4 Fornecer recursos adequados para a gestão de riscos de TI

Domínio RE RE2.1 Definir o escopo da análise de risco de TI.

3. PRAM Iniciação

Definir o escopo, os objetivos e o contexto para a gestão de riscos,

posteriormente dividida em duas subfases:

a. Definir o projeto visa assegurar a compreensão comum que o

processo de gestão de risco deve ser aplicado.

B. Foco Processo de Gestão de Riscos ajusta os detalhes do processo

de gestão aos requisitos específicos

Estrutura Organizacional

Planejamento para a gestão de riscos

Responsabilidades

40

A norma ISO/IEC 27005, em consonância com a norma genérica expressa pela

ISO 31000, prevê um estrutura pré-existente na organização onde o processo de gestão

de riscos é executado. Desta forma, apesar das duas normas aparentemente iniciarem

com estabelecimento de contexto, já existem definições importantes alimentadas pelo

framework anterior ao processo.

No caso dos modelos de maturidade (CMMI e MPS.BR) é compreensível que

muito do que era esperado para planejamento de gestão de risco não possa ser

encontrado no processo específico de Gerência de Riscos. São modelos mais amplos,

que tentam evitar redundância entre diferentes processos. No caso do MPS.BR, está

especificado que o planejamento da gestão de riscos tem início no nível G de

maturidade com os resultados GPR6 e GPR15 do processo Gerência de Projetos (GPR).

Áreas funcionais:

O papel do Gerente de Projetos

O papel do Gerente do Processo de Riscos

O papel do Gerente de Riscos

O papel do dono do Risco

O papel do dono da Ação

O papel do Especialista Técnico

Outros papéis funcionais

O papel do executivo patrocinador

Gestão de riscos e o ciclo de vida do projeto

Provendo recursos ao processo de gestão de riscos

Provendo recursos às ações de resposta aos riscos

4. PMBOK 11.1. Planejar o gerenciamento de riscos

O processo de decidir como abordar e conduzir as atividades de

gerenciamento de risco para um projeto.

Entradas: fatores ambientais da empresa; Ativos de processos

organizacionais; declaração do escopo do projeto; Plano de

gerenciamento do projeto. Ferramentas e técnicas: planejamento de

reuniões e análise.

Saídas: Plano de Gestão de Riscos (metodologia, funções e

responsabilidades, orçamentação, calendário, categorias de risco,

definições de probabilidade e impacto, tolerâncias dos stakeholders,

formatos de relatórios, acompanhamento

5. CMMI Preparar-se para a Gerência dos Riscos (SG 1)

• Determinar Fontes e Categorias de Riscos (SP 1.1)

• Definir Parâmetros de Riscos (SP 1.2)

• Estabelecer uma Estratégia para Gerência de Risco (SP 1.3)

6. MPS BR (Começa na maturidade G, com GPR6 e GPR15

GRI 1. O escopo da gerência de riscos é determinado;

GRI 2. As origens e as categorias de riscos são determinadas e os

parâmetros usados para analisar riscos, categorizá-los e controlar o

esforço da gerência de riscos são definidos;

GRI 3. As estratégias apropriadas para a gerência de riscos são

definidas e implementadas;

41

O PRAM coloca uma ênfase grande na etapa de planejamento, vide o número de

itens expostos na tabela 3.1. Esta complexidade no planejamento é condizente com a

leitura de Del Caño de que o processo PRAM é desenhado com foco em projetos de

maior porte [38]. Para projetos pequenos, talvez o benefício obtido com este grau de

detalhe não compense o esforço empenhado.

Já o PMBOK parece ir no caminho oposto. Ao contrário do PRAM, ele não se

preocupa tanto com alguns aspectos organizacionais alheios ao projeto. Uma conclusão

que pode ser tirada é que o processo de gestão de riscos do PRAM receita como a

organização deve gerir riscos no projeto, enquanto o processo no PMBOK, apesar de

receber ativos organizacionais como entrada, foca mais no papel do gerente de projeto.

Sobre o Risk IT, não parece razoável restringir o planejamento a um único

domínio ou processo. Para fazer um paralelo com o estabelecimento de contexto da

norma ISO 31000 é necessário visitar pelo menos dois domínios. No entanto, seria

premeditado concluir que o framework rompe com o processo genérico. Apesar da

pluralidade dos domínios e processos, as atividades estão entrelaçadas de forma coesa,

representando na prática uma fase de planejamento.

3.3 – Identificação de Riscos

A Identificação de Riscos não é uma das etapas principais do processo genérico

de gestão de riscos da ISO 31.000, sendo na verdade uma subdivisão do processo

Avaliação de Riscos (no sentido de assessment). O mesmo entendimento foi mantido na

norma ISO/IEC 27005. No entanto, além da existência nítida de três fases totalmente

dissociáveis, nota-se uma ausência de identidade própria neste agrupamento. Parece que

tal agrupamento existe somente no intuito de criar uma classificação hierarquicamente

superior que pudesse ser referenciada posteriormente. Por exemplo, a ISO/IEC 31010 é

uma norma que reúne técnicas para as atividades de identificação de risco, análise de

risco e avaliação de risco (evaluation). Desta forma, criar o agrupamento avaliação de

risco (assessment) parece uma demanda de coesão da própria família ISO 31000.

Na Tabela 3.2 são listadas as formas com que os diferentes modelos descrevem

a fase de identificação de riscos. Esta talvez seja a fase que apresenta maior

convergência entre todos os modelos, inclusive em relação a terminologia, pois em

cinco deles consta o verbo identificar ou uma de suas flexões. Praticamente em todos os

padrões a identificação ocorre em uma etapa exclusiva para esse fim.

42

Tabela 3.2. Análise Comparativa – Identificação de Riscos

Identificação de Riscos

ISO 31.000 5.4. Avaliação de riscos (assessment)

5.4.2. Identificação de riscos

1. ISO 27.005 8. Avaliação de riscos de segurança da informação

8.2. Identificação de riscos

8.2.2. Identificação dos ativos

8.2.3. Identificação das ameaças

8.2.4. Identificação dos controles existentes

8.2.5. Identificação das vulnerabilidades

8.2.6. Identificação das consequências

2. IT Risk Este processo está incluso em RE2.2 Estimar o Risco de TI

A identificação de riscos compreende os seguintes elementos:

• Cenários de Risco

• Fatores de Risco

3. PRAM Fase de identificação:

Buscar por fontes de risco e respostas;

Classificação: estrutura adequada para riscos e respostas, agregando

ou segregando conforme apropriado.

Caracterização: identificador simples ou descrição

4. PMBOK 11.2. Identificar riscos

Entradas: Planos de gerenciamento (riscos, custos, cronograma,

qualidade, recursos humanos); Linha de base do escopo; Estimativas

de custos e duração das atividades; Registro das partes interessadas;

Documentos do projeto; Documentos de aquisição; Fatores

ambientais da empresa; Ativos de processos organizacionais

Saídas: Registro dos riscos

5. CMMI Identificar e Analisar Risco (SG 2)

• Identificar Riscos (SP 2.1)

6. MPS BR GRI 4. Os riscos do projeto são identificados e documentados,

incluindo seu contexto, condições e possíveis consequências para o

projeto e as partes interessadas;

A única exceção fica por conta do framework Risk IT. Ao invés de separar uma

atividade específica para identificar riscos, a ISACA optou por manter esta fase como

uma parte integrante da atividade Estimar Risco (RE2.2). O entendimento do modelo é

que a identificação dos riscos ocorre como uma consequência natural da identificação

de fatores e cenários de risco. Em outros modelos a análise de cenários é vista como

uma ferramenta de identificação de riscos, não sendo necessariamente obrigatória.

Vale ressaltar que a necessidade de documentar os riscos identificados nesta fase

está explícita em todos os modelos estudados. Este resultado, chamado no PMBOK de

registro do risco, pode variar seu formato de acordo com a metodologia utilizada.

43

3.4 – Análise de Riscos

Na Tabela 3.3 são listados os aspectos referentes à análise de riscos, conforme

foram identificados nos modelos estudados. Se na fase de identificação existia um

consenso entre os modelos, nesta fase há um movimento no sentido oposto.

Tabela 3.3. Análise Comparativa – Análise de Riscos

Análise de Riscos

ISO 31.000 5.4. Avaliação de riscos (assessment)

5.4.3. Análise de riscos

1. ISO 27.005 8. Avaliação de riscos de segurança da informação

8.3. Análise de riscos

8.3.1. Metodologia de análise de riscos

• Análise qualitativa de riscos

• Análise quantitativa de riscos

8.3.2. Avaliação das consequências

8.3.3. Avaliação da probabilidade dos incidentes

8.3.4. Determinação do nível de risco

2. IT Risk RE2 Analisar Risco

RE1 Coletar Dados

3. PRAM Fase de avaliação (assess):

Estrutura:

Busca / brainstorm / entrevista;

Ordenar riscos e respostas para propósito de discussão;

Distinguir respostas específicas e gerais.

Ownership:

Alocar responsabilidade;

Aprovar alocação de contractors.

Estimativa:

Identificar áreas requerendo decisões cuidadosas;

Identificar áreas requerendo mais dados e análise.

4. PMBOK 11.3. Realizar a análise qualitativa dos riscos

Entradas: Plano de gerenciamento de riscos; Linha de base do escopo;

Registro dos riscos; Fatores ambientais da empresa; Ativos de

processos organizacionais

11.4. Realizar a análise quantitativa dos riscos

Entradas: Planos de gerenciamento (riscos, custos e cronograma);

Registro dos riscos; Fatores ambientais da empresa; Ativos de

processos organizacionais

Saídas: Atualizações dos Documentos do projeto

5. CMMI Identificar e Analisar Risco (SG 2)

Avaliar, Categorizar e Priorizar Riscos (SP 2.2)

6. MPS BR GRI5 - Os riscos são priorizados, estimados e classificados de acordo

com as categorias e os parâmetros definidos

44

A maior parte dos modelos estudados parece divergir do entendimento da ISO

31000, que separa a análise de risco da fase de avaliação de risco (evaluation). Neste

entendimento, compartilhado pela ISO/IEC 27005 e pela PRAM, analisar risco vai de

encontro ao conceito de estimar risco, ou seja, mensurar a probabilidade de ocorrência e

dimensão do impacto dos riscos identificados. A confrontação destas estimativas com

critérios pré-estabelecidos a fim de categorizar e priorizar riscos seria coberta pela fase

seguinte, de avaliação de riscos (no sentido de evaluation).

Independente desta divergência, pode ser dito que em todos os modelos há

alguma espécie de mensuração de probabilidade e impacto na fase de análise. Existem

três formas de fazer esta mensuração: por métodos qualitativos, por métodos

quantitativos ou por uma combinação dos dois métodos. O PMBOK atribui uma ordem

entre eles, determinando que a análise quantitativa seja feita após a priorização dos

riscos por vias qualitativas. Os outros modelos já preferem deixar esta escolha a critério

do responsável pela atividade de análise de riscos.

Considerando exclusivamente a gestão de riscos de TI, percebe-se nesta etapa

um diferencial do framework Risk IT em relação a ISO/IEC 27005. Seu processo de

Analisar Riscos (RE2), além de considerar todas as abordagens de estimativa

mencionadas na ISO, preocupa-se também em gerar informações uteis para suportar

decisões relacionadas a risco, levando em consideração a relevância para o negócio.

3.5 – Avaliação de Riscos

A Tabela 3.4 apresenta as abordagens dos modelos estudados em relação a

avaliação de risco (no sentido de evaluation). Conforme pode ser observado, as normas

ISO e o modelo PRAM descrevem uma fase própria, enquanto as demais executam a

categorização e a priorização de riscos junto de fases anteriores. A separação traz um

benefício na representação gráfica dos processos. Analisando os fluxogramas sugeridos

pela ISO/IEC 27005 (Figura 2.6) e PRAM (Figura 2.11), percebe-se que a fase de

avaliação de risco representa um ponto de decisão. Se a avaliação não ocorrer de forma

satisfatória o processo retorna a fase de estimativa (no caso do PRAM) ou reinicia na

fase de definição de contexto (no caso da ISO/IEC 27005).

45

Tabela 3.4. Análise Comparativa – Avaliação de Riscos

Avaliação de Riscos

ISO 31.000 5.4. Avaliação de riscos (assessment)

5.4.4. Avaliação de riscos (evaluation)

1. ISO 27.005 8. Avaliação de riscos de segurança da informação

8.4. Avaliação de riscos (evaluation)

2. IT Risk RE2.2 Estimar Risco de TI

3. PRAM Fase de avaliação (assess):

Avaliar (evaluate)

4. PMBOK 11.3. Realizar a análise qualitativa dos riscos

11.4. Realizar a análise quantitativa dos riscos

5. CMMI Identificar e Analisar Risco (SG 2)

• Avaliar, Categorizar e Priorizar Riscos (SP 2.2)

6. MPS BR GRI5 - Os riscos são priorizados, estimados e classificados de acordo

com as categorias e os parâmetros definidos

3.6 – Tratamento de Riscos

Na etapa de tratamento de risco (Tabela 3.5), o conjunto de possíveis cursos de

ação mencionado pela maioria dos padrões foi bastante limitado, e inclui as seguintes

respostas: evitar o risco, mitigar o risco (reduzindo a probabilidade ou limitando os

impactos), transferir ou aceitar o risco.

Por outro lado, PRAM, PMBOK e Risk IT são modelos que entendem que o

risco pode ter um resultado positivo para organização. Consequentemente, a etapa de

tratamento de risco inclui estratégias para também lidar com oportunidades, como:

exploração, aumento da probabilidade, melhoria de consequências e partilha de riscos.

Além disso, conforme pontua Raz [2], a PRAM distingue entre dois níveis de

risco em projetos, "eventos de risco" e "risco de projeto", dividindo a etapa de

tratamento de risco em duas para lidar cada um à sua maneira.

O processo da ISO/IEC 27005 inclui, após o Tratamento de Riscos, um segundo

ponto de decisão no processo. Caso o risco residual não seja tolerável, segundo critérios

pré-estabelecidos no processo de gestão de riscos, retorna o processo para a definição de

contexto. Em caso de decisão positiva, chega-se a uma fase inédita, a aceitação.

46

Tabela 3.5. Análise Comparativa – Tratamento de Riscos

A aceitação do risco descrita pela ISO/IEC 27005 é diferente da opção de

resposta ao risco de mesmo nome. No processo descrito pela norma de segurança da

informação, tal atividade consiste da submissão do plano de tratamento de riscos e dos

riscos residuais para aprovação por parte da gerência. O framework do Risk IT também

prevê esta atividade, sob o rótulo de Aceitar o Risco de TI (RG3.4).

3.7 – Monitoramento e Controle de Riscos

Na Tabela 3.6 compara-se a forma como os diferentes padrões abordam a etapa

de monitoramento (ou monitoração) e controle de riscos. Considerando que todos os

processos estudados parecem alinhados, de maneira declarada ou implícita, com o ciclo

PDCA de Deming / Shewhart, faz sentido que todos descrevam uma fase que monitore

e retroalimente o processo, objetivando a melhoria contínua.

Tratamento de Riscos

ISO 31.000 5.5. Tratamento de riscos

5.5.2. Seleção das opções de tratamento de riscos

5.5.3. Preparação e implementação dos planos de tratamento de riscos

1. ISO 27.005 9. Tratamento do risco de segurança da informação

9.2. Modificação do risco

9.3. Retenção do risco

9.4. Ação de evitar o risco

2. IT Risk RE2.3 Identificar opções de resposta ao risco.

RR2.3 Responder à descoberta de exposição a risco oportunidade.

3. PRAM Fase de planejamento de respostas:

• Planejar respostas aos eventos de risco

• Planejar respostas aos riscos do projeto

Fase de implementação de respostas:

Implementar respostas aos eventos de risco;

Implementar respostas aos riscos do projeto;

4. PMBOK 11.5. Planejar as respostas aos riscos

Entradas: Planos de gerenciamento de riscos, registro dos riscos

Saídas: Atualizações do plano de gerenciamento do projeto,

Atualizações dos documentos do projeto

5. CMMI Mitigar Riscos (SG 3)

· Desenvolver Planos de Mitigação de Riscos (SP 3.1)

6. MPS BR GRI6 - Planos para a mitigação de riscos são desenvolvidos

47

Tabela 3.6. Análise Comparativa – Monitoramento e Controle de Riscos

Existem dois aspectos da atividade de controle: controle das ações de mitigação

de risco para determinado projeto/atividade, e controle do processo de gestão de risco

propriamente dito. Esta análise pela tabela é complicada, mas todos os modelos

abordam a questão do monitoramento e controle da efetividade das ações de tratamento

de risco selecionadas na etapa anterior, mas nem todas se preocupam com a gestão e

melhoria do processo de gestão de riscos como um todo.

Monitoramento e Controle de Riscos

ISO 31.000 5.6. Monitoramento e Análise Crítica

1. ISO 27.005 12. Monitoramento e análise crítica de riscos de segurança da

informação

12.1. Monitoramento e análise crítica dos fatores de risco

12.2. Monitoramento, análise crítica e melhoria do processo de gestão

de riscos

2. IT Risk Integrar com a Gestão de Riscos Corporativa (RG2)

RG2.4 Fornecer recursos adequados para a gestão de riscos de TI.

RE2.4 Efetuar uma revisão por pares da análise de risco de TI.

RG2.5 Fornecer garantia de independência para gestão de riscos de TI.

3. PRAM Fase de implementação de respostas:

Monitorar mudanças na exposição aos riscos;

Endereçar efetividade do processo de gestão de riscos.

Fase de gerência do processo:

Rever abordagem de cada fase;

Considerar integração da gestão de riscos com outro projeto ou

processo de negócio.

4. PMBOK 11.6. Controlar os riscos

Entradas: Plano de gerenciamento do projeto; Registro dos riscos;

Dados de desempenho do trabalho; Relatórios de desempenho do

trabalho

Saídas: Informações sobre o desempenho do trabalho; Solicitações de

mudança; Atualizações do Plano de gerenciamento do projeto;

Atualizações dos documentos do projeto; Atualizações dos ativos de

processos organizacionais

5. CMMI Mitigar Riscos (SG 3)

· Implementar os Planos de Mitigação de Riscos (SP 3.2)

6. MPS BR GRI8 - Os riscos são avaliados e monitorados para determinar

mudanças em sua situação e no progresso das atividades para seu

tratamento

GRI9 - Ações apropriadas são executadas para corrigir ou evitar o

impacto do risco, baseadas na sua prioridade, probabilidade,

consequência ou outros parâmetros definidos

48

3.8 – Comunicação de Riscos

Na Tabela 3.6 compara-se a forma como os diferentes padrões abordam a etapa

de monitoramento (ou monitoração) e controle de riscos. Considerando que todos os

processos estudados parecem alinhados, de maneira declarada ou implícita, com o ciclo

PDCA de Deming / Shewhart, faz sentido que todos descrevam uma fase que monitore

e retroalimente o processo, objetivando a melhoria contínua.

Tabela 3.7. Análise Comparativa – Comunicação de Riscos

Comunicação de Riscos

ISO 31.000 5.2. Comunicação e consulta

1. ISO 27.005 11. Comunicação e consulta do risco de segurança da informação

2. IT Risk RG1.5 Promover a cultura consciente de risco de TI.

RG1.6 Incentivar uma comunicação eficaz do risco de TI.

RE3.6 Desenvolver indicadores de risco de TI.

3. PRAM Fase de implementação de respostas:

Prover informações de riscos para stakeholders

4. PMBOK Vide “Gerenciamento das comunicações”

5. CMMI GP 2.7 Identificar e Envolver os Stakeholders relevantes

6. MPS BR GQA3. Os problemas e as não-conformidades são identificados,

registrados e comunicados;

MED 7. Os dados e os resultados das análises são comunicados aos

interessados e são utilizados para apoiar decisões.

Somente três dos modelos estudados (ISO 2705, PRAM e Risk IT), além do

próprio modelo de referência (ISO 31000), possuem de forma explicita a necessidade de

manter a comunicação durante todo o processo de gestão de riscos.

O PMBOK trata a questão da comunicação em uma outra área de conhecimento,

chamada “Gerenciamento das comunicações”. Desta forma, para que a comunicação

funcione durante toda gestão de riscos, será necessário que o processo de planejar,

gerenciar e controlar as comunicações tenha consciência desta demanda.

Os modelos de maturidade (CMMI e MPS.BR) também dependem de resultados

/ objetivos alinhados a outros processos. No entanto, esta dependência parece menos

crítica do que o caso do PMBOK. Sendo processos de nível de maturidade anteriores a

Gestão de Riscos, pode-se supor que a comunicação não será um problema.

49

Capítulo 4

Conclusões

Excetuando-se pelo referencial comparativo (ISO 31000), todos as normas, boas

práticas e modelos de gestão de riscos estudados neste trabalho optaram de alguma

forma por delimitar seu próprio escopo de aplicação. Seja direcionando esforços na

gestão de risco de projetos (PRAM e PMBOK), na gestão de riscos de TI (Risk IT) ou

em tópicos ainda mais específicos (ISO 27005, CMMI e MPS.BR). No entanto, não

foram observadas diferenças significativas entre eles em termos de estrutura do

processo de gestão de riscos ou de suas diferentes fases. Parece que as melhores práticas

desta área, já incorporadas por estas normas, são aplicáveis tanto a projetos, quanto a

outros tipos de atividades realizadas nas organizações.

Conforme pode ser observado a partir das tabelas de comparação, os processos

de gestão de risco apresentados têm muito em comum, sugerindo que existe um

consenso universal sobre o que este deve cobrir. As diferenças aparentes no processo

são, em grande parte, atribuíveis a variações na terminologia escolhida. As atividades de

análise risco e avaliar (evaluate) risco são perfeitamente dissociáveis, justificando a

abordagem das normas mais recentes. Por outro lado, não parece razoável combinar

estas duas, junto da atividade identificar risco, como subatividades do grupo avaliar

(assess) riscos. Esta opção torna-se ainda mais infeliz por ocasião da tradução da norma

ISO 31000 para o português, considerando que ambos os termos, evaluation e

assessment, acabaram traduzidos da mesma forma.

Percebe-se ainda uma fonte de variabilidade entre os padrões vai além do

próprio processo de gestão de risco e torna-se evidente quando analisado o escopo de

atuação de cada um dos modelos. Certas normas cobrem somente o próprio processo de

gestão de riscos e ignoram os aspectos envolvidos no estabelecimento da infraestrutura

organizacional necessária para que processo possa ser executado. Fora os modelos de

maturidade (CMMI e MPS.BR), somente o Risk IT demonstra enxergar o processo

como um ativo organizacional, preocupando-se em medir a eficácia do mesmo, gerando

lições aprendidas e buscando a melhoria contínua.

50

Outro ponto que merece ser destacado são as diferentes abordagens que nascem

da própria concepção de risco adotada em cada modelo. Alguns padrões afirmam

explicitamente que o risco inclui tanto a ameaça (risco com potencial impacto negativo)

como a oportunidade (risco potencialmente positivo), enquanto outros se concentram

exclusivamente em ameaças. Os modelos que consideram a existência do risco positivo

acabam, naturalmente, permitindo novos tipos de resposta ao risco que rompem com a

visão tradicional de que a gestão de risco é mero instrumento de prevenção de perdas e

direcionam esforços para captura de ganhos potenciais.

Com base em observações feitas até momento, conclui-se que, embora haja um

amplo consenso sobre os principais passos e atividades de um processo genérico de

gestão de riscos, existem algumas questões conceituais que precisam ser levadas em

consideração no momento de adotar um modelo de gestão de riscos. As discussões

realizadas no presente trabalho ajudam a conhecer as semelhanças e diferenças dos

modelos selecionados. A gestão de riscos está em constante evolução, exigindo que este

tema seja revisitado diante da eventual atualização ou surgimento de novas normas,

padrões, boas práticas e modelos de maturidade.

51

Bibliografia

[1] RISK AND INSURANCE MANAGEMENT SOCIETY, INC. (RIMS), An

Overview of Widely Used Risk Management Standards and Guidelines, RIMS

Executive Report, 2011.

[2] RAZ, T., HILLSON, D., A Comparative Review of Risk Management Standards,

Risk Management, Vol. 7, No. 4 (2005), pp. 53-66, Palgrave Macmillan Journals,

2005, http://www.jstor.org/stable/3867797 (Acesso em 10 Dezembro 2016).

[3] PETRAVICIUS, T., TAMOSIUNIENE, R., Using Project Risk Management

Process in Investment Appraisal, II International Science Conference for Young

Researchers “Technical Science and Industrial Management”, pp. 39-42, 2008.

[4] FABRA, M. G. M. C., Gerenciamento de Riscos em Projetos de Implantação de

Sistemas ERP. 2006. 90 f. Dissertação (Mestrado em Engenharia Industrial) –

Pontifícia Universidade Católica do Rio de Janeiro, Rio de Janeiro, 2006.

[5] BERNSTEIN, P. L. Desafio aos Deuses: a fascinante história do risco. 2ª edição.

Rio de Janeiro – Campus, 1997.

[6] GAMBA, M. A., SANTOS, E. R., Risco: repensando conceitos e paradigmas, Acta

paul. enferm. v.19 n.4, Editorial, São Paulo Oct./Dec. 2006.

[7] LIEBER R.R. & LIEBER N.S.R., O conceito de risco: Janus reinventado, in Saúde

e Ambiente Sustentável: estreitando nós, Minayo, M.C.S. (org), Editora Fiocruz,

Rio de Janeiro, 2002.

[8] NASCIMENTO, J. A. S., Vulnerabilidade a eventos climáticos extremos na

Amazônia Ocidental: uma visão integrada na bacia do rio Acre: UFRJ/COPPE,

2011. Tese (doutorado) – UFRJ/ COPPE/ Programa de Planejamento Energético,

2010.

[9] GTZ - Desenvolvimento Sustentável incorporando a Gestão de Risco Conceitos e

práticas a partir da experiência da GT - Programa Desarrollo Rural Sostenible –

PDRS, 2008.

[10] OLIVEIRA, Viviane Luciana de. Uma análise comparativa das metodologias de

gerenciamento de risco FIRM, NIST SP 800-30 e OCTAVE. 2006. 180f.

Dissertação (Mestrado em Computação) – Universidade Estadual de Campinas,

Campinas.

[11] DAGNINO, R.S. e CARPI Jr. S. (2007), Risco Ambiental: Conceitos e Aplicações.

Climatologia e Estudos da Paisagem Rio Claro - Vol.2 - n.2 - julho/dezembro/2007

[12] SANTOS, J. A. S., CARVALHO, H. G., Referencial Brasileiro de Competências

em Gerenciamento de Projetos. ABGP / IPMA. 2005.

52

[13] PMI, PROJECT MANAGEMENT INSTITUTE, A Guide to the Project

Management Body of Knowledge, Newtown Square, PA, 2008.

[14] ABNT, ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC

31000: Gestão de riscos – Princípios e diretrizes. Rio de Janeiro, 2009.

[15] MAYER, J., FAGUNDES, L. L., Proposta de um Modelo para Avaliar o Nível de

Maturidade do Processo de Gestão de Riscos em Segurança da Informação. Anais

do VIII Simpósio Brasileiro em Segurança da Informação e de Sistemas

Computacionais, pp. 347-356. Gramado, 2008.

[16] SANTOS, R. O bê-a-bá da gestão de risco e governança. Observatório de

Tecnologias de Gestão OTG, Brasília, 2008.

[17] APM. APM Body of Knowledge, 5th Edition. High Wycombe: The Association for

Project Management. 2006.

[18] ISACA, CISA Review Manual 2006. Information Systems Audit and Control

Association. p. 85. 2006.

[19] NETO, E. F. N., REIS, L. C. D., Risk IT based on Cobit: uma visão sistêmica para

auditoria de TI, http://www.cnasi.com.br/, 2012, (Acesso em 12 Dezembro 2017).

[20] QSP – Centro da Qualidade, Segurança e Produtividade para o Brasil e América

Latina, Gestão de Riscos – A norma AS/NZS 4360:2004, Risk Tecnologia Editora,

São Paulo. 2004.

[21] VELOSO, M. A., ISSO 31000 x ISO 27005: Comparação entre as normas para

gestão de riscos. Artigo (MBA em Gestão de Segurança da Informação) –

Universidade FUMEC, Belo Horizonte, 2012.

[22] SILVA, P. J. S., Análise/avaliação de riscos de segurança da informação para a

Administração Pública Federal: um enfoque de alto nível baseado na ISO:IEC

27005. Trabalho de Conclusão (Especialização em Ciências da Computação) –

UNB, Brasília, 2009.

[23] SEMOLA, M., Gestão da Segurança da Informação. 10ª reimpressão. Rio de

Janeiro: Elsevier, 2003.

[24] ABNT, ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC

27005: Tecnologia da informação – Técnicas de segurança – Gestão de riscos de

segurança da informação. Rio de Janeiro, 2011.

[25] ISACA, Risk IT Overview, www.isaca.org/Knowledge Center/Standards, 2009,

(Acesso em 12 Dezembro 2017).

[26] COOPER, D. F., GREY, S., RAYMOND, G., WALKER, P., Project Risk

Management Guidelines: Managing Risk in Large Projects and Complex

Procurements. John Wiley & Sons, 2005, pp. 384.

53

[27] CHAPMAN, C. B., Large engineering project risk analysis. IEEE Transactions on

Engineering Management, EM-26, 78–86, 1979.

[28] BARTLETT, J. E., KOTRLIK, J. W., HIGGINS, C. C., Organizational Research:

Determining Appropriated Sample Size in Survey Research. Information

Technology, Learning, and Performance Journal, Vol. 19, No. 1, pp. 43-50, 2001.

[29] CHAPMAN, C. B., WARD, S., Project risk management: processes, techniques

and insights. John Wiley, 2003.

[30] THAHEEM, M. J., Project Risk Management for Sustainable Restoration of

Immovable Cultural Heritage: Lessons from Construction Industry and

Formulation of a Customized PRM Model. Tese (Doutorado em Filosofia) –

Politecnico de Torino, 2014.

[31] RAMLAOUI, S. SEMMA, A., Comparative study of COBIT with other IT

Governance Frameworks. IJCSI International Journal of Computer Science Issues,

v.11, i.6, n.1, Novembro 2014.

[32] KOHOUT, K., IT Risk Register. Dissertação (Mestrado em Informática) – Vysoká

skola ekonomická v Praze, Praga, 2013.

[33] SEI, SOFTWARE ENGINEERING INSTITUTE. The capability maturity model:

guides for improving the software process. Reading: Addison Wesley, 1997.

[34] CMMI Product Team. CMMI for Systems Engineering/Software Engineering,

Version 1.1 Staged Representation (CMU/SEI-2002-TR-029, ESC-TR-2002-029).

Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University. 2002.

[35] ROCHA, P. C., BELCHIOR, A. D., Mapeamento do Gerenciamento de Riscos no

PMBOK, CMMI-SW e RUP. Anais do VI Simpósio Internacional de Melhoria de

Processos de Software, pp. 279-290. São Paulo, 2004.

[36] WILLIAMS, R. C., The CMMI RSKM Process Area as a Risk Management

Standard. Sixteenth Annual International Symposium of the International Council

On Systems Engineering (INCOSE). Julho de 2006.

[37] ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE

BRASILEIRO – SOFTEX. Guia de Implementação – Parte 5: Fundamentação

para Implementação do Nível C do MR-MPS-SW:2016. Disponível em:

www.softex.br. 2016.

[38] DEL CAÑO, A., DE LA CRUZ, M. P., The project risk management process:

different approaches. Anais do IV AEIPRO International Congress on Project

Engineering, Lérida, España, organizado por la Universidad de Lérida y la

Asociación Española de Ingeniería de Proyectos (AEIPRO). 2000.