GESTÃO E ANÁLISE DE RISCOS Livro-Texto - Unidade IV

Prévia do material em texto

141
GESTÃO E ANÁLISE DE RISCOS
Unidade IV
7 PROJETO DE IMPLANTAÇÃO DA GESTÃO DE RISCOS
No decorrer dessa jornada, ficou demonstrada a importância da organização e do planejamento 
para atingir a gestão de riscos eficaz. Foram apresentados muitos conceitos e exemplos sobre gestão, 
governança, análise e tratamento dos riscos. Dessa maneira, para encerrar, será necessário colocar isso 
para funcionar, demonstrando como implantar uma área de gestão de riscos desde o seu início. Para 
cumprir com esse objetivo, necessariamente, devemos assumir que a implantação de uma gestão de 
riscos de segurança da informação é um projeto e, assim, requer escolher uma metodologia de gestão 
de projetos para nortear as ações a fim de atingir o resultado final: a implantação de uma área de 
gestão de riscos à segurança da informação que atue de forma sistemática e consistente na corporação.
7.1 Definindo o projeto de implantação
A escolha da metodologia que vai gerir o projeto não é uma decisão fácil. Para fins acadêmicos, será 
utilizada uma metodologia tradicional de gestão de projetos amplamente difundida pelo PMI (Project 
Management Institute), que expõe, em detalhes, cada passo rumo à implantação da gestão de riscos. 
Para fins de projeto, vamos abordar as principais definições das fases do projeto ajustando-as ao escopo 
aqui apresentado.
Inicialmente, por que a implantação da metodologia de gestão de riscos deve ser tratada como 
um projeto na organização? Os projetos, segundo o PMBOK (PMI, 2013), são um esforço temporário 
empreendido para criar um produto, serviço ou resultado exclusivo.
Os projetos são marcados por algumas características básicas comuns a todos os processos. Isso 
implica em afirmar que possuem prazo limitado, uma data estipulada para conclusão e um resultado 
diferente daquele produzido no curso da rotina operacional. Um projeto tem pontos claros de início e 
fim, uma série de atividades, entre elas, um conjunto definido de objetivos.
O gerenciamento de projeto permite focar prioridades, monitorar desempenhos, superar dificuldades 
e adaptar-se a mudanças. Permite mais controle e fornece técnicas que o ajudam a liderar equipes para 
atingir metas no prazo e dentro do orçamento. Organizar as tarefas de um projeto pode demandar 
tempo no início, mas, no longo prazo, economiza tempo e esforço e reduz o risco de erros.
O quadro a seguir demonstra, de forma resumida, as características básicas de projetos e como elas 
se relacionam com o projeto de implantação de gestão de riscos no cenário corporativo.
142
Unidade IV
Quadro 33 – Características básicas de projetos e 
a implantação da análise de risco
Características Pontos relevantes Relação com o projeto de implantação da análise de risco
Início e fim definidos: 
todo projeto tem fases 
claras de começo e de 
encerramento
Alguns projetos são repetidos várias vezes, mas 
não são processos, pois têm pontos claros de 
início e fim
O trabalho de rotina distingue-se dos projetos 
por ser recorrente e não ter um fim claro de 
processo
Esse tipo de projeto terá começo 
meio e fim e após seu término, 
sua entrega representará ou uma 
nova área para empresa ou novos 
processos
Plano organizado: 
abordagem planejada, 
metódica, é usada para que 
se atinjam os objetivos do 
projeto
O bom planejamento assegura que o projeto 
fique pronto no prazo e dentro do orçamento, 
com os resultados esperados
Um plano eficiente oferece um modelo que 
guia o projeto e detalha o trabalho que precisa 
ser feito
É necessário elaborar 
planejamento faseado do 
processo de implantação da 
análise de riscos corporativa
Recursos próprios: 
o projeto conta com 
recursos especialmente 
alocados a ele, como tempo, 
pessoal e verba
Alguns projetos são feitos fora da rotina 
normal e outros dentro dela, mas todos exigem 
recursos próprios
Trabalhar com recursos com os quais se 
concorda é vital para o sucesso
Preferencialmente o projeto 
de implantação de uma gestão 
de risco deve ser gerenciado 
por recursos especificamente 
alocados para essa atividade
Equipe: 
usualmente o projeto exige 
uma equipe capaz de levar 
a termo o trabalho proposto
A equipe de projeto assume a responsabilidade 
e gosta de seu trabalho; ao mesmo tempo, 
contribui para o sucesso da empresa como 
um todo
Projetos oferecem novos desafios e experiências 
para a equipe
Nesse caso, podem ser 
contratados recursos de 
consultorias especializadas, mas 
a gerência do projeto fica a cargo 
de um funcionário de segurança 
da informação
Metas estabelecidas: 
os projetos trazem 
resultados em termos 
de qualidade e/ou de 
desempenho 
Muitas vezes, um projeto resulta em novo modo 
de trabalhar ou gera algo que anteriormente 
não existia
Os objetivos devem ser identificados para todas 
as pessoas envolvidas no projeto
Nesse caso, é exatamente o que 
se procura estabelecer: uma nova 
metodologia de trabalho
 Observação
Existem muitos modelos de gerenciamento de projeto. O modelo do 
PMBOK proposto pelo PMI não é a única forma de gerenciar projetos, 
podendo ser utilizados outros formatos, inclusive mescla de modelos.
Sendo assim, os projetos apresentam algumas características específicas e que atendem às 
expectativas de implantação da gestão de riscos corporativa, como:
• Temporalidade: todos os projetos têm um começo, meio e fim definidos. Então é possível encaixar 
a implantação de uma área de gestão de riscos a um projeto, pois os processos para a implantação 
podem ser faseados levando a um término e posterior operação dos processos implantados.
• Singularidade ou unicidade: todo o projeto tem algo que o diferencia de outros projetos, mesmo 
daqueles que são similares, ou seja, os projetos de implantação da gestão de riscos devem ser 
143
GESTÃO E ANÁLISE DE RISCOS
dimensionados conforme a estrutura organizacional. Mesmo que exista um processo padronizado, 
nunca será inteiramente semelhante.
• Incerteza: projetos são marcados por risco. Nesse caso, risco de o próprio projeto não dar certo 
ou de algo dar errado durante sua execução.
• Complexidade: os projetos possuem níveis de complexidade que vão depender do número de 
setores envolvidos e do conhecimento dessas áreas, conclui-se que a implantação da gestão 
de riscos é complexa.
Sabbag (1999) chamou a relação entre complexidade, singularidade e precisão de objetivos de 
cubo da incerteza. No modelo por ele proposto, o nível de incerteza do projeto é determinado pela 
complexidade, singularidade e precisão do objetivo do projeto. O cubo da incerteza pode ser útil para 
definir o tipo de estratégia de gerenciamento do projeto que será adotado.
Complexidade
Singularidade
Precisão dos 
objetivos
Figura 48 – Cubo da incerteza de Sabbag
Projetos podem envolver ampla gama de pessoas com diferentes habilidades e experiências. Mas 
existem muitos papéis básicos comuns a todos os projetos. É importante conhecer as funções que esses 
profissionais devem desempenhar.
Segundo Carvalho e Rabechini Júnior (2005), existem alguns atores que vão atuar em projetos e que 
devem ser identificados. Suas funções são primordiais para o bom andamento e, por isso, devem estar 
devidamente instruídos e capacitados para elas.
O gerente de um projeto está incumbido de desenvolvê-lo integralmente. Mas não terá êxito sem 
ajuda. Assim, é vital criar boas relações com outros agentes principais. Entre eles, estão o patrocinador, 
que, geralmente, é o superior, é quem dá apoio (financeiro ou moral); os membros-chave da equipe, 
responsáveis pelo sucesso global do projeto; os membros de tempo parcial, que, apesar disso, contribuem 
para o plano; os especialistas ou consultores.
Existem ainda os interessados, ou seja, pessoas afetadas pelo resultado do projeto, como clientes, 
fornecedores ou executivos de outras áreas da empresa.
144
Unidade IV
No quadro a seguir, está demonstrada a relação dos principais atores, suas atribuições e a relação 
com o projeto de implantação da gestão de riscos.
Quadro 34 – Principais atores envolvidosnos projetos
Atores Funções Atuação no projeto de implantação da análise de risco
Patrocinador: 
inicia um projeto, reforça a 
autoridade na equipe e, nela, 
é o membro mais graduado
Garante que o projeto é realmente relevante para 
a empresa. Ajuda a estabelecer objetivos e limites. 
Age como figura de destaque, referencial. Pode 
fornecer recursos
Esse ator no projeto em questão 
pode ser representado pelo 
executivo da segurança da 
informação
Gerente do projeto: 
responsável pela obtenção 
dos objetivos do projeto e 
pela liderança da equipe
Produz um plano de ação detalhado. Motiva 
e organiza a equipe de projeto. Comunica 
informações do projeto a apoiadores e a outros 
interessados. Monitora a evolução do trabalho
Esse ator no projeto em 
questão pode ser representado 
pelo gerente da segurança da 
informação
Interessado: 
qualquer outra pessoa 
beneficiária do resultado 
do projeto ou que possa ser 
afetada por ele
Contribui para várias etapas do planejamento, 
fornecendo feedback. Pode ser envolvido apenas 
eventualmente. Pode não ser interessado em todo 
o projeto, mas apenas em partes específicas dele
Esse ator no projeto em questão 
pode ser representado por toda a 
organização e reguladores
Membro-chave: 
dá assistência ao gerente 
e fornece a quantidade de 
conhecimento necessária
Dá valiosa contribuição: estuda a viabilidade do 
projeto e ajuda em seu planejamento. Oferece 
expertise técnica quando preciso. É responsável 
pelo encerramento do projeto no prazo e dentro 
do orçamento
Esse ator no projeto em questão 
pode ser representado por 
analista de projetos sênior, 
consultor sênior ou analista de 
segurança da informação sênior
Membro: 
pessoa que, em tempo 
integral ou não, executa 
tarefas para o andamento 
do projeto
Executa atividades segundo foram descritas 
no plano do projeto. Desempenha papel 
especializado se envolvido como consultor ou 
como alguém só necessário em parte do projeto 
Esse ator no projeto em questão 
pode ser representado por 
analistas de segurança da 
informação plenos e júniores
Cliente: 
interno ou externo à 
empresa, beneficia-se das 
mudanças que serão trazidas 
pelo projeto
Influencia fortemente os objetivos do projeto 
e o modo de medir seu sucesso. Impõe como 
e quando algumas atividades devem ser 
conduzidas. Serve como guia ao gerente de 
projeto
Esse ator no projeto em questão 
pode ser representado pelas 
demais áreas de controle da 
organização
Fornecedor: 
fornece materiais, produtos 
ou serviços necessários para 
o andamento do projeto
Pode envolver-se bastante no projeto e dar-lhe 
forte apoio. Entrega os suprimentos no prazo e 
fornece serviços ou bens a preço fixo, combinado 
no início com o gerente de projeto
Esse ator no projeto em questão 
pode ser representado por uma 
consultoria especializada
Segundo Carvalho e Rabechini Júnior (2005), algumas atitudes devem ser assumidas quando os 
projetos são instituidos na organização, na realidade, dicas que, se seguidas, podem levar ao sucesso.
As atitudes são procurar envolver os interessados logo no início dos trabalhos, nem todos serão 
igualmente importantes, por isso, identificar aqueles que podem ter efeito significativo no projeto; ao 
desenvolver o plano, pensar na regularidade com que deve consultá-los; solicitar aos mais entusiasmados 
com a ideia que ajudem a motivar outros; procurar estabelecer fortes alianças com os que controlam os 
recursos; e, finalmente, verificar se cada um dos interessados entende a razão de seu envolvimento no 
projeto e o impacto que este exercerá sobre eles. Tudo isso é relevante, uma vez que, segundo o PMBOK 
(PMI, 2013), gerenciar projetos implica em administrar em especial as restrições de escopo, prazo e 
custo, cujo balancemento afeta a qualidade do projeto.
145
GESTÃO E ANÁLISE DE RISCOS
Alguns dos principais fatores que implicam na necessidade de gerenciar projetos nas organzações 
remetem à busca de maior competitividade, adoção de novas tecnologias (automação de processos, 
sistemas de informações, entre outros dependendo da importância ou tamanho do empreendimento); 
todavia, no caso específico desse estudo, há necessidade de implantar um modelo que estabeleça 
uma efetiva análise de riscos à segurança da informação a fim de identificar, categorizar e tratar os 
riscos corporativos.
Apesar de ser algo crucial e praticamente obrigatório de ser implantado por ser uma exigência 
regulatória, legal e de mercado, o projeto de implantação de análise de riscos à segurança da 
informação está relacionado ao modelo de gestão corporativo, que exige que sejam realizadas análises 
de riscos de uma maneira geral. Isso inclui a segurança da informação, que está dentro da categoria de 
risco operacional.
Mesmo com todas essas justificativas para a continuidade do projeto, todos devem se preocupar 
com sua viabilidade. Antes de iniciar um projeto, deve ser assegurado que ele tem boas possibilidades 
de sucesso, que será realizado no momento apropriado e que é viável e vale a pena, para só então 
desencadear o processo.
No caso do projeto de análise de riscos à segurança da informação, a exigência é a urgência de ter 
uma governança efetiva dos riscos de segurança da informação. Mesmo esse projeto necessita entrar 
no momento apropriado, ou seja, por mais obrigatório que ele possa parecer, deve sempre haver o 
momento certo de iniciá-lo. Devem ser considerados outros projetos que já começaram.
Algumas organizações colocam tantos projetos em andamento ao mesmo tempo que é impossível 
o sucesso de todos. Às vezes, é preciso admitir a hipótese de adiar o projeto ou abreviá-lo conforme a 
necessidade e disposição dos recursos. Como todos exigem recursos limitados ou mesmo escassos, é vital 
que se tenha uma razão clara para sua existência e do momento oportuno para realizá-lo. É evidente que, 
para projetos com esse nível de exigência e complexidade, é mais importante identificar as chamadas 
forças impulsoras e resistentes.
As forças impulsoras remetem ao fato de que todos os projetos resultam de uma ou mais 
necessidades corporativas. Quanto mais fortes são essas forças impulsoras, mais provável o êxito do 
projeto. Se, por exemplo, ele envolve atender uma exigência legal, a força impulsora é poderosa. Para 
criar uma relação de forças impulsoras, ou de razões pelas quais o projeto deve ir em frente, é necessário 
verificar quais as questões empresariais que trazem impacto e, então, comparar com os outros projetos. 
Por exemplo, se há uma força impulsora por trás de dois projetos para atender à legislação, aquele que, 
digamos, propõe ter o menor prazo para atendimento terá maior probabilidade de êxito.
Igualmente importante são as forças resistentes, ou se pode afirmar que sempre existem razões 
pelas quais os projetos podem não dar certo. Essas forças podem ser geradas por inúmeros motivos, 
entre eles estão:
146
Unidade IV
• Resistência das pessoas à mudança: no caso do projeto abordado, isso pode ser um problema. 
Ninguém gosta de ter mais controles de segurança da informação que possam impedir sua atuação. 
Isso remete em deixar separado no projeto uma atividade exclusiva destinada à conscientização e 
ao aculturamento dos riscos corporativos destinados aos funcionários.
• Peso da carga de trabalho: com certeza, os controles de segurança vão necessariamente 
aumentar, e o volume de trabalho pode causar insatisfação, por isso o aculturamento 
é importante.
• Falta de informação ou recursos: pode acarretar descontentamento na própria equipe do 
projeto e nos envolvidos. No caso do projeto de implantação da gestão de risco à segurança da 
informação, toda a organização requer uma atenção especial em relação à comunicação.
• Escassez de pessoas com aptidão necessária: uma saída para essa situação seria a contratação de 
uma consultoria especializada, que vai auxiliar com pessoal capacitado e dedicado exclusivamente. 
Isso é muito comum em projetos dessa complexidade.
É importante identificar logo nos estágiosiniciais as forças resistentes e agir para superá-las. 
Uma poderosa força resistente emerge em organizações que iniciam projetos para mudar o modo de 
trabalho das pessoas, mas não as motivam. Se os funcionários enxergam no projeto apenas mais uma 
iniciativa da administração, será difícil envolvê-los para que deem resultados.
Dinsmore e Cavalieri (2005) enumeram algumas características que uma gestão de projetos eficaz 
pode trazer, apresentando um referencial com foco no projeto de implantação da gestão de segurança 
da informação:
• Simplicidade de propósito: o projeto possui metas e objetivos facilmente entendidos. Para o 
projeto em questão, se faz necessário estruturar metas e objetivos de fácil entendimento. Como 
sugestão, pode-se dividi-lo em fases bem definidas, como mapeamento dos riscos, categorização 
dos riscos, matriz corporativa de riscos e metodologia de tratamento de riscos; para, assim, 
deixar o objetivo bem delimitado – a implantação de um modelo de gestão de risco à segurança 
da informação.
• Clareza de propósito e escopo: o projeto pode ser descrito claramente em poucos termos, 
como os objetivos, o escopo, as limitações, os recursos, a administração, a qualidade de 
resultados e assim por diante. Quando consideramos o projeto em questão, deve ser definido 
o escopo conforme a implantação da metodologia de gestão de risco.
• Controle independente: o projeto pode ser protegido do mercado ou de outras flutuações que 
afetam operações rotineiras.
• Facilidade de medição: o andamento do projeto pode ser medido por meio de sua comparação 
com metas e padrões definidos de desempenho. Esse ponto é de fácil entendimento no projeto 
por meio de indicadores de tratamento dos riscos e sua efetividade.
147
GESTÃO E ANÁLISE DE RISCOS
• Flexibilidade de emprego: a administração do projeto pode empregar ou cooptar especialistas 
e peritos de alto padrão por períodos limitados, sem prejudicar os arranjos de longo prazo na 
lotação de cargos. Nesse ponto, o gerente do projeto pode entender ser necessária a ação de 
especialistas de riscos em períodos específicos e limitados do projeto.
• Condução da motivação e moral da equipe: a novidade e o interesse específicos do trabalho 
do projeto são atraentes às pessoas e leva à formação de equipes entusiásticas e automotivadas.
• Sensibilidade ao estilo de administração e liderança: embora, às vezes, capazes de autogestão, 
as equipes de especialistas automotivados reagem criticamente a certos estilos de liderança.
• Útil ao desenvolvimento individual: trabalhar com uma equipe de projeto eficiente favorece o 
desenvolvimento acelerado e a capacitação pessoal.
• Favorecimento da discrição e da segurança: os projetos podem ser protegidos de ação hostil 
ou atividade de informação para defesa, pesquisa, desenvolvimento de produto ou segurança de 
produtos sensíveis ao mercado ou de alto valor.
• Mobilidade: como entidades independentes, os projetos podem ser executados em locais remotos, 
países estrangeiros e assim por diante.
Carvalho e Rabechini Júnior (2005) relacionam as principais causas dos fracassos em projetos de 
uma maneira geral, conforme a figura a seguir.
Objetivos mal 
definidos
Falta de liderança do 
gerente de projeto Controle inadequado
Falta de integração 
entre as áreas-chave 
do projeto
Pouca compreensão 
da incerteza e 
complexidade do 
projeto
Falta de liderança do 
gerente de projeto
Treinamento 
inadequado
Dados insuficientes 
ou inadequados
Cenário 
político-econômico 
desfavorável
Tentativa de "vender" 
o projeto a qualquer 
custo
Figura 49 – Principais causas de fracasso em projetos
148
Unidade IV
 Saiba mais
Para compreender melhor as principais causas de fracassos em projetos, 
assista ao filme:
HORIZONTE profundo. Dir. Peter Berg. EUA: Summit Entertainment, 
2016. 107 minutos.
O gerenciamento do projeto traz algumas vantagens que devem ser vistas como resultado da tarefa 
árdua da organização e do planejamento estruturado que, segundo Carvalho e Rabechini Júnior (2005), 
acaba colhendo seus frutos. Os principais benefícios do gerenciamento eficaz de projetos são:
• evitar surpresas durante a execução dos trabalhos (prever ações preventivas e corretivas);
• desenvolver diferenciais competitivos (lançar novos produtos mais rapidamente e com menor 
investimento);
• agilizar o retorno sobre o investimento em projetos;
• agilizar a tomada de decisões sobre o planejamento e controle do projeto;
• otimizar a utilização dos recursos envolvidos;
• gerar conhecimento para projetos futuros.
Dinsmore e Cavalieri (2005) demonstram que assim como o fracasso pode ser previsto em projetos, 
o sucesso também pode e relaciona os fatores que devem ser perseguidos para atingir os objetivos 
propostos no início dos trabalhos em projetos. Dinsmore e Cavalieri (2005) demonstram uma técnica 
útil, conhecida como análise do campo de forças, que pode ajudar a verificar se as forças impulsoras 
sobrepujam as resistentes e, portanto, se o projeto tem boas chances de êxito. Com essa análise, é 
possível identificar se a balança pende para o sucesso ou para o fracasso. Para avaliar o impacto relativo 
de cada força, o quadro seguinte descreve uma escala de análise.
Quadro 35 – Escala de análise dos fatores de sucesso em projetos
Escala de sucesso × fracasso em projetos
As forças impulsoras variam de 1 (força 
fraca) a 5 (necessidade essencial)
0-1: indica uma força resistente que não chega 
a ameaçar o êxito do projeto
5: define uma força poderosa que pode impedir 
que os resultados desejados sejam alcançados, 
salvo se o impacto for minimizado
149
GESTÃO E ANÁLISE DE RISCOS
Muitos são os fatores para atingir o sucesso em projetos, assim, é preciso priorizar aqueles que 
têm maior relevância, ou seja, ao gerenciar vários projetos, é necessário avaliar qual deles é o mais 
importante para a organização a fim de alocar o tempo e os recursos necessários. No caso específico 
do projeto de implantação da gestão de riscos à segurança da informação, a priorização se daria pela 
exigência legal e regulamentar.
Também é possível identificar os valores relativos antes de iniciar um projeto, para isso é 
recomendado definir os recursos humanos e materiais que ele exigirá. O objetivo é fornecer os 
recursos da empresa aos projetos que ofereçam o maior valor em seus resultados. Torna-se necessário 
convencer os superiores sobre o valor relativo do projeto. Talvez seja preciso manter reuniões com 
cliente ou com outros membros da equipe de projeto. Devido a sua complexidade e abrangência, 
o projeto de implantação de uma análise de riscos de segurança da informação deverá procurar a 
opinião de outras áreas antes de estabelecer as prioridades.
Saber no início quanto tempo o projeto tem para finalização é importante, sendo assim, é preciso 
desenvolver um cronograma geral para ajudar a decidir, logo no começo, o melhor modo de desenvolver 
uma série de projetos. Nesse estágio, não é preciso detalhar os recursos, trata-se de uma estimativa 
sobre os recursos necessários. Isso permitirá identificar problemas potenciais entre projetos e confirmar 
ou negar a viabilidade de um novo. Por exemplo, se dois deles exigem um analista desenvolvedor ao 
mesmo tempo e a organização só tem um, reprogramar um dos projetos para que o analista fique 
disponível para ambos.
Foram dispostas algumas métricas e fatores que podem levar um projeto a ser um sucesso, mas é 
possível simplificar a lista de fatores que ao serem analisados podem determinar se o projeto foi um 
sucesso. A figura seguinte contrapõe-se à figura anterior e expõe os fatores considerados de sucesso 
em projetos.
Ser concluído dentro 
do prazo previsto
Ter sido aceito sem 
restrições pelo cliente 
do projeto
Ter sido concluído 
com o mínimo de 
alterações em seu 
escopo
Ser concluído dentro 
do orçamento previsto
Ter sido executado 
sem interrupção 
ou prejuízo nas 
atividades normais da 
organização
Ter utilizado 
eficientemente os 
recursos(materiais, 
equipamentos e 
pessoas)
Ter atingido a 
qualidade e o 
desempenho 
desejados
Figura 50 – Fatores que determinam o sucesso em projetos
150
Unidade IV
 Saiba mais
Para compreender melhor as principais causas de sucesso em projetos, 
assista ao filme:
MONEY ball: o homem que mudou o jogo. Dir. Bennett Miller. EUA: 
Columbia Pictures, 2011. 133 minutos.
Na figura anterior, se pode perceber a presença de três elementos essenciais para o sucesso dos 
projetos: tempo, custo e qualidade.
A relação entre eles não é nada amistosa: se o tempo é acelerado, aumenta-se o custo; se o custo 
não é aumentado, a qualidade vai sentir; se os custos forem reduzidos, o prazo aumenta; e se o prazo 
não for aumentado, a qualidade vai sentir. Essa conta apenas vai fechar, é importante frisar, se os três 
seguirem ao máximo aquilo que foi planejado no início do projeto, se foi aprovado pelo patrocinador 
como uma projeção de custo aceitável, pelos clientes com prazo aceitável e com a qualidade requerida 
por ambos. Dessa forma, cabe ao gerente do projeto buscar impiedosamente manter-se dentro do 
planejado. Quanto mais próximo do que foi inicialmente planejado, maior o sucesso atingido.
Segundo o PMBOK (PMI, 2013), devido ao seu caráter temporário, todo o projeto apresenta um ciclo 
de vida que nada mais é do que as fases em que o projeto está dividido. O PMBOK (PMI, 2013) divide o 
ciclo de vida do gerenciamento do projeto em cinco processos:
• Iniciação: identificação da necessidade e do escopo do projeto.
• Planejamento: detalhamento do projeto.
• Execução: execução das atividades do projeto.
• Monitoramento e controle: controle do que está sendo executado e ações corretivas.
• Encerramento: avaliação de tudo o que foi feito no projeto.
Há grande vantagem em conhecer as fases do ciclo de vida de um projeto: a capacidade de avaliar 
o seu andamento desde o início até o encerramento.
151
GESTÃO E ANÁLISE DE RISCOS
Inicial Intermediária Final
Ideia
Termo de 
abertura
SAÍDAS
do gerenciamento 
do projeto
FASES
ENTRADAS
ENTREGA
do projeto
Plano Linha 
de base Progresso
Aceitação
Aprovação Entrega
Declaração 
do escopo
Equipe de gerenciamento do projeto
Figura 51 – Ciclo de vida de gerenciamento de projetos
A abordagem faseada ajuda a compreender melhor o projeto, auxiliando a gestão, pois possibilita a 
identificação de eventuais atrasos, aumento dos custos ou desvios na qualidade acordada nos estágios 
iniciais do projeto.
Não é pretensão dessa obra capacitar o aluno em gestão de projetos, todavia é necessário enquadrar o 
assunto relacionado à implantação da gestão de riscos à segurança da informação em um procedimento 
estruturado e devidamente organizado, por isso a metodologia de gestão de projetos foi a selecionada 
conforme exposto no início deste tópico. Será demonstrado de forma resumida pelo que cada fase é 
responsável no ciclo apresentado na figura 50 e como abordá-las no projeto-alvo do estudo.
Na fase iniciação do projeto, é possível verificar a entrada de um projeto que pode estar vinculada 
a uma ideia, a algum processo de inovação ou, no caso do projeto em questão, a uma necessidade legal 
e regulatória obrigatória. Ainda dentro da fase inicial, deve ser criado o termo de abertura do projeto 
que, segundo o PMBOK (2013), é o processo de desenvolvimento de um documento que, de maneira 
formal, autoriza a existência de um projeto e dá ao seu gerente a autoridade necessária para aplicar 
recursos organizacionais às atividades do projeto. Na prática, esse documento habilita o gerente do 
projeto a iniciar os trabalhos.
No termo, devem conter as especificações do trabalho do projeto, a explicação de sua necessidade, 
os acordos realizados entre as áreas para a viabilidade do projeto, os fatores ambientais da empresa, os 
ativos de processos organizacionais envolvidos, as ferramentas e técnicas utilizadas e, se for o caso, a 
opinião especializada e as técnicas de facilitação, como fóruns e reuniões de reporte e de alinhamento.
Na figura seguinte, estão relacionados os itens que devem compor o termo de abertura de projeto 
com destaque aos itens em amarelo, que devem obrigatoriamente constar no termo de abertura do 
projeto de implantação da gestão de riscos à segurança da informação.
152
Unidade IV
Necessidade de negócios
Descrição do escopo do produto/serviço
Plano estratégico
Demanda de mercado
Necessidade organizacional
Solicitação do cliente
Avanço tecnológico
Requisito legal
Fatores ambientais da empresa
Ativos de processos organizacionais
Especificação 
do trabalho do 
projeto
Business case
Acordos
Figura 52 – Componentes do termo de abertura do projeto de implantação 
 da gestão de riscos à segurança da informação
 Lembrete
Durante o processo de planejamento do projeto de implantação da 
gestão e análise de risco à segurança da informação, o gestor pode perceber 
a necessidade de uma análise preliminar das condições da organização 
antes da definição do próprio escopo do projeto.
O termo de abertura do projeto deve conter ordinalmente os itens propósito ou justificativa do 
projeto, os objetivos mensuráveis do projeto e os critérios de sucesso relacionados, os requisitos de alto 
nível, a descrição do projeto em alto nível, os riscos de alto nível, um resumo do cronograma de marcos, 
um resumo do orçamento, uma lista das partes interessadas, os requisitos para aprovação do projeto 
(o que constitui o seu sucesso, quem decide se o projeto é bem-sucedido e quem assina o projeto), 
o gerente do projeto, a responsabilidade e o nível de autoridade designados, nome e autoridade do 
patrocinador ou de outra(s) pessoa(s) que autoriza(m) o termo de abertura do projeto.
Logo na sequência, o gerente deverá constituir a equipe que responsável pela condução das 
atividades do projeto. Nesse ponto, é necessário lembrar que devem ser equalizados os investimentos, 
os prazos e a qualidade que se deseja obter. Como exemplo para o projeto em questão, pode-se prever 
de dois a três anos de duração com uma equipe com três a cinco membros que tenham conhecimentos 
avançados em gestão de ricos, segurança da informação e gestão de projetos.
A fase de iniciação termina com a declaração do escopo do projeto, mas para chegar até a 
declaração, existem alguns processos necessários que, segundo o PMBOK (PIM, 2013), passam pela 
definição do próprio escopo do que é o processo de desenvolvimento de uma descrição detalhada do 
projeto e do produto.
153
GESTÃO E ANÁLISE DE RISCOS
O principal benefício desse processo é que ele descreve os limites do projeto, serviços ou resultados 
ao definir quais dos requisitos coletados serão incluídos e quais serão excluídos do escopo do projeto. 
É importante ressaltar que é preciso, assim como definir o que será entregue ao final, demonstrar o 
que não será entregue para não gerar expectativas frustradas ao final do projeto.
Plano de gerenciamento do 
escopo
Termo de abertura do projeto
Documentação dos requisitos
Ativos de processos 
organizacionais
Opinião especializada
Análise de produto
Geração de alternativas
Oficinas facilitadas
Declaração do escopo do projeto
Atualizações nos documentos 
do projeto
Entradas
Ferramentas
Saídas
Figura 53 – Processos que levam à declaração do escopo do projeto
A declaração do escopo do projeto deve conter de forma ordenada os critérios de aceitação, as 
entregas do projeto, as exclusões do projeto, as restrições do projeto e as premissas do projeto.
Na fase de planejamento, deve ser disposto o plano de gerenciamento do projeto que, segundo 
o PMBOK (PMI, 2013), é um documento que descreve como o projeto será executado, monitorado e 
controlado. Ele integra e consolida todos os planos de gerenciamento auxiliares e linhas de base dos 
processos de planejamento. Desenvolver o plano de gerenciamento do projeto é o processo de definir, 
preparar e coordenar todos os planos auxiliares e integrá-los a um plano de gerenciamento de projeto 
abrangente. O principal benefíciodesse processo é estabelecer um documento central que define a base 
de todo trabalho do projeto.
Termo de abertura do projeto
Saídas de outros processos
Fatores ambientais da empresa
Ativos de processos 
organizacionais
Opinião especializada
Técnicas de facilitação Plano de gerenciamento do projeto
Entradas
Ferramentas
Saídas
Figura 54 – Processos que levam ao plano de gerenciamento do projeto
O plano de gerenciamento do projeto pode ser elaborado no nível resumido ou detalhado e pode 
ser composto por um ou mais planos auxiliares. Cada um dos planos auxiliares é detalhado até o ponto 
requisitado pelo projeto específico. Uma vez que o plano de gerenciamento tenha sido estabelecido, ele 
somente pode ser modificado quando uma solicitação de mudança é gerada e aprovada por meio de um 
processo que realiza o controle integrado de mudanças. Embora o plano de gerenciamento de projeto 
154
Unidade IV
seja um dos principais documentos usados para gerenciar o projeto, outros documentos são também 
utilizados. Esses outros documentos não são parte do plano de gerenciamento do projeto.
O plano de gerenciamento do projeto deve conter os seguintes tópicos: o plano de gerenciamento 
de mudanças, o plano de gerenciamento das comunicações, o plano de gerenciamento da configuração, 
a linha de base dos custos, o plano de gerenciamento dos custos, o plano de gerenciamento dos recursos 
humanos, o plano de melhorias no processo, o plano de gerenciamento das aquisições, a linha de base 
do escopo, a declaração do escopo do projeto, a estrutura analítica do projeto (EAP), o dicionário da 
EAP, o plano de gerenciamento da qualidade, o plano de gerenciamento dos requisitos, o plano de 
gerenciamento dos riscos, a linha de base do cronograma, o plano de gerenciamento do cronograma, o 
plano de gerenciamento do escopo e o plano de gerenciamento das partes interessadas.
Após estabelecido o plano de gerenciamento do projeto, é necessário definir a linha de base do projeto 
que servirá de referência nele todo. Sendo assim, existe uma linha-base para todos os componentes do 
projeto, existe a linha para o prazo, para o escopo, para os custos, entre outros. A linha-base estabelece 
o comportamento definido como ideal para o projeto durante todas as suas fases e vai demonstrar se o 
projeto está saindo da forma definida lá no seu início.
O acompanhamento da linha-base leva a análises do progresso do projeto, que nada mais é do que 
definir datas para aferições periódicas (marcos importantes) a fim de determinar o andamento do projeto.
Para cada marco estipulado, é necessária a assinatura de um termo de aceite de entregas parciais do 
projeto até a sua entrega definitiva.
A entrega do projeto significa encerrar o projeto ou a fase. É o processo de finalização de todas as 
atividades de todos os grupos de processos de gerenciamento do projeto a fim de encerrar formalmente 
o projeto ou a fase. O principal benefício desse processo é o fornecimento de lições aprendidas, o 
encerramento formal do trabalho do projeto e a liberação dos recursos organizacionais para utilização 
em novos empreendimentos.
Plano de gerenciamento do 
projeto
Entregas aceitas
Ativos de processos 
organizacionais
Opinião especializada
Técnicas analíticas
Reuniões
Transição do produto, serviço ou 
resultado final
Atualizações nos ativos de 
processos organizacionais
Entradas
Ferramentas
Saídas
Figura 55 – Processos que levam ao encerramento do projeto
Carvalho e Rabechini Júnior (2005) demonstram que os projetos podem ser classificados por sua 
duração, sendo de curto, médio e longo prazo. Para o projeto em questão, implantação da gestão de 
risco à segurança da informação, podemos mencionar, com base na sua complexidade e em experiências 
anteriores, como sendo um projeto de média a longa duração, pois pode levar cerca de dois a três anos 
para a sua conclusão.
155
GESTÃO E ANÁLISE DE RISCOS
Curto prazo
1 mês a 1 ano
Médio prazo
até 2 anos
Longo prazo
mais de 2 anos
Figura 56 – Classificação do ciclo de vida do projeto
O projeto de implantação da análise de riscos à segurança da informação possui características 
específicas: seu ciclo de vida é previsto, também chamado de ciclo de vida inteiramente planejado. 
Isso quer dizer que ele faz parte daqueles projetos em que o escopo, o tempo e os custos exigidos para 
entregar tal escopo são determinados o mais cedo possível no ciclo de vida do projeto.
Esses projetos progridem através de uma série de fases sequenciais ou sobrepostas. Cada fase geralmente 
foca um subconjunto de atividades de projeto e processos de gerenciamento de projeto. O trabalho executado 
em cada fase é geralmente de caráter diferente do trabalho das fases anteriores e subsequentes. Assim sendo, 
a formação e as habilidades exigidas da equipe do projeto podem variar de fase para fase.
Planejamento
Requisitos
Construção
Projeto
Viabilidade
Tese
Giro
Figura 57 – Exemplo de ciclo de vida previsível
7.2 Estrutura para projetos
Segundo Carvalho e Rabechini Júnior (2005), as organizações devem propor estruturas organizacionais 
que se adaptem aos projetos. Para isso, devem acoplar os projetos em estruturas fundamentadas para 
projeto ou em estruturas convencionais que os integram. Dessa forma, existem três formas ou estruturas:
156
Unidade IV
• Estrutura funcional.
• Estrutura projetizada.
• Estrutura matricial.
A estrutura funcional não apresenta diferenças das características habituais segmentas em 
funções, ou seja, os projetos são divididos entre os segmentos e alocados aos grupos funcionais 
relevantes dentro das áreas funcionais maiores. Nesse caso, o projeto é coordenado pelos gerentes 
funcionais e por membros da alta administração. Essa estrutura tem como principais vantagens o uso 
dos recursos humanos, a alocação de especialistas, a possibilidade de armazenamento do conhecimento 
do projeto pelo departamento, o crescimento técnico, o controle sobre os recursos humanos, os canais 
de comunicação vertical e a rápida resposta às reações necessárias. Como desvantagens, essa estrutura 
não tem o cliente como foco, as ações e decisões favorecem mais o departamento que o projeto. 
As responsabilidades ficam, em geral, com o gerente funcional, o que é uma tendência de subestimar o 
projeto, e não há sistema de gerenciamento focado em projetos.
Compras
Gestão 
do projeto
Atividade
Recursos 
humanos
Diretoria
Atividade
Atividade
Tecnologia da 
informação
Atividade
Atividade
Figura 58 – Estrutura funcional e os projetos
A estrutrura projetizada é focada em projetos, o que é sua principal característica. As equipes 
participam de projetos e somente de projetos. Eles são coordenados pelos gerentes de projetos. 
As principais vantagens são o gerente do projeto ter o controle total dele, a comunicação fluir melhor e 
os canais de comunicação serem mais fortes. A equipe de projeto fica sob responsabilidade do gerente, 
assim a possibilidade de tomar decisões rápidas é mais importante, existe uma rápida resposta 
ao cliente e um alinhamento melhor com a alta direção. Como desvantagem, destacam-se o difícil 
gerenciamento entre muitos projetos (duplicidade), a alocação de especialistas em função de sua 
disponibilidade e nem sempre da necessidade, políticas e procedimentos que se incompatibilizam com 
projetos, a incerteza dos membros da equipe de que serão novamente aproveitados quando o projeto se 
encerrar e, dessa forma, não conseguirem dar continuidade a suas carreiras.
157
GESTÃO E ANÁLISE DE RISCOS
Gerente de 
projeto
Projeto 1
Atividade
Gerente de 
projeto
Diretoria de 
projetos
Projeto 2
Atividade
Gerente de 
projeto
Projeto 3
Atividade
Figura 59 – Estrutura projetizada e os projetos
Segundo Carvalho e Rabechini Júnior (2005), na estrutura matricial, um gerente é alocado para 
supervisionar o projeto dividindo responsabilidades e autoridades. Para completá-la, trabalha junto a 
gerentes funcionais.
Gerentes de projetos e gerentes funcionais dirigeme tomam decisões juntos sobre vários segmentos 
e fluxos de trabalho. Algumas das vantagens dessa estrutura é que o gerente de projetos, responsável 
pelo projeto, usa das competências técnicas dos departamentos para realizar as atividades do projeto, dar 
respostas rápidas aos clientes, ter maior flexibilidade, mais representatividade, maior controle dos vários 
projetos e cria políticas e procedimentos para vários projetos. As desvantagens dessa estrutura residem 
em dúvidas quanto a responsabilidades, pois os membros da equipe ficam com dois chefes. Isso pode 
gerar conflitos entre os gerentes funcionais e os de projetos, com prioridades alteradas continuamente. 
A habilidade de negociação do gerente de projetos nem sempre segue como deveria.
A estrutura matricial pode gerar alguns conflitos na estrutura de gestão da organização. Para evitar 
esses conflitos, é necessário decidir entre duas formas distintas de estruturas matriciais: matricial leve 
e matricial pesada.
Segundo Carvalho e Rabechini Júnior (2005), na estrutura matricial leve, um gerente tem autoridade 
limitada e é designado para coordenar o projeto ao longo de diferentes áreas ou grupos funcionais. 
Esse gerente retém as responsabilidades e autoridade sobre os seus segmentos específicos de 
trabalho. Na estrutura matricial pesada, o gerente é designado para supervisionar o projeto, tendo 
responsabilidade e autoridade primárias para completá-lo.
O gerente funcional aloca o pessoal necessário e prova as competências técnicas que melhor 
atendem o projeto.
158
Unidade IV
Gerente 
TI
Analista de TI
Atividade
Gerente 
 jurídico
Diretoria
Analista jurídico
Atividade
Gerente de 
projeto
Projeto 3
Atividade
Figura 60 – Estrutura matricial e os projetos
Geralmente, os projetos se encaixam na estrutura corporativa vigente. Quando colocados em pauta 
o projeto de implantação da gestão de riscos à segurança da informação e as estruturas existentes, em 
80% dos casos, a estrutura que vai abarcar o projeto será a funcional por ser a mais tradicional. Isso leva 
a acreditar que será nomeado um gerente de projetos, possivelmente um coordenador ou um gerente de 
segurança da informação, que deverá estruturar sua equipe com membros da sua própria área funcional 
ou alocando-os de outras áreas para a sua. Nesse momento, a importância dada ao projeto pela alta 
gerência fará a diferença.
A contratação de consultoria para auxiliar no planejamento, na gestão e até mesmo na execução 
do projeto pode ser uma alternativa devido à experiência em projetos anteriores semelhantes, 
todavia a gestão e as decisões devem estar a cargo do gerente funcional designado. Algumas 
organizações possuem os chamados escritórios de projetos que, nesse caso, será responsável pela 
gestão do andamento do projeto com o controle dos três principais fatores (custo, prazo e qualidade), 
organizando as reuniões de alinhamento e reporte dos resultados parciais e identificando os possíveis 
desvios e propondo correções.
Independentemente de como está estruturado o projeto, ele deverá ter de estabelecer um 
gerenciamento como mencionado anteriormente. Dessa forma, algumas atitudes, segundo o PMBOK 
(PMI, 2005), devem ser características do gerenciamento do projeto desde sua concepção, levando à 
entrega final.
O gerenciamento de projetos é a aplicação de conhecimentos, habilidades, ferramentas e técnicas 
às atividades do projeto a fim de cumprir os seus requisitos. A aplicação do conhecimento requer 
o gerenciamento eficaz dos processos de gerenciamento do projeto. Lembrando que o processo de 
gerenciamento é um conjunto de ações e atividades inter-relacionadas executadas para criar um produto, 
serviço ou resultado pré-especificado. Cada processo é caracterizado por suas entradas, ferramentas e 
técnicas que podem ser aplicadas e as saídas resultantes.
159
GESTÃO E ANÁLISE DE RISCOS
Ainda segundo o PMBOK (PIM, 2013), o gerente de projetos deve considerar os ativos de processos 
organizacionais e os fatores ambientais da empresa, que devem ser considerados para todos os processos, mesmo 
que não estejam explicitamente listados como entradas na especificação do processo.
Os ativos de processos organizacionais fornecem diretrizes e critérios para adequação dos processos 
da organização às necessidades específicas do projeto. Os fatores ambientais da empresa podem 
restringir as opções de gerenciamento do projeto.
Dessa forma, para que um projeto seja bem-sucedido, a equipe do projeto deverá:
• selecionar os processos apropriados para cumprir os objetivos do projeto;
• usar uma abordagem definida que pode ser adaptada para cumprir os objetivos;
• estabelecer e manter a comunicação e o engajamento apropriado com as partes interessadas;
• cumprir os requisitos para atender às necessidades e expectativas das partes interessadas;
• obter um equilíbrio entre as demandas concorrentes de escopo, organograma, orçamento, 
qualidade, recursos e riscos para criar o produto, serviço ou resultado especificado.
Os processos do projeto são executados pela equipe do projeto com a interação das partes interessadas. 
Em geral, podem ser classificados em uma de duas categorias principais:
• Processos de gerenciamento de projeto: garantem o fluxo eficaz do projeto ao longo da 
sua existência. Esses processos abrangem as ferramentas e técnicas envolvidas na aplicação de 
habilidades e capacidades descritas nas áreas de conhecimento.
• Processos orientados a produtos: especificam e criam o produto do projeto. Os processos 
orientados a produtos são normalmente definidos pelo ciclo de vida do projeto e variam de acordo 
com a área de aplicação e a fase do ciclo de vida do produto. O escopo do projeto não pode ser 
definido sem algum entendimento básico de como criar o produto especificado. Por exemplo, as diversas 
técnicas e ferramentas de construção devem ser consideradas ao determinar a complexidade 
geral da casa que será construída.
A figura anterior demonstra os grupos de processos que devem ser considerados em um projeto 
convencional segundo o PMBOK (PIM, 2013).
 Observação
A estrutura da organização influencia diretamente a forma como será 
definido e gerenciado o projeto durante todas as suas fases, facilitando ou 
dificultando o próprio gerenciamento do projeto.
160
Unidade IV
Processos de 
inicação
Sair de fase/
encerrar projeto
Entrar em fase/
iniciar projeto
Processos de 
encerramento
Processos de 
monitoramento e controle
Processos de 
planejamento
Processos de 
execução
Figura 61 – Grupos de processo para gerenciamento de projetos
7.3 Desenvolvendo a metodologia de análise de riscos de segurança da informação
O projeto de implantação pode ser significativamente facilitado quando se estabelece uma 
metodologia de implantação ágil sem esquecer as bases de projetos anteriormente apresentadas e que 
levam a um processo estruturado e gerido de forma organizada. Dessa forma, o modelo apresentado faz 
uma análise das competências desenvolvidas pelo Centro de Educação Corporativa da Boston University, 
o qual demonstra sua gestão de projetos por competências, uma proposta derivada do próprio PMBOK, 
que enfatiza as competências necessárias para obtenção de sucesso em projetos.
Figura 62 – Competências necessárias para o gerenciamento de projetos
161
GESTÃO E ANÁLISE DE RISCOS
Nesse momento, a preocupação gerada reside no fato de ter que pensar em todas essas competências 
para gerenciar o projeto de implantação da análise de riscos à segurança da informação. O projeto aqui 
representado, além de ser de extrema importância, também apresenta muitas fases.
O gerenciamento complexo apresentado na metodologia proposta pelo PMBOK (PIM, 2013), e 
aprimorada no Centro de Educação Corporativa da Boston University, serviria muito bem; todavia, como 
mencionado, existem várias metodologias de projetos, e algumas se apresentam como sendo mais 
simples e flexíveis em seus controles e atividades.
Um exemplo dessas metodologias vem do Cobit (ControlObjectives for Information and Related 
Technologies), que é um modelo (framework) de boas práticas criado pela Isaca (Information Systems 
Audit and Control Association) para a governança de tecnologia de informação, onde foi desenvolvido o 
modelo de identificação pela análise das capacidades, sendo definidas cinco as capacidades que, quando 
analisadas, levam a um diagnóstico preciso. Ressaltando que isso não substitui a gestão de projetos, 
todavia facilita a criação das competências, levando mais rapidamente a um plano de implantação.
As capacidades a serem analisadas são cinco: governança, organização, processos, tecnologia 
e métrica. Ao final, resultam em um plano de ação factível e orientado a projetos. A abordagem 
teórica a seguir foi baseada no projeto-alvo da análise e implantação da gestão de riscos à segurança 
da informação.
Para compreender como o modelo é estabelecido, devemos verificar como funciona a estrutura 
de análise na qual é realizada uma análise da situação atual sobre a capacidade. Após essa análise, é 
comparada com um modelo de negócio ou de melhores práticas. No nosso projeto, vamos utilizar o ISF 
(Standard of Good Practice for Information Security) de 2018 (NIST, 2018).
O comparativo entre a situação atual com o ISF levará a direcionadores que devem ser implantados 
para melhora da maturidade e da performance no assunto analisado, no nosso caso, a gestão e análise 
de riscos à segurança da informação. Veja a seguir:
• Capacidade de governança: responsável pela gestão geral da gestão do risco. Nessa capacidade, 
devem ser analisados itens, políticas, normas, controles e elementos de conformidade.
• Capacidade de organização: responsável pela gestão das pessoas envolvidas no SGSI, seguindo 
nosso exemplo, as pessoas envolvidas no processo de gestão dos riscos à segurança da informação, 
devendo ser analisados os papéis, as responsabilidades, as habilidades e as competências.
• Capacidade de processo: responsável em operacionalizar a execução das atividades da gestão 
de risco em que devem ser analisados os fluxos, os workflows, os procedimentos e as atividades.
• Capacidade de tecnologia: fornece as especificações em alto nível e tipos de tecnologias de 
maneira a suportar tecnicamente o tema gestão e análise de riscos à segurança da informação, 
devendo analisar as ferramentas, as aplicações e a infraestrutura.
162
Unidade IV
• Capacidade de métrica: fornece os indicadores que medem a capacidade da gestão e análise 
de risco em atender aos seus destinos estratégicos e ao tema estratégico. Cada indicador deve 
ser relativo ao atendimento aos controles e direcionadores indicados nas demais capacidades 
analisadas e deve fornecer informações para que os gestores da organização possam tomar 
decisões referentes ao modelo operacional de segurança da informação e de gestão e análise de 
riscos à segurança da informação, devendo propor relatórios, KPIs, KRIs e dashboards.
Após completadas as análises das capacidades, a tarefa de desenvolver um plano de implantação fica 
facilitada, uma vez que o gestor do projeto vai endereçar suas ações nas melhores práticas ainda não 
implantadas ou parcialmente implantadas; lembrado que deve existir uma base de controles para haver 
a comparação com os processos já implantados. O resultado dessa análise pode definir os requisitos do 
projeto de implantação da gestão e análise de riscos à segurança da informação.
– Política
– Normas
– Controles
– Elementos de conformidade
– Papéis
– Responsabilidades
– Competências
– Habilidades
– Fluxos
– Workflows
– Procedimentos
– Atividades
– Ferramentas
– Aplicações
– Infraestrutura
– Relatórios
– KPIs
– KRIs
– Dashboards
Modelo de análise 
das 5 capacidades
Capacidade de 
governança
Capacidade de 
organização
Capacidade de 
processo
Capacidade de 
tecnologia
Capacidade de 
métrica
Figura 63 – Modelo de análise das 5 capacidades
A gestão e análise dos riscos são parte integrante da estratégia organizacional, sua implantação 
requer acompanhamento e aval da alta direção. Sendo assim, o primeiro passo é definir o objetivo 
da atividade ou área que se pretende ter implantada ao final de tudo, ou seja, o que deve estar 
operacionalizado, ressaltando que o objetivo e o escopo do projeto podem ser coisas distintas.
163
GESTÃO E ANÁLISE DE RISCOS
Como exemplo de objetivo para o nosso projeto, podemos definir da seguinte forma: gerir, 
identificar, avaliar e categorizar os riscos vinculados à segurança da informação e cibernética nos 
produtos, serviços, processos e projetos da organização, suportando os gestores na tomada de decisão, 
e estabelecer critérios e programa de compliance e conformidade de segurança da informação e 
cibernética, amparados nas políticas e normas corporativas de segurança da informação e cibernética, 
leis, regulamentações, autorregulamentação e padrões de mercado. Isso parece ser um escopo 
bem ambicioso, mas reflete o recomendado pela ABNT NBR ISO 31000 (2018), que diz para serem 
estabelecidos os seguintes focos estratégicos:
• Instauração de cultura corporativa consciente do risco, que deve ser institucionalizada para 
auxiliar a organização a reduzir os riscos de segurança da informação por meio da implantação 
de políticas e procedimentos adequados para todos os funcionários e contratados, bem como 
programas de educação e conformidade.
• Processos, métricas e tecnologias adequadas de gestão de riscos (ferramentas de GRC) que possam 
identificar os “pontos críticos” organizacionais e atribuir a devida responsabilidade pela correção e 
consequência da não conformidade que deve ser implantada.
• Melhorias na tomada de decisões e no desempenho dos negócios e da segurança da informação 
possibilitadas pelas práticas e processos de gestão integradas dos riscos (IRM) apoiados por uma 
cultura e tecnologias conscientes de riscos.
• Aplicação de indicadores de risco para a segurança associada aos ativos, atividades ou atributos 
que fornecem informações sobre a categorização do risco na organização em nível de tecnologia 
da informação e na eficácia do programa de segurança da informação.
• Implantação de uma metodologia de avaliação de risco adaptada que aborde e acompanhe os 
riscos da empresa de acordo com a intenção em correr riscos.
• Processo de início ao fim em toda a organização e na cadeia de abastecimento (terceiros) para 
transformar a corporação e todo o ecossistema resiliente aos riscos em todos os aspectos, físicos 
e digitais, por meio de uma gestão adequada dos riscos.
• Processo robusto para suportar leis mais rígidas, como a GDPR e LGPD, que permitem à organização 
identificar e tratar os riscos para a privacidade dos indivíduos para uma utilização deliberada, 
segura e intencional dos dados pessoais dos clientes e funcionários.
Para atingir esses objetivos secundários, é necessário estabelecer um ciclo de atividades que levará à 
implantação efetiva da gestão e análise de riscos à segurança da informação.
164
Unidade IV
Quadro 36 – Principais atividades para gestão e análise de riscos
Atividade Descrição 
1 Identificar e avaliar os riscos de segurança da informação e cibernética nos produtos, serviços e projetos da organização, periodicamente e sob demanda 
2 Gerir os riscos de segurança da informação e cibernética
3 Identificar as leis, regulamentações, autorregulamentações, normas infralegais e obrigações contratuais que são escopo da segurança da informação e cibernética
4 Gerir aceite e controle dos riscos
5 Identificar e converter os riscos em requisitos de segurança e cibernética
6 Identificar e/ou revisar padrões específicos do setor e extrair obrigações relevantes (por exemplo, PCI, Cobit) e converter em requisitos de segurança da informação
7
Avaliar a conformidade em segurança da informação e cibernética da organização baseado 
em normas internas de segurança da informação e cibernética, leis, regulamentações, 
autorregulamentações e normas infralegais
8 Assegurar a implementação dos controles desegurança da informação e cibernética para atender esses requisitos
9 Identificar e/ou revisar políticas internas (por exemplo, recursos humanos e acesso remoto) para determinar se há requisitos de segurança da informação e cibernética
10 Fornecer visão única e corporativa de conformidade em segurança da informação e cibernética
Quando falamos na análise da capacidade de governança, devemos considerar os processos atuais 
comparativos com melhores práticas selecionadas e, a partir desse ponto, traçar os objetivos para as 
capacidades de governança. Para exemplificar, será utilizado um exemplo fictício de uma média empresa 
que já possui uma metodologia de gestão de risco corporativo, todavia não apresenta implantada uma 
gestão e análise de riscos à segurança da informação institucionalizada. Esse é o foco desse estudo.
Situação atual
Baseline 
escolhido
ISF (2018)
Resultado 
desejável
– Não possui processo corporativo de gestão
– Avaliação de riscos pontuais
– Avaliação de riscos de informação - abordagem de 
gerenciamento
– Avaliação de riscos de informação - metodologia
– Avaliação de riscos - material de apoio
– Conformidade legal e regulatória
– Estabelecer e comunicar processo de avaliação de 
riscos de SI, cyber, conformidade suportada por 
norma, metodologia estruturada e integridade com 
a metodologia corporativa
Figura 64 – Modelo de gestão da capacidade de 
governança dos riscos de segurança da informação
165
GESTÃO E ANÁLISE DE RISCOS
Para atender o resultado desejável, após a análise das capacidades de governança, é necessário definir 
as atividades necessárias que vão levar ao pleno atendimento e, assim, elevar à maturidade identificada:
• Estabelecer, comunicar e implantar o processo de avaliação de conformidade corporativo em 
acordo com os controles abordados em requisitos de conformidade de segurança da informação.
• Definir, comunicar e implantar o processo de avaliação de risco e de conformidade de segurança 
e cibernética.
• Atualizar e publicar norma corporativa de avaliação de riscos e de conformidade de segurança 
da informação e cibernética.
• Definir e implementar metodologia de avaliação de risco e de conformidade de segurança 
e cibernética.
• Revisar e implantar os processos de avaliação de riscos e de conformidade de segurança da 
informação e cibernética.
• Definir e implantar ferramenta de GRC destinada à automação dos processos de avaliação de riscos 
e de conformidade de segurança da informação e cibernética.
• Estabelecer e implantar os indicadores de avaliação de riscos e de conformidade de segurança da 
informação e cibernética.
• Implantar sistema de gestão e avaliação de riscos e de conformidade de segurança da informação.
Quando acopladas ao gerenciamento de projetos, as capacidades podem seguir a implantação 
faseada, todavia algumas capacidades podem ser seguidas de forma simultânea conforme estabelecido 
no cronograma do projeto. Dessa forma, podemos afirmar que o projeto pode ter um escopo único que 
seria a implantação da gestão e análise de riscos à segurança da informação, que, por sua vez, poderia 
ser dividido em cinco fases ou entregáveis. Na finalização, resultaria na entrega final do projeto.
Seguindo a mesma estrutura de análise, a capacidade de organização remete a compreender como 
estão estabelecidos os papéis, as responsabilidades, as habilidades e as competências necessárias para 
operacionalizar a gestão e análise de riscos conforme o mesmo exemplo anterior de uma empresa de 
médio porte fictícia.
166
Unidade IV
Situaçao atual
Baseline 
escolhido
ISF (2018)
Resultado 
desejável
– Não possui processo corporativo definido para papéis e 
responsabilidades sobre a gestão de risco
– Equipe limitada
– Avaliação de riscos de informação - abordagem de 
gerenciamento
– Avaliação de riscos de informação - metodologia
– Relatório de risco de informação
– Gerenciamento de conformidade de SI
– Descrever as habilidades e competências necessárias 
para a operalização da gestão e análise de riscos à 
segurança da informação
Figura 65 – Modelo de gestão da capacidade de organização da gestão dos riscos de segurança da informação
O resultado da análise dessa capacidade será um desenho dos perfis necessários para os 
funcionários que vão atuar com a gestão dos riscos à segurança da informação, bem como 
os papéis e responsabilidades inerentes à gestão dos riscos à segurança da informação dentro do 
ambiente corporativo a fim de delimitar as competências corporativas sobre a gestão de risco à 
segurança da informação, estabelecendo, assim, os limites de atuação e as atividades relacionadas 
ao cotidiano da área escopo do projeto.
Na capacidade de processo, devem ser analisados os processos atuais considerando o modelo 
almejado como padrão, propondo melhorias conforme necessário. Nessa análise, também é preciso 
desenhar os fluxos dos processos atuais e mapear as atividades necessárias para complemento ou 
alterações no modelo atual, assim como cada atividade que está sendo executada e as que serão após 
a implantação da projeto.
Situaçao atual
Baseline 
escolhido
ISF (2018)
Resultado 
desejável
– Não existe norma específica
– Os processos estão mapeados, mas são insuficientes
– Procedimentos necessitam alteração
– Avaliação de riscos de informação - fluxo
– Avaliação de riscos de informação - metodologia
– Perfil da ameaça
– Tratamento do risco
– Identificação de vulnerabilidades
– Operacionalizar avaliação de riscos de segurança da 
informação e cibernética
– Operacionalizar avaliação de conformidade de 
segurança da informação e cibernética
Figura 66 – Modelo de gestão da capacidade de processos da gestão dos riscos de segurança da informação
167
GESTÃO E ANÁLISE DE RISCOS
Dessa forma, o entregável dessa capacidade será um conjunto de fluxos de atividade que vão 
compor as atividades após a entrega do projeto, sendo possível, assim, estabelecer uma operação eficaz 
da análise e gestão dos riscos corporativos passando pela identificação dos riscos, mapeamento das 
ameaças, tratamento dos riscos, detecção de vulnerabilidades e, principalmente, a categorização do 
riscos à segurança da informação. Outro importante entregável dessa área é a matriz Raci (Responsável, 
Autoridade, Consultado e Informado), que determina, dentro de cada processo, a cadeia de aprovação 
e seus envolvidos.
A capacidade de tecnologia remete à definição de como será a automação dos processos 
desenhados, partindo da avaliação do que já está implantado e propondo novas ferramentas e 
especificações técnicas que vão compor e suportar todo o modelo estratégico de gestão. A análise 
de riscos à segurança da informação também está inclusa nesse processo, além das ferramentas 
tecnológicas e das aplicações.
A infraestrutura que vai suportar todos os processos, relatórios gerenciais e processos de decisão 
e categorização dos riscos à segurança da informação devem ser definidas em esfera organizacional 
devidamente documentada, comunicada, treinada e gerida de forma automatizada.
Situação atual
Baseline 
escolhido
ISF (2018)
Resultado 
desejável
– Processo manual de aferição controlado por planilhas 
e formulários
– Avaliação de riscos de informação - metodologia
– Avaliação de risco
– Relatório de risco de informações
– Gerenciamento da conformidade de SI
– Selecionar, adquirir e implantar ferramenta de GRC - 
Gestão de Riscos e Compliance
Figura 67 – Modelo de gestão da capacidade 
tecnológica da gestão dos riscos de segurança da informação
O resultado desejado para essa capacidade remete não apenas à automatização dos processos 
por meio de uma ferramenta especializada em GRC, mas também congrega a infraestrutura que vai 
suportar. Isso denota obrigatoriamente acionar algumas áreas específicas de tecnologia da informação 
considerando a definição da melhor infraestrutura e a escolha da ferramenta mais viável, além da 
decisão sobre comprar uma solução ou desenvolvê-la internamente, o que denota em estimativa de 
prazose custos no projeto. Lembrando que essas atividades podem correr em paralelo a outras no 
cronograma de projeto.
168
Unidade IV
É necessário durante a elaboração do projeto que sejam mapeadas todas as fases, definindo, 
assim, os entregáveis para o projeto, levando ao resultado desejado estabelecido no termo de 
abertura do projeto.
A capacidade de métrica deverá ser a última parte do projeto ou então ser implantada em um 
momento posterior ao próprio projeto. Algumas métricas de desempenho necessitam de amadurecimento 
para gerar dados e confirmar a sua efetividade. Assim, nessa capacidade, serão estabelecidos os 
formatos e possíveis resultados que se deseja extrair destinados a auxiliar não apenas a própria gestão 
dos riscos, mas também a alta direção na tomada de decisões sobre o posicionamento em relação aos 
ativos críticos e às decisões de investimentos em novos controles de segurança da informação, a fim de 
reduzir os riscos.
Situaçao atual
Baseline 
escolhido
ISF (2018)
Resultado 
desejável
– Os indicadores que estão implantados remetem apenas 
à volumetria de atendimeno de pareceres de risco, que, 
por sua vez, têm periodicidade mensal
– Relatório de risco de informações
– Gerenciamento da conformidade de segurança 
da informação
– Definir modelo de reporte funcional estabelecendo os 
indicadores de avaliação de riscos e de conformidade 
de segurança da informação
Figura 68 – Modelo de gestão da capacidade de métrica 
para gestão dos riscos de segurança da informação
O resultado da capacidade de métricas remete a controlar se tudo aquilo que foi implantado está 
funcionado como deveria a fim de estabelecer critérios para melhoria dos processos da gestão de riscos 
à segurança da informação
O processo de implantação da metodologia de análise de riscos à segurança da informação remete 
estabelecer dentro do projeto a forma como serão estruturadas as entregas do projeto, seu prazo de 
execução e a qualidade requerida, além dos recursos necessários e dos custos previstos.
O exemplo a seguir de cronograma para fins didáticos segue dentro da análise fictícia elaborada em 
“Desenvolvendo a Metodologia de Análise de Riscos de Segurança da Informação”:
169
GESTÃO E ANÁLISE DE RISCOS
Definir modelo de reporte funcional 
estabelecendo os indicadores de 
avaliação de riscos e de conformidade de 
segurança da informação
Operacionalizar avaliação de riscos de 
segurança da informação cibernética
Operacionalizar avaliação de conformidades 
de segurança da informação cibernética
Selecionar, adquirir e implantar ferramenta 
de GRC - Gestão de Riscos e Compliance
Estabelecer e comunicar processo 
de avaliação de riscos de SI, cyber e 
conformidade suportada por norma, uma 
metodologia estruturada e integridade 
com a metodologia corporativa
Descrever as habilidades e competências 
necessárias para a operacionalização da gestão 
e análise de riscos à segurança da informação
Figura 69 – Entregas do projeto de implantação da gestão de riscos à segurança da informação
O formato das entregas vai determinar como se desenvolverá o cronograma. A figura seguinte 
representa de forma simplista o possível cronograma para o projeto foco da análise fictícia realizada em 
que constam os elementos essenciais do projeto, como prazo, custo, recursos necessários (humano e 
financeiro) e as entregas esperadas. Evidentemente que de cada uma dessas entregas derivam inúmeras 
atividades que, ao final, chegam ao resultado desejado. Sem esquecer que se aumentarem os recursos, o 
tempo diminui; se reduzi-los, o tempo aumenta; e se forem reduzidos o tempo e os recursos, a qualidade 
vai ser prejudicada.
Jan. Fev. Mar. Abr. Mai. Jun. Jul. Ago. Set. Out. Nov. Dez.
Tempo
Entregas
$
$
$
$$
$
Figura 70 – Cronograma simplificado do projeto de implantação 
da gestão de riscos à segurança da informação
170
Unidade IV
8 RISCOS DE AUDITORIA
Os projetos são concebidos para desenvolver algo novo ou modificar algo existente e possuem 
começo meio e fim bem definidos. Sendo assim, eles podem demorar mais um dia, acabam, e, quando 
acabam, certamente, se tornarão processos operacionais compostos de inúmeras atividades executadas 
no cotidiano corporativo.
Num determinado momento, com certeza, tornam-se componentes dos mecanismos corporativos, 
trazendo valor e agregando desempenho; contudo, mesmo os mais belos e promissores depois se tornarão 
obsoletos e, às vezes, serão negligenciados pelos funcionários que deveriam seguir suas recomendações, 
mas não as seguem mais. Isso parece uma história triste, mas não é. Tudo se renova, se transforma, se 
reinventa. Essa é a mágica dos projetos.
A auditoria é um elemento que precisa estar presente para garantir que os processos não estejam 
se desviando das suas diretrizes. Mesmo os recém-implantados também podem apresentar desvios que 
podem levar a uma vulnerabilidade, que pode ser explorada por uma ameaça, causando impactos para 
a organização. Sendo assim, os processos de auditoria têm a responsabilidade de aferir se tudo está 
seguindo dentro do que foi estabelecido como ideal. Com o projeto de implantação da gestão e análise 
de risco à segurança da informação não seria diferente. Assim que entregue, será mais um processo 
corporativo que sofrerá no momento certo uma auditoria.
Não é escopo dessa obra demonstrar o funcionamento de um processo de auditoria, e sim demonstrar 
que o próprio processo de auditagem também sofre com os riscos.
Cabe uma breve introdução ao assunto. Avalos (2009) ressalta que a primeira área da gestão a se 
preocupar com seus processos e submetê-los a auditorias foi a contábil, devido aos seus processos 
bem desenhados e metódicos, pois pode facilitar desvios de conduta. Por motivo de ética profissional 
nas análises, os auditores precisam ser isentos de viés e totalmente confiáveis. A definição do papel 
de auditor estabelecida na auditoria pode ser definida por Avalos (2009) como sendo a de auditor 
independente, um profissional altamente especializado que cumpre suas funções com ética e diligência 
para tanto, possui conhecimentos profundos nos assuntos que vai auditar, bem como nas técnicas de 
auditoria que compõem seu cotidiano.
8.1 Identificando o risco na auditoria
Existem riscos em todas as atividades, inclusive naquelas em que os riscos não são aceitáveis. Um bom 
exemplo disso são os processos de auditoria, por isso é importante identificar esses riscos e procurar 
reduzir sua probabilidade. Segundo Avalos (2009), os riscos que produzam erros nas diversas áreas dos 
relatórios devem ser identificados. Os passos sugeridos para essa identificação estão a seguir.
1º – Identificação dos itens mais importantes
Os motivos significantes são áreas quantitativamente significativas, isto é, aquelas que estão acima da 
importância relativa previamente determinada; áreas qualitativamente significativas, ou seja, quando estão 
ligadas a um sistema de informações importante, incidentes de segurança da informação, por exemplo.
171
GESTÃO E ANÁLISE DE RISCOS
2º – Identificação dos sistemas
Podem afetar os relatórios. Esses sistemas podem ser divididos em dois grandes grupos:
• Sistemas ativos: vendas, recebimentos, compras, pagamentos.
• Sistemas passivos: contagens físicas, valorização de estoques, cálculo das provisões; outros 
cálculos, como impostos, amortizações etc.; folha de pagamentos; ativo imobilizado, produção, 
segurança da informação.
3º – Avaliação preliminar do risco
A avaliação deve ser feita sobre o sistema a ser analisado. Essa etapa do trabalho está condicionada 
ao nível de decisão do auditor, que é quem deve determinar quais dos sistemas precisa analisar em 
termos de controle interno, bem como quais não deve analisar.
As conclusões a que um auditor pode chegar ao analisar um sistema são as de que ou os controles 
internos são bons, caso em que o risco de erro pode ser considerado pequeno e o alcance das provas de 
auditorias será menor; ou de que os controles internos são ruins, casoem que o risco de erro torna-se 
médio-alto e será necessário programar provas de auditoria de alcance maior.
Segundo Avalos (2009), caso o auditor decidir não analisar um sistema, então os controles internos, 
por não terem sido investigados, possuem um grau de risco de erro desconhecido, portanto o alcance 
das provas programadas deverá ser maior. As técnicas normalmente utilizadas para analisar os sistemas 
de controle interno são a narrativa e a chamada técnica de Skinner (nome do pesquisador canadense 
que a desenvolveu). Com a aplicação dessas técnicas, é possível compreender se os controles internos 
são bons ou não.
4º – Provas sobre sistemas de controle interno
São os testes mediante os quais fica evidenciada a qualidade dos sistemas analisados.
5º – Avaliação definitiva do risco
Pode ser feita mediante a aplicação dos modelos de cálculo do risco existentes, como o proposto 
pelo American Institute of Certified Public Accountants (AICPA): RA = RI × RC × RD. Em que:
RA = risco de auditoria
RI = risco inerente
RC = risco de controle
RD = risco de detecção
172
Unidade IV
 Observação
O American Institute of Certified Public Accountants (AICPA) é a associação 
profissional nacional dos CPAs (Certified Public Accountants-Contadores 
Públicos Certificados) dos Estados Unidos, com mais de 330.000 membros.
O instituto estabelece padrões éticos para os profissionais e normas de 
auditoria para companhias privadas, governos federal e estaduais, e locais 
e organizações sem fins lucrativos.
8.2 Analisando o risco de auditoria
Para Avalos (2009), o risco geral de auditoria remete ao risco de concluir o processo de auditoria sem 
que as aferições retratem a fiel realidade dos fatos amparados nas evidências verificadas e sem qualquer 
viés do auditor, bem como no risco de não auditar tudo o que deveria, deixando vulnerabilidades expostas.
O auditor deve obter o maior nível de certeza possível, de tal maneira a restringir o risco de auditoria 
ao seu menor nível relativo. Se, por exemplo, o auditor deseja ter 99% de certeza, então correrá 1% de 
risco de auditoria. Na prática, um risco de auditoria de 5% tem sido considerado suficientemente baixo 
para emitir uma opinião.
A categorização dos fatores que envolvem o risco contém alta carga de subjetividade. Geralmente, 
o que pode ocorrer nas auditorias de segurança da informação é que alguns fatores de riscos podem 
compor riscos maiores ou complementar outras categorias de riscos. Essa soma integrada dos riscos é 
chamada de risco geral da auditoria, que, por sua vez, também vai incluir a análise do risco inerente. 
O quadro a seguir mostra uma lista de checagem de alguns fatores de risco à segurança da informação. 
Ressalta-se que essa lista é apenas uma exemplificação de um modelo extremamente simples e 
representativo, no qual apenas um artefato de auditoria foi selecionado. 
Quadro 37 – Exemplo de fatores de riscos para controle de acesso
Fator de risco 
Nível de risco da empresa
Baixo Alto
Ausência de processo de liberação 
de acesso
Possíveis problemas de gestão nos 
acessos
Ausência de controle de exclusão 
dos acessos
Acessos indevidos na rede ou 
sistemas
Ausência de controles de 
segregação de acessos Possibilidade de fraude interna
Ausência de processo de revisão 
dos acessos
Possíveis problemas de gestão nos 
acessos
Ausência de travas para criação 
de senhas fracas
Possibilidade de sucesso em 
ataques de força bruta
173
GESTÃO E ANÁLISE DE RISCOS
8.3 Elementos do risco de auditoria
O risco geral da auditoria, segundo Avalos (2009), é uma mistura de três grandes blocos de risco:
• Risco inerente: origina-se da natureza própria da conta ou do tipo de operação analisada.
• Risco de controle: consiste na incapacidade de o sistema de controle interno evitar ou detectar 
oportunamente um erro importante.
• Risco de detecção: nada mais é do que o risco de que erros importantes, individualmente ou em 
conjunto com as contas anuais, não sejam detectados pelas provas substantivas.
O auditor deve determinar e categorizar os riscos inerentes e de controle, bem como planejar e 
estabelecer procedimentos de auditoria para o risco de detecção a fim de que, dessa maneira, seja evitado 
que o risco geral de auditoria não sobreponha o risco aceitável, pois, assim, a própria auditoria não faria 
sentido. Basicamente, pode-se cravar que o risco de detecção é uma função direta dos procedimentos 
de auditoria:
Risco de detecção = f (Procedimentos de auditoria).
O risco inerente é definido como a vulnerabilidade de o ativo auditado estar suscetível, 
independentemente dos efeitos dos controles internos aplicados. Dessa forma, o risco inerente 
é influenciado pela natureza do ativo e pela classificação do tipo de informação acessada, como 
exemplo: uma ativo em papel está menos suscetível a vazamento do que informações trafegando 
pelos meios eletrônicos.
É importante salientar o que menciona Castelló (1991), que indica que a revisão do entorno da 
empresa ajuda a determinar os fatores que afetam especificamente o cliente e a antecipar a possível 
existência de erros ou irregularidades que possam ser produzidos no trabalho.
Existem as chamadas considerações externas. São aquelas sobre as quais a organização, sob uma 
avaliação inicial, não consegue exercer qualquer controle, por exemplo:
• Condições de entorno: problemas de falhas nas operadoras de internet podem causar danos 
à disponibilidade da informação, todavia é possível desenvolver mecanismos de contingência 
contratando duas operadoras distintas. Mesmo assim não dá para exercer controle sobre elas.
• Requisitos legais e obrigatoriedade da informação: o total conhecimento das normas legais 
aplicáveis, como exemplo da Lei n. 13.709/2018-LGPD.
Mas também existem as considerações internas, ou seja, aquelas que são derivadas das próprias 
características da empresa e sobre as quais ela pode exercer algum tipo de controle:
174
Unidade IV
• Influência dos acionistas: é necessário conhecimento completo do relacionamento dos acionistas 
e sua influência sobre a organização e administração.
• Particularidades da gerência: influência que ela pode ter em determinadas operações da empresa, 
mais ou menos seguras.
• Aspectos operacionais: dependendo da área de atuação, cada organização tem suas particularidades 
operacionais, que devem ser levadas em conta.
Os objetivos de auditoria com maior probabilidade de serem afetados pelas condições do risco 
inerente são os relacionados ao atendimento legal, regulatório, fatores externos governamentais 
e econômicos.
Outro aspecto importante remete ao controle interno, sendo condições de risco inerente não cobertas 
normalmente pelos próprios sistemas de controle internos. Sendo assim, podem ser estabelecidos 
controles especiais ou serem aplicados procedimentos especiais para atender a essa necessidade.
Alguns fatores de risco inerente podem ser mencionados para a estimativa de risco inerente à 
segurança da informação:
• Decisões financeiras e operacionais sobre os controles de segurança da informação a serem 
adotados ficam a cargo de um único departamento.
• A má reputação da gerência de segurança da informação.
• Problemas em projetos de segurança.
• Dificuldades significativas para a auditoria.
• Transações problemáticas com organizações correlacionadas.
• Erros de consideração detectados na auditoria do ano anterior.
Segundo Avalos (2009), as características do risco inerente são atribuíveis a ativos que podem afetar 
todos os objetivos de auditoria, exemplificando:
• Ativos suscetíveis ao furto: pode incluir vazamento de informações ou fraudes facilmente 
conversíveis, bem como a ação intencional de ação interna a conhecida fraude interna.
• Riscos associados ao processo legal: risco que pode ser bastante reduzido pelos controles 
internos.
• Experiência passada de fraudes e erros: principalmente quando o histórico mostra 
continuamente esses erros ou fraudes que afetam determinados ativos de informação.