Auditoria de Sistemas da informação - Livro-texto - Unidade II

Prévia do material em texto

53
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
Unidade II
3 O PROCESSO DE AUDITORIA
Neste tópico, iremos tratar especificamente do processo de auditoria. Discussões sobre o que é e como 
um processo de auditoria deve ser incorporado ao ciclo de vida de sistemas serão as pautas principais. 
Também serão levantados aspectos importantes sobre controles de segurança físicos e lógicos, com uma 
série de recomendações e exemplos de uso.
3.1 Pequeno histórico da auditoria
A prática da auditoria remonta à Idade Média, em que era exercida por reis para evitar fraudes e 
roubos. Já nessa época a conferência acontecia de forma dupla e independente. O desenvolvimento do 
comércio foi o gatilho para que a independência nas revisões ganhasse espaço. Garantir a idoneidade dos 
negócios perpetuava a prosperidade, já que as possibilidades de fraudes diminuíam consideravelmente.
As auditorias contábeis buscavam o equilíbrio financeiro das empresas e tiveram início na França, com o 
advento do capitalismo após a Revolução Industrial. Contudo, a consolidação dessa prática se deu na Inglaterra 
com as primeiras empresas e bancos que visavam garantir a estabilidade das empresas e dos negócios.
Figura 35 – Esquema ilustrativo de um processo de auditoria contábil comum
A origem da palavra “auditoria” é o latim auditore, que significa cargo de auditor, lugar onde o 
auditor exerce sua função e análise pericial.
Muito ligada às mudanças da sociedade ao longo do tempo, a auditoria segue a evolução ocorrida nas 
empresas e indústrias até os dias atuais, principalmente na avaliação de quanto vale o que é produzido. 
Por isso, o termo é muito relacionado à área contábil e financeira. Contudo, como pode ser visto neste 
livro-texto, o conceito é muito mais amplo e finca raízes em vários setores da sociedade, sempre 
analisando, medindo e avaliando se os processos, os métodos e as atividades estão sendo executados de 
forma correta e se os resultados são aqueles esperados.
54
Unidade II
3.2 Auditando sistemas
Um dos objetivos primordiais da auditoria é garantir que os processos auditados estejam funcionando 
de acordo com o planejamento e que atendam às necessidades ou expectativas definidas previamente. 
Esse propósito pode ser adaptado para qualquer área de negócios, inclusive sistemas.
Nesta unidade, o termo “sistemas” envolve toda a área de desenvolvimento, utilização, procedimentos 
e organização da TI. Sendo assim, a auditoria de sistemas engloba os processos realizados para 
identificação de riscos no projeto, no desenvolvimento, nos testes, na operação e até no descarte de 
sistemas computacionais.
Em relação à operação, que corresponde às atividades e ao uso diário da TI nas organizações, os 
procedimentos de revisão e avaliação são fundamentais, principalmente em operações críticas.
3.2.1 A revisão na auditoria
Uma revisão, sob a ótica da auditoria, engloba a verificação das atividades e de suas funcionalidades. 
Muitas vezes, acontecem discrepâncias entre as atividades realizadas e as funcionalidades.
 Observação
Projeto, desenvolvimento, testes, operação e descarte representam ciclos 
ou fases pelas quais um projeto ou sistema passa ao longo do tempo. Essa 
sequência temporal é chamada de ciclo de vida de um sistema.
Especificação
DesenvolvimentoDescarte
Operação Implantação
Figura 36 – Esquema do ciclo de vida de um sistema
55
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
Exemplo de aplicação
Imagine uma empresa de laticínios que possui alguns computadores executando um sistema de 
gestão empresarial – do inglês, Enterprise Resource Planning (ERP).
ERP são sistemas (softwares) utilizados por empresas que reúnem soluções gerenciais para diversas 
áreas da corporação, como controle de estoque, finanças, contabilidade, vendas, conformidade 
jurídica, entre outras.
Figura 37 – Esquema ilustrado das funcionalidades do ERP
A empresa estoca materiais perecíveis como o leite em grandes tanques. À medida que vai 
processando, engarrafando e vendendo os carregamentos de leite, o conteúdo dos tanques vai sendo 
usado e reposto. Para a empresa, é muito importante saber quanto leite foi produzido e quanto foi 
engarrafado. Contudo, o ERP faz obrigatoriamente um controle de quanto leite saiu dos tanques.
Perceba que esse controle não é importante para a empresa, já que ela sabe que o leite que sai 
dos tanques nem sempre é o que fica engarrafado – há perdas. Porém, como o sistema tem uma 
funcionalidade que obriga o controle dos tanques, a empresa acaba realizando uma tarefa adicional que 
não precisava fazer. Perdem-se tempo e dinheiro devido a uma funcionalidade não ajustada à tarefa.
Revisões por processos de auditoria são importantes para descobrir e eliminar problemas como esses.
3.2.1.1 Verificação de funcionalidades
Uma boa revisão também verifica se essas atividades estão sendo executadas da forma correta e dentro 
do planejado. Uma das práticas mais recomendadas é simplesmente comparar as funcionalidades 
dos sistemas com padrões, normas e boas práticas adotadas por outras empresas. Isso pode ser feito 
56
Unidade II
por meio da coleta de sugestões e entrevistas com colaboradores ou com a revisão de controles de 
segurança voltados para o controle de acesso lógico e físico.
Figura 38 – Revisão financeira de processo
Esse tipo de comparação de funcionalidades pode ser realizado manualmente ou mesmo de forma 
automatizada, com programas de varredura de vulnerabilidades. Outro detalhe importante a respeito da 
revisão é que ela exige um conhecimento prévio de como os sistemas devem funcionar – não é possível 
revisar um sistema sem saber minimamente como este precisa se comportar. Isso abre espaço para outro 
ponto relevante no estudo da auditoria, que será visto mais à frente neste conteúdo: a importância de 
uma boa documentação.
3.2.1.2 Códigos de programas
Verificações em códigos de programas são um capítulo à parte na revisão de uma auditoria. 
Em boa parte das vezes, o código é confidencial e não pode passar por auditorias externas. Mesmo em 
auditorias internas, cuidados são necessários.
Quando se trata de um software proprietário, boa parte dos problemas resulta de práticas de 
programação ruins. As principais categorias incluem a integração não segura entre componentes, o 
gerenciamento arriscado de recursos e o perímetro de defesa insuficiente.
Muitas vezes, a questão não são as falhas na programação. A segurança de um software está ligada 
diretamente à qualidade e à confiabilidade dele. Esses adjetivos indicam se determinado programa 
está ou não preparado para falhas acidentais, como entradas não previstas ou uso incorreto do código. 
Em geral, a frequência desse tipo de problema diminui com testes.
No entanto, códigos com erros são mais complicados e podem exigir o uso de programação segura, 
também chamada de programação defensiva.
57
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
Figura 39 – Programador trabalhando com linguagem identada
Nesse tipo de programação (segura), todos os erros e situações são tratados do ponto de vista de 
ataques e incidentes. Qualquer problema é considerado um vetor para a concretização de ameaças ou a 
geração de novas vulnerabilidades. O programador deve estar sempre voltado para o fato de que o seu 
código pode se transformar em uma bomba-relógio.
Outras práticas seguras que podem ser adotadas na programação segura incluem:
• Tratamento de entradas do programa: atividades de validação, verificação de tamanho de 
campos e variáveis, interpretação dos inputs e correção de sintaxe podem evitar problemas 
de ataques por injeção de código.
• Implementação correta de algoritmos, API e bibliotecas: a implementação incorreta é uma 
causa comum de problemas.
• Uso correto da memória: programas ou sistemas operacionais que não gerenciam bem a 
memória podem sofrer um processo conhecido como vazamento de memória – quando o espaço 
de memória usado normalmente por aplicativos não passa por processo de limpeza após o uso da 
aplicaçãoe fica totalmente sem espaço. Outra possibilidade é a concorrência mal administrada 
do uso de memória realizada por alguns programas, que gera problemas de concorrência e 
travamento de aplicativos.
• Interação adequada com o sistema operacional: assim como há algumas incompatibilidades 
entre elementos de hardware, pode haver incompatibilidades entre versões de sistemas operacionais 
e códigos de programas, fato capaz de gerar problemas insolúveis.
58
Unidade II
• Interação com outros programas: a execução conjunta de outros programas, ou mesmo de 
máquinas virtuais, não deveria, mas pode afetar a execução de um código.
• Uso de variáveis de ambiente: as variáveis de ambiente são valores padronizados guardados na 
memória pelo sistema operacional ou pelo código em execução. Como essas variáveis podem ser 
utilizadas e/ou modificadas por diversos programas em execução, problemas de entrada de dados 
manipulados, travamento e incompatibilidades não são incomuns.
• Gerenciamento dos arquivos temporários: arquivos temporários são usados pelos sistemas 
e, muitas vezes, esquecidos com conteúdo importante em seu interior. O ideal é impedir a 
manipulação e alteração desses arquivos durante a execução dos programas.
• Gestão adequada de privilégios: para o desenvolvimento ou a execução de um software, nem 
sempre há a necessidade do uso de altos privilégios, como os de administrador. Programas que 
executam sem privilégios altos de modificar um sistema operacional ou ambiente tendem a 
causar menos danos.
• Tratamento de saídas do programa: é importante que as saídas dos programas sejam adequadas 
ao que se destinam. Há saídas para telas de usuários, para memória, para banco de dados etc. 
Em todas, há informações valiosas que podem ser manipuladas de forma maliciosa se não forem 
validadas e filtradas.
Há diversas soluções para os problemas apresentados. Atualizações e documentação organizada de 
software são imprescindíveis para garantir softwares seguros, confiáveis e de qualidade.
 Saiba mais
Para saber mais sobre programação segura, sugerimos a leitura do livro 
a seguir:
HOWARD, M.; LEBLANC, D. Escrevendo código seguro: estratégias e 
técnicas práticas para codificação segura de aplicativos em um mundo em 
rede. 2. ed. Porto Alegre: Bookman, 2005.
3.2.2 A avaliação na auditoria
Enquanto a revisão se preocupa em verificar se tudo está funcionando como o planejado, uma 
avaliação está mais focada nos resultados finais que estão sendo obtidos.
59
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
Figura 40 – Verificação dos resultados
A avaliação é uma ferramenta poderosa para a evolução dos sistemas. A partir da análise, novas 
funcionalidades são criadas e os sistemas melhoram e se adaptam aos novos tempos.
3.2.2.1 Controles de segurança físicos
Os controles de segurança físicos são aqueles utilizados na proteção de ativos físicos, como imóveis, 
salas, ambientes, equipamentos e objetos. Também são usados na proteção de pessoas e contra 
incidentes naturais, como enchentes. Entre os exemplos, podem ser incluídos os extintores de incêndio, 
as escadas e saídas de emergência, as grades e os cadeados para impedir roubos, as catracas de controle 
de acesso, entre outros.
A) B) 
Figura 41 – Controles de segurança físicos
60
Unidade II
3.2.2.2 Controles de segurança lógicos
Um controle de segurança lógico diz respeito a proteções implementadas para garantir a segurança 
do fluxo de informações em computadores, sistemas, smartphones, redes e equipamentos. Um exemplo 
bastante comum é o uso de firewalls, colocados, em geral, como proteção entre a internet e a rede a ser 
protegida, como mostra a figura a seguir.
Rede protegida
Firewall
Internet 
Figura 42 – Firewall posicionado entre a internet e uma rede protegida
Em sua versão clássica, os firewalls são sistemas (hardware ou software) que analisam o tráfego à 
procura de padrões maliciosos que constam em um banco de dados, avisando o administrador da rede 
em caso de identificação de eventuais ameaças.
Adiante, veremos mais detalhes sobre alguns controles de segurança lógicos, como os firewalls.
Os próximos tópicos irão se debruçar sobre aspectos bem diferentes que, quando aglutinados, 
formam uma base para a implantação de um processo de auditoria.
Inicialmente, serão discutidos os requisitos necessários para um auditor e os aspectos da formação 
desse profissional, com ênfase na importância da ética e da independência de um processo de auditoria.
Também serão conhecidos em detalhes alguns conceitos e classificações, como auditorias internas, 
externas, manuais e automáticas.
3.3 A formação do auditor
As competências e habilidades de um auditor se concentram no campo das ciências exatas; porém, 
habilidades na área das ciências humanas também são necessárias, já que comunicação e interação 
pessoal são imprescindíveis. Cursos de pós-graduação voltados para a área de TI, gestão e administração 
costumam ser bons antecedentes para quem deseja seguir a profissão. Discrição para lidar com 
informações confidenciais também é uma qualidade desejada.
61
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
É comum, a cada processo de auditoria, que o profissional acumule experiência ao longo do tempo. 
Para alguns profissionais experientes, há algumas certificações de qualidade oferecidas pela Information 
Systems Audit and Control Association (ISACA) – entidade internacional independente com foco na 
segurança da informação criada em 1969 –, como pode ser visto no quadro a seguir.
Quadro 4 – Certificações oferecidas pela ISACA
Certificação Descrição
Certified Information 
System Auditor (CISA)
A certificação CISA é reconhecida mundialmente como o padrão de conquista para 
quem audita, controla, monitora e avalia a TI e os sistemas de negócios de uma 
organização.
Certified in Risk and 
Information Systems 
Control (CRISC)
O CRISC é a única certificação que posiciona os profissionais de TI no crescimento 
futuro da carreira, vinculando o gerenciamento de riscos de TI ao gerenciamento 
de riscos corporativos e direcionando-os para se tornarem parceiros estratégicos 
dos negócios.
Certified Information 
Security Manager (CISM)
O CISM, focado no gerenciamento, é o padrão globalmente aceito para indivíduos 
que projetam, constroem e gerenciam programas de segurança da informação 
corporativa. O CISM é a principal credencial para os gerentes de segurança da 
informação.
Certified in the Governance 
of Enterprise IT (CGEIT)
A CGEIT reconhece uma gama de profissionais por seu conhecimento e aplicação 
dos princípios e das práticas de governança de TI da empresa. A CGEIT fornece 
credibilidade para discutir questões críticas sobre governança e alinhamento 
estratégico com base em suas habilidades, seus conhecimentos e sua experiência 
comercial reconhecidos.
O recente índice trimestral IT Skills and Certifications Pay Index (ITSCPI) da Foote Partners (2019b) 
classificou as certificações listadas no quadro anterior entre as certificações de TI mais procuradas e com 
os melhores salários.
 Saiba mais
O ITSCPI é um índice publicado pela Foote Partners que concatena 
pagamentos, certificações e habilidades dos profissionais de TI. Leia mais em:
FOOTE PARTNERS. About foote partners. 2019a. Disponível em: https://
footepartners.com/pages/about-foote. Acesso em: 24 out. 2020.
3.4 Responsabilidades do auditor
Entre os encargos e as responsabilidades de um auditor, destacam-se as recomendações das normas 
NBR ISO 9001 (ABNT, 2015b), NBR ISO 14001 (ABNT, 2015a), NBR ISO/IEC 27001 (ABNT, 2013a) e 
NBR ISO 19011 (ABNT, 2018):
• Responsabilidade com os clientes e manutenção da relação de confiança entre as partes.
• Avaliação justa e transparente.
62
Unidade II
• Responsabilidade ética baseada nos valores definidos pela International Organization of 
Supreme Audit Institutions (INTOSAI): verdade, confiança, integridade, honestidade, candidez, 
independência, entre outros.
• Responsabilidade legal, civil e criminal,já que o auditor responde legalmente por tais ações e, por 
consequência, pode sofrer penalizações previstas em lei em caso de fraude.
• Planejamento adequado e criterioso, que alinhe cronogramas e preze pela documentação.
Adicionalmente, a norma ABNT NBR ISO 19011 recomenda uma abordagem baseada na coleta de 
evidências, na qual o auditor aplique uma metodologia que explique e justifique os resultados de seu 
trabalho. O objetivo é solidificar a confiança de seus resultados perante o cliente.
3.5 A importância da independência do auditor/auditoria
O ideal é que a implantação de sistemas de monitoramento de segurança e de desempenho de 
processos seja definida pelas áreas competentes em conjunto com a alta administração. Nesses casos, a 
auditoria externa deve sempre fazer recomendações de mudanças no sistema quando julgar necessário, 
agindo de forma independente para direcionar a gestão em busca da eficiência.
A independência do auditor externo pode ser vista por quatro ângulos principais:
• Independência da programação: permite ao auditor a livre gestão, sem ingerência no tempo e 
no desempenho do processo de auditoria.
• Independência investigativa: permite ao auditor o acesso irrestrito às informações relevantes 
para a investigação.
• Independência de relato: permite ao auditor emitir a própria opinião, livre de qualquer 
censura prévia.
• Independência relativa: evita a criação de relações interpessoais entres as partes (cliente e 
auditor), a fim de prevenir qualquer conflito de interesse.
Apesar de necessária, a independência da auditoria pode gerar problemas. As organizações 
questionam a relação custo-benefício da auditoria independente. O próprio auditor pode passar pelo 
dilema entre tomar uma decisão que atenda ao interesse da organização ou ao seu próprio.
Por esses motivos, os atributos do auditor e os princípios de auditoria devem ter como base os 
objetivos do processo de auditoria. Uma boa relação de confiança entre as partes (cliente e auditor) 
também é recomendável para o sucesso da operação. Outra solução é o desenvolvimento de uma 
auditoria interna de qualidade, capaz de alcançar os mesmos resultados da auditoria externa.
63
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
3.6 Adequando sistemas à PSI
Os processos de revisão e avaliação podem ser muito bem-sucedidos quando apoiados em uma 
PSI consistente.
Como discutido anteriormente, uma PSI contém regras vitais para a proteção dos ativos e processos 
da empresa em conformidade com as estratégias definidas pela direção. A adoção de uma PSI nos 
processos de auditoria tende a diminuir os riscos operacionais e as possibilidades de ocorrência de 
incidentes. Nesse contexto, algumas questões devem ser observadas:
• A PSI está alinhada com as estratégias da empresa? Se não estiver, a PSI está errada e não 
pode ser utilizada como guia em um processo de auditoria.
• A PSI trata sobre aspectos de segurança relacionados às principais atividades, sistemas 
e controles de segurança adotados pela empresa? Detalhes sobre a segurança de alguns 
sistemas, processos e controles críticos podem e devem ser especificados na PSI, justamente pela 
importância destes.
• Os ativos organizacionais estão sendo respeitados pela PSI? Um ativo organizacional é a 
própria organização da empresa. Uma companhia bem organizada possui hierarquia, quadros 
de funções bem definidos, resposta a incidentes e trabalho direcionado a partir das estratégias 
traçadas pela diretoria. É importante garantir uma organização mínima na empresa que permita 
a aplicabilidade da PSI e da auditoria.
• A disseminação e a obrigatoriedade da PSI estão sendo observadas? Uma PSI que não é 
seguida por determinados setores pode atravancar alinhamentos com o processo de auditoria.
Muitas vezes, os sistemas e processos da empresa estão adequados a esses aspectos listados de 
uma PSI, mas os problemas podem estar nos controles de segurança adotados. Além de alinhados, os 
controles devem passar por auditoria para que se saiba se são adequados às necessidades.
Controles precisam de manutenção e acompanhamento; estão sujeitos a ameaças e vulnerabilidades, 
como todos os ativos. Como os controles também evoluem e se adaptam, é importante que as revisões 
e avaliações sejam periódicas e que sejam verificados alguns aspectos:
• Se a revisão e a avaliação dos controles estão sendo realizadas de maneira independente.
• Se os serviços de segurança gerados pelos controles atendem às necessidades do cenário em que 
estão sendo aplicados.
• Se a documentação dos registros dos controles (logs) existe e se está sendo gerenciada de 
modo correto.
• Se há históricos da avaliação e dos resultados anteriores dos controles de segurança, para 
comparação e criação de estatísticas que sirvam para a auditoria.
64
Unidade II
• Se os controles realmente estão evoluindo ao longo do tempo, ou se, pelo menos, há proposta 
para isso. Esse aspecto é importante, pois as ameaças e vulnerabilidades evoluem.
• Se os controles oferecem um nível de segurança adequado ao cenário em que eles estão sendo 
aplicados. Muitas vezes, o nível de proteção dos controles é demasiado para determinado ambiente 
(gasta-se desnecessariamente). O inverso também acontece em ambientes onde a proteção 
oferecida é menor que a ideal.
3.7 Auditoria interna e externa
A auditoria pode ser de caráter interno, também conhecida como de primeira parte, quando 
é realizada pela própria equipe interna da empresa; e de caráter externo, também conhecida como 
de segunda parte, quando terceiros são contratados para a realização do trabalho de interesse 
interno da companhia.
 Lembrete
A norma ABNT NBR ISO 19011 (ABNT, 2018) cita a auditoria de terceira 
parte, que é externa, mas conduzida para outros fins que não têm a ver 
com interesses internos diretos da empresa.
Não há diferença significativa entre as duas práticas, já que ambas seguem os mesmos padrões. 
Contudo, algumas distinções sutis podem ser observadas no quadro a seguir.
Quadro 5 – Diferenças entre auditoria externa e interna
Externa Interna
Realizada por terceiros; contratada Realizada pela equipe interna
Possui uma meta clara desde o início (isso não impede que 
a auditoria se desdobre para outros objetivos ou setores)
Tem como meta resolver um problema específico ou a 
melhoria contínua
O próprio processo de revisão dos sistemas é utilizado para 
determinação da extensão da auditoria
Os processos de revisão e avaliação de sistemas e 
controles estão muito mais ligados a um problema 
identificado e ao processo de melhoria contínua
Os auditores são mais independentes, já que o vínculo 
com a empresa contratante é contratual e (deveria ser) 
isento de políticas
Influências políticas podem acontecer; concorrências 
internas podem estimular uma auditoria mais enfática, 
enquanto apadrinhamentos podem resultar em revisões 
e avaliações mais brandas
O conhecimento do auditor externo sobre o ambiente 
pode variar bastante; o conhecimento do ambiente 
pode ser completo, intermediário ou nulo – esse aspecto 
costuma influenciar bastante o andamento e a velocidade 
da auditoria, sendo que, muitas vezes, serve como teste 
para o auditor ou para os administradores do sistema que 
está sendo avaliado
Em tese, o conhecimento do sistema é mais 
abrangente; o auditor conhece relativamente bem o 
ambiente que está auditando
As evidências levantadas têm um escopo bem definido As evidências podem ser levantadas de forma contínua
Adaptado de: Beneton (2019).
65
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
Quando a auditoria é externa, em geral, há uma meta clara para a qual o trabalho é redirecionado; 
afinal, há custos a serem considerados. Uma auditoria interna pode se estender indefinidamente 
realizando revisões e avaliações dos sistemas e controles. Porém, não são incomuns os casos nos quais 
os interesses políticos influenciam a auditoria.
Muitas vezes, uma companhia pode necessitar de ambas as abordagens de auditoria, e a cooperaçãoética é fundamental.
Figura 43 – Cooperação entre auditorias internas e externas
É bastante comum que equipes internas e externas atuem juntas, cada uma buscando seus objetivos, 
mas cooperando uma com a outra.
3.8 Auditorias manuais e automáticas
Tendo como base todo o planejamento, cabe ao auditor, muitas vezes em concordância com os 
auditados, definir se a auditoria será implementada de forma manual, automática ou se uma maneira 
híbrida das duas opções será utilizada.
Uma auditoria manual deve ser considerada quando existem dificuldades na automatização de 
algumas tarefas. Entrevistas e questionários com usuários, reuniões e brainstorms, levantamentos 
de requisitos por meio de observações e até a análise de alguns dados são formas manuais bastante 
usadas nas auditorias.
Quando o objeto auditado é um software ou hardware que pode automaticamente responder com 
resultados, cálculos, correlações e dados que podem ser úteis para a consultoria, é muito comum que isso 
seja feito de forma automática. Para esse fim, há uma categoria de ferramentas usadas no levantamento 
automático de dados em auditorias: as Computer Assisted Audit Techniques (CAAT).
Muitas vezes, alguns valores e eventos só podem ser levantados de forma automática, como o 
resultado de cálculos complexos. Além disso, análises e levantamentos automáticos, quando bem 
configurados, tendem a ser mais precisos e livres de erros e tendenciosidades.
66
Unidade II
Entre os exemplos de ferramentas CAAT, estão:
• Softwares genéricos para auditoria: são aplicativos, geralmente executados em lote (batch), 
voltados para diversas funções de auditoria, como coleta de dados, cálculos e emissão de relatórios. 
Também permitem a realização de testes em arquivos e banco de dados. Entre os exemplos, 
estão: o software de extração e coleta de dados Audit Command Language (ACL); o Interactive 
Data Extraction & Analysis (IDEA), também usado para coleta e análise de dados; o programa de 
planejamento e monitoramento de recursos voltados para auditoria, conhecido como Pentana; 
e o software de gestão de auditorias internas Magique Galileo, que realiza a gestão de riscos, a 
documentação e a emissão de relatórios, entre outras tarefas.
• Softwares especializados de auditoria: são programas que executam tarefas muito específicas 
dentro do universo da auditoria. Muitos são criados pelas próprias empresas de auditoria, que os 
aplicam nos ambientes auditados dos clientes.
• Utilitários: são programas usados para funções diversas, que podem ser direcionados para 
resolver algumas funcionalidades dos processos de auditoria. Entre os exemplos, estão as planilhas 
e os gerenciadores de banco de dados, que podem realizar cálculos e correlações úteis para o 
processo de auditoria.
4 FASES DA AUDITORIA: PLANEJAMENTO
De forma básica, um processo de auditoria pode ser dividido em três fases, muito parecidas com 
as do PDCA:
• Planejamento.
• Execução.
• Resultados (relatórios).
A importância de planejar e definir corretamente requisitos e critérios de uma auditoria, assim como 
estabelecer com precisão alguns limites (escopo), faz parte da fase de planejamento de um processo 
de auditoria. Esse assunto será tratado neste tópico com base nas atividades de revisão e avaliação de 
uma auditoria.
O conteúdo será permeado por alguns exemplos que concretizam os conceitos explicados.
4.1 Planejamento da auditoria: escopos e critérios de avaliação
A fase de planejamento é o início do processo de auditoria e deve levar em conta a definição 
dos objetivos dos sistemas e processos auditados. A equipe que fará parte do processo (interna e 
externa) também é definida nessa fase, assim como o nível de informação que será distribuído aos 
auditores e à equipe.
67
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
Caso existam, detalhes e estatísticas sobre antigas auditorias podem ser usados, desde que não 
enviesem de forma negativa as opiniões dos auditores.
Estatisticamente, não há nada que garanta que dados obtidos anteriormente se repitam no futuro. 
Muitas vezes, resultados e padrões já obtidos podem sofrer alterações devido a mudanças em parâmetros 
não analisados ou desconhecidos.
O resultado disso são alterações inesperadas que, quando não levadas em conta, podem produzir 
reflexos indesejados no processo de avaliação.
Em alguns casos de migração para a nuvem, testes e simulações aplicadas previamente sobre o 
sistema representam um ótimo índice para a auditoria basear a avaliação. Contudo, é preciso olhar 
com cautela esse tipo de dado, pois a migração final pode apresentar dados diferentes, apesar do 
histórico. Isso acontece porque versões, plataformas (sistemas operacionais), configurações ou mesmo 
alguns parâmetros desconhecidos podem causar mudanças, gerando resultados totalmente diferentes 
da auditoria. Para casos assim, o ideal é que o processo de revisão se estenda um pouco mais e seja 
realmente interconectado com o de avaliação.
No planejamento, o escopo e os limites da avaliação dos sistemas, das redes ou dos processos também 
devem ser determinados. Em alguns casos, quando há processos críticos que não podem ser interrompidos, 
o gestor pode flexibilizar alguns limites, desde que isso seja um consenso entre a equipe ou o contratante.
A gestão de mudanças é um ramo da governança de recursos que procura gerenciar os processos 
de migração ou mudança que determinados sistemas, setores ou processos passam em uma empresa. 
A figura a seguir traz um exemplo de requisitos que precisam ser analisados quando se pretende realizar 
a migração do sistema de armazenamento local para a nuvem.
Atributos 
da qualidade 
de serviço
Objetivos do
negócio
Decisões 
da arquitetura
Gestão da 
função de TI
Figura 44 – Requisitos necessários para a migração de armazenamento local para a nuvem
Uma troca de ERP, uma mudança de endereço do setor de TI ou uma migração de um sistema de 
uma rede local para uma nuvem computacional são exemplos que exigem uma gestão de mudanças 
precisa. Muitas vezes, um processo de auditoria é necessário para organizar e antecipar o aparecimento 
de eventuais problemas.
68
Unidade II
Uma auditoria executada para antecipar um processo de mudança de um sistema para a nuvem, dentro 
do possível, deve contar com mais de uma data para a mudança definitiva. Determinar uma data para a 
mudança é importante para que ela não se prolongue indefinidamente; porém, contar com uma segunda 
data a ser usada em casos de problemas é uma cautela que pode surtir efeitos em sistemas críticos.
 Lembrete
ERP são sistemas (softwares) utilizados por empresas que integram 
soluções gerenciais para diversas áreas da corporação, como controle de 
estoque, finanças, contabilidade, vendas, conformidade jurídica, entre outras.
Basicamente, um planejamento adequado tende a se refletir em uma auditoria mais eficaz. Por 
isso, a fase de planejamento não se resume a criar uma lista de arquivos e itens que devem passar por 
auditoria; há outros detalhes, como:
• Estudar e entender o cenário no qual a auditoria se desenrola: computadores, sistemas, 
redes, dispositivos, links, pessoas, processos – há vários elementos que podem gerar informações 
antecipadamente para a auditoria.
• Analisar as regras da auditoria: é importante saber como a auditoria vai ser aplicada, quem 
são os responsáveis a serem contatados em caso de necessidade e de que forma a aplicação da 
avaliação (ou mesmo da revisão) impacta a continuidade do trabalho.
• Avaliar resultados históricos da análise de riscos: entender quais são os sistemas mais críticos 
ou propensos à exploração maliciosa.
• Estudar o histórico de problemas nos equipamentos e sistemas: conferir previamente 
as configurações de servidores, aplicativos, programas, rotinas e dispositivos eletrônicos 
é uma boa medida.
• Avaliar o histórico de incidentes de segurança para a identificação de tendências: ter 
ciência das medidas tomadas para garantir a continuidade do negócio também é importantepara 
que o auditor saiba o que fazer em caso de interrupções ou problemas mais sérios.
• Considerar eventuais testes de penetração: esses testes servem para testar controles de 
segurança. A ciência do nível de segurança desses controles auxilia o auditor no ajuste dos limites 
e escopos da avaliação.
Dentro do possível, ao menos os componentes e as funcionalidades principais de um sistema devem 
ser avaliados. Da mesma forma que na revisão, a avaliação exige que se saiba minimamente sobre 
os resultados de um sistema. Políticas e controles que garantam bons resultados também podem ser 
adotados, caso seja necessário.
69
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
Exemplo de aplicação
Tome como exemplo a empresa de laticínios do exemplo de aplicação anterior. Suponha que 
exista um controle de segurança que testa a acidez do leite por meio de um software ligado ao ERP. 
Contudo, o processo de avaliação mostra que 3% dos resultados de acidez tidos como aceitáveis são 
falsos, ou seja, 3% do leite que sai da empresa contêm acidez acima do permitido.
A avaliação do processo determinou que isso acontece porque algumas informações usadas no 
cálculo da acidez (pH, presença de nitratos, gás carbônico etc.) são inseridas de forma errada no sistema. 
A própria equipe de avaliação descobriu que a origem do problema está no fato de os funcionários 
trocarem formulários manuscritos com dados que são inseridos no sistema. Essa operação está sujeita a 
erros de escrita, interpretação e digitação.
Figura 45 – Formulário preenchido a mão para posterior entrada no sistema: motivo do erro
Como os resultados do sistema eram tidos como confiáveis, estes nunca foram conferidos. Nesse 
caso, a avaliação dos resultados mostrou a importância desse tipo de verificação. Além disso, prova 
que a avaliação pode ser utilizada na sugestão de adequação de processos. Uma sugestão interessante 
é automatizar a coleta de dados, que antes era manuscrita, com equipamentos de leitura automática.
No entanto, deve ficar claro que a revisão e a avaliação são ferramentas que auxiliam na verificação 
do funcionamento e dos resultados de um sistema. A auditoria não é voltada para a definição de novas 
políticas e controles, mas para o entendimento do que acontece. Se, ao final do processo de auditoria de 
um sistema, novas recomendações de processos, programas, funcionalidades ou controles surgem, estes 
são simplesmente os resultados da auditoria.
4.2 Plano e documentação da auditoria
Ainda na fase de planejamento da auditoria, para compreender como funcionam as principais 
ferramentas utilizadas nos processos de auditoria, é importante acompanhar como um plano de 
auditoria deve ser definido e documentado.
70
Unidade II
Um plano para documentar o processo e os resultados da auditoria é necessário e deve incluir 
diversas atividades: planejamento prévio, análise de riscos, supervisão e controle de qualidade, análise dos 
controles, aplicação da auditoria, continuidade dos negócios, uso de amostragem estatística, entre outras.
A documentação está ligada à fase de planejamento da auditoria e serve para evitar a ocorrência de 
incidentes e surpresas indesejadas durante o processo de auditoria.
Figura 46 – O planejamento garante a organização da empresa
Por isso, é importante que a atividade de planejamento se preocupe com a atribuição de 
responsabilidades entre os auditores e com os riscos de todo o processo. Como o processo 
de gerenciamento de riscos deve buscar uma melhoria contínua do objeto auditado, essa prática serve 
para a evolução do próprio processo de auditoria. A experiência dos profissionais envolvidos na auditoria 
conta muito nesse aspecto.
A matriz de riscos também é uma forma de documentação do processo de auditoria. É uma 
ferramenta que pode ajudar bastante se estiver sempre atualizada, contemplando resultados de testes 
e mudanças ocorridas nos processos de negócios.
Tabela 1 – Exemplo de uma matriz de riscos
Probabilidade de ocorrência
Nível de 
danos
Insignificante Leve Moderada Alta Altíssima
Insignificante 1 2 3 4 5
Leve 2 4 6 8 10
Moderado 3 6 9 12 15
Grave 4 8 12 16 20
Irrecuperável 5 10 15 20 25
O objetivo da matriz de riscos é identificar e priorizar ações. Com essa ferramenta, o auditor 
consegue acompanhar quais são os processos e sistemas críticos que merecem um acompanhamento 
mais refinado ou urgente, assim como realizar testes mais precisos.
71
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
A documentação de todos esses processos é vital e deve ser realizada, de preferência de forma 
eletrônica (preenchimentos online, scan de documentos manuais, arquivos de logs etc.), durante a 
auditoria dos sistemas, com o relato das ocorrências e dos detalhes observados. Quando possível, é 
desejável que esses registros (informações de planejamento e monitoramento, formulários de follow-up 
e controle de usuários e senhas, entre outros) sejam armazenados em um banco de dados.
4.3 Fases da auditoria: execução e resultados
Depois da fase de planejamento, a fase de execução contempla uma série de atividades que devem 
ser levadas em conta antes do início de um processo de auditoria. Pelo menos duas dessas atividades serão 
discutidas em detalhes neste tópico: a rastreabilidade e a análise de requisitos.
A rastreabilidade envolve a busca e investigação da razão de alguns eventos, por meio de geração 
de logs e correlacionamentos. Já a análise de requisitos faz parte de um processo de entendimento do 
sistema auditado pelo qual o auditor precisa passar para a compreensão dos sistemas e das tarefas que 
serão avaliadas.
A fase de resultados corresponde ao final do processo de auditoria e será contemplada neste tópico 
através de explicações sobre os relatórios de auditoria.
4.4 Análise de requisitos para a auditoria
Realizada com base em estudos sobre as necessidades de uma atividade qualquer, uma análise de 
requisitos tem como objetivo determinar a partir de quais critérios, limitações, parâmetros e escopos os 
dados são colhidos e analisados.
Figura 47 – Esquema ilustrativo sobre o levantamento e a análise de requisitos
A análise de requisitos estabelece uma espécie de referência que servirá para a validação dos 
resultados da atividade proposta. Por isso, dados levantados a partir de requisitos relevantes e precisos 
tendem a influenciar de forma positiva a execução de uma auditoria ou mesmo um projeto qualquer.
72
Unidade II
Como o papel da análise de requisitos é alinhar o que será construído com o que se 
espera, uma das suas principais demandas é o envolvimento dos usuários do sistema nesse processo 
de levantamento e análise. Um benefício adicional dessa prática é o potencial para a diminuição de 
custos desnecessários.
Uma análise de requisitos envolve os seguintes aspectos:
• Identificação do problema: é preciso entender o problema que está ocorrendo, mas, para isso, 
é necessário primeiro compreender o sistema e suas especificações. A partir daí, fica mais fácil a 
compreensão da ameaça e das vulnerabilidades, sempre que possível, sob a ótica do cliente.
• Avaliação do problema: agora que o problema é conhecido, é preciso avaliar os dados, estudá-los 
e apresentar soluções entre as diversas hipóteses que surgirem.
• Modelagem: trata-se da tarefa de direcionar a solução por meio de algum método ou modelo 
que seja adequado aos objetivos. Basicamente, nesta tarefa a solução é implementada usando 
ferramentas para a criação de modelos que vão permitir a execução do sistema e a checagem de 
suas funcionalidades e seu comportamento.
• Especificação de requisitos: trata-se da tarefa de especificar as características que os requisitos 
devem conter. Engloba a especificação das funcionalidades, das interfaces, do desempenho, dos 
parâmetros, das formas de avaliação e dos limites que os requisitos devem possuir.
• Revisão auditor-auditado: esta etapa diz respeito a alinhamentos entre o auditor e o auditado. 
A prática auxilia na verificação de rumos e objetivos,na eliminação de atividades redundantes e 
inconsistências, no levantamento de necessidades e omissões, entre outros ajustes.
Quanto ao tipo, os requisitos podem ser:
• Funcionais: estão diretamente relacionados às funcionalidades do sistema. Expressam ações e 
serviços oferecidos por um sistema, como:
— Manutenção de uma tabela de banco de dados: incluir/alterar/excluir o cadastro de um cliente.
— Emissão de um relatório gerencial.
— Consulta ao estoque de um determinado produto.
— Alerta gerado por um controle de segurança.
73
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
Figura 48 – Requisito funcional: relatório gerencial
• Não funcionais: podem ser definidos como a maneira pela qual uma ação é executada por um 
sistema. Envolvem qualidades como confiabilidade, desempenho e rapidez de um sistema, como:
— Se a velocidade de uma transmissão será em Kbps ou pela quantidade de pacotes recebidos.
— Se a confiabilidade de uma rede será medida pelo atraso médio ou pelo throughput.
— A velocidade com que um sistema deve funcionar.
A) 
B) 
C) 
Figura 49 – Exemplo de requisito não funcional: medição da 
velocidade de rede (internet) com três ferramentas diferentes
74
Unidade II
Há algumas técnicas específicas para o levantamento de requisitos. Entre as principais que podem 
ser citadas, estão:
• Brainstorming: reunião que congrega os diversos envolvidos em uma tarefa (auditoria) para a 
geração de ideias, sugestões e até críticas. Serve como um levantamento geral sobre o projeto. A 
ideia é selecionar as melhores sugestões e, se forem viáveis, colocá-las em prática. Muitas vezes, 
são necessários vários brainstorms iniciais antes de passar para reuniões mais focadas e seletivas.
• Entrevistas: coletas de sugestões e críticas diretamente com usuários envolvidos na auditoria 
ou no sistema auditado. Podem ser extremamente úteis para que um auditor externo consiga 
um contato mais próximo com os usuários do sistema, conhecendo melhor seus problemas e 
suas limitações.
• Questionários e pesquisas: formulários com questões pertinentes ao processo de auditoria 
ajudam bastante no levantamento de requisitos e informações sobre o sistema, pois, em geral, os 
usuários se sentem mais à vontade para respondê-las, muitas vezes sob anonimato.
• Acompanhamento: nesta técnica, o auditor simplesmente acompanha e observa o uso diário do 
sistema pelos usuários. É uma técnica menos invasiva, que não requer a coleta de opiniões e críticas 
do usuário. Porém, pode não detectar todas as minúcias do uso de um sistema, principalmente 
quando o auditor ainda não conhece tanto o objeto auditado.
4.5 Aplicando a rastreabilidade
A rastreabilidade é quase um sinônimo da auditoria. Trata-se de uma forma de investigação capaz 
de traçar os meios e caminhos pelos quais um determinado evento ocorre.
Rastrear envolve identificar: dados (o que é), origem (de onde veio), destino (para onde vai) e, 
algumas vezes, período (quando).
Figura 50 – A rastreabilidade envolve investigação
75
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
Para uma rastreabilidade eficiente, são necessárias uma análise apurada dos dados e uma 
documentação coerente das etapas e dos eventos da auditoria.
Também é bastante comum integrar eventos internos da organização com ocorrências externas de 
clientes e fornecedores durante a rastreabilidade. Isso estende o processo a níveis além da empresa, fato 
que pode ser útil quando se quer auditar o comportamento de terceiros.
É importante destacar que, na maior parte das vezes, um processo de rastreabilidade deve ser 
transparente ao usuário, para evitar viés e influências no levantamento de dados.
Exemplo de aplicação
Imagine uma investigação da polícia federal sobre uma corrupção da qual os auditores querem saber 
a origem, o destino e as datas de depósitos irregulares em contas bancárias fora do país.
Trata-se de uma auditoria com um forte processo de rastreabilidade.
Para descobrir todo o fluxo do dinheiro (que deve estar muito bem escondido), os auditores precisam 
levantar uma série de dados internos (que estão à mão), como documentos, informações bancárias e 
registros telefônicos. Em seguida, é preciso correlacionar os dados internos com informações externas 
(que não estão à mão), como informações legais, dados bancários internacionais, uso de passaportes 
fora do país, além de datas e contatos que os investigados fizeram.
Por fim, a expectativa é que um fluxo do dinheiro irregular seja traçado, levando à culpabilidade dos 
corruptos.
4.5.1 Logs e evidências de auditoria
Ainda dentro dos processos de rastreabilidade, existem os registros de atividades realizadas pelos 
sistemas. Os sistemas computacionais são pródigos na geração desses registros, os chamados logs, como 
mostra a figura a seguir.
76
Unidade II
Figura 51 – Os logs de um sistema operacional (Windows) são uma fonte para o rastreamento de eventos
Qualquer sistema operacional ou mesmo aplicativo implementado é capaz de gerenciar registros 
de forma eficaz. Contudo, a Lei n. 5.869 (BRASIL, 1973), art. 332 do CPC, deixa claro que a geração de 
evidências, vitais para o exercício do processo de auditoria, deve ser realizada de forma idônea e legítima.
Qualquer investigação que não seguir esses princípios estará agindo fora da lei, ainda que as 
informações geradas sejam vitais para a conclusão da auditoria.
A geração de logs e registros de quaisquer tipos deve ser feita com prudência para que não sejam 
excedidos os limites da lei. Vale lembrar que toda afirmação realizada na auditoria deve ser provada por 
evidências coletadas; ou seja, tudo o que for levantado precisa ser reprodutível e estar lastreado em 
fatos comprováveis.
 Observação
Segundo o art. 332 do CPC, Lei n. 5.869, de 1973: “(...) todos os meios 
legais, bem como os moralmente legítimos, ainda que não especificados 
neste Código, são hábeis para provar a verdade dos fatos, em que se funda 
a ação ou a defesa” (BRASIL, 1973).
77
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
A perda de validade das evidências de toda auditoria é, consequentemente, bastante comum nesses 
casos de violação dos estatutos legais. Tudo isso remete à perícia forense computacional.
A dependência dos serviços informáticos tornou os computadores alvos ou instrumentos para as 
mais diversas práticas delituosas, tornando-os, por analogia ao mundo real, um potencial local de 
crime. A perícia forense computacional tem como principais objetivos a recuperação e a preservação 
da evidência digital, respeitando a reprodutibilidade dos métodos usados na investigação para que um 
terceiro possa provar o delito.
A perícia forense busca, essencialmente, o esclarecimento da autoria e das circunstâncias acerca 
do ilícito. Portanto, pode ser altamente relevante para o fortalecimento da PSI e para os esforços de 
reposta a incidentes.
Contudo, a contaminação da evidência é um problema recorrente nessa área. Essa contaminação é 
fruto das boas intenções do trabalho do auditor, que, durante a interação com o ambiente, não consegue 
garantir a perfeita preservação do elemento auditado. A coleta de evidências sem metodologia definida, 
testada e validada representa um enorme risco de contaminação.
Assim, baseada na investigação de mídias, memórias, relatórios, arquivos, sistemas, logs e eventos 
computacionais, a perícia forense computacional deve procurar responder às perguntas a seguir:
• Como preservar adequadamente a evidência digital de alta volatilidade para coleta?
• Como garantir o valor probatório da evidência digital?
• Como garantir a validade e reprodutibilidade dos procedimentos investigativos?
• Como realizar tudo dentro do direito?
Mesmo tendo que fazer frente a essas exigências, a perícia forense oferece algumas soluções 
interessantes que podem ser utilizadas para integrar dados e rastrear informações aparentemente 
ocultas dos olhos da auditoria. Um exemplo é a correlação de dados.
A correlação busca a relação entre registros de fontes diferentes,como sistemas operacionais, redes 
sociais, e-mails, controles de segurança, aplicações, equipamentos e softwares diversos. Por meio da 
ligação lógica desses registros (em geral, o horário sincronizado da ocorrência), é possível analisar causa 
e efeito, traçar origem e destino de eventos e analisar ocorrências inesperadas.
4.6 Relatórios de auditoria
Os relatórios de auditoria são parte da fase de resultados da auditoria. Costumam ser um dos 
últimos capítulos do trabalho, já que trazem as conclusões e evidências levantadas durante o 
processo de auditoria.
78
Unidade II
Em geral, esses relatórios possuem três seções:
• Findings (descobertas): são pontos novos ou inesperados levantados pela auditoria. Podem ser 
resultados ou mesmo evidências, mas ainda assim devem ter uma conformidade com o padrão de 
análise e com o relatório para que eventuais novas prioridades evidenciadas sejam tratadas.
• Recomendações: são sugestões trazidas pelo processo de auditoria que devem ser priorizadas 
de acordo com algum critério, como a relevância. Como se trata de sugestões para a melhoria 
do sistema, o ideal é que tenham prazo para execução, para não ficarem esquecidas, sem 
implementação. A fim de evitar sobressaltos ou surpresas, as recomendações também devem 
trazer especificado o nível de risco associado à sua implementação. Trâmites burocráticos como 
a assinatura de gerentes e elementos envolvidos no processo são importantes para atestar a 
veracidade e garantir a irretratabilidade (não repúdio) do trabalho. Por fim, a conformidade legal 
e de processo deve estar garantida. Não há coerência em gerar um relatório com recomendações 
fora dos limites da lei ou que não atenda às próprias recomendações do sistema auditado.
• Follow-up (acompanhamento): é o processo de revisão e avaliação contínua do que foi auditado. 
Deve-se verificar se a empresa está realmente colocando em prática os pontos levantados na 
auditoria. É importante também verificar se esses pontos estão sendo implementados da forma 
correta e se os resultados estão sendo satisfatórios. O exercício de acompanhamento, como em 
outros ramos da governança, serve principalmente para que os sistemas evoluam.
Como resultado do processo de auditoria, os relatórios não são pedras imexíveis. É preciso que 
reuniões para a apresentação dos resultados à diretoria sejam agendadas, prazos sejam estabelecidos e 
até mesmo questionamentos sejam realizados. Tudo é benéfico quando o objetivo principal é garantir a 
continuidade e a melhoria dos sistemas da organização.
79
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
 Resumo
Citando um breve histórico do processo de auditoria, esta unidade 
tratou diretamente sobre a auditoria de sistemas e como esse processo 
se encaixa no ciclo de vida de sistemas. Foram discutidos dois conceitos 
fundamentais para as operações críticas: a revisão, com foco na comparação 
de funcionalidades e na programação segura; e a avaliação, com foco nas 
diferenças entre os controles de segurança físicos e lógicos. O conhecimento 
sobre quais tipos de controles de segurança estão disponíveis é uma 
informação vital para o auditor.
Os principais requisitos necessários para a formação de um auditor 
– incluindo sugestões de certificação nessa área – foram elencados e 
discutidos. Da mesma forma, pela ótica da norma ABNT NBR ISO 19011, as 
responsabilidades que cabem a um auditor foram esmiuçadas, com foco na 
ética e na colaboração com o auditado.
Foi discutida a importância da independência do auditor para o 
bom andamento do processo de auditoria. Entendemos, assim, como 
as atividades de revisão e avaliação servem de base para sugestões de 
alinhamento entre sistemas e processos com as regras listadas na PSI. Foram 
detalhados alguns conceitos de aplicação prática, que serão extremamente 
importantes nas próximas unidades, como auditorias internas, externas, 
manuais e automáticas.
Como vimos, o planejamento corresponde à fase inicial de uma 
auditoria. Trata-se da fase de organização e entendimento do processo a 
ser executado, que envolve o estabelecimento de limitações (escopo) e o 
levantamento dos critérios que devem ser utilizados nas atividades de 
avaliação. Por meio dos exemplos, ficou clara a necessidade de atenção a 
essa fase, devido justamente ao caráter organizacional que ela confere 
à auditoria. Ainda dentro da fase de planejamento, foram discutidos os 
aspectos relacionados às formas de documentação dos procedimentos e 
resultados da auditoria.
Por fim, foram tratadas as fases de execução e de resultados de uma 
auditoria. A fase de execução foi permeada por discussões sobre a análise 
de requisitos e pela aplicação da rastreabilidade, com a geração de logs e 
correlacionamentos; enquanto a fase de resultados foi caracterizada por 
detalhes sobre a geração de relatórios de auditoria.
80
Unidade II
 Exercícios
Questão 1. Os procedimentos de auditoria encontram respaldo na área de gestão e análise de riscos. 
Nesse contexto, analise as descrições I, II e III a seguir.
• Descrição I: trata-se de atividades coordenadas para dirigir e controlar uma organização no que 
se refere à questão dos riscos.
• Descrição II: trata-se do elemento que, de modo individual ou combinado, apresenta potencial 
para originar o risco.
• Descrição III: trata-se de uma ocorrência ou de uma mudança em um conjunto específico 
de circunstâncias.
As descrições I, II e III referem-se, respectivamente, aos termos:
A) Controle, evento e consequência.
B) Gestão de risco, fonte de risco e consequência.
C) Parte interessada, fonte de risco e gestão de risco.
D) Fonte de risco, gestão de risco e evento.
E) Gestão de risco, fonte de risco e evento.
Resposta correta: alternativa E.
Análise da questão
Justificativa: a gestão de risco corresponde às atividades coordenadas para dirigir e controlar uma 
organização no que se refere à questão dos riscos.
A fonte de risco é o elemento que, de modo individual ou combinado, apresenta potencial para 
originar o risco.
O evento é uma ocorrência ou uma mudança em um conjunto específico de circunstâncias.
81
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
Questão 2. A análise de requisitos visa estabelecer os critérios, as limitações, os parâmetros e o 
escopo dos dados relativos à validação dos resultados da atividade proposta. Na listagem a seguir, temos 
os componentes C1, C2, C3, C4 e C5 de uma análise de requisitos.
• C1: realizar a modelagem relativa à solução escolhida.
• C2: especificar requisitos (funcionalidades, interfaces, desempenho, parâmetros, formas de 
avaliação e limites).
• C3: identificar o problema que está ocorrendo.
• C4: avaliar o problema e apresentar alternativas de soluções.
• C5: fazer a “revisão auditor-auditado”.
Assinale a alternativa que apresenta o ordenamento sequencial correto dos componentes, do 
primeiro ao último a ser executado.
A) C2, C1, C4, C5 e C3.
B) C4, C1, C3, C5 e C2.
C) C3, C5, C2, C1 e C4.
D) C3, C4, C1, C2 e C5.
E) C1, C2, C3, C4 e C5.
Resposta correta: alternativa D.
Análise da questão
Justificativa: o ordenamento sequencial correto dos componentes C1, C2, C3, C4 e C5, do primeiro 
ao último a ser executado, é apresentado a seguir.
Primeira etapa
C3: identificar o problema que está ocorrendo.
Segunda etapa
C4: avaliar o problema e apresentar alternativas de soluções.
82
Unidade II
Terceira etapa
C1: realizar a modelagem relativa à solução escolhida.
Quarta etapa
C2: especificar requisitos (funcionalidades, interfaces, desempenho, parâmetros, formas de avaliação 
e limites).
Quinta etapa
C5: fazer a “revisão auditor-auditado” para a verificação de rumos, a eliminação de atividades 
redundantes, a retirada de inconsistências e o levantamento de novas necessidades, por exemplo.