Tradução do texto - COBIT Case Study: IT Risk Management in a Bank, por Eduardo R Martins (02/03/2011) 1

Texto disponível em:

http://www.isaca.org/Knowledge-Center/cobit/Pages/COBIT-Case-Study-IT-Risk-Management-in-a-Bank.aspx

COBIT - Estudo de Caso: Gerenciamento do Risco de TI em um Banco

®
Este estudo de caso é um exemplo de uso do COBIT , extraído da vida real, para o gerenciamento do risco de TI (Tecnologia
da Informação) dentro de um banco global. O COBIT foi usado efetivamente para gerenciar o risco dentro das equipes de TI,
1
para assegurar que uma governança de TI apropriada e que processos de garantia de TI (IT Assurance ) fossem utilizados
por todo o banco.

Antecedentes
O banco, neste caso, é um conglomerado global com operações em mais de 50 países e com mais de 125.000 empregados
em todo o globo. Suas equipes de TI estão localizadas em todo o mundo para sustentar linhas de negócios globais. As
equipes de TI incluem centros de desenvolvimento que são parte do banco e outros que são terceirizados (fornecedores),
bem como escritórios de retaguarda de TI que sustentam os serviços e a infraestrutura de TI.
2
O banco tinha um histórico de múltiplos modelos de governança e de garantia , seguidos por diferentes equipes, regiões e
localidades. Assim, o principal desafio foi criar processos comuns de governança e de garantia, para serem utilizados por
todas as suas equipes de TI, independentemente de localização geográfica.

O programa de governança e de garantia de TI foi completamente concebido como um framework (estrutura) de

gerenciamento de risco para assegurar um gerenciamento eficaz do risco e do controle.

O framework foi definido para tratar as deficiências existentes no gerenciamento do risco e do controle, tais como:
• Processos imaturos para avaliar e testar a conformidade (compliance)
• Ausência de repositório único de controle, resultando em duplicação de controles
• Ausência de um processo claro e repetitivo para concluir as avaliações de risco.

Esse novo framework era aguardado para permitir às equipes de TI entender os riscos operacionais significativos e seu
impacto global na organização por:

• Abordar as áreas nas quais os riscos não eram efetivamente controlados

• Permitir, aos executivos de TI, demonstrar eficientemente as responsabilidades regulatórias
• Usar uma plataforma comum para comunicar todos os requisitos regulatórios através de regiões e países
• Comunicar, de modo eficaz, as deficiências de risco e controle da TI que podem impactar o negócio
• Implementar um processo-padrão através das regiões e escritórios, para assegurar consistência e evitar a duplicação de
relatórios.

1
Trata-se de um ramo da Auditoria de TI que se preocupa com a Governança da Tecnologia da Informação e Comunicação (TIC).
2
Utilizou-se o termo ‘garantia’ como tradução para ‘assurance’, de tal maneira que nos variados momentos do texto em que a palavra
‘garantia’ for utilizada, deve-se entendê-la como aquele ramo da auditoria de TI que se ocupa da governança da TIC.
 Tradução do texto - COBIT Case Study: IT Risk Management in a Bank, por Eduardo R Martins (02/03/2011) 2

Uso do COBIT
A equipe de governança decidiu usar o COBIT como framework padrão. Uma equipe de profissionais - incluindo pessoal de
risco, pessoal de segurança de TI e especialistas em processos da Lei Sarbanes-Oxley (EUA) - foi então convocada para
definir os processos e os modelos. A equipe trabalhou principalmente em três áreas:

1. Definição de um framework para usar - Framework de Objetivo de Controle (ou COF, acrônimo inglês para Control
Objective Framework);

2. Identificação de uma definição-padrão para as “entidades”, contra as quais os riscos e os controles devem ser
avaliados - Modelo de Gerenciamento de Entidade-Chave;

3. Identificação de um processo de gerenciamento de risco - Avaliação de Controle e Risco (ou RCA, acrônimo inglês
para Risk and Control Assessment).

As etapas essenciais no processo de desenvolvimento de um framework de gerenciamento de risco para o banco são
descritas nas próximas seções.

Etapa 1 — Definição do Framework de Objetivo de Controle (COF)

O COF foi definido para associar os riscos que afetam os escritórios de tecnologia com as melhores práticas de controle que
são o padrão nessa indústria, como definido pelo COBIT. Três objetivos foram então estabelecidos enquanto definição para o
COF:
1. Ele deve agir como uma ferramenta para facilitar a avaliação eficaz dos riscos e controles no ambiente de TI do banco;
2. Ele deve agir como um framework de informação (relatórios) para demonstrar como a TI atende às exigências regulatórias
quanto a relatórios, incluindo aqueles da ‘Sarbanes-Oxley’;
3. Ele deve agir como um auxílio para guiar o gerenciamento da garantia.

As etapas de implementação do COF, usando o COBIT, incluíram:

• Identificar os principais riscos (Riscos de Nível I) - Os principais riscos (ou riscos de nível I) foram definidos e
‘congelados’ com base em informação anterior. Os riscos identificados incluíram aqueles relacionados com tecnologia,
operações, pessoas, exigências legais e regulatórias, relatório financeiro, crime financeiro, marca comercial e mudança.

• Identificar os riscos de Nível II - O risco principal foi subdividido em riscos de nível II. Como exemplo, o ‘risco principal de
tecnologia’ foi subdividido em:
- Métodos inadequados de desenho e teste de sistemas de TI;
- Indisponibilidade de sistemas de TI;
- Ausência de segurança de TI.

• Identificar objetivos de controle - Para cada um dos riscos de nível II, foram identificados objetivos de controle usando o
COBIT. A Figura 1 indica o mapeamento dos riscos de nível II com os objetivos de controle identificados contra cada um dos
riscos de tecnologia.
 Tradução do texto - COBIT Case Study: IT Risk Management in a Bank, por Eduardo R Martins (02/03/2011) 3

FIGURA 1 - Mapeamento dos Riscos de Nível II

Métodos inadequados de desenho e

Indisponibilidade de Sistemas de TI Segurança de TI
teste de Sistemas de TI

• PO2 Definir a arquitetura da informação • AI2 Adquirir e manter aplicativo de • PO2 Definir a arquitetura da
software informação

• AI3 Adquirir e manter infraestrutura • PO4 Definir os processos, a

• PO3 Determinar a direção tecnológica
tecnológica organização e os relacionamentos de TI

• PO8 Gerenciar a qualidade • AI5 Obter recursos de TI • PO9 Avaliar e gerenciar os riscos de TI

• DS1 Definir e gerenciar níveis de • AI2 Adquirir e manter aplicativo de

▪ PO10 Gerenciar projetos
serviço software

• DS3 Gerenciar performance e • DS5 Assegurar a segurança dos

• AI1 Identificar soluções automatizadas
capacidade sistemas

• AI2 Adquirir e manter aplicativo de

• DS4 Assegurar serviço contínuo • DS11 Gerenciar dados
software

• AI3 Adquirir e manter infraestrutura • DS8 Gerenciar service desk e

• DS12 Gerenciar o ambiente físico
tecnológica incidentes

• AI6 Gerenciar mudanças • DS10 Gerenciar problemas

• AI7 Aprovar e instalar soluções e

• DS11 Gerenciar dados
mudanças

• DS12 Gerenciar o ambiente físico

• DS13 Gerenciar operações

Benefício da Etapa 1
Antes de implementar esse framework, cada entidade, organização e local tinha seu próprio conjunto de controles. O COBIT
ajudou no desenvolvimento e no gerenciamento de uma lista única de controles para cada tipo de risco, por meio do
mapeamento dos controles necessários para o COBIT. Por sua vez, essa lista auxiliou na comprovação de cada tipo de risco,
o que forneceu confiança para os executivos sêniores em relação ao processo de comunicação e de comprovação.
Posteriormente, um processo de avaliação de risco foi desenvolvido para definir os riscos e os controles. Isso ajudou a
assegurar que os controles adequados fossem empregados para cobrir os riscos principais (riscos de nível I) e os riscos de
nível II.
 Tradução do texto - COBIT Case Study: IT Risk Management in a Bank, por Eduardo R Martins (02/03/2011) 4

Etapa 2 — Identificação de Entidades para Gerenciar Riscos e Controles

O modelo de gerenciamento de entidade-chave foi definido para incluir blocos de construção de TI, contra os quais as
avaliações de risco e controle deveriam ser realizadas. Os blocos de construção de TI são logicamente associados entre si
para fins de comunicação, para fornecer uma avaliação de risco e controle para todos os serviços de suporte de competência
do escritório de tecnologia.

Os blocos de construção de TI foram definidos como:

• Entidades ‘Processos’ - Essas entidades representam os processos usados para apoiar, controlar e gerenciar o ambiente
de TI. Todas as questões de controle em uma entidade Processo deveriam afetar vários serviços de TI. Por exemplo: o
3
controle de mudança é pervasivo à maioria dos serviços de TI.

• Entidades ‘Suporte a Serviços’ - A vinculação com entidades ‘Processos’ e ‘Tecnologia’ permite uma avaliação completa,
“ponta a ponta”, do risco e do controle para aquele serviço de suporte. Por exemplo: “interfacear” riscos entre entidades
‘tecnologia’; riscos de nível de serviço para serviço de TI “ponta a ponta”; e riscos de integração (o gerenciamento de
interações interdepartamentais).

• Entidades ‘Tecnologia’ - Essas representam os componentes tradicionais de TI. Por exemplo: servidores, aplicativos, redes
e firewalls. Os mapas de serviço e o processo de RCA (Avaliação de Controle e Risco) foram usados para facilitar a
identificação das entidades ‘tecnologia’ essenciais, que compõem cada serviço de suporte.

• Entidades ‘Projeto’ - Embora as entidades ‘projeto’ não tenham nenhum efeito (ao menos, imediato) sobre os serviços “top
20” (superiores; de nível mais alto dentre os serviços disponíveis, até o 20º deles), é muito importante capturar qualquer
informação de controle e risco antes de essas entidades serem colocadas em prática. Isso permitirá manter controle sobre o
estado do objetivo para uma nova alteração de desenvolvimento/projeto poder ser avaliada, relatada e comunicada antes de
ser posta em prática. Alguns exemplos de serviços top 20 incluem: conectividade ATM e serviços de suporte a aplicativos do
núcleo central da atividade bancária (core banking).

O método do banco para definir os serviços de TI é através de um Catálogo de Serviços de TI. Como parte desse catálogo,
cada um dos serviços top 20 foi identificado para o suporte aos serviços que lhes são subjacentes. Um mapa de serviço foi
criado para cada serviço de suporte. Os mapas de serviço ilustram os componentes tecnológicos que estão associados entre
si para suportar os serviços de ponta a ponta.

Cada entidade ‘processo’, assim como cada entidade ‘tecnologia’, é diferente e pode ser associada a múltiplos serviços de
suporte. Como resultado, o modelo de gestão da entidade-chave é flexível e pode suportar expansão, com a agregação de
serviços de TI adicionais, conforme necessário. A articulação entre as entidades permite que as avaliações de risco sejam
agregadas para fornecer um perfil, ponta a ponta, do risco do serviço, o que é significativo para o gerenciamento e para os
diferentes grupos que gerenciam as entidades no serviço global.

Benefício da Etapa 2
Antes da implementação do novo processo de gerenciamento de risco, cada região, país, etc, do banco tinha suas próprias
matrizes de controle e risco. A avaliação dos controles e dos riscos estava baseada no entendimento particular de cada uma
das equipes de trabalho em relação ao gerenciamento de risco em cada região, sendo que não havia foco no ‘resultado final’,
isto é, no impacto do risco sobre o serviço ao cliente. O COBIT ajudou na identificação dos serviços esssenciais que tinham
impacto sobre o negócio e sobre os clientes, e manteve o foco em controles. Uma vez identificados esses riscos, os controles
foram congelados com base no framework do COBIT e foram avaliados sob o ponto de vista de sua eficácia, com o claro
objetivo de determinar o impacto sobre o serviço ao cliente. Isso resultou na redução do total do número de incidentes e na
redução do impacto dos incidentes sobre os clientes e/ou sobre os serviços ao cliente.

3
Pervasivo: Trata-se de neologismo; significa: estar presente em todo lugar e em todo instante. Representa tradução, que vem sendo
empregada por variados autores, para o termo inglês pervasive. Este adjetivo possui vários significados em português; entre eles: penetrante;
universal; que se infiltra; difusivo.
 Tradução do texto - COBIT Case Study: IT Risk Management in a Bank, por Eduardo R Martins (02/03/2011) 5

Etapa 3 — Definindo e Implementando o Processo de RCA (Avaliação de Risco e Controle)

A visão geral do processo, apresentada na Figura 2, destaca as cinco etapas para a realização de uma avaliação de risco.
Dentro de cada uma dessas etapas foram identificadas as tarefas essenciais. Uma série de ferramentas/processos auxiliares
foi definida para ajudar com o escopo, a programação e a entrega da avaliação de risco, e está delineada nessa Figura.

O objetivo no desenvolvimento de um processo de RCA comum (a todas as unidades envolvidas) foi o de assegurar que as
análises de riscos e controles fossem consistentes entre as equipes no mundo todo.

Uma das ferramentas era um modelo simples em Excel, definido para capturar informações de risco e controle. O modelo foi
então congelado para utilização por todas as entidades. O modelo foi definido para capturar as seguintes informações
essenciais:
 Riscos principais (riscos de nível I) e de nível II
 Objetivos de controle com referência aos processos de controles do COBIT
 Referência aos requisitos de controle para Sarbanes-Oxley
 Proprietário do controle
 Avaliação do controle — eficiente, não-eficiente
 Ações para tornar o controle eficiente
 Detalhes do encerramento da ação — proprietário da ação, data-limite.
 Tradução do texto - COBIT Case Study: IT Risk Management in a Bank, por Eduardo R Martins (02/03/2011) 6

Os modelos foram preenchidos pelo proprietário de risco e controle e foram enviados para a equipe central de risco, para
revisão. Eles foram então inseridos na ferramenta de gerenciamento de riscos para o acompanhamento das ações para o
encerramento e para a apresentação de relatórios sobre riscos em aberto. Cada um foi rotulado com:

• Proprietários das entidades - Tipicamente, os proprietários de RCA

• Proprietários dos riscos - Os proprietários responsáveis pelos riscos

• Proprietários dos controles - Os proprietários responsáveis pela manutenção da eficiência dos controles

• Proprietários das ações - Os proprietários das ações definidas devido aos controles ineficientes.

Benefício da Etapa 3
Através de programas de treinamento, os termos ‘proprietário de entidade/RCA’, ‘proprietário do risco’, ‘proprietário do
*
controle’ e ‘proprietário da ação’ foram explicados usando uma tabela RACI (Responsible, Accountable , Consulted and
Informed ou, na tradução para o português, respectivamente: Responsável, Responsabilizado [ou responsável por prestar
conta], Consultado e Informado), conforme se pode ver na Figura 3 como um exemplo. As responsabilidades foram também
mapeadas nas descrições dos serviços e nos critérios de avaliação da performance do pessoal.

Chefe de
Gestor de Responsável Chefe da
Risco/Controle/Ações CEO COO Recursos
Risco pelas instalações Segurança
Humanos
Gerenciar a segurança física I C,I C,I A R
Reportar incidentes de segurança física -
empregados e vendedores I A C,I C,I R C,I

(Obs.: Na tabela acima, as letras utilizadas significam: R - Responsável; A - Responsável por prestar conta; C - Consultado; I - Informado)

O exemplo da Figura 3 esclarece que embora o responsável pelas instalações (facilities) seja mantido como responsabilizado
(accountable) por fornecer segurança física contínua, o COO (Chief Operations Officer - Chefe do Escritório de Operações) foi
responsabilizado por assegurar o relato dos incidentes e por acompanhá-los. Para quaisquer ações do pessoal empregado e
dos vendedores trabalhando fora do escritório, o Chefe de RH foi consultado e informado.

*
Accountability é um termo da língua inglesa que não tem tradução exata para o português e que se associa à obrigação de prestar
contas em relação a uma situação, ação, decisão, processo, etc. Um termo usado numa possível versão para o português
é responsabilização. Na prática, accountability é a situação em que "A deve reportar-se a B quando A é obrigado a prestar contas a B de
suas ações e/ou decisões, passadas ou futuras, para justificá-las e, em caso de eventual má-conduta, receber sanções/punições”.
Accountable, de acordo com o Dicionário Michaelis significa: responsável; dever de dar conta; explicável. O termo “responsabilizado”, por
vezes empregado como tradução para accountable, na verdade trata-se de um neologismo, pois não existe na língua portuguesa.

Etapa 4 —Treinando os Stakeholders Essenciais

Um dos principais desafios foi explicar o processo inteiro para todos os stakeholders com diferentes experiências e
entendimentos dos riscos e controles, e ainda em várias localizações. O desafio foi gerenciado por meio da criação de
programas de treinamento adicionais, em vários níveis. Isso envolveu:

• Formar especialistas em riscos (tipicamente com experiência anterior e certificações, tais como Certified Information
®
Systems Auditor™ [CISA ] and Chartered Accountant [CA]) nas diversas regiões e escritórios, que foram treinados
no âmbito de um programa de formação para formadores. Tais recursos foram usados para treinar os stakeholders.

• Adaptar do treinamento para ser ministrado por esses especialistas para as demais audiências. Para os proprietários
de entidade, uma simples visão geral do processo foi fornecida através de treinamento obrigatório baseado em
computador. Para proprietários de risco e controle, o treinamento foi detalhado e incluiu exemplos e testes, e foi
entregue em salas de aula em diferentes localidades, ou por meio de sessões de treinamento baseadas na web.
• Oferecer, como parte de um programa de treinamento obrigatório, uma sessão de treinamento dedicada à
sensibilização, na qual foi explicado o processo e foram fornecidos os contatos e os links dos especialistas em risco
da própria localidade, dentro da organização, para a obtenção de informações e orientações.
 Tradução do texto - COBIT Case Study: IT Risk Management in a Bank, por Eduardo R Martins (02/03/2011) 7

• Organizar um seminário (workshop) para disseminar informação relevante para os stakeholders; este deve iniciar
qualquer processo de avaliação de risco. Os recursos de treinamento foram usados para facilitar o controle da auto-
avaliação (CSA) em diferentes localidades.

• Modificar a descrição do papel e o processo de avaliação de desempenho para incluir tarefas específicas para riscos
e controles.

Benefício da Etapa 4
Devido a essa abordagem top-down (de cima para baixo), a importância do gerenciamento do risco foi bem aceita e esse
gerenciamento tornou-se eficiente em todos os níveis da organização.

Etapa 5 — Usando uma Ferramenta para Relatórios

Uma planilha simples foi usada para manter um repositório de risco e controle para cada entidade. Dentro da entidade, o
membro da equipe de risco usou uma planilha Excel para acompanhar os riscos, as ações, etc. Contudo, havia a exigência de
se ter um único e comum repositório de banco de dados, para manter os riscos e os controles para toda a organização.
Assim, uma ferramenta foi desenvolvida para coletar informações de todas as entidades. Isso ajudou em:

• Acompanhar todos os riscos relacionados a um determinado serviço

• Centralizar um repositório para todas as informações de riscos e controles
• Acompanhar todas as ações definidas e acordadas no processo de RCA
• Acompanhar as ações de encerramento
• Relatar aos executivos sêniores sobre os riscos, com base em exigências específicas e em níveis de risco
• Basear os relatórios por exigências regulatórias em um único e comum banco de dados de riscos e controles.

Benefício da Etapa 5
Um repositório único para todos os riscos, controles e ações, foi usado pelas equipes de garantia em seus relatórios para o
CIO, e também para o acompanhamento da conformidade (compliance) em um alto nível.

Conclusão
O desenvolvimento e implementação integral do novo processo demorou em torno de dois anos. Enquanto uma equipe central
foi responsável por desenvolver o processo, os recursos relacionados com riscos, baseados em cada localidade, foram o
instrumental usado na implementação do processo, no treinamento, etc. Uma vez que esses implementadores, em diferentes
localidades, faziam parte da equipe, os seus feedbacks foram usados para fazer as mudanças e as correções necessárias e,
assim, ajudar a melhorar a maturidade do processo.

Outros benefícios tangíveis dessa iniciativa incluíram:

• Antes dessa implementação havia mais de 500 entidades para as quais os riscos e os controles eram acompanhados.
O número foi otimizado para algo em torno de 100 entidades. Isso foi possível devido à implementação do modelo de
gerenciamento de entidade-chave.

• Inicialmente, foram definidos mais de 1000 controles. O número foi reduzido e cada controle foi mapeado para o
COBIT. Em nível global, o número de controles foi reduzido q quase 350. Contudo, dentro de uma entidade, região,
país, etc, em particular, um desenvolvimento adicional para um determinado controle foi permitido, a fim de ser
localmente acompanhado. Por exemplo: globalmente, na RCA, um único controle foi identificado para as conformidades
locais: controle de conformidade regulatória local. Contudo, esse controle foi desenvolvido (drill-down) em várias
conformidades baseadas em exigências específicas daquele determinado país. Na Índia, por exemplo, isso foi
gerenciado através de uma planilha separada, que cobria todas as regulamentações, tais como as leis de trabalho e
empregado e as relativas aos impostos.

• O exercício auxiliou o banco no processo de gerenciamento do risco e controle para a Sarbanes-Oxley, e em outros
processos regulatórios. A planilha RCA forneceu um filtro separado para a aplicabilidade da conformidade de acordo
com a Sarbanes-Oxley.
 Tradução do texto - COBIT Case Study: IT Risk Management in a Bank, por Eduardo R Martins (02/03/2011) 8

• O repositório de processos na ferramenta ajudou a manter consistência. Isso foi feito por meio da criação de uma
subunidade separada dentro da equipe de risco, para checar a qualidade de cada RCA antes de ela ser inscrita na
ferramenta de RCA.

• Um pacote de treinamento comum foi visto, pelas equipes de risco, como uma entrega importante e valiosa, e foi
definido de acordo com o público-alvo. Por exemplo, um pacote de treinamento de 15 minutos para todos os
proprietários de entidades (tipicamente, os líderes em cada região ou país) foi desenvolvido e implementado com a
utilização de um portal de treinamento e-learning, enquanto um pacote detalhado de treinamento no processo foi
desenvolvido para os proprietários de risco e controle.

Autor: Jitendra Barve (CISA, FCA)

É contador certificado, com mais de 18 anos de experiência em contabilidade, finança, auditoria e consultoria. Ele atuou por

mais de 10 anos em auditoria e consultoria de segurança de informação e trabalhou em diversas atividades de gerenciamento

de risco, em auditoria interna baseada em riscos, e em análises e auditorias de segurança da informação. Barve é um

membro do Conselho da ISACA, Capítulo Pune (Índia). É um associado de uma empresa de médio porte de Pune, a GD Apte

and Co.

Nota do Editor
Os leitores podem querer obser que o framework Risk IT da ISACA se expande sobre as áreas cobertas neste artigo e apóia

as empresas na identificação, na governança e no gerenciamento dos riscos de negócio relacionados com TI,

complementando as orientações de controle (mitigação de riscos) fornecidas no COBIT. Clique aqui para mais informações

sobre o Risk IT.