AUDITORIA

DE SISTEMAS

autor
JOÃO PAULO BROGNONI CASATI

1ª edição
SESES
rio de janeiro  2016
Conselho editorial  regiane burger; roberto paes; gladis linhares; karen bortoloti;
helcimara affonso de souza

Autor do original  joão paulo casati

Projeto editorial  roberto paes

Coordenação de produção  gladis linhares

Coordenação de produção EaD  karen fernanda bortoloti

Projeto gráfico  paulo vitor bastos

Diagramação  bfs media

Revisão linguística  amanda carla duarte aguiar

Imagem de capa  rawpixelimages | dreamstime.com

Todos os direitos reservados. Nenhuma parte desta obra pode ser reproduzida ou transmitida
por quaisquer meios (eletrônico ou mecânico, incluindo fotocópia e gravação) ou arquivada em
qualquer sistema ou banco de dados sem permissão escrita da Editora. Copyright seses, 2016.

Dados Internacionais de Catalogação na Publicação (cip)

C336a Casati, João Paulo

Auditoria de sistemas / João Paulo Casati
Rio de Janeiro : SESES, 2016.
120 p. : il.

isbn: 978-85-5548-215-1

1. Auditoria de sistemas. 2. Segurança da informação. 3. Tecnologia da

informação. 4. Sistemas de informação. I. SESES. II. Estácio.
cdd 657.453

Diretoria de Ensino — Fábrica de Conhecimento

Rua do Bispo, 83, bloco F, Campus João Uchôa
Rio Comprido — Rio de Janeiro — rj — cep 20261-063
Sumário

Prefácio 7

1. Auditoria de Sistemas, Auditor e

Planos de Contingência 9

1.1  Fundamentos de auditoria de sistemas 11

1.2  O papel e o perfil do auditor de sistemas 13
1.3  A carreira do auditor de sistemas 14
1.4  A auditoria de sistemas nas organizações 16
1.5  Abordagens de auditoria de sistemas 18
1.5.1  Abordagem ao redor do computador 18
1.5.2  Abordagem através do computador 19
1.5.3  Abordagem com o computador 19
1.6  Padrões e código de ética 20
1.7  Planos de contingência 21
1.7.1  O que é plano de contingência 22
1.7.2  Riscos e Ameaças 22
1.7.3  Componentes de um plano de contingência 30

2. O Funcionamento, os Controles Internos e

as Ferramentas da Auditoria 35

2.1  O funcionamento da auditoria de sistemas 37

2.2  Controles internos 40
2.3  Fases de uma auditoria de sistemas 43
2.3.1  Fase de planejamento 44
2.3.2  Fase de execução 46
2.3.3  Emissão de relatórios 47
2.3.4 Follow-up 47
2.4  Ferramentas de auditoria 48
2.4.1 Softwares generalistas 48
 2.4.2 Softwares especializados 49
2.4.3 Softwares utilitários 50

3. Técnicas de Auditoria e Controles

Organizacionais e Operacionais 53
3.1  Técnicas de auditoria 55
3.1.1 Software para auditoria 55
3.1.2 Questionário 57
3.1.3 Visita in loco 58
3.1.4 Entrevista 59
3.1.5  Teste de observância 60
3.1.6  Teste substantivo 60
3.1.7  Dados de teste 60
3.1.8  Teste integrado 61
3.1.9  Simulação paralela 61
3.1.10  Lógica de auditoria embutida nos sistemas 62
3.1.11  Mapeamento estatístico dos programas 62
3.1.12  Rastreamento dos programas 62
3.1.13  Análise da lógica de programação 63
3.1.14  Análise de log 63
3.2  Auditoria de controles organizacionais e operacionais 63
3.2.1  Políticas organizacionais 64
3.2.2  Violação de políticas organizacionais 67
3.2.3  Descrição de cargos em tecnologia da informação 67

4. Auditoria Direcionada 73

4.1  Auditoria de rede 75

4.2  Auditoria de hardware 78
4.3  Auditoria de controles de acesso 82
4.4  Auditoria de aquisição, desenvolvimento,
documentação e manutenção de sistemas 86
4.5  Auditoria de operação 91
 4.6  Auditoria de suporte técnico 93
4.7  Auditoria de aplicativos 94
4.8  Auditoria de eventos 96

5. Relatórios e Pacotes de Auditoria 99

5.1  Emissão de relatórios 101
5.2  Avaliação de software de auditoria de sistemas 107
5.2.1  Método de seleção 108
5.2.2  Pacotes disponíveis no mercado 112
5.2.3  Avaliação de pacotes de auditoria 114
Prefácio
Prezados(as) alunos(as),

A disciplina de auditoria de sistemas tem como objetivo apresentar as visões te-

órica e prática do processo de auditoria em sistemas de informação. O livro aborda
desde os fundamentos básicos da auditoria até informações específicas de audito-
rias direcionadas, relatórios e informações referentes a softwares de auditoria.
Muitos outros temas pertinentes, como planos de contingência, análise de ris-
cos, auditoria de controles internos, são abordados neste livro, passando por temas
que destacam o papel do auditor, seu trabalho no dia a dia e informações sobre a
carreira, certificações e cursos da área.
Ao final da disciplina, o aluno conhecerá aspectos gerais e específicos sobre o
processo de auditoria de sistemas, as ferramentas utilizadas para o trabalho do au-
ditor e poderá desenvolver uma visão crítica sobre os diferentes pontos de vista e
decisões que devem ser tomadas no âmbito das organizações.

Bons estudos!

7
 1
Auditoria de
Sistemas, Auditor
e Planos de
Contingência
No cenário atual, as organizações (empresas, governos, entre outras) estão cada
vez mais dependentes do funcionamento correto das tecnologias de informa-
ção. Com isto, a auditoria de sistemas se mostra um campo de atuação impres-
cindível, podendo auxiliar e promover maior confiabilidade das organizações
em seus serviços de tecnologia da informação. Neste capítulo o leitor pode-
rá adquirir os conhecimentos iniciais em auditoria de sistemas, assim como
aprender sobre o perfil e a carreira do auditor. Informações sobre planos de
contingência também são apresentadas neste capítulo, introduzindo o leitor a
uma ação de grande importância que é desenvolvida nas organizações.

OBJETIVOS
Os principais objetivos de aprendizado deste capítulo são:
•  Introdução do leitor ao universo da auditoria e mostrar sua importância para as organizações;
•  Compreensão das principais características do auditor e de sua carreira;
•  Apontar as principais características dos planos de contingência e a importância de sua
introdução no cotidiano das organizações.

10 • capítulo 1
1.1  Fundamentos de auditoria de sistemas
Os dados e as informações geradas por meio de sistemas de informação são
cruciais para as organizações, representando uma grande vantagem estratégi-
ca para elas. O bom funcionamento, a confiabilidade e a segurança aplicada a
estes sistemas são de fundamental importância para que as informações co-
lhidas sejam de grande valia para o auxílio à tomada de decisão por parte dos
gestores das organizações.
O uso de sistemas informatizados é abrangente na economia brasileira e
não para de crescer. Ao mesmo tempo em que algumas empresas não são tão
dependentes dos sistemas de informação, outras não conseguem funcionar
nem poucas horas sem a utilização deste recurso. A auditoria de sistemas é es-
timulada e cresce à medida que as organizações ficam mais dependentes da
informação de qualidade, e, portanto, do uso de sistemas informatizados. (GIL,
2000).
A auditoria de sistemas engloba as operações de uma organização, os pro-
cessos envolvidos com estas operações, os sistemas que geram as informações
e por fim a responsabilidade gerencial. Ela também se atém à verificação da
conformidade destes itens com os objetivos, normas, padrões, regras, orça-
mento e a política de uma organização. Garantir a segurança da informação, a
disponibilidade e a qualidade de recursos e serviços também é papel da audi-
toria de sistemas.
Segundo Imoniana (2008), a auditoria de tecnologia de informações visa,
além da utilização de recursos de informática para auditar sistemas e computa-
dores, ao uso dos recursos de informática também para automatizar processos
de auditoria em outras áreas.
As funções administrativas da auditoria de sistemas passam por três fases:

Em que são definidas as expectativas de comporta-

mento, os padrões a serem seguidos, as políticas da
PLANEJAMENTO organização, as previsões orçamentárias, entre outras
definições. O cronograma de execução da auditoria
também é definido nesta fase.

capítulo 1 • 11
 Medidas das operações e processos da organização.
Nesta fase o auditor deve verificar minuciosamente cada
EXECUÇÃO processo a ser auditado e colher informações suficien-
tes para que se possa analisar as operações em relação
ao planejamento.

Nesta fase as medidas adquiridas são confrontadas com

os padrões definidos na fase de planejamento, a fim de
verificar se as operações estão em conformidade com
CONTROLE estes padrões. Em caso de desvios, deve-se definir quais
ações serão tomadas para que as discrepâncias não
sejam repetidas.

O diagrama exibido na figura 1.1 exibe as fases das funções administrativas

da auditoria de forma ilustrativa.

Planejamento

Padrões Políticas

Execução

Testes Medidas

Controle

Medidas x Padrões Avaliação

Figura 1.1  –  Fases da auditoria de sistemas.

12 • capítulo 1
 Pode-se definir auditoria de sistemas como uma verificação de conformida-
de dos processos com os padrões de uma organização. Nestes padrões devem
estar definidos os processos, as normas de segurança da informação, a disponi-
bilidade e a confiabilidade dos sistemas, entre outros.

1.2  O papel e o perfil do auditor de sistemas

O auditor de sistemas é um verificador do trabalho realizado. É ele quem con-
fronta as medidas obtidas no processo de auditoria com os padrões previamen-
te estabelecidos, a fim de verificar a conformidade daquilo que se tem como
expectativa com aquilo que vem sendo executado no ambiente da organiza-
ção auditada.
O profissional de auditoria atua nas seguintes ações:

É a etapa em que o auditor executa testes a fim de

VALIDAÇÃO validar o processo que foi definido.

O auditor julga a medida adquirida em relação aos

AVALIAÇÃO padrões previamente estabelecidos e emite uma opinião
por meio de relatório de auditoria.

O perfil de um auditor de sistemas deve estar em conformidade ou muito

próximo aos seguintes itens:

•  conhecimento teórico em Sistemas de Informação: conhecer normas e

funcionamento de sistemas computacionais;
•  conhecimento prático em sistemas de informação: conhecer metodolo-
gias de desenvolvimento, boas práticas, problemas comuns, é necessário que
tenha experiência trabalhando diretamente com sistemas;
•  visão abrangente da empresa: conhecer as áreas de atuação, o planeja-
mento estratégico, políticas adotadas em diversas áreas, principalmente no
que se refere aos dados e informações;

capítulo 1 • 13
 •  vestir-se adequadamente: passar a imagem de um profissional de
alto escalão;
•  comportamento de liderança: criar sinergia, não entrar em conflitos, de-
monstrar conhecimento e agregação de valor;
•  utilizar palavreado formal: não utilizar-se de gírias e linguajar exagerada-
mente coloquial, a fim de transparecer confiança e segurança;
•  não aceitar presentes: o auditor não deve aceitar qualquer tipo de agrado
para passar a imagem de isenção e ética.

1.3  A carreira do auditor de sistemas

Ser um auditor de sistemas não significa que o profissional não necessite da
qualificação que o designa auditor, além dos conhecimentos específicos em
sistemas de informação e computação (GIL, 2000).
A carreira do auditor de sistemas passa por uma certificação, que pode ser
emitida por três instituições:

•  ISACA: Certified Information System Auditor (CISA);

•  British Computer Society: Exame da Sociedade Britânica de Informática;
•  Institute of Internal Auditors (IIA): Qualificação em Auditoria
Computacional.

Ao adquirir uma destas certificações, o profissional torna-se habilitado a

executar auditorias em sistemas.

CONEXÃO
O ISACA é uma associação internacional de profissionais de governança de TI. O site do
ISACA mantém várias informações e calendário de eventos da área. http://www.isaca.org

Existem basicamente dois tipos de auditoria: a auditoria interna e a externa.

Na auditoria interna, a organização tem em seu quadro de colaborado-
res uma equipe de profissionais qualificados e habilitados em auditoria de

14 • capítulo 1
sistemas, que são treinados especificamente para as necessidades e os objeti-
vos de segurança da própria organização.
Auditoria externa é a contratação de uma empresa especializada que presta
serviços de auditoria. A equipe desta empresa contratada irá atuar sob deman-
da na organização.
O programa de desenvolvimento da carreira de auditor de sistemas pode ser
dividida em duas diferentes necessidades.
A primeira é quando o auditor tem pouca ou nenhuma experiência na área
de TI. Neste caso, os profissionais devem se especializar nas seguintes áreas:
•  conceitos de TI;
•  tabelas de decisões aplicadas em linguagens de programação;
•  aquisição de equipamentos (hardware);
•  aquisição de programas de computador (software);
•  metodologias e normas para desenvolvimento de soluções tecnológicas;
•  controles de acesso;
•  operação e manutenção de sistemas;
•  fundamentos de arquitetura de sistemas;
•  entrada e saída de dados;
•  redes de computadores (internet, intranet e extranet);
•  programação de computadores;
•  modelagem de sistemas;
•  sistemas gerenciadores de bancos de dados;
•  processamento lógico;
•  unidades de memória (auxiliar e principal);
•  estudos de caso que exemplifiquem cada situação (jogos de negócio).

Para o profissional que tem conhecimento na área de TI, o treinamento

deve ser direcionado para os seguintes objetivos:
•  auditoria de sistemas aplicativos;
•  princípios de práticas de auditoria, enfatizando os controles organizacio-
nais e gerenciais;
•  monitoramento;
•  emissão de relatórios;
•  gerenciamento de riscos;
•  políticas de segurança da informação;

capítulo 1 • 15
 •  avaliação dos sistemas on-line;
•  processamento em tempo real;
•  identificação de programas;
•  verificação das autenticações e autorizações;
•  registros das transações;
•  detecção e manutenção de diários das operações.
•  softwares de auditoria;
•  controles de acesso aos dados e programas;
•  propriedade intelectual;
•  plano de contingência.

O auditor de sistemas deve também possuir uma biblioteca de consulta.

Esta biblioteca deve conter informações pertinentes à área de TI da organiza-
ção, documentos e informações sobre auditorias passadas.
É também de suma importância manter uma biblioteca técnica para con-
sulta sobre conceitos tecnológicos e de auditoria, assim como manter-se atua-
lizado em relação a novas tecnologias que surgem no mercado.

1.4  A auditoria de sistemas nas organizações

A equipe de auditoria de sistemas deve ter autonomia para execução do traba-
lho nas organizações. O acesso aos dados, softwares e computadores deve ser
permitido para que o auditor possa colher informações suficientes, executar os
testes e colher medidas, para posteriormente comparar estas medidas com os
padrões adotados pela organização.
Para que isso ocorra, é necessário que a equipe de auditoria seja diretamen-
te ligada à presidência da organização, não podendo esta equipe estar subor-
dinada aos departamentos a serem auditas, garantindo assim a isenção dela
diante do órgão auditado. A figura 1.2 mostra um exemplo de organograma em
que a equipe de auditoria está diretamente ligada e subordinada apenas à pre-
sidência da organização (GIL, 2000).

16 • capítulo 1
 Presidência

Auditoria de
Sistemas

Diretoria Diretoria Diretoria Diretoria de

Administrativa Financeira de Vendas Informática

Figura 1.2  –  Organograma considerando a auditoria de sistemas (GIL, 2000).

Obedecendo a esta estrutura organizacional, o auditor tem liberdade e aces-

so às informações para trabalhar e apontar as distorções visando a melhorar os
processos da organização.
A equipe de auditoria de sistemas pode esbarrar em algumas dificuldades
para que o trabalho possa ser bem executado. As principais dificuldades encon-
tradas pela auditoria de sistemas, indentificadas por Benetti (2015), são:
•  defasagem tecnológica;
•  falta de bons profissionais;
•  falta de cultura da empresa;
•  tecnologia variada e abrangente.

As áreas de auditoria de sistemas são basicamente as seguintes: segurança

da informação, TI e Aplicativos. Não há uma regra fixa para determinar como
as organizações devem classificar sua área de auditoria; isto fica a critério da
própria organização.
Na área de segurança da informação, é necessário avaliar a conformidade
com as políticas de segurança da organização, efetuar controles ambientais e
plano de contingência e continuidade dos serviços.
Os controles de segurança da informação a serem implantados são:

capítulo 1 • 17
 •  confidencialidade: controles de acesso (físico e lógico);
•  integridade: gravação e atualização autorizadas (mantém-se um respon-
sável pela informação);
•  disponibilidade: sistema disponível sempre que necessário;
•  consistência: sistema funcionando dentro dos requisitos especificados;
•  confiabilidade: sistema atua conforme esperado.

Na área de tecnologia da informação, o auditor deve manter conhecimento

sobre as mudanças organizacionais, operações de sistemas, hardware, com-
putação em nuvem (Cloud Computing), sistemas ERP (Enterprise Resource
Planning), data warehousing, entre outras. É desejável também que o auditor
desta área tenha certificações (ITIL, Cobit, entre outras) a fim de agregar valor
à enrega do serviço,
A área de aplicativos controla o desenvolvimento de software, a entra-
da, o processamento e a saída dos dados, o conteúdo e o funcionamento dos
aplicativos.

1.5  Abordagens de auditoria de sistemas

Existem três tipos de abordagem de auditoria de sistemas. Estas abordagens
levam em consideração o uso do computador para a execução da tarefa de au-
ditoria. São elas: abordagem ao redor do computador, abordagem através do
computador e abordagem com o computador. Cada uma destas abordagens é
descrita a seguir.

1.5.1  Abordagem ao redor do computador

Esta abordagem é considerada mais antiga. Muitos métodos utilizados nesta

abordagem são considerados obsoletos. O computador não é utilizado de ne-
nhuma forma nesta abordagem. São algumas características da abordagem ao
redor do computador:
•  uso de rotinas manuais;
•  mais utilizada no passado (obsoleta);
•  não exige muito conhecimento de TI;
•  análise de entrada e saída de documentos fonte;

18 • capítulo 1
 Apesar de ser uma abordagem por muitos considerada obsoleta, ainda é viá-
vel que se aplique a sistemas menores e pouco complexos.
Os baixos custos e a facilidade de se mensurá-los pode ser considerada
uma vantagem, além de não exigir conhecimentos avançados de tecnologia
da informação.
Algumas desvantagens também podem ser citadas, como a dificuldade de
se avaliar o resultado da auditoria pela falta de padronização, a não necessi-
dade de conhecimentos em tecnologia da informação podem comprometer o
resultado final e também a reavaliação quando uma alteração é feita no siste-
ma, o relatório da auditoria pode ser distorcido por não abranger o computador
como unidade de processamento lógico.

1.5.2  Abordagem através do computador

Ao utilizar esta abordagem de auditoria, o audito utiliza o computador como

ferramenta para a execução dos trabalhos, podendo assim o auditor verificar
com maior frequência as áreas que necessitam de monitoria constante.
Esta abordagem é uma melhoria da anterior (ao redor do computador), pois
uma pessoa poderia requisitar de diferentes maneiras a verificação dos docu-
mentos-fonte. Além de poder utilizar o computador para auditar a si próprio
e a entrada e saída de dados. Utilizando-se do test data (técnica aplicada em
auditoria de sistemas), pode-se simular todas as transações possíveis, fazendo
assim com que o teste seja mais completo e abranja todas as possibilidades
(IMONIANA, 2008).
Além das vantagens já citadas, pode-se destacar a maior confiabilidade nas
medidas em relação à abordagem ao redor do computador.
Como desvantagens do uso desta abordagem, destacam-se: maior custo
em relação à abordagem ao redor do computador (necessita de treinamento de
auditores na área de TI), pode-se necessitar de técnicas manuais para comple-
mentar o papel dos softwares, se as operações forem programadas incorreta-
mente, as perdas podem ser incalculáveis (IMONIANA, 2008).

1.5.3  Abordagem com o computador

Buscando a maior perfeição possível no processo de auditoria, esta abordagem

é completamente assistida por computador. Foi introduzida pelo fato de que as

capítulo 1 • 19
abordagens ao redor do computador e através do computador são suscetíveis a
erros de cálculos e produção incompleta de registros.
Os principais objetivos da abordagem com o computador são:

•  a utilização do computador para efetuar cálculos aritméticos e lógicos,

obtendo assim a exatidão nas contas que se referem a impostos, depreciação
de bens, taxas etc.
•  efetuar cálculos estatísticos e de geração de amostras para facili-
tar confirmações;
•  fazer uma compilação dos resultados de processos automatizados
e manuais;
•  capacidade de ordenar e selecionar os registros, efetuando varredura da
base de dados e utilizando apenas as informações que são pertinentes;
•  desenvolvimento de programas específicos para serem usados pela equi-
pe de auditoria, se necessário;
•  utilização de técnicas de auditoria assistidas por computador (TAAC), ou
em inglês CAAT (Computer Assisted Audit Techniques).

1.6  Padrões e código de ética

Algumas associações procuram apresentar regras para exercício da profissão
de auditor de sistemas, visando reduzir a falta de padronização destes termos.
O comitê de padrões da Associação de Controle e Auditoria de Tecnologia
de Informação dos Estados Unidos define os seguintes padrões:

•  responsabilidade, autoridade e prestação de contas;

•  independência profissional;
•  ética profissional e padrões;
•  competência;
•  planejamento;
•  emissão de relatório;
•  atividades de follow-up (acompanhamento).

20 • capítulo 1
 Já a Associação de Auditores de Sistemas & Controles (ISACA) define o códi-
go de ética profissional contendo os seguintes itens:
1. apoiar a implementação de padrões sugeridos para procedimentos e
controles dos sistemas de informação e encorajar seu cumprimento;
2. exercer suas funções com objetividade e zelo profissional, seguindo pa-
drões profissionais e melhores práticas;
3. servir aos interesses dos stakeholders de forma legal e honesta, com
alto padrão de conduta e caráter profissional e desencorajar atos de descrédito
à profissão;
4. manter a privacidade e a confidencialidade das informações obtidas,
exceto quando exigido legalmente. Estas informações não devem ser utilizadas
em benefício próprio ou compartilhadas com pessoas não autorizadas;
5. manter competência na sua especialidade e assegurar que somente
atua nas atividades em que tem habilidade suficiente;
6. informar os stakeholders sobre os resultados de seus trabalhos, expon-
do os fatos significativos desde que em seu alcance; e
7. apoiar a conscientização profissional das partes envolvidas para auxi-
liar sua compreensão dos sistemas de informação, segurança e controle.

1.7  Planos de contingência

Primeiramente, é importante o entendimento do que é contingência. Uma con-
tingência é um evento que pode ou não acontecer. O auditor deve se preocupar
com os eventos (contingências) que podem trazer danos à organização, como
por exemplo:
•  um equipamento que para de funcionar;
•  um funcionário que adoece;
•  um incêndio;
•  a indisponibilidade de sistema;
•  queda de energia elétrica, entre outros.

Na ocorrência de uma contingência, é importante a organização estar

preparada para tomar medidas com o intuito de sanar ou minimizar os da-
nos causados.

capítulo 1 • 21
1.7.1  O que é plano de contingência

Um plano de contingência e recuperação de desastres é uma sequência de ações

predeterminadas que devem ser seguidas na ocorrência de uma emergência, a
fim de estabelecer a continuidade do serviço, em caso de indisponibilidade.
O plano não contempla apenas os serviços de informática e sua disponibili-
dade. Os impactos que a emergência pode causar para a segurança das pessoas,
danos ambientais e até mesmo o desgaste da imagem da organização em rela-
ção aos clientes e fornecedores devem ser considerados no momento da elabo-
ração do plano de contingência, para que os danos causados com a ocorrência
sejam os menores possíveis.
No âmbito empresarial, a responsabilidade pelos planos de contingência
pode variar, dependendo do tamanho da empresa e da importância que é dada
para a disponibilidade dos serviços de TI.
A ocorrência de uma catástrofe é rara, porém suas consequências podem
ser devastadoras. Portanto, um plano de contingência é necessário para reduzir
a possibilidade de danos à organização, reduzir a descontinuidade de rotinas,
a fim de manter o fluxo do negócio em seu curso normal, e reduzir os custos de
recuperação, que geralmente são elevados.
As diferentes áreas da organização devem ser coordenadas na elaboração
de um plano de contingência, apesar de terem seus próprios planos de forma
independente. Esta coordenação é importante para o gerenciamento das áreas
que são vitais para o bom funcionamento da organização.

1.7.2  Riscos e Ameaças

A ameaça é um evento ou uma atitude indesejável que pode danificar um recur-

so. Como exemplos de ameaça temos:
•  roubo;
•  incêndio;
•  vírus;
•  queda de energia elétrica.

22 • capítulo 1
 As ameaças podem ser acidentais, como uma falha de hardware ou uma
descarga atmosférica (raio), ou ameaças deliberadas, como uma invasão ou um
assalto. As ameaças deliberadas são divididas em passivas e ativas. As ameças
passivas não alteram a informação da organização, enquanto as ameaças ativas
são aquelas que alteram a informação armazenada, portanto, são mais perigo-
sas e de difícil recuperação.
Os componentes da TI (recursos) que podem ser danificados quando da
ocorrência de uma ameaça podem ser:
•  físico: uma sala de computadores;
•  software: vírus de computador;
•  hardware: uma descarga atmosférica que queima um equipamento;
•  informação: roubo de informações;
•  pessoas: vírus biológico.

As vulnerabilidades são as fraquezas ou deficiências que, quando explora-

das, podem potencializar os danos causados ou aumentar a probabilidade de
ocorrência de uma ameaça.
Um bom exemplo de exploração de vulnerabilidades são os hackers ou
crackers, que buscam por essas vulnerabilidades para conseguir uma invasão
com fins de roubo de informação ou indisponibilidade do serviço.
A probabilidade de ocorrência de uma ameaça precisa ser estudada e anali-
sada para que se possa ponderar sobre o desenvolvimento de planos de contin-
gência, torná-los mais efetivos e conhecidos no âmbito organizacional.
A concretização de uma ameaça é chamada de ataque. Na ocorrência
de um ataque, recorre-se ao plano de recuperação de desastres ou plano
de contingência.
O impacto é o resultado da concretização de uma ameaça, ou seja, o impac-
to causado pelo ataque. Este impacto pode ser direto ou indireto. O impacto di-
reto envolve prejuízos financeiros, enquanto o impacto indireto envolve perda
de credibilidade com clientes e fornecedores, passando para o mercado uma
imagem de que não é preocupada com segurança da informação, de que não
se importa o suficiente com o negócio do cliente, entre outros prejuízos de or-
dem indireta.

capítulo 1 • 23
 A figura 1.3 exibe um esquema em que se pode observar todo o proceso de
recuperação de desastres.

Protegem Ativos Sujeitos

Medidas de
Vulnerabilidade
Segurança

Limitados RISCO Permitem

Impactos Ameaças

Confidencialidade
Causam Integridade Perdas
Disponibilidade

Figura 1.3  –  Processos considerados para avaliação de riscos (WebAula - Estácio).

Ainda observando a figura 1.3, pode-se concluir que todas as etapas devem
ser utilizadas para que se possa analisar o risco de forma coerente. Iniciando
a análise pelos ativos, estes estão sujeitos a vulnerabilidades. Ao serem explo-
radas, as vulnerabilidades permitem que ameaças possam ser detectadas. Na
ocorrência de uma ameaça, a organização sofre perdas que podem ser de dife-
rentes tipos; são alguns deles:
•  perda de confidencialidade: roubo de informações;
•  perda de integridade: alteração na informação;
•  perda de disponibilidade: ataques de negação de serviço, em que se pode
sobrecarregar um servidor até que ele pare de responder adequadamente.

Essas perdas causam impactos negativos na organização, como baixo fa-

turamento, diminuição na produção, entre outros. Para que os impactos se-
jam minimizados ou limitados, há as medidas de segurança. Estas medidas

24 • capítulo 1
normalmente são os planos de contingência que são executados a fim de prote-
ger os ativos da organização.
A criação do plano de contingência não é um processo barato, pois o mes-
mo deve ser elaborado, implementado e testado. É possível que se necessite
do desenvolvimento de programas ou processos específicos para que se possa
atender de forma satisfatória a ocorrência de uma emergência. Portanto, in-
vestimentos em pessoal qualificado, tecnologias, aplicativos, entre outros são
vitais para um bom plano de contingência.
Por razões de alto custo, não se recomenda o desenvolvimento de planos
de contingência para todas as funções da empresa, apenas para as mais vitais e
com maior risco de ocorrência, é preciso priorizar certas áreas.
A identificação das partes críticas, que demandam a criação de um plano de
contingência, é um papel analítico em que se consideram a probabilidade de
ocorrência e a profundidade dos danos que podem ser causados por uma ameaça.
No processo de identificação das áreas críticas da organização, tem-se o en-
volvimento de:
•  sistemas: em que são identificadas as funções críticas de um determina-
do sistema;
•  tecnologia da Informação: em que são identificados quais são os sistemas
críticos da organização;
•  departamento: identificar as áreas críticas de uma organização ou de uma
determinada área ou departamento que é parte da organização.

Para a análise de impacto e cálculo de riscos, um esquema separado em três

etapas é adotado, conforme exibido na figura 1.4.

Riscos Prioridades Escore

Figura 1.4  –  Etapas para seleção de áreas que adotarão planos de contingência.

Na etapa de riscos, é comum utilizar-se da técnica de brainstorming, em

que se elenca todo e qualquer risco que pode ser encontrado no âmbito da or-
ganização. Na etapa de prioridades, elencam-se aqueles riscos que merecem

capítulo 1 • 25
mais atenção, que podem trazer maiores danos e que têm maior probabilidade
de ocorrência (probabilidade e impacto na organização). Na terceira etapa (es-
core), é feita uma escolha de quais dos riscos selecionados como prioritários
terão o plano de contingência efetivamente desenvolvido.

ATENÇÃO
Devido ao alto custo de implantação dos planos de contingência, é recomendado que se
escolha aplicá-los apenas às áreas e processos mais críticos da organização.

Para o cálculo de prioridades e auxílio na tomada de decisão sobre quais

ameaças merecem o desenvolvimento de um plano de contingência, há duas
tabelas de classificação. A tabela 1.1 versa sobre a classificação do impacto que
pode ser causado pela ameaça. Em uma escala de 0 a 5, em que 0 é o menor im-
pacto e 5 é o impacto mais desastroso para a organização.

ESCALA CLASSIFICAÇÃO DO IMPACTO

0 Impacto irrelevante.

Efeito pouco significativo, sem afetar a maioria dos processos da

1 empresa.

Sistemas indisponíveis por um determinado período de tempo, poden-

2 do causar perda de credibilidade e também perdas financeiras.

Perdas financeiras mais significativas e perda de clientes para

3 concorrentes.

Efeitos desastrosos, mas que não comprometam a sobrevivência da

4 organização.

26 • capítulo 1
 ESCALA CLASSIFICAÇÃO DO IMPACTO

Efeitos desastrosos que comprometam a sobrevivência da

5 organização.

Tabela 1.1  –  Tabela de classificação de impacto da ameaça.

Além da tabela de classificação de impacto, tem-se a tabela 1.2, que auxi-

lia no cálculo da probabilidade de ocorrência de uma ameaça. A escala tam-
bém varia de 0 a 5, em que 0 significa menor probabilidade de ocorrência e 5, a
maior probabilidade de ocorrência possível.

ESCALA CLASSIFICAÇÃO DE PROBABILIDADE

0 Ameaça completamente improvável de acontecer.

Probabilidade de a ameaça ocorrer menos de uma vez

1 por ano.

Probabilidade de a ameaça ocorrer pelo menos uma vez

2 por ano.

Probabilidade de a ameaça ocorrer pelo menos uma vez

3 por mês.

Probabilidade de a ameaça ocorrer pelo menos uma vez

4 por semana.

5 Probabilidade de a ameaça ocorrer diariamente.

Tabela 1.2  –  Tabela de classificação da probabilidade de que a ameaça ocorra.

capítulo 1 • 27
 Após a classificação das ameaças utilizando as escalas da tabela, os resulta-
dos são inseridos em uma matriz de riscos. A tabela 1.3 mostra um exemplo de
classificação de ameaças considerando as análises feitas por meio das tabela
1.1 e 1.2.
A coluna de escore de risco é calculada multiplicando-se o valor da análise
de impacto com o valor da análise de probabilidade. Este valor do escore de ris-
co é considerado no momento em que se decide o desenvolvimento ou não de
um plano de contingência para a ameaça detectada.

MATRIZ DE RISCO

ESCORE DE
AMEAÇAS IMPACTO PROBABILIDADE RISCO

Incêndio 5 1 5

Falta de energia
4 3 12
elétrica

Indisponibilidade
3 3 9
de servidor

Greve de
funcionários do 2 1 2
transporte

Funcionário que
1 1 1
adoece

Falha de switch
2 4 8
de rede

28 • capítulo 1
 MATRIZ DE RISCO

ESCORE DE
AMEAÇAS IMPACTO PROBABILIDADE RISCO

Ataque de vírus 3 5 15

Tabela 1.3  –  Matriz de risco que auxilia a definição dos planos de contingência que se-
rão desenvolvidos.

Para a criação do plano de contingência, deve-se também adotar uma es-

tratégia. Esta estratégia parte da tentativa de eliminar o risco. Quando não é
possível eliminar completamente o risco, parte-se para a estratégia de redução
do risco a um nível aceitável. Se esta segunda estratégia não é viável, tenta-se
limitar o dano causado pela ameaça, reduzindo assim o impacto desta ocorrên-
cia na organização. Por último, procura-se compensar o dano causado, como
por exemplo, contratar seguros.
Para definir responsabilidades em um plano de contingência, Imoniana
(2008) traz uma tabela chamada de matriz de responsabilidades. Nesta matriz
constam o nome da pessoa, o item no qual esta pessoa é responsável, a auto-
ridade delegada, ou seja, a função desta pessoa na organização, e os contatos.

EXEMPLO
Segue um exemplo de matriz de responsabilidades:

NOME RESPONSABILIDADE AUTORIDADE DELEGADA TELEFONES DE CONTATO

William Gates Controle da rede Analista de redes 3133-5515

Administrador de ban-
Steve Jobs Controle de dados 4141-5544
cos de dados

Transporte e realoca-
Larry Page Analista de sistemas 3544-4435
ção de pessoas

capítulo 1 • 29
1.7.3  Componentes de um plano de contingência

O termo plano de contingência é abrangente. Este plano pode ser de três tipos:
•  plano de emergência;
•  plano de backup;
•  plano de recuperação.

O plano de emergência é formado pelas respostas de risco, como exibido

nas tabelas 1.1, 1.2 e 1.3 e baseado em tentativas de evitar danos causados por
desastres, mantendo desta maneira a organização em funcionamento estável.
Os principais objetivos do plano de emergência são:
•  prever as possibilidades de desastres, sejam eles naturais ou provocados;
•  prover os meios necessários para que se possa detectar antecipadamente
e com isto buscar evitar ou ao menos preparar melhor a organização para os
danos causados pela ocorrência;
•  prover segurança física em caso de fogo, fumaça, água, intrusos.
•  prover as respostas de risco (planos de ação) para as ameaças com alto ín-
dice de escore de risco, calculadas a partir do uso da matriz de risco (ver tabela
1.3).

O plano de emergência deve conter um checklist, isto é, uma lista com um

conjunto de ações a serem tomadas no caso de uma ocorrência. Segue abaixo
um exemplo de checklist no caso de um incêndio:
•  quem decide quando e como o local será evacuado;
•  quais as proteções para as pessoas e recursos da organização;
•  definir qual o tipo de extintor de incêndio deve ser utilizado;
•  pessoa responsável por alertar o corpo de bombeiros;
•  pessoa responsável por desligar a rede elétrica;
•  definição de um local alternativo para trabalhar até a recuperação da
área danificada.

No plano de emergência é necessário manter o pessoal envolvido em alerta.

A participação da CIPA (Comissão Interna de Prevenção de Acidentes) também
é importante.
Após o plano de emergência ser testado e aprovado, pode ser utilizado (en-
trar em ação) no caso de ocorrência da ameaça.

30 • capítulo 1
 É de suma importância que o plano de emergência siga um calendário
de testes, com o objetivo de treinamento, comprometimento e atualização
do plano.
No plano de backup, o principal objetivo é manter informações que possam
ser utilizadas no caso de um plano de emergência vir a ser utilizado. O plano de
backup provê:
•  backup de arquivos e dados;
•  processamento alternativo;
•  continuidade dos serviços;
•  atualização da biblioteca externa: em caso de emergência, é necessário
que se tenha redundância de informação e recursos em local afastado do local
principal de trabalho, a fim de que se possa utilizar esta informação em caso de
emergência que danifique as informações e os recursos armazenadas no local
principal de trabalho.
•  acordo de reciprocidade com terceiros: acordos feitos com outras empre-
sas a fim de que, em caso de emergência em uma delas, os recursos da outra
podem ser utilizados ou emprestados até que a empresa se recupere dos da-
nos causados.
Deve-se atentar, em um plano de backup, para os seguintes itens:

•  interrupções que possam causar grandes perdas;

•  tempo máximo tolerado para uma indisponibilidade;
•  recursos e ambientes alternativos para que se possa manter o funciona-
mento e a disponibilidade dos serviços;
•  treinamento da equipe;
•  criação de calendário para testes do plano;
•  avaliar os resultados dos testes;
•  manter o plano atualizado;
•  fazer divulgação do plano, para que os envolvidos tenham conhecimento
da existência e do funcionamento do plano.

CURIOSIDADE
No dia 11 de setembro de 2001 houve o ataque às torres gêmeas nos Estados Unidos. Além
das mortes causadas e da queda dos prédios, muitas empresas deixaram de existir a partir
daquele momento, pois o backup dos dados de algumas empresas da torre um estava na tor-

capítulo 1 • 31
re dois, e vice-versa. Sendo assim, algumas empresas perderam seus dados e informações
por completo.
Esta história trágica atenta para a importância de manutenção do backup em local fisica-
mente afastado, mantendo uma distância segura que é definida pela empresa.

O plano de recuperação descreve as atividades e recursos que são necessá-

rios para que se possa passar da situação de emergência para a situação normal.
O estado de emergência ocorre sempre que um plano de emergência entra
em ação. Os riscos e os danos causados pela ocorrência devem ser controla-
dos para que a organização entre em seu estado normal de funcionamento. As
medidas para a recuperação, neste caso, definidas no plano de recuperação,
devem ser seguidas para que o retorno ao estado de normalidade seja o mais
rápido possível.

EXEMPLO
Em um caso de emergência por dano a um equipamento de rede (switch por exemplo) cau-
sado por uma descarga atmosférica (raio), pode estar descrito no plano de recuperação a
maneira mais eficiente e rápida de se restabelecer o funcionamento, seja consertando ou
adquirindo e configurando um novo equipamento.

A figura 1.5 esquematiza o processo que é executado ao acionar o plano de

recuperação, este que faz parte do plano de contingência.

Ocorre uma
Estado interrupção Estado de
Normal Emergência

Executa-se o plano de recuperação

Figura 1.5  –  Ativação do plano de recuperação.

32 • capítulo 1
 Em conclusão: a união dos planos de emergência, de backup e de recupera-
ção formam o plano de contingência como um todo, que para o bom funciona-
mento dos processos da organização, deve ser desenvolvido e implantado para
as operações que podem trazer maiores danos, dependendo do foco de atuação
e da necessidade da própria organização.

ATIVIDADE
A auditoria de sistemas é de vital importância para o bom andamento dos processos organi-
zacionais. Alguns tipos de empresas podem ter perdas financeiras significativas na ocorrên-
cia de ameaças que parecem não ser tão graves.
Defina qual a importância da disponibilidade de serviços de TI em uma empresa de ven-
das pela internet. Dê um exemplo de ameaça com alto escore de risco para empresas des-
te tipo.

REFLEXÃO
Neste capítulo foram estudados os fundamentos de auditoria, sua importância no âmbito
organizacional e quais os principais aspectos da auditoria de sistemas.
O perfil do auditor, informações sobre a carreira e o código de ética também são de
fundamental importância para o desenvolvimento de um auditor de sistemas de sucesso.
Os planos de contingência, estudados também neste capítulo, mostram como uma or-
ganização pode se preparar de forma adequada para a ocorrência de ataques ou desastres.
Este tema é de suma importância para que os serviços de TI e a segurança da informação e
das pessoas sejam garantidos na organização.

LEITURA
Para o aprofundamento dos conhecimentos em fundamentos de auditoria, uma leitura inte-
ressante pode ser o livro do Marcelo Cavalcanti Almeida, denominado Auditoria: Um curso
Moderno e Completo.
ALMEIDA, Marcelo Cavalcanti. Auditoria: um curso moderno e completo. 6. ed. São Paulo: Atlas,
2003. 589 p.

capítulo 1 • 33
 REFERÊNCIAS BIBLIOGRÁFICAS
BENETTI, Marcos Antonio. Segurança e Auditoria de Sistemas. Disponível em: <http://www.
benetti.eti.br/home/informatica/auditoria>. Acesso em: 15 ago. 2015.
GIL, Antonio de Loureiro. Auditoria de computadores. 5. ed. São Paulo: Atlas, 2000. 236 p.
IMONIANA, Joshua Onome. Auditoria de Sistemas de Informação. 2. ed. São Paulo: Atlas, 2008.
207 p.

34 • capítulo 1
 2
O Funcionamento,
os Controles
Internos e as
Ferramentas da
Auditoria
A segurança da informação nas organizações é de vital importância para seu
potencial competitivo no mercado. A utilização de controles internos dá-se
como uma das mais importantes ações que buscam garantir a segurança e evi-
tar fraudes em uma empresa. A auditoria de sistemas, quando executada de for-
ma correta, traz também muitos benefícios para a organização. Neste capítulo
são apresentadas as ações da auditoria de sistemas, suas quatro fases, a utiliza-
ção de controles internos e ferramentas de software que auxiliam na execução
da auditoria. Ao final do capítulo, é esperado que se desenvolva uma visão sistê-
mica e prática da auditoria.

OBJETIVOS
Os principais objetivos de aprendizado deste capítulo são:
•  Compreensão do dia a dia do auditor de sistemas;
•  Mostrar o que são e quais são os controles internos utilizados em auditoria de sistemas;
•  Apresentar a sequência lógica das fases da auditoria de sistemas e suas ações; e
•  Apresentar as ferramentas de software que auxiliam na auditoria.

36 • capítulo 2
2.1  O funcionamento da auditoria de
sistemas

Como já visto no capítulo anterior, a auditoria visa examinar as operações, os

processos, os sistemas e as responsabilidades gerenciais das organizações. Este
exame é feito para verificar sua conformidade com regras, normas, padrões e
objetivos da organização auditada.
Neste momento, podemos dividir a auditoria de sistemas em três fases. São
elas:
•  planejamento;
•  execução;
•  emissão de relatórios.

Uma quarta fase também é muito importante e será abordada oportunamen-

te: o acompanhamento das mudanças geradas como resultado da auditoria.
Na figura 2.1 é apresentado um diagrama com as funções da auditoria e
como estão interligadas.

Avaliação

Objetivos,
Regras,
Padrões,
Normas
Operações,
Sistemas,
Processos,
Responsabilidades

Auditoria

Figura 2.1  –  Relação entre as funções de uma auditoria de sistemas.

capítulo 2 • 37
 De acordo com a exemplificação na figura 2.1, a auditoria começa com a
checagem das operações, dos sistemas, dos processos e das responsabilidades
gerencias (isto ocorre porque as informações no âmbito organizacional sempre
têm um responsável).
Após estas checagem, ocorre o confronto das medidas obtidas com os obje-
tivos, as regras, os padrões e as normas da organização. Esta comparação se dá
pela verificação de conformidade entre o que é esperado que se ocorra e o que
realmente ocorre (na prática).
Por fim, a etapa de avaliação. Nesta etapa o auditor emite relatórios para
que medidas possam ser tomadas a fim de que as medidas se aproximem dos
padrões previamente estabelecidos.
Existem duas áreas de atuação, chamadas também de áreas de verificação
da auditoria:
•  auditoria de campo;
•  âmbito da auditoria.

A auditoria de campo é referente à natureza da auditoria, isto é, o objeto da

auditoria, como, por exemplo, sistemas de TI.
Outra preocupação da auditoria de campo é o período em que esta auditoria
será executada, isto é, o período em que o objeto da auditoria será avaliado,
testado e medido.
Por fim, a auditoria de campo pode definir qual o objeto da auditoria, como,
por exemplo, segurança da informação.
No âmbito da auditoria é definido qual sua abrangência, ou seja, qual o nível
de detalhamento que será abordado pelos auditores. Define-se também quais
as áreas da organização serão auditadas, até que ponto o auditor fará as verifica-
ções e medidas para após isto, confrontá-las com os padrões pré estabelecidos.
O dia a dia de uma auditoria de sistemas pode ser dividido em 17 ações ou
etapas básicas a serem executadas. São elas:
1. Preparar a análise de risco: definir quais áreas ou objetos são passíveis
de auditoria. Neste caso, fatores ambientais também são levados em considera-
ção. No final desta etapa, tem-se um escore de priorização para que se auditem
as áreas que demandam tal ação.
2. Fazer revisões dos projetos e produtos: são revisões detalhadas dos pro-
cessos da organização com o objetivo de verificar o escore de risco e estabelecer
quais áreas devem ser priorizadas, uma vez que auditar todos os sistemas da
organização é inviável, devido ao custo.

38 • capítulo 2
 3. Familiarizar-se com a área de sistemas: compreender os produtos, ser-
viços e processos da área de TI, adquirir conhecimento sobre o ambiente e os
sistemas que serão auditados por meio de documentação e levantamento.
4. Estabelecer a estratégia: definição das ferramentas (estas ferramen-
tas podem ser softwares) a serem utilizadas, considerando o sistema que
será auditado.
5. Estabelecer os objetivos: definir os controles internos e os proces-
sos, que devem estar sempre alinhados ao negócio e definir também o que
será verificado.
6. Definir preocupações: definir quais os itens que mais preocupam a
equipe de auditoria, ou seja, os itens aos quais os auditores precisam prestar
mais atenção, previamente indicados como necessários.
7. Fazer avaliação preliminar dos controles internos: verificar os controles
que estão implantados no sistema e definir quais controles serão utilizados.
Apenas controles gerais são considerados nesta fase.
8. Finalizar os procedimentos de planejamento: determinar o tempo da
auditoria, qual a equipe de auditores, quais são os recursos necessários e qual a
data provável de emissão do relatório final.
9. Preparar um documento de aviso: normalmente um memorando, assi-
nado pelo diretor da auditoria, deve ser emitido ao gerente da área de sistemas,
ao diretor e ao diretor da área para qual o sistema dá suporte. Este documento
tem objetivos, cronograma e intenções da auditoria que será executada.
10. Reunião inicial: uma reunião inicial deve ser realizada com os audi-
tados, sua gerência e diretoria, informando sobre as intenções da auditoria
e pedindo colaboração para que o fornecimento de informações e acessos
seja garantido.
11. Elaboração de testes: uma massa de testes deve ser elaborada, com de-
finição de escopo de teste, geração de dados de teste e determinação dos resul-
tados que serão esperados.
12. Aplicação dos testes: aplica-se a massa de testes elaborada anterior-
mente e colhem-se os resultados. Estes testes podem ser executados com simu-
lação em laboratório ou em campo. Os testes têm como objetivo a aprovação da
efetividade dos processos e resultados.
13. Análise das simulações: as simulações efetuadas devem ser analisa-
das a fim de se detectar discrepâncias. Em caso positivo, o auditado deve ser
avisado verbalmente e por formulário próprio, emitindo a opinião quanto aos

capítulo 2 • 39
resultados ou do ambiente auditado, com recomendações e solicitação de pra-
zo para correção das falhas encontradas.
14. Emissão de relatório provisório: ao término do trabalho de campo,
deve-se emitir um relatório provisório com todas as falhas encontradas e que
não foram solucionadas durante o período da auditoria. Um carimbo escrito
“RASCUNHO” deve ser utilizado neste relatório para que não se confunda com
o relatório final da auditoria.
15. Discussão de relatório provisório: pode-se utilizar de uma reunião
para a discussão do relatório. Neste momento os auditados e sua gerência
devem concordar ou discordar do relatório provisório por escrito, explicando
os motivos.
16. Emissão e distribuição do relatório final: o relatório final deve conter a
“nota” do relatório, que é a parte do relatório que contém as falhas encontradas
e que não foram solucionadas, além de estabelecer uma data para o acerto das
falhas. Os auditados podem concordar com o relatório ou não. Em caso de ne-
gativa, justificar o motivo por escrito.
17. Follow-up (acompanhamento): acompanhamento das datas de acerto
das falhas indicadas na auditoria e que constam no relatório final.

As 17 ações apresentadas demonstram de maneira organizada o dia a dia do

trabalho da equipe de auditoria, uma vez que para cada ação a ser executada são
necessários conhecimentos e habilidades específicas.

2.2  Controles internos

A implementação de controles internos é uma das medidas de segurança mais
importantes da organização. Imoniana (2008) define que controles internos
em sistemas de informação seguem os conceitos básicos de auditoria, porém
com abordagens modificadas devido ao uso de sistemas informatizados.
Champlain (2003) afirma que muitos problemas de ordem legal enfrentados
pelas organizações ocorrem devido a controles internos mal implementados.

40 • capítulo 2
 DEFINIÇÃO
O Portal da Auditoria (2015) define controle interno como:
“Planejamento organizacional e todos os métodos e procedimentos adotados dentro de
uma empresa, a fim de salvaguardar seus ativos, verificar a adequação e o suporte dos dados
contábeis, promover a eficiência operacional e encorajar a aderência às políticas definidas
pela direção, com o objetivo de evitar FRAUDES, ERROS, INEFICIÊNCIAS e CRISES nas
empresas.”

Os controles internos, segundo Imoniana (2008), têm uma série de princí-

pios e objetivos:

•  supervisão: a gerência deve manter um controle que permita uma super-

visão efetiva no ambiente de TI;
•  registro e comunicação: a gerência deve manter registros de responsabili-
dades e autorização na disseminação, criação e processamento de informações
de dados;
•  segregação das funções: funções incompatíveis devem estar segregadas,
com o objetivo de minimizar a perpetuação de fraudes, erros e falha na opera-
ção normal;
•  classificação de informação: deve ser estabelecido pela gerência um
plano de classificação da informação seguindo as normas e necessidades
da organização;
•  tempestividade: a gerência monitora os registros das transações, proces-
sando-as e comunicando os resultados a quem for necessário em tempo hábil;
•  auditoriabilidade: de acordo com as políticas da organização, os procedi-
mentos operacionais devem permitir a programação e a verificação periódica
em relação à precisão no processamento de dados e emissão de relatórios;
•  controle independente: os sistemas em operação devem ter procedimen-
tos que permitam correções de erro no fluxo de processamento;
•  monitoramento: a gerência deve ter acesso total ao sistema e ao controle
de uso para que possa acompanhar as transações;
•  implantação: planejamento por parte da gerência do desenvolvimento,
manutenção, documentação e aquisição do sistema;

capítulo 2 • 41
 •  contingência: deve-se elaborar plano de controle de prevenção de falhas
nas fases pré e pós implantação do sistema (desenvolvimento e operação);
•  custo efetivo: planejamento dos investimentos em tecnologia
da informação.

CONEXÃO
Com o objetivo de proteger a informação, a norma ISO 27000 Information Security Manage-
ment Systems (Sistemas de Gerenciamento de Segurança da Informação) apresenta seus
critérios no seguinte link: http://www.iso27001security.com/

A implantação de controles varia de acordo com a complexidade da tecno-

logia envolvida. Em ambientes de sistemas computadorizados básicos, pode-se
adotar controles convencionais. Já em ambientes de sistemas computadoriza-
dos mais complexos, controles modernos e computadorizados são mais bem
aceitos e efetivos (IMONIANA, 2008).
As organizações devem, segundo Champlain (2003), implementar controles
internos para que os riscos possam ser gerenciados de maneira viável. Os prin-
cipais tipos de controles internos que são passíveis de auditoria de sistemas são
os seguintes:
1. Integridade de dados e processos: trata do acesso aos dados, da confi-
dencialidade, dos controles de arquivos e tabelas e dos controles de mudanças
no sistema.
2. Segurança de sistemas: trata da segurança do acesso físico e lógico ao
sistema, segurança do banco de dados, uso de criptografia e assinatura digital.
3. Legibilidade operacional: plano de recuperação de desastres, plano de
backup, plano de contingência, treinamento de pessoal, documentação, de-
sempenho e capacitação.
4. Conformidade: trata de aspectos legais, da política da organização, dos
padrões e normas estabelecidos pela organização e por órgãos competentes, se
cumpre normas regulatórias e se tem seguro.
5. Guarda de registros: trata dos logs do sistema, da retenção de arquivos
e do registro de tudo aquilo que ocorre no âmbito de TI, para que se possa ave-
riguar posteriormente.
6. Guarda de ativos: trata do inventário da organização.

42 • capítulo 2
 7. Programas de sistemas: manter o monitoramento dos programas e sis-
temas operacionais.
8. Organização e administração: trata da segregação de funções (verifica
se as funções estão sendo corretamente executadas), da organização dos proje-
tos, verificação se normas de gerenciamento de projeto são aplicadas, se existe
PMO (Project Management Office).
9. Processo de desenvolvimento: trata do desenvolvimento de software.
Estes controles visam checar se o processo de desenvolvimento está utilizan-
do de padrões e procedimentos corretos, se o software está sendo devidamente
documentado, entre outros fatores relacionados ao processo de desenvolvi-
mento, inclusive a respeito do treinamento de pessoal e de testes unitários e
de integração.
10. Ambiente da TI: trata da segurança física e lógica do ambiente, das
bibliotecas da organização. Pode englobar a utilização do ITIL (Information
Technology Infrastructure Library).
11. Contrato de serviços: os serviços contratados pela organização também
são objetos da auditoria.
12. Procedimentos e padrões: as definições feitas pela organização de-
vem ser cumpridas no âmbito da TI, portanto, esta checagem também e alvo
da auditoria.

CONEXÃO
O ITIL (Information Technology Infrastructure Library) é um documento que reúne um conjunto
de boas práticas de gerenciamento de serviços de TI. Mais informações podem ser obtidas
acessando o site oficial odo ITIL na internet: http://www.itil-officialsite.com/

2.3  Fases de uma auditoria de sistemas

A divisão da auditoria de sistemas em três fases dá-se até o momento da emis-
são de relatórios. Após isto, existe uma quarta fase, chamada de follow-up, que
seria o acompanhamento da auditoria após a emissão do relatório final. A figu-
ra 2.2 exibe as quatro fases da auditoria em sua sequência lógica.

capítulo 2 • 43
 Emissão
Planejamento Execução Follow-up
de Relatórios

Figura 2.2  –  As quatro fases da auditoria de sistemas.

A auditoria deve ser tratada como um projeto, portanto, necessitando de

um planejamento prévio para que a execução se dê de forma organizada. Desta
forma, a auditoria, como um projeto, tem datas de início e término definidas.

2.3.1  Fase de planejamento

A primeira etapa da fase de planejamento é definir qual o tipo de auditoria que

será executado. No caso de auditoria de sistemas, segue-se um escore de risco
para definir qual área ou sistema é mais crítico e, assim, mais propício para que
seja auditado.
O método de ponderação utilizado para definição do escore de risco é uma
definição de pesos e medidas que, depois de definidos, resultam em um nú-
mero (escore) que, dentro de uma avaliação posterior, define se o sistema é de
baixa ou alta prioridade para ser indicado a uma auditoria.
Os dados a serem analisados no método de ponderação são:
•  custo do sistema;
•  valor diário das transações;
•  volume diário das transações;
•  visibilidade do cliente;
•  impacto;
•  extensão do sistema;
•  capacitação da equipe.

44 • capítulo 2
 Estes dados recebem, cada um, um valor numérico de peso, este definido
pela organização. Os sistemas mais críticos ou importantes, na visão da organi-
zação, recebem valores maiores de pesos.
O planejamento da auditoria visa a atribuir, a cada um dos dados citados,
uma nota, também um valor numérico, variando de 0 a 10. Esta nota, atribuída
pela equipe que planeja a auditoria, é multiplicada pelo valor de peso atribuído
pela organização, gerando um valor total para cada um dos itens abordados.
Ao final da análise, os totais são somados, e o valor do escore de risco do
sistema que está sendo avaliado é obtido.
Para a avaliação final do sistema, o valor de escore obtido é comparado a uma
tabela de faixas de valores; para cada uma delas, uma prioridade é atribuída.

EXEMPLO
Segue um exemplo de avaliação e obtenção de escore de risco de um sistema:

ITEM PESO NOTA TOTAL

Custo do sistema 15 6 90
Valor diário das
15 9 135
transações
Volume diário das
10 8 80
transações
Visibilidade do cliente 10 10 100
Impacto 15 9 135
Extensão do sistema 10 6 60
Capacitação da equipe 10 8 80

A coluna dos totais é somada, resultando em um escore de risco de 680.

Na tabela abaixo tem-se as faixas de prioridade.

ESCORE DE RISCO PRIORIDADE

até 200 Baixa
de 201 a 300 Média
de 301 a 500 Alta
acima de 500 Muto alta

Portanto, o sistema avaliado tem prioridade muito alta (escore de risco acima de 500)
para que seja auditado; neste caso, muito provavelmente este sistema entrará no planeja-
mento da auditoria.

capítulo 2 • 45
 Após a escolha do sistema a ser auditado, deve-se obter conhecimento estu-
dando-se com profundidade seu funcionamento e seus detalhes.
Com o conhecimento adquirido sobre o sistema a ser auditado, é necessá-
rio que se decida sobre os controles internos, os processos e os controles de
negócio que serão utilizados na auditoria. Define-se também no planejamento
a amplitude e o grau de abrangência da auditoria, isto é, qual o nível de detalhe
em que o sistema será testado.
Cada ponto a ser auditado é chamado de ponto de controle. Caso um ponto
de controle apresente falhas durante a auditoria, deve-se informar ao auditado
para que elas sejam corrigidas.
O cronograma da auditoria deve ser definido também na fase de planeja-
mento, com data de início, datas das diversas etapas e ações da auditoria e a
data de emissão do relatório final. Este cronograma considera a complexidade
e tempo estimado para a verificação de cada ponto de controle da auditoria.

2.3.2  Fase de execução

Assim que a fase de planejamento é encerrada, inicia-se o processo de execução

da auditoria propriamente dita.
Benetti (2015) divide a auditoria de sistemas em três etapas. As duas primei-
ras pertencentes à fase de execução, e a terceira pertencente à fase de emissão
de relatórios. São elas:

•  pré-auditoria;
•  auditoria;
•  pós-auditoria.
Na etapa de pré-auditoria, são executados os processos que preparam o am-
biente para ser auditado. O auditor deve informar à área auditada qual o siste-
ma eleito para auditoria, e então um aviso deve ser emitido aos interessados,
com o cronograma e as definições previamente planejadas. Nesta etapa tam-
bém ocorrem as reuniões entre os envolvidos da área a ser auditada com os au-
ditores. Estas reuniões tem o objetivo de esclarecer pontos do planeamento da
auditoria aos interessados.
O corpo administrativo da área a ser auditada precisa preparar as ativi-
dades de apoio à equipe de auditoria, visto que informações e acessos se-
rão requisitados.

46 • capítulo 2
 Após a reunião inicial, a informação por parte dos auditores do que será in-
vestigado, a data de início da auditoria, a data de emissão do relatório final, o
pedido de colaboração por parte do auditado para que sejam fornecidos aces-
sos e informações à equipe de auditoria, o trabalho de auditoria propriamente
dito pode ser iniciado.
No início do trabalho de campo, o chefe (diretor) da auditoria faz as solicita-
ções por escrito para o representante setor auditado (BENETTI, 2015).
A equipe de auditoria deve, neste momento, verificar a existência dos con-
troles internos, processos e controles de negócios. Após esta verificação, testar
e avaliar sua eficiência e eficácia.
Ao identificar fraquezas, vulnerabilidades, inconsistências e irregularida-
des do sistema, o auditor deve informar o fato verbalmente e solicitar a corre-
ção, com data prevista.

2.3.3  Emissão de relatórios

Ao término do trabalho de campo, o auditor se prepara para a pós-auditoria,

que consiste basicamente na etapa de emissão do relatório final. Este relatório
apresenta uma “nota” contendo todas as falhas do sistema e as datas para que
sejam corrigidas.
O papel do auditor não é corrigir as falhas, e sim apresentar as recomenda-
ções para que sejam corrigidas. Em hipótese alguma o auditor deve corrigi-las.

2.3.4  Follow-up

Nesta fase, a auditoria deve acompanhar a solução das falhas encontradas e

que constam na nota do relatório final e também a solução das falhas alertadas
durante o trabalho de campo. Estas falhas têm datas para que sejam corrigidas,
portanto, tornam-se um compromisso do auditado com a auditoria.
A resposta do auditado ao relatório final contendo as soluções e as justifi-
cativas é avaliada pela equipe de auditoria, que por sua vez deve assegurar o
cumprimento das ações executadas e analisar as tendências de correção das
falhas (BENETTI, 2015).

capítulo 2 • 47
2.4  Ferramentas de auditoria
A auditoria de sistemas pode ser executada tanto em sistemas que estão em
desenvolvimento quanto em sistemas em operação.
No caso de sistemas em desenvolvimento, a auditoria foca sua atenção no
planejamento dos controles internos, processos e controles de negócio. Já no
caso de sistemas em operação é verificada a existência de pontos de controle e
são executados testes para verificação destes pontos.
Imoniana (2008) cita que, na auditoria de sistemas em operação, têm-se:
•  softwares generalistas;
•  softwares especializados;
•  softwares utilitários.

Cada tipo de software tem seus usos específicos, suas vantagens e desvanta-
gens, que são apresentadas a seguir.

2.4.1  Softwares generalistas

Os softwares generalistas são programas em ambiente batch (offline). São

aplicativos que carecem de personalização, softwares conhecidos como
“de prateleira”.
Segundo Imoniana (2008), podem ter funções como:
•  extração de dados de amostra;
•  geração de dados estatísticos;
•  gravação de arquivos auxiliares;
•  testes globais;
•  detecção de duplicidades;
•  apontamento de duplicidade de registros;
•  apontamento de sequência incorreta;
•  outros.

São alguns exemplos deste tipo de softwares:

•  ACL (Audit Command Language): extração e análise de dados;
•  IDEA (Interactive Data Extraction & Analysis): extração e análise de dados;
•  Galileo: softwares integrado de gestão de auditoria, incluindo gestão de
riscos, documentação, relatórios;

48 • capítulo 2
 •  Pentana: softwares para planejamento estratégico de auditoria, diversos
controles, entre outras funcionalidades.

Imoniana (2008) apresenta algumas vantagens e desvantagens do uso deste

tipo de software. Como vantagens, pode-se citar:
•  poder de processamento de vários arquivos ao mesmo tempo;
•  poder de integração com outros softwares e hardwares;
•  não é necessário que o auditor seja especialista em informática para
que desenvolva aplicativos de testes de dados, apenas utiliza-se do aplicativo
já desenvolvido.

Como desvantagens, tem-se (IMONIANA, 2008):

•  não se pode fazer aplicações online, pois os softwares utilizam-se de ar-
quivos que são analisados separadamente;
•  impossibilidade de rodar cálculos complexos e específicos devido ao seu
caráter generalista.

2.4.2  Softwares especializados

Como o próprio nome já diz, o software especializado é aquele que atende me-
lhor o usuário na especialidade para qual foi desenvolvido.
Ao contrário dos softwares generalistas, que visam abranger um maior nú-
mero de usuários e soluções, os softwares especialistas são aqueles mais espe-
cíficos que, normalmente, resolvem um menor número de problemas que por
serem incomuns, não são implementados nos softwares generalistas.
Estes softwares geralmente são desenvolvidos pelos auditores, a fim de re-
solver problemas pontuais e específicos da área ou sistema auditado.
Como vantagens do uso deste tipo de software, pode-se citar (IMONIANA,
2008):
•  inclusão de testes e verificadores de controles internos específicos do sis-
tema auditado;
•  desenvolvimento de soluções para auditar áreas mais complexas e especí-
ficas, podendo se utilizar disto como vantagem competitiva.

capítulo 2 • 49
 Apesar de o uso de softwares especializados ser de grande valia quando a
auditoria é feita em um sistema mais complexo, algumas desvantagens são des-
tacadas por Imoniana (2008):
•  o auditor deve estar familiarizado com desenvolvimento de software;
•  o custo do desenvolvimento de softwares especializados pode
não compensar.

2.4.3  Softwares utilitários

Os utilitários são softwares que geralmente são utilizados para funções bási-
cas da auditoria. Estes não necessitam ser softwares específicos para auditoria,
eles podem ter outra finalidade, mas, se utilizados como apoio à auditoria, po-
dem auxiliar em tarefas comuns.
Normalmente, os sistemas operacionais e os sistemas gerenciadores de
bancos de dados possuem softwares que podem ser utilizados como auxílio a
auditoria, como, por exemplo, para efetuar cálculos, geração de relatórios, en-
tre outras funcionalidades auxiliares.
Uma vantagem apontada por Imoniana (2008) no uso deste tipo de software
é que, na falta de outros recursos, pode-se atingir bons resultados utilizando
softwares de apoio. Como desvantagem, é citado que sempre necessitará do au-
xílio do auditado para o uso da ferramenta.

ATIVIDADES
01. Defina ao menos cinco importantes controles internos que devem ser implementados
em sistemas de informação que utilizam dados bancários sigilosos.

02. Cite ao menos três passos, mantendo sua ordem lógica, que pertencem à fase de exe-
cução da auditoria.

03. Defina um cenário em que seria viável o desenvolvimento de uma ferramenta especialis-
ta (software especializado) para uso na auditoria de um sistema.

50 • capítulo 2
 REFLEXÃO
Este capítulo abordou, dentre outros termos, o dia a dia da equipe de auditoria (auditor). Pô-
de-se perceber a importância da existência de controles internos e de sua efetividade. Muitos
deles foram exemplificados, trazendo uma visão prática da execução da auditoria.
Uma visão sistêmica, com as fases bem definidas da auditoria foi apresentada, tornando
o processo de entendimento da auditoria mais simples, como uma sequência de passos.
O uso de ferramentas de software também foi abordado, demonstrando sua importância
e especificidades de uso em cada caso. Desta maneira, o leitor torna-se apto a fazer escolhas
de diferentes abordagens.

LEITURA
Com um foco em auditoria interna, o livro The Essential Handbook of Internal Auditing traz
uma série de detalhes interessantes de abordagem de auditoria, provendo conhecimento e
também servindo como um guia para auditores internos.
PICKETT, K. H. Spencer. The Essential Handbook of Internal Auditing. Chichester: Wiley, 2005.

REFLEXÃO
AUDITORIA, Portal da. Controles Internos. Disponível em: <http://www.portaldeauditoria.com.br/
controles-internos/>. Acesso em: 20 ago. 2015.
BENETTI, Marcos Antonio. Segurança e Auditoria de Sistemas. Disponível em: <http://www.
benetti.eti.br/home/informatica/auditoria>. Acesso em: 15 ago. 2015.
CHAMPLAIN, Jack J.. Auditing information systems. 2. ed. Hoboken: Wiley, 2003.
IMONIANA, Joshua Onome. Auditoria de Sistemas de Informação. 2. ed. São Paulo: Atlas, 2008.
207 p.

capítulo 2 • 51
52 • capítulo 2
 3
Técnicas
de Auditoria
e Controles
Organizacionais e
Operacionais
Neste capítulo são apresentadas as técnicas de auditoria mais utilizadas nas
auditorias de sistemas. Estas técnicas são explicadas de forma detalhada para
que se possa criar uma visão crítica sobre quais técnicas utilizar e quando utili-
zá-las. Além das técnicas, são abordados controles organizacionais e operacio-
nais, que compreendem a criação de políticas de segurança da informação e as
funções de alguns cargos-chave na área de tecnologia da informação.

OBJETIVOS
Os principais objetivos de aprendizado deste capítulo são:
•  conhecer em detalhes as principais técnicas utilizadas em auditoria de sistemas;
•  aprender sobre o processo de implantação de política de segurança da informação; e
•  conhecer os cargos da área de tecnologia da informação e suas respectivas funções.

54 • capítulo 3
3.1  Técnicas de auditoria
As técnicas utilizadas em uma auditoria de sistemas não precisam ser sempre
as mesmas. Cada auditoria pode necessitar o uso de determinadas técnicas,
que são definidas considerando o escopo da auditoria. Este escopo compreen-
de o conjunto de controles internos, os processos e os controles de negócios do
sistema que será auditado.
As técnicas de auditoria abordadas neste livro são as seguintes:
•  software para auditoria;
•  questionários;
•  visita in loco;
•  entrevista;
•  teste de observância;
•  teste substantivo;
•  dados de teste;
•  teste integrado;
•  simulação paralela;
•  lógica de auditoria embutida nos sistemas;
•  mapeamento estatístico dos programas;
•  rastreamento dos programas;
•  análise da lógica de programação;
•  análise de log.

3.1.1  Software para auditoria

Como abordagem para a auditoria de sistemas, o auditor pode se utilizar de

softwares voltados para auditoria. Isto significa que esta técnica de auditoria
provê algumas facilidades para o trabalho e também permite a execução de al-
guns passos e processos de auditoria essenciais.
Uma destas facilidades pode ser identificada como a tabulação e impressão
de conteúdos. O software além de padronizar, facilita o manuseio de conteúdos
se utilizado com este fim.
O confrontamento e acompanhamento de resultados acumulados e a veri-
ficação de integridade dos dados são de suma importância para o processo de
auditoria e o uso de software permite a automação e a exatidão na execução
destas tarefas.

capítulo 3 • 55
 Cálculos como média, desvio-padrão, moda, entre outros, são calculados
com mais exatidão e velocidade se utilizado um software. Estas e outras medi-
das estatísticas permitem uma análise mais detalhada e precisa do comporta-
mento do sistema.

DEFINIÇÃO
Os logs são arquivos que armazenam informações de acesso e uso de um servidor, sistema
ou aplicação. Geralmente têm data, hora, descrição do evento, informações do usuário e/ou
da máquina.

A utilização de logs é muito útil quando se necessita de informações deta-

lhadas sobre o que e quando aconteceu em um sistema. A análise destes arqui-
vos podem evidenciar informações de alto valor para o auditor.
No detalhamento da auditoria baseada em software deve-se verificar se os
atributos estão corretos. No caso de a auditoria encontrar atributo incorreto,
deve-se exibir de alguma forma o erro, seja listando ou gravando a tela na qual
evidencie a incorreção do atributo, entre outras formas.
A listagem de código-fonte pelo auditor deve-se ater a alguns requisitos, es-
tes são eles:
•  quando não há movimento (utilização) há mais de um ano;
•  quando a quantidade em estoque registrada no software for abaixo da
quantidade real;
•  quando a quantidade em estoque registrada for zero ou negativa.

Para a execução de teste em um sistema, o auditor pode fazê-lo de

duas maneiras:
•  desenvolvendo programas e os rodando com massa de dados real;
•  preparando a massa de dados artificial e rodando com programas
em produção.

56 • capítulo 3
 DEFINIÇÃO
Um sistema em produção, diferentemente do que pode parecer, é um sistema que está
sendo utilizado, um sistema pronto, e não um sistema que está sendo produzido (neste caso,
diz-se que o sistema está em desenvolvimento).

Se utilizando da primeira maneira, o auditor estaria desenvolvendo o seu

próprio programa e testando a massa de dados utilizada no dia a dia da orga-
nização, a fim de verificar a conformidade dos dados transitados pelo sistema.
Na segunda maneira, o auditor estaria preparando uma massa de dados ar-
tificial (não aquela que é utilizada no ambiente organizacional), para que possa
simular o uso do sistema da organização com o objetivo de verificar a conformi-
dade nas tarefas executadas por este sistema.

3.1.2  Questionário

O uso de questionários por auditores é comum. É importante que cada ponto

de controle (item a ser auditado) tenha seu próprio questionário (GIL, 2000).
Um questionário contém perguntas e um espaço necessário para que o au-
ditor possa assinalar se o sistema satisfaz ou não o ponto de controle em ques-
tão. Caso o sistema não o satisfaça, o auditor deve então registrar a solicitação
de correção.
Há uma série de pontos de controle específicos para os quais se pode dire-
cionar os questionários, como segurança da informação e a eficiência no uso de
recursos de tecnologia da informação.
Em segurança da informação, podem-se citar:
•  a segurança física dos equipamentos computacionais;
•  a segurança lógica do tráfego de informações pela rede;
•  o controle de acesso físico às instalações da área de tecnologia da infor-
mação; e
•  a segurança ambiental (combate a incêndios, invasões, atentados, sabo-
tagens, situações de greve, inundações, entre outras).

Quanto ao uso eficiente dos recursos de TI, a verificação pode abranger,

além de outros, os seguintes pontos de controle:

capítulo 3 • 57
 •  o tempo médio de disponibilidade do sistema que está sendo auditado
no momento;
•  o tempo de uso dos equipamentos;
•  a verificação do SLA.

DEFINIÇÃO
O termo SLA (Service Level Agreement) é dado a um acordo entre o prestador de serviços de
TI e o cliente, no qual constam, de forma mensurável, os serviços que serão prestados, com
o objetivo de manter a qualidade dele.

A utilização da técnica de questionário normalmente é acompanhada de

alguma outra técnica de auditoria, como entrevistas e visita in loco. O seu uso
como apoio à outras técnicas também é comum no ambiente de auditoria
de sistemas.

3.1.3  Visita in loco

O termo em latim in loco significa no local. Portanto, esta técnica é uma visita
pessoal do auditor ao local para que se possam fazer as verificações. Esta visita
deve ser agendada formalmente com o auditado, por meio de carta, e-mail, en-
tre outros (SILVA, 2009).
Esta técnica é de suma importância para que, quando na existência de
pontos nebulosos na utilização de outras técnicas, estes sejam devidamen-
te esclarecidos.
O seu caráter complementar permite que estas visitas sejam pontuais, por-
tanto, assim como os questionários, normalmente utiliza-se a visita in loco em
conjunto com outras técnicas.
Dentre as ações que podem ser executadas por meio desta técnica, pode-
mos destacar:
•  obtenção de dados por observação;
•  obtenção de dados por teste;
•  obtenção de dados por documentação;
•  anotação de informações para posterior documentação.

58 • capítulo 3
 Caso o auditor identifique falhas, o auditado é informado instantaneamen-
te, pessoalmente e informalmente. Porém, posteriormente, o auditor também
notifica o auditado sobre falha por escrito.

3.1.4  Entrevista

As entrevistas de campo no âmbito da auditoria de sistemas podem ser feitas

pessoalmente, por telefone e também por videoconferência. No planejamento
da auditoria, é feito um roteiro para a execução das entrevistas. Este roteiro ser-
ve como um guia, definindo a abordagem e quem serão os entrevistados.
As entrevistas devem ter uma sequência lógica, que deve ser orientada
pelo processo que está sendo auditado. Perguntar aos entrevistados o que fa-
zem, quais informações recebem e quais passam adiante, para que se possa
identificar se há divulgação de informações de forma indevida (TÉCNICA DE
ENTREVISTA PARA AUDITORIAS, 2010).
De acordo com o manual de técnica de entrevista para auditorias do
Tribunal de Contas da União (TÉCNICA DE ENTREVISTA PARA AUDITORIAS,
2010), existem três tipos de entrevistas de campo:
•  estruturada;
•  não estruturada;
•  semiestruturada.

No caso da entrevista estruturada, o auditor utiliza formulários para a coleta

de informações e dados. Normalmente estes formulários são definidos no pla-
nejamento, e tem-se um modelo em que o auditor se limita a obter as informa-
ções requeridas por este formulário.
A entrevista não estruturada é mais flexível, podendo o auditor adaptar
as perguntas e o rumo da entrevista de acordo com as informações que fo-
rem adquiridas durante o processo. Neste caso, não se utiliza de formulá-
rio prédefinido.
A entrevista semiestruturada segue um roteiro prédefinido com algumas
perguntas fechadas, porém, há a possibilidade do auditor estender a entrevista
para abordagens diferentes conforme haja necessidade.
Ao utilizar-se de perguntas abertas, o auditor deixa o entrevistado falar li-
vremente, fornecendo informações voluntariamente, tornando o processo de
auditoria mais agradável.

capítulo 3 • 59
3.1.5  Teste de observância

Também conhecida como teste de aderência, o objetivo do uso desta técni-

ca é determinar se os procedimentos internos (controles internos) da orga-
nização estão sendo cumpridos por meio de observação por parte do auditor
(LINDNER, 2015).
Primeiramente, verificam a credibilidade dos controles internos da organi-
zação. A aplicação deste teste pode prover maior confiabilidade aos controles
internos adotados pelo auditado, tornando a observação essencial para a audi-
toria (CORDEIRO, 2015).
Uma das particularidades do teste de observância é que o auditado não
pode perceber que está sendo observado. Geralmente, a pessoa que está exe-
cutando uma operação não sabe que está sendo auditada, para que esta possa
executar as ações da forma como habitualmente o faz, caso contrário, a opera-
cionalização efetuada pelo auditado poderia sofrer influência com a presença
do auditor.

3.1.6  Teste substantivo

O teste substantivo é executado pelo auditor com o objetivo de obtenção de pro-

vas convincentes sobre as operações, para que possa determinar sua opinião
com embasamento (CORDEIRO, 2015).
Cordeiro (2015) define como objetivos fundamentais do teste substantivo:
•  verificar a existência real de que as transações registradas realmente te-
nham acontecido;
•  verificar a integridade das informações e se permanecem inalteradas des-
de sua gravação;
•  verificar se os interessados recebem as informações em sua totalidade;
•  verificar se os itens foram avaliados e aferidos de forma correta;
•  verificar se as transações e os registros têm sido divulgados corretamente.

3.1.7  Dados de teste

Esta técnica também é conhecida como test data ou test deck e consiste em o
auditor preparar um conjunto de dados que são utilizados para testar os con-
troles do sistema auditado (IMONIANA, 2008).

60 • capítulo 3
 Este conjunto de dados (massa de dados) deve ser preparado com os dados
de entrada e os dados de saída esperados, para que se possa fazer as compa-
rações entre a saída desejada (que consta na massa de dados) e a saída que o
sistema produziu.
Outro ponto importante destacado por Imoniana (2008) é que a massa de
dados deve ser preparada com o objetivo de testar uma grande quantidade de
possibilidades e combinações de possíveis transações, a fim de que se possa
simular o ambiente real de uso do sistema.
Como vantagens, Imoniana (2008) destaca a possibilidade de utilizar
softwares de geração de dados para execução da tarefa de forma mais eficien-
te, além da possiblidade de que a criação desta massa de dados seja feita por
pessoas com pouco conhecimento em informática. Já a grande desvantagem
que pode ser citada é a dificuldade de prever as possibilidades de transações do
sistema com seus respectivos dados de saída desejados.

3.1.8  Teste integrado

Esta técnica é normalmente conhecida como ITF (Integrated Test Facility), é

utilizada em ambiente on-line, isto é, com o sistema rodando em produção. Sua
execução consiste na aplicação de entidades fictícias no sistema, para que se
possa testar as funcionalidades sem precisar manipular os dados reais da apli-
cação (IMONIANA, 2008).
O confronto dos dados reais com os dados de teste é o trabalho do audi-
tor ao executar esta técnica, que acontece sem o consentimento do operador
do computador.
Esta técnica não atualiza as bases de dados reais da organização, pois são
criados arquivos separados para os dados fictícios (IMONIANA, 2008).

3.1.9  Simulação paralela

A utilização desta técnica consiste no desenvolvimento de um programa

pelo auditor que simula as funções do sistema auditado, focando nos pontos
de controle.
Ao contrário da técnica de dados de teste, em que simulamos a massa de
dados com o programa em produção, nesta técnica o programa é simulado e
executado com a massa de dados real (IMONIANA, 2008).

capítulo 3 • 61
3.1.10  Lógica de auditoria embutida nos sistemas

A técnica de inclusão da lógica de auditoria nos sistemas informatizados con-

siste em desenvolver funcionalidades que permitam o próprio sistema emi-
tir relatórios de auditoria. Esta técnica deve ser implantada com o sistema
em desenvolvimento.
Como vantagem do uso desta técnica pode-se citar o monitoramento per-
manente das atividades do sistema. Como desvantagens, há o custo adicional
de desenvolvimento do sistema e perda no desempenho (IMONIANA, 2008).

3.1.11  Mapeamento estatístico dos programas

Esta técnica, segundo GIL (2000), é utilizada para a verificação de ações como:
•  rotinas obsoletas ou não utilizadas;
•  frequência de utilização de rotinas;
•  rotinas existentes em programas já desativados ou de uso esporádico;
•  rotinas mais utilizadas, normalmente a cada processamento do programa;
•  rotinas fraudulentas e de uso em situações irregulares;
•  rotinas de controle acionadas a cada processamento;

Para que se aplique esta técnica, existem alguns pré-requisitos, como a ne-
cessidade de utilização de software de apoio e a necessidade de inclusão de ins-
truções especiais junto aos programas em produção, acarretando em custo e
perda de desempenho do programa.

3.1.12  Rastreamento dos programas

Esta técnica possibilita ao auditor efetuar o rastreamento das transações du-

rante o seu processamento. Isto significa que os passos seguidos por uma
operação do sistema são registrados, com o objetivo de fornecer um caminho
percorrido pela transação executada. Isto permite ao auditor detectar rotinas
fraudulentas e caminhos incorretos das transações (GIL, 2000).

62 • capítulo 3
3.1.13  Análise da lógica de programação

O objetivo da aplicação desta técnica é determinar se a lógica das funcionalida-

des do sistema está em conformidade com a documentação e a efetividade dos
controles programados (IMONIANA, 2008).
Obviamente, para poder executar esta técnica, o auditor deve ser um conhe-
cedor da linguagem de programação utilizada no desenvolvimento do sistema.

3.1.14  Análise de log

Com a análise dos arquivos de log do sistema, o auditor pode verificar quando
e como o sistema está sendo utilizado.
Com isto, Gil (2000) cita que o auditor pode:
•  determinar erros de programas;
•  flagrar o uso de programas fraudulentos;
•  captar tentativas de acesso indevido a arquivos;
•  monitorar a rede.

Esta análise, segundo Gil (2000), pode gerar:

•  indicadores de qualidade;
•  indicadores para estudo e planejamento da capacidade da tecnologia da
informação, buscando maior rendimento e segurança;

3.2  Auditoria de controles organizacionais e

operacionais

Os controles organizacionais e operacionais são os controles administrativos

do processo de fluxo das transações dos sistemas de informação com o intuito
de auxiliar no cumprimento dos objetivos do negócio (IMONIANA, 2008).
Algumas das responsabilidades destes controles citadas por Imoniana
(2008) são:
•  delineamento das responsabilidades operacionais;
•  coordenação de orçamento de capital de informática e bases;
•  desenvolvimento e implantação das políticas globais de informática;

capítulo 3 • 63
 •  intermediação com terceiros (networking);
•  gerenciamento de suprimentos;
•  desenvolvimento do plano de capacitação.

Apenas os controles não garantem a segurança da organização, pois a se-

gurança também abrange a proteção de informações e recursos. Neste caso,
Imoniana (2008) discorre sobre a importância da confiança mútua entre a or-
ganização e os funcionários. Práticas como baixo salário e más condições de
trabalho oferecem risco à empresa, visto que funcionários de tecnologia da in-
formação geralmente têm acesso à informações estratégicas.

3.2.1  Políticas organizacionais

Para que os objetivos administrativos da organização sejam alcançados, é de

suma importância que as políticas organizacionais de tecnologia da informa-
ção sejam implantadas.
A figura 3.1 exibe a atuação das políticas organizacionais com o objetivo de
preservação das funções administrativas.

Políticas
Segurança
Organizacionais

Responsabilidade Padronização de
de Todos Comportamento

Responsabilidade
Preservação
de Cada Um

Figura 3.1  –  O papel das políticas organizacionais de segurança.

64 • capítulo 3
 As políticas organizacionais devem ser seguidas por todos os funcionários
da empresa, e seu descumprimento pode justificar uma demissão por justa
causa. Estas políticas têm um foco na segurança, com o objetivo de garantir a
credibilidade no serviço prestado ao cliente.

EXEMPLO
Um exemplo de política de segurança de uma organização pode ser a proibição da con-
tratação de pessoal que tenha parentesco com algum outro colaborador, evitando assim
protecionismo e fraudes.

O processo de implantação de uma política de segurança da informação é

definido por Imoniana (2008) como a seguinte sequência:
•  identificação dos recursos críticos;
•  classificação das informações;
•  identificação das possíveis ameaças e análise de risco;
•  objetivos de segurança a serem alcançados;
•  elaboração da proposta da política;
•  discussão com os envolvidos;
•  apresentação do documento formal à gerência superior;
•  aprovação pela gerência superior;
•  divulgação e implementação;
•  avaliação da política e identificação das mudanças;
•  revisão e implementação definitiva.

Na identificação dos recursos críticos, têm-se como foco o hardware, o

software, os dados, as pessoas, a documentação e os suprimentos.
A classificação das informações pode ser feita em quatro classes:
•  públicas ou de uso irrestrito;
•  internas ou de uso interno;
•  confidenciais;
•  secretas.

As informações públicas ou de uso irrestrito são aquelas que podem ser di-
vulgadas a qualquer pessoa, como, por exemplo, por página de internet, revis-
tas e jornais.

capítulo 3 • 65
 Informações internas são aquelas que não devem sair do âmbito da organi-
zação, mas que não são críticas, como, por exemplo, um aviso aos funcionários
ou um jornal interno.
A informação confidencial é aquela que deve ser protegida contra o aces-
so externo. A violação desta informação pode comprometer o funcionamento
da empresa, causar danos financeiros, prejuízo à imagem e perda de clientes
para a concorrência. São exemplos: dados de clientes, senhas e informações
de contratos.
A violação no caso de informação secreta, seja esta violação interna ou ex-
terna, é extremamente crítica. O número de pessoas autorizadas a acessar tais
informações é geralmente muito restrito e bem controlado. Como exemplos
podemos citar informações militares, fórmulas secretas e dados de seguran-
ça nacional.
No terceiro subprocesso de implantação de política de segurança da infor-
mação, deve-se levantar as ameaças possíveis e traçar uma matriz de risco, a fim
de que se detectem as maiores ameaças.
Os objetivos a serem alcançados devem ser especificados na política de se-
gurança e divulgados aos funcionários, para que estes percebam a importância
do cumprimento de tal política.
A proposta a ser elaborada deve ter como objetivo eliminar ou reduzir a
um nível aceitável o risco, limitando danos e reduzindo impactos sofridos
pela organização.
Na etapa de discussão com os envolvidos, a proposta deve ser discutida
com o time de segurança, os gerentes da área de sistemas, recursos humanos,
recepção, expedição, portaria, entre outros órgãos envolvidos com a política a
ser implantada.
A compensação do dano deve ser uma preocupação na definição da política
de segurança, geralmente efetuada com a contratação de seguros.
A etapa de aprovação deve ser feita pela alta administração após as discus-
sões com os envolvidos. O comprometimento da alta administração e de todos
da organização é fundamental para o cumprimento da política.
Após a aprovação da política proposta, deve-se divulgar sua existência e im-
plantá-la de fato. Uma recomendação para esta etapa é a de fornecer, quando
necessário, treinamento para os colaboradores.
O prazo para avaliação da política pode variar de seis meses a um ano.
Para a identificação de falhas na política de segurança, é recomendado colher

66 • capítulo 3
feedback dos colaboradores e, caso necessário, as alterações serão estudadas,
implementadas e divulgadas.
Após a revisão da política de segurança, esta é implementada definitiva-
mente e, a partir deste momento, não sofre mais alterações. A política de segu-
rança diz o que deve ser feito. A questão de como deve ser feito fica por conta
dos procedimentos; estes sim podem sofrer alterações ao longo do tempo.
É comum que se definam subgrupos de políticas, como política de backup,
política de senhas, políticas de acesso, políticas de instalação de equipamen-
tos, entre outras.

3.2.2  Violação de políticas organizacionais

Não é uma tarefa corriqueira detectar uma violação de política organizacional.

Portanto, os procedimentos devem ser implementados com o objetivo de evitar
as violações.
É necessário que se investigue a causa da violação da política para identifi-
car se ela ocorreu por negligência, erro, acidente, desconhecimento, problema
no plano de sistemas de informação, ação deliberada, entre outros possíveis
fatores causadores.
A política de segurança engloba a ação que deve ser tomada em cada
tipo de violação, incluindo as correções sobre vulnerabilidades e a punição
dos infratores.

3.2.3  Descrição de cargos em tecnologia da informação

As descrições de cargos e funções possibilitam a implantação consistente de

controles organizacionais na área de tecnologia da informação (IMONIANA,
2008). São definidos por Imoniana (2008):
•  supervisor de infraestrutura de TI;
•  administrador de redes;
•  administrador de bancos de dados;
•  administrador de segurança;
•  analista de sistemas;
•  web designer;
•  suporte técnico;
•  supervisor de service desk;

capítulo 3 • 67
 •  supervisor de restart/recovery;e
•  bibliotecário.

Cada cargo em TI tem suas funções específicas, e o auditor deve verificar se

elas estão sendo devidamente cumpridas. A seguir são descritas as funções dos
cargos de TI de acordo com Imoniana (2008).
O supervisor de infraestrutura de tecnologia da informação atua direta-
mente com a gerência de TI, definindo as metas. São funções do supervisor
de infraestrutura:
•  planejar a capacidade da TI, indicando melhorias;
•  buscar recursos para o ambiente;
•  coordenar as ações para projetos e metas da área;
•  garantir o perfeito funcionamento da TI com equipe técnica competente.

O administrador de redes tem como funções:

•  instalar e fornecer suporte aos diversos servidores da organização;
•  administrar as contas de usuários e acessos;
•  monitorar o desempenho da rede;e
•  adotar as ações necessárias para a implantação de novas tecnologias.

Como funções do administrador dos bancos de dados da organização, po-

de-se citar:
•  administrar todo o ambiente de bancos de dados;
•  planejar e implantar estratégias de utilização dos bancos de dados pelas
pessoas, sistemas ou programas;
•  implantar ajustes, melhorias e modificações quando surgirem novos
avanços tecnológicos;
•  oferecer suporte técnico aos usuários;
•  planejar e executar os backups;
•  coordenar as atividades de administração de dados.

O administrador de segurança tem como funções as seguintes:

•  implementar a política de segurança da empresa;
•  detectar possíveis invasões ou ameaças, realizando as ações corretivas;
•  identificar as vulnerabilidades na rede e na política de segurança;
•  manter a estrutura de segurança atualizada;

68 • capítulo 3
 •  customizar o sistema de segurança de acordo com a política de segurança
da organização;
•  pesquisar falhas de segurança dos sistemas operacionais e dos aplicativos;
•  pesquisar novas soluções de segurança para um processo de melho-
ria contínua.

As funções do analista de sistemas na organização são:

•  especificar os requisitos junto aos clientes;
•  analisar e projetar os aplicativos;
•  manter um serviço permanente para verificação dos aplicativos;
•  testar os sistemas desenvolvidos;
•  manter a documentação dos sistemas atualizada;
•  fazer ajustes nos programas quando houverem avanços tecnológicos;
•  dar suporte aos usuários dos sistemas e aplicativos.

O papel do web designer é:

•  implementar as soluções de design propostas e aprovadas pelas áreas res-
ponsáveis pela implementação do site;
•  efetuar as manutenções no site da empresa;e
•  pesquisar sobre novas ferramentas de design;

O profissional de suporte técnico tem como funções:

•  efetuar manutenção preventiva e corretiva dos equipamentos instalados;
•  fazer inventário de hardware e software;
•  instalar, remanejar e manter a estrutura de cabeamento;
•  disponibilidade de licenças de uso dos software;
•  suporte técnico aos usuários;
•  acompanhar cada chamado até a solução, interagindo com o usuário e a
equipe técnica.

Algumas funções do supervisor de service desk são:

•  documentar os problemas operacionais;
•  solucionar os problemas secundários e encaminhar os problemas mais
sérios a quem for de direito;
•  controlar a qualidade na entrega do serviço.

capítulo 3 • 69
 O supervisor de restart/recorery tem como funções:
•  definir procedimentos para, em caso de interrupção, efetuar a recupera-
ção de dados;
•  definir as rotinas de backup;
•  implementar os procedimentos de pontos de checagem;
•  recuperar o banco de dados;
•  instalar no-breaks e anti-vírus;
•  implementar o hot-site;
•  providenciar o cold-site.

DEFINIÇÃO
O cold-site é um local onde os equipamentos são instalados e utilizados em caso de contin-
gência (local backup).

O bibliotecário deve manter controle sobre a responsabilidade de docu-

mentar programas e arquivos e não ter habilidades que possibilitem a perpe-
tuação de fraudes (IMONIANA, 2008).

ATIVIDADES
01. Quais as técnicas de auditoria que podem necessitar do desenvolvimento de programas
por parte do auditor?

02. Quais as técnicas de auditoria que necessitam da presença física do auditor na organi-
zação auditada?

03. Qual o profissional de TI responsável por programar o backup dos bancos de dados?

04. O que pode ser alterado após uma política organizacional ter sido implanta-
da definitivamente?

70 • capítulo 3
 REFLEXÃO
As técnicas de auditoria abordadas neste capítulo compreendem um ferramental poderoso
para a auditoria de sistemas de informação. Se utilizadas da forma correta e em conjunto
com outras, o processo de auditoria pode se tornar completo e eficiente. Considerando o que
foi apresentado neste capítulo, ficam evidentes a importância do cumprimento da política de
segurança da informação nas organizações e a correta segregação de funções, visto que
cada colaborador da área de tecnologia da informação é fundamental para o bom andamento
de uma empresa.

LEITURA
O site do Tribunal de Contas da União (TCU) tem diversos manuais de técnicas de auditoria,
como técnicas de entrevistas, manual de auditoria de sistemas de informação, entre outros.
Vale a pena checar estes manuais para que se possa conferir algumas normas e informações
relevantes que são apresentadas.
Site do TCU: http://www.tcu.gov.br
Slides sobre Auditoria Interna na Área de Tecnologia da Informação:
PACHECO, André Luiz Furtado. Auditoria Interna na Área de Tecnologia da Informação.
2011. Disponível em: <http://portal3.tcu.gov.br/portal/pls/portal/docs/2188952.PDF>.
Acesso em: 27 ago. 2015.

REFERÊNCIAS BIBLIOGRÁFICAS
CORDEIRO, Cláudio Marcelo Rodrigues. Testes em auditoria: uma revisão conceitual aplicável na
prática. Disponível em: <http://www.portaldeauditoria.com.br/artigos/testesemauditoria.htm>. Acesso
em: 26 ago. 2015.
GIL, Antonio de Loureiro. Auditoria de computadores. 5. ed. São Paulo: Atlas, 2000. 236 p.
IMONIANA, Joshua Onome. Auditoria de Sistemas de Informação. 2. ed. São Paulo: Atlas, 2008.
207 p.

capítulo 3 • 71
LINDNER, Graselene. Procedimentos de auditoria. Disponível em: <http://auditoriaemfoco.blogspot.
com.br/2011/05/procedimentos-de-auditoria_11.html>. Acesso em: 27 ago. 2015.
SILVA, Walcyr de Moura e. Auditoria de sistemas computacionais. 2009. Disponível em: <http://
www.ecnsoft.net/wp-content/plugins/downloads-manager/upload/FATEC-SBC_AUSC_Auditoria
sistemas FATECSBC.doc>. Acesso em: 26 ago. 2015.
TÉCNICA DE ENTREVISTA PARA AUDITORIAS. Brasília: Tribunal de Contas da União, 13 abr. 2010.

72 • capítulo 3
 4
Auditoria
Direcionada
As auditorias direcionadas visam à verificação de controles específicos para
cada uma de suas diferentes abordagens. Este capítulo traz as auditorias dire-
cionadas à rede, ao hardware, aos controles de acesso, à aquisição, desenvol-
vimento, documentação e manutenção de sistemas, à operação, ao suporte
técnico, aos aplicativos e aos eventos. Cada uma destas direções tem suas espe-
cificidades, portanto uma visão prática também é abordada. Esta visão é apre-
sentada por meio de questionários, em que é possível conhecer alguns contro-
les comuns e importantes para cada tipo de auditoria.

OBJETIVOS
O objetivo de aprendizado deste capítulo é fornecer uma visão teórica e prática para o aluno
sobre as auditorias direcionadas em diversos aspectos.

74 • capítulo 4
4.1  Auditoria de rede
A rede de uma organização é de grande importância, pois nela habitam e tra-
fegam as informações que alimentam as transações, sejam elas operacionais,
financeiras, entre outras (IMONIANA, 2008).
Categorizando a rede de uma organização, têm-se três tipos:
•  Intranet; •  Internet; •  Extranet.

A intranet é a rede interna da organização, aquela que só pode ser acessa-

da pelos colaboradores internos. A extranet é quando se concede acesso a uma
parte da intranet para público externo (clientes, parceiros etc). Sendo que este
acesso continua sendo controlado. A internet é a rede mundial de computado-
res e geralmente as informações disponibilizadas nesta rede podem ser acessa-
das por qualquer pessoa.
O autor Hall (2011) divide a rede apenas entre intranet e internet, citando
assim alguns dos principais riscos em intranets e internet. Os riscos apresenta-
dos referentes à intranets são:

•  interceptação de mensagens;
•  acesso às bases de dados da organização; e
•  privilégio de acesso indevido à funcionários;

Já no ambiente da internet, Hall (2011) apresenta como principais riscos:

•  falsificação de IP (IP Spoofing);

•  ataque de negação de serviço;

LEITURA
O livro de Stallings (2008) é uma excelente referência para aprofundar os conhecimentos
sobre segurança em tecnologia da informação, pois, além de apresentar conceitos, detalhes
técnicos de ataques e criptografia também são abordados.
STALLINGS, William. Criptografia e Segurança de Redes: Princípios e Práticas. 4. ed.
São Paulo: Pearson Prentice Hall, 2008.

capítulo 4 • 75
 Sobra a implantação de redes, os conceitos que são avaliados no processo
de auditoria, segundo Imoniana (2008), são:
•  planejamento da rede com visão estratégica (integração ao plano diretor
de informática);
•  desenho das arquiteturas e da topologia da rede;
•  implantação dos projetos físicos e lógicos;
•  monitoramento do desempenho da rede;
•  monitoramento de possíveis interceptações;
•  replanejamento de capacidade;
•  levantamento dos problemas operacionais visando sua solução.

O principal objetivo da auditoria de redes, de acordo com Imoniana (2008),

é certificar que a rede é confiável. Quatro aspectos são considerados para este
fim; são eles:
•  segurança física;
•  segurança lógica;
•  segurança de enlace;
•  segurança de aplicação.

A segurança física da rede contempla a arquitetura da rede, sua construção

e distribuição, os equipamentos e periféricos (hardware).
A segurança lógica da rede contempla os recursos de software em ge-
ral, os rendimentos da rede, o acompanhamento e a avaliação de desempe-
nho operacional.
A segurança de enlace da rede assegura que as transmissões entre localida-
des remotas e unidades estão obedecendo aos limites previamente estabeleci-
dos, assim como os canais de transmissão.
A segurança de aplicação da rede certifica a disponibilidade da rede, trazen-
do confiança na rede por parte dos usuários.
No programa de auditoria de redes é necessário que se utilize de um ques-
tionário, que deve ser documentado e arquivado em pasta própria do projeto
de auditoria. Estes documentos também são conhecidos como working papers.
A importância desta documentação se dá pelo fato de que todo o traba-
lho do auditor deve ser documentado e ser baseado em fatos, não em opi-
niões pessoais.

76 • capítulo 4
 Baseado em Imoniana (2008), segue na tabela 4.1 um exemplo de questio-
nário do programa de auditoria de redes.

CLIENTE: DATA: ___/____/______

FEITO POR: REVISADO POR:

S/N/NA REF. W/P OBS.

C1 - Há políticas organizacionais que

garantem implementação efetiva dos
controles relacionados com o ambien-
te de rede, que incluem:

•  administração de rede;
•  registro das operações;
•  vigilância sobre os acontecimentos;
•  registro dos custos dos usos;
•  soluções dos problemasoperacionais;
•  geração de relatórios gerenciais
Se sim, fazer o resumo da política.

C2 - Controles sobre o ambiente e

informações com relação a definição
da plataforma de hardware, software,
sistema operacional e mitigação de
riscos inerentes.

C3 - Controles sobre o software

C4 - Controles de segurança

Tabela 4.1  –  Questionário do programa de auditoria de redes, adaptado de Imoniana (2008).

capítulo 4 • 77
 No cabeçalho do questionário da tabela 4.1, define-se quem é o cliente e
quem é o responsável pelo preenchimento (auditor). A data e o revisor também
são descritos no cabeçalho.
A seguir, têm-se os itens a serem questionados. No caso do exemplo apre-
sentado na tabela 4.1, a questão C1 versa sobre a existência de políticas que
garantam o funcionamento do ambiente de rede.
Na primeira coluna (S/N/NA), responde-se com S para Sim, N para Não e
NA para Não se Aplica. Na segunda coluna (W/P), referencia-se o documento
(working paper) que dá embasamento à resposta do auditor e, finalmente, na
terceira coluna, o auditor faz suas observações referentes à questão. Após o
principal questionamento, responde-se para cada tópico aninhado às mesmas
três colunas.

4.2  Auditoria de hardware

A auditoria de hardware visa implantar os procedimentos de segurança física
nos equipamentos instalados em ambiente de informática. Estes procedimen-
tos controlam os contatos físicos e o monitoramento do uso adequado (IMO-
NIANA, 2008).

CURIOSIDADE
Em 1996, um computador foi roubado da empresa VISA, na Califórnia, Estados Unidos. Este
não se tratava de um computador comum, tinha informações de mais de 300 mil contas de
cartão de crédito da VISA, MasterCard, American Express e Diners Club. E o pior é que as
informações não estavam criptografadas (CHAMPLAIN, 2003).

Os inventários de hardware são de extrema importância para que os contro-

les destes sejam efetivos, assim como sua padronização na aquisição e monta-
gem, como, por exemplo, aquisição de servidores que funcionam com os mes-
mos sistemas operacionais ou da mesma marca (IMONIANA, 2008).
Algumas características da auditoria de hardware apresentadas por Gil
(2000) no tocante à verificação de contratos são, em caso de aquisição:

78 • capítulo 4
 •  intermediação da transação;
•  apólices de seguros;
•  cobertura do seguro.

Em caso de manutenção, Gil (2000) cita que é necessário verificar:

•  prazo de atendimento dos chamados;
•  o tempo máximo para se resolver um problema;
•  os períodos cobertos pelo contrato (madrugada, finais de semana, feria-
dos, entre outros).

Os principais objetivos da auditoria de controles de hardware, de acordo

com Imoniana (2008), são divididos em dois eixos. O primeiro garante a pro-
teção dos equipamentos, como terminais, unidade central de processamento
(CPU), servidores, unidade de conversão de dados, entre outros. O segundo
eixo verifica se há equipamentos que restrinjam os acessos físicos de pessoas
alheias ao ambiente, isto é, pessoas que têm interesse nas informações da orga-
nização e não têm permissão de acesso.
Com o objetivo de facilitar o levantamento de dados para a auditoria dos
controles de hardware, a tabela 4.2 apresenta um questionário (checklist) que
compreende diversos itens que devem ser verificados pelos auditores.

S/N/NA REF. W/P OBS.

C1 - Controles de acesso físico

ao ambiente de informática:

P1 - Verificar se a segurança
física sobre o hardware e os
dados é adequada em relação
ao uso dos computadores.

C2 - Controles de acionamento
e desligamento de máquinas:

capítulo 4 • 79
 S/N/NA REF. W/P OBS.

P2 - Avaliar, por meio de

observação, se o acesso ao
CPD (Centro de Processa-
mento de Dados) é permi-
tido somente à pessoas da
área para acionar e desligar
equipamentos.

P3 - Verificar se no des-
ligamento de pessoas há
procedimentos específicos
com relação à retenção de
identificação e eliminação da
senha de acesso.

C3 - Controle de acesso físico a

equipamentos de hardware:

P4 - Verificar se há um
controle efetivo de entrada
e saída de equipamentos da
área do CPD.

P5 - Verificar se um inventá-
rio completo e atualizado dos
equipamentos de informática
é efetuado periodicamente.

C4 - Localização e infraestrutu-
ra do CPD:

80 • capítulo 4
 S/N/NA REF. W/P OBS.

P6 - Verificar se há um sis-
tema alternativo de alimenta-
ção de energia elétrica (por
exemplo: no-break, gerador).

C5 - Controle de backup e
off-site:

P7 - Verificar se o backup,
armazenadas em local ex-
terno, estão disponíveis para
utilização 24 horas por dia.

P8 - Verificar se as cópias
armazenadas por longos
períodos são testadas e subs-
tituídas periodicamente.

C6 - Controles de aquisição e
disposição do equipamento:

P9 - Verificar se existe proce-

dimento periódico para:
– efetuar inventário de to-
dos os equipamentos;
– verificar as condições
ambientais dos equipamentos.

C7 - Controles sobre o ambien-

te e informações com relação
à definição da plataforma de
hardware, software, sistema
operacional e riscos inerentes:

capítulo 4 • 81
 S/N/NA REF. W/P OBS.

P10 - Avaliar se a plataforma

adotada está de acordo com
os padrões e as necessida-
des da empresa.

C8 - Controles sobre os recur-

sos instalados:

P11 - Verificar se existe

um procedimento formal e
consistente para monito-
rar a obediência à política
corporativa.

C9 - Garantia de integridade de
transmissão:

P12 - Identificar os equi-

pamentos que permitam
upload/download.

Tabela 4.2  –  Questionário do programa de auditoria de hardware. Fonte: IMONIANA, 2008.

Adaptado.

Os itens abordados no questionário da tabela 4.2 atentam para algumas im-

portantes tarefas e verificações necessárias por parte do auditor em se tratando
de auditoria dos controles de hardware.

4.3  Auditoria de controles de acesso

Primeiramente deve-se saber que o acesso pode ser dividido em duas partes
(acesso físico e lógico):
•  acesso físico;
•  acesso lógico.

82 • capítulo 4
 CONCEITO
De acordo com a Wikipedia (2015), o conceito de controle de acesso pode ser definido por:
“O controle de acesso, na segurança da informação, é composto dos processos de au-
tenticação, autorização e auditoria (accounting). Neste contexto o controle de acesso pode
ser entendido como a habilidade de permitir ou negar a utilização de um objeto (uma entidade
passiva, como um sistema ou arquivo) por um sujeito (uma entidade ativa, como um indivíduo
ou um processo). A autenticação identifica quem acessa o sistema, a autorização determina o
que um usuário autenticado pode fazer, e a auditoria diz o que o usuário fez.”

Basicamente, o acesso físico diz respeito à entrada de pessoas em determina-

dos recintos, enquanto o acesso lógico é relativo ao manuseio das informações.
Para o controle de acesso físico, pode-se utilizar, dentre outras formas, de:
•  crachás de identificação;
•  biometria;

A biometria, muito utilizada para este fim nos dias de hoje, é o uso da me-
dição de componentes biológicos das pessoas para identificá-las unicamente.
Sendo assim, a imagem da íris, a impressão digital, a voz e o reconhecimento
facial são medidas bem aceitas e confiáveis.
A forma mais comum de controle de acesso lógico é o gerenciamento de
senhas. Para que as senhas sejam um modo seguro de se controlar o acesso às
informações, deve-se tomar uma série de cuidados. Alguns deles são:
•  não utilizar dados pessoais em senhas;
•  não repassar sua senha individual para os outros;
•  tempo de expiração de senha;
•  número máximo de tentativas malsucedidas;
•  não digitar a senha sem que haja uma máscara que não deixe exibir os
caracteres que estão sendo digitados;
•  criar senhas difíceis de serem quebradas, com tamanho mínimo e con-
tendo letras, números e caracteres especiais.

É importante ressaltar que existem softwares que são utilizados para a que-
bra de senhas. Muitas vezes são utilizados ataques de força bruta para que a se-
nha seja descoberta. Os ataques de força bruta são testes exaustivos de todas as

capítulo 4 • 83
combinações de caracteres até que se chegue à combinação que corresponde à
senha que está sendo quebrada. Portanto, quanto mais difícil e maior esta com-
binação, mais difícil de se aplicar com êxito um ataque como este (STALLINGS,
2008).
O uso de senhas pode ocorrer juntamente com o uso da biometria, fortale-
cendo assim a segurança das informações do sistema (IMONIANA, 2008).
O administrador de ambiente deve forçar a troca de senha por parte do
usuário periodicamente, além de garantir que as senhas sejam armazenadas
de forma criptografada.
Um exemplo de working paper de teste de controles de acesso lógico é exi-
bido na tabela 4.3. Este exemplo tem os controles (C1 a C6) e alguns questiona-
mentos (P1 a P8).

S/N/NA REF. W/P OBS.

C1 - Políticas de segurança que

forneçam diretrizes e normas de
segurança:

P1 - A política é revisada pe-

riodicamente para assegurar
que ainda é adequada às
mudanças tecnológicas.

C2 - Rotinas e procedimentos
estabelecidos para atribuição
ou modificação do nível de
acesso:

P2 - Os usuários são respon-

sáveis por atividades executa-
das com sua senha.

C3 - Software para controle de

acesso:

84 • capítulo 4
 S/N/NA REF. W/P OBS.

P3 - O sistema é administra-
do por equipe competente.

P4 - O sistema é monitorado
por equipe competente.

P5 - O sistema está apropria-

damente instalado.

C4 - Controle de acesso às
transações:

P6 - Avaliar o procedimen-
to que determina o nível
de acesso do usuário às
transações.

C5 - Controle sobre a utilização

de software:

P7 - Verificar se existem
controles para detecção
e eliminação de vírus de
computador.

C6 - Controle sobre a utilização

de redes:

P8 - Verificar se o acesso
físico ao servidor da rede é
restrito.

Tabela 4.3  –  Programa de auditoria de segurança de acesso lógico (adaptado de IMONIA-

NA, 2008).

capítulo 4 • 85
 Caso os controles de acesso lógico não sejam efetivos ou não existam, pode-
se concluir que o sistema está com risco de perda de dados, vazamento de infor-
mação, entre outros danos que podem ser causados à organização (IMONIANA,
2008).
O sistema deve ser construído considerando-se que seu administrador não
tenha permissão ou não possa de maneira alguma fazer alterações nos logs,
para que este não possa efetuar fraudes e apagar as provas posteriormente
(CHAMPLAIN, 2003).

4.4  Auditoria de aquisição, desenvolvimento,

documentação e manutenção de sistemas

Muitas vezes, quando uma organização necessita de um software para seu ge-
renciamento ou para melhora de algum serviço, surge uma dúvida: deve-se
comprar este software pronto ou desenvolver o próprio software?
Normalmente, softwares prontos são mais baratos, porém é preciso avaliar
se algum dos softwares disponíveis no mercado supre as necessidades da or-
ganização. Neste caso, é necessário considerar a viabilidade econômica, ope-
racional e técnica para se decidir se é viável a aquisição ou o desenvolvimento
do software.
Em caso de aquisição de software, é necessário que as seguintes ações se-
jam tomadas:
•  planejamento das aquisições;
•  documentação dos requisitos;
•  cotação, ofertas e propostas;
•  seleção da fonte (melhor proposta);
•  contrato e relacionamento com o fornecedor;
•  fechamento de contrato.

O roteiro da auditoria (papel do auditor), neste caso, de acordo com o guia

PMBOK (Project Management Body Of Knowledge), é verificar:
•  aprovação para início do projeto;
•  a definição dos requisitos;

86 • capítulo 4
 •  a declaração do escopo (tudo que é gerado pelo sistema, como arquivos,
telas, relatórios);
•  a definição das atividades do projeto e as interdependências;
•  o cronograma do projeto;
•  o orçamento do projeto;
•  a definição da equipe e outros recursos;
•  as necessidades de treinamento;
•  o plano de implantação;
•  o plano de contingência e riscos;
•  atualização da biblioteca de produção (arquivos).

Além das etapas demonstradas anteriormente, é necessário que se efetue

um teste do sistema. Este teste visa garantir que o software atenda aos requisi-
tos funcionais e não funcionais descritos na especificação de requisitos.
Outra necessidade é a de documentar o sistema. Esta documentação deve
seguir linguagens, padrões, modelos e normas específicas para cada tipo de
software e tecnologia empregada em seu desenvolvimento. O auditor verifica
se a documentação:
•  está em uma biblioteca;
•  segue padrões;
•  apresenta narrativas, fluxograma do sistema e arquivos;
•  tem manual de operação e do usuário.

O objetivo específico da auditoria, neste caso, de acordo com Imoniana

(2008), é verificar se:
•  há a necessidade de um sistema novo;
•  se os usuários podem fazer recomendação entre aquisição desenvolvi-
mento interno;
•  se as funcionalidades, a operacionalidade, a tecnologia, a segurança e o
custo-benefício são esclarecidos em caso de aquisição;
•  se os usuários são treinados para utilizar o sistema;
•  se a manutenção pode ser feita sem a interrupção da operação;
•  se a documentação está disponível.

capítulo 4 • 87
 Após a auditoria, deve-se elaborar relatório preliminar. Para auxílio nesta
tarefa, o checklist apresentado na tabela 4.4 contém alguns exemplos para ava-
liação dos controles.

S/N/NA REF. W/P OBS.

C1 - Procedimentos para elabo-

ração de requisitos e declara-
ção de escopo, visando suporte
ou mudanças:

P1 - Verificar se os usuários
estão envolvidos no processo.

P2 - Verificar se o gerente
de projetos está devidamente
identificado.

P3 - Verificar se as reuniões
são documentadas em atas.

C2 - Procedimentos para o
envolvimento de usuários na
seleção de sistemas:

P4 - A decisão para a aquisi-

ção é feita analisando critério
de custo/benefício.

C3 - Procedimentos para envol-

vimento do usuário na seleção,
especificação ou modificação
de sistemas:

88 • capítulo 4
 S/N/NA REF. W/P OBS.

P5 - Os usuários são convida-

dos a descrever as caracte-
rísticas ou mudanças de que
necessitam.

C4 - Procedimentos que
determinam prioridades para
projetos de desenvolvimento e
manutenção:

P6 - Mudanças críticas são

classificadas como de alta
prioridade.

P7 - Mudanças no sistema
são executadas na ordem
correta.

P8 - Mudanças nas priori-

dades e cronograma são
comunicadas aos usuários.

C5 - Há procedimentos para
rever as especificações dos
projetos por pessoal de opera-
ção, segurança e suporte?

C6 - A organização desen-
volve ou modifica sistemas
internamente:

capítulo 4 • 89
 S/N/NA REF. W/P OBS.

P9 - Programas são desen-

volvidos seguindo padrões de
programação e orientações
da organização.

C7 - Procedimentos para testar

aplicativos novos ou que sofre-
ram mudanças:

P10 - Testes unitários.

P11 - Testes de entrada e

saída de dados.

P12 - Testes das interfa-

ces com outros sistemas
(integração).

P13 - Participação dos usuá-

rios nos testes.

C8 - Manutenção de do-
cumentação para sistemas
significativos:

P14 - A documentação é
atualizada.

P15 - A documentação é
suficientemente detalhada
para dar suporte a futuras
mudanças.

90 • capítulo 4
 S/N/NA REF. W/P OBS.

C9 - Projetos de manutenção
são executados internamente
pela organização:

P16 - A manutenção de
programas está sujeita aos
padrões de programação.

Tabela 4.4  –  Programa de auditoria de aquisição, desenvolvimento, manutenção e docu-

mentação de sistemas. Fonte: IMONIANA, 2008. Adaptado.

Conforme apresentado na tabela 4.4, pode-se perceber que os controles re-

ferem-se, especificamente, a:
•  C1: especificação do sistema;
•  C2, C3, C4 e C5: aquisição de sistemas;
•  C6: programação;
•  C7: teste;
•  C8: documentação;
•  C9: manutenção.

4.5  Auditoria de operação

Para que se possa auditar as operações de sistemas e computadores, o auditor
deve conhecê-las. Algumas das operações mais comuns apresentadas por Imo-
niana (2008) são:
•  inicialização do sistema;
•  desligamento do sistema;
•  monitoramento dos sistemas e redes;
•  plano de capacidade da TI;
•  gerenciamento de bibliotecas e backups;
•  automação da produção;
•  coordenação e programação de atualização de equipamentos;

capítulo 4 • 91
 •  plano de recuperação de desastres;
•  gerenciamento do service desk.

O principal objetivo da auditoria de operações é verificar a existência de con-

troles que garantam que as operações da organização estejam em conformidade.
Os pontos abordados na tabela 4.5 apresentam exemplos de checklist para
auxílio ao auditor, lembrando que, na primeira coluna em branco, o auditor
deve assinalar a existência do controle, na segunda coluna deve referenciar do-
cumento que comprove a existência do controle, e na terceira coluna em bran-
co deve fazer suas observações.
Cada controle apresentado na tabela 4.5 pode ter seus desdobramentos
mais detalhados, para que assim o auditor possa ter mais embasamento para a
emissão do relatório.

S/N/NA REF. W/P OBS.

C1 - Controle sobre o processo

operacional.

C2 - Controles sobre o
monitoramento.

C3 - Controles sobre as entra-

das offline.

C4 - Controles sobre a identifi-

cação e correção de problemas.

C5 - Controles de restart e
recovery.

C6 - Controles que evitem que

operações do dia a dia sejam
interrompidas.

Tabela 4.5  –  Programa de auditoria de operações Fonte: IMONIANA, 2008. Adaptado.

92 • capítulo 4
4.6  Auditoria de suporte técnico
A função de suporte técnico é a de implantar e dar apoio a usuários no que diz
respeito a equipamentos, sistemas e aplicações de informática.
As funções de suporte são definidas por Imoniana (2008) em dois tipos: roti-
neiras e esporádicas. As funções rotineiras definidas pelo autor são:
•  gerenciamento do service desk;
•  resolução de problemas de instalação de redes;
•  monitoramento das ocorrências;
•  treinamento de usuários;
•  manutenção preventiva de equipamentos;
•  substituição de equipamentos obsoletos;
•  cuidar da segurança da informação.

São definidas por Imoniana (2008) como algumas das funções esporádicas
do suporte técnico as seguintes:
•  instalação de utilitários;
•  manutenção dos sistemas operacionais;
•  instalação de upgrades;
•  avaliação de software para aquisição;
•  padronização dos equipamentos e dos recursos de tecnologia
da informação.

As funções acima descritas (rotineiras e esporádicas) podem variar depen-

dendo do ambiente da organização e do organograma em que estão inseridos
os funcionários de suporte técnico.
A auditoria de controles de suporte técnico verificará se os recursos de TI da
organização estão sendo adequadamente utilizados.
Como um checklist para auxílio ao auditor, tem-se o questionário apre-
sentado na tabela 4.6, que traz algumas possíveis questões levantadas por
Imoniana (2008).

capítulo 4 • 93
 S/N/NA REF. W/P OBS.

C1 - Os sistemas operacionais
processam aplicativos relevan-
tes ao negócio?

C2 - Existem procedimentos
padronizados para aquisição de
utilitários?

C3 - Há uma equipe de suporte

técnico que efetua a manuten-
ção dos sistemas operacionais
e outros softwares?

C4 - A equipe de suporte técni-

co treina os usuários para uso
pleno dos recursos?

C5 - A equipe de suporte técni-

co tem apoio de service desk?

Tabela 4.6  –  Programa de auditoria de controles de suporte técnico. Fonte: IMONIANA,

2008. Adaptado.

4.7  Auditoria de aplicativos

Os aplicativos, ou sistemas aplicativos, são aqueles que executam as transações
rotineiras da organização. A auditoria visa checar se os controles internos estão
alinhados ao negócio, isto é, se o funcionamento dos aplicativos estão em con-
formidade com a expectativa.
Sejam os aplicativos adquiridos externamente ou desenvolvidos interna-
mente na organização, a auditoria de aplicativos deve checar as conformidades.

94 • capítulo 4
 A auditoria dos sistemas aplicativos pode utilizar-se de algumas técnicas.
Dentre elas é válido citar algumas, como:
•  observação;
•  revisão documental;
•  testes dos controles internos;
•  testes dos controles programados.

São verificadas ainda as estruturas dos controles e também são efetuados

testes das transações.
Os pontos que devem ser contemplados pela auditoria, segundo Imoniana
(2008), são:
•  apontamento dos sistemas-chave: focar a atenção do auditor para os siste-
mas mais importantes da organização;
•  descrição do sistema: descreve a finalidade do sistema;
•  descrição do perfil: especifica se o sistema foi desenvolvido internamen-
te na organização ou adquirido e também outros detalhes, como o volume
de transações;
•  documentação do processamento: identifica o processamento das
informações-chave;
•  descrição de riscos: verifica-se a existência de plano de contingência e re-
cuperação de desastres.

Os objetivos da auditoria de aplicativos são definidos por Imoniana (2008)

de forma global e específica. Os objetivos globais definidos são:
•  integridade: confiança nas transações;
•  confidencialidade: informações são disponibilizadas apenas a quem é
de direito;
•  privacidade: usuário tem acesso apenas às funções pertinentes a seu perfil;
•  acuidade: dados de entrada no sistema são verificados quanto à
sua consistência;
•  disponibilidade: sistema está e sempre estará disponível;
•  auditabilidade: sistema documenta as transações e registra logs;
•  versatilidade: os sistemas têm interfaces amigáveis;
•  manutenibilidade: a manutenção é padronizada e tem documenta-
ção atualizada.

capítulo 4 • 95
 No que diz respeito aos objetivos específicos, a auditoria deve verificar, se-
gundo Imoniana (2008), os seguintes aspectos:
•  se há coerência entre as operações da organização e as transa-
ções registradas;
•  se há coerência entre a legislação, os princípios da organização e as tran-
sações registradas;
•  se são aplicados uniformemente os princípios nos diversos sistemas;
•  se os relatórios refletem o resultado das transações;
•  se o sistema integra-se de forma completa com outros sistemas-chave.

Um checklist nos moldes de um questionário, como visto nos itens anterio-

res, pode ser aplicado também para a auditoria de sistemas aplicativos. Sendo
assim, o auditor deve elaborá-lo com base nos conhecimentos sobre a organi-
zação, sobre tecnologia da informação, sobre os aplicativos que está auditan-
do, entre outros conhecimentos necessários para que se elabore um questio-
nário eficaz.

4.8  Auditoria de eventos

A auditoria de eventos tem como objetivo a coleta de dados de registros refe-
rentes à eventos ocorridos em recursos de tecnologia da informação (SANTOS
JUNIOR, 2008).
Os pontos a serem auditados quando da ocorrência de um evento de entra-
da e saída de um sistema, segundo Santos Junior (2008), são:
•  endereço de origem: endereço IP de quem acessou o sistema;
•  máquina de origem: máquina utilizada por quem fez o acesso;
•  identificação de usuário: identificação única em caso de usuário cadas-
trado no sistema;
•  data e hora de entrada: momento em que o usuário se conecta ao sistema;
•  data e hora de saída: momento em que o usuário sai do sistema;
•  identificador de sessão: em qual sessão o usuário está logado no sistema.

Existem também os eventos transacionais, que identificam e registram as

ações tomadas por usuários do sistema, como, por exemplo, quando um funcio-
nário adentra ao sistema para efetuar um registro de novo produto no estoque.

96 • capítulo 4
 EXEMPLO
A tabela abaixo exibe um exemplo de evento de acesso ao sistema registrado:

Número do evento 115487

IP de origem 192.168.2.50

Data de acesso 10/08/2015

Horário de acesso 14:54:11

Data de saída 10/08/2015

Horário de saída 15:25:33

Máquina PC-013

Sessão 13254321824

ATIVIDADES
01. Sobre as redes de computadores, podemos dividi-las em três tipos. Quais são estes
tipos de rede? Explique resumidamente cada tipo.

02. Sobre a decisão de adquirir ou desenvolver internamente um sistema, quais aspectos

devem ser considerados?

03. Que tipo de auditoria direcionada verifica se os recursos de TI estão sendo utilizados de
forma correta?

04. Dê um exemplo do uso de biometria com auxílio de senha para controle de acesso
a sistemas.

05. Dê um exemplo de versatilidade do sistema, um dos objetivos da auditoria de aplicativos.

capítulo 4 • 97
 REFLEXÃO
As abordagens apresentadas neste capítulo são específicas para cada tipo de auditoria direcio-
nada, portanto pode-se observar uma grande quantidade de questionários e itens práticos do
dia a dia do auditor, além de conceitos teóricos e informações pertinentes para a área de tecno-
logia da informação. É importante o aluno absorver informações sobre a prática da auditoria em
ambientes distintos relacionados à tecnologia da informação, para que se possa ter uma visão
abrangente sobre o processo de auditoria e o funcionamento das áreas de TI das organizações.

LEITURA
O livro de auditoria de sistemas escrito por Joshua Onome Imoniana é um dos mais utilizadas
e famosas referências na área. Os questionários abordados nesse livro são adaptações do
livro de Imoniana, e para a aquisição de conhecimento em formulários e questionários mais
completos, nesta etapa do curso, sua leitura é altamente recomendada.
IMONIANA, Joshua Onome. Auditoria de Sistemas de Informação. 2. ed. São Paulo:
Atlas, 2008. 207 p.

REFERÊNCIAS BIBLIOGRÁFICAS
CHAMPLAIN, Jack J.. Auditing information systems. 2. ed. Hoboken: Wiley, 2003.
CORDEIRO, Cláudio Marcelo Rodrigues. Testes em auditoria: uma revisão conceitual aplicável na
prática. Disponível em: <http://www.portaldeauditoria.com.br/artigos/testesemauditoria.htm>. Acesso
em: 26 ago. 2015.
GIL, Antonio de Loureiro. Auditoria de computadores. 5. ed. São Paulo: Atlas, 2000. 236 p.
HALL, James A.. Information Technology Auditing and Assurance. 3. ed. Mason: South-
western Cengage Learning, 2011.
IMONIANA, Joshua Onome. Auditoria de Sistemas de Informação. 2. ed. São Paulo: Atlas, 2008.
207 p.
SANTOS JUNIOR, Alfredo Luiz dos. Quem mexeu no meu sistema? Rio de Janeiro: Brasport, 2008.
STALLINGS, William. Criptografia e Segurança de Redes: Princípios e Práticas. 4. ed. São Paulo:
Pearson Prentice Hall, 2008.
WIKIPEDIA. Controle de acesso. Disponível em: <https://pt.wikipedia.org/wiki/Controle_de_
acesso>. Acesso em: 31 ago. 2015.

98 • capítulo 4
 5
Relatórios
e Pacotes de
Auditoria
A comunicação dos resultados da auditoria é uma fase muito importante do
processo. A emissão de relatórios de qualidade e concisos dão credibilidade
à auditoria e ao trabalho do auditor. Neste capítulo são apresentadas diver-
sas técnicas de informações acerca da redação de relatórios de auditoria. São
apresentados também alguns softwares e pacotes que auxiliam no processo de
auditoria, assim como a metodologia de avaliação para que seja selecionado e
adquirido o software que realmente é necessário para a execução da tarefa.

OBJETIVOS
Com a leitura deste capítulo, o aluno estará apto a:
•  aplicar conceitos e aspectos gerais e específicos sobre os relatórios de auditoria;
•  redigir relatórios de auditoria seguindo uma série de normas e procedimentos para que os
relatórios sejam produzidos com qualidade; e
•  avaliar e selecionar os melhores pacotes e softwares disponíveis no mercado para o auxílio
no processo de auditoria de sistemas.

100 • capítulo 5
5.1  Emissão de relatórios
A comunicação dos resultados do processo de auditoria de sistemas pode ser
feita de forma verbal ou escrita. A comunicação verbal geralmente ocorre du-
rante o processo de auditoria, sendo que estas comunicações precisam ser for-
malizadas posteriormente por meio de relatório de auditoria.
Dentre os objetivos dos relatórios de auditoria de sistemas, destacam-se:
•  apontamento de falha em ponto de controle;
•  documentação do processo de auditoria; e
•  em caso de auditorias complexas, apresentar resultados parciais.

De acordo com Imoniana (2008), os relatórios podem ser emitidos em diver-

sas etapas da auditoria. São elas:
•  no momento da constatação de fato relevante que possa trazer prejuízos e
necessita de atenção imediata (correção urgente);
•  gradativamente durante o processo de auditoria, geralmente ocorre
em auditoria interna com enfoque construtivo, com o objetivo de aprimorar
a gestão;
•  após a conclusão dos trabalhos, podem ser emitidos relatórios prelimina-
res, porém, com o auditor ou equipe de auditoria ainda em campo;
•  ao final do trabalho de auditoria de sistemas, chamado de relatório final.

Anterior à emissão do relatório final, é altamente recomendado que se emi-

ta uma carta de encaminhamento do rascunho do relatório final para o audita-
do. Esta carta é emitida pelo gerente da auditoria (ou responsável) a quem for
de direito e nela é solicitada a compreensão ou não por parte do auditado sobre
as falhas encontradas durante o processo de auditoria de sistemas, a revisão e
inclusão de comentários sobre aquilo que foi identificado pelo auditor.

EXEMPLO
A seguir um exemplo de estrutura de uma carta de encaminhamento de rascunho para um
cliente fictício denominado TESTEAUDIT.

capítulo 5 • 101
 TESTEAUDIT
A/C do Sr. João da Silva
Gerente de TI

Ref.: Relatório sobre Revisão de Sistemas - 2015

Estamos enviando um relatório preliminar em forma de rascunho, conforme acordado

com o sr. João Neves, contendo nossas observações e recomendações resultantes das ava-
liações e revisões no sistema GERENCIAR (nome do sistema), e dos controles (descrever os
controles), efetuada em agosto de 2015.

Solicitamos que o relatório seja revisado e que sejam comentados os pontos identifi-
cados em relação à concordância ou discordância com as nossas observações, as ações
corretivas e seus prazos.

Quaisquer dúvidas sobre o relatório estamos à disposição para esclarecimentos.

Atenciosamente,

Fabio Almeida
Gerente de auditoria de sistemas

Os comentários a serem feitos pela gerência (auditado) a respeito do rascu-

nho devem ser voltados para os seguintes objetivos:
•  sobre a concordância ou discordância das falhas ou desvios encontradas
pela auditoria;
•  sobre a abordagem de correção que será implementada;
•  se necessário, estipular um prazo para que a correção seja efetuada.

Em caso de discordância com as falhas ou desvios apontados pela auditoria,

o auditado deve então tecer seus comentários com o objetivo de convencer a au-
ditoria de que o que foi identificado não se trata de uma falha ou desvio, e que
não há necessidade de tomar medidas de correção para tal item.
O rascunho do relatório deve conter os seguintes itens:

102 • capítulo 5
 •  o objetivo;
•  as considerações sobre o ambiente de tecnologia da informação;
•  os pontos para observação.

Na descrição do objetivo do relatório, podem ser descritos os objetivos da

auditoria de sistemas efetuada no ambiente.
As considerações a serem feitas sobre o ambiente de TI são descritas de for-
ma geral, apontando a qualidade dos recursos de TI e seu ambiente.
Os pontos para observação são compostos dos controles gerais que foram
auditados. Para cada controle (ponto que foi auditado), têm-se, de acordo com
Imoniana (2008):
•  observação;
•  consequências: o risco que a organização corre devido a este fato observado;
•  recomendações: sugestões feitas pelo auditor;
•  comentários da gerência: concordância ou discordância sobre o fato ob-
servado e prazo para correção.

No campo de observação, o auditor descreve, sobre o controle auditado, se

este está adequado ou não. Os detalhes e as constatações também são descri-
tos, apontando as falhas e desvios, se for o caso.
Nas consequências o auditor descreve o risco que a organização está corren-
do em relação ao que foi observado no item anterior, como perdas financeiras,
de credibilidade, entre outras. Esta descrição é feita de forma detalhada, apon-
tando também a possibilidade de falta de planos de contingência.
A etapa de recomendação consiste na descrição de ações a serem tomadas
para que as observações negativas feitas anteriormente sejam corrigidas, com o
objetivo dos riscos identificados na etapa de consequências sejam sanados ou
ao menos reduzidos a um patamar tolerável. A criação de planos de contingên-
cia pode ser uma recomendação do auditor.
O relatório (rascunho) a ser entregue para a gerência do auditado consiste
destas partes apresentadas até o momento. A etapa de comentários da gerência
é preenchida geralmente após uma discussão prévia e então a gerência faz seus
comentários. Estes comentários são feitos em teor de resposta sobre o que foi
escrito pelo auditor.
Como pode ser observado na figura 5.1, que apresenta as etapas para a ela-
boração de relatórios, após a aprovação do rascunho emitido pela equipe de

capítulo 5 • 103
auditoria por parte dos envolvidos (auditado), o relatório final pode ser en-
tão redigido.

• Emite
relatório de
Auditor
auditoria
(rascunho)

• Aprova o
Envolvidos relatório
(rascunho)

• Emite versão
final do
Auditor
relatório de
auditoria

Figura 5.1  –  Fases da emissão de relatórios.

A versão final do relatório de auditoria contém todos os documentos que fo-

ram emitidos pela auditoria. Estes documentos devem ser acompanhados (fase
de follow-up) até a sua conclusão definitiva.
Para se redigir um bom relatório, é necessário que o auditor se atente para
uma série de detalhes, visto que este documento será lido e analisado por pro-
fissionais de alto escalão.
O relatório deve descrever as falhas identificadas de forma clara, direta e su-
cinta, com o objetivo de transparecer segurança e autoridade sobre o assunto.
Segue algumas das dicas para a redação de um bom relatório de auditoria:
•  usar voz ativa;
•  usar frases curtas;
•  não emitir opinião;
•  não utilizar termos ofensivos;
•  quantificar resultados;
•  explicar siglas na primeira citação.

104 • capítulo 5
 A opinião do auditor, neste momento, não deve ser transcrita para o relató-
rio. Ele deve ater-se a fatos e recomendações.
Ao mencionar algum funcionário da organização auditada, não deve-se
referenciá-lo com termos que possam vir a denegrir sua imagem, como, por
exemplo: incompetente, preguiçoso, entre outros.
A quantificação de resultados significa exemplificar, com números, os fa-
tos constatados.
Na área de tecnologia da informação existem muitas siglas. Mesmo que se-
jam termos corriqueiros, deve-se, no relatório, explicar cada uma delas no pri-
meiro momento em que forem utilizadas.
O relatório, para ser escrito, necessita de atenção do auditor a uma série de
pontos importantes, como os vistos acima. Além destes pontos, algumas pon-
derações devem ser feitas a fim de que este relatório obtenha sucesso.
O conhecimento de quem será o leitor é muito importante para a escrita do
relatório. Dependendo de quem for, a escrita deve ser alterada quanto a termos
técnicos, definições, entre outras mudanças necessárias.
A definição de termos leva em consideração, além do leitor do relatório, o
nível de detalhamento desejado e necessário para tal definição.
É necessário também ponderar o que o leitor deve saber. Ao ponderar este
item, é necessário averiguar se as informações necessárias sobre os fatos estão
redigidas no relatório e se estas estão fáceis de serem obtidas.
De acordo com a Auditoria-geral da UFMG (2013), um relatório de auditoria
deve se ater aos seguintes atributos:
•  tempestividade: quando a recomendação é feita a tempo de ser adotada;
•  clareza: quando a sua estrutura e a terminologia utilizadas podem ser
compreendidas por qualquer pessoa;
•  concisão: quando se utilizada de linguagem clara e precisa, atendo-se
ao essencial;
•  completude: quando se inclui todos os fatores relevantes, sem omissões;
•  objetividade: quando a recomendação expressa conteúdo claro e direto,
sem deixar dúvidas do que é para ser resolvido;
•  coerência: quando sua estruturação segue um padrão;
•  imparcialidade: quando a recomendação restringe-se ao problema efeti-
vamente identificado;
•  convicção: quando o apontamento de fatos e recomendações é entendido
da mesma maneira por qualquer leitor.

capítulo 5 • 105
 O nível de detalhamento também é muito importante para a redação do
relatório. Quando se detalha além do necessário, a leitura se torna maçante.
Porém, se os detalhes necessários não estiverem presentes, pode-se não ter o
entendimento completo por parte do leitor.
Na emissão do relatório de auditoria têm-se, basicamente, duas fases:
•  primeira audiência;
•  segunda audiência.

Na primeira audiência são valorizados os detalhes e a recomendação. O

relatório passa por pessoal responsável por atuar nas recomendações, isto é,
os executores que serão responsáveis por corrigir os problemas identificados
na auditoria.
A segunda audiência é a versão que é lida pela alta administração da organi-
zação. Nesta fase, o relatório tem as falhas e recomendações de forma resumi-
da. Detalhes técnicos e de execução são omitidos.
Para auxílio na elaboração do relatório de auditoria, pode-se acompanhar o
seguinte checklist:
•  esquematização: é importante fazer um esquema daquilo que se pretende
escrever, como um planejamento da escrita;
•  conclusão: conclua antes mesmo da avaliação dos pontos de controle, a
nota do relatório geralmente é o objetivo principal do leitor;
•  posicionamento: colocar-se no lugar do leitor é muito importante para
a escrita do relatório e para melhorar a comunicação, porém é necessário ter
bom senso para identificar o que o leitor está querendo;
•  confiança: não ser prolixo, demonstrar conhecimento sobre o assunto;

CONEXÃO
O site Portal da Auditoria apresenta uma série de erros a serem evitados na escrita de relató-
rios de auditoria. http://www.portaldeauditoria.com.br/auditoria/relatorio-auditoria-erros.htm

Para a escrita do relatório final, é necessário que se utilize de um formato

padronizado e uma estrutura bem definida. Um exemplo de estrutura de rela-
tório de auditoria é dado por:
1. memorando (capa)
2. relatório final

106 • capítulo 5
 2.1. objetivos
2.2. escopo
2.3. abordagem
2.4. sumário e conclusão
2.5. assinaturas
2.6. falhas e recomendações
2.7. follow-up de auditorias anteriores
2.8. anexo - vista geral do sistema

3. relatório resposta: concordância ou discordância pelo auditado e ações

corretivas a serem tomada com seus devidos prazos

Nesta estrutura dada como exemplo, o campo que deve-se ter mais cautela
e atenção ao ser escrito é a etapa 2.6, em que se descrevem as falhas identifi-
cadas pelos auditores, as consequências que estas falhas podem trazer para
a organização e as recomendações feitas pelo auditor para que as falhas se-
jam corrigidas.
Na etapa 3, relatório resposta, o auditado faz seus comentários acerca da-
quilo que foi identificado como falha, concordando ou discordando da audi-
toria, e, em caso de concordância, descreve-se a maneira como as falhas serão
corrigidas com seus respectivos prazos, para que na etapa de follow-up o audi-
tor possa verificar se aquilo que foi descrito foi cumprido dentro do prazo.

5.2  Avaliação de software de auditoria de

sistemas

Em todas as esferas de negócios, é de grande importância que se procure por

alternativas que objetivam maior agilidade dos processos, redução de custos e
a busca por vantagens competitivas. Na auditoria de sistemas não é diferente, e
uma das principais alternativas é o uso de ferramentas que proporcionem me-
lhoria no processo de auditoria. Estas ferramentas, na maioria dos casos, são
softwares de gestão de auditoria.

capítulo 5 • 107
 Há softwares generalistas disponíveis no mercado, também conhecidos
como pacotes, que têm como objetivo facilitar e agilizar o processo de audito-
ria, podendo trazer também outras vantagens, como segurança da informação
de auditoria, integração de equipe, registros com facilidade para buscas, entre
muitas outras.
Para a aquisição de um software que visa facilitar processos e reduzir cus-
tos, muitos fatores devem ser ponderados, dependendo do objetivo, orçamen-
to, recursos e necessidade da organização.
Na implantação de qualquer iniciativa de informatização, deve-se conside-
rar aspectos relevantes referentes à organização. O autor Imoniana (2008) cita
os seguintes:
•  cultura;
•  objetivos;
•  missão;
•  programas de trabalho;
•  características dos produtos e serviços oferecidos;
•  necessidades e interesse por parte dos usuários pela informação;
•  plataforma disponível na organização (hardware e software);
•  capacidade de atualização da plataforma;
•  recursos humanos disponíveis.

Após as considerações apresentadas, aplica-se um método de seleção do

pacote de auditoria a ser adquirido, em que são estudadas as opções que o mer-
cado oferece para que a decisão tomada seja a mais apropriada para o cenário
da organização.

5.2.1  Método de seleção

O método para seleção do pacote de auditoria de sistemas a ser utilizado consi-

dera vários fatores e envolve estudos e análises de características destes paco-
tes. Alguns pontos importantes devem ser observados e analisados por quem
vai selecionar o pacote e entre eles, os destacados por Imoniana (2008) são:
•  análise de documentos que demonstrem experiências anteriores do pa-
cote no mercado;
•  análise e leitura de catálogos, prospectos, folders e documentação especí-
fica fornecida pelo fabricante;

108 • capítulo 5
 •  entrar em contato com o fabricante do software com o objetivo de obter
informações que possam ser úteis para o processo de escolha;
•  visitar usuários dos produtos;
•  trocar informações com outras organizações que já utilizam o produto;
•  analisar a capacidade institucional da empresa que fornece o produto,
principalmente quanto à infraestrutura de TI, seus produtos e serviços.
•  analisar a idoneidade do fornecedor do produto para que não seja contra-
tada uma empresa sem credibilidade e comprometimento com o cliente.

Esta análise é feita considerando os diversos pacotes de auditoria de siste-

mas disponíveis no mercado. A coleta de dados sobre estes pacotes pode ser
feita por meio de visitas de representantes, questionários enviados aos fornece-
dores, reuniões, entre outras maneiras. Estes dados devem ser referentes a uma
série de informações pertinentes ao software avaliado, como, por exemplo:
•  desempenho;
•  versatilidade;
•  consistência;
•  rastreabilidade;
•  compatibilidade;
•  automação de processos.

Sobre os pacotes a serem analisados, deve-se considerar alguns aspectos.

Cada um deles se refere a uma esfera da organização e, para que o pacote se-
lecionado seja o que mais satisfaz às necessidades, deve ser cuidadosamente
examinado. Os aspectos definidos por Imoniana (2008) são:
•  aspectos funcionais;
•  aspectos de gestão;
•  aspectos relacionados à tecnologia;
•  aspectos de fornecimento de suporte;
•  estrutura dos custos.

Os aspectos funcionais são referentes às funcionalidades do sistema e é

importante a verificação destas funcionalidades para concluir se o software
permite e auxilia de maneira satisfatória o processo de auditoria de sistemas.
Alguns destes requisitos são os seguintes:
•  armazenamento de imagens referentes ao processo;
•  permissão ao auditor tecer seus comentários;

capítulo 5 • 109
 •  acesso on-line;
•  auxiliar na emissão de relatórios;
•  controlar arquivos gerados por outros softwares;
•  extração direta de informações de bancos de dados;
•  apoiar a auditoria de forma remota;
•  trabalhar com working papers.

CONEXÃO
O Instituto dos Auditores Internos do Brasil (IIA) tem um site com diversas informações re-
levantes como notícias, e eventos além de informações sobre cursos e certificações em
auditoria interna. http://www.iiabrasil.org.br/

Os aspectos de gestão são referentes às características gerais e de planeja-

mento do processo de auditoria. Segundo Imoniana (2008), os aspectos de ges-
tão são, dentre outros, os seguintes:
•  apoiar o planejamento dos projetos de auditoria;
•  gerenciar o tempo do auditor;
•  permitir gerenciamento online;
•  customizar legislação no banco de dados de processos.

Os aspectos relacionados à tecnologia são referentes à capacidade

do software:
•  interface amigável (gráfica);
•  segurança dos dados (criptografia);
•  arquitetura de rede que permita o acesso e atualização remotos;
•  mecanismo eficiente de pesquisa (texto);
•  registrar log dos acessos e alterações;
•  integração com outras ferramentas como e-mail;
•  níveis de permissão de acesso: usuários podem apenas ler certos arqui-
vos, outros podem editar, acesso à áreas restritas à apenas alguns usuários, en-
tre outros;
•  permitir importação de documentos de outras plataformas;
•  facilidade para aplicação de treinamento de usuários;
•  controlar acesso simultâneo a arquivos e à base de dados;
•  facilidade de programação e customização.

110 • capítulo 5
 Os aspectos relativos ao suporte dizem respeito ao apoio que o fornecedor
do pacote (software) é capaz de dar ao cliente. De acordo com Imoniana (2008),
estes aspectos são:
•  apoio na implantação do pacote;
•  contrato de manutenção (assistência);
•  disponibilização do código-fonte para que o cliente possa customizar ou
corrigir problemas emergenciais;
•  atualização de versão do software, dando preferência para contratos
sem custos;
•  capacidade de implementação das solicitações feitas pelo cliente;

Sobre o custo da contratação de um pacote de auditoria de sistemas, aspec-

to muito relevante nas organizações, os valores de alguns serviços devem ser
considerados para a escolha do pacote de auditoria de sistemas que melhor
satisfaz as necessidades (inclusive as financeiras) da organização. Devem ser
considerados neste caso, segundo Imoniana (2008), os seguintes aspectos:
•  o valor da licença de uso do software: esta licença pode ser contratada de
várias formas, portanto é necessário que se examine com muita atenção as in-
formações que constam no contrato de licença para evitar surpresas;
•  a taxa de manutenção: valor cobrado pelo fornecedor para que erros e pro-
blemas sejam corrigidos;
•  serviços de customização: pode ser executado pelo fornecedor ou pelo
contratante, dependendo do contrato firmado;
•  serviços de treinamento: pode ser executado pelo fornecedor, pelo contra-
tante ou por empresa terceira que atua apenas na área de treinamento;
•  serviços de apoio na implantação;
•  viagens e diárias: caso o fornecedor precise deslocar funcionários para a
execução dos serviços.

Após o exame das características dos pacotes segundo os diferentes aspec-

tos apresentados, confrontam-se as informações coletadas com as necessida-
des e políticas da organização a fim de que seja feita a melhor escolha quanto à
aquisição do pacote de auditoria de sistemas que irá auxiliar e controlar o pro-
cesso de auditoria na organização.

capítulo 5 • 111
5.2.2  Pacotes disponíveis no mercado

Os softwares de gestão de auditoria de sistemas são uma ferramenta imprescin-

dível para o auxílio no processo de auditoria, principalmente nos dias de hoje.
Alguns destes softwares são apresentados, com descrições de algu-
mas características, para que se possa conhecer um pouco destes pacotes e
suas funcionalidades.
O primeiro é o Audit Automation Facilities (AAF). Este software é proprie-
dade da WJ Informática e é voltado para a gestão de auditoria interna e busca
aumentar a eficiência e a produtividade dos processos com redução de custos
(WJ INFORMÁTICA, 2015).

CONEXÃO
A WJ Informática mantém um blog para maiores informações sobre o AAF.
http://aaf.wj.com.br/blog

As principais funcionalidades do AAF para a fase de execução da auditoria,

de acordo com Imoniana (2008), são:
•  planejamento assistido;
•  auditoria interativa e assistida;
•  revisão dos trabalhos à distância;
•  adaptação à demanda;
•  gestão integrada de auditoria e segurança;
•  diminui consumo de papel;
•  padroniza processos e relatórios da auditoria;
•  controla custos por hora;
•  facilita a adaptação de novos auditores;
•  reduz o tempo no preparo de programas de trabalho.

O AAF apoia também a emissão de relatórios, a fase de follow-up, entre ou-

tros recursos importantes. Na fase de follow-up, as principais características
destacadas por Imoniana (2008) são:
•  permite acesso a dados de auditorias passadas;
•  automatiza a cobrança de soluções;

112 • capítulo 5
 •  disponibiliza os relatórios ao auditado com segurança;
•  disponibiliza informações resumidas sobre as auditorias em andamento.

O sistema AAF permite também a geração de gráficos sobre diferentes infor-

mações, com o objetivo de facilitar a visualização dos dados por parte do audi-
tor e do auditado.
Outro sistema é o Audin, focado em auditoria interna e desenvolvido pela
Dataprev (Empresa de Tecnologia e Informações da Previdência Social). Este
software auxilia as equipes de auditoria no planejamento e execução das tarefas,
além de permitir o monitoramento dos processos pela gerência (IMONIANA, 2008).
O sistema AUDITAR, voltado para a gestão de auditorias no setor público,
cobre todas as fases básicas do processo de auditoria. São elas:
•  pré-auditoria;
•  planejamento;
•  execução;
•  emissão de relatórios;
•  monitoramento.

Os principais objetivos do AUDITAR são a otimização, a integração e a pre-

sença nas ações dos auditores (participação) nas ações típicas de auditoria de
gestão pública (IMONIANA, 2008).
A empresa alemã SAP (Systeme, Anwendungen und Produkte, que em por-
tuguês significa Sistemas, Aplicações e Produtos), é a desenvolvedora do soft-
ware SAP ERP (Enterprise Resource Planning, em português Planejamento de
Recursos Empresariais). Este software é oferecido de forma modularizada. Um
destes módulos é o AIS (Audit Information Systems), que é voltado para a audi-
toria de sistemas.

CONEXÃO
Mais informações sobre a empresa SAP e seus módulos encontram-se no site da empresa.
http://www.sap.com/brazil/

capítulo 5 • 113
 Algumas ferramentas voltadas para a análise de dados são muito utilizadas
no âmbito de auditoria de sistemas. As principais são:
•  ACL (Audit Command Language);
•  IDEA (Interactive Data Extraction & Analysis).

O ACL foi criado e é fornecido pela empresa ACL Business Assurance, que
tem o potencial para analisar grandes bases de dados de diversos formatos
(TERUEL, 2010).
Segundo Imoniana (2008), o ACL é um software de auxílio a auditoria com o
objetivo de melhorar a eficiência de testes de controles, como:
•  identificação de tendências;
•  localizar erros através da comparação de arquivos;
•  verificação de saldos;
•  detecção de pagamentos duplicados;

Desenvolvido pela Caseware Analytics, o software IDEA permite a análise de

dados advindos de diferentes tipos de fontes, além de outras vantagens como
ter uma interface amigável, não ter limites para o número de registros a serem
analisados, manutenção de trilha de auditoria para alterações em arquivos, en-
tre outras (CASEWARE ANALYTICS, 2015).

5.2.3  Avaliação de pacotes de auditoria

O processo de avaliação, segundo Imoniana (2008), deve ser voltado a alguns

fatores técnicos do software, mas também às necessidades da organização e
seus processos de auditoria.
Portanto, de forma resumida e bem semelhante ao processo de aquisição
de dados sobre os pacotes, Imoniana (2008) apresenta alguns elementos que
devem ser avaliados para o auxílio à decisão de qual pacote de auditoria deve
ser adotado pela organização; são eles:
•  performance: a quantidade de tempo para execução das tarefas deve
ser satisfatória;
•  versatilidade: ter integração com diversas plataformas diferentes;
•  consistência: a apresentação de resultados de processamentos deve
ser exata;

114 • capítulo 5
 •  rastreabilidade: deve-se manter um histórico e documentar as ações exe-
cutadas no sistema;
•  compatibilidade: deve-se ter a capacidade de acesso e leitura de diferen-
tes arquivos e bases de dados;
•  facilidade de uso: a interface com o usuário não deve ser confusa ou de-
mandar estudo para operação, visto que deve ser direcionada a qualquer pessoa;
•  automação de processo: execução de tarefas automaticamente, deman-
dando menos esforço por parte do usuário.

LEITURA
O livro de Imoniana (2008) apresenta, na página 164, um checklist para auxílio na avaliação
de pacotes de auditoria.
IMONIANA, Joshua Onome. Auditoria de Sistemas de Informação. 2. ed. São Paulo:
Atlas, 2008. 207 p.

Não é comum encontrar sistemas que tenham todas as características abor-

dadas de forma plena, porém, a avaliação pode ser feita pesando os itens que
mais são necessários para a execução das auditorias da organização em questão.

ATIVIDADES
01. Por que se deve emitir um relatório rascunho antes do relatório final?

02. Cite três objetivos do uso de softwares (pacotes) de auditoria.

REFLEXÃO
Neste capítulo foi descrita a fase de comunicação dos resultados da auditoria por parte do
auditor, isto é, a emissão de relatórios. Alguns exemplos foram dados sobre como redigir
um bom relatório final de auditoria, porém vale observar que o bom senso do auditor deve
prevalecer na elaboração do documento, lembrando de sempre se colocar no lugar do leitor
na hora de escrever, para que o relatório possa ser entendido sem dificuldades. O exemplo

capítulo 5 • 115
de estrutura de relatório apresentado é apenas uma ideia de como pode ser montado um re-
latório final, portanto, variações podem ser adotadas, se necessário. Outro assunto abordado
foram os pacotes de auditoria, softwares que dão suporte aos processos da auditoria de sis-
temas, facilitando, integrando e provendo segurança deles. O método de avaliação apresen-
tado ao final do capítulo sugere atenção na escolha do pacote a ser adquirido pela organiza-
ção com o objetivo de redução de custos e execução do serviço com a qualidade desejada.

LEITURA
O artigo de TERUEL (2010) traz informações precisas e bem resumidas sobre ferramentas
de auxílio a auditores. É interessante conferir o conteúdo do artigo para conhecimento de
outras ferramentas e seu potencial.
TERUEL, Evandro Carlos. Principais ferramentas utilizadas na auditoria de sistemas e
suas características. In: WORKSHOP DE PÓS-GRADUAÇÃO E PESQUISA DO CENTRO
PAULA SOUZA, 5., 2010, São Paulo. Anais do V Workshop de Pós-Graduação e Pesqui-
sa - 2010. São Paulo: Ceeteps, 2010. p. 1 - 10. Disponível em: <http://www.centropau-
lasouza.sp.gov.br/pos-graduacao/workshop-de-pos-graduacao-e-pesquisa/anais/2010/
Trabalhos/gestao-e-desenvolvimento-de-tecnologias-da-informacao-aplicadas/Trabalhos
Completos/TERUEL, Evandro Carlos.pdf>. Acesso em: 31 ago. 2015.

REFERÊNCIAS BIBLIOGRÁFICAS
Auditoria-geral da UFMG. Manual de auditoria interna. Belo Horizonte: Universidade Federal de
Minas Gerais, 2013. Disponível em: <https://www.ufmg.br/auditoria/images/stories/documentos/
manual_2a_verso_revisado.pdf>. Acesso em: 31 ago. 2015.
CASEWARE ANALYTICS. IDEA. Disponível em: <http://www.casewareanalytics.com/products/idea-
data-analysis>. Acesso em: 31 ago. 2015.
IMONIANA, Joshua Onome. Auditoria de Sistemas de Informação. 2. ed. São Paulo: Atlas, 2008.
207 p.
TERUEL, Evandro Carlos. Principais ferramentas utilizadas na auditoria de sistemas e suas
características. In: WORKSHOP DE PÓS-GRADUAÇÃO E PESQUISA DO CENTRO PAULA SOUZA,
5., 2010, São Paulo. Anais do V Workshop de Pós-Graduação e Pesquisa - 2010. São Paulo:

116 • capítulo 5
Ceeteps, 2010. p. 1 - 10. Disponível em: <http://www.centropaulasouza.sp.gov.br/pos-graduacao/
workshop-de-pos-graduacao-e-pesquisa/anais/2010/Trabalhos/gestao-e-desenvolvimento-de-
tecnologias-da-informacao-aplicadas/Trabalhos Completos/TERUEL, Evandro Carlos.pdf>. Acesso
em: 31 ago. 2015.

WJ INFORMÁTICA. Audit Automation Facilities. Disponível em: <http://aaf.wj.com.br/>. Acesso

em: 30 ago. 2015.

GABARITO
Capítulo 1

01. Este tipo de empresa (vendas pela internet) depende muito da disponibilidade dos servi-
ços, pois, se o acesso a esta “loja” estiver prejudicado e o site ficar inacessível, fica impossível
efetuar as vendas.
Uma das ameaças neste caso é a queda de energia elétrica no CPD, tornando assim o site
da empresa inacessível, impossibilitando-o de efetuar vendas, prejudicando o faturamento da
empresa, ocasionando perda financeira.

Capítulo 2

01. Apesar de diversos tipos de controles internos serem importantes para este tipo de sis-
tema, alguns tipos requerem maior atenção, pois são fundamentais para a boa utilização do
sistema e para a saúde da organização. São alguns deles:
•  a segurança de sistemas;
•  a integridade de dados e processos;
•  legibilidade operacional;
•  guarda de registros; e
•  programas de sistemas.
02. A fase de execução da auditoria pode ser dividida em três etapas, cada uma delas com
suas respectivas tarefas. As três etapas são:
•  pré-auditoria;
•  auditoria; e
•  pós-auditoria.

capítulo 5 • 117
03. A diversidade de cenários que podem ser encontrados em uma auditoria de sistemas
torna necessário o desenvolvimento de aplicações especialistas em diversos casos. Como
exemplo, pode-se citar a análise de dados em formato incompatível com os softwares de
mercado. Neste caso, deve-se desenvolver um software que converta os dados para um for-
mato compatível ou até mesmo um software que faça a análise dos dados no formato nativo.

Capítulo 3

01. Das diversas técnicas de auditoria apresentadas neste livro, as que poderiam demandar
o desenvolvimento de programa por parte do auditor são:
•  software para auditoria;
•  teste substantivo;
•  dados de teste;
•  teste integrado;
•  simulação paralela;
•  lógica de auditoria embutida nos sistemas;
•  mapeamento estatístico dos programas;
•  rastreamento dos programas; e
•  análise de log.
02. Embora em algumas outras técnicas o auditor possa estar fisicamente presente na or-
ganização auditada, a obrigatoriedade desta presença se dá no uso das técnicas:
•  visita in loco;
•  entrevista; e
•  teste de observância.
03. A função de programação do backup especificamente do banco de dados é executada
pelo administrador de bancos de dados. O supervisor de restart/recovery pode atuar na recu-
peração dos dados restaurando backups ou auxiliando o administrador de bancos de dados
na tarefa de criar as rotinas de backup.
04. O que pode ser alterado após a implantação definitiva de uma política organizacional
são os procedimentos para que ela seja cumprida, e não seu conteúdo, isto é, alterar “como
fazer”, mas não “o que fazer”.

118 • capítulo 5
Capítulo 4

01. As redes são divididas em três tipos; são eles:

•  internet: rede mundial de computadores, onde geralmente as informações são disponibili-
zadas para qualquer usuário;
•  intranet: rede interna de uma organização, onde o acesso às informações é restrito apenas
à colaboradores; e
•  extranet: rede interna de uma organização com disponibilização de parte dela para acesso
de colaboradores de outras organizações.
02. O processo de decisão entre desenvolvimento ou aquisição de software é baseado em
três aspectos:
•  a viabilidade econômica: desenvolver software é um processo custoso;
•  a viabilidade operacional: em caso de aquisição, verificar se existe software que atende às
necessidades da organização no mercado; e
•  a viabilidade técnica: em caso de desenvolvimento, verificar se a organização tem pessoal
qualificado para o desenvolvimento e manutenção do software.
03. A auditoria que faz a verificação da utilização correta dos recursos de TI é a auditoria de
suporte técnico.
04. Vários exemplos podem ser dados sobre o uso de biometria em conjunto com senha
para controle de acesso. Um deles pode ser a utilização de leitura de impressão digital jun-
tamente com senha numérica, conferindo assim maior segurança, por se tratar de controle
de acesso em duas etapas.
05. Um exemplo de versatilidade do sistema pode ser dado pelo uso de acessibilidade nas
interfaces do sistema. Como exemplo de acessibilidade pode-se ter um sistema que apre-
sente ferramenta que aumenta o tamanho dos caracteres ou que lê as informações para
auxílio a pessoas com deficiência visual;

Capítulo 5

01. A importância do relatório rascunho se dá pela possibilidade de discussão das conside-

rações feitas pelo auditor com o auditado antes da emissão do relatório final, tornando assim
a emissão do relatório final mais fiel e concisa.
02. Como objetivos do uso de softwares na auditoria de sistemas podem-se citar:
•  automatizar tarefas;
•  fazer análise de grande quantidade de dados;
•  manter o controle dos processos e fases da auditoria;
•  controlar o acesso a arquivos;

capítulo 5 • 119
•  reduzir custos;
•  aumentar a agilidade nos processos;
•  entre outros.

120 • capítulo 5